A pilot is one process, two weeks, a fixed fee. It ends with a written report. The report is the reason to run a pilot rather than a demonstration: a demonstration shows what a system can do on our documents, a report says what it did on yours.
This note lists the sections of the report and what each one is for. The structure is the same for every process; the figures come from the partner's own sample and are never quoted before the pilot.
1. The process, as scoped
The first page restates the scope that was agreed before day one: the process, the document types or channels, the fields or decisions, the systems involved, and the sample that was used. If anything changed during the two weeks, this section says what and why.
2. The sample
Where the documents came from, how many there were, how they were chosen, and how the ground truth was produced. Ground truth is usually the partner's own historical output, corrected where the pilot found it wrong. The report says how often that happened, because it is a finding in itself.
3. Acceptance criteria and results
The criteria were written down before the pilot started. This section puts each one beside its result. For extraction, that is field accuracy per field and overall, and the exception rate: how many items went to a person. For classification, it is accuracy per class and the confusion between classes. For an agent, it is disposition accuracy and the hand-off rate.
Every figure carries its basis: the sample it was measured on, the definition used, and the date. A figure without a basis does not go in the report.
4. What went to review, and why
The review queue is part of the system, so the report describes what reached it. Which fields, which document types, which rules. Which corrections the reviewers made most often. This is the section a process owner reads most closely, because it says where the work will be once the system is live.
5. What we found in the process
A pilot always finds something about the process that nobody had written down. A supplier whose invoices arrive as photographs. A field that two teams define differently. A rule that has an exception everyone knows and no document records. These go in the report as findings, with a suggested handling for each.
6. What the production system would need
The gap between the pilot system and a production one, stated plainly: integrations, volumes, environments, residency, reviewer capacity, and the monitoring the operations retainer would add. This is the section that becomes the SOW.
7. What transfers
A list of what the partner receives at the end of the pilot: the report, the running system, the code, the prompts and rules, the evaluation set, and the audit log of the two weeks. Everything we build transfers to the partner, and this section is the inventory.
What is not in the report
There are no comparisons to other vendors and no projections of savings. The first is not ours to make. The second depends on the partner's costs and pricing, which we do not see, because the BPO sets the price.
The report is written so that the partner can put their name on it and hand it to their client. That is the test we apply to every sentence in it.