When Self-Service Does Not Pay, and Where to Stop

Friday, 15:30, at Meridian Parts. Lena has a list of twenty articles she would like to write next quarter. She is proud of it, because every one of them came from a real ticket. Number seven is "Fixing the expense report export error", which she spent an hour on last Tuesday and found genuinely interesting. Hana, who runs the desk, asks one question: how often does that ticket arrive? Lena checks. Four times in the past year, each taking about twenty minutes. Hana does the arithmetic out loud. It is eighty minutes a year of technician time, against three hours to write the article and an hour a year to keep it true. The article would cost more than it saved for as long as it existed. Lena crosses it off, and then, with less enthusiasm, finds that the same test crosses off ten more.

Self-service pays when the question is common, the answer is stable, and the reader can act on it alone. When any of the three is missing, the arithmetic in the rest of this series goes negative. The effort to write and maintain exceeds the hours the article returns, and the honest ledger says stop. This article is part of our Measuring Self-Service ROI series. It is the one about the bottom of the arithmetic: the desks, the ticket types and the requests where self-service costs more than it saves. It covers how to know where to stop before the knowledge base becomes a second queue. Every number in it is a worked example from the same fictional desk.

It covers the break-even test and why the arithmetic has a floor, then small desks and rare tickets. Next come the article nobody reads, and the request that must be a ticket anyway. We cover the places where self-service costs more than it saves, then knowing where to stop. We finish with the honest line on the one-pager, a short war story, and the stop-doing list to copy, in that order.

The Break-Even Test

An article pays when it meets two conditions. The hours it returns in a quarter must exceed the hours it costs in the same quarter. It must pay back its writing effort inside a year. That is the break-even test, and it takes thirty seconds per candidate. Return per quarter is the tickets of that type per quarter times the minutes each one would save, whether by not arriving or by being worked faster. Cost per quarter is the upkeep, usually an hour or so for a checked article, plus a quarter of the writing effort spread over the first year. If return is below cost, the article loses hours for as long as it exists. Lena's expense-export article returned twenty minutes a quarter and cost an hour and three-quarters. The ledger did not need a second column.

The test looks generous, and on paper it is. An article that takes four hours to write and an hour a quarter to maintain breaks even on one half-hour ticket a month. That would seem to justify almost anything. Two honest corrections pull the floor up. First, many of the articles a desk writes never achieve the use their author expected. The title is wrong, the question stops being asked, or the readers were never going to search. So the expected return must be discounted for the chance the article is one of those. Second, the writing hours were not free. They came from a technician who would otherwise have worked tickets or written a different article. The right comparison is not with zero but with the best other use of the same four hours. Both corrections push the practical floor well above one ticket a month.

Meridian's working rule, after a year of ledgers, was ten tickets a quarter or one slow one a month. A desk should set its own from its own figures rather than borrowing that one. Below the floor, the knowledge is still worth capturing, in a form that costs ten minutes rather than four hours, which the next sections describe. Above it, the article goes on the list in order of return. That order is what the hands-on table from the first article in this series was for. Knowledge bases do not know when to stop; they have never once declined an article. Somebody on the desk has to.

Small Desks

A small desk has the same arithmetic as a large one and far fewer tickets to put through it, so most of its ticket types fall below the floor. A one-person desk handling forty tickets a month sees perhaps five types often enough for an article to pay. And the rest of the knowledge base is not a knowledge base but a set of notes. That is not a failure; it is the correct size. The first twenty articles a desk should write, and why that number, are the subject of The First Twenty Articles. For a very small desk the honest number is lower and the list is shorter. The ledger is the thing that says when to stop adding to the list.

The portal is the first thing to question on a small desk, because it has a fixed cost that does not shrink with the queue. Consider setting one up, writing the explanatory text, placing links on error pages, and running the campaign that gets people to visit it. The hours are much the same at forty tickets a month as at four hundred, and the return scales with the tickets. At four hundred, the portal pays in a quarter. At forty, it may never pay. At that volume, a knowledge base reached by a single link in the desk's e-mail signature and its acknowledgment message does most of the same work. It takes a tenth of the effort. Measure before building, which for a small desk means counting how many of the forty tickets a month are the kind an article could answer.

Where self-service does pay on a small desk is technician time, and especially the solo administrator's own time. A one-person desk has no colleague to ask, so every runbook is the second person. And that argument is made in full in the series on the one-person IT department. The deflection side is small because the volume is small. The runbook side is large because the alternative is one person rediscovering the certificate renewal from scratch every year. A small desk that writes five public articles and fifteen runbooks has usually got the proportion right. One that writes fifty public articles and no runbooks has built a portal for its users and left itself with nothing.

