Your Most Expensive Software Problem Might Be an Employee Doing a Computer's Job

A company tells us they need to hire another operations person. They're growing — orders are up, and the existing team can't keep up. That's a completely reasonable thing to want to fix.

But before signing off on another $60,000 salary, there's a question worth asking first: what is the existing team actually doing all day?

Spend a few hours with the person who actually does the job, and the answer is usually some version of this: download the order. Copy it into a spreadsheet. Enter it into the warehouse system. Copy the tracking number back. Update the CRM. Send the customer an email. Enter the transaction into accounting. Repeat, dozens of times a day, for every order that comes in.

That's not a staffing problem. That's an integration problem.

What that actually costs

Put a number on it, because the number is usually bigger than anyone expects. Say an employee costs the business $70,000 fully loaded — salary, benefits, taxes, overhead. If 30% of their time goes to this kind of repetitive data movement, that's $21,000 a year spent on work a computer does faster and more accurately. Three employees doing some version of the same thing, and it's $63,000 a year — before counting what a tired person gets wrong on the four-hundredth copy-paste of the day.

That changes how an automation project should get evaluated. If a workflow is consuming $40,000 a year in repetitive labor and it costs $15,000 to automate, the question isn't whether $15,000 sounds expensive. The question is whether continuing to spend $40,000 every year makes more financial sense than spending $15,000 once to eliminate most of it. Good automation should have a measurable payback period — and if the numbers don't work, it probably shouldn't be built.

Stop asking what automation costs. Ask what doing nothing costs.

And labor is only the visible cost. A mistyped shipping address, a duplicate order, a missed follow-up, an incorrect invoice, or an inventory adjustment made in one system but not another creates a second cost: someone has to find the mistake, understand what happened, fix it, and sometimes explain it to a customer. The real return on fixing this isn't just labor saved — it's labor saved plus errors prevented plus faster processing plus the capacity to grow without hiring around the problem.

It gets worse with growth, not better. The business grows 30% next year, order volume grows with it, and the honest fix under the current setup is hiring a fourth person to keep moving the same data by hand. The company ends up paying more every year to keep doing the same manual work, just at a slightly larger scale.

There's a name for the alternative: operating leverage — a business where transaction volume can grow without administrative headcount growing at anywhere near the same rate. That's not a technology outcome. It's a business outcome, and it's the thing being sold here, not Node.js, an API, or an AWS bill. The real test of an operational system isn't whether it handles today's volume. It's what you have to hire when today's volume doubles.

We've written about the sibling version of this cost — the labor hiding inside a spreadsheet nobody ever sat down and designed — and the arithmetic is the same shape. The cost doesn't show up as its own line on a P&L, so it never gets fixed on purpose. It just gets staffed around, one hire at a time.

What this looks like in practice

Here's the same order, moving through the business two different ways.

The goal isn't to automate the employee out of the business. It's to automate the computer work out of the employee's job.

That's also the point behind workflow automation for service businesses: the goal was never to remove the person from the loop. It's to remove the parts of their day that were never actually a judgment call to begin with.

Where AI actually fits into this

Not every step here is a good fit for AI, and it's worth being honest about which is which, because getting this backwards wastes money in a different direction. If a document arrives unstructured — a PDF invoice from a vendor, a supply update buried in the body of an email, an inventory spreadsheet formatted slightly differently every time it shows up — that's a real AI problem: pulling a defined shape out of something that doesn't reliably have one. If a customer message needs to be routed by intent, or a step genuinely requires judgment about an ambiguous case, AI earns its place there too.

But "an order was created, so send it to the warehouse" isn't one of those problems. It's deterministic: the same input should produce the same output, every time, and there's already a clean, unambiguous rule for what should happen. Routing that through an AI model doesn't make it more reliable — it makes a plain integration slower, more expensive to run, and occasionally wrong in a new and more interesting way than a spreadsheet ever was.

The best automation isn't the one with the most AI in it. It's the one that removes the most friction with the least new risk.

Not everything that can be automated should be

Automation makes the most sense when the work is repetitive, the rules are reasonably clear, the volume is meaningful, and mistakes or delays have a measurable cost. It makes a lot less sense when a process changes constantly, happens twice a month, depends heavily on human judgment, or costs more to automate than it does to simply perform.

A $20,000 integration that eliminates $2,000 of annual work isn't automation. It's an expensive hobby. The goal isn't maximum automation. It's maximum return from the right automation — which is exactly why the payback math earlier in this piece matters more than the technology choice does.

The 30-minute automation audit

You don't need a consultant to find the first opportunity. Pick one employee, one process, and sit with them for half an hour:

That question about disappearing for a week is worth sitting with on its own — it uncovers a different class of automation opportunity than the others: institutional knowledge that only exists in one person's head, which is its own kind of risk regardless of how much automation the process needs.

Then ask the question that actually matters: if sales doubled tomorrow, which administrative role would you need to hire first? Whatever answer comes to mind first is probably where you should start looking. The team already knows where the friction is worst — that's what the answer to that question actually is.

Where this leaves you

None of this argues against ever hiring again. Some work is genuinely someone's job, and no integration replaces judgment, a relationship with a client, or someone noticing a problem nobody thought to build a rule for. It argues against hiring for the parts that were never actually that kind of work — and paying that salary again next year, and the year after, as the business grows into needing more of it.

Before the next hire goes to a job that's mostly moving data from one system to another, show us the workflow. You don't need a software specification. Show us what happens from the moment an order, email, referral, request, or invoice arrives until the work is finished. We'll identify where people are doing work your existing systems could be doing for them — and whether fixing it actually makes financial sense.