Most teams know which tasks they dislike. Few know which ones cost them the most time. The small tasks are the problem: each takes a few minutes, nobody has ever timed them, and together they fill whole days. Before automating anything, it pays to put a number on each of them, in hours per month, measured on your own work rather than on industry averages.
The method below is the one we use at the start of a diagnostic. It needs no software, only a spreadsheet, a few days of honest counting and a sample of real files.
The five criteria
List the recurring tasks of one team, then score each one on five criteria.
- Frequency. How many times the task occurs in a month. Count it from records wherever possible: invoices in the ledger, messages in a folder, files opened in the month. Memory is a poor counter.
- Share of files. Of all those occurrences, the share that actually requires the work. Every file gets checked, but perhaps only four in ten need a missing document chased.
- Time per occurrence. Time ten to twenty real occurrences, from the moment someone opens the file to the moment it is done, including look-ups and interruptions. Keep the median, not the best case.
- Difficulty. Low, medium or high. Low means structured documents, clear rules and few exceptions. High means judgement, many sources or free-form text.
- Goal. Automate, where the system does the work and people handle exceptions, or assist, where the system prepares and a person does the work.
The formula
Occurrences per monthShare of filesMinutesHours per month
The same formula, on the same definitions, measures the task again after go-live.
The formula is deliberately simple. Its value comes from the inputs: counted rather than guessed, and timed on real files rather than described in a meeting. Two cautions. First, count rework: if one file in ten comes back for a correction, the correction is part of the task. Second, keep the definitions stable, because you will measure the same task again later and compare.
A worked example
Take a fictitious accounting firm that lists five recurring tasks in its bookkeeping team. The figures below are invented to show the method; they describe no real firm.
| Task | Per month | Share | Minutes | Hours | Difficulty |
|---|---|---|---|---|---|
| Purchase-invoice entry | 1,400 | 100% | 3 | 70.0 | Low |
| Supporting document per figure | 35 | 100% | 75 | 43.8 | High |
| Bank reconciliation preparation | 90 | 100% | 20 | 30.0 | Medium |
| Monthly client report draft | 40 | 100% | 30 | 20.0 | Medium |
| Missing-document chase | 320 | 45% | 8 | 19.2 | Low |
| Total | 183.0 |
Two lines deserve a closer look. Purchase-invoice entry takes three minutes each time, which nobody would call a problem, yet at 1,400 invoices a month it is the largest item in the table. The missing-document chase happens on only 45% of files, so its 320 files a month become 144 chases, and 19.2 hours.
Ranking: volume among the simplest
A ranked table invites a simple rule: automate the biggest number. That rule fails often, because the biggest number is frequently the hardest task. Here, the supporting documents behind each figure cost 43.8 hours, but the work calls for judgement and draws on many sources. It is a candidate for assistance later, not for a first project.
The rule we apply is different: take the highest volume among the simplest tasks. Filter on low difficulty first, then rank by hours.
Hours per month, by task
In the example, two tasks are rated low: invoice entry at 70 hours and the chase at 19.2. Invoice entry comes first. The chase is a natural second task, because it reuses much of what the first one builds: the same documents, the same client records, the same rules.
Four traps when measuring
The numbers are only as good as the counting. Four mistakes are easy to make.
- Timing the expert. The person who knows the task best is also the fastest. Time several people, including the newest, and keep the median.
- Forgetting the switching. A task that takes three minutes but interrupts other work twenty times a day costs more than its minutes. Note it in the difficulty score, and time the task in real conditions, not in a quiet hour.
- Taking the peak for the norm. Many trades are seasonal. Measure an ordinary month, then note the peak separately: it decides capacity, not value.
- Mixing two tasks in one line. “Handling invoices” hides entry, checking, filing and chasing. Split until each line has one start, one end and one person who does it.
Why one task, end to end
It is tempting to automate a little of everything. We recommend the opposite: one task, taken end to end, on real files, before a second one starts. There are four reasons.
- It proves value on your own files, not on a demonstration. The acceptance criterion is measurable and agreed before work starts, for example the share of invoices entered without correction on a sample.
- It trains the team while the system is being built, on its own documents, so the people who will run it shape it.
- It writes down the company’s context once: clients, codes, rules, exceptions. The second task starts from that base, so it costs less than the first.
- It keeps a person in charge. Each file gets a status, green, orange or red, and staff handle the exceptions. Review and signature stay human.
What to measure after go-live
Measure the same task again, with the same formula and the same definitions, a month after go-live and then every month. The inputs change in telling ways: occurrences stay the same, but the share of files that still needs a person falls, and so do the minutes spent on each exception.
Track a few other signals alongside the hours:
- the share of files that are green on the first pass;
- the time from a document’s arrival to its file being done;
- the errors caught before anything is sent, and the corrections clients still ask for;
- the share of the work that actually goes through the system, rather than around it.
Compare with the baseline measured before the project, never with a promise. If the numbers do not move, the table tells you where to look.
