Where the FAQ Goes: At the Point of Need

Wednesday, 08:20, at Harbourview Clinic. Jo is first in on a desk of three. The first ticket of the day is 3306, from Amara on reception: "Label printer at the front desk won't print, red light, patients waiting." It is the fourth ticket this month about that printer and the fourth from a different receptionist. Reception runs on a rota, and each one meets the red light for the first time. There is an article about it. There is also a page on the portal called FAQ, with seventy-one questions on it, and the red light is question forty-four. Nobody on reception has ever opened that page. Reception does not browse. Reception has a queue of people holding appointment letters.

Jo walks to the front desk, holds the feed button for three seconds, and the printer wakes up. Then she takes a card from her pocket, writes four lines on it, and tapes it to the top of the printer: "Red light? Hold the feed button for three seconds. Still red? Ring 2200." That card is the whole of this article. The answer was already written; it had been sitting in the wrong place for a year.

The point of need is the moment and the place where the user actually has the question: standing at the printer, staring at the error, typing the ticket. A FAQ, for frequently asked questions, is the desk's short list of the questions it hears most and the answer to each. It deflects a ticket only when the answer is at the point of need. A page called FAQ is not a point of need. It is where answers go to be alphabetised. This article is part of our Ticket Deflection Strategy series. It is about moving the answers to where the questions are.

It covers why the FAQ page fails even when every answer on it is right, and the five points of need, with a table. Then come the answer on the thing itself, the answer beside the error message, and the answer in the form and in the acknowledgment. Next is the portal front page, briefly, because it has its own series. Then comes choosing the ten questions worth placing, with a worked example from one fictional desk. Keeping placed answers current, a short war story, and the placement map to copy finish the article, in that order.

Why the FAQ Page Fails

The FAQ page fails because nobody goes to it. Nobody goes to it because it is organised around the desk's convenience rather than the user's moment. The desk has seventy-one answers and wants one place to keep them. The user has one question and is standing somewhere specific with it. The page serves the first need perfectly and the second not at all. That is why its view count is a handful a month. Most of those are the desk checking that it still loads.

Users do not look for a page of questions; they look at the thing that is broken. Amara looked at the printer, then at the red light, then at the queue, then at the phone. At no point in that sequence did a web page come to mind. The web page is in a different room, behind a login, under a menu. She is holding a stack of appointment letters. The answer has to be in the sequence she is already in. The printer is in that sequence. A card on the printer is read by every receptionist who ever meets the red light, at the precise moment they meet it. It never needs a login.

The second failure is scale. A page with seventy-one answers has a scrolling problem, a naming problem and a finding problem. Every one of those gets worse with each answer added. A card with one answer has none of them. The unit of deflection is one question at one place, and the FAQ page is an attempt to make one place do the work of seventy-one. It is a filing cabinet. Filing cabinets are excellent at holding things and poor at handing them to people who did not know to open the drawer.

The Five Points of Need

There are five points on a user's path where an answer can arrive before a ticket. They were drawn as a picture in What Deflection Means. In order from the user's side: the thing itself, the portal front page, the search results, the request form as they type, and the acknowledgment after they submit. The table below says, for each, when the user is there, what kind of answer fits in that space, and an example. The earlier the point, the cheaper the deflection, because the user has spent less time by the time the answer reaches them.

Each row is a different medium with a different size of answer. The card on the printer holds four lines; the acknowledgment can hold a paragraph and a link; the search results hold a title and nothing else. The mistake desks make is writing one answer and expecting it to work at every point. The printer card and the full article are two different documents about the same thing. The article is the long version, kept once. The card is the short version, placed many times.

On the Thing Itself

The thing itself is the cheapest point of need and the one desks forget, because it is not on a screen. Take printers, meeting-room screens, door-entry panels, the till, the scanner in the warehouse, and the phone on the reception desk. Each is a physical object that the user stands in front of when it misbehaves. Each has a flat surface. A card, a label or a sticker on that surface is read by exactly the people who need it, at exactly the moment they need it. Nobody else reads it. A label is a knowledge base article with a readership of one and a hit rate close to certain.

