Document Robot

Context and problem

To analyze credit, the sales team receives from each customer a package with dozens of files (trial balances, contracts, bank statements, partners’ IDs) as ZIP, RAR, photos and scanned PDFs. Someone opened file after file, named it, stored it in the right SharePoint folder and then filled the CRM with the folder link and what was still missing for the analysis.

The robot walks that path on its own: it receives the package from the CRM card, classifies each document with AI, renames it to the TYPE ENTITY MM.YYYY standard, files it in the right folder and returns the link and a checklist of pending items to the CRM.

Project constraints

• When in doubt, a person decides. The automation flags what needs checking and never rewrites type, period or name on its own.
• Nothing gets lost. Replace mode never deletes the previous folder, and an archive that fails to extract does not count as a delivered document.
• One run per customer. Two concurrent runs for the same customer are blocked at intake.
• Hostile files exist. Recursive extraction with limits against compression bombs, and symbolic links inside RAR files are refused.
• Cost and latency matter. Every document goes through a model; picking the setting is an engineering decision, not a matter of taste.

Decisions that shaped the product

Measure before choosing

Architecture

Operating lessons

• Extensions lie. A video saved as .pdf broke classification. Now the real file type is detected before any other step.
• Tests never touch production. A test run against the real database cancelled a real job and created 97 copies. A test and a config guard now prevent it.
• Success must be confirmed. Zero confirmed CRM writes become an error, never a success. The checklist is saved in the database, and a command resends only the CRM part without repeating the upload.
• Large files take their own path. Above 20 MB the document goes through the model’s file API, and SharePoint uploads are chunked above 100 MB.
• Throttling is expected. SharePoint calls retry with backoff behind a breaker that opens after 5 consecutive throttles.

My role

I conceived the robot and built its foundation over four months: the end-to-end pipeline, the CRM and SharePoint integrations, the naming and folder standard, the checklist, idempotency and operations. In October a collaborator ran a classifier-hardening pass: the thinking-budget experiment, parallel classification, the rule-based review, the large-file path and the guard against malicious RAR files.

What the product delivers

• Classification of 26 document types, including photos and scanned PDFs, with entity, accounting period and a flag for debt documents.
• Standardized names and folders, with separate folders for partners and group companies.
• A pending-items checklist in the CRM, computed over the whole folder and aligned with the credit-analysis team’s rules.
• Live progress for every run and a full history.

What I would do differently

• An anonymized reference set in CI. Today the labelled sample contains real documents and cannot live in the repository, so accuracy regression is still measured outside the pipeline.
• Ask the model for a confidence level. Without it, review relies on rules alone; a score would let human checks be prioritized.
• Plan the move off the single process earlier. A simple database and one worker serve today’s volume well, but they are the known scaling limit.