Measure the work saved, and the work that remains.

1. Establish a baseline people trust.

Measure a representative sample of the existing process before changing it. Record volume, active handling time, waiting time, and corrections. Include work that happens outside the main tool, such as finding missing information or chasing an approval.

Ask the people doing the work to check the numbers. An optimistic estimate of time spent can make a later improvement look larger than it is. If the sample is small or unusually busy, record that limitation alongside the result.

2. Separate capacity from cash savings.

A simple capacity estimate is the number of eligible tasks multiplied by the reduction in average handling time. Subtract time spent reviewing output and resolving exceptions. Use the number of tasks the automation actually handles, not the total volume entering the team.

Released time does not automatically reduce spending. It may create room for faster follow-up, better service, or work that previously went undone. Describe that as capacity unless there is a specific, observed change in cost.

3. Include the ongoing work.

Build effort is only part of the cost. Include relevant tool usage, maintenance, monitoring, reviews, and updates when connected systems or business rules change. Be explicit about which costs already exist and which are added by the new workflow.

For an early estimate, use a range and write down the assumptions. A process with many exceptions may need more human attention than a clean demonstration suggests. Review those assumptions after the pilot rather than treating the original forecast as a fixed commitment.

4. Track quality alongside speed.

Choose measures that reveal whether the work is actually better: duplicate records, missing fields, incorrect routing, unresolved exceptions, or time until an owner receives a usable request. Keep definitions stable so the before-and-after comparison means something.

Review a sample of completed work, including successful runs. Logs can confirm that an action executed without showing whether the information was useful or correct. Ask downstream users whether the new output reduces their work.

• Compare similar categories and periods.
• Record manual intervention rather than hiding it.
• Investigate fast results that generate extra corrections later.

5. Decide what the evidence supports.

At the end of the pilot, compare the measured result with the agreed goal and the full operating effort. Explain what improved, what did not, and what remains uncertain. Separate observed outcomes from projected benefits at a larger volume.

The right decision may be to expand, simplify, change the input process, or stop. A small pilot is valuable when it answers that question clearly, even if the answer is that this task should remain manual for now.