The Real Cost of We Have Always Done It This Way

·6 min read·Ervandra Halim

Key answer

The real cost of 'we've always done it this way' stays invisible until you measure it: hours lost to manual steps, an error rate that triggers rework, and good staff who quit over drudgery. In my consulting work, one multifinance client's manual payment entry carried roughly a 4% monthly error rate before anyone priced it. Ervandra Halim argues the fix isn't buying software first, it's pricing the status quo with three simple calculations before deciding whether change is worth it.

  • Resistance to technology change is usually a rational response to a status quo cost that has never been priced, not stubbornness or a character flaw.
  • Three calculations, hours lost to manual steps, error rate times rework cost, and turnover cost from drudgery, add up to a real, defensible monthly figure for what the current process costs.
  • Pricing the status quo isn't an argument to buy software immediately, it's an argument for deciding with real numbers instead of a gut feeling and memories of a past failed rollout.

Every business owner I've worked with has said some version of the same sentence at least once: "This is how we've always done it, and it works fine." Resistance to technology change usually isn't stubbornness. It's a rational response to a real cost, the cost of switching, weighed against a cost that never shows up on any invoice, the cost of staying put.

That's the trap. Switching costs are visible: a new system, training time, a few weeks of confusion. The cost of the status quo is invisible because it's already baked into your operating rhythm. Nobody sends you a monthly bill for "manual data entry errors" or "the two hours a day your finance team spends reconciling spreadsheets by hand." But the bill exists. It's just unpaid, accumulating as opportunity cost, and it compounds.

I've sat across the table from owners running seven-figure operations on paper forms and WhatsApp because "the current process works." It works the way a leaking bucket works: you don't notice until you measure how much water actually made it to the other side.

It works the way a leaking bucket works: you don't notice until you measure how much water actually made it to the other side, says Ervandra Halim, CPTO and principal architect.

Why does resistance to technology change feel rational?

Resistance to technology change feels rational because it responds to three recurring patterns in how businesses actually operate, not to stubbornness or fear of learning something new. Nobody resists change for no reason. Three patterns show up again and again:

  • The system isn't visibly broken. Revenue is fine, orders ship, nobody's complaining loudly. Pain that doesn't produce a fire doesn't get budget.
  • Past software failures. Almost every owner I meet has a scar: a system they paid for that never got adopted, or a vendor who disappeared after go-live. That scar tissue makes the next proposal look like the last one.
  • Nobody owns the decision. In many traditional businesses, the person who feels the daily pain (a warehouse supervisor, an admin staffer) has no budget authority, and the person with budget authority never touches the manual process.

None of that means the resistance is wrong to feel. It means the cost of staying put has never been priced, so it can't be compared fairly to the cost of change.

How do you price the status quo?

Pricing the status quo takes three simple calculations, not a data team or expensive software. A spreadsheet and honest time estimates from the people doing the work are enough to put a number on inertia, then adding the three figures together gives a defensible monthly cost for staying put.

1. Hours lost to manual steps. Pick one recurring task, say, manually reconciling daily cash payments against a ledger. Time it for a week. Multiply hours per month by the loaded hourly cost of the staff doing it (salary plus benefits, divided by working hours). A task that eats 3 hours a day at a loaded rate of Rp 60,000/hour is roughly Rp 3.9 million a month, quietly, forever, unless something changes.

2. Error rate times rework cost. Manual processes have an error rate even when your best people do them, because humans are not built for repetitive precision. Estimate how often a manual entry needs correcting (ask the team, they know), then estimate the cost of catching and fixing it: the time spent, the customer friction, the occasional refund or penalty. A multifinance company I advised found roughly 4% of manually entered payment records needed correction each month. At their volume, that translated to real money in late fees and customer complaints, not just inconvenience.

3. Recruiting and turnover cost from drudgery. Manual, repetitive work is the kind of work good people leave over. Every replacement costs recruiting time, onboarding time, and a productivity dip while the new hire ramps up. If you've replaced the same role twice in two years and exit interviews mention "boring," "repetitive," or "too much manual work," that's a technology cost wearing an HR costume.

Add the three together and you have a genuine, defensible monthly figure for what "the way we've always done it" actually costs. In my experience that number is almost always bigger than the quote for the system that would fix it, and bigger than the owner expected.

What should you do with the number once you have it?

The number itself is not an argument for buying software immediately, it's an argument for making the decision with real numbers instead of a gut feeling and a bad memory of the last failed rollout. Once you have the figure, three moves turn it into an actual decision:

Step What it does
Compare monthly inertia cost to solution cost + payback period Turns "is it worth it" into simple math
Pilot with the team that feels the pain most Builds internal advocates instead of top-down mandates
Set a 90-day adoption checkpoint, not a "launch and hope" Catches the failure mode that killed the last system

I've seen this exact pattern play out with a pharmacy chain that let data decide its reorders instead of relying on a manager's memory and gut feel. The resistance before the change was strong. The math, once someone finally did it, wasn't close.

Traditional businesses aren't losing to competitors because they lack ambition. They're losing because digital-first rivals priced their inertia correctly and traditional operators didn't.

The takeaway

Resistance to technology change is a symptom of an unpriced status quo, not a character flaw in your team or in you. Before your next "let's leave it as is" decision, run the three calculations above on just one process. If the number that comes back doesn't change your mind, you've made an informed choice. If it does, you now have the business case you needed, in your own numbers, not a vendor's slide deck.

change resistanceoperationscultureefficiencytraditional business

Frequently asked questions

What if the number I calculate doesn't change my mind?

Then you've made an informed choice, and that's a legitimate outcome of the exercise. Pricing the status quo isn't meant to force a switch, it's meant to replace a gut feeling with a real monthly figure so the decision, whichever way it goes, is deliberate rather than avoidance dressed up as caution.

Why do past software failures make owners resist even good proposals?

Because a failed rollout leaves scar tissue, money spent on a system nobody adopted, or a vendor who vanished after go-live. That scar tissue makes the next proposal look like the last one, even when the new vendor, process, or team involved has nothing to do with the earlier failure.

Who should pilot a new system once the status quo cost justifies changing it?

The team that feels the pain most directly, not a top-down mandate from ownership. Piloting with the people already absorbing the manual work, a warehouse supervisor or reconciliation staffer rather than management, builds internal advocates who can vouch for the change instead of resenting it.

Why set a 90-day adoption checkpoint instead of just launching the new system?

Because launch and hope is the specific failure mode that killed the last system these owners tried. A fixed 90-day checkpoint forces someone to confirm the tool is actually being used and solving the priced problem, rather than assuming adoption happened just because the rollout finished.

Ervandra Halim

Ervandra Halim

CPTO & Principal Architect

Ervandra Halim helps owners and leaders modernize operations and put AI to work daily. He partners with a few businesses at a time, mostly by referral.

Keep reading

Business & Tech

Reading Your P&L Like an Operator

Reading your profit and loss for decisions, not vanity: which lines to watch monthly, and which expense lines automation actually moves.

·8 min read

© 2011–2026 Ervandra Halim