Home › Topics › Ticket Deflection Strategy › What Deflection Means

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.

A path from 'something goes wrong' on the left to 'ticket raised' on the right, with five numbered points along it where an answer can arrive before the ticket: at the thing itself, on the portal front page, in the search results, in the form as the user types, and in the acknowledgment. Each point says where the user is at that moment and what form the answer takes there. The ticket at the end of the path is marked as always one click away.
Five points where an answer can arrive before the ticket, and the ticket, still one click away at every one of them.

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.

NeighbourWhat it isExampleWho does the workWhat the desk builds
DeflectionThe answer arrives before the ticket is neededA card on the label printer; an article found by searchThe user, following the answerAnswers, placed where the question is asked
Self-serviceThe user does a desk task with a tool built for itResetting their own password through the directory's reset featureThe user, operating the toolThe project to switch the tool on and enrol people
AutomationA system does the work with no human on either sideA starter's account created from the HR recordThe systemThe rule or integration
PreventionThe cause is removed so the question stops arisingThe jamming printer is replacedWhoever fixes the causeThe 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?
It is a hoop if the user cannot reasonably fill it in, such as an asset tag they have never seen, or a system name they do not know. It is not a hoop if it asks for something the user has to hand and the desk genuinely needs on every ticket, such as which building they are in. The test is whether a user with a real problem can get past it in under a minute without guessing. Keep required fields to the two or three that pass that test.
Our tool reports a "deflection rate". Can we use it?
Only once you know what it counts. Ask whether the figure is article views, "this answered it" clicks, abandoned forms, or a drop in volume. Each of those means something different and only the clicks are close to a real deflection. Report the tool's figure alongside the method, as a range, and never as a count of saved tickets on its own.
Is password self-service a kind of deflection?
It is self-service, which is a neighbour. The user does a task the desk used to do, using a feature of the directory or identity system rather than the help desk tool. Count it separately, because the sum is different and the project to switch it on is different. The desk's role is running that project, doing the manual reset safely for people not yet enrolled, and measuring the drop.
If tickets go down but phone calls go up, what has happened?
Most likely a hoop or a hidden door has moved tickets to a more expensive channel rather than answering them. Check what changed on the form or the portal in the same month, and ask three of the callers why they phoned. If the answer is "I tried the form", undo the change and watch the two counts for another month.
Does a drop in tickets after we fixed a recurring fault count as deflection?
No; that is prevention, and it is better than deflection because the question no longer arises for anyone. Record it as a permanent fix in the problem record, with the ticket count before and after. Keep it out of the deflection figures so that the knowledge base is not credited with work the fix did. Mixing the two makes both numbers useless.
Is deflection worth bothering with on a desk of two people?
Yes, for the five or ten questions that arrive every week, and no for the rest. A small desk gets more from one card on the printer and one well-titled article for its top question than from any portal feature. That is because the writing costs an hour and the saving repeats. Start with the single most common ticket, put its answer where that question is asked, and count for a quarter before writing the next.

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.