Tracking Slowness Tickets as a Signal, Not a Nuisance

Monday, 09:30, at Northgate Retail. Fiona runs a desk of four for head office and twenty-two stores. Since the spring she has had every slowness ticket tagged at close with what was slow and what was found. That was because the first article in this series told her to and she did not quite believe it would be worth the effort. The monthly counts are on her screen: twelve, fourteen, thirteen, nineteen, twenty-four, thirty-one. Every one of the thirty-one was closed, and most were closed with a real fix and a before-and-after timing. Nobody on the desk thinks there is a problem; the queue is healthy and the satisfaction scores are fine. Fiona cuts the thirty-one by the tags. Fourteen are on one laptop model in the stores. Nine are the finance application. Five are at the same store. The other three are scattered. She has been looking at three different problems for six months, one ticket at a time. And each of them has been closed thirty times.

Tracking slowness tickets as a signal means counting them as their own kind. It means tagging each one with what was slow and what was found. It means watching the count over months, and cutting it by model, application, site and team. That way, complaints that were each closed on their own add up to the earliest warning a desk gets. The warning is of a fleet ageing, an application outgrowing its server, data outgrowing its application, or a site's network starting to fail. This article is part of our The Vague Slowness Complaint series. It is the one that makes the other five pay. The general method for reading ticket volume as a warning belongs to Volume as an Early Warning System. The method for finding the hotspot belongs to Finding Hotspots in the Ticket Data. This article applies both to one kind of ticket and does not re-teach them.

It covers why slowness is a leading signal; the tags at close; counting honestly. It then covers the trend and what moves it; the hotspot it reveals; the refresh case it supports, in hours. Next come the honest report line and the twenty minutes a month that does all of this. It ends with a short war story and the slowness report line to copy, in that order.

Why Slowness Is a Leading Signal

An outage ticket tells the desk about something that has already happened; a slowness ticket tells it about something that is about to. The disk that is filling is slow for months before it is full. The database that is outgrowing its server is slow for a year before the morning it stops answering. The laptop fleet that is ageing produces slow-start tickets long before it produces dead-laptop tickets. The access point in the back office is slow at nine every day for a term before the day it drops everyone. Each of those ends in a ticket with the word "down" in it. And each of them sent a dozen tickets with the word "slow" in it first. A leading signal is a measurement that moves before the thing you care about moves. And the slowness count is the cleanest one a help desk owns.

The signal is thrown away by closing each ticket well. That is the uncomfortable part. A desk that measures the slow laptop, clears its disk, times the fix and writes a good resolution note has done everything the first five articles ask. It has produced a closed ticket that nobody will look at again. Fourteen of those, on the same model, in the same month, are a closed ticket each and a fleet decision together. The fleet decision only exists if somebody counts. The individual fix is the desk's job. The count is the desk lead's, and it takes twenty minutes a month once the tags exist.

The cost of not counting is the war story at the end of this article. And the general shape of it is always the same. The slowness tickets rose for months, each one was closed, and the outage that followed was described in the review as "unexpected". It was not unexpected. It was announced, one ticket at a time, by the people who were going to be hurt by it. And the desk had written "fixed" on every announcement. (Reviews are very fond of "unexpected". It is the word for "nobody added up the tickets".)

The Tags at Close: What Was Slow, What Was Found, What Happened

The count only works if slowness tickets can be told apart from the rest and told apart from each other. That takes three tags written at close, by the technician who did the work. Use whatever the tool offers: a category, a tag, a custom field, or a fixed word at the start of the title if the tool offers nothing. The first tag is what was slow, with four values: the computer, an application, the network, or nothing, meaning it was an expectation. The second is what was found, from the short lists in the third and fourth articles of this series. Those lists cover the full disk, the start-up list, memory, the browser, the scan schedule, age, the server, the vendor, the data, the path. The third is what happened: fixed, expectation recorded, put on the refresh list, vendor case raised, data archived, schedule moved, handed to the network owner, or still open.

Keep the lists short and fixed, because a tag that can say anything says nothing when counted. Ten causes and eight outcomes is plenty. A technician who cannot find the right one picks "other" and writes a word in the note. If "other" grows past a handful a month, the list gets a new entry. Resist the urge to make the tags describe the ticket perfectly. They describe it well enough to be counted, which is a different standard, and a lower one.

