Deflection counts everybody who did not file a ticket — including everybody who gave up. A number that cannot tell those two apart will be optimised by a system that cannot tell them apart either. This page is about what changes when you score the other thing.
A hundred people arrive with a question. Three things happen to them, and the number a bot is scored on counts two of the three as the same result.
Found the answer, applied it, carried on with their day. The only ending anybody actually wants.
Closed the window. Worked around it. Asked a colleague. Decided the feature was not for them. Filed nothing, said nothing, and counts as a win.
Reached a person eventually, having first been asked whether the article was helpful. The only ending the metric treats as a loss.
Change any number above and the bracket still covers two of the three. A system scored on that bracket has no reason to prefer the first bar over the second, and over time it stops preferring it.
None of these is a bad decision. Each is correct play for a system scored on tickets avoided — which is the argument. Change the score and all four stop making sense.
Anything is better than nothing when nothing is scored as a ticket. A near-miss article costs the bot nothing and costs the reader four minutes finding out it was a near miss.
Asked at the moment the reader is least able to know. They have not tried it yet. Whatever they press, the conversation is now over, which was the objective.
Escalation is the one outcome the metric punishes, so it sits behind a rephrase, then another rephrase, then a form. Every second of that is spent by somebody who already knew they needed a person.
Not knowing is free, as long as the reader keeps typing. There is no number anywhere in the system that gets worse the longer this goes on.
Amvio is scored on whether the person got the thing working. Read the four boxes again against that sentence and every one of them becomes a losing move.
Not a better model on the same architecture. Four things a support bot structurally does not have, each of which is a page of its own.
The question is almost never the question. “How do I export?” from the billing page and from a report are two different answers, and only one of them is on any page in your help centre.
read the page →It walks your software before it answers anything — every screen, every control, including the behaviour nobody wrote a page about. That is what makes an answer specific instead of plausible.
read the page →What this company struggled with in March, what they never came back to, what they were told. Held per organisation, so the fourth person from an account does not start over.
read the page →And stop there, out loud, with everything already said handed to a person. The one behaviour a deflection metric can never reward.
read the page →Saying “I don’t know, here is a person, here is everything you already told me” is not a missing feature in the products you have tried. It is the feature their scoring forbids.
Pricing, contracts, roadmap promises, anything you told it not to touch, and anything it cannot support with evidence. Refusing is a defined outcome, not a fallback.
The person picking it up gets what was asked, what was tried, and what it was unsure about — so the reader is not asked to explain themselves a second time.
Somebody who leaves politely without getting there is the exact case a deflection rate scores highest. Here it is the case worth looking at.
Ask any bot something it has no evidence for. What it does in the next three seconds tells you what it is paid on, and you will not need the rest of this page.
The second frame readers land on, usually about ninety seconds after the first. Three differences that are structural rather than a matter of quality.
Retrieval is the easy half and every product on the market has it. The hard half is deciding which of the four plausible pages is the one for this account, on this screen, on this plan — and then saying the answer instead of handing over three links and a shrug.
Every conversation is read afterwards for what it taught — what your product does that nobody had written down, what your team calls things, which explanation actually landed. Today is the worst it will be.
The renewal conversation knows about the onboarding because it is the same one holding the same account record. A support bot bolted to a separate onboarding tool is two systems that have never met.
Run these against whatever you have now, and against this. We have no production numbers to show you and will not invent any — but you can run the test yourself this week.
Not a trick question — a real one about your own pricing, or a promise nobody has made. A bot rephrases and offers an article. The other thing says it does not know and offers you a person.
If the answer is identical, it never knew which screen you were on, and everything it told you was written for an average user who does not exist.
Every product has behaviour nobody has written a page about. A retrieval system cannot reach it by definition. This is the single fastest way to tell the two apart.
The demo is thirty minutes on your product, not ours. The useful part is watching what happens at the edge of what it knows — because that is the part no scoring metric can fake.
You arrived with one frame. The person you have to convince next is holding a different one.
all four, in one page →A document knows what it says. It does not know where anything is in this account, or that the step it describes was renamed.
read the comparison →It fires on your calendar and cannot watch. Nobody is stuck on day one — they are stuck on day forty.
read the comparison →The honest one, and the strongest. A person is better than this at four things. They are also asleep, ramping, and outnumbered.
read the comparison →Your users are already having the conversation. Right now it is with nobody.