Finding the Ticket Patterns Worth Preventing First

Thursday, 16:10, at Ashgrove Housing. Nadia runs a desk of three for about 260 staff, a third of them repairs officers who spend the day in tenants' homes with a tablet. On her screen is last quarter's audit sheet, and section C of it names nine causes behind the preventable tickets. On Monday, for the first time, each technician has an hour in the calendar that the queue is not allowed to take. Hal wants to spend it on the housing system's month-end report, which times out for forty people in the last three days of every month. It is the biggest line on the sheet. Bea wants the depot printer, which jams every Tuesday and which she is fairly sure has worn rollers. They are both right about something. Nadia has until Monday to decide which something.

A prevention candidate is a named cause with four things written beside it. They are how many tickets a month it produces, how many hours those tickets cost, what it would cost to remove, and who can remove it. The audit in the first article of this series produces the names and the counts. This article is about the other two columns, and about choosing. This article is part of our From Reactive to Proactive Support series. It is the one that stands between a list of nine causes and a Monday morning with one hour in it.

It covers the three places patterns hide, which are the repeat categories, the hotspots and the problem records. Each is already taught elsewhere in this library and linked rather than rebuilt. Then come why a category is not a cause, and cheap-to-prevent against costly-to-prevent, which is the sum that decides the order. Next are the top-five list Ashgrove built and what it chose first, and what never to pick first. It ends with a short war story and the prevention candidates list to copy, in that order.

Three Places the Patterns Hide

Patterns worth preventing show up in three views of the same tickets, and a desk that looks in only one of them finds only one kind. The first view is the repeat category: the monthly count of tickets by type, which says what the desk is doing most. The second is the hotspot: a cut across categories by device, application, location or group. It says where and to whom the tickets are happening, and often reveals a cause the categories were hiding. The third is the problem record: a cause the desk has already noticed, named and written down, with the tickets it explains linked to it. Each of these has its own series in this library, and the method for each lives there. The job here is to say what each view contributes to the candidates list, and to go and collect it.

The three views overlap, and the overlap is where the best candidates are. A category that is large, a hotspot that explains most of it, and a problem record that already names the cause is a candidate with its homework done. A category that is large with no hotspot behind it and no problem record is probably several causes wearing one label. It needs reading before it can be a candidate at all. Collect all three views before choosing, which takes an afternoon for a desk of three, and resist the urge to pick from the first view alone. The category report is the easiest to pull and the least honest about causes, which is an unfortunate combination.

The Repeat Categories, and Why a Category Is Not a Cause

The category report is where every desk starts, and it is a good start as long as nobody mistakes a category for a cause. "Lockouts" at Ashgrove was fifty-one tickets a month, which looked like one candidate. Read, it was three. Twenty-six were field tablets retrying an old password after a change. Fourteen were people mistyping after the holidays. Eleven were a mixture of forgotten passwords and one person who locked themselves out on purpose every Friday. He did that so the desk would log him off a shared machine (he had his reasons; they were not good ones). Only the first of the three is a cause the desk could remove. The category report said fifty-one. The candidate was twenty-six.

Read the tickets behind any category you are considering, a month's worth, and tally the causes as you go. This is the method in finding the repeat tickets. It is the single most valuable afternoon in the whole programme, because a candidates list built from unread categories is a list of labels. The tally does not need to be elegant: a sheet with the ticket number, the cause in six words, and a tick. By the fortieth ticket the causes have names and the names have counts. The counts are usually not the ones the category report implied. Categories are kept for routing and reporting; they were never designed to explain anything.

Sort the read categories by hours, not by count, before the next step. A ticket type that arrives sixty times a month at five minutes each is five hours. One that arrives twelve times at an hour and a quarter is fifteen. Both are worth preventing. Only one of them is the biggest line, and it is not the one the count says. Take the hands-on time from a sample of ten real tickets of each type, the way the ROI series does it. Write the hours beside the count. Hours are what prevention is bought with, so hours are what it has to be measured against.

