Moving From the Front Line to Self-Service, One Article at a Time

Monday, 08:35, at Northgate Retail. Imogen on the front line takes the call she has taken roughly forty times a month since the overnight update went in. A store's label printer shows offline. She does not look anything up. "Turn it off at the back. Hold the feed button down. Turn it on while you're still holding it. Let go when the light goes green. Give it a minute." The store manager, Dev, does it and the printer comes back. He says what two or three of them say every week: "You should write that down somewhere." Imogen has. It is in the runbook, which is in the knowledge base, which is visible to the desk and to nobody else. Dev could not find it if he tried, and he has tried. The next call is at 08:41.

Moving a ticket type to self-service means the user resolves it themselves, from an article they find before they raise a ticket. It is the second step down the staircase this series draws. It is a different kind of step from the first, because the reader is not a technician. Nothing can be assumed. Nothing can require a right the user does not have, and nothing can be dangerous to get wrong. It is made of three things, like the first step. But the three are different. They are an article written for the user, a place where the user will actually find it, and a measure that says honestly whether it is working. This article is part of our Shift-Left Strategy series. And it is about those three and about the ticket types that must never take this step at all.

It covers the different reader and the different document, then which front-line types are candidates. Next come the article visible to everyone, the place where the user will find it, and the measure, counted honestly. The article covers what should never be self-service and the ticket that still arrives. It finishes with a short war story and the self-service candidate sheet to copy, in that order.

A Different Reader, a Different Document

The runbook the front line uses was written for a competent stranger who knows the trade. The article the user reads is written for a frustrated person who does not. The two are different documents with different titles even when they describe the same fix. The runbook says "power-cycle the printer with the feed button held to clear the configuration cache". The article says "Turn the printer off. Press and hold the feed button. Turn the printer on while still holding it." Same fix, every word changed, and the second one has a photograph of which button. The craft of the user's version, including the first sentence that tells the reader they are in the right place, is in Writing for the Frustrated Reader. The two documents are derived from each other rather than written separately, which keeps them true at the same time.

The article is derived from the runbook. And the runbook has been run, which is why the staircase has the front-line step before this one. A fix that went from the specialist's head straight to a public page has been tested on nobody. A fix the front line has talked forty users through has had its missing sentence found forty times. Imogen knew that the light had to go green, not just come on, because the first three store managers she talked through it let go too early. That sentence is in the runbook because of them. It will be in the article because it is in the runbook.

Some of the runbook never reaches the article, on purpose. Anything that names an internal server, a service account, a console or a step the user cannot perform stays in the technician's document. The rule for what crosses the line and what does not is in What Must Never Be in the User Doc. The article is the runbook with the desk's half removed. If the desk's half is most of it, the type is not ready for this step, and that is useful to know before the writing starts.

Which Front-Line Types Are Candidates

The test is the talk-through. If the front line resolves the type by telling the user what to do, the type is a candidate. In that talk-through, the user's own hands are on the keyboard or the printer. The article is the talk-through written down. If the front line resolves it by doing something the user cannot, it is not a candidate yet. That could mean connecting to the machine, changing a setting on a server, or granting a right. The question then becomes whether the desk's part can be removed or made safe for the user to do. Many types are a mixture, where the first two steps are the user's and the third is the desk's. Those become an article that ends with "if this did not work, raise a ticket and tell us you tried these steps". That turns the ticket that still arrives into a shorter one.

Beyond the talk-through, four more things decide the order. Volume, because an article that answers two tickets a month is not worth its upkeep and one that answers forty pays for itself in its first week. Recognisability, because the user has to know, from the symptom alone, that this article is theirs; "the label printer shows offline" is recognisable and "the system is slow" is not. Safety, because the user will sometimes follow the article when it does not apply, and the cost of that must be a restart rather than a loss. And stability, because an article about a thing that changes every month is an article that is wrong most of the time. Sort candidates by volume, then strike out the ones that fail any of the other three.

Password resets deserve one sentence here because they are the largest self-service move on most desks and they are not an article. Self-service reset is a feature of the directory or the identity system, with its own enrolment project and its own trade-offs, and the desk's role in it is the project, the manual reset while it lands and the measurement; that whole subject has its own series at Password Reset Self-Service. Everything in this article is about the self-service that lives in a knowledge base, which is most of the rest.

The Article Visible to Everyone

Most knowledge bases can mark an article as visible to agents only or to everyone. And the whole of this step is moving the fix from the first setting to the second in a form the second audience can use. QuerySolv's knowledge base works that way, as most do, and the distinction matters more than it looks. The agents-only runbook and the public article are often the same record in the tool's eyes. The desk has to treat them as two documents regardless. Title the public one in the user's words: "The label printer says offline", not "Label printer configuration cache reset". The title is what the user searches for. The user searches for the symptom, in the words on the screen, because those are the only words they have.

Open the article with the recognition test in the user's form. The runbook's "applies when" becomes "Does this sound like your problem?" The two sentences that describe it follow. Then comes the one sentence that says what to do if it does not sound like theirs. A user who reads an article that is not about their problem and follows it anyway is the commonest way a self-service move produces more tickets than it removes. And the first paragraph is the only defence. Then come the steps, one action per numbered line, each with what the user should see when it worked. For a printer that is a light, and for a drive it is a letter appearing in a list.

