The Most Expensive Sentence in Business: “It Works Well Enough.”

There is a sentence I hear in business that sounds completely reasonable:

“It works well enough.”

And sometimes it does.

The spreadsheet is ugly, but people know how to use it. The supplier needs chasing, but eventually somebody gets an answer. The report takes half a day to prepare, but it arrives. The owner gets involved in too many operational questions, but they know the company better than anyone. The ERP does not quite reflect reality, but Sarah knows which numbers need checking.

Nothing is obviously broken.

So why change it?

That is a perfectly rational question.

After years working in operations and advising business owners, I have learned that people rarely resist change by saying:

“I am afraid of change.”

It sounds much more reasonable.

• “Now isn't the right time.”
• “The team is already busy.”
• “Let's stabilize first.”
• “I don't want to disrupt operations.”
• “We've already invested a lot in this.”
• “I need more proof.”
• “Maybe next quarter.”
• “And honestly, what we have works.”

Any of those statements might be correct.

But they can also hide something more interesting.

The current way of working has one enormous advantage over every alternative:

You already know how to survive its problems.

You know which spreadsheet needs checking twice.

You know which employee has the answer.

You know which supplier needs chasing.

You know the report will be late.

You know the owner will eventually solve the exception.

The problems are familiar.

And familiar problems have an extraordinary ability to feel safer than unfamiliar improvements.

That is where “it works well enough” can become expensive.

Not because change is always good. Not because every company needs more technology. And certainly not because somebody selling AI tells you that your business needs “transformation.”

The better question is:

What is it costing you to keep making the current way work?

The status quo has home-field advantage

Human beings do not evaluate every decision from zero.

What we already have matters.

Economists William Samuelson and Richard Zeckhauser famously described status quo bias: when one option is presented as the existing state, people tend to favour it more than they otherwise would.

Later research has found the same mechanism across business, economics, information systems and technology adoption.

That does not mean staying with what you know is irrational.

Quite the opposite.

Changing systems costs money.

Changing processes consumes management attention.

Employees need to learn something new.

Something may fail.

Customers could be affected.

And the promised return may never appear.

An experienced business owner knows this.

They may already have lived through a software project that took twice as long as promised, a consultant who understood the presentation better than the business, or an internal “transformation” that created more meetings than results.

So when someone says:

“Why take the risk? The current process works.”

I understand the logic.

The problem is that we rarely subject the current process to the same level of scrutiny.

The new solution has to prove itself. The old process gets a free pass.

Propose changing an operational process and the questions begin immediately.

• How much will it cost?
• How long will implementation take?
• What if employees don't use it?
• Will it integrate with our ERP?
• What happens if something breaks?
• Will we need training?
• What is the ROI?
• When will we see results?

Good.

You should ask all of those questions.

Now apply the same interrogation to the current process.

• How much does it cost every year?
• How many employee hours does it consume?
• How often does it create errors?
• How many customer questions does it generate?
• How much management attention does it require?
• How many manual checks are needed to keep it reliable?
• How much margin disappears because problems are discovered too late?
• How much additional headcount will it require as volume grows?

Suddenly the answers become much less precise.

“We've never really calculated that.”

Exactly.

The proposed change arrives with a price tag.

The status quo usually doesn't.

Nobody presents the owner with two quotations:

Option A: Change the process — HK$120,000

Option B: Keep the current process — HK$0

Yet psychologically, that is often how the choice feels.

One requires an active investment.

The other appears to require nothing.

But doing nothing is not free simply because nobody sends you an invoice.

We feel the possible loss before we feel the possible gain

There is another reason changing feels difficult.

The downsides are immediate and easy to imagine.

Implementation goes wrong.

The team complains.

Something gets lost.

Operations slow down.

The money has already been spent.

The potential gains are different.

Three hours recovered every day.

Another year before you need to hire.

Faster reporting.

Fewer mistakes.

Better visibility.

Less owner dependency.

More orders handled by the same team.

Those benefits live in the future.

Behavioural research around loss aversion shows that people do not experience equivalent gains and losses in the same way. Potential losses often feel more significant.

There is also the endowment effect: once something is ours, we tend to value it more.

That translates very easily into business.

