Many automation projects are declared successful at go-live. The workflow runs, the demonstration looks clean and the project team moves on. Six months later, nobody can say whether cycle time fell, whether exceptions grew or whether people quietly returned to the old spreadsheet. The automation is still there. The improvement is unproven.
Measurement after go-live is not a reporting exercise for its own sake. It is how you find out whether the design worked, where it needs adjustment and whether the next investment is justified. The method is simple: decide the measures before you launch, take a baseline, then repeat the same measures on a schedule.
Choose a short list and keep it stable
A useful measurement set is small enough that someone will actually produce it. Four to six measures is enough for most processes. They should be defined in writing, with a start event, an end event and a rule for what is excluded. If “cycle time” means something different in month one and month four, you do not have a measure. You have a series of anecdotes.
- Volume: how many cases entered the process.
- Straight-through rate: how many finished without a person intervening.
- Cycle time: start to finish, including waiting.
- Hands-on time: minutes of human work per case, where you can sample it.
- Exception rate: how many cases left the happy path, and why.
- Rework: how many cases came back after they were thought complete.
Not every process will have all six. A routing change in support may focus on first-assignment resolution and reassignment count. An invoice flow may focus on straight-through rate, cycle time and exception reasons. The important thing is that the same definitions are used before and after.
Take the baseline while the old process still exists
The most common measurement failure is starting the clock at go-live. Without a baseline, any later number can be interpreted as an improvement. Two weeks of measurement on the current process is enough if you cannot get more. Use system timestamps where they exist. Where they do not, sample real cases rather than asking for a general estimate.
Record the conditions of the baseline. Was it a quiet period or a peak? Was a key person away? Did a system outage distort the numbers? These notes prevent a later argument in which someone dismisses the comparison because “that month was unusual.” Every month is unusual in some way. The notes make the comparison honest.
If you cannot describe how the process performed last month, you will not be able to describe how automation changed it.
Read exceptions as design feedback
After go-live, the exception queue is the most valuable report you have. Each reason code is a sentence about the design. “Missing cost center” means capture is incomplete. “Wrong team” means routing rules are off. “Customer already resolved this” means tickets are being created that should not exist. Review the top reasons monthly and change the design, not only the staffing of the queue.
A rising exception rate is not automatically a failure. It can mean the process is now visible. Work that used to hide in inboxes is sitting in a queue with a name. Distinguish between exceptions that were always there and exceptions created by the automation, such as a rule that is too strict or a data field that is being required too early.
Watch for silent reversion
People will return to old methods if the new path is slower, unclear or untrusted. The signs are familiar: a shadow spreadsheet appears, approvals move back to email, a “temporary” workaround becomes the real process. Measurement should include a periodic look at these paths, not only at the official workflow numbers.
Adoption is part of performance. If 40 percent of volume still arrives through the old channel, the automation is not yet the process. That may be expected in the first weeks. It is a problem if it is still true after three months and nobody owns the remaining channel. Closing the old path, once the new one is reliable, is often the step that makes the benefits real.
Report what changed, and what you will change next
A good post-launch review is short. It shows the baseline, the current figures, the main exception reasons and one or two design changes you will make. It does not need a slide for every metric that moved by a point. It does need enough honesty that a skeptical reader can see what worked and what did not.
This review is also the input to the next piece of work. If invoice matching is straight-through but approvals still wait three days, the next design problem is clear. If routing improved but customers still send unstructured email, intake is the next constraint. Measurement turns a completed project into a sequence.
Where to start
Before the next go-live, write down four measures with definitions, take two weeks of baseline data and name the person who will produce the same figures at 30, 90 and 180 days. After launch, read the exception reasons before you read the success metrics. Adjust the design. Then decide, with evidence, whether the process is better than it was.