The Real Cost of a Manual Process: How to Measure It Before You Automate

The figure that never hits the balance sheet

The cost of a manual process has no accounting line. There is no ledger account called "hours the team spent copying data from one system into another": that cost is spread inside salaries you already pay, which is why it behaves as if it were free. It isn't. It is merely invisible.

That invisibility explains two opposite and equally expensive mistakes. The first: never automating, because the process "costs nothing". The second: automating out of enthusiasm, on a number invented in a meeting that nobody can defend afterwards.

The way out is measurement. And measuring a manual process honestly is simpler than it looks, if you start by deciding what must not enter the calculation.

What doesn't count: the sunk-salary fallacy

The most frequent error when justifying an automation is this: "this task is done by a person who earns X a month and spends half their time on it, so automating it saves half a salary a month."

It is almost never true, for a simple reason: that salary keeps being paid. Unless the automation comes with an explicit decision to reduce headcount — which is rarely the intent and almost never the best idea — next month's payroll will be identical. The saving that calculation promised shows up in no income statement, and when management goes looking for it and can't find it, the project gets marked as a failure even though it worked perfectly.

What does change, and what you should be measuring, are three concrete things:

• Freed capacity. The hours that person now spends on work that genuinely requires judgment: serving customers, reviewing exceptions, closing sales. The value lives in what gets done with the recovered hours, not in the hours themselves.
• Work that doesn't get done today. The follow-up that slips, the reconciliation that gets postponed, the report that arrives late. Automation here doesn't save: it executes something that today simply doesn't happen.
• Errors avoided. A real, measurable cost with an identifiable victim — unlike the sunk salary.

McKinsey Global Institute documented it in "A future that works": a significant share of work activities is automatable with already-demonstrated technology, and automation transforms activities within jobs rather than eliminating whole jobs. That qualitative conclusion is exactly why the correct calculation is one of freed capacity and not of reduced payroll.

The formula

With the ground cleared, the cost of a manual process is measured with four terms:

Frequency × handling time × people involved, plus the cost of rework.

Each term has its own trap.

Frequency

How many times the process occurs in a comparable unit of time — monthly is the most practical. The trap is counting the big event and forgetting the small ones: if reconciliation "happens once a month" but during that month someone checks partial payments twelve times, the real frequency is thirteen, not one.

Handling time

How long one case takes, start to finish. Two classic errors live here. The first is estimating in a meeting: ask someone how long a task they do every day takes and their answer will be optimistic systematically — not out of bad faith, but because memory compresses the repetitive. The second is timing only the visible part: handling time includes opening the systems, hunting for the value, waiting for it to load, fixing a field that didn't reconcile, and going back.

The honest way to get it: have the person who runs the process record the real time of ten consecutive cases, in their normal week, with nothing prepared. Ten cases are enough to see the spread, which is usually more informative than the average.

People involved

How many hands touch one case. This is the most underestimated term, because every hand-off adds time that appears on nobody's stopwatch: the email asking for the missing value, the wait until the other area replies, the context that gets explained again. If a case passes through three people, measure all three — and record the waiting time between them separately, because it is often larger than the work itself.

Rework

The term that is almost always missing and the one that changes the result the most. It is made of two numbers: what proportion of cases comes out wrong, and what it costs to fix one.

Fixing almost never costs the same as doing it right the first time: it costs more, because it includes detecting the error, tracing its origin, undoing what already propagated into other systems and, frequently, an uncomfortable call with a customer or a supplier. When you measure this, ask about the last real error in that process and reconstruct what it actually cost. One concrete case is worth more than an invented percentage.

An example with numbers you must replace

The numbers below are placeholders: they exist to show the shape of the calculation, not to describe your company or anyone else's. Replace each one with yours.

Take a supplier-invoice capture process:

• Frequency: 120 invoices a month — replace with your actual count from last month.
• Handling time: 6 minutes per invoice, measured over ten consecutive cases — replace with your measurement.
• People involved: 2 (whoever captures and whoever validates), with 3 minutes of average wait between them — replace with your real flow.
• Rework: 8 of every 100 invoices need correction, at 20 minutes each — replace with your last quarter.

With those placeholders: 120 × (6 + 3 + the second person's time) gives the monthly capture hours, and 120 × 0.08 × 20 minutes gives the monthly correction hours. Their sum is the number you take into the decision.

That number is yours and it does not generalize. There is no typical saving, no industry average and no standard payback period: anyone offering you one is describing their sales material, not your operation.

How to compare against a fixed price

With monthly hours in hand, the comparison against a fixed-price project is direct arithmetic: multiply the monthly hours by the loaded hourly cost of the people involved — salary plus employer burden, divided by working hours — and compare it against the project price. The quotient tells you in how many months the project pays for itself out of freed capacity.

Three honesty checks to apply to that quotient:

Automation has an operating cost. Someone approves at the gate, someone handles the exceptions the workflow doesn't resolve, someone maintains the system when a supplier changes a format. That residual cost is small against the manual process, but it is not zero, and subtracting it before comparing prevents later disappointment.

Not every case gets automated. It is normal for a workflow to cover most cases and leave exceptions to a person. Run the calculation on the portion that actually gets automated, not on the total.

The value of what doesn't get done today doesn't belong in the division. The follow-up you recover, the report that starts arriving on time, the reconciliation that stops being postponed: that is not saved hours, it is new capacity. Count it separately, in its own language, and don't mix it into the return.

Our custom automation works on a fixed written scope, USD $1,300 to $2,900 depending on the process — a written-quote range, not a list price: the scope document fixes the price and the date. That number is the denominator of your comparison, and it is fixed before we start precisely so the comparison can be made.

In what order to automate when there are several candidates

There is almost always more than one process hurting. Rank them on three axes, in this order:

1. Recoverable hours per month — the result of the calculation above. Rule out from the start anything that runs a few times a year: without repetition there is no return, however automatable it may be.

2. Clarity of the rules. If the answer to "what happens when it arrives incomplete?" is "it depends", that process isn't ready — not because of a technical limit, but because nobody has decided the rule. Automating ambiguous exceptions doesn't remove chaos: it accelerates it.

3. Consequence of error. Not as a veto, but as design: high-consequence processes get automated too, with the preparation fully automated and per-action approval at the moment of effect.

And a fourth criterion, rarely written down, that usually breaks the tie: which one teaches your team to operate automation. The first project has a by-product as valuable as the workflow itself — a team that already knows how to approve at a gate, read an audit trail and use a stop button. With that learned, the second process is chosen better and delivered faster. Which is why the first one should be bounded and clear, even if it isn't the highest-volume one.

The next step costs 3 minutes

If you still don't know which process tops your list, start with the free assessment: 3 minutes, a maturity score, and recommendations prioritized by impact — no card, no mandatory call.

Take the free assessment →

And once you have your number, the full offer — fixed written scope, approval gates, audit trail, stop button and documented rollback — is at simiriki.com/automatizacion.

---

Sources cited in this article:

• McKinsey Global Institute, "A future that works: Automation, employment, and productivity" (2017) — a significant share of work activities is automatable with currently demonstrated technologies; automation transforms activities within jobs
• Every number in the example is an illustrative placeholder to be replaced with your own measurements — not an industry average and not data from any company
• Price ranges and timelines match the current offer at /automatizacion and are written-quote ranges