How to gather examples of past work before a custom AI project

An example is a pair. It holds what arrived and what a careful person did with it, such as a supplier invoice and the entry keyed into the ledger. Or a first quotation, followed by the version after the manager corrected the margin, which is the pair that teaches the most.

Both halves matter. An input without its correct result teaches nothing. Keep each file in its original form, whether PDF, phone photo, email body or spreadsheet, because that is exactly what the system will receive.

Typical cases are easy, and staff handle them without thinking. A build is judged on the odd ones. Think of the invoice with two tax lines, or the purchase order photographed at an angle with a coffee ring across the total. Add a quotation built in the customer’s own template, and a credit note that arrives labelled as an invoice and gets paid twice.

Ask the team which cases they dread. Which get checked twice? Then mine the correction trail: rejected entries, reopened tickets, credit notes and emails that say please ignore the previous version, all places where the first answer failed.

Cover every supplier, branch, language and format. A hundred invoices from one supplier tell the builder very little about the other forty suppliers whose layouts, tax lines and paper sizes are all different.

Start with a few dozen. Spread them across every variety you handle. Narrow, repeated tasks need fewer. Open-ended ones, like free-text email, need more. After a first test, the builder will show where the gaps are, and you then collect fresh examples for exactly those cases.

One named owner signs off each pair. Not the intern. Not the vendor. Where two experienced staff would disagree, note it, because the disagreement exposes rules nobody ever wrote down, and each one found now is a mistake avoided later.

Record who confirmed each pair and when. Rules change. A pair confirmed three years ago, before the discount policy was rewritten and the approval limits were raised, may no longer be right.

Leave out examples where the outcome was wrong and never fixed, because the system will learn the mistake along with everything else. Leave out papers from retired processes, old price lists and suppliers you no longer use, unless the build must read old archives.

Mask personal and confidential data you do not need. That means bank account numbers, salaries, patient details and ID scans. Ask the builder what they need and how it will be stored before anything travels by email. Check your contracts and local data-protection rules, and ask a lawyer if unsure.

Hold back a small set. These are your test papers. They measure the system later, on cases it has never seen.

Use one folder per task, with subfolders by document type and file names that carry the supplier or branch plus a number. One spreadsheet indexes every pair.

Add a single page describing the task. Who does it today? What does a correct result look like? Which fields matter? What does a wrong result cost? Then book half an hour with the builder, and walk through ten examples aloud so the odd ones get explained face to face.

Start this week. Ask each team member for their three most dreaded cases, and photograph the originals before anyone files them away.