The last row is the one per-technician figure this article allows, and it is a coaching figure. The share of a technician's slowness tickets that have a baseline timing in the note says whether the habit from the first article has taken, and nothing else. That share is read with the technician, from no fewer than forty or so of their tickets, and never put on a list beside other names. Cutting the slowness count itself by technician tells you who was on shift. That is not a signal about slowness and is not a signal about the technician either.

Counting Honestly

The count is tickets per month with the slowness tag, every one of them. And the honest rules are the ones every count in this library follows. Every walk-up and corridor fix is logged, or the count measures how many people filled in a form rather than how many machines were slow. Duplicates merged into one ticket count once. Several people raising the same slow application are linked to a parent and counted as several. That is because the number of people touched is the signal. Expectation tickets stay in the count with their own tag. A rising count of expectations is a rising count of people whose equipment is no longer good enough for their work. That is a signal of a different kind and the one budget holders most need to see.

Small numbers need the usual care. A desk with twelve slowness tickets a month will see the count move by a third when four extra people have a bad week. A monthly line at that volume is noise with a trend drawn through it. Read quarters, or read the count beside its cuts, where fourteen on one model out of thirty-one is a pattern even when thirty-one itself is not. The general discipline of counting tickets so that two people get the same number belongs to the volume analysis series. The slowness count borrows it whole and adds only the tags.

Count against something. Thirty-one slowness tickets a month means one thing for a desk serving sixty people and another for a desk serving six hundred. It means one thing when the fleet is two hundred laptops and another when it is two thousand. Keep the user count and the device count beside the slowness count in the same sheet. That way, a reader can see "thirty-one of two hundred and forty devices" rather than thirty-one on its own. The share is for the reader; the counts are for the desk. The counts are what the cuts are made from.

The Trend and What Moves It

Fiona's six months, twelve to thirty-one, is a trend. The first question about any trend is whether it is a step or a slope. A step, where the count jumps in one month and stays up, is a change. That could be an update rolled out, a new application, a new site, a new security tool with a nine o'clock scan. A slope, where the count rises a little every month, is growth. That could be data getting bigger, disks filling, a fleet getting a year older every year, an access point serving more handsets than it was planned for. Steps have a date and the date has a change record. Slopes have a cause that nobody scheduled, and the cuts are how you find it.

Seasons move the count too, and the honest trend knows them. Year-end produces report tickets. The month the new intake starts produces expectation tickets from people who came from faster jobs. The summer, when half the building is away, produces almost nothing and makes the autumn look like a crisis. A trend is read against the same month last year where the tags go back that far, and against the quarter where they do not. A desk in its first year of counting writes "first year, no comparison" on the line rather than reading a season as a signal.

The trend that matters is the one in each cut, not the total. Twelve to thirty-one is interesting; "the store laptop model went from four to fourteen while everything else stayed flat" is a decision. The total slowness count is the headline for the report line, and the cuts are the body. And a desk lead who reports only the headline will be asked what is driving it by the first manager who reads it. Have the answer on the same page.

The Hotspot It Reveals

A hotspot is one model, one application, one site or one team that accounts for a share of the tickets out of all proportion to its size. The four cuts find it in minutes once the tags exist. Fiona's thirty-one cut by model gave fourteen on one store laptop, which the stores have about forty of. Cut by application, it gave nine on the finance system, which has a dozen users. Cut by site, it gave five at one store with eight staff. Cut by team, it gave nothing, because the teams follow the models and the applications. Three hotspots, each with its own owner, each with its own next step, and none of them visible in any single ticket.

Each kind of hotspot goes somewhere different. The model that keeps appearing goes to the device hotspot method in Device and Model Hotspots. That method decides whether the model is a lemon, is simply old, or has a fixable common cause such as a scan schedule or a small disk. For slowness the usual answer is old or small-disked, and the usual next step is the refresh case below. The application that keeps appearing goes to its owner with the evidence sheet from the fourth article and the count of people touched. That is the number that moves a vendor conversation from "we'll look into it" to a date. The site that keeps appearing goes to the slow-internet series. That is because a site that is slow for everyone is a network branch, and the isolation and measurement there are what prove it.

The cut by "what was found" is the fourth hotspot, and it is the one that produces a sweep rather than a purchase. If eleven of the month's slow computers had full disks, a monthly free-space sweep across the fleet stops most of next month's tickets before they are written. The proactive remediation series has the sweep. If seven had a scan scheduled at nine, one conversation with the security tool's owner moves it for the whole fleet. The count tells the desk which class of ticket to prevent next, in the order that would remove the most, which is the only honest way to pick.