Hotspots: The Cut That Finds the Cause Behind the Label

A hotspot is the device, application, location, process or group behind an outsized share of tickets. The cut that finds it is in finding hotspots in the ticket data. Where the category view says "printing, thirty-eight a month", the hotspot view says "the depot printer, twelve a month, every Tuesday". That second sentence is a candidate where the first was a department. Hotspots are how the desk finds the one laptop model with the failing dock, and the one site with the damp paper store. They also find the one team whose new system nobody trained them on. A category rarely points at a cause. A hotspot usually does.

Run the four cuts that cost nothing: by device model, by application, by location, and by requester group. Most desks can do all four from a spreadsheet export in an hour. The method does not need a pivot table if the words "sort and count" are available to you. At Ashgrove the location cut found the depot printer, and the application cut found the housing system's month-end timeout. The group cut found that every new starter in lettings raised the same shared-mailbox ticket in their first week. Nobody had noticed because the tickets were nine a month and spread across three categories. Three of the eventual top five came out of the cuts and not the category report.

Carry the hotspot's evidence into the candidate line as it stands, because the same evidence will be needed later for the owner conversation. "Forty tickets a month, all in the last three working days, all from finance and lettings, all the same report" is a sentence that an application owner can act on. The way to have that conversation is in application and process hotspots. The candidates list does not need to repeat the method; it needs the sentence.

The Problem Record: Causes Already Named

A problem record is a cause the desk has already noticed and written down, and the problem list is the candidates list half-finished. The idea, with the "we have fixed this five times" test that starts one, is in problems vs incidents. A desk that has been running the weekly problem hour has a list of five to ten causes with an owner and a linked-ticket count on each. Those go straight onto the candidates list with their counts. The proactive programme is, in a real sense, the problem list with a time budget attached. If the desk has no problem list, the audit's section C is the first draft of one. In that case, the two lists should become the same document rather than two. If you run QuerySolv, the tickets that share a cause can be linked to one another. That way, the count on each line stays honest without a search. In any tool, a fixed form of words in the note does the same job.

The known-error records are the preparation already done, and they belong on the list for a different reason. A known error with a published workaround is a cause the desk has stopped suffering but not stopped paying for. The running count of linked tickets is the evidence that the permanent fix is still owed. At Ashgrove the tablet photo-sync known error had a one-minute workaround and forty-one linked tickets. That is forty-one minutes a month plus forty-one interruptions. The known error had been comfortable for so long that nobody had thought of it as a candidate. The candidates list is where comfortable known errors go to be reconsidered.

Where the cause is still a guess, it is a problem record, not yet a candidate. "The month-end report times out; we think it is the query" is an investigation with a name. Its next step is root cause analysis, not a prevention hour spent fixing something that might not be the cause. Put it on the list and mark the cause column "suspected". Let the problem hour do its job before the prevention hour spends anything on it. A fix applied to a suspected cause is an experiment, and experiments go in the problem record, where their results can be read later.

Cheap to Prevent, Costly to Prevent

The sum that decides the order is the hours to remove the cause against the hours the cause costs each month. The ratio between them is the payback: how many months the fix takes to repay itself. The depot printer cost Ashgrove about nine technician hours a month, counting the walk to the depot. Removing the cause means a service visit for the rollers and moving the paper store away from the loading-bay door. That would take about two technician hours and one phone call. Payback: a quarter of a month. The month-end timeout cost about twenty-four hours a month. Removing it would take a root cause investigation nobody had yet done, then a conversation with a supplier. Then it would possibly take a change to a report that finance had written and was fond of. Payback: unknown, divided by a number of meetings. Both are worth doing. Only one of them can be done on Monday.

Two more columns decide the order alongside payback, and they are the owner and the certainty. The owner is who has to act to remove the cause. It is the desk alone, the desk with another team's help, or someone outside the desk entirely, such as a supplier or an application owner. The certainty is whether the cause is known or suspected, and whether the fix is known or guessed. A candidate the desk owns, with a known cause and a known fix, can be removed in the next prevention hour. A candidate owned elsewhere, with a suspected cause, needs evidence, persuasion and probably a change window. Its hours will be spent in meetings before they are spent on the fix. Both kinds belong on the list. The columns are there so the list can tell the difference.

