Deflecting Without Annoying People: No Hoops, Always a Way Through

Monday, 08:40, at Bluewater Bank. Kemi, a branch adviser, has a dead card reader at her counter and a customer in front of it. She opens the portal. It asks her to search first, so she types "card reader" and gets three articles about the staff car park. She clicks past them. A page asks "Have you tried restarting the device?" with two buttons. She has, and says so. The form appears, with a required field called "device serial number". The number is on a sticker underneath a reader that is bolted to the counter. She types "unknown". A dialog says "Are you sure this needs a ticket? Many issues are resolved by the knowledge base." She is sure. It is 08:51. The customer has left, and Kemi picks up the phone.

At the desk, Jon sees the phone queue light up and, on the same screen, the form count for the morning sitting lower than usual. For about a minute he is pleased. Then the third caller in a row says "I did try the portal". Jon opens the form himself, as a user, for the first time since it was changed. He counts the steps between a branch adviser and the submit button. There are five. Each was added by someone who meant well. Together they are a turnstile with a help page on it.

Annoyance, in deflection, is any step that costs the user time without giving them an answer. A false deflection is a ticket that did not get raised because the user was blocked rather than answered. And the two are the same thing seen from opposite ends. Every hoop produces a share of false deflections, and every false deflection comes back by a more expensive door. The deflection that respects the user's time offers an answer and never demands anything in return. This article is part of our Ticket Deflection Strategy series. It is about the difference between an offer and a gate.

It covers the offer and the gate, then the hoops, each with the good intention behind it and what it costs. Next comes always a way through, and why the form is one door and never the only one. It covers what a false deflection costs, as a worked example from one fictional desk. Then comes respecting the user's time with a three-second rule. A table covers the wording that annoys and the wording that does not. Next come the signs that you are annoying people, a short war story, and the no-annoyance rules to copy.

An Offer, Not a Gate

An offer puts an answer beside the user's path and lets them take it or walk past. A gate puts something across the path and lets them through when they have done what it asks. Both reduce tickets. Only one of them deflects, in the honest sense defined in What Deflection Means, because only one of them leaves the user answered. The other leaves them delayed. A user delayed enough will stop walking and take a different path: the phone, or the corridor, or silence.

The test is what happens to the user who ignores the offer. If they lose nothing, it was an offer. Examples are the search box above the form that they scrolled past, and the three suggested titles they did not open. Another is the line in the acknowledgment they did not read. If they are stopped, it was a gate. Examples are the search they had to run, the tick box they had to tick, and the question they had to answer. Another is the dialog they had to dismiss. A good offer is invisible to the user who does not need it. A gate is visible to everyone and resented by most.

Gates are built one at a time, by people who are tired of the same ticket, and nobody ever builds the fifth gate on purpose. The first was a search box, which is fine. The second made the search mandatory, because nobody used the box. The third added "have you tried restarting?", because of the forty tickets that a restart fixed. The fourth made the serial number required, because of the technician who kept having to ask for it. The fifth was the dialog, added by someone who had read something about deflection. Five reasonable decisions, one unusable form, and a phone that rings at 08:51.

The Hoops, and the Good Intentions Behind Them

Every hoop has a reason, and the reason is usually a real problem the desk was trying to solve. That is what makes hoops hard to remove: whoever argues for taking one out is arguing against a reason. The table below lists the common ones, the intention behind each, what it costs the user, and the offer that solves the same problem without a gate. The pattern in the last column is always the same: do the thing beside the path instead of across it.

Two of these deserve a sentence more. The required field the user cannot know is the hoop desks most often defend, because the technician's time is real and the question is genuinely asked on every ticket. The answer is to ask it once, in the first reply, from a technician. That technician can also say "or tell me which counter you are at and I will look it up". This avoids making a branch adviser crawl under a counter with a customer waiting. And the wizard routes tickets by asking the user to classify their own problem. It assumes the user knows which team owns what. They do not and should not have to. Routing is the desk's job. The triager does it in ten seconds with a ticket in front of them. The user does it in two minutes with a form in front of them, and gets it wrong.

Always a Way Through

The form is one door into the desk. The rule that protects users from every hoop at once is that it is never the only door. The e-mail address stays in every signature and on the portal. The phone number stays on the portal, on the printer cards, and on the wall. The walk-up stays possible for anyone in the building. Each is a way through for the user the form has failed. And each is a safety valve for the desk, because the pressure that a hoop builds up has somewhere to go that the desk can see. Remove the doors, and the pressure goes into the corridor, the technicians' personal inboxes, and the problems people decide to live with.

Keeping every door open does not mean running every door separately. The doors all lead to one queue. That way, a request by e-mail and a request by form are the same kind of thing. They are triaged the same way, in the same list. The user who chose the phone is not punished for it by a slower reply. The argument for one queue with many doors is made in full in One Queue, Many Doors. If you run QuerySolv, requests from the web form, e-mail, live chat and social messages all become ordinary tickets in the same queue. That makes the many-doors rule a matter of leaving the addresses published rather than of running anything extra. In any tool, the rule is that the user chooses the door and the desk chooses nothing about them because of it.

