Measure before, or you cannot measure at all
The most common reason an automation cannot prove its value is that nobody recorded what the process cost beforehand. Two weeks of timing settles it permanently.
It costs almost nothing and it cannot be reconstructed afterwards, which is why it has to happen first.
Be honest about saved time
Four hours a week saved across three people is not half a day of capacity unless those people had something specific waiting. Otherwise it is a better week, which is worth having and is not a number.
The credible version names what the time went to: a backlog cleared, a role not backfilled, more customer contact, faster turnaround.
Measures that survive scrutiny
| Measure | Credible because |
|---|---|
| Role not backfilled | Visible in payroll |
| Backlog eliminated | Countable before and after |
| Turnaround time | Measured by the system |
| Errors prevented | Countable, with known cost |
| Volume absorbed without hiring | Growth handled, evidenced |
Count the full cost
- Build cost
- Hosting and any service subscriptions
- Maintenance, at 15–25% annually
- Your own team's time during the project
- The time spent monitoring and owning it
A business case counting only the build overstates the return, and it makes the next project harder to approve when the numbers do not hold.
Review at ninety days
Not at launch. Processes take weeks to settle and behaviour change takes longer. Book the review at the start, with the baseline attached.
A scheduled review with a real number is what protects a good automation at the next budget discussion.