Every small business we work with has one process that costs far more than anyone realises. It is rarely the one people complain about. The loud problems get fixed because they are loud. The expensive ones are quiet: a step so normal that nobody has questioned it in four years.
The distributor in the composite above thought their bottleneck was invoicing. Their team said so in the kickoff, twice. When we timed the actual work, invoicing took eleven minutes a day. Checking stock availability — a step nobody mentioned, because it had always been done that way — took three and a half hours a week.
Time one real thing, end to end
Do not survey the team. Ask someone how long a task takes and they will give you the number they wish it took, or the number from the one time it went smoothly. Instead, pick a single real unit of work — one order, one ticket, one invoice — and follow it from the first email to the final payment with a stopwatch.
Write down every moment a person touches it, including the ones that feel like nothing: opening a second tab, waiting for a page, checking a spreadsheet to confirm what the first screen already said. Those thirty-second steps are where the hours live.
You do not need a month of discovery. Following four or five real units of work through the system surfaces the same pattern every time, and it costs the business almost nothing to let you watch.
The three questions
Once you have the timings, three questions separate the work worth automating from the work that merely feels tedious.
Moving information between systems is the clearest automation candidate there is. Creating it — a judgement, a negotiation, a decision about a difficult customer — is not.
If ninety-five percent of cases follow one path, automate that path and route the rest to a person. Chasing the last five percent is where automation projects go to die.
If the answer is “someone notices eventually”, you have found a second problem worth more than the first. Automation makes failure silent unless you design for it.
Design the fallback first
The temptation is to build the path that works and add error handling later. Do it the other way round. Decide what happens to the awkward five percent before you write a line of the happy path, because that decision shapes everything else: what gets logged, who gets notified, how much context travels with the exception.
Two people used to spend their mornings re-typing orders between systems. That job stops existing, and nothing gets missed.
In the distributor's case the fallback was simple: anything the workflow could not price with confidence went to a named person, with the original email attached and a one-line explanation of what it could not decide. Six orders out of two hundred and fourteen took that path last week. The other two hundred and eight nobody touched.
What to do this week
Pick the process that generates the most inbound questions from customers or colleagues — that is usually a proxy for where information is stuck. Follow one real case through it with a stopwatch. Write down every touch. Then ask the three questions above of each step.
You will almost certainly find something that costs a day a week and takes a fortnight to fix. That ratio is why this exercise is worth two half-days of somebody's attention.
