Measure before you build
The most common reason an AI project cannot prove its value is that nobody recorded the baseline. Two weeks of timing the current process, before anything changes, settles the question permanently.
It costs almost nothing and it is impossible to reconstruct afterwards.
What to record
- Time per item, sampled over a normal fortnight including a busy day
- Volume per week, and how much it varies
- Error rate, and what errors cost when they escape
- Backlog age — how long things wait
- What people stopped doing because of this work
Be honest about saved time
Six hours a week saved across four people is not one and a half days of capacity unless those people had something specific waiting. Otherwise it is a better week, which is worth having and is not a number for a business case.
The credible version names what the time went to: a backlog cleared, a role not backfilled, more calls made, faster response to customers.
Measures that survive scrutiny
| Measure | Credible because |
|---|---|
| Roles not backfilled | Directly visible in payroll |
| Backlog eliminated | Countable before and after |
| Response time to customers | Measured by the system, not estimated |
| Errors prevented | Countable, with known cost each |
| Volume handled without added headcount | Growth absorbed, evidenced |
Review at ninety days
Not at launch. Quality settles about six weeks after first users, and behaviour change takes longer than that.
Book the review when the project starts, with the baseline attached. A scheduled review with a number is what protects a good system at the next budget round.