Most companies know that some of their work is manual and slow. Fewer can say how much it costs per week, and that is the number you need before you decide what to automate. Without it, the loudest complaint wins, or the process that happens to be easiest to demo.
This article describes a method that one operations lead can run in five working days with a spreadsheet and the people who already do the work. It is deliberately simple. If you want the wider argument about why manual work costs more than it looks, our article on the true cost of manual processes covers it. Here we focus on the practical part: what to count, how to calculate it and how to choose.
Before you start: pick three to five processes
Do not try to measure the whole company. Ask your team leads which recurring tasks they dislike most or which ones cause delays elsewhere, and write down three to five. Good candidates have three properties: they happen at least several times a week, they follow mostly the same steps, and they leave a trace such as an email, a ticket or a file you can count afterwards.
Avoid one-off projects and creative work in this round. They are hard to measure in a week and rarely the right first automation anyway.
Name one person per process who will keep the tally. It should be someone who does the work, not a manager who estimates it. People are quick at this: a tally sheet that takes ten seconds per run is accepted, one that takes two minutes is not.
What to measure: four numbers per process
For every process, collect the same four numbers over the week.
1. Runs. How many times the task was done. Count from the system where you can (tickets closed, invoices posted, emails sent) and from a tally mark where you cannot.
2. Active minutes per run. The time someone is actually working on it, not the calendar time from start to finish. Ask people to note the minutes for each run in the tally, or for high-volume tasks for every fifth run. Round to the nearest minute; precision beyond that is false comfort.
3. Errors and fix time. How many runs contained a mistake that someone had to correct later, and how many minutes the correction took, including the time of the person who found it and the person who fixed it. Count only errors that were noticed. The real number is probably higher, so treat it as a lower bound.
4. Waiting time. How long the work sat idle because it needed a person, an approval or a reply. This is not salary cost in the same way, but it is real: a customer waits, a payment is late, a colleague is blocked. Record the average and the longest wait, in hours.
Add one free-text column, "what annoyed you", filled in by the person doing the work. It costs nothing and often shows the step that is worth automating inside a process, which is not always the one you expected.
The calculation
For each process, the weekly cost in hours is:
runs x active minutes per run / 60 + errors x fix minutes / 60
Multiply the hours by a loaded hourly rate. Loaded means the salary plus employer costs, not the net pay. Ask finance for one agreed number for the team; do not argue about it process by process. Use the same rate for all processes so that the ranking is not distorted by it.
Keep waiting time out of this formula and show it in its own column. If you add it, you start mixing salary and delay, and the total becomes impossible to defend in a meeting.
A worked example
The numbers below are invented for illustration, to show the arithmetic. Yours will differ. We assume a loaded rate of 40 currency units per hour.
| Process | Runs/week | Min/run | Errors | Fix min | Hours/week | Cost/week |
|---|---|---|---|---|---|---|
| Invoice data entry | 120 | 6 | 9 | 20 | 12 + 3 = 15 | 600 |
| Customer status emails | 200 | 3 | 4 | 15 | 10 + 1 = 11 | 440 |
| Weekly management report | 1 | 180 | 1 | 60 | 3 + 1 = 4 | 160 |
For invoice entry: 120 x 6 = 720 minutes, which is 12 hours; 9 errors x 20 minutes = 180 minutes, which is 3 hours; together 15 hours, or 600 units at 40 per hour. Over a working year of about 46 weeks that is roughly 690 hours or 27,600 units. That is the ceiling on what automation could save, not a forecast of what it will save, because no automation removes all of the work.
From cost to ranking
The biggest number is a starting point, not the answer. Before you pick, score each process against four further questions. Use a simple high, medium or low.
- Repeatability. Are the steps the same nearly every time? A process with ten exceptions per hundred runs is a good candidate. One with forty is not yet. If you are unsure, our guide to describing a process before building an agent shows how to write down steps, exceptions, owner and data.
- Clear rules. Can a new colleague do it from a written checklist? If the answer is "it depends, ask Jana", the rules are in someone's head and need to be written down first.
- Cost of a mistake. What happens if the automation gets one wrong? A wrong status email is awkward; a wrong payment is expensive. High cost of error does not rule a process out, but it means a person approves the result at the start.
- Reversibility. Can you undo the result? Processes where you can are safer first projects. We discuss this in more detail in choosing a first AI agent process by risk, value and reversibility.
In the example above, invoice entry has the highest cost, but it touches money, so it needs an approval step. Customer status emails cost slightly less, are repetitive, have clear rules and are easy to reverse because a draft can be reviewed before sending. Many teams would start there, take the lessons, and move to invoices second. The weekly report is cheap in hours, but if waiting time shows that management always receives it a day late, it may still be worth a small fix.
That is the point of keeping the columns apart: the ranking is a conversation, and each column gives you something specific to say in it.
Do you need an AI agent at all?
Not every costly process needs an agent. If the steps are fixed and the data is structured, a plain workflow or a script may do the same job with less risk and cost. Look at your top process and ask whether a rule-based tool could handle at least 80 percent of the runs. If so, start there. Our article on when a simple workflow is enough offers a short test. Reserve an agent for work where the input is messy, such as free-text emails, mixed documents or requests that need interpretation.
Common mistakes in the week
- Measuring only the average. One run takes 3 minutes, another takes 25. Note the range; the long runs are usually the exceptions that decide whether automation works.
- Letting managers estimate. Estimates tend to be round numbers and miss the interruptions. Ask the people who do the work.
- Counting a bad week. If the week included a holiday, a migration or a month-end peak, say so in the sheet and repeat one process in a normal week.
- Forgetting handover time. Work that moves between two people often loses the most time in the gap. This is what the waiting column is for.
- Skipping the baseline. If you do not record where you started, you cannot show later what changed. Save the sheet with the date.
What to do with the result
At the end of the week you should have a one-page summary: the table, the waiting times, your scoring and a recommendation for one process with a short reason. Keep it that short. Then do three things.
- Choose one process and write down the outcome you expect, in hours and in errors, so that success can be judged later.
- Name an owner who is responsible for the process and for deciding whether the automation is good enough.
- Plan the review. After the first month, repeat the same tally for one week and compare. The article on measuring AI agent value with a baseline, rework and review cost explains what else to include, for example the time people spend checking the automation's output, which is easy to forget.
If you would rather not do the measuring yourselves, an AI audit follows a similar logic but with outside help for the analysis.
The week of tallies will not give you a perfect model of your business. It will give you a number for each process, a reason for the order, and a baseline. That is more than most automation projects start with, and it makes the decision easier to explain to the people who pay for it and to the people who do the work.
