The second step of our guide on how to implement AI in a company gives this advice: if nobody knows how long handling one case really takes, spend two weeks measuring it. This article shows how. The tool is a one-case log — a table with five columns, filled in for every case over ten working days. A number measured before the start like this is where we begin every business process automation project, rather than with a percentage borrowed from someone else’s company.
At the end the log turns into simple arithmetic. It contains no ready-made return percentage, because that percentage depends on numbers you have yet to measure. What it does show is which number goes where and how to read the result — including when the result is “don’t automate”.
First, check what your systems already record
Before anyone starts logging, check what the systems a case passes through already record. A ticketing system, an ERP (the system that runs orders, stock and accounting) or a CRM (the system for customers and sales) often keeps a history of the case: when it came in, when its status changed, who took it over, when it was closed and whether someone reopened it. A mailbox at least keeps the dates of messages and replies. Establish which fields those records can supply and which will have to be filled in by hand.
From the records available, check whether you can establish:
- how long the case took from arrival to closing;
- how many times it changed hands;
- whether it came back for rework — a reopened case, a corrected document;
- which status it sat in longest.
Two notes on those records. Handing a case to someone else is not the same as a touch: the same person can come back to a case several times, and the system usually does not record that. Count a reopened case as rework only once you have checked why it was reopened — sometimes it is simply the next stage, not a mistake.
What systems usually do not know is how many minutes someone actually spent working on the case. An “in progress” status can last two days while the work itself took a quarter of an hour. That one column is the one you usually have to note by hand.
This is the same test that is step three in the guide: try to export the last hundred cases as a single table. If the export works, keep it: cases from before the measurement will come in useful shortly, when you check whether the measurement itself changed how people worked.
The one-case log: five columns
Before you start, settle three things. First, what starts a case and what finishes it — for example, the email arriving and the decision being sent to the customer. Second, that the log takes in cases that arrive during the ten days, and that you follow them to the end, including after the last day of the measurement. Add up the results only once all or nearly all of the cases from those ten days have closed. Do not leave out cases that are still open: they are usually the longest ones, so without them the average would come out too low. Include them with the time that has passed up to the day you add up, give their number next to the result, and note that the average is then a lower bound — the real one will be higher. This applies to how long cases take; for labour costs, use only the minutes worked that were recorded. Third, for how many days after closing you check whether a case came back for rework; that period must be the same before and after implementation, and until it has passed, write “not yet known” in the “Rework” column. Count that period from the first closure and note its date in the notes. If the case comes back for rework, add its minutes and change “Finished” to the date and time it closed after the rework. Work out the final rework rate only once that period has passed for every case in the log. If you need a figure sooner, report it as interim: next to the rate, say how many cases it was calculated from and how many are still “not yet known”. Cases that close later are often the harder ones, so an interim rate may come out too low.
Each case is one row. Besides the case number and the date and time it came in and was finished, you record five things:
| Column | What to write | What it is for |
|---|---|---|
| Time worked | Total minutes in which someone actually worked on the case | The labour cost, and what automation could take over |
| Time waited | Time from arrival to finish minus time worked, calculated at the end | How much of the time the case took was waiting rather than work |
| Touches | How many times someone picked the case up | Shows frequent interruptions; their cause needs checking |
| Rework | Yes, no or “not yet known”: did the case come back because something was done wrong | Today’s error level, to compare with the system’s errors |
| Where it stalled | The step at which the case waited longest — from the status history in the system, or from the start and end times of spells recorded in the notes | Whether the waiting comes from a shortage of hands or from something else |
Why five columns rather than a dozen metrics from the guides? Because each of them answers one of the questions that come up below: in the cost arithmetic, or in judging whether automation will shorten the wait. A column that answers none of them only makes logging longer — and the longer logging takes, the sooner people start filling it in carelessly. A single entry — adding the minutes after another spell of work, or changing a date — should take well under a minute. A case someone came back to many times takes longer in total, because there are more entries; that is expected. If a single entry already takes longer, there are too many columns or they are unclear.
Download the log template (CSV): a hundred numbered rows, these columns and space for notes, with no formulas and no fields for customer data. It opens in Excel or Google Sheets; if you have more cases, add rows.
How to note time worked
You do not need a stopwatch. After each spell of work on a case, the person who worked on it adds to the row how many minutes it took. Record a spell shorter than a minute as an estimated fraction of a minute (for example 0.2), add up without rounding and round only the result you report — work out time waited from the unrounded total. If the system keeps no status history, at each spell also record in the notes the start and end times and what the case was waiting for before that spell (for example “Wed 9:40–9:55, waiting for photos”). Waiting is the gap from arrival to the first spell, the gaps between the end of one spell and the start of the next, and the gap from the end of the last spell to the finish — for example when the case was still waiting for an approval, an overnight system run or a batched send. Note the reason for that last gap in the notes too; the longest of all the gaps shows where the case stalled. If the reason changed during a gap — for example, the photos arrived but the case still sat in the queue — record that change with its time and count the two stretches separately; if you do not know, mark the reason as “not established”. The simplest way is to type successive numbers into the “Time worked” column as a formula, for example =10+15, and to add one to the “Touches” count each time. A case that comes back for rework stays on the same row: the rework minutes go into the same total. If the system is meant to take over only part of the work — say, reading and entering the data, but not the conversation with the customer — at each spell also note in the notes how many of those minutes belong to that part, because those are the minutes that go into the arithmetic. If people on different rates work on a case, add the role too, for example “manager 10, of which 6 in scope”.
If there are so many cases that logging each one takes a noticeable part of the day, log only some of them — say every fifth case in order of arrival, starting from one picked at random among the first five — always by the same rule, set before you start. Picking “typical” cases by eye distorts the result, because it leaves out the hardest ones.
The minimal version: four fields
If you know nobody will keep up full logging for ten days, start with four fields: received, first closed, finally finished (different only when the case came back for rework), and “came back for rework: yes, no or not yet known”. The first closure shows whether the rework follow-up period has passed. That gives you how long cases take and the rework rate, but it does not separate work from waiting, so the saving in the arithmetic will remain an estimate. A minimal version is better than a full log abandoned on day three.
An example of a filled-in log
The rows below are invented: they show what a filled-in log looks like, not what the process looks like in any company. The process is complaints at a wholesaler, from the customer’s email to a decision.
| Case | Received | Finished | Time worked (min) | Time waited (h) | Touches | Rework | Where it stalled |
|---|---|---|---|---|---|---|---|
| R-101 | Mon 9:10 | Mon 14:40 | 20 | 5.2 | 2 | no | complaints team queue |
| R-102 | Mon 11:30 | Wed 10:05 | 35 | 46.0 | 3 | yes | photos from the customer |
| R-103 | Tue 8:45 | Tue 9:30 | 15 | 0.5 | 1 | no | — |
| R-104 | Tue 13:20 | Fri 12:00 | 25 | 70.3 | 4 | no | manager’s approval |
| R-105 | Wed 16:50 | Thu 10:15 | 20 | 17.1 | 2 | no | complaints team queue |
Time waited is counted here in calendar hours, nights included, because the customer waits through the night too. What matters is counting it the same way before and after implementation. In the template, once received and finished are entered as a date with a time, type =24*(D2-C2)-E2/60 into cell F2 and copy it down: a spreadsheet counts the difference between dates in days, hence the multiplication by 24, and dividing the minutes worked by 60 turns them into hours. Subtracting the minutes worked from how long the case took works when people do not work on it at the same time. If two people worked on a case simultaneously, record time waited as “not established”; both people’s minutes still count towards the labour cost.
Even five rows show something. Work takes minutes; waiting takes hours and days. The longest waits were for a manager’s approval and for photos from the customer — the system taking over the work will not speed those up on its own. The complaints team queue is different: the case waited until someone had time for it, so less work on each case can shorten that wait.
Why ten working days
Ten days is our practical starting point, not a standard. Ideally they are two full calendar weeks, Monday to Friday: every weekday then appears in the measurement twice, so the Monday rush or a quiet Friday distorts the result less than in a measurement lasting a few days. If a public holiday or a company closure falls in that time, add the same weekday from the following week — for example, the next Wednesday in place of a Wednesday holiday — and note which day was missing. Two weeks do not guarantee that the measurement covers a month-end or a quarter-end, though. If your process has peaks like that — month-end close, settlements, a season — run a second measurement window that covers them, and work out the averages for the two windows separately. How to combine them in the arithmetic is explained below.
The second trap: people who know they are being observed may work differently from usual. This is called the Hawthorne effect. A review of the research on it, published in 2014, found signs of such an effect in most of the studies it analysed, but its authors write that little is known about when it appears or how large it is. That is why system records are so valuable: they were made before anyone started measuring anything. Compare how long cases took during the logging period with how long cases took in the export for previous months. If cases were closed noticeably earlier than usual during the measurement, treat that as a signal to look into, not as proof: also compare the number and type of cases and how many people were at work. If those conditions were similar, the measurement itself remains one possible explanation — so do not treat the faster result as an ordinary week without further checking. It is safer then to take case durations from the pre-measurement export and only the minutes worked from the log, bearing in mind they may be understated too.
Work and waiting: two different numbers
Separating these two columns is the most important thing in the whole log. Automation takes over work. That shortens waiting mainly when the case was waiting for someone to become available, that is, in the queue for the people who do the work. If it was waiting for a manager’s decision, a document from the customer or a reply from another company, taking over the work will not shorten that wait on its own. Only a solution that also covers that stage will — for example, one that spots a missing document straight away and sends the customer a reminder.
So the log produces two separate numbers:
- the labour saving — minutes of work a person will no longer do; only this number goes into the cost arithmetic below;
- the time the customer experiences — hours from arrival to finish; this number changes mainly for cases that sat in the queue for work, not for those waiting on a decision or documents.
The “where it stalled” column lets you separate these cases. Count in how many cases the longest wait was the queue for work and in how many it was something else. If the second outweighs the first, a promise of “three days down to an hour” is not backed by taking over the work alone — it also takes a change to the approval rules or to how documents are collected. The labour saving may still be worth having; it is simply a different goal from a shorter wait.
The “Touches” column helps here too. Many touches with only a few minutes of work are a signal to check why work was interrupted and whether the case went back into the queue. If it was waiting for missing data, that wait can be shortened by a solution that gathers all the data before the case reaches a person.
The arithmetic: the saving and four cost items
You take the numbers in square brackets from your own log and your own price lists. The rate is the hourly cost of the person who handles the case, including employer costs — not just the salary in their contract. If people on different rates work on a case, cost each role separately from the notes (role, minutes and minutes within the automation scope) and add the results.
Gross monthly saving = [cases per month] × [average minutes worked per case within the scope the system is to take over] ÷ 60 × [rate]
Use only the work the system is meant to take over; leave out tasks that will stay as they are. The formula assumes the system takes that work over in every case, so it is an upper limit. What stays with a person anyway — checking and approving, and the cases the system will not handle — you deduct in the table below.
Take the number of cases per month from a system export. Without an export, scale to a month the number of all cases that arrived during the measurement — including those you did not enter in the log if you logged every fifth case. If cases arrive only on working days, divide that number by 10 and multiply it by the number of working days in the month you are calculating (with 21 working days, that means multiplying by 2.1). If cases also arrive at weekends and on public holidays — customer emails, for example — the measurement covers two full calendar weeks, from the first Monday to the last Sunday. Enter weekend cases in the log like any other when someone picks them up, so that the average time worked includes them too, and divide the number of cases by the number of calendar days you counted them over — usually 14, or one more if you added a day in place of a holiday — and multiply by the number of days in the month. If you know only the number of rows in an every-fifth sample rather than the number of all cases, multiply it by 5 as well. That conversion is a poorer approximation than an export, because it misses the peaks. The average time worked from a sample of every fifth case, on the other hand, can be used as it is. Time worked here is the average, not the median (the middle value): the cost is the total of all cases’ minutes, and the total equals the number of cases multiplied by the average.
If you measured in two windows — an ordinary period and a peak — do not multiply the ordinary window’s average by every case in the month. Work out each period separately: [cases in the ordinary part of the month] × [average minutes worked from the ordinary window] + [cases in the peak] × [average minutes worked from the peak window]. Put that total of minutes into the formula in place of the number of cases multiplied by the average. Take the number of cases in each period from a system export. If the peak comes once a quarter, work out the whole quarter this way and divide the result by three.
Four items go into the arithmetic: three reduce the monthly saving, and one — the parallel-running period — is added once to the build cost. The first two are the cost of a set-up in which the system prepares the result and a person approves it. We start every implementation with that set-up (step 4 of the guide explains why), so it has to be counted from the start, not after everyday use begins. The table also mentions the AI model — the engine the solution runs on, like the one behind ChatGPT; its provider charges for use and retires older versions from time to time.
| Item | Formula | Where the numbers come from |
|---|---|---|
| Checking results (monthly) | [cases per month] × [share of cases the system handles] × [minutes to check, correct if needed and approve one case] ÷ 60 × [rate] | From a pilot on a few dozen cases; before a pilot, an estimate from the person who handles the cases today. How to design the approval itself is the subject of our piece on human approval |
| Exception queue (monthly) | [cases per month] × [share of cases the system will not handle] × [minutes of in-scope work per such case] ÷ 60 × [rate] | The share from the pilot; the minutes at first from the log, for unusual cases rather than the average, and later from the pilot. Where the line between the system’s cases and a person’s comes from: step 6 of the guide |
| Parallel-running period (one-off) | [weeks] × ([additional model and infrastructure fees per week] + [hours comparing results per week] × [rate]) | Step 6 of the guide: the system runs alongside people who keep working as before |
| Retest after a model change (per month) | [model changes per year] × [cost of one test] ÷ 12 | Our piece on automation maintenance; the cost of a test is the hours and rate of whoever runs it, in-house or a contractor |
Count every minute and every charge once. A case the system handled goes into checking results; a case that went to the exception queue goes only there — with all the minutes spent checking, correcting and finishing by hand the work the system was meant to take over. Leave tasks outside that scope out of both the gross saving and the deductions. For the parallel-running period, count only what comes on top of current handling — do not add people’s ordinary work a second time.
On top of that come the remaining running costs: model and infrastructure fees that depend on the number of cases, quality monitoring (periodic sample checks, not approving each case), and fixes after changes in connected systems. We set them out in our piece on what AI implementation costs, so we do not repeat them here. The fourth item listed there, periodic retesting, is already in the table above.
Net monthly saving = gross saving − checking results − exception queue − [running costs per month] − retest after a model change (per month)
Months to pay back = ([build cost] + [parallel-running period]) ÷ [net monthly saving]
The months are counted from the switch to everyday work with the system; the build and the parallel-running period come before that. To know how many months will pass from the start of the project, add the time the build and the parallel running take. If the net saving comes out at zero or below, there is no point working out the months: automation in that form will not pay back, whatever the build costs.
One caveat that is easy to forget: this arithmetic values the time that is freed, not money that stays in the bank. If people are paid the same, the company gets hours back, not cash. Automation pays back in money only once the freed time turns into lower spending — less overtime, less work sent outside, a new hire you do not need as the number of cases grows — or into additional work that earns money after the cost of doing it. For a cash payback, use that lower spending or those earnings, not the full value put on the freed hours. If you cannot say what you will use that time for, write it down as an open question before you start building.
What the arithmetic shows with many cases and with few
The cost of the build and of the parallel-running period is largely fixed, while the saving grows with the number of cases. For a process repeated in the company hundreds of times a month, minutes decide the result: a few minutes saved, multiplied by hundreds of cases, can cover the running costs and, over time, the build cost. For a process done a few times a month, the build cost decides — divided by a small saving, it gives a long payback time.
We deliberately do not say how many months that is. A number given without your rate, your number of cases and your checking time would come from someone else’s process.
After implementation: the same log again
Once you move from parallel running to everyday work with the system, keep the same log, in the same columns, for the same number of working days and in a comparable period — do not set a month-end against an ordinary week. For each case, also record whether the system handled it with approval or it went to the exception queue. For cases the system handled, note the total time spent checking, correcting if needed and approving the result; for exceptions, all the minutes spent checking, correcting and finishing by hand the work the system was meant to take over. Time worked in the main column still includes all of a person’s minutes; these extra notes are parts of that total, not time to add on top. These are the numbers that were estimates in the arithmetic above; now you check them.
When the measurement says: don’t automate
A log can be most useful when it rules a project out. Hold back if:
- there are few cases — the gross saving, even if all of the work were taken over, does not cover the running costs; a process done a few times a month rarely justifies an integration project, as we also note in our piece on what AI implementation costs;
- checking and correcting a result takes almost as long as today’s work — then little or nothing is left of the saving, while the running costs remain;
- a large share of cases are exceptions — the exception queue eats the saving, and someone also has to handle it day to day;
- the goal is a shorter wait, but the project does not change its cause — if “where it stalled” is dominated by a manager’s approval or documents from the customer, first change the approval rules or how documents are collected;
- rework comes from an unclear process — if two people handle the case differently and both believe they are right, automation will lock that ambiguity in.
A result like that is not a failed measurement. We describe some of these situations on our what we don’t do page and in the part of our implementation methodology about when we say it is not worth it.
The same log in specific processes
The log is general. For several processes we have already written up its variants:
- customer service — five numbers from your own inbox and phone system, with a sample of two hundred tickets from recent months instead of logging as you go;
- phone calls — the arithmetic from the phone system report in our piece on what a voicebot costs (an automated system that handles phone calls);
- sales — time from enquiry to quote, measured for two weeks in a spreadsheet.
What next
With a filled-in log and the arithmetic, a conversation about automation starts from your numbers rather than someone else’s promise. Totals and averages are enough for that conversation; case details and customer data stay with you. How we approach business process automation — one process, a metric measured before the start and a person approving results at first — is set out on the service page.
Sources, as at 13 October 2026
- Jim McCambridge, John Witton, Diana R. Elbourne, “Systematic review of the Hawthorne effect: New concepts are needed to study research participation effects”, Journal of Clinical Epidemiology 67(3), 2014, pp. 267–277 — a review of 19 studies; most reported some evidence of an effect of being aware of being studied on behaviour, but according to the authors little is known about the conditions, mechanism or size of that effect; read on 13 October 2026.
- Ten days, five columns and a hundred template rows are our practical choices, not standards or research findings. The example cases are invented, and the arithmetic rests on numbers you fill in yourselves.