A baseline of how work is done today
Before automating a process I establish a baseline of how it is currently done. It doesn’t require an extensive study: recording for a few weeks what comes in, how long it takes and what goes wrong is enough. Without that reference, nobody can later say whether the automation has added value.
Defining when a case is finished
This is where comparisons are most often distorted. It is best to choose a process with a clear start and end. For example, a request starts when it is received and ends when its data is validated and it has an assigned owner.
That definition must stay the same throughout the measurement. If you counted received requests before and created tasks afterwards, you are comparing different things.
Separating working time from waiting time
A request may need a few minutes of attention and then wait days for an approval. Automating those minutes doesn’t reduce the wait, and it is worth knowing that before starting.
I also record atypical cases, such as incomplete or urgent ones. If only the simple cases are measured, the exceptions, which usually account for most of the work, are left out of the analysis.
Errors and the cost of review
I record corrections and reopened requests. Once the automation is running, I also measure how many AI results a person reviews and how much time that takes.
A system often closes more tasks while creating more checking work. Measuring only the first figure gives a partial picture and doesn’t show which rules to adjust.
A rigorous comparison
I use the same definition of “finished” in both periods and don’t mix simple and complex requests. If the team changes or volume increases during the measurement, I document it, because it affects the result.
When the sample is small, I say so explicitly. It helps identify specific problems, but not yet to commit to a saving.
If you want to know whether a process is worth automating, here is how I work, or book a meeting and we’ll look at your case.