Support deflection that resolves cases instead of turning people away

Deflection is one of the most popular support metrics and one of the most misleading. It counts how many tickets never get created. From the user's perspective, the same situation often looks different: the bot answered, the problem is still there, and the next attempt goes through email, phone, or a new ticket. The ticket was avoided. The case was not.

The FAQ bot shifts work, it does not finish it

Many deflection solutions are, at their core, search engines on top of an FAQ. They can answer a question, but they cannot do anything. No access to cases, no view of systems, no way to check a status or execute a step.

The user receives instructions and is left alone with the execution. The work does not disappear, it shifts: back to the user, or back to the team with a delay. And when the case finally reaches a person, it starts from scratch, because nothing from the conversation was documented.

Four steps that turn deflection into resolution

Turning an answer into a completed case requires an unbroken chain. It consists of four steps.

Answers with a source. Answers come from a structured knowledge layer, not from free-floating model knowledge. In nara, that layer is Memory and the knowledge graph: guides, product information, and processes remain verifiable, and the agent cites the source instead of guessing. When knowledge is missing, it says so and hands off rather than inventing a plausible answer.

Status instead of a waiting loop. A large share of recurring requests only asks about the state of a case. The agent reads tickets and cases directly and answers with the current status. The team is not interrupted, and the user is not stuck in a queue.

Executing standard actions. Many requests do not end with information but with an action: updating a case, triggering a check, sending a notification. The agent uses only tools approved for that agent. Every execution is recorded in the log and the ticket.

Escalation with context. When a person takes over, everything is there: the history, the verified knowledge, the steps already executed, and the open question. Nobody tells their story a second time, and nobody repeats a diagnosis that has already run.

How to measure the difference

Counting only avoided tickets also rewards brushing people off. More telling questions include: Was the case actually completed? Did the same user come back with the same issue through another channel? How many handoffs did an escalated case need, and could the team take over the history without follow-up questions?

This kind of measurement requires every automated contact to be documented as a case. That is exactly why nara turns conversations into tickets with history instead of letting chats run alongside support. The IT service desk automation page shows what this chain looks like in an IT context.

Naming the boundaries honestly

Special cases and goodwill decisions stay with people. The agent prepares decisions involving discretion and hands them over fully documented; it does not make them. Which tools an agent may use is defined per agent.

And there is no universal resolution rate. How much can be completed automatically depends on knowledge, system access, and processes, and is validated per environment, not promised up front.

The starting point is in your tickets

Which requests are worth tackling first is written in your own ticket history: the most frequent questions, the typical returners, the cases that only ask for a status. In a ticket analysis, we walk through these patterns together and show, using your most frequent requests, what nara can complete and where your team takes over.