Where the time goes

An order comes in at the front desk. The employee opens the email, looks up the customer in one system, checks stock in another and retypes the address into a third. In between, a phone call to the back: has that delivery already left? Five minutes, everyone thinks. Do that forty times a day and half a person's time goes to handling that adds nothing.

This is not laziness and it is not bad staff. It is the shape of the work. In most companies the day leaks in three places at once: on searching, on retyping and on waiting. None of the three appears on an invoice, and that is exactly why they stay untouched for years.

Searching is the quietest leak

McKinsey Global Institute measured it back in 2012: knowledge workers spend almost 20% of their working week, roughly one full day, searching for and gathering internal information. That day goes to pulling together what they need in order to work, before the real work begins.

Interaction workers, the people who switch all day between colleagues, customers and suppliers, lose on top of that around 28% of their time on email. One in every four hours goes to keeping an inbox in motion. That leak goes unnoticed, because it appears on no timesheet.

Retyping, and then retyping again

The second leak is a piece of data that passes from hand to hand. An average company used around 106 different SaaS applications in 2024. Each of them keeps its own piece of the truth. A customer name sits in the CRM, is retyped into billing, then into the delivery note, then into accounting. The same piece of data four times, four chances of a typo, four places where it drifts apart.

And the galling part is that this is exactly the work that is easiest to remove. Data-processing tasks have around 69% automation potential with existing technology (McKinsey, 2017). Retyping is not a craft. It is a symptom of systems that do not talk to each other.

Waiting is time too

The third leak appears on no screen: waiting. A file sits ready at the front desk, but accounting will not look at it until tomorrow. Operations waits for approval, finance waits for a receipt, everyone waits for someone. The handling takes two minutes, the lead time three days. That difference is pure waiting time, and it costs margin without anyone working on it.

Rework belongs in the same list. An order entered incorrectly comes back. The correction costs more than the first entry, because now someone also has to work out what went wrong. Every error is expensive on the way back, in time and in trust.

What a process audit measures

A process audit follows one order from start to finish, from the front desk to accounting. What actually happens on an ordinary day, with the exceptions no one writes down. Every step is recorded: who does what, in which system, how long the handling takes and how long the file sits idle before the next person picks it up.

• Actions that add value, and actions that do not
• Moments where a piece of data is retyped instead of passed on
• Handovers between people or departments, with the waiting time in between
• Points where work comes back: errors, exceptions, missing information

What you are left with is a map of the real flow, with the time attached. On that map you see where the day disappears, and usually it is not where management suspected. Only then can you choose a sensible order.

Quick wins and structural fixes

Not every leak deserves the same approach. Some can be closed tomorrow: a form that asks for one field too many, an approval no one reads anymore, an export that can be done with two fewer clicks. Those are the quick wins, and you capture them without a single line of new software.

The structural fixes sit deeper. Two systems that do not talk, a handover that costs a day by definition, a check placed at the wrong point in the chain. Something like that calls not for a trick but for a redesign of the step. In our approach that happens in waves, with a go/no-go per step, so you never build more than what has already proven itself.

Bill Gates wrote it back in 1999: automation of an efficient process increases the efficiency, automation of an inefficient process increases the inefficiency. That is why smoothing out the process comes before the software, and not the other way around. First redesign the flow, then build the modules around it that take over what remains. Reverse that order and you pay to make your mess faster.