An industrial distributor's WhatsApp assistant handles orders and sends PDF technical sheets whenever a customer asks for one. One day it stopped being able to send the sheets for one of the suppliers in the catalog. Nobody noticed for weeks. Not because nobody was watching, but because, as far as the system was concerned, nothing had gone wrong: every request still ended with a reply correctly sent. That reply just happened to be the same apology every time.
If your business runs any automated process (an assistant, a form, an automatic confirmation email), it could be failing right now in exactly this way: no error, no number turning red on any report, nothing to catch anyone's eye.
What was actually happening?
The supplier's website, where that technical sheet came from, started blocking automated lookups without warning anyone. The WhatsApp assistant already had a line ready for when it couldn't find a document: "I couldn't check that sheet, let me connect you with someone." A reasonable message, meant for the odd one off case.
The problem is that fallback line can't tell the difference between "this happens once a month" and "this happens every single time, for weeks." Both situations produce the exact same entry in the exact same place: a request handled, a reply sent, case closed. To any report that only checks whether the system responded, the two look identical: fine.
It took several weeks to notice, and the way it surfaced wasn't a report. It was a customer, asking why the sheets for that particular supplier had stopped arriving.
Why didn't the system ever flag it as a failure?
Because "breaking" and "giving the wrong answer" are not the same thing to a computer, and almost no business measures the second one. A system that crashes, or that takes forever, or that throws an error is easy to catch: something visible is broken, and someone can count it. A system that keeps running perfectly but has quietly changed what it delivers leaves no such trace. It keeps "working." What it hands back just stopped being useful.
This isn't unique to a WhatsApp assistant. The same pattern shows up in a confirmation email that a form change quietly redirects to the wrong inbox (and keeps sending, just to the wrong place), in a report that compares two locations and assumes both share the same setup when only one was ever actually configured, or in any connection between two systems that, faced with data it doesn't know how to read, chooses to "carry on anyway" instead of stopping to flag it. In every case, the "all good" count keeps climbing. The only thing that changes is what's really sitting behind that number.
How many times a month does your business fall back to a stock answer?
This is the question that actually matters, and almost no owner has ever asked it, simply because the number has never been in front of them. Most systems, when something doesn't go as expected, already have a line ready: "please try again later," "we couldn't find your order," "let me pass you to a colleague." Those lines are written for the rare case. The trouble starts when the case stops being rare and nobody is counting how often that line gets used.
In the distributor's case, looking at exactly that number is what revealed how big the problem really was: out of 31 requests about that supplier in the weeks before the fix, not a single one had retrieved its sheet. Not one. After the fix (the system was changed to pull the sheet straight from the supplier's public catalog instead of the route that had been blocked), 15 of that same volume of requests now retrieve it correctly. The jump from 0 to 15 over the same number of requests is the proof that the failure was real and constant, not a one off.
The check you can run today, without touching anything
None of this needs technical know how. It just needs looking with a different question in mind.
- List every customer facing automated process your business runs: an assistant answering on WhatsApp or chat, an order or booking form, an automatic confirmation or invoice email, a sync between two systems.
- For each one, ask: what does it say when something doesn't go well? If the answer is "I don't know," that's already your first warning sign: nobody designed that message on purpose, which usually means nobody is counting how often it shows up either.
- Ask for, or check yourself, how many times that fallback reply was used last month. Not the total number of requests or orders, just the ones that ended with "I couldn't" or the equivalent. If nobody can hand you that number in five minutes, it means nobody is watching it today.
- If the number exists and it's high, ask since when. A fallback reply used 1% of the time is normal. The same reply used 40% of the time, for weeks, isn't an exception anymore: it's a broken process dressed up as a working one.
- Also ask who finds out today when it happens. In the distributor's case, the one who found out was a customer, on the phone. If a complaint is your only way of discovering a failure like this, you already know how long it can run before anyone does.
The rule that matters beyond this one case
If any process in your business has a fallback reply ready for when something fails, that reply isn't the end of the problem, it's the start of a question somebody needs to ask every month: "How often are we using it, and is that number going up?" As long as that question has no answer, a real failure and a one off look exactly the same from the outside, and only one of the two is going to cost you.
This is exactly the kind of problem that disappears once the data from your different systems lives in one place, instead of each one keeping its own private version of "everything's fine": you can see how it works for an AI sales assistant handling real WhatsApp orders inside a distributor's ERP in this real case. It's also the kind of review we run as part of our services, before a customer finds the failure instead of you.
If you want us to look together at how many stock answers your business is quietly giving out right now, get in touch.