Rare Tickets

A ticket type that arrives less than about once a quarter does not justify an article, and the knowledge it carries goes into the ticket instead. The resolution note on the ticket is written for the stranger who will search for the same error in a year. It costs ten minutes, needs no upkeep, and is found by searching the ticket system for the error text. It is exactly as true as it was on the day, because nobody will ever expect it to be current. How to write such a note is the subject of Notes for the Stranger. An article about a problem that happens twice a year is a diary entry with headings, and it will be out of date before the second entry.

The exception is the rare ticket that is also long or dangerous, and the exception is a runbook rather than a public article. Consider the annual certificate renewal that takes a day if you remember the order and three if you do not. Consider the quarterly payroll export that fails one way and must never be retried the other way. Another example is the once-a-year rebuild of the meeting-room system. These arrive rarely and cost hours each. The break-even test passes on the hours alone. Four tickets a year at two hours saved is eight hours, against a three-hour runbook and an hour of annual upkeep. It is still technician time, not deflection, and it is measured by the method in the technician-time article in this series. The user will never read it, and should not have to.

Rare but recurring with a known cause is a third case, and it belongs to problem management rather than to the knowledge base. A fault that returns every few months because the permanent fix is waiting on a supplier gets a known-error record with its workaround. That record is linked from every ticket the fault causes, so that the count rises and the fix gets argued for. The pattern is in Known Errors and Workarounds. Writing a public article for it instead tells users the fault is normal, which it is not, and hides the count that would have got it fixed. Do not write the article for the ticket you found interesting. Write it for the ticket you found boring for the fourth time.

The Article Nobody Reads

An article may have sat idle for two quarters, with few views, no votes and no ticket type it could have changed. In that case, it is costing its upkeep and returning nothing, and the ledger says retire it. How to find such articles from the usage signals is in the usage article in this series. It includes the check that an idle article is not merely a hidden one with the wrong title. This section is about why they were written in the first place, because a desk that understands that stops writing them, which is cheaper than retiring them later.

Most unread articles answer a question nobody asked. They were written from the technician's side, about something the technician found notable, in words the technician would use. And the people who had the problem never searched for it because they did not think of it as that problem. Some were written because the author had an afternoon and a list. Some describe how the desk works, which is of intense interest to the desk and to nobody else. I have written the "how our desk works" article at three different organisations. It has been read, in total, by the three people who replaced me, each of whom rewrote it.

The cure is to write only from the failed-search list and the hands-on table, in that order, and to let the ticket system choose the subjects. A failed search is a question in the user's own words that the knowledge base did not answer. A high line in the hands-on table is a ticket type that costs the desk hours. Both are evidence that the article will be looked for. A subject that appears on neither list may still deserve a ticket note or a runbook. But it does not deserve the four hours and the quarterly check. And a desk that keeps to the two lists writes fewer articles and retires almost none.

The Request That Must Be a Ticket Anyway

Some requests cannot be deflected, because a ticket is the right outcome. The self-service effort for those goes into making the ticket a good one rather than into preventing it. A request is a ticket asking for something the user is entitled to but cannot do alone. That could be an account, a permission, a piece of hardware, or a change to a shared system. Many need an approval from someone other than the desk. Most need a technician's hands; nearly all need a record of who asked, who approved and what was done, which is the audit trail. An article cannot grant a permission. And an article that tells the user how to get one is a form of words for "raise a ticket", which is what the user was about to do.

The honest self-service for a request is a form that asks the right questions once. That way, the ticket arrives complete and the approval can be sought on the first day. That is intake, not deflection, and it is a good thing in its own right; the fulfilment pattern is in Requests, Approvals and Fulfilment. Do not count it in the deflection sum, because no ticket was avoided. Count the minutes saved per request by not having to ask for the missing details, which is technician time, small and real. In QuerySolv, as in most tools, a form submission arrives as an ordinary ticket in the same queue as everything else. That is exactly where a request with an approval attached belongs.

The temptation is to write the article anyway, "How to request a new account", and then to count its views as deflection because the requests fell. They fell because the form got better, or because fewer people joined that quarter, and the article's role was a signpost. A signpost is useful and cheap, and it should be one paragraph with a link to the form, not an article with upkeep. A request type may be truly self-serviceable: the user can do the thing alone with no approval and no risk. In that case, it is no longer a request. It is a how-to, and the deflection sum applies. The test is whether the user can act on the answer alone. If the answer ends with "then wait for us", it is a ticket.

