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.

Why resistance to technology change feels rational

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.

A method for pricing the status quo

You can put a number on inertia with three simple calculations. None require a data team, just a spreadsheet and honest time estimates from the people doing the work.

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 to do with the number once you have it

Pricing the status quo isn't 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:

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.