Most growing companies do not decide to run on manual work. It accumulates quietly. A process that worked for a team of ten is stretched to fit a team of forty, and the gaps are filled by people: someone copies figures from one system into another, someone chases approvals by email, someone keeps a spreadsheet that has become the real source of truth for a part of the business.
None of this looks like a problem on any single day. Each task takes a few minutes, and the people doing it are usually competent and conscientious. The cost only becomes visible when you add it up across a month, or when the one person who understands the spreadsheet goes on holiday. This article looks at where that work tends to hide, why it is so easy to miss, and how to start making it visible.
Why manual work is hard to see
Manual work hides because it is spread thinly across roles that have other responsibilities. A finance analyst does not think of themselves as a “data transfer clerk,” even if they spend six hours a week moving numbers between the ERP and a reporting template. A support team lead does not record the time spent re-assigning tickets that landed in the wrong queue. The work is real, but it is absorbed into job descriptions rather than recorded as a process.
It also hides because it is often invisible to the systems themselves. When an invoice waits in someone’s inbox for four days before it reaches the right approver, the accounting system only records the moment it was finally entered. The waiting, the forwarding and the follow-up emails leave no trace in any report. From the system’s point of view, the process took seconds.
Finally, manual work is protected by habit. People who have built a workaround are understandably reluctant to question it, because it works and because they are the ones who made it work. The workaround becomes part of how the team operates, and new joiners learn it as “the process.”
The common hiding places
While every company is different, the same patterns show up again and again once you start looking. Most manual effort sits in the spaces between systems and between teams, rather than inside any one tool.
- Shared inboxes that act as work queues, where requests are read, forwarded and tracked by memory rather than by status.
- Spreadsheets that reconcile data from two or more systems, updated by hand every week or every month.
- Approval chains run over email or chat, where the only record of a decision is a reply that says “ok.”
- Re-keying of the same information into several systems, such as a new employee’s details entered separately into HR, payroll, IT and facilities tools.
- Status chasing, where people spend time asking where something is because no system can tell them.
- Report preparation, where someone exports data, cleans it, pastes it into a template and adjusts formatting before every management meeting.
Each of these has a legitimate origin. Shared inboxes are easy to set up. Spreadsheets are flexible. Email approvals require no new software. The issue is not that these tools were chosen, but that they were never replaced once volume grew beyond what they could reasonably handle.
Signals that a process has outgrown its design
There are some reliable signs that manual work has become a structural cost rather than an occasional inconvenience. They tend to show up in conversations before they show up in data.
One is the phrase “only one person knows how to do that.” When a monthly reconciliation or a customer onboarding step depends on a single individual’s knowledge, the process is being held together by that person rather than by its design. Another is repeated rework: a support ticket that is re-assigned three times before it reaches someone who can resolve it, or a purchase order that is sent back twice because a required field was missing.
A third signal is a growing gap between when work is done and when it is recorded. If month-end figures are only reliable a week after month-end, or if the CRM is updated in a batch every Friday afternoon, the systems are no longer reflecting the business in real time. People compensate by asking each other, which creates more manual work.
The most expensive manual work is rarely a single large task. It is dozens of small ones that no one owns and no system records.
Estimating the cost without a large study
You do not need a months-long analysis to understand the scale of the problem. A rough estimate is usually enough to decide whether a process deserves attention. Start by choosing one workflow and asking the people who run it three questions: how often does this happen, how long does each instance take, and how often does something go wrong.
As an illustration, suppose a team processes 400 supplier invoices a month and each one takes about eight minutes to check, code and route for approval. That is over 50 hours a month, before counting the time spent chasing approvers or correcting mistakes. If one invoice in ten needs a follow-up conversation, add another few hours. The numbers in your own organization will differ, but the method of multiplying frequency by effort, then adding rework, gives a defensible starting point.
It is also worth estimating the cost that is not measured in hours. Delays have consequences: late payments can strain supplier relationships, slow onboarding delays a new hire’s first productive week, and a report that arrives late means decisions are made on older information. These effects are harder to quantify, but they are often what matters most to leadership.
Making the work visible
The first practical step is simply to write down what actually happens, as opposed to what the process documentation says should happen. This is best done with the people who do the work, walking through a recent real example from start to finish. Where did the request arrive? Who looked at it first? What did they need to check, and where did they find that information? Who did they hand it to, and how?
This kind of walkthrough usually reveals steps that nobody had listed: a quick check in a second system, a message to a colleague to confirm a detail, a manual correction to a field that is always imported incorrectly. These small steps are where the time goes, and they are also where errors enter.
- Follow one real case end to end rather than describing the process in general terms.
- Note every system touched, every handoff and every point where someone waits.
- Record the workarounds without judgment. They exist for a reason.
- Mark which steps require judgment and which are purely mechanical.
That last distinction is important. Not all manual work should be automated. Some steps require context, discretion or a relationship with a customer. The aim is to separate the mechanical steps, which are good candidates for automation, from the judgment steps, which people should keep and ideally have more time for.
Where to start
Pick one process that is frequent, involves at least two teams or systems, and generates regular complaints or follow-up questions. Walk through a handful of recent examples with the people involved. Estimate volume, time per case and error rate, even roughly. Then list the mechanical steps separately from the judgment steps.
By the end of that exercise you will have a clear picture of one piece of hidden work, a rough sense of what it costs, and a shortlist of steps that could be handled differently. That is a far better foundation for improvement than a general sense that “we should automate more.” It is also the kind of starting point we use at Metric Minds when we look at a new process: specific, grounded in real cases, and honest about what should stay with people.