Every company we've worked with has somewhere between five and fifteen hours a week disappearing into work that nobody chose and nobody enjoys. Retyping. Chasing. Reconciling two systems that disagree. Producing a report three people skim.
The hard part isn't fixing it. The hard part is finding it — because this work is invisible from the top. It doesn't appear in any system, nobody complains about it, and if you ask people what takes their time they'll describe their job, not the friction around it.
So here's the whole method, written out. It takes an afternoon, it needs no tools, and you don't need us to run it. If you do it honestly you'll finish with a ranked list of what's actually costing you, and — more usefully — a clear view of which items shouldn't be automated at all.
Step 1: Ask the right question (30 minutes)
Don't ask "what takes up your time?" You'll get job descriptions.
Ask these instead, to four or five people who do the actual work:
- "What did you do this week that a competent stranger could have done with a checklist?"
- "What do you type into one system that already exists in another?"
- "What are you waiting on right now?" — waiting is where the real losses live, and it never shows up in a time survey.
- "What do you do at the end of every month that you dread?"
- "What breaks often enough that you've got a workaround for it?" — a well-worn workaround is a fossilised process failure.
- "If you were off sick for a week, what would silently not happen?"
Write answers down verbatim. Don't summarise, and don't let anyone jump to solutions yet — the moment someone says "we should just get a tool for that" the diagnostic ends and the shopping begins.
Step 2: Put a number on each item (45 minutes)
For everything on the list, get three figures. Rough is fine — you're ranking, not budgeting.
- Minutes per instance. Ask the person who does it, then add 25%. People systematically underestimate routine work because they don't count the context-switch either side.
- Instances per month.
- People involved. A task that touches three people costs more than three times as much, because handoffs add waiting.
Multiply out to hours per month. Then add a fourth column that matters more than the arithmetic:
- What happens when it goes wrong? Nothing / mild embarrassment / a customer notices / money moves incorrectly.
That last column is what separates a good automation candidate from a dangerous one, and it's the column everybody skips.
Step 3: Sort into four boxes
Draw the classic two-by-two: volume on one axis, judgement required on the other.
High volume, low judgement — automate. This is the whole prize. Copying data between systems, generating the same report, routing incoming requests, chasing missing documents. It's boring work that computers have been good at for thirty years, and most of it doesn't need AI at all.
High volume, high judgement — assist, don't automate. Drafting responses, reviewing documents, triaging tickets. The right target here is removing the blank page and the sorting, then leaving the decision with a person. Aiming for full automation in this box is how projects fail badly.
Low volume, low judgement — leave it alone. Automating a twenty-minute monthly task takes three days and saves four hours a year. It feels productive and it isn't. This box is where enthusiasm goes to die.
Low volume, high judgement — this is the actual job. Don't touch it. If someone proposes automating this box, that's a signal they're selling hours rather than solving a problem.
Step 4: Ask what the process is really for
Before automating anything in the top-left box, ask one question about each item: why does this exist?
An uncomfortable share of routine work traces back to a system limitation from six years ago, a report someone requested once who has since left, or a control that was added after a specific incident that can no longer happen.
This is the highest-return five minutes in the whole exercise, because the fastest process is the one you delete. And automating a pointless step is worse than leaving it — you've now encoded it, and it will outlive everyone who remembers it was optional.
A blunt test: if this task simply stopped happening for a month, who would notice, and what would they miss?
Step 5: Design for the failure case before you build
For whatever survives to the top of your list, answer these before anyone writes a line of anything:
- When it goes wrong, who finds out and how? Silent failure is the only truly expensive kind. A process that breaks loudly on Tuesday costs an hour; one that quietly writes wrong data into your system of record for six weeks costs a great deal more.
- What's the accuracy you actually need? Sorting inbound email at 90% is excellent. Posting invoice values at 90% is a disaster. The same number means opposite things in different processes.
- Where does a human check the output? If the answer is nowhere, you've built something you'll stop trusting the first time it surprises you.
- How will you know in six months that it's still working? Have a handful of known cases with known correct answers, and re-run them whenever anything changes. This is the boring difference between something that lasts and something that quietly drifts.
A worked example
A real shape we see constantly, with the numbers filled in:
Supplier invoices arrive by email as PDFs. Someone opens each one, retypes six fields into the accounting system, saves the PDF to a shared drive, and forwards it for approval.
6 minutes each (say 8, honestly) × 180 a month = 24 hours a month. Two people involved. Failure mode: a wrong number reaches accounting — which is money moves incorrectly, the worst category.
Box: high volume, low judgement. Strong candidate.
Why does it exist? Because the accounting system has no import. That's a real constraint, not a legacy one — so it stays.
Failure design: extract the fields automatically, but anything where confidence is low, or the total doesn't match the line items, goes to a human queue instead of straight through. Target isn't 100% automation — it's turning 24 hours of typing into 3 hours of checking.
That last line is the one worth internalising. The goal is almost never full automation. It's moving a person from producing the work to reviewing it, which is usually an 80% reduction and carries a fraction of the risk.
What to do with your list
Pick one item. Not the biggest — the one with the clearest failure mode and the least political weight. Fix it end to end, including the part where people are told it exists and the old way is switched off.
That last part is where most of these projects actually die: the automation works fine and everyone carries on doing it manually because nobody owned the change. A working system that nobody adopted is worth exactly zero, and no amount of engineering fixes it.
Then run the audit again in six months. The list regenerates — that's not a failure, it's what a growing company does.
If you run this and want a second opinion on what you found, we're happy to look. But the audit is the valuable part, and it's yours.