The current process is already ours.

We built it.

We selected the ERP.

Someone created the spreadsheet.

The operations manager developed the workaround.

Employees spent years learning how the business really works.

Changing part of that feels like giving up something concrete in exchange for something promised.

So the mind naturally asks:

What could go wrong if we change?

A better decision requires asking the opposite question with equal seriousness:

What keeps going wrong if we don't?

Familiar problems feel safer because we already know the workaround

This is something I see constantly in operating businesses.

The inventory figure cannot always be trusted?

Fine. Ask the warehouse.

Supplier dates are unreliable?

Purchasing knows which suppliers need chasing.

Management reporting takes too long?

Finance knows how to rebuild it.

The ERP does not capture one operational reality?

There is a spreadsheet.

Too many questions come back to the owner?

The owner answers them.

The company develops workarounds around its weaknesses.

And those workarounds can be surprisingly effective.

That is precisely what makes them dangerous.

The business learns how to survive the problem, so eventually the problem stops feeling urgent.

A new operating model contains uncertainty.

The old one contains familiar inconvenience.

When you are responsible for customers, employees, cash and reputation, familiar inconvenience can feel safer.

That is not stupidity.

It is understandable risk management.

But there is an important distinction:

Knowing how to compensate for a problem does not mean the problem is cheap.

“It works” and “it works well” are not the same thing

A process can work because somebody makes it work.

That difference matters.

The weekly report works because one person spends Friday afternoon preparing it.

Supplier tracking works because purchasing constantly follows up.

Stock control works because someone checks the ERP against Excel.

Customer service works because operations gets interrupted to provide answers.

Decision-making works because the owner knows everything.

Nothing has technically failed.

But that does not mean the operating model is good.

It means the organisation has become skilled at compensating for it.

Experienced employees can make weak processes look remarkably strong.

They remember.

They improvise.

They catch errors.

They know the shortcuts.

They know what the system actually means rather than what it says.

That expertise is valuable.

But if management concludes that everything is fine because good people keep rescuing the process, it learns the wrong lesson.

The employee becomes evidence that the process works.

Sometimes the employee is actually the reason it works at all.

We also defend what we already invested in

Another very human sentence is:

“But we've already spent so much on this.”

Maybe you invested heavily in your ERP.

Perhaps your team spent months implementing a process.

Someone built a sophisticated reporting system.

Changing part of it can feel like admitting the original investment was wrong.

This is related to the sunk-cost effect: once we have invested money, effort or time into something, we become more reluctant to walk away from it, even when the past investment should no longer determine the best next decision.

The business version sounds familiar:

• “We've already spent too much on Odoo.”
• “We've worked this way for six years.”
• “We invested heavily in training everyone.”
• “We built this internally.”

But the useful question is not:

How much did we already spend?

That money is gone.

The useful question is:

Given where the business is today, what is the best operating model from here?

Sometimes the answer is to keep exactly what you have.

Replacing a perfectly good ERP because someone discovered a shiny AI platform would be madness.

But keeping a bad workflow solely because you have already invested in it is something else.

Past investment should inform the next decision.

It should not own it.

Different people resist the same change for completely different reasons

This is where behavioural profiling becomes useful.

We often talk about “resistance to change” as though it were one thing.

It isn't.

Present exactly the same operational change to four people and you may hear four completely different questions.

• “Will I still be able to see and control everything?”
• “Show me the numbers. How do we know this will work?”
• “How is the team going to react?”
• “How long will implementation take? I don't want this slowing us down.”

Same project.

Different concern.

One person may be protecting control.

Another is protecting certainty.

Another is protecting relationships and stability.

Another is protecting speed and autonomy.

Call all four people “resistant” and you learn nothing.

A much better question is:

What does this person believe they might lose?

That changes the conversation.

If somebody fears losing control, showing them AI features will not help. Show them how the change gives them better visibility and lets them intervene where their judgment actually matters.

If somebody fears uncertainty, enthusiasm is not enough. Show scope, evidence, milestones and a contained first step.

If they are worried about the team, do not talk about replacing people. Show which frustrating work disappears and where people remain essential.

If they fear disruption, stop selling “transformation.” Show how little has to change at once.