Partial prevention counts, and should be written down as partial. The VPN self-check guide at Ashgrove was expected to remove about half the field "can't connect" tickets. That was the half that were hotel and café captive portals, and not the other half. A candidate line that says "eighteen a month, expect to remove nine" is honest and still worth five hours. A line that says "eighteen a month" and later removes nine will be read as a failure by anyone who only saw the first number. The prevention hour has enough enemies without manufacturing one.

The Top-Five List at Ashgrove, and What They Chose First

Nadia's list, built on the Thursday from the audit, the four cuts and the problem list, had five lines on it. The picture of the five is worth reading in full because it is the shape most small desks will recognise. The month-end report timeout: about forty tickets and twenty-four hours a month, cause suspected, owner the supplier and finance, cost to remove unknown. The field tablet lockouts after a password change cost twenty-six tickets and eight hours. The cause was known (the tablet's mail application keeps retrying the old password, the pattern described in the lockout that keeps coming back). The fix was known (a line in every reset reply telling the user to update the tablet first, and a one-time sweep of the tablets). The owner was the desk, and the cost about three hours. The depot printer: twelve tickets and nine hours, cause known, fix known, owner the desk and facilities, cost two hours and a service call. The lettings shared mailbox for every new starter cost nine tickets and four and a half hours. The cause was a missing line on the onboarding form, and the fix was a role profile. The owner was the desk and the lettings manager, and the cost two hours. The field VPN connections: eighteen tickets and nine hours, half of them removable with a self-check guide, owner the desk, cost about five hours.

They chose the printer and the tablets first, and the reason is the point of this article. Both were cheap, both belonged to the desk, and both had a known cause and a known fix. Between them they would remove about thirty-eight tickets and seventeen hours a month for five hours of work and a service call. That is a result the desk could have inside a month and show at the next review. A programme that has shown one result is a programme that keeps its hour. The month-end timeout, three times bigger, went on the list with its forty tickets a month, a problem record, an owner and a next step. It stayed there, gathering evidence. Hal, who had wanted it first, was given it to own. He later described that as having been handed the interesting one and the slow one in the same sentence.

The second month's picks were the shared mailbox and the VPN guide. By the end of the quarter four of the five lines had moved. The fifth had a root cause investigation with a timeline, and a count that had grown to a hundred and twenty tickets across three months. It had a meeting booked with the supplier at which the count did most of the talking. That is what a costly, elsewhere, suspected candidate is supposed to look like after a quarter: not fixed, but no longer a complaint. The loop that turns a list like this into a monthly habit is the fifth article in this series, the proactive loop. The list is its input.

What Never to Pick First

Do not pick the biggest line first, however loudly it argues for itself. The biggest line is usually big because it is hard, and hard means slow. Slow means the first quarter of the programme ends with nothing removed and a manager wondering what the hours were for. The biggest line goes on the list, gets an owner and a problem record, and is worked at the problem hour's pace while the prevention hour removes things. Its turn comes when the cause is proved and the fix is known. By then the desk has three results behind it and the standing to ask for a change window.

Do not pick the most annoying one, the political one, or the one that needs a budget. The most annoying ticket is annoying to the desk, which is not the same as costly to the organisation. A candidates list sorted by irritation is a list of grudges with counts. The political one, the cause that belongs to a department that has already said no, needs an ally before it needs an hour. An ally is earned by results elsewhere. The one that needs a budget is a case to be made. The case is the tooling case or the headcount case in another series, with the candidate's count as its evidence. A prevention hour spent on something that then waits six months for approval is an hour that produced a document.