Test it on two real users before it goes public. That means watching them follow it without helping, in the same silence the specialist kept during the front line's rehearsal. The step that is obvious to Imogen and missing from the page will be found in the first three minutes by a store manager with a printer in front of them. Two testers is enough for a short article; a long one has already failed a different test. Then publish it, and date it, and put a name on it. An article with no owner is an article that will be wrong in a year and nobody will know whose job it was to notice.

The Place Where the User Will Find It

An article the user cannot find is a ticket with extra steps, and finding it has four places, in order of how many tickets each one catches. The first is the error message or the symptom itself, where that is possible. That could be a line on the printer's own status page or a link in the automatic reply the desk sends when a ticket is raised. It could be a notice on the intranet page the store managers open every morning. The second is the portal's search, which must match the words the user will type, including the wrong ones. The third is the portal's front page, for the handful of articles that answer the most tickets this month. The fourth is the suggestion that appears as the user types the subject of a new ticket. It is the last chance and the one that catches the user who has already decided to ask. The design of that last moment, so that it helps rather than nags, is in Deflection at the Point of Submission.

The portal itself has to be a place users return to, which is a larger project than any one article. The reason users bypass it in the first place is usually that the first visit failed. They searched, found nothing or found a runbook they could not read, and went back to the phone. Making that first visit succeed is the subject of Making the First Visit Succeed. The point for this article is that the first self-service move on a desk is also the first test of the portal. It should be chosen partly for that. Pick a type whose users are already on the portal, or who open the same page every day, and put the article on that page. Northgate put the label printer article in the store managers' morning checklist, which every manager opened at eight. The portal came later. The checklist was where they already were.

Tell the front line where it is, and have them send it. Every ticket of the type that still arrives gets a reply that fixes the problem and links the article, in that order. The fix comes first, because the user has waited. The link comes second, so that next time they do not have to. A reply that is only the link is a reply that says "go away and read", and users remember it. (They remember it for longer than they remember the fix.) The link in a reply is the slowest way an article spreads and the one that reaches the users who never visit the portal at all.

The Measure, Counted Honestly

The measure is deflection, which is a ticket that never needed raising because the answer reached the user first. The honest ways of counting it, with a baseline, a control type and two columns, belong to Measuring What Got Deflected and to the deflection arithmetic in the self-service ROI series. This article borrows the method and shows the shape on one type. Northgate's label printer tickets ran at about forty a month for three ordinary months before the article. In the three months after, skipping the launch month, they ran at about fourteen. The till scanner tickets, chosen as the control because nobody had written about them, ran at twenty-six before and twenty-five after, so no drift came off. The drop of twenty-six is the high count. The "this solved it" responses on the article ran at about eighteen a month, and that is the low count.

Turn the counts into hours with the type's own figure, not the desk's. A label printer call cost Imogen about eight minutes including the note. So the low column is eighteen tickets at eight minutes, about two and a half hours a month. The high column is twenty-six at the same, about three and a half. Set that against two hours of writing, an hour of testing with two store managers, and half an hour a quarter of upkeep. The article paid back inside its first month on either column. The desk's saving is a small number, and it is the honest one. And it is not the whole saving: forty store managers a month were also spending ten minutes each on the phone. And that time is the organisation's, not the desk's. And it belongs in a sentence beside the desk's hours rather than in the same sum. Report both. Blend neither.

Expect the number to be modest per article and to add up across articles. And expect most of the knowledge base to deflect nothing, because most of it was never meant to. The self-service share of a desk's resolutions grows a few points a quarter when the moves are chosen well. The last article in this series shows how to report that share without flattering it. A desk that reports a dramatic deflection figure after one article has usually measured the launch month, or forgotten the control type, or counted views as tickets. Views are not tickets. A view is a person who looked.

What Should Never Be Self-Service

Some types stay on the front line or above however often they arrive. And the list is short enough to write down and important enough to write down first, before the candidate sheet is filled in. That way, nobody has to argue a type off it later. The common thread is what the fix needs. It needs either a judgement the user cannot make about themselves, a right that must not be theirs, or a step whose wrong version costs more than the ticket. The fifth article in this series, on the limits of shift-left, covers the user who should not be asked to self-serve even when the type is safe. This table is about the types.

Put the never list on the knowledge base's own page for article authors, so that the question "could this be self-service?" is answered before the draft starts. The list protects the desk's judgement from the desk's enthusiasm, which is a real risk on the day the deflection numbers first look good. A user guide for an irreversible step is the fastest way to turn a knowledge base from a thing users trust into a thing they screenshot for each other as a warning.

The Ticket That Still Arrives

After the move, some tickets of the type keep coming, and each one is one of three things. It may be a user who did not find the article or a user who found it and it did not work. Or it may be a user who should not have been asked to try. The first is a placement problem and the reply carries the link. The second is a gap in the article. The reply fixes the problem and the note records what the article missed, so that whoever owns the article hears about it. The third is the limits article's subject, and the right answer is a fix and no link at all. Read the type's tickets for a month after the move and sort them into those three piles; the piles are the next three jobs.