The Refresh Case It Supports

The refresh case is the argument that a set of machines should be replaced. And the slowness count makes it in hours, which is the currency a budget holder can check. Fourteen tickets a month on forty machines of one model is the starting fact. Each ticket costs the desk somewhere between one and two hours, measuring, clearing and writing. That is fourteen to twenty-eight desk hours a month on that model. Each slow machine costs its user time every day whether or not they raise a ticket. If the start-up and the application opening cost ten to fifteen minutes a day beyond what a current machine takes, that is three to five hours a month per user. In that case, across forty users it is a hundred and twenty to two hundred hours a month of people waiting for a screen. Those are Fiona's figures from her tagged tickets and her timings, stated as ranges because the timings vary. And a different desk will have different ones.

Put the hours beside what the fix removes. Replacing the forty machines removes most of the fourteen tickets and most of the waiting. The case is the hours saved over the machines' expected life against the hours and money of the replacement, which the budget holder can price and the desk should not. The desk's contribution is the count, the timings and the hours, laid out so that a reader can check each step. The discipline for laying them out, with the pushback anticipated, is in Evidence Over Anecdote. A refresh case built on "the stores keep complaining" gets a sympathetic nod and no budget. The same case built on fourteen tickets, forty machines and a hundred and fifty hours a month gets a question about the hours. That is the right question and one the desk can answer.

The expectation tickets are part of this case, not an embarrassment to be left out of it. A machine that is slow because it is old and matches its twin is an expectation on the day and a line in the refresh case at the end of the month. A desk that closes expectation tickets quietly, because they feel like admitting the equipment is not good enough, has hidden the strongest evidence it had. Count them, tag them, and put their number beside the defects. The budget holder is not embarrassed by old machines. They bought them.

The Honest Report Line

The slowness signal reaches leadership as one line in the monthly report. The line has five parts. It gives the count with its trend and the top hotspot in plain words. It says what the desk did about it, what the desk is asking for, and what it will report next month. "Slowness tickets: 31 this month, up from 12 in the spring; 14 of them on the store laptop model, which is five years old; disks cleared and scan schedule moved, which will reduce the count but not remove it; asking for the refresh of 40 machines to be brought forward, case attached; next month's line will show whether the schedule change held." One line, five parts, a number in each. The format of the report it sits in and the rule that every number comes with the counts behind it belong to The Monthly Report They Will Read. The slowness line is one of the few in that report that predicts rather than describes, and it should say so.

Never write "users are complaining more". It is true. It is what the count measures. And it is the sentence that makes a reader hear "the desk is losing control" rather than "the fleet is ageing". The line reports a signal about equipment, applications and sites. And the words in it are the names of those things, with the count beside them. Equally, never leave out a bad number. A slowness count that has doubled and a line that says "performance tickets stable" will be found out by the first director who asks their own team. And the desk's next six report lines will be read as fiction.

When the number is bad because the desk has only just started counting, say that. "First month with slowness tagged; 31 tickets; no trend yet; the cuts are below" is an honest line and a credible one. The reader who sees it in month one will believe the trend in month six. The temptation in month one is to leave the line out until the numbers look better. The numbers will not look better, because the fleet is not getting younger, and the line will be harder to introduce at forty than at thirty-one.

The Twenty Minutes a Month

The whole routine is twenty minutes on the first working day after month end, and it goes in a fixed order. Filter the month's closed tickets to the slowness tag and write the count beside last month's and the same month last year's. Read the three tags across the set and note the largest value of each. Cut by model, application, site and team, and write the top one of each with its count. Read the open ones, the vendor cases and the handoffs, and note which have moved. Link any new tickets on an existing hotspot to its parent. Write the report line. If you run QuerySolv, the standard reports on volume give the monthly count once slowness tickets can be told apart from the rest. In that case, linked tickets under one parent turn a hotspot into a list rather than a search. In any tool, the twenty minutes is mostly reading, and the tags are what make it twenty rather than two hours.

Once a quarter, add ten minutes and re-time the known-slow list. That is because an expectation that has drifted is a defect nobody reported. The quarterly re-timing is the only way it gets found. Put the drifted items into the count for the quarter as defects with the cause "drift". And watch whether the same application or model keeps appearing there. A known-slow list that is never re-timed becomes a list of things the desk has agreed not to look at.