Keep it to the one thing that fixes the one common fault, and the number to ring when it does not. "Red light? Hold the feed button for three seconds. Still red? Ring 2200." Four lines is the limit, because a card with twelve lines is a FAQ page with tape on it. If the device has two common faults, it gets two cards, or one card with two lines each. If it has five, the device has a problem that a card will not fix. That belongs to whoever manages the problem rather than to the label.

Where the answer is longer than four lines, the card carries the short version and a way to the long one. That can be the article's title, written exactly as the user should search for it. Or it can be a printed code they can point a phone camera at to open the article directly. The code works well on devices in shared spaces, where the user has a phone and no computer. It works badly on anything users operate while sitting at their own desk, where typing the title is faster. Test it by handing the card to a colleague and timing them to the article. If it takes more than a minute, the card is decoration.

Beside the Error Message

The error message is the point of need that the desk does not own and should still influence. When the login page says "Your account has been locked", the user is reading the one sentence that could tell them what to do next. Most of the time it does not. The best version of the error says the next step in the message itself: "Your password has expired. Reset it at the usual reset page, or ring the desk on 2200." The second-best has a link beside it to the one article for that error. The worst, and the commonest, says "Contact your administrator", which produces a ticket with the error text pasted in and nothing else.

The desk rarely controls the message, but it usually knows who does. Internal applications have an owner; the login page has a configurable banner on most directory systems; the intranet has a page that users land on. Ask the owner for one sentence, or one link, beside the three errors that generate the most tickets. Owners say yes to this far more readily than desks expect, because the owner is also tired of the tickets and has simply never been asked. The request is small and specific: "Could the locked-account message say 'wait fifteen minutes or ring 2200'?" Nobody has ever refused that sentence, in my experience, though several have taken a quarter to do it.

The outage banner belongs here too. When the finance system is down and the desk knows, the single most deflecting thing it can do is say so. Say it where users will see it before they raise the ticket. Put it on the portal front page, on the login page if it can be reached, and in the acknowledgment for the next hour. One line, in plain words, with a time for the next update, saves every ticket that would have said "is the finance system down?" More importantly, it saves the user the trouble of asking. The words, channels and cadence for that line have a series of their own on outage communication. The only placement rule this article adds is that the banner goes where the user is. That is at the error, not on the FAQ page.

In the Form and in the Acknowledgment

The request form and the acknowledgment are the two points of need the desk fully controls, and they are the two most desks leave empty. The form is where the user puts the problem into words. That means the words are on the screen at the moment the answer could be matched to them. Some portals show two or three matching article titles beneath the subject line as the user types. The mechanics of doing that without getting in the way, and what to do when your portal cannot do it at all, are the subject of Deflection at the Point of Submission. The placement rule is simpler: whatever appears beside the form must never hide the way to send it.

The acknowledgment is the automatic reply the user receives after submitting a ticket. It is read by everyone who raises one, which makes it the most-read document the desk publishes. Most acknowledgments say "We have received your request" and a ticket number. They could also carry one answer. A desk that knows its top five request types can put, in the acknowledgment for each, one line and one link: "If this is about the label printer at reception, holding the feed button for three seconds usually fixes it; if that worked, reply 'fixed' and we will close this." Many tools let the acknowledgment differ by department, form or mailbox, and some do not. Check yours. Where it cannot, one acknowledgment with the three most common answers in it still beats one with none.

The acknowledgment is the last point of need. It is the one with the most text room and the least urgency, because the user has already done the work of raising the ticket. That is exactly why it works: the user is now waiting, with nothing to do. A short answer to try while they wait is welcome in a way that a hoop before the form never is. The ticket exists. Nobody has been blocked. If the answer works, the user replies "fixed" and the desk closes a ticket it never had to think about. A ticket closed by the requester before the desk opened it is still deflection by any honest test. The user got what they needed, and the desk did no work on the day.

