Killing the Source, Not the Symptoms: Five Fixes and the Case

Wednesday, 17:20, at Kestrel Coaches. Sinead runs the three-person desk for a bus and coach operator with four depots. She has a hotspot card on the desk in front of her and a meeting with the operations manager on Thursday morning. The card says: driver sign-on terminals, one per depot, thirty-eight tickets a month. They split roughly into PIN resets, frozen screens and jammed duty-sheet printers. They cost about fourteen desk hours a month, with a queue of drivers at 05:30 every time one fails. The desk has already made the tickets fast. Arjun has a canned reply for the PIN reset and can do one in four minutes. There is a knowledge base article for the depot supervisors on clearing the printer. The tickets have not got fewer. They have got quicker, which is a different thing. Sinead has just realised that she has been reporting it as the same thing for a year.

A symptom fix makes a hotspot's tickets cheaper: a faster resolution, a canned reply, a known-error article, a technician who can do it in their sleep. A source fix makes the tickets stop. Both have a place, and a desk that confuses them will get steadily more efficient at work that should not exist. This article is about the second kind: the five ways a source can be removed and how to choose among them. It covers how to build the case in tickets and hours so that someone outside the desk says yes. It also shows how to prove afterwards that the hotspot actually cooled rather than moved. It is part of our Hotspot Analysis series. It assumes you have a card from the earlier articles with a source, a count and a rate on it.

It covers the difference between symptom fixes and source fixes, then the five fix options and choosing among them. Next come the case in tickets and hours, the one-page case, and doing the fix without creating a new hotspot. Then it covers verifying that the hotspot cooled and what to do when the fix is refused. A short war story and the source-fix plan to copy finish the article.

Symptom Fixes Are Not Wrong, They Are Just Not This

The desk's instinct when a ticket type repeats is to make it fast, and the instinct is right as far as it goes. A canned reply, a scripted reset, an article the supervisor can follow: each one turns a twenty-minute ticket into a four-minute ticket. On a hotspot producing forty a month, that is ten hours a month returned to the desk. It is also where most desks stop, because the pain has gone and the metrics look good. The tickets are still arriving. The drivers are still queuing at half past five. The source is still there, and the desk is now its efficient servant.

The tell that a desk has stopped at the symptom is a hotspot whose tickets are fast, frequent and proudly reported. First-contact resolution for the type is high. Resolution time is low. Satisfaction is fine because the fix is quick, and the count has not moved in a year. Those are the numbers of a well-run symptom. A source fix shows up as the one metric the others cannot flatter: the count going down, for that source, against its peers, and staying down. Keep the symptom fixes; they are how the desk survives the months before the source fix lands. Just stop calling them the fix.

The Five Fix Options

Every source fix is one of five moves, or a combination, and naming the five keeps the conversation from collapsing into "we need a new system". Replace swaps the thing for a different thing: a new model, a new application, new access points in the hall. Retrain changes what the people do with the thing. The search needs a student number, not a name; the receipt must be a photo under a certain size. Redesign changes the process or configuration around the thing without replacing it: a standard role at onboarding, a lead time, a setting the vendor documented, a form with the right fields. Retire removes the thing altogether because it turns out not to be needed: the terminal nobody would miss, the report nobody reads, the second system that duplicates the first. Automate makes the thing fix itself or the request fulfil itself: a scheduled restart, a self-service reset, a role granted by rule.

Each option has a characteristic shape of cost and a characteristic risk, and the table below lays them side by side. Replace is the most expensive and the most certain; retire is the cheapest and the rarest, because the thing usually is needed by somebody. Redesign is the option most often available and most often missed. It requires someone outside the desk to change a decision rather than someone inside it to do work. Retrain is the one everyone reaches for first and the one that fades fastest. Automate is the desk's own option, and the one most likely to be built for a ticket that a redesign would have removed entirely.

Choosing Among the Five

Ask the five in a fixed order, and the order is by how much they cost to ask, not by how often they win. Retire first: does anyone actually need this thing, and have we checked by asking rather than assuming? Kestrel's sign-on terminals were needed; drivers must sign on. Redesign second: is there a decision, a setting or a process change that would remove the ticket type at its source? Two of the three ticket types were candidates. The PIN resets were one: the terminal could accept the driver's badge instead of a PIN, and nobody had turned that on. The printer jams were the other: the duty sheet could be sent to the driver's handset instead of printed. Automate third: for whatever remains, can it fix itself? The frozen screens cleared on restart, and a scheduled restart at three in the morning was a day's work. Retrain fourth, for whatever the first three left. Replace last, when the thing itself is the source and nothing around it will do.