Resist the argument that keeping e-mail open "undermines the portal". It does not. A portal that answers questions is used because it answers questions, and the existence of an e-mail address changes that not at all. A portal that is used only because the alternatives were removed is not being used; it is being endured. And the adoption figure it produces is the same counted silence as every other false deflection. How to grow portal use without taking anything away from anyone, including the explicit rule of never punishing people for e-mailing, is in Promoting the Portal Without Nagging.

What a False Deflection Costs

Every number in this section is a worked example from the fictional desk at Bluewater Bank, invented to show the shape of the cost. Kemi's attempt at the form took eleven minutes and produced no ticket. Her phone call took the desk nine minutes. The technician had to take the details down by hand and log the ticket. He also had to listen to an account of the form that Kemi felt he needed to hear. A ticket raised on an honest form would have taken her two minutes and the desk one minute to triage. The hoops saved the desk nothing; they cost it eight minutes and cost Kemi nine, before the card reader had been looked at by anyone.

Multiply by the morning. Jon counted eleven callers that day who said some version of "I tried the portal". If each cost the same, the day's hoops cost the desk roughly an hour and a half and the branches roughly the same. All that was for a form count that was lower by about a dozen. The form count was reported upward as a success for two months before anybody counted the phone. The money side of that sum, and the rules for doing it without fooling yourself, belong to the return-on-investment series. The point here is that the cost is paid twice, once by the user and once by the desk. Only the second half is ever visible from the desk's side.

The slower cost is trust, and it does not show up in minutes. A user who was blocked once searches less next time, trusts the suggestions less, and raises the ticket by whichever door was least annoying. That is rarely the form. A user who was blocked twice stops trying the portal at all and tells the branch so. Jon's estimate, a quarter later, was that somewhere between a fifth and a third of the branch staff had stopped opening the portal for anything. He also estimated that winning them back took longer than the five hoops had taken to build. Hoops go up in an afternoon. The trust they spend comes back a user at a time.

Respecting the User's Time

The rule that keeps an offer from becoming a gate is the three-second rule. An answer offered on the user's path must be recognisable as relevant or not within three seconds, or it must get out of the way. Three suggested titles in the user's words pass; the user reads them and knows. A paragraph of advice above the form fails; the user has to read it to find out it does not apply. A suggestion that opens on an introduction fails; the user wanted step one. Everything the desk puts beside the path is competing with the submit button for a few seconds of a busy person's attention. It has to earn them or lose gracefully.

Respecting time also means never making the user do the desk's work. That work includes classifying the ticket, finding the serial number, and choosing the right team. It includes deciding the priority against a definition they have never read. Each is a thing the desk does in seconds and the user does slowly and badly. Suppose a form asks the user for the three things only they know: where they are, what is wrong in their words, and how it is affecting them. It leaves the rest to the triager. That is a form that takes two minutes and is not resented. The triager's part of that bargain, asking once for everything else, is a different discipline, and it is what makes the short form possible.

The acknowledgment, the automatic reply after submitting, is the last place to respect time and the commonest place to waste it. Suppose an acknowledgment opens with two paragraphs about the desk's hours, its service levels and its commitment to excellence, before the ticket number. It is read by nobody and resented by the people who scroll it looking for the number. Ticket number first, one line on what happens next and when, and, if there is one, the single answer worth trying while they wait. Four lines. The desk's commitment to excellence can be demonstrated rather than announced.

The Wording That Annoys and the Wording That Does Not

Most hoops are built from words, and the same intention can be phrased as a gate or an offer. The table below pairs the common annoying phrasings with versions that offer the same help without the implied doubt. The pattern is that the annoying version addresses the user as a suspect. It treats them as someone who probably has not tried the obvious thing and needs to be checked. The better version addresses them as a colleague with a problem. The tone that makes this natural across a whole desk, writing like a person rather than a policy, is the subject of Writing Like a Person, Not a Policy. And the table is that article's advice applied to the three places users meet deflection.

Read the left column aloud and notice how much of it is about the desk: its process, its knowledge base, its requirement that you confirm. Read the right column and notice that it is about the user's problem. That is the whole trick. Nobody minds being offered help. Everybody minds being told, by a form, that they probably have not tried hard enough.

Signs You Are Annoying People

The signs arrive by the other doors, because the form cannot report its own failures. The phone rings more, and callers open with "I did try the portal". Walk-ups increase, especially from the people nearest the desk, who have discovered that the corridor is faster than the form. Technicians start finding requests in their personal inboxes and chat messages from users who have learned a name. A manager mentions, in passing, that their team "finds the portal a bit much". And the ticket count on the form falls. Read on its own, that looks like success. When the other doors are busy, it is the most reliable sign of the opposite.