Ask the user, in the reply, whether they tried the article, and make it easy to say no. "Did you find the printer article on the morning checklist? If not, no problem; here is the link for next time" gets an honest answer. "The article covers this" gets silence and a slightly worse opinion of the desk. The answers tell you whether the placement is working, which no view count can. A user who says "I read it and the light never went green" has just handed the article's owner the next edit. They should be thanked for it in the ticket.

Watch the reopen as the sign that an article is answering the wrong question. Suppose a user follows the article, thinks it worked, and raises or reopens a ticket two days later because it did not. The article has cost that user time. And a run of those on one article means the fix was never the fix, or the recognition test is letting the wrong problem in. A requester's reply to a resolved ticket reopens it in QuerySolv and in many tools. Where that happens, the reopened tickets of the type are a filter rather than a search. A glance at them each month is the article's health check. An article that deflects twenty tickets and causes four reopens is doing less than it looks, and the four are where the work is.

A Short War Story: The Helpful Article at Ashgrove Housing

Ashgrove Housing's desk had a steady run of "access denied on the shared folder" tickets from the housing officers, about twenty a month. The front line resolved each by asking the folder's owner to approve and then adding the officer with read access. The desk lead, Fiona, was keen to move the type to self-service. She published an article visible to everyone called "Access denied on a shared folder". It told the officer to ask the folder's owner directly. It showed the owner, with screenshots, how to add a colleague from the folder's own sharing settings. Tickets fell to six a month, which was celebrated. The folder owners were not technicians and had no reason to know what the options meant. Over the next two quarters they added about sixty colleagues with full control rather than read. That included two to the folder holding tenants' rent arrears. The access review that found it took the desk and the data protection officer most of a fortnight to put right, somewhere between fifty and seventy hours. And the article was withdrawn with a note that it should never have been written. Anything that changes another person's access is a request with an approver, not a step the user takes, however many tickets it would save.

The Self-Service Candidate Sheet

The sheet below is one page per ticket type, filled in before any writing starts. And it is designed so that most candidates fail it, because the ones that pass are the ones worth the article. Section A is the never list applied first; a single tick there ends the sheet. Section B is the talk-through test and the four conditions. Section C is the plan for the article, its place and its measure, with the baseline recorded now rather than remembered later. Keep the sheet with the article. When the numbers are read in a quarter, the baseline on the sheet is the one written down before anyone had a result to defend.

SELF-SERVICE CANDIDATE SHEET — ONE TICKET TYPE, ONE PAGE
Ticket type (in the user's words): _________________________________
Tickets per month (three ordinary months): ____ / ____ / ____   Middle value: ____
Front-line runbook exists and has been run: yes / no   Runbook owner: ______________

A. THE NEVER LIST (one tick here ends the sheet; the type stays on the front line)
   [ ] Needs the user's identity verified before the fix
   [ ] Changes another person's access, data or mailbox
   [ ] Irreversible: deletes, wipes, resets a device, restores over current data
   [ ] Symptom could be a security event
   [ ] A wrong attempt costs more than the ticket (visit, reimage, lost morning)
   [ ] Changes a shared system used by others

B. THE TESTS (all must be yes)
   [ ] Talk-through: the front line resolves it by telling the user what to do
   [ ] Recognisable: the user can tell from the symptom that this article is theirs
   [ ] Safe: following the steps when they do not apply costs a restart at most
   [ ] Stable: the steps have not changed in the last two quarters
   [ ] Worth it: tickets per month times minutes per ticket exceeds the upkeep
   Steps the user cannot perform (if any): __________________________________
   How the article ends if those steps are needed: "raise a ticket and tell us you tried ____"

C. THE PLAN
   Article title (the symptom, in the user's words): ____________________________
   First paragraph: the recognition test, and what to do if it does not match
   Derived from runbook: ______________   Removed from it: ______________________
   Tested on two real users, in silence, on: ____________   Gaps found: ____
   Owner: ______________   Review date: ____________
   Places it will be found:
     [ ] the error message or symptom itself: ____________________
     [ ] portal search (words users will type, including wrong ones): ____________
     [ ] portal front page or the page users already open daily: ____________
     [ ] the suggestion when a ticket is being raised
     [ ] linked in every reply to a ticket of this type, after the fix
   Measure:
     Baseline (three ordinary months, recorded now): ____ per month, give or take ____
     Control type (similar size, not written about): ______________  at ____ per month
     Minutes per ticket on the front line: ____
     Read again after three months, skipping the launch month, on: ____________
     Report as: a low and a high count, in hours, beside the users' own time saved

Imogen filled in the sheet for the label printer in about twenty minutes, most of it hunting for the baseline. The article went on the morning checklist eleven days later with a photograph of the feed button that Dev took on his phone. The calls did not stop. They dropped to a third, and the ones that remained were mostly printers that were genuinely broken. That is the kind of call Imogen can do something about. Dev has not said "you should write that down" since. He has, once, said "I read the thing", which on a help desk is as close to applause as it gets.

Frequently Asked Questions