Where Self-Service Costs More Than It Saves

The forced hoop is the most expensive self-service feature a desk can buy, because it saves tickets by making people give up. Consider a portal that will not show the submit button until the user has searched. Or it makes them click through three suggested articles that do not match. That portal reduces ticket volume and increases telephone calls, hallway visits and messages to whichever technician's name the user remembers. None of those are counted. The whole subject, and the rules that keep deflection from turning into obstruction, is Deflecting Without Annoying People. For the ledger, the point is simpler: a drop in tickets that is matched by a rise in phone calls is not deflection. A desk that measures only the portal will report it as a success. The review at one desk I knew described this as "channel shift", which was accurate, in the way a weather report is accurate about a flood.

The wrong article costs more than no article. A reader who follows the steps, fails, and raises a ticket anyway has spent their own time and arrives with less patience. They begin the ticket with "I followed the article". That means the technician must first find out which article and what it said. The usage article's busy-but-failing box is where these live. And every one of them is a negative entry on the ledger: the ticket still arrived, and it arrived longer. An article that is not going to be kept true should not be published. That is the real cost of the quarterly check and the reason upkeep is on the cost side of every sum in this series.

Media drifts faster than text, and costs more to make. A ninety-second video of a sign-in flow takes several hours to record, trim and caption. It is wrong the day the sign-in screen changes, which for most systems is once or twice a year. Annotated screenshots are cheaper and drift at the same speed. Both pay for the five most common questions and almost never for the fiftieth. The break-even test for them must include the remake, because there will be one. The upkeep problem has its own article in the series on visual and video guides. The same test applies to translations, printed quick-start cards, and anything else that cannot be fixed with a two-minute edit. A desk that can only afford to keep text current should publish text.

Enrolment projects for tiny populations are the last place to look. A self-service password reset that needs every user to enrol a second factor is a project of weeks. It pays handsomely at a few hundred users and a hundred reset tickets a month. At thirty users and three reset tickets a month, the enrolment campaign costs more than a year of manual resets. In that case, the manual reset done safely is the better answer. The arithmetic is the same arithmetic; only the volume changed. Self-service is a way of spending hours once to save hours many times, and when "many" turns out to be "three", it is a way of spending hours.

Knowing Where to Stop

Stop writing when the list of candidates that pass the break-even test is empty, and let it stay empty until the failed-search list or the hands-on table refills it. That will happen, because systems change and new questions arrive. A desk that writes two articles a quarter from real evidence is doing better than one that writes twenty from a sense that the knowledge base should be bigger. The size of a knowledge base is not a measure of anything. Meridian's went from a hundred and forty articles to about a hundred over a year of retirements, and its net hours went up. That was because the hundred were the ones people read and the forty had been costing their upkeep for nothing.

Stop maintaining when the usage report says an article is idle for the second quarter running and the title check has been done. In that case, retire it the same week rather than putting it on a list. Lists of articles to retire have a way of becoming permanent, because retiring feels like admitting the article was a mistake. It was not; it was a reasonable guess that the evidence did not support. Say that in the retirement note and move on. A desk that retires briskly keeps the knowledge base it reports on identical to the knowledge base that is working, which is the only state in which the ROI figures are true.

Stop measuring what nobody acts on. Consider a deflection sum for a ticket type with no clean baseline, or a usage report nobody reads. Consider a monthly figure that has not changed a decision in two quarters. Each costs an hour and returns nothing, and the ledger applies to the ledger. Meridian cut its monthly usage report to the top ten, the failed searches and the three action lists. It stopped producing the per-article view history because nobody had opened it since the second month. The measurement that pays is the one that produces a name and a date on an action list. Everything else is a report, and reports, left alone, breed.

The Honest Line on the One-Pager

Put what did not pay on the one-page summary for management, in one line, because it is the most persuasive sentence on the page. "Two articles cost more to maintain than they returned and were retired; the portal's suggested-article feature was switched off after it was found to be raising phone calls" tells the reader that every other figure was counted by someone willing to report a loss. The page itself is laid out in the previous article in this series, and the honest line has a place on it. A desk that has nothing to put there has either a perfect knowledge base or an incomplete ledger, and only one of those exists.

The line also protects the ask. A manager may be asked for protected upkeep time by a desk that has just retired forty articles. That manager knows the time will be spent on the hundred that work, not on growing the number. A manager asked for the same time by a desk that reports only growth suspects the time will be spent writing article a hundred and forty-one. The manager expects it to be about the expense export error, and is usually right. Stopping is evidence of judgement, and judgement is what the ask is really asking the manager to fund.