Resistance starts making a lot more sense when you understand what the person is trying to protect.

Sometimes “resistance” is simply good judgment

Technology companies are not always very good at accepting this.

Not every reluctant prospect has a psychological bias.

Sometimes the proposal is bad.

Sometimes the ROI is unclear.

Sometimes implementation genuinely is too disruptive.

Sometimes the organisation does not have the bandwidth.

Sometimes the vendor does not understand the business.

Sometimes the problem is annoying but simply not expensive enough to justify solving.

Research from the OECD on SME digitalisation supports this practical view. In its 2025 work, some of the most commonly reported barriers included maintenance costs, lack of time for training and technology costs. Employee and management resistance ranked much lower.

That matters.

It challenges the convenient story that businesses fail to adopt technology because owners are old-fashioned or employees hate change.

Most owners are asking much more sensible questions:

• How much will this cost?
• Who is going to implement it?
• Who maintains it?
• What happens when something breaks?
• Does it solve something important enough to justify the effort?
• Can we afford to be wrong?

Those are not excuses.

They are business questions.

Calling them “resistance” is lazy.

Small businesses cannot afford expensive experiments as easily as large ones

This point matters especially for SMEs.

A multinational can spend millions on a technology initiative that disappoints.

People get annoyed.

A post-mortem is written.

Life goes on.

A 15-person company makes a bad HK$300,000 decision and the owner feels it.

The cash matters.

The management distraction matters.

There may be no internal IT department to rescue the project.

The same people implementing it may also be trying to run purchasing, finance, sales or operations at the same time.

So SMEs often take a wait-and-see approach.

They want proof.

They want peer examples.

They want to know the solution is relevant to a business like theirs.

Again, rational.

The problem appears when responsible caution no longer has an endpoint.

“I want evidence first” makes sense.

“I will never have enough evidence to accept any uncertainty” creates paralysis.

No meaningful business decision comes with zero uncertainty.

The objective is to reduce risk enough to make a rational decision, not eliminate risk entirely.

Doing nothing does not remove risk

We talk about change as risky as though staying the same were neutral.

It isn't.

Your best operations employee can resign.

Volume can increase 30%.

A customer can demand faster reporting.

Margins can tighten.

A supplier can fail.

Payroll can rise.

A spreadsheet can eventually reach the point where nobody trusts it.

The owner can simply become exhausted.

The current operating model has risks.

We just know them so well that they no longer feel like risks.

They feel like Tuesday.

And this is why the decision can become asymmetric.

A business owner can describe everything that could go wrong during a three-week implementation.

Ask what continuing the current process will cost over the next three years and the answer is often much less concrete.

One side is being evaluated through risk.

The other is being evaluated through habit.

That is not a fair comparison.

Doing nothing is still a decision

The status quo has another psychological advantage.

Doing nothing does not feel active.

You do not sign anything.

You do not approve a budget.

You do not announce a project.

You simply continue.

But economically, you still made a decision.

If manual reporting consumes 30 hours every month, you have decided to buy another 30 hours next month.

If supplier follow-up consumes three hours a day, you have decided to continue paying for that work.

If every exception reaches management, you have decided to continue spending management capacity on those exceptions.

If another administrator is required because the process cannot absorb more volume, you have decided to buy capacity through payroll rather than change the operating model.

That may still be the right decision.

But call it what it is.

Doing nothing is still a business decision. It just happens to be the one nobody asks you to approve.

Once you see it this way, “wait” stops meaning “free.”

“Nice to have” is often a framing problem

This happens constantly with operational technology.

You show an owner:

• A dashboard
• An assistant
• An automated workflow
• Document processing
• An alert

They think:

Nice.

But not essential.

Fair enough.

A dashboard is a feature.

Most businesses can survive without another dashboard.

Now describe the same investment differently.

Three hours of repetitive work removed every day.

Another 30% of order volume before you need another operations hire.

A supplier delay visible while there is still time to act.

The owner receiving five routine questions instead of thirty.

Management reporting available without someone rebuilding it every Friday.

The solution has not changed.

The frame has.

You moved from:

What does the technology do?

to:

What does the business become capable of doing?