The Portal Front Page, Briefly

The portal front page gets one paragraph here because it has a whole series elsewhere. What fits on it, for deflection purposes, is two things. They are the box of the ten most-asked questions, written as the user would ask them, and the banner for anything currently broken. What does not fit is the seventy-one-question FAQ page, a welcome message, the desk's opening hours in a paragraph, or anything that pushes the search box below the top of the screen. The layout that makes people come back, and the reasons they do not, are in Designing a Portal People Return To. This article only insists that the front page is a point of need for the user who arrives already knowing they have a question. The ten questions, not the seventy-one, are what belong there.

Choosing the Ten Questions Worth Placing

The questions come from the queue, not from a brainstorm. Pull the last quarter's tickets, group them by what the user was actually asking, and sort by count. The top twenty ticket types are usually most of the volume, and the method for turning them into the first articles is in The First Twenty Articles. The placement question is a filter on top of that list: of the top twenty, which ones has an answer the user can follow, by themselves, in under two minutes, with no technician involved? Those are the ones worth placing at a point of need. The rest need a ticket whatever you do, and placing an answer for them wastes the space.

Every number from here to the end of the section is a worked example from the fictional desk at Harbourview Clinic. Jo pulled a quarter's tickets, 612 of them, and found the top twenty types covered 390. Of the twenty, seven passed the two-minute test. These were the reception label printer, the meeting-room screen showing no signal, and "my password has expired" for the clinical system. Then came the scanner on the second floor, the patient-letter template that opens blank, the headset that will not pair, and "how do I book the pool car". The other thirteen needed a technician: new accounts, access changes, and hardware that was actually broken. There was also a cluster of "the clinical system is slow" that was a problem for the problem record, not for a card.

Each of the seven got a placement, and not the same one. The printer and the scanner got cards on the device. The meeting-room screen got a sticker beside the cable with two lines on it. The expired-password message got a sentence added to the login banner, which took the clinical system's owner three weeks and one e-mail. The letter template and the headset got a line each in the acknowledgment for the IT department's form. The pool car went in the portal's top-ten box. People ask it from their desks, with a computer in front of them, and nowhere else. Seven questions, five kinds of placement, and not one of them on a page called FAQ.

The full article behind each placement stays in the knowledge base, kept once, and the short version at the point of need points to it. If you run QuerySolv, a knowledge base article can be visible to everyone or only to agents. So the card on the printer and the line in the acknowledgment can both point at one public article. The technician's longer notes for when the card did not work can live in a second article that only agents see. They sit beside the public article rather than mixed into it. In any tool, the principle is one source and many placements. When the fix changes, you change it once and then update the cards. That beats discovering in a year that the card and the article disagree.

Keeping Placed Answers Current

A placed answer is a document with no view counter, no owner field and no review date. It will outlive the thing it describes unless somebody writes down that it exists. The card on the printer stays on the printer when the printer is replaced with a model whose feed button does something else. The banner on the login page stays up after the reset process changes. The line in the acknowledgment keeps recommending the fix for a template that was retired. Each of these is worse than no answer, because the user follows it, it fails, and they raise a ticket that begins "I did what the card said".

The fix is a register, which is what the template at the end of this article is. Use one line per placed answer. It says what it answers, where it is, which article it points to, who owns it, and when it was last checked. The owner is the person who checks it when the thing changes, and "when the thing changes" is the trigger, not a calendar. A new printer model, a new reset process, a new version of the clinical system: each is a line in the change record. Each should prompt a look down the placement map for anything that mentions the thing that changed. The quarterly knowledge base sweep, which looks at the articles themselves, is in Maintenance Without a Documentation Day. The placement map is the sheet that sweep should also read. An article can be perfectly current while the card quoting it is three printers out of date.

Retire placements as readily as you add them. When the reception printer is replaced with one that never shows a red light, the card comes off that day, and the line in the acknowledgment goes with it. A placed answer to a question nobody asks any more is clutter at the point of need. Clutter at the point of need is how the next card, the one that matters, gets ignored. The printer at Harbourview has had one card on it for a year. It will have one card on it next year too, and it may say something different.

