The moment a case falls outside the rules, the front line improvises
The tool covers the common cases. It is the others that produce the pricing errors, the orders to redo and the unhappy customers — and they are precisely the ones nobody ever specified.
What you see
- A salesperson reaches for a calculator, or reopens an old file to copy from it.
- A printed sheet is pinned up next to the workstation. It says what to do in the cases the tool does not handle.
- New staff take months to work unaided, because the essential part is not learnt in the tool but from the colleague at the next desk.
- The same request gets two different answers depending on the person, and on the site.
- Someone regularly has to go back over things: a price to correct after the fact, a file to redo, a claim turned down.
What is actually going on
A tool is specified around what is frequent, and rightly so: you start from the situations that make up the volume, and you ship. But a trade is not judged on its frequent cases. It is judged on its hard ones — and those are exactly the ones the tool hands back to a person.
The problem is not that the tool stops. It is that it stops without saying so. It displays a result, and nothing indicates that the result has left its domain of validity. The old hand knows and corrects it; the newcomer does not and applies it. The difference between the two shows up on the invoice, several weeks later.
Alongside that, there is everything the tool does not see at all: outside portals where information is re-keyed by hand, one body at a time, fields that already sit in the file open on screen. That is not a missing feature. It is a boundary nobody crossed, because it belonged to no project.
What it costs you
The lost time is visible. What is less visible is trust: a salesperson contradicted twice by the tool stops relying on it and goes back to their own method. From then on, the figures you look at no longer describe what happens on the ground. You are steering by a picture, not by reality — and that is the kind of gap you only find while looking for something else.
How we go about it
We start with the edge cases, not the common ones. That is the reverse of the usual order, and it is deliberate. We collect them from the people who meet them, we write them down, and we settle each one: the tool handles it, the tool explicitly refuses and says why, or the tool hands over with everything needed to decide.
The third answer is often the right one. A tool that says “this case is outside my domain, here is what I have” is worth more than a tool that answers wrongly with confidence.
What you end up with
A tool that knows its limits and states them. The hard cases are handled, or explicitly ruled out — never left vague. A newcomer works unaided from day one on the common cases, and knows exactly when to ask for help.
And the trips out to external portals disappear wherever they can: what is already in the file does not have to be typed in somewhere else.
Where we have already seen this
On corrections outside the standard range, the tool showed a result without flagging that it had left its domain. Staff took over by eye. The first task was to name those cases, not to code them.
A handful of families, and almost as many special cases: here the edge case is the norm. The tool had to be designed for the exception before it was designed for the rule.
The questions we get asked
Our special cases really are special. Can they go into a tool at all?
Some of them, yes. The work starts by sorting them: those that are unwritten rules, those that are genuine exceptions, and those that no longer exist but that nobody dared remove. The third group is always larger than people think.
How do you collect those cases?
From the people who meet them, not from the people who describe them. The real data says the rest: a survey of what exists brings up values that should not be there, and each one tells the story of a case that had been forgotten.
What if the tool has to depend on third-party software we do not control?
It happens, and it has to be said at the scoping stage. A connection that depends on an outside vendor can end up blocked by a defect that is not ours. In that case we plan a fallback, and we do not invoice a promise that is not ours to keep.
Our teams do not like new tools.
Almost always because one was imposed on them that did not follow the way they work. Acceptance is done by your users, on their real files, against criteria written in advance. Not our demo screens, and not our test data.
The other situations
- Re-keyingThe same order gets typed in three times
- Business rulesYour business rules live in a spreadsheet nobody dares touch
- Platform ceilingYour application has hit the limits of its technology
Tell us about the case your tool cannot handle.
Thirty minutes are enough to know whether a bespoke tool is justified, what it would cost, and how long it takes to pay for itself. If the answer is no, we tell you that too.
Book 30 minutes (new tab)