A Short War Story: The Monday the Records Stopped at Wexford Dental

At Wexford Dental, a group of eleven practices served by a desk of two, a technician called Callum closed slowness tickets about the practice management system for eight months. Each one was measured. Each one ended with a restart of the user's machine or a cleared cache and the honest note "fine now, could not reproduce". The count, which nobody kept, went from two a month to nineteen. The system's database lived on a server at head office whose disk had been filling as the patient records, the images and the appointment history grew. The server had been swapping to that nearly full disk for most of the eight months. That was why every practice saw the records open slowly at the busiest times and quickly in the afternoon when Callum came to look. On a Monday morning in the ninth month the disk filled completely and the database stopped. Eleven practices could not open a patient record for four hours while the server was rescued. At about fourteen staff per practice, that is in the region of six hundred staff hours, plus the appointments that were cancelled and rebooked by hand. The review called the outage unexpected. Callum, who had the nineteen tickets in front of him by then, did not argue. That was because he had closed every one. The desk started tagging slowness tickets the following week. And the count has since caught two more filling disks before anyone said the word "down". A rising slowness count is an outage that has not happened yet, and it will keep saying so for as long as somebody is listening.

The Slowness Report Line

The sheet below has two parts. The monthly block is the twenty minutes. It covers the count with its comparisons, the three tags' largest values, the four cuts, the open items and the one-line report. These are filled in the same order every month so that the sheets can be read side by side a year later. The quarterly block is the known-slow re-timing and the refresh case summary in hours. The report line at the bottom of the monthly block is the one sentence that leaves the desk. Everything above it is the evidence for the first manager who asks what is driving it.

SLOWNESS SIGNAL — MONTHLY SHEET AND REPORT LINE
Desk: ______________   Month: ________   Users served: ____   Devices in fleet: ____   Filled in by: ______

A. THE COUNT
   Slowness tickets closed this month: ____   last month: ____   same month last year: ____ / first year
   Of which: computer ____   application ____   network ____   expectation ____   still open ____
   Walk-ups logged this month: ____   Linked to an existing parent: ____

B. WHAT WAS FOUND (largest first)
   1. ______________ ____     2. ______________ ____     3. ______________ ____     other ____

C. WHAT HAPPENED
   Fixed ____   expectation recorded ____   refresh list ____   vendor case ____   data archived ____
   schedule moved ____   handed to network ____   open ____

D. THE FOUR CUTS (top one of each, with its count and its size)
   Model: ______________ ____ tickets of ____ machines      Owner / next step: ______________
   Application: ______________ ____ tickets of ____ users   Owner / next step: ______________
   Site: ______________ ____ tickets of ____ staff          Owner / next step: ______________
   Team: ______________ ____ tickets of ____ people         Owner / next step: ______________

E. OPEN ITEMS CARRIED
   Vendor cases: ____ (oldest raised ________)   Network handoffs: ____   Refresh list additions: ____

F. THE REPORT LINE (one sentence, five parts)
   "Slowness tickets: ____ this month, [up / down / flat] from ____;
    ____ of them on ______________ [model / application / site];
    the desk has ______________;
    asking for ______________;
    next month's line will show ______________."

QUARTERLY BLOCK
   Known-slow list re-timed on ________: items ____   drifted ____   moved to defects as "drift": ____
   Refresh case: ____ tickets a quarter on ____ machines of ______________;
     desk hours per ticket ____ to ____ ;  user hours per machine per month ____ to ____ ;
     total hours a month in the range ____ to ____ ;  case sent to ______________ on ________
   Baseline recorded on slowness tickets: ____ of ____ (desk-wide; per-technician figures are coaching only,
     read from forty or more tickets, never ranked)

Fiona's sheet for the month had fourteen in the model row, nine in the application row and five in the site row. It had three report lines' worth of evidence under one sentence. The store laptop refresh was brought forward by two quarters on the strength of a hundred and fifty hours a month that nobody had previously added up. The finance application's vendor got an evidence sheet with the count of twelve users on it and, for the first time, a date. The store with five tickets got a visit from the network contractor, who found an access point doing the work of three. The slowness count the following month was nineteen. The month after, eleven. Nobody on the desk had done anything differently on any single ticket. They had just started counting them together.

Frequently Asked Questions