A Short War Story: The Till Reboot at Northgate Retail

At Northgate Retail, the head-office desk, led by a technician called Femi, built an intranet FAQ page with a hundred and twenty questions on it. Number sixty-three was the sequence for restarting a till that showed a frozen screen at power-on. Every weekday at about five to nine, somewhere between three and eight store managers phoned the desk about a frozen till. The FAQ page was on a computer in the back office. The till was at the front of the shop with a queue forming behind it. Across forty stores, the review estimated roughly thirty minutes of lost opening time a week per affected store. The desk also spent its first hour each morning reading the same six steps aloud down the phone. Femi printed the six steps on a card the size of a receipt. Femi sent one to every store with instructions to tape it under the till drawer. The same six steps went into the acknowledgment for tickets raised from the stores' form. The morning calls fell to one or two a week within a month. The FAQ page's view count did not change at all, because it had never had anything to do with the problem. An answer in the back office does not help a till at the front of the shop; the answer has to be where the queue is.

The Placement Map

The placement map is the register of every answer the desk has put at a point of need, and it is also the worksheet for deciding where the next one goes. Fill in the top section once a quarter from the ticket counts. Run each question through the two-minute test. Choose the placement by asking where the user is standing when they have that question. The bottom section is the register, one line per placed answer, and the "last checked" column is the one that stops the card outliving the printer. Keep it beside the knowledge base, not in a drawer, because a placement map in a drawer is a FAQ page about FAQ pages.

THE PLACEMENT MAP — ONE PAGE
Desk: ______________________   Owner of the map: ______________   Quarter: ________

PART 1: CANDIDATES (from the last quarter's ticket counts)
   #   Question, in the user's words                     Tickets   Two-minute test   Place it?
   1   ______________________________________________    ______    [ ] pass [ ] fail   [ ]
   2   ______________________________________________    ______    [ ] pass [ ] fail   [ ]
   3   ______________________________________________    ______    [ ] pass [ ] fail   [ ]
   4   ______________________________________________    ______    [ ] pass [ ] fail   [ ]
   5   ______________________________________________    ______    [ ] pass [ ] fail   [ ]
   Two-minute test: can the user follow the answer alone, in under two minutes,
   with no technician?  Fail = needs a ticket anyway; do not place it.

PART 2: CHOOSING THE POINT OF NEED (for each question that passes)
   Where is the user standing when they have this question?
   [ ] At a device              -> card or label on the device (four lines max + number to ring)
   [ ] Reading an error         -> sentence in the message, or link beside it (ask the owner)
   [ ] Arriving at the portal   -> top-ten box entry, in the user's words
   [ ] Typing a ticket          -> suggestion beside the form, submit button still visible
   [ ] Waiting after submitting -> one line and one link in the acknowledgment

PART 3: THE REGISTER (one line per placed answer)
   Question                  Placement           Points to article    Owner        Last checked   Retire when
   ________________________  _________________   __________________   __________   __________     _______________
   ________________________  _________________   __________________   __________   __________     _______________
   ________________________  _________________   __________________   __________   __________     _______________
   ________________________  _________________   __________________   __________   __________     _______________

PART 4: TRIGGERS TO RE-CHECK THE REGISTER
   [ ] A device on the register is replaced or moved
   [ ] A system on the register changes its login, reset or error wording
   [ ] The article a placement points to is edited or retired
   [ ] A placed question stops appearing in the ticket counts (retire the placement)

The two columns on the register that matter most are "points to article" and "retire when". The first keeps the short version honest, because the card is only ever a summary of something longer that somebody owns. The second is the one nobody fills in, and it is the reason there are cards on printers in offices everywhere describing buttons that no longer exist. Jo's register at Harbourview has seven lines on it. The printer line says "retire when: printer replaced", and the day that happens, the card comes off before the new printer is switched on.

Frequently Asked Questions