The measure that chooses is tickets removed per hour of effort, over a year, and it is a rough figure, not a formula. Badge sign-on would remove about twenty of the thirty-eight tickets a month. It would take a setting change and an afternoon re-enrolling badges at each depot. That is around two hundred and forty tickets a year for perhaps sixteen hours of work. Replacing the four terminals would remove perhaps the same twenty, plus some of the frozen screens. It would take a purchase and a week of rollout. The redesign wins by a distance, and the comparison is what makes the Thursday meeting short: Sinead is not asking for new terminals. She is asking for a setting.

Retraining alone is the option I trust least, and I say so because I have watched it fail politely a dozen times. A training session removes a ticket type for about a quarter. After that, the people who attended have forgotten, and the people who joined since never heard it. The count is back where it was with a line in the report saying "training delivered". Retraining holds when it is attached to a redesign that makes the right action the easy one. That means the guide linked from the error screen or the field that will not save without the student number. It can also mean the message that arrives before the run. Teach people and change the thing. Teaching them instead of changing it is a quarter's relief and a year's disappointment.

Combine options where the ticket types differ, because a hotspot with three symptoms rarely has one fix. Kestrel's plan was redesign for the PINs and the printing, automate for the frozen screens, and a one-page retraining note for the depot supervisors to cover the transition. Three options, three lines on one plan, one owner conversation. The temptation is to pick the biggest option and let it cover everything. The biggest option is replacement, and replacement of the terminals would have kept two of the three ticket types. The PIN policy and the paper duty sheet would have moved to the new hardware unchanged. (New hardware is excellent at running old processes.)

The Case in Tickets and Hours

The case is three numbers and a comparison: what the hotspot costs now, what the fix costs, and how long before the second is paid back by the first. All three are in hours, because hours are what the desk can prove from its own tickets. The person approving the fix can attach a rate to hours in their own head faster than the desk can defend a currency figure. Where the fix involves a purchase, the budget holder prices it. The desk's job is to put the hours beside it so the purchase has a comparison. There are two different hours-per-ticket figures: hands-on and loaded. They must never be mixed. The figures and that rule are in What ROI Means for a Help Desk. The case uses hands-on for the low column and loaded for the high, and reports both.

Kestrel's numbers, as the fictional example: thirty-eight tickets a month. Hands-on time from a sample of ten tickets was between twelve and twenty-five minutes. That means eight to sixteen desk hours a month, a hundred to a hundred and ninety a year. Add the requesters' time honestly and separately. A driver waiting at a dead terminal loses ten to twenty minutes, and so does the driver behind them. That comes to something like a hundred and fifty to three hundred driver hours a year. The operations manager will care about that figure more than the desk's. The fix: about sixteen hours of desk and depot time for the badge change, and a day for the scheduled restart. Add the handset duty-sheet change, which the operations team had already planned for other reasons. Expected removal: thirty or so of the thirty-eight tickets a month. Payback of the desk's effort: inside the first two months even on the low column. Written down, the case is four lines. The hotspot had run for three years without anyone writing them.

Range every figure a reader might copy, and say where each came from. "Twelve to twenty-five minutes, from a sample of ten tickets closed last month" is a sentence that survives a sceptic; "about twenty minutes" is a sentence that gets asked about. The sample is the desk's own evidence, and ten tickets read with a stopwatch in mind is a half-hour job that makes the whole case defensible. How do you turn this kind of count into a case a manager will fund? How do you meet the objections before they are raised? That is the subject of Evidence Over Anecdote and its series. The hotspot case is the simplest version of it, because the evidence is already sorted by source.

The One-Page Case

The case fits on one page because the decision it asks for is usually small, and a long document signals a large ask. The page carries the hotspot in one line from its card, and the count and the hours as ranges. It gives the option chosen, with the two it beat and why. It includes the fix's cost in hours and anything the budget holder must price. It also gives the expected count afterwards, how and when the desk will measure it, and the single sentence of the ask. It is written for the person who will say yes or no, in their words rather than the desk's. Say "drivers queue at a dead terminal" rather than "terminal availability". The source-fix plan at the end of this article is that page with blanks in it.

Name the measure before the fix, in the case, so that nobody can argue afterwards about what success looked like. "The sign-on terminals produce thirty-eight tickets a month now; after the badge change and the scheduled restart we expect under ten; we will count in the third month after the change and report either way" is a sentence that commits the desk as much as the approver. That commitment is what makes the desk credible the next time. A case with no measure in it is a request. A case with a measure is an experiment. People fund experiments more readily than requests, because an experiment can be stopped.

Doing the Fix Without Making a New Hotspot

