The scene is easy to recognize: an order arrives late, the customer calls, warehouse says it left on time, sales blames transport, and customer service ends up apologizing without being able to explain what happened. At first glance it looks like a software problem. In practice, it is often a coordination problem.
When nobody owns the final call on an exception, the customer pays for the confusion.
The uncomfortable but useful thesis is this: in many SMEs, the worst enemy of service is not a lack of technology, but ambiguity about who decides when operations drift off script. That ambiguity is not fixed by adding more screens. It is fixed by clarifying rules, limits and ownership.
What the customer sees, and what the company thinks is happening
In a small or mid-sized business, an order flow seems straightforward until an exception appears. Stock exists in the system but not on the shelf. A delivery date was promised, but transport misses it. A ticket is open, but nobody knows whether warehouse, sales or after-sales should handle it.
The real problem is not the exception itself. The problem is that each area optimizes its own part and nobody optimizes the end-to-end experience. That creates very familiar symptoms:
- overly optimistic sales promises;
- rework between teams;
- messages asking for confirmation of something that should already be clear;
- customer calls made mainly to “buy time”;
- decisions that depend on one specific person instead of a shared rule.
When that happens, software usually amplifies the confusion already there. If the process is vague, the system makes the vagueness visible; it does not correct it by itself.
A small scenario, but a very real one
Imagine a distribution SME with multiple sales channels. It has internal sales, an online store and recurring orders from business customers. For several weeks, leadership notices the same pattern: volume is up, but so are incidents. Not because there are more technical errors, but because each order touches more people before it closes.
The company decided not to start by buying anything. First it mapped three critical decisions:
- which orders can be promised without manual validation;
- which cases must be blocked until reviewed;
- who can approve an exception and how quickly.
Then it tracked four simple signals:
- orders stopped for lack of a clear rule;
- average time to a useful customer response;
- number of promise changes after the sale;
- repeated incidents for the same reason.
The most important change was not technical, but organizational: they stopped hunting for blame on every case and started recording decisions. That made it possible to see where time was being lost and which exception types were consuming the most resources.
The uncomfortable decision: less apparent flexibility
This is the part many companies struggle to accept. Better service often requires less improvisation, not more. That means saying no to some sales promises, limiting certain urgent warehouse exits, or forcing a review of orders that used to ship because “that is how we have always done it.”
That discipline feels slower at first. Some teams feel they are losing autonomy. Sales fears losing deals. Operations fears control will slow everything down. And in fact, something does slow down: arbitrary decisions.
The benefit appears later, when the company no longer depends on internal heroes to solve daily issues. Fewer improvised exceptions usually lead to:
- fewer avoidable returns;
- fewer follow-up calls;
- less time spent figuring out who did what;
- more predictability for both the customer and the team.
It is not glamorous improvement, but it shows up in cash flow, workload and reputation.
What is worth measuring for real
If leadership wants to know whether the problem sits in the process or the tool, it should look at operational signals rather than opinions. For example:
- percentage of orders requiring manual intervention;
- time between the incident and the first useful action;
- number of promise changes per week;
- recurring blocking causes;
- how often a case is passed from hand to hand.
These measures help distinguish three scenarios:
- the process is badly designed;
- the process is clear, but not followed;
- the process is clear and followed, but the system does not support it well.
That distinction matters because it prevents the wrong investment. More automation is not always the answer. Sometimes the answer is a better rule, a clearer owner, or a less frequent exception.
The lesson for leadership: decide before you digitize more
The best-run companies are not the ones with the most tools, but the ones that know who decides what, with which data and at which moment. If that framework does not exist, any technology improvement eventually runs into the same problem: too many exceptions and too few shared rules.
So before asking which system is missing, ask which decision still has no owner. That question usually reveals more than an application map.
At Codefuente, that is often where we start: at the boundary between process, responsibility and technology support. Because when that boundary is drawn badly, the customer feels it first.