How to measure an automation pilot without overstating savings
Measure an automation pilot by separating hands-on work, elapsed time, exceptions, and costs before claiming savings.
On this page
An automation pilot should measure the change in a defined process, including the work created by the automation itself. Separate hands-on effort, elapsed time, exception handling, and financial effects. A faster notification is not proof of a lower operating cost.
Record a usable baseline
Choose comparable work before and during the pilot. Record the number of cases, their complexity, staff effort, waiting time, and rework. Note differences such as staff experience or a quieter trading period that may affect the comparison.
Do not compare a difficult historical month with a hand-picked set of easy pilot cases and attribute the entire difference to the new workflow.
A transparent worked example
Suppose a hypothetical team processes 100 comparable requests. Before the pilot, each takes eight minutes of hands-on work: 800 minutes in total. During the pilot, routine handling takes three minutes per request, while ten exceptions require ten additional minutes each. Monitoring the workflow takes another 60 minutes.
The pilot effort is 300 + 100 + 60 = 460 minutes. The observed reduction is 340 minutes, or five hours and 40 minutes, for this sample. Those figures are illustrative and are not Dood client results.

Distinguish capacity from cash
The released time may allow staff to complete other work. It becomes a financial saving only when a real expense changes or an avoided expense is justified. Keep those claims separate.
Include software fees, implementation, training, and ongoing maintenance when evaluating the financial case. Also record benefits that do not translate neatly into money, such as clearer ownership or more complete records, without assigning invented monetary values.
Use a compact pilot scorecard
| Measure | Question |
|---|---|
| Hands-on effort | How much staff time does the whole process use? |
| Elapsed time | How long does the customer wait? |
| Exception share | How often does the ordinary path fail? |
| Rework | How much work must be corrected? |
| Coverage | Which cases are excluded from automation? |
| Reliability | Can failed work be identified and resumed? |
Agree the continuation decision before reviewing the results: expand, revise, or stop. A pilot that reveals a poor fit can still prevent a larger mistake.
Use the first-workflow guide to choose the scope, then discuss a measurable prototype with a baseline your team can reproduce.