Start here.
Define a useful completed job, record how that job works today, and compare it with a bounded trial of the proposed workflow. Count review, corrections, retries, and cleanup as part of the effort. Keep quality and unresolved work beside the time comparison so a quicker result cannot hide an unfinished handoff.
- Measure the accepted result, not just the generated output.
- Include the human work that moves into review and exception handling.
- Use a comparable workload and keep hypothetical calculations separate from observed results.
Define the finish line before timing anything.
For an illustrative inquiry workflow, completion could mean a usable destination record with the original message, the right owner, and a next step. A generated summary alone would not meet that definition. A record missing the contact address might be held for review instead of counted as complete.
Keep the acceptance condition the same in the current process and the trial. If the trial produces a shorter output or omits a step, compare that change openly. Otherwise the time saving may simply come from doing less of the job.
Also distinguish effort from elapsed time. Ten minutes of work spread across two days has a different effect from ten uninterrupted minutes. Both can matter, but they answer different questions.
Record a baseline that includes the awkward cases.
Observe a bounded set of ordinary jobs and record the source, work type, start, accepted completion, human effort, corrections, and unresolved issues. Capture reasons for rejection or rework while they are still visible. Avoid excluding the jobs that were inconvenient to finish.
Keep personal information out of a shared measurement sheet when it is unnecessary; an internal record ID can link an authorised reviewer to the original. Agree who records the effort and how waiting time is handled so people use the same definitions.
A baseline is evidence about that workload. A quiet week, a different reviewer, or a simpler set of requests can change the comparison. There is no universal trial duration or sample size that proves every automation useful.
Compare total effort and useful output together.
The example below is entirely hypothetical. It compares two sets of 20 similar inquiries under the same completion definition. The trial’s 70 minutes include 40 minutes reviewing proposals and 30 minutes making corrections and following up on exceptions. The baseline’s 120 minutes include its own checking and corrections.
Both sets reach 19 accepted completions and leave one inquiry unresolved at the cutoff. The trial takes 50 fewer minutes of human effort in this invented comparison, but more inquiries need a correction. Those two findings belong together.
| Measure | Current process | Automation trial |
|---|---|---|
| Inquiries received | 20 | 20 |
| Accepted completions at cutoff | 19 | 19 |
| Unresolved inquiries | 1 | 1 |
| Total human effort | 120 minutes | 70 minutes |
| Inquiries needing correction | 2 | 4 |
Find out where the work moved.
A reduction in typing can create a new queue of reviews. Check whether the same person now reviews every proposal, whether corrections are small or consequential, and whether someone must repair downstream records. The time spent monitoring failed deliveries belongs in the effort total too.
In the hypothetical example, the extra corrections are a reason to inspect the errors, not automatically a reason to accept or reject the trial. A repeated wrong assignment may require a routing fix. An omitted phrase may be cheap to repair. A missed commitment may make the result unacceptable regardless of the time saved.
Count missed jobs and duplicates as well as visible rejections. The integration guide explains why a timed-out request can leave an uncertain destination result. Measuring only requests marked successful can miss that cleanup work.
Keep cost estimates separate from measured time.
Fifty fewer minutes in a hypothetical set of requests is not an observed financial return. Turning a real effort difference into a planning estimate would require an agreed value for the time, expected volume, and evidence that the comparison remains representative. Freed time is not automatically a reduction in cash spending.
Include software charges, initial setup, ongoing maintenance, reviewer effort, and exception handling. State what you have measured and what you are assuming. Show a range if volume or support effort is uncertain rather than presenting one precise annual savings number.
Revenue or customer satisfaction may matter to the project, but a quicker handoff does not establish that either improved. Keep those outcomes separate until you have evidence that supports the connection.
Choose a decision the evidence can support.
Agree the decision criteria before the trial: what quality is required, which errors block use, how much review is manageable, and who makes the call. Expand when the complete workflow meets those conditions. Revise it when a specific repairable failure dominates. Stop when the result is unreliable or the total burden outweighs its usefulness.
Our MixPass story offers a useful distinction without claiming measured savings: feedback, a revision, and approval are different events. An evaluation should count the event that finishes the chosen job, rather than whichever event is easiest to instrument.
The result of a trial can be a clearer understanding of the job, including evidence that automation is unnecessary. A useful measurement brief lets that be an acceptable decision.
A worksheet for one job.
A short measurement brief is more useful than a broad promise to save time.
- Completed means
- Describe the accepted output and the next action it makes possible.
- Today’s baseline
- Record volume, work mix, total effort, unresolved items, and common corrections.
- Trial evidence
- Collect the same measures, plus review and recovery effort introduced by the automation.
- The decision
- Name the quality limits, responsible reviewer, and evidence that would justify expanding, changing, or stopping.
A couple of common questions.
Can we estimate savings before building?
Yes, as a labelled planning estimate. Start with an observed baseline, state the assumed change, and include review, setup, support, and ongoing costs. Verify the assumptions with a bounded trial before presenting them as achieved results.
What if output is faster but takes longer to review?
Compare the total effort to reach the same accepted result. Then inspect review reasons and unresolved work. Faster generation helps only if the complete workflow meets the quality and effort conditions you agreed.