And do not pick anything whose cause is still a guess, which was said above and bears saying twice, because it is the mistake I have made most often. A fix applied to a guessed cause removes the tickets about a third of the time, in my experience. The other two thirds the tickets continue and the hour looks wasted. The real cause is then hiding behind a fix that somebody is proud of. The problem hour exists to turn guesses into causes. Let it.

A Short War Story: The Wrong First Pick at Stonebridge Insurance

Stonebridge Insurance gave its desk of four a protected hour a week each. Hugo, who ran the desk, chose as the first candidate the claims application's slowness. At sixty tickets a month it was the biggest line on the list by a distance and the one the claims director mentioned at every meeting. The cause was suspected and not proved, the application belonged to a supplier, and the fix, if there was one, would need the supplier's release schedule. Hugo spent the quarter's prevention hours, about fifty between the four of them, in meetings with the application owner, calls with the supplier, and writing. The writing was a case that was read and admired and not acted on. At the end of the quarter the claims tickets were sixty-two a month. The second line on the list, dock firmware on one laptop model, twenty tickets a month and an afternoon's work, had sat untouched for thirteen weeks. At the review the operations director, looking at a programme that had cost fifty hours and removed nothing, withdrew the hour. The desk went back to the queue for a year. The first pick's job is to prove the loop works, and Hugo had picked the one candidate that could not do it in a quarter.

The Prevention Candidates List

The list below is one page, five to ten lines, rebuilt each quarter from the audit, the cuts and the problem list. It is read at the monthly loop. The columns are the ones this article argued for. They include the count, the hours, the cause and whether it is known, and the fix and whether it is known. They include the owner, the cost to remove, the payback, and the honest expected result where prevention will only be partial. The last section is the decision, with the reason written down so that the next review can judge whether the reason was a good one. Keep the superseded lists. The line that moved from "suspected" to "known" to "removed" across three of them is the story the programme tells leadership.

PREVENTION CANDIDATES LIST — ONE PAGE, ONE QUARTER
Desk: ______________________   Quarter: ____________   Built by: ______________   From: audit / cuts / problem list

A. THE CANDIDATES (largest hours first)
   #  Cause (named, not a category)        Tickets/mo  Hours/mo  Cause known?  Fix known?  Owner        Cost to remove (h)  Payback (mo)  Expect to remove
   1  _____________________________________  ______     ______    yes / susp    yes / no    __________   ______              ______        ____ of ____
   2  _____________________________________  ______     ______    yes / susp    yes / no    __________   ______              ______        ____ of ____
   3  _____________________________________  ______     ______    yes / susp    yes / no    __________   ______              ______        ____ of ____
   4  _____________________________________  ______     ______    yes / susp    yes / no    __________   ______              ______        ____ of ____
   5  _____________________________________  ______     ______    yes / susp    yes / no    __________   ______              ______        ____ of ____

B. WHERE EACH ONE CAME FROM
   Category read (a month of tickets tallied by cause): lines ______
   Hotspot cut (device / application / location / group): lines ______
   Problem record or known error already open: lines ______  (problem IDs: ______________)

C. THE DECISION FOR THIS MONTH
   First pick: line ____   because: cheap / owned by the desk / cause known / fix known
   Second pick: line ____  because: __________________________________________________
   Parked with a problem record and an owner: lines ____  next step: ______________________
   Not a candidate yet (cause suspected): lines ____  investigation owner: ______________

D. BEFORE THIS LEAVES THE DESK
   [ ] Every line names a cause, not a category
   [ ] Hours are from a sample of real tickets, not the count times a guess
   [ ] "Cause known" means proved, not likely
   [ ] The first pick could be finished inside the month's prevention hours
   [ ] Partial prevention is written as "____ of ____", not as the whole count
   [ ] The biggest line has an owner and a problem record, whether or not it was picked

Nadia filled hers in on the Thursday evening, with the printer on line three and the tablets on line two circled as the first two picks. Hal's name was against line one with "RCA by end of month" as its next step. On Monday at nine, Bea rang the printer supplier. The depot has not raised a Tuesday ticket since.

Frequently Asked Questions