A company can have orders on time, a green dashboard and still be losing money quietly. The symptom is rarely a dramatic failure. It is usually a chain of small frictions: a call to confirm something that was “already done”, an internal email to correct an address, an exception handled from memory instead of by shared rules.
When the dashboard says everything is fine, it is worth asking who is doing the invisible work to make it look that way.
The thesis is simple: many operations do not break because they lack technology, but because the customer’s reality and the company’s internal reality drift apart. The problem is not that exceptions exist. The problem is that each area measures something different, rewards something different, and ends up hiding the cost of shortcuts.
The order that looked fine and still went wrong
Think of a mid-sized company selling physical products with an associated service. The order is entered, prepared, shipped and delivered. In the ERP it looks complete. In the management view there is no incident. Yet customer service keeps getting messages because the customer expected a different installation date, an accessory was missing, or the invoice did not match what was agreed.
This pattern is common. Friction tends to appear in the gaps between departments: sales promises, operations interprets, warehouse packs, logistics delivers and after-sales explains. Each area may be doing its part. The customer, however, experiences the journey as one single service.
What the dashboard hides is the accumulation of micro-decisions. Is an order “delivered” when it leaves the warehouse, or when the customer can actually use it? Does an issue count only if it enters a ticketing system, or also if it is solved through WhatsApp? What work remains invisible because the team has learned that recording it takes longer than fixing it?
The incentives that push people toward workarounds
Most workarounds do not come from bad intent. They come from misaligned incentives.
If sales is judged on closing, it will tend to overpromise. If operations is judged on speed, it will move the order even when details are missing. If customer service is measured on cases closed, it will aim for fast resolution even if the root cause remains.
Here is the uncomfortable tension: companies often reward local progress and punish global friction. They celebrate that the order “keeps moving”, but no one asks how many corrections were needed to keep it moving. They reward visible speed and undervalue coordination work, which is less glamorous but much more expensive when it fails.
A useful signal is not just how many orders leave the building. It is how many require manual intervention across teams. Another is the time between someone spotting an exception and it becoming clear who owns it. If that ownership depends on calls, favours or memory, the process still lives in people rather than in agreements.
A small case: less automation, more clarity
A mid-sized distributor with seasonal pressure noticed a strange pattern. Tickets were not rising because of pure volume, but because of orders that were “almost right”: a missing reference, an incomplete address, or a promised delivery date that never appeared in the internal flow. The team had normalised correcting things by phone before logging the issue.
The first instinct could have been to automate more validation. But the real problem was not only data capture. It was the operating contract.
For two weeks, the team ran a reversible test: they manually flagged every relevant exception in a shared sheet with three simple fields — what was missing, who detected it and who resolved it. No ERP overhaul, no large project. Just visibility into the cost of friction.
The result was not dramatic, but it was useful. Three dominant causes emerged: sales promises made without context, mandatory fields nobody understood and last-minute changes entering through informal channels. With that, the company adjusted one validation rule, reset one sales expectation and removed several repetitive corrections.
The lesson was not “digitise everything”. It was “first understand what the system was hiding”.
The uncomfortable decision: accepting a little slowness
Here is the less popular part. Reducing friction sometimes requires an intentional pause.
That may mean an order should not move until a critical detail is confirmed. It may mean sales cannot promise an exact date without a realistic range. It may even mean the customer gets a slightly slower answer at first. Nobody applauds that slowness on day one.
But there is a difference between slowing the operation down and preventing it from degrading later. The question is not whether something feels smoother today, but whether the flow remains sustainable when volume rises, someone is absent, or an exception falls outside the script.
Mature companies do not remove all friction. They choose which friction is worth keeping to protect the overall experience. That choice almost always has an internal political cost, because it means saying no to habits that have been in place for years.
A reversible experiment before a big programme
If your customer and your team describe different realities, do not start by redesigning the whole architecture. Start with a short test:
- Pick one frequent exception type.
- Track it for two weeks without trying to hide it.
- Measure three things: frequency, resolution time and the exact point where information was lost.
- Check whether the issue sits in a promise, a handoff or a normalised workaround.
- Adjust one rule and see whether friction drops.
That approach does not reject technology. It puts technology in the right place. In many cases, the right solution comes later, once it is clear which decision needs support, which data is missing and which team is absorbing the cost.
If your company is reviewing integrations, processes or automation, at Codefuente we usually start with that uncomfortable question: what friction is the system hiding today so the dashboard looks better than reality?