A source fix is a change, and changes produce tickets of their own, briefly. That can look like the hotspot getting worse at exactly the moment the desk has promised it will get better. Treat the fix as a change with a record, however light. Record what is being changed, when, who is affected, how it is reversed if it goes wrong, and who was told. The one-page form for that lives in The One-Page Change Record. A hotspot fix is exactly the kind of change it was written for. It is planned, beneficial, and capable of generating forty tickets on a Monday if the badges were not enrolled first.

Pilot where the fix allows it, on one depot, one department or one floor, and count there before rolling out. A pilot answers the question "does the fix remove the tickets" with real tickets rather than a prediction. It turns the one-page case's expected count into a measured one, which strengthens the roll-out conversation enormously. Kestrel changed the north depot's terminal to badge sign-on first. Its PIN tickets went from about six a month to one. The other three depots followed a month later with that number in hand. A pilot also catches the fix that moves the ticket rather than removing it. At one depot, badge sign-on produced a new ticket type, "badge not recognised", because half the badges were an older kind. That was found at one depot and fixed before four.

Tell the people who will feel the change, before it happens, in their words, and keep the symptom fix alive through the transition. The canned PIN reply stayed in use for two months after the badge change, because some drivers kept using PINs. The desk did not want the first week of the fix to be the worst week of the hotspot. Where the fix is an automation, it needs rules for safety. Test it on a few machines, log what it does and never let it do anything destructive. Those rules are in Turning a Fix Into a Script Safely. A scheduled restart at three in the morning is the gentlest automation there is. It still needs a note saying it exists, so that the next technician does not spend a morning hunting a mysterious reboot.

Verifying the Hotspot Cooled

A hotspot has cooled when its rate has fallen to the level of its peers and stayed there for two consecutive periods of the same length as the one that found it. One good month is a good month; two quarters at the peer rate is a fix. Run the same cut that found the hotspot, on the same kind of export, over the same length of period, and read the same line. If the hunt found the terminals at thirty-eight tickets a month over a quarter, the verification is the terminals' line over the next two quarters. Changing the method between before and after is how a desk convinces itself a fix worked when it did not. The simplest defence is to use the saved worksheet from the hunt and fill in the same boxes.

Watch for the symptom moving rather than stopping. Tickets about a fixed source can reappear under a different label when the fix changed the words people use ("badge not working" instead of "PIN reset"). They can also reappear in a different channel. Drivers who used to raise a ticket start phoning the depot supervisor instead, and the supervisor fixes it off the books. Read the after-period tickets by content, not by label, exactly as the hunt did. Ask the supervisors whether the calls have stopped as well as the tickets. A hotspot that has moved into a shadow channel has not cooled; it has gone quiet, which is worse, because now nobody is counting it.

Use a control source, one that was not fixed, to tell the fix's effect from the desk's general weather. Suppose every source on the desk fell by a fifth in the after-period because the organisation shrank or the summer came. The terminals' fall needs a fifth taken off it before the fix is credited. Kestrel's control was the depot printers for other documents, which ran at the same rate before and after, so the whole of the terminals' fall belonged to the fix. If you run QuerySolv, the volume reports give the before-and-after by department without an export. Each ticket's event history says when it was opened and closed. That is enough to rebuild the source's count at ticket level when the question is asked a year later. Whatever the tool, write the result on the card: the before rate, the after rate, the control, and the date it was declared cooled. That line is the record the quarterly review reads, and it is what the desk points to the next time it asks for a decision.

When the Fix Is Refused

Sometimes the owner says no, or says yes and does nothing, and the hotspot stays. Record the decision on the card, with the date and the reason given. Record the cost of leaving it as the hours per year from the case. Then put it on the quarterly review's list as a known, chosen cost, which is what it now is. Report it there plainly: "the sign-on terminals continue to cost eight to sixteen desk hours a month; the badge change was declined in March pending the handset project." That sentence is not a complaint. It is a fact the organisation has decided to live with. It is written where the people who decided it can see it every quarter. That is the mechanism by which refusals get revisited. The review is the subject of The Quarterly Hotspot Review.

Do not punish the requesters for the owner's decision, and do not quietly stop the symptom fixes to make the cost visible. The drivers did not decline the badge change. Keep the tickets fast, keep counting, and let the count do the arguing at the next review. A refused fix with a clean count behind it is approved more often than not within a year. Usually, something else changes: a new manager, a budget round, a bad morning at a depot that the operations manager happened to witness. The desk's job is to have the case ready and the count current when that morning comes. It will.

A Short War Story: The Print Queue at Fairlea Schools Trust