A Short War Story: The Two Hundred Articles at Bellweather Logistics

At Bellweather Logistics, a technician called Tomasz was given a quarter to "build the knowledge base". With no ledger and a long list of tickets he had found interesting, he wrote two hundred and twelve articles in eleven weeks. His desk lead later estimated the cost at around three hundred and forty technician hours. A year on, the usage report, produced for the first time, showed that fourteen of the articles accounted for nearly all the views. They also accounted for all of the measurable drop in tickets. About a hundred and sixty had been viewed fewer than ten times in the whole year. Thirty or so described the depot systems as they had been before a software change. They were generating "I followed the article" tickets at about twenty a month. The desk spent a further sixty hours reviewing and retiring. During that work, the lead calculated that the fourteen articles that worked would have taken about fifty hours to write from the failed-search list. The remaining two hundred and ninety hours of the quarter would have cleared the backlog twice over. Tomasz had not done bad work; he had done unmeasured work, in volume, which is the expensive kind. A knowledge base built without a break-even test is a backlog that looks like an asset. The hours it costs are paid for by the tickets that waited while it was written.

The Stop-Doing List

The list below is reviewed once a quarter, alongside the usage report, and it is deliberately mostly negative. The rest of this series is about what to do and this is the page about what not to. Section A is the break-even test, one line per candidate article, filled in before anything is written. Sections B to E are the things to stop: writing, maintaining, doing on the portal, and measuring. Section F exists so that the review ends with the articles that are earning their keep, named. Those articles are the reason the rest of the list is worth the trouble. Fill in your desk's own floor in section B from your own ledgers rather than from anyone else's.

SELF-SERVICE STOP-DOING LIST — REVIEWED QUARTERLY
Desk: ______________   Quarter: ______________   Reviewed by: ______________
Our floor for a public article: ____ tickets a quarter, or one slow one a month

A. BREAK-EVEN TEST (one line per candidate, before writing)
   Candidate article          Tickets per   Minutes     Return per      Writing   Upkeep per   Pays?
                              quarter       saved each  quarter (min)   (hours)   quarter (h)
   ________________________   ____          ____        ____            ____      ____         yes / no / note instead
   ________________________   ____          ____        ____            ____      ____         yes / no / note instead
   ________________________   ____          ____        ____            ____      ____         yes / no / note instead
   Passes when return per quarter exceeds upkeep per quarter and the writing pays back inside a year.
   Below the floor: write a resolution note in the ticket, or a runbook if the fix takes hours.

B. STOP WRITING
   [ ] Public articles for ticket types below the floor
   [ ] Public articles for requests that need approval, a technician, or an audit trail
       (write a one-paragraph signpost to the form instead)
   [ ] Articles about how the desk works, for the desk
   [ ] Articles that repeat the supplier's own help page (link it)
   [ ] Video or annotated screenshots for screens that change more than once a year
   [ ] Anything not on the failed-search list or the hands-on table

C. STOP MAINTAINING (retire this week, keep the text findable)
   Idle two quarters, title checked:  ______________  ______________  ______________
   System retired:                    ______________  ______________
   Duplicates, merged into:           ______________  ______________

D. STOP DOING ON THE PORTAL
   [ ] Any step between the user and the submit button that does not change the answer
   [ ] Suggested articles that do not match the words typed
   [ ] Enrolment projects for populations too small to pay back the campaign

E. STOP MEASURING
   [ ] Views reported as results
   [ ] Deflection for any ticket type without a three-month baseline
   [ ] Any report nobody has acted on for two quarters

F. KEEP DOING (the articles earning their keep, by net hours)
   1. ______________________________   net ____ to ____ hours a month
   2. ______________________________   net ____ to ____ hours a month
   3. ______________________________   net ____ to ____ hours a month
   Honest line for the one-pager: ______________________________________________

Lena's list of twenty became nine, and the nine were written over the following two quarters from the failed-search list, in order of return. The expense-export error was recorded as a resolution note in the ticket it had come from. Ravi found it there eleven months later in about forty seconds. Of the eleven that were crossed off, seven became ticket notes, two became runbooks, and one became a link to the supplier's own help page. One, "How the Meridian desk works", Hana wrote anyway, for the next desk lead, and did not put in the knowledge base. It is the only article in this series that was not measured. And it will be read, eventually, by exactly one person, who will rewrite it.

Frequently Asked Questions