The Process That Works Perfectly Until Someone Asks a Question
Your sales process has twelve steps. They're documented. Your team follows them. The CRM tracks each stage. On paper, it's bulletproof.
Then a customer asks: "Can I pay in three instalments instead of two?"
Silence. The process doesn't cover this. Your sales rep doesn't know who to ask. They promise to "check and get back" — which means emailing someone, waiting, chasing, and eventually giving an answer three days later when the customer has already moved on.
This is the illusion of a working system. It functions perfectly within its narrow boundaries. The moment reality introduces a variable, it collapses.
The Difference Between Complete and Robust
A complete process covers the steps. A robust process handles the exceptions.
These are not the same thing, but they look identical on a flowchart.
You can document every stage of order fulfilment, from receipt to dispatch. You can create checklists, assign responsibilities, build dashboards. It will all look professional and thorough.
But what happens when:
- A supplier sends the wrong item and the customer needs it tomorrow?
- A payment fails halfway through a subscription?
- Someone wants to return something that's technically outside policy but clearly reasonable?
If your team's only option is to escalate to you, your process isn't complete. It's decorated.
The Escalation Dependency
Here's the pattern that reveals a fragile system: count how many times per week someone asks you a question that your process should answer.
"Quick one — can we offer this customer 10% off?"
"Just checking — do we refund delivery costs in this situation?"
"Not sure what to do here — the system won't let me process this order."
Each of these feels minor. Each takes only a few minutes of your time. But collectively, they expose the truth: your process works right up until it doesn't, and then it needs you.
That's not a system. That's a dependency wearing a system's clothes.
Why This Happens
Processes get built during calm periods. Someone sits down, maps out the ideal flow, documents the happy path. It makes sense. It's logical. It accounts for how things should work.
Reality doesn't follow the happy path.
Customers ask awkward questions. Suppliers make mistakes. Staff interpret instructions differently. Edge cases aren't edges — they're a constant stream of minor deviations that your documentation never anticipated.
The process wasn't wrong when it was written. It was incomplete. And because it looked finished, nobody thought to stress-test it.
A Real Example
A service company we worked with had a client onboarding process they were genuinely proud of. Automated emails. Templated contracts. A client portal with everything neatly organised.
But their account managers still spent hours every week answering basic questions that the portal should have resolved. "Where do I upload this?" "When does billing start?" "Who do I contact about X?"
The process looked complete. The documentation existed. But it assumed clients would read everything, understand everything, and never need clarification.
When we mapped the actual experience — not the documented one, but the real journey clients took — we found seven points where clients consistently got stuck. Not because the information wasn't there, but because it wasn't where they expected it, when they needed it.
The fix wasn't more documentation. It was restructuring the existing documentation around how clients actually behaved, not how the company wished they would.
Building for the Exception
Robust processes don't just handle the standard path. They include decision trees for common exceptions. They give staff clear authority to resolve issues within defined boundaries. They answer the question before it gets asked.
This means:
Documenting the "what ifs." Not every possible scenario, but the ones that come up repeatedly. If your team asks you the same question every month, that question should be in the documentation with a clear answer.
Defining decision boundaries. Your sales rep shouldn't need your approval to offer a 5% discount if that's a normal business practice. Document the threshold. Give them authority. Free yourself from micro-decisions.
Creating escalation criteria, not escalation habits. Escalation should happen for genuinely unusual situations, not for anything that feels slightly unfamiliar.
The Test You Should Run
Pick one process in your business — sales, onboarding, fulfilment, support. Ask your team to list every question they've escalated or been unsure about in the last month.
If that list is longer than two or three items, your process isn't robust. It's a facade.
The good news: you now know exactly what to fix. Each of those questions is a gap that, once closed, removes friction permanently.
The Business That Looks Right But Isn't
From the outside, your systems appear solid. The documentation exists. The software is in place. The dashboards show activity.
But underneath, your team is improvising constantly. Decisions stall. Questions queue up. Customers wait.
That gap between appearance and reality is where profit leaks, where staff burn out, where growth quietly stalls.
Closing it doesn't require new technology or more staff. It requires honesty about what your processes actually handle — and the willingness to build them for the world as it is, not as your flowchart wishes it were.