Ticket Deflection with a Self-Service Knowledge Base

Q: What is ticket deflection?

Answering a person's question with self service content before they submit a ticket, so the ticket is never needed.

Ticket deflection is resolving a question before it becomes a ticket, usually by showing the right knowledge-base article while someone is typing their request. It works when three things are true: the articles answer the questions people actually ask (written from real past requests), people see them at the moment of asking (not in a separate portal they never visit), and search understands their words, not just the article's keywords. Measure it with an explicit signal — "this solved my problem" — rather than guessing from abandoned forms.

Why deflection matters more than speed

Every request that doesn't need a human frees time for the ones that do. It also serves the requester better: an answer in ten seconds beats a good answer in two hours. And it compounds — each article written once can answer the same question hundreds of times.

But deflection is only good if the person was actually helped. A form that's hard to submit also "deflects" tickets, by making people give up. The goal is fewer unnecessary tickets, not fewer tickets.

Step 1: write the articles people need

Most knowledge bases fail because they're written from the team's point of view ("VPN configuration overview") instead of the requester's ("I can't connect to the VPN from home").

Start from data:

Export the last three months of requests.
Group them by what was actually asked. The top ten questions are usually a large share of volume — password resets, access requests, "how do I…" for common tools.
For each repeated question, write one article that answers it completely.

Article rules that make them findable and useful:

Title in the requester's words — the question as people ask it.
Answer in the first two lines, then the steps. People scan.
Numbered steps with the exact names of buttons and menus.
What to do if it doesn't work — including "file a request with this category", so failed self-service still ends somewhere.
An owner and a review date. An outdated article is worse than none; it sends people down the wrong path confidently.

Step 2: show answers where people ask

A separate help portal gets a fraction of the traffic the request form gets, because people go straight to "ask a human". So put the knowledge base in the request form:

As someone types a title (after a short pause and a few words), search the knowledge base and show two or three matching articles below the field.
Each suggestion shows a title and a one-line excerpt, and opens in place without losing what they've typed.
A clear confirmation button closes the loop — LetRelay's says "This solved my problem" — while submitting the form as normal keeps going.

This is the pattern on LetRelay's New Request form. When someone confirms an article solved their problem, the app logs a deflection — who, which article, what they typed — and no ticket is created.

Step 3: search that understands meaning

Keyword search fails on the exact problem deflection is meant to solve: people describe problems in their own words. "Can't get on wifi" won't match an article titled "Intermittent wireless connectivity".

Semantic search fixes this by comparing meaning: each article is stored with an embedding (a vector representing its meaning), the typed text is embedded the same way, and the closest articles above a similarity threshold are shown. The setup — pgvector, an HNSW index, a threshold, and hybrid keyword search for exact terms like error codes — is in semantic search with Supabase pgvector.

Tune the threshold on real queries. Too low and irrelevant articles appear (people learn to ignore the suggestions); too high and nothing appears. LetRelay's default similarity threshold for suggestions is 0.72, chosen by checking real questions.

Step 4: measure it honestly

There are two ways to measure deflection:

Method	How	Problem
Inferred	Suggestion viewed + form abandoned = deflected	Counts people who gave up as helped
Explicit	Person clicks "this solved my problem"	Undercounts people who just leave satisfied

Use the explicit signal as your headline number — it's conservative but honest — and track the inferred one as a trend. Then check both against a third signal: if deflection goes up but repeat requests on the same topic also go up, people aren't really being helped.

Useful reports:

Deflections per article — your most valuable articles; keep them current.
Top queries with no good match — what to write next.
Articles shown often but rarely confirmed — titles that match but content that doesn't answer; rewrite them.

LetRelay stores deflections in their own table, readable by staff for analytics, with row-level security scoping them to the organization. Nothing about the AI's output is stored, just the fact that a ticket was avoided and which article did it. The wider metrics set is in help desk metrics that matter.

The ticket deflection rate formula

Once you have a deflection count, the rate is simple:

deflection rate = deflections / (deflections + tickets submitted)

Take a month where 120 people confirmed an article solved their problem and 480 tickets were filed: 120 / (120 + 480) = 20%. Compute it per category, not overall, because a knowledge base that deflects 60% of password questions and 0% of access requests tells you where to write next. Use the explicit count for the headline, and treat a rising rate with rising repeat requests on the same topic as a warning, not a win.

Step 5: close the loop from resolved tickets

Every resolved request is a potential article. Make it easy for agents to turn a good answer into a knowledge-base draft with one click — prefilled with the request's question and the agent's reply, then edited for a general audience. An AI model can draft the article from the thread; an agent reviews and publishes. Over months, the knowledge base grows exactly where demand is.

What AI adds, and what it doesn't

A chat assistant can answer questions conversationally from the knowledge base, which is deflection in another form. It must be grounded — answer only from the articles it retrieved, and say "I don't know, file a request" when nothing matches. An assistant that invents an answer deflects a ticket today and creates two tomorrow. The design principles are in the case for AI that degrades gracefully.

A 30-day plan

Week	Action
1	Export requests; list the top 10 repeated questions
2	Write those 10 articles in the requester's words
3	Turn on suggestions in the request form + the "this solved my problem" button
4	Review: deflections per article, top unmatched queries; write the next 10

FAQ

What is ticket deflection?

Answering a person's question with self-service content before they submit a ticket, so the ticket is never needed.

How do you measure ticket deflection?

Most honestly with an explicit signal: the person confirms an article solved their problem. Track inferred deflection (suggestion viewed, form abandoned) only as a trend, because it counts people who gave up.

What should a knowledge base article include?

A title in the requester's own words, the answer in the first lines, numbered steps with exact button names, what to do if it doesn't work, and an owner with a review date.

Does AI improve ticket deflection?

Semantic search improves findability, and a grounded assistant can answer conversationally. Both only help if the articles are good and the AI answers only from them.

What is a good ticket deflection rate?

There is no universal number, and published figures vary a lot with how deflection is counted. Use your own: compute deflections divided by deflections plus tickets, per category, from the explicit "this solved my problem" signal, and track whether it rises over a few months as you write the articles people search for. A rate that rises while repeat requests on the same topic also rise means people are giving up, not being helped.