That is why an operational solution can look like a nice-to-have at feature level and look completely different when evaluated economically.

A feature can be optional.

A meaningful change in the economics of how the business operates is something else.

Most employees do not want transformation. They want annoying work to disappear.

This is where technology companies often make life unnecessarily difficult.

Your procurement manager probably does not wake up excited about AI orchestration.

They want to stop chasing the same supplier three times.

Customer service wants to answer an order question without involving two other departments.

Finance wants the numbers to reconcile.

Management wants a report it can trust.

The owner wants to stop being involved in everything.

So starting the conversation with:

“We are implementing an AI transformation programme.”

can actually create resistance that did not need to exist.

A much better conversation is:

“You currently spend six hours a week rebuilding this report. We want that work gone.”

Now everyone understands the problem.

Commercial change-management research has repeatedly found that people struggle with changes when they do not understand why the change is necessary, when they fear what it means for their role, or when they feel excluded from the process.

That is hardly surprising.

People do not need a motivational speech about transformation.

They need to understand:

• Why are we changing this?
• What becomes easier?
• What changes for me?
• What stays the same?
• What do I still control?
• What happens when something goes wrong?

That is a much more human way to implement change.

Resistance to change is often resistance to perceived loss

When management introduces a new system, management usually thinks about what is being added.

Better information.

Automation.

Visibility.

Faster reporting.

AI.

The employee may hear something completely different.

• Will I still know how to do my job?
• Will I lose control?
• Will management monitor me more closely?
• Does this make my role less important?
• Will I look incompetent while learning?
• Are they trying to reduce headcount?
• Will something I built disappear?

Management is describing gain.

The employee may be evaluating loss.

That matters.

An employee can even be attached to a bad manual process because they are exceptionally good at operating it.

Their expertise creates status.

People come to them for answers.

Now a better system promises to make some of that knowledge available to everyone.

The business sees resilience.

The individual may experience a subtle loss of importance.

You cannot solve that with another product demonstration.

You have to understand the human change underneath the technical one.

Control is not the same as involvement

This is particularly important with business owners.

Being involved in everything can feel like control.

If you built the company, knowing what is happening matters.

But there are two very different versions of control.

One is:

I am involved in everything.

The other is:

I can see what matters, know when something is wrong and intervene when my judgment is actually required.

The first creates dependence.

The second creates management capacity.

A good operational change should not make the owner feel blind.

It should do the opposite.

The message should never be:

“Don't worry. AI will handle it.”

I wouldn't like that either.

The objective is:

You should not need to chase normal operations. You should see the exceptions that deserve your attention.

That is a much stronger definition of control.

The best change feels smaller than the problem

Another reason people resist operational change is that companies often present it terribly.

The company has a supplier-tracking problem.

Management announces a digital transformation programme.

Reporting is weak.

Somebody proposes replacing half the technology stack.

Customer service cannot see order status.

Suddenly thirty people are invited to workshops.

No wonder everyone gets nervous.

If the pain is specific, start specific.

One workflow.

One measurable problem.

One part of the operation.

Show the result.

Learn.

Then expand.

This matters particularly for SMEs because the company cannot stop running while it “transforms.”

Customers still need answers on Tuesday.

Orders still need shipping.

Invoices still need paying.

So the perceived risk of the change should be smaller than the problem being solved.

Not:

“Trust us. Everything will be better in nine months.”

Instead:

“This is the problem. This is what changes. This is what stays the same. This is how we will know whether it worked.”

That gives people something real to evaluate.

Sometimes “it works well enough” is exactly the right answer

I want to be very clear about this.

Not every inefficient process deserves fixing.

Suppose an employee prepares a spreadsheet once a month.

It takes 25 minutes.

It works reliably.

Nobody else depends on it.

Automating it costs HK$30,000.

Leave the spreadsheet alone.

Seriously.

Make a coffee.

Do the spreadsheet.

Move on.

You do not need AI.

You do not need an integration.

You do not need a transformation workshop.

Technology has a cost too.

Implementation consumes time.

Automation requires maintenance.

Complexity has consequences.

The objective is not to build a technologically perfect company.

Change something when the economics, capacity or risk justify changing it.

Not because change sounds modern.

