Most Support teams approach automation the same way: identify the high-volume, low-complexity ticket types, build the flows, and measure deflection rate. If deflection goes up, the project worked.
The problem with that logic is that the deflection rate tells you how many conversations your automation handled. It doesn’t tell you whether it handled them well, or what it cost you when it didn’t.
I’ve spent fifteen years in Customer Support, a significant chunk of it in QA consulting. The patterns I keep seeing in automated queues aren’t random. The failures cluster in predictable places, around predictable interaction conditions.
Once I started mapping those conditions against what we actually know about how human communication works, a clearer picture emerged: many automation routing decisions are measuring the wrong thing.
This post lays out what the right signals are, and why they matter more than ticket category or handle time.
The Question Routing Decisions Are Answering
When you decide to automate a ticket type, you’re making a claim about that interaction: that it doesn’t require anything a human uniquely provides.
That claim is fine for a lot of ticket types. It’s wrong for more of them than most teams realize.
The useful question isn’t “is this ticket simple enough to automate?” It’s: “does this interaction require anything that automation structurally cannot do?”
There are four categories of requirement where automation hits a hard wall. They don’t show up in your ticket categories. They show up in the conversation itself.
Signal One: the Customer’s State Before You’ve Said Anything
The single most important routing signal is also the one almost no QA framework measures: how recoverable is this conversation before the agent says a word?
I’ve been calling this entry tractability. It describes the degree to which a conversation is recoverable toward genuine resolution given what the customer is bringing into it. And it’s shaped almost entirely by what happened before the conversation was opened.
A customer contacting Support for the first time about a bounded, factual issue has high entry tractability. They want information or an action. They’re oriented toward cooperation. Automation handles this well.
A customer contacting Support for the third time about the same unresolved issue has low entry tractability.
- They’ve accumulated frustration across every prior interaction.
- Their trust in the process is already compromised.
- They’re not looking for information.
- They’re looking for someone to take ownership.
The gap between those two conversations isn’t visible in the ticket category. Both might be tagged “account issue” or “billing query.” But they require completely different responses, and only one of them is a candidate for automation.
The signals to look for in the opening message:
- References to prior contact (“as I mentioned last week,” “this is the third time”).
- Relational leverage language (“I’ve been a customer for five years,” “I’ve always recommended you to colleagues”).
- Multiple unrelated complaints surfacing at once.
- Escalation language before any response has been given.
- Fragmented or emotionally activated sentence structure.
Any of these indicate that the customer is not in a cooperative orientation. They’re in a repair-seeking orientation. And automation cannot perform the repair they need, because repair requires genuine acknowledgment, not a template.
The most acute version of this is what researcher John Gottman identified as flooding: a state of emotional overwhelm in which productive exchange becomes neurologically impossible until the person has had time to regulate.
An automated response to a customer in a flooding state doesn’t help them regulate. It gives them something to be frustrated at while they regulate on their own, and then they arrive at a human agent angrier than when they started.
You’ve added a step and made the human’s job harder.
Route these conversations to humans. The deflection you lose is worth less than the relationship you preserve.
Signal Two: the Gap Between What the Message Says and What It’s Doing
Here’s a request that looks automatable: “I’ve been a customer for four years and I’m just wondering what my options are at this point.”
It’s polite. It’s vague. It contains no explicit complaint. A topic classifier will probably tag it as “account query” or “general enquiry.”
It is in fact a cancellation signal.
The customer isn’t asking for information. They’re performing a retention threat in the politest possible register, giving the organization one last opportunity to respond before they leave.
An automated response that answers the surface question, “here are your account options”, has committed the worst kind of communication failure: technically responsive, completely irrelevant.
This gap between what a message says and what it’s doing is one of the most consistent failure points in automated Support.
Customers don’t write Support tickets in the direct, explicit language that automation handles well.
They write in the indirect, contextual language that humans use when they’re frustrated, disappointed, or testing whether the organization actually cares.
Some patterns to train your team to flag before routing decisions are made:
- “I suppose I could just…” = embedded threat or ultimatum.
- “I’ve been with you for X years / months” = relational leverage, often precedes an escalation or cancellation.
- “I don’t really understand what happened” = trust repair request, not a comprehension gap.
- “This is the third time I’ve…” = escalation demand embedded in a factual report.
- Any message that ends with a question that isn’t actually a question.
None of these are automatable.
That’s not because they’re complex in a procedural sense, but because responding to them correctly requires reading what the customer is doing with their words, not just what they’re saying. That’s a profoundly human skill.
Current automation, including AI-assisted automation, manages common versions of these patterns with reasonable accuracy. It fails on the long tail, and the long tail is exactly where your most at-risk customers live.
Signal Three: Whether Your Organization Has a Coherent Position
This one is less visible than the others, and it’s the one that causes the most damage when it’s missed.
Some ticket types arrive in Support carrying a contradiction the organization itself created.
Marketing positioned a feature one way. Sales promised something in a call that isn’t documented anywhere. A policy changed and not everyone was told. The customer’s understanding of what they’re entitled to doesn’t match what Support is authorized to deliver, through no fault of their own.
When that gap exists, automation doesn’t just fail to help. It actively makes things worse. It states policy.
The customer knows policy doesn’t match what they were told. They experience the automated response as the organization refusing to acknowledge its own contradiction. What was already a frustrating situation becomes a trust-destroying one.
The signal here is harder to catch at the routing stage, but some markers are reliable:
- Issue types with high repeat-contact rates on the same underlying problem (a signal that the first contact isn’t establishing shared understanding, which automation will compound).
- Ticket categories that frequently involve Sales-originated commitments.
- Feature or policy areas where Marketing messaging has historically outrun product reality.
- Any issue type where agents regularly escalate not because the customer is difficult but because they don’t know what the organization’s actual position is.
These interactions require a human who can navigate the gap between organizational promise and organizational reality with enough care to preserve the relationship.
Automation cannot perform that navigation. It can only report on one side of the contradiction, which is the side that makes the customer feel gaslit.
Signal Four: Whether Resolution Is Verifiable Without Asking the Customer
The last signal is the simplest, and it’s the one that’s easiest to apply systematically.
Good automation handles interactions where resolution is binary and system-confirmable. The refund was processed. The address was updated. The information was sent. The system knows whether it happened. The customer can verify it independently.
Poor automation handles interactions where resolution requires judgment about whether the underlying situation is actually resolved.
The customer’s problem was technically addressed but the real issue was something the ticket description didn’t capture. The policy technically applies but the specific circumstances make it feel deeply unfair.
The customer needs an exception and there’s no rule that covers it.
These interactions require discretion. Not just policy knowledge, not just empathy, but the capacity to recognize when the right answer in this specific situation is different from the standard answer, and to act on that recognition.
That’s judgment, and judgment is not encodable. You can give automation rules. You cannot give it the recognition of when rules don’t apply.
A quick practical test: for any ticket type you’re considering automating, ask whether a human reviewing the closed ticket could confirm resolution without contacting the customer again. If yes, strong automation candidate. If no, keep a human in the loop.
Putting It Together
None of this means automation is the wrong tool. It means the criteria your team uses to decide what to automate might be incomplete, or at least needs a good look.
Ticket category and handle time do not tell you about interaction conditions:
- what the customer is bringing into the conversation,
- what they’re actually asking for beneath the surface of their message,
- whether the organization’s own coherence issues have already damaged the relationship before automation responds,
- whether resolution in this type of interaction is something a system can confirm.
Before routing a ticket type to automation, run it against four questions:
- What does entry tractability typically look like for this ticket type? Are these customers arriving in a cooperative orientation, or a repair-seeking one?
- Is there a reliable gap between what customers say and what they’re doing in this ticket category? Are indirect requests, embedded threats, or relational leverage common here?
- Does the organization have a coherent position on this issue type? Or is this a category where upstream misalignment regularly produces contradictions that agents have to navigate?
- Is resolution verifiable without asking the customer? Or does knowing whether the interaction actually worked require human judgment?
If the answers to questions one through three are consistently favorable and the answer to question four is yes, you have a strong automation candidate. If any of the first three raise flags, you have an interaction type where automation will produce failures that deflection rate will never show you.
The goal isn’t to deflect as many tickets as possible. It’s to deflect the right ones, and to know the difference.
Written by Ines van Dijk
Ines van Dijk is the founder of Customer Support Excellence and the author of The Customer Support QA Playbook. Her research on the Conversational Integrity Model is indexed on SSRN.
