The baseline of a process is the measurement of how it works today, before you change it: how long each case takes, how many cases there are, how many errors occur and what it costs in people's hours. You get it by logging, for one week, every time someone runs the process, with start time, end time, outcome and incidents. Without that measurement you cannot know whether an automation has improved anything, or how much you can afford to spend on it.
When I am asked to automate a process, the first question is always the same: what does it cost today? The usual answer is "a lot" or "loads of hours". That is no use for deciding. What is useful is a number with a method behind it. This article explains what to measure, how to do it in a week without special tools, and how to use the result to decide whether to automate, how much to invest and how to prove the improvement afterwards.
Why measure before, not after
There are three practical reasons:
- Deciding whether it pays off. If a process costs four hours a month, an automation costing several thousand euros will never pay for itself. If it costs forty hours a week, almost any improvement pays for itself. Without the number, you decide on intuition.
- Setting the budget. The annual cost of the manual process is a reasonable ceiling for what makes sense to invest in the first year. It is a simple rule, but it prevents oversized projects.
- Proving the improvement. After automating, everyone remembers the old process as worse or better than it was. With before-and-after data the comparison is objective and it justifies the next investment.
There is a fourth, less obvious reason: measuring forces you to describe the process step by step, and in doing so the steps that make no sense come to light. Sometimes the best automation is removing a step, not speeding it up.
The four quantities that matter
| Quantity | What it measures | How it is logged | Unit |
|---|---|---|---|
| Volume | How many cases come in during the period | One row per case in the log sheet | Cases per week |
| Working time | Minutes of a person's real attention per case | Start and end of each intervention; added up if there are several | Minutes per case |
| Cycle time | From the moment the case comes in until it is closed | Time in and time closed | Hours or days per case |
| Errors and rework | Cases that had to be corrected, redone or chased | Incident column with the reason | Percentage of the total |
Cost derives from the above: working time per case, times volume, times the person's hourly cost. The hourly cost is not gross salary divided by hours: you have to add the employer's social security contributions and the other costs attached to the role. If you do not have the exact figure, use an estimate and label it as such: what matters is that the same figure is used before and after.
Keep working time and cycle time clearly apart. A quote can take twenty minutes of work and three days of cycle because it waits for someone to approve it. Automating the twenty minutes does not change the three days. Sometimes the business problem is the cycle (the customer gets tired of waiting), and the solution is not AI but an automatic reminder to whoever approves.
The one-week template
No software needed. A shared spreadsheet with these columns, filled in by the people who run the process, is enough:
| Column | What to record | Example |
|---|---|---|
| Identifier | Case reference | Request, invoice or ticket number |
| Received | Date and time it arrived | Monday 09:12 |
| Started | When someone started working on it | Monday 11:30 |
| Finished | When it was closed | Tuesday 10:05 |
| Working minutes | Real attention time, adding up interruptions | 35 |
| Outcome | Closed, waiting for data, rejected | Waiting for data |
| Incident | What went wrong, if anything did | Tax ID missing; price copied wrongly |
| Who | Person or role that did it | Admin |
Rules that make the data usable:
- One full, normal week. No public holidays, no month-end close, no key person on holiday. If the process has monthly peaks, measure a peak week too and keep the two apart.
- Log in the moment, not at the end of the day. Memory rounds things off. A timer on your phone or a quick note at start and finish is enough.
- Log every case, including the easy ones. The temptation is to log only the problematic ones. That inflates the average time and distorts the decision.
- Separate "work" from "waiting". If someone leaves a case half done to take a call, the minutes on the call do not count.
- Write the reason for each incident in concrete words. "Error" is no use; "old price list" is. At the end of the week, group the reasons and the pattern appears.
What to calculate at the end of the week
- Weekly volume and its annual projection (multiply by active weeks, not by 52).
- Median and 90th percentile of working time. The mean misleads when there are extreme cases. The median says how long a typical case takes; the 90th percentile, how long the hard ones take. The hard ones are what will decide whether the automation works.
- Median cycle time. To know whether the problem is the work or the waiting.
- Incident rate and its three most frequent reasons.
- Annual cost: annual working hours times hourly cost, plus an estimate of the cost of errors (time to fix them, discounts, lost orders) wherever you can put a figure on them.
With that you have two sentences that fit in an email: "Process X costs us Y hours and Z euros a year, and N% of cases need a correction". That is the baseline.
Three examples
The three cases are built to illustrate the method with plausible figures. They are not client data: measuring your own process will give different numbers, and that is the point.
Quotes
A services company receives requests by email and web form. The measurement week shows 42 requests, a median of 25 minutes of work, a 90th percentile of 70 minutes and a median cycle of two days. 30% were left waiting for data and someone had to write back to the customer. Conclusion: the biggest cost is not writing the quote but chasing missing information. The first automation is a form that cannot be submitted without the mandatory fields plus an immediate acknowledgement. Then, if it still pays off, an assistant that prepares the draft. I explain that second step in what is an AI agent.
Supplier invoices
Admin receives invoices as PDFs, keys them into the accounting software and matches them to the purchase order. Measurement: 85 invoices a week, a median of 8 minutes, 12% with an incident (amount does not match the order, duplicate supplier, repeated invoice). The annual cost can be calculated. Here automatic data extraction has enough volume, but the valuable figure is that 12%: the automation must detect the discrepancies, not only type faster. Also, in Spain invoicing is subject to its own technical requirements (verifiable invoicing systems, mandatory B2B e-invoicing) with implementation calendars published in the BOE; check the current one before touching anything.
Customer support
A support inbox receives 120 emails a week. A median of 6 minutes per reply, but a median cycle of 9 hours because it is checked only twice a day. 40% of the queries are the same five questions. Conclusion: half the problem is solved by a well-written FAQ page and an auto-reply that links to it. The other half, by automatic classification that prioritises what is urgent. An AI chatbot is the third option, not the first, as I explain in what is RAG and when search is enough.
Common mistakes when measuring
- Measuring an unusual week and extrapolating. If there was a peak or an absence, repeat it.
- Using only the mean. Three monstrous cases can double it. Look at the median and the 90th percentile.
- Forgetting the cost of errors. An invoice paid twice costs more than all the invoices keyed in that day.
- Measuring only the step you want to automate and not the whole process. The bottleneck may be somewhere else.
- Promising a saving before measuring. "We will save 70%" without a baseline is an empty promise. With a baseline it is a hypothesis that can be tested.
How to use the baseline in the pilot
Define success before you start, in the same quantities: "reduce the median working time from 25 to 10 minutes and the incident rate from 30% to 10% in eight weeks". Measure again with the same template once the pilot has been running for a month. If the target is not met, the data will say whether the problem is the tool, the process or the hard cases in the 90th percentile.
What is not measured before cannot be improved after; it can only be argued about.
If you want me to measure a process with you, the automation service starts with exactly this week of data, and the decision about what to build (or whether to build anything at all) comes out of it. You can write to me with the process you have in mind.