This distinction matters.

Once people realize you are willing to say “leave this alone”, your recommendation to change something else becomes much more credible.

The real risk is not change. It is bad change.

There is a lazy argument in technology:

“Change is inevitable. Embrace it.”

No.

Bad change is expensive.

Unnecessary change is distracting.

Poor implementation destroys trust.

Technology without a clear operational problem creates complexity.

The objective is not to become comfortable with change for its own sake.

It is to become better at distinguishing between:

change that creates leverage and change that creates more work.

A good operational change should have a clear problem underneath it.

Something costs too much.

Takes too long.

Requires too many people.

Creates too many mistakes.

Limits growth.

Consumes too much management attention.

Or creates unacceptable risk.

Then there should be a believable reason why changing the process improves that outcome.

If neither exists, do not do the project.

Evaluate the result, not how impressive the technology sounds

This is where the conversation comes back to business.

In one STREVIO wholesale operation, what could easily have been described as “supplier visibility and workflow automation” translated into approximately 60% less procurement and supplier tracking work, more than three hours recovered per day and around 35% more orders handled by the same team.

Those outcomes change the conversation.

Likewise, “better coordination and reporting” in a manufacturing operation sounds like a reasonable improvement.

But when it translates into around 70% less manual coordination, 80% faster reporting and approximately 35% more throughput without additional administrative headcount, you are no longer evaluating a piece of software.

You are evaluating what the operating model allows the company to do.

Those are individual case outcomes, not promises that every company will produce the same result.

But they illustrate the point.

The question is not:

“Is this feature worth buying?”

It is:

“If this outcome is achievable here, what is it worth to the business?”

That is a much better decision.

How do you know when the status quo has become too expensive?

Look at what is required to keep it functioning.

Not simply whether the process eventually reaches the correct outcome.

Ask:

• How much manual effort sits underneath it?
• How often does someone need to intervene?
• How many people need to know the workaround?
• How much management attention does it consume?
• What happens when volume increases?
• What happens when the key person is away?
• How often does it create a customer, margin or timing problem?
• What does another year of this realistically cost?

Then compare that with the actual cost and risk of changing.

Now you are comparing two business choices.

Not:

Change versus free.

But:

Change versus continue.

That is the decision that should have been on the table from the beginning.

Stop asking, “Why are they resisting?”

When an owner, manager or employee hesitates, I would avoid starting with:

“How do we overcome their resistance?”

That language already assumes the person is the problem.

Start somewhere else.

What are they trying to protect?

• Control?
• Certainty?
• Cash?
• Time?
• Competence?
• Their team?
• Customer stability?
• A system they spent years building?

Their answer may expose a genuine weakness in the proposed change.

Or it may expose a perceived risk that can be reduced.

Either way, you have learned something useful.

The objective is not to defeat resistance.

It is to understand it well enough that the right decision becomes easier to make.

The most expensive sentence is not always wrong

“It works well enough” can be a perfectly good business conclusion.

If you have examined the process and changing it is not worth the cost, keep it.

The danger lies in using the sentence before doing the economics.

There is a big difference between:

“We've looked at this carefully and changing it is not worth the investment.”

and:

“We've stopped noticing what it costs because everybody knows how to deal with it.”

One is a decision.

The other is habit.

Growing companies cannot confuse the two forever.

Eventually, familiar inefficiencies scale.

The spreadsheet gets bigger.

The questions increase.

The owner becomes busier.

Another employee gets hired.

Then another.

Margins tighten.

Customers expect faster answers.

The process still “works.”

It simply requires more and more effort to keep it working.

That is when the sentence becomes expensive.

Ask a better question

The next time someone says:

“But it works.”

Do not immediately argue.

They may be right.

Ask:

“What does it take to keep it working?”

That question is far more useful.

It forces the business to look beyond the final outcome and examine the effort underneath it.

The time.

The workarounds.

The people.

The management involvement.

The errors.

The hidden cost.

Then ask one more:

“If we were designing this business today, would we choose to work this way?”

Sometimes the answer will still be yes.

Fine.

Keep it.

But if the answer is no, then perhaps the status quo is not safe.

It is simply familiar.

And those are not the same thing.