What Deflection Means, and What It Does Not
Tuesday, 09:10, at Tollgate Foods. Marta runs a desk of four. The operations director, Clive, has just forwarded her a vendor's slide deck with one line on top: "Can we do this?" The slide says the product will deflect a large share of her tickets. On her screen are two things from the last ten minutes. The first is ticket 4471, from Priya in the warehouse: "label printer on bay 3 not printing, amber light." Marta closed it in a minute with a link to an article called "Label printer flashing amber: hold the feed button", which has existed for eight months. Priya's reply came back at once: "Oh, I didn't know that was there." The second is a phone call from Dev in packing, about the same printer. He tried to raise a ticket on the form and got as far as a required field called "asset tag". He did not know what one was, and phoned instead.
Ticket 4471 is a deflection that failed: the answer existed, and nobody saw it until after the ticket. Dev's phone call is a block that the monthly report would have counted as a success, because the ticket was never raised. Marta writes back to Clive: "Depends what you mean by it." That is the correct answer, and this article is the longer version of it.
Ticket deflection is the answer reaching the user before a ticket is needed. That way, the user does the thing, the desk never hears about it, and both sides are content with the silence. The honest test belongs to the user: asked afterwards, would they say "I got what I needed"? If yes, that was deflection. If they would say "I gave up", it was something else wearing deflection's badge. This article is part of our Ticket Deflection Strategy series. This article is about telling the two apart before you build anything.
This article covers the two tickets that did not happen and why only one of them counts, then the honest definition in three parts. Next come the three fakes, which are the hoop, the hidden door and the counted silence. Then we show where on the user's path an answer can arrive, with a picture. We cover deflection's neighbours, self-service, automation and prevention, which get confused with it. Next come what a deflected ticket costs and saves, as a worked example from one fictional desk, and the deflection that comes back as a phone call. Then come telling management what you mean, a short war story, and the deflection definition card to copy.
Two Tickets That Did Not Happen
Priya's ticket and Dev's phone call both look, from the report, like one ticket fewer. Priya's would have been one fewer if she had seen the article first; Dev's was one fewer because the form stopped him. The report cannot tell these apart, because the report counts tickets. A ticket that was never raised leaves the same hole whether the user was answered or defeated. Every mistake in deflection comes from treating that hole as a single thing.
The difference is what the user is doing ten minutes later. Priya, had the article reached her, would be printing labels and would not think about the desk again that day. Dev is on the phone, cross, having spent six minutes on a form that argued with him. The desk is now spending longer on his call than the ticket would have taken. One of these is a saved ticket. The other is a ticket that moved to a more expensive channel and brought a mood with it.
Both are invisible in the ticket count, and that is why the definition matters before the measurement does. A desk that defines deflection as "fewer tickets" will build things that produce fewer tickets. The easiest way to produce fewer tickets is to make them harder to raise. A desk that defines deflection as "the answer arrived first" will build things that deliver answers. In that case, the ticket count falls as a consequence rather than as a target. The ticket count is a side effect. Treat it as the goal and you will get it, by the worst available route.
The Honest Definition, in Three Parts
The definition has three parts, and a thing has to satisfy all three to be deflection. First, the need was real: the user had a question or a problem that, without an answer, would have become a ticket. A user who browses the knowledge base out of curiosity has not been deflected from anything. Second, the answer arrived: a piece of knowledge reached the user, by some route, at a moment when they could use it. Third, the user got what they needed without the desk doing work on that occasion. The desk may have done the work earlier, by writing the article. That is the whole economy of the thing. The saving is that the work was done once and used many times.
Some vocabulary, since this series uses it throughout. A knowledge base is the collection of written answers the desk keeps, usually as short articles, each answering one question. A portal is the web page where users search those articles, raise a ticket on a form, and see the state of tickets they have already raised. A FAQ, for frequently asked questions, is a short list of the questions the desk hears most, with the answer under each. All three are places an answer can live; none of them is deflection by itself, any more than a shelf is a meal.
Notice what the definition does not say. It does not say the user went to the portal, or searched, or read an article. The answer could have arrived on a label stuck to the printer. It does not say the desk did nothing; the desk wrote the label. And it does not say a ticket was prevented; it says a ticket was not needed, which is a different claim with a different test. Prevented means a wall stood in the way. Not needed means the user walked past the door because they had no reason to open it.
Remember: deflection is the answer arriving before the ticket. If the user, asked afterwards, would not say "I got what I needed", it was not deflection, whatever the report calls it.
The Three Fakes
The hoop is a step the user must complete before the form will accept the ticket. It might be a mandatory search, a tick box that says "I have read the suggested articles", or a question such as "have you tried restarting?" Or it might be a required field the user cannot fill in, like Dev's asset tag. Each hoop was added by someone who meant well and was tired of the same ticket. Each costs the user time without giving them an answer, and each stops a share of them, which the report then counts. A hoop deflects nothing. It filters the queue by patience.
The hidden door is a way of raising a ticket that still exists but is hard to find. It might be the submit button below the fold, or the e-mail address removed from the signature. It might be the phone number taken off the portal, or the "I still need help" link in the same grey as the page. The users who find the door raise their tickets anyway, slightly later and slightly crosser. The users who do not find it go to the other doors, the phone, the walk-up, the technician they know by name, or they stop reporting altogether. The last group is the one that should worry you, because their problems have not gone anywhere. They have simply stopped being counted.
The counted silence is the measuring fake: calling every article view a saved ticket, every drop in volume a deflection, every quiet week a success. Views are not tickets saved. A user can read an article, fail to follow it, and raise the ticket anyway. In that case, the report counts the view and the ticket both. A drop in volume can be a holiday, a system that was replaced, a hoop, or a hidden door. The counted silence is the fake that gets a desk a budget cut. That is because a number that says the knowledge base saved nine hundred tickets will, sooner or later, be used by someone to argue that the desk needs one fewer person. The honest counting methods are in Measuring What Got Deflected. The one-sentence version is: count shadows, report ranges, and never call a view a ticket.
Where the Answer Can Arrive
An answer can reach the user at five points on the path from "something goes wrong" to "ticket raised". The picture below lays them out in order. The first point is the thing itself: a label on the printer, a card by the meeting-room screen, or an error message that says what to do next. The second is the portal's front page, with its box of the ten most-asked questions and the banner that says the finance system is down and the desk knows. The third is the search results, where a title written in the user's words sits at the top of the list. The fourth is the request form, where some portals show two or three matching articles as the user types the subject line. The fifth is the acknowledgment, the automatic reply after the ticket is submitted. It can carry the article for that kind of request and a time by which the desk will reply.
Two things about the picture matter more than the five points. The first is that the points are ordered by cost to the user. A label on the printer costs them nothing, and a search costs them a minute. An acknowledgment arrives after they have already spent the time writing the ticket. The earlier the answer, the cheaper the deflection. That is why the question of placement gets its own article, Where the FAQ Goes. The second is the green box at the end: at every one of the five points, the ticket is still there to raise. The path offers an answer. It never closes the road.
Priya's article was at point three, and she never reached point three, because she went straight from the printer to the form. A label at point one would have caught her. Dev went to point four and met a hoop instead of an answer. The desk at Tollgate had put its one good answer in the one place neither user looked, and then wondered why the article had eleven views in eight months. Articles do not go and find people. People have to be standing where the article is.
Deflection and Its Neighbours
Three other things reduce tickets and are regularly called deflection. Keeping them apart matters because each is built differently and counted differently. Self-service is the user doing for themselves a thing the desk used to do, with a tool built for it. That might mean resetting their own password, ordering a replacement mouse from a catalogue, or adding themselves to a distribution list. Automation is the desk's system doing the work with no human on either side: a new starter's account created from the HR record, a mailbox quota raised by a rule. Prevention is removing the cause so the question never arises: replacing the printer that jams, fixing the sign-on fault that generated forty tickets a month. Deflection is none of these. In deflection the user still does the work; they just do it with an answer in hand instead of a ticket.
| Neighbour | What it is | Example | Who does the work | What the desk builds |
|---|---|---|---|---|
| Deflection | The answer arrives before the ticket is needed | A card on the label printer; an article found by search | The user, following the answer | Answers, placed where the question is asked |
| Self-service | The user does a desk task with a tool built for it | Resetting their own password through the directory's reset feature | The user, operating the tool | The project to switch the tool on and enrol people |
| Automation | A system does the work with no human on either side | A starter's account created from the HR record | The system | The rule or integration |
| Prevention | The cause is removed so the question stops arising | The jamming printer is replaced | Whoever fixes the cause | The problem record and the permanent fix |
The password reset is the classic confusion, so it gets a sentence of its own. Letting users reset their own password is a feature of the directory or identity system the organisation runs, not of the help desk tool, and a desk that wants it runs a project to switch it on and enrol everybody. The desk's part is the project, the manual reset for the people who are not enrolled yet, and the measurement of the drop. That whole subject has its own series at Password Reset Self-Service. It is counted as self-service, separately from deflection, because the sum is different. Self-service replaces a task; deflection replaces a question.
Why does the distinction matter on a small desk? Because the four things have four different costs. An article costs an hour to write and a few minutes a quarter to keep true. A self-service reset costs a project with enrolment at the end of it. An automation costs someone who can build the rule and someone who will own it when it breaks. Prevention costs a permanent fix, which may be a purchase. A desk lead who lumps all four under "deflection" will promise the cheap one and deliver the expensive one. Management will remember the promise.
What a Deflected Ticket Costs and Saves
Every number in this section is a worked example from the fictional desk at Tollgate Foods, invented to show the shape of the sum and nothing else. The label printers generated, in the quarter before Marta looked, 38 tickets. Each took a technician about six minutes to close, which is a little under four hours a quarter. Add the walk to bay 3 when the technician did not trust the user to hold a button. Marta's article took her fifty minutes to write and test. A laminated card for each printer, the same text in four lines, took another half hour and a trip to the warehouse with a roll of tape.
In the following quarter, label-printer tickets ran at somewhere between 8 and 14, depending on which month you looked at. Marta does not know exactly how many were deflected, because a deflected ticket leaves no ticket to count. She is honest about that in her report: "somewhere between 20 and 30 fewer a quarter, probably because of the card, possibly partly because the printers were serviced in the same month." The range is the honest answer. A point would have been a guess with its uncertainty filed off.
The saving is not four hours. It is the difference between four hours of technician time and the hour and a half the answer cost to make. That repeats every quarter the card stays true, minus the ten minutes a quarter someone spends checking that the printers still flash amber for the same reason. Converting that into money, and deciding whether the knowledge base as a whole earns its keep, belongs to the deflection math article in the return-on-investment series. This series counts, and that one converts. The point here is only that a deflected ticket is never free. Someone wrote the card, and someone has to keep the tape from peeling.
The Deflection That Comes Back as a Phone Call
A false deflection does not vanish; it changes channel. Dev's ticket became a phone call. The next one becomes a walk-up at the desk at ten to five, or a message to the technician whose name the user happens to know. Or it becomes a question asked of a colleague who guesses, or a problem that is simply lived with until it is big enough to be an outage. Each of those is more expensive to the desk than the ticket would have been. That is because it arrives without a record, outside the queue, and usually with the words "I did try the portal".
The tell is in the other doors. When the form count falls, look at the phone log, the walk-ups and the technicians' own inboxes for the same month. If those rose, the deflection was a fake. If you run QuerySolv, requests that arrive by e-mail, chat and social messages land in the same queue as the form submissions. A call the technician logs by hand does too. That puts the other doors on the same list as the one you were watching rather than in four people's memories. In any tool, the check is the same: count every door, not the one you changed.
The slowest return is the user who stops reporting. They met the hoop once, decided the desk did not want to hear from them, and now work around every problem they can and ignore the rest. The desk's count goes down and stays down. The desk is pleased, right up until the printer that three people have been quietly not using for a month is needed for the year-end run. Silence from users is not satisfaction. Sometimes it is. The only way to know which is to ask them, which is a thing desks rarely do about tickets that were never raised.
Telling Management What You Mean
Clive's question deserves a one-sentence definition and a one-sentence caution, in that order. Then the slide deck can be discussed on its merits. The definition: "Deflection means the user finds the answer before they need to raise a ticket, so the ticket never happens and the user is fine with that." The caution: "Anything that makes tickets harder to raise will also lower the count, and we will not be doing that, because those tickets come back by phone and crosser." Two sentences, no vocabulary, and Clive now knows what the desk will and will not build. That is the thing he actually wanted to know.
Resist the vendor's number on the slide. It is a number from somebody else's desk, with somebody else's ticket mix, measured by a method the slide does not describe. The only honest thing to say about it is that your desk will find out its own number by trying it and counting. The format for the short written version, the one-page brief a manager reads in two minutes, is in Explaining Technical Things to Management. The deflection version of it has three lines: what we will do, what we expect in a range, and how we will know. Vendor slides are optimistic documents. Yours should not be.
A Short War Story: The Quiet Queue at Redbrook Engineering
At Redbrook Engineering, a desk lead called Dominic was asked to cut ticket volume and did it in a week. The request form gained a mandatory search step, a tick box reading "I have checked the knowledge base", and a required "system name" field. The support e-mail address was removed from the portal so that everything came through the form. Tickets fell by a third in the first month, and Dominic reported the figure as deflection. In the third month the licence server for the drawing software stopped issuing licences at 07:40 on a Monday. Nobody told the desk until 13:15, because the engineers had learned that the form was a chore. They had spent the morning borrowing licences from each other and restarting their machines. They had also asked the one engineer who knew a technician's mobile number to text him, which he did, at lunchtime. Forty engineers lost most of a working day. A customer drawing deadline slipped by two days. The review found that the "deflected" tickets had mostly become phone calls to the project managers. They had been fielding them without telling anyone. The form went back to one required field. The e-mail address went back on the portal. The ticket count went up, which Dominic reported as recovery. A ticket that is not raised has not been deflected; it has been hidden, and hidden problems choose their own moment to arrive.
The Deflection Definition Card
The card below is the definition in a form you can pin above the desk and attach to any proposal that uses the word. Fill in the top two lines once, and run every new idea, the vendor's or your own, through the three tests and the four questions. An idea that passes the tests and answers the questions is deflection. An idea that fails a test is one of the fakes, however good its intentions. The card says so before the monthly report has to. Marta attached hers to her reply to Clive, with the vendor's slide scored against it. The conversation that followed was shorter and better than the one the slide had been trying to start.
THE DEFLECTION DEFINITION CARD — ONE PAGE
Desk: ______________________ Owner of this card: ______________
DEFINITION
Deflection is the answer reaching the user before a ticket is
needed, so the user does the thing and the desk never hears of it.
Test from the user's side: asked afterwards, would they say
"I got what I needed"? [ ] yes = deflection [ ] no = not deflection
THE THREE TESTS (all three must be true)
[ ] The need was real: without an answer, this would have been a ticket
[ ] The answer arrived: at a point on the path where the user could use it
[ ] The user got what they needed with no desk work on that occasion
THE THREE FAKES (any one of these means it is not deflection)
[ ] A hoop: a step the user must complete before the ticket is accepted
[ ] A hidden door: a way to raise a ticket that is harder to find than before
[ ] A counted silence: views, quiet weeks or volume drops reported as saved tickets
FOUR QUESTIONS FOR ANY PROPOSAL
1. Where on the user's path does the answer arrive?
[ ] the thing itself [ ] portal front page [ ] search [ ] the form [ ] acknowledgment
2. Is the ticket still one click away at that point? [ ] yes [ ] no
3. How will we know it worked? Method: ____________________ Range expected: ______
4. Which other doors will we watch for the same period?
[ ] phone [ ] walk-up [ ] e-mail to technicians [ ] chat [ ] other: ________
NEIGHBOURS (counted separately, built differently)
Self-service: user does a desk task with a tool built for it (project)
Automation: a system does the work, nobody on either side (rule)
Prevention: the cause is removed (permanent fix)
SIGN-OFF
Proposal: ______________________ Passes all three tests: [ ] yes [ ] no
Reviewed by: ______________ Date: ________ Re-check after: ________
One line on the card earns its place above the rest: question two. Every fake in this article fails it, and every honest deflection passes it, which makes it the fastest test you have. If the ticket is not one click away at the point where the answer arrives, you are not deflecting. You are standing in a doorway, and the people who need to get through will find another one.
Frequently Asked Questions
Is a required field on the request form a hoop?
Our tool reports a "deflection rate". Can we use it?
Is password self-service a kind of deflection?
If tickets go down but phone calls go up, what has happened?
Does a drop in tickets after we fixed a recurring fault count as deflection?
Is deflection worth bothering with on a desk of two people?
From the QuerySolv team: we build self-hosted help desk software for Windows. QuerySolv runs as one Windows service on your own network. It takes requests by web form, e-mail, live chat, social messages and REST API. It is licensed once per installation rather than per agent per month. The free trial runs the full product for 30 days.