Fairlea Schools Trust ran nine schools from one desk of three. Its largest hotspot for two years was printing: around sixty tickets a month across the schools. The tickets said "printer not responding", "job stuck", and "printing from the staff room takes ten minutes". They were resolved by clearing the print queue on the trust's central print server. A technician called Dana turned that fix into a script. It ran every night and could be triggered from the desk in one click. The ticket count fell by a third in the first quarter. The desk reported the script as the fix, and the report was well received. Over the next year the count crept back, and then past where it had started. Staff had learned that the desk's fix was temporary and had begun phoning the school office instead. There, the business manager cleared the queue herself from a link Dana had given her. The tickets were quieter and the printing was no better. A new desk lead, Elliot, read the printing tickets by content. Elliot found that every slow or stuck job came through the one central print server. It served all nine schools across a thin connection from the trust's office. The fix had never been a queue to clear but a server in the wrong place. A print server at each school, a redesign, took a fortnight. The printing tickets fell to a handful a month and stayed there. The nightly script had cost a year, had hidden the count, and had been reported as a success in four quarterly reports. A symptom fix that works is the most dangerous kind, because it feels exactly like a source fix from the inside.

The Source-Fix Plan

The plan below is the one-page case and the verification on the same sheet, so that the promise and the result sit together. Section A is the hotspot in one line from its card. Section B is the five options asked in order, with a line for each. Writing "retire: no, drivers must sign on" is what proves the cheaper options were considered. Section C is the case in hours, both columns. Section D is the ask, the owner and the decision. Section E is the change and the pilot. Section F is the measure, named before the fix and filled in after. Keep the sheet with the card, and bring both to the quarterly review until the status says cooled.

SOURCE-FIX PLAN — ONE HOTSPOT, ONE PAGE
Hotspot (from card): ______________________________   Card ID: ________
Prepared by: ______________   Date: ____________

A. THE HOTSPOT NOW
   Tickets per month: ______   Ticket types (largest first): ______________ / ______________ / ______________
   Hands-on minutes per ticket (sample of ten): ______ to ______
   Desk hours per year: ______ to ______      Requester hours per year, if known: ______ to ______
   Symptom fixes already in place: ___________________________________________________

B. THE FIVE OPTIONS, ASKED IN ORDER
   Retire    — could the thing go altogether?        ______________________________________
   Redesign  — a decision, setting or process change? ______________________________________
   Automate  — could it fix or fulfil itself?         ______________________________________
   Retrain   — a changed habit, attached to what?     ______________________________________
   Replace   — is the thing itself the source?        ______________________________________
   Chosen (one or a combination): __________________________________________________________
   Ticket types each chosen option removes: ______________ / ______________ / ______________

C. THE CASE IN HOURS                                    LOW (hands-on)    HIGH (loaded)
   Tickets removed per year (expected) .................. ______            ______
   Desk hours freed per year ............................ ______            ______
   Desk hours to make the fix (build, test, roll out) ... ______
   Owner or other team hours to make the fix ............ ______
   Items the budget holder must price ................... ______________________________
   Payback of the desk's hours, LOW column .............. ______ months

D. THE ASK
   Decided by: ______________   The one sentence asked: ____________________________________
   Asked on: ____________   Decision: [ ] yes  [ ] yes with conditions: ______________  [ ] no, because: ______________
   If no: cost of leaving it recorded for the quarterly review on: ____________

E. THE CHANGE
   Change record reference: ________   Planned date: ____________   Reversal if it fails: ______________
   Pilot group: ______________   Pilot result (tickets per month before / after): ______ / ______
   New ticket types seen in the pilot: ___________________________________________________
   People told, how and when: ___________________________________________________________
   Symptom fixes kept during transition until: ____________

F. THE MEASURE (named before the fix)
   Expected tickets per month after: ______   Count on: ____________ and ____________
   Same cut, same period length, same labels? [ ]   Control source: ______________
   Result period 1: ______ per month   Result period 2: ______ per month   Control change: ______
   Tickets moved to another label or channel? ______________________________________________
   Status: [ ] planned  [ ] piloted  [ ] rolled out  [ ] period 1 counted  [ ] cooled on: ____________

Sinead's Thursday meeting lasted fourteen minutes. The operations manager read section A and asked whether badge sign-on would work with the older badges. The manager also said yes to all three lines of section B at that meeting. The north depot pilot answered the question about the older badges a month later. The terminals' count in the third month after rollout was seven, mostly "badge not recognised" from the older badges, which were replaced. The sixth month was four. Arjun kept the PIN canned reply in the library for a year, out of sentiment, and then deleted it. That was the moment the desk agreed the hotspot was dead.

Frequently Asked Questions