Check for them once a quarter, deliberately, by counting the other doors for the same period as the form and by asking. Three callers, asked kindly why they phoned rather than used the form, will tell you in a sentence each. The sentences will name the hoop. Walk the form yourself, as a user, on a phone, with a real problem from last week's queue. Count the steps to the submit button. If it is more than one screen and three fields, something has been added since you last looked. In that case, the something is the thing to remove. The wider diagnosis of why users avoid a portal, of which hoops are one cause among five, is in Why Users Bypass the Portal.

The hardest sign to read is silence. A user who has met the hoops twice may stop reporting. In that case, their problems do not appear by any door until one of them is big enough to be an outage. There is no counter for this. There is only the habit of asking, in the quarterly conversation with each department, "is there anything you have stopped bothering to tell us about?". There is also the willingness to hear the answer. The answer is usually a printer, and it has usually been broken for a month.

A Short War Story: The Triage Wizard at Greyfriars School

At Greyfriars School, the IT lead, Marcus, replaced the request form with a six-question wizard. It asked teachers to classify their problem by system, by device type, and by urgency on a four-point scale with definitions. It asked whether they had restarted, then asked for room number in a format the wizard checked. Finally it asked whether the problem "prevents teaching". Only then did it show a form whose submit button sat beneath a panel of suggested articles. Teachers, who raise tickets in the four minutes between lessons, gave up on it within a fortnight and went back to catching a technician in the corridor. That worked for the teachers who knew a technician and not for the rest. A classroom projector in the humanities block stayed dead for most of a term. The three teachers who used that room each assumed someone else had reported it, and none of them could face the wizard. The review costed it at something over forty lessons taught without the board. The cost also included a head of department who stopped trusting the desk's "we fix things in a day" line. Marcus replaced the wizard with a form of three fields. He put the e-mail address back on the portal and sent every teacher one line: "Tell us what's wrong in your own words; we'll sort out the rest." Tickets went up. The corridor went quiet, and the projector was fixed in an afternoon. A form the user cannot face in four minutes is not deflecting tickets; it is deciding which problems the desk will never hear about.

The No-Annoyance Rules

The rules below are the checklist for any form, portal page, acknowledgment or suggestion panel the desk puts on a user's path. Run every proposed change through them before it goes live. Run the whole set once a quarter against what is actually live, because hoops accrete between reviews. Each rule is a yes-or-no question about a specific thing. And a no on any of them is a hoop to remove rather than a point to debate. Jon printed the sheet at Bluewater and walked the form with it the afternoon of the eleven phone calls. Five noes, five removals, and the phone was back to normal by Wednesday.

THE NO-ANNOYANCE RULES — ONE PAGE
Desk: ______________________   Reviewed by: ______________   Date: ________
Walk the form as a user, on a phone, with a real problem from last week's queue.

THE OFFER TEST
   [ ] A user who ignores every suggestion, search box and hint loses nothing
   [ ] Every answer offered can be judged relevant or not in three seconds
   [ ] Nothing the desk puts on the path asks the user to do the desk's work
       (classifying, routing, prioritising against a definition, finding a serial number)

THE FORM
   [ ] Submit button on screen without scrolling, same place before and after suggestions appear
   [ ] No mandatory search before the form
   [ ] No "have you tried ..." page or question before the form
   [ ] No tick box confirming that suggestions were read
   [ ] No confirmation dialog, "are you sure?", or second page
   [ ] Required fields: ____ (three or fewer), each answerable by any user in ten seconds
   [ ] Steps from opening the form to submit, counted today: ____ (one screen)

THE DOORS
   [ ] E-mail address published on the portal and in signatures
   [ ] Phone number published on the portal, on device cards, and on the wall
   [ ] Walk-up possible and not discouraged
   [ ] Every door lands in the same queue and is triaged the same way
   [ ] No user is answered slower, or told off, for choosing a door other than the form

THE WORDING
   [ ] Nothing above, beside or after the form addresses the user as if they had not tried
   [ ] Acknowledgment: ticket number first, one line on what happens next and when,
       one answer to try at most, under five lines in total
   [ ] First reply with an article: the link, one sentence, and a way back if it fails

THE QUARTERLY CHECK
   Form tickets: ____   Phone: ____   Walk-ups: ____   E-mail to individuals: ____
   Callers asked "why not the form?": ____   Hoops they named: __________________________
   Departments asked "anything you've stopped telling us?": ____   Answers: ______________

NOES FOUND: ____   REMOVED: ____   OWNER OF EACH REMOVAL: ______________________

The one rule on the sheet that catches the most is the first: a user who ignores everything loses nothing. Every hoop fails it. Every honest offer passes it. The rule takes about ten seconds to apply to any proposed change. Kemi, at the branch, now opens the portal and types "card reader dead". She sees one suggestion that is actually about card readers. She either follows it or presses the button beneath it. Two minutes either way. The customer stays at the counter, which, as far as Kemi is concerned, is what the help desk is for.

Frequently Asked Questions