Measuring Add-Ons and What They Reveal About the Desk

Friday, 15:10, at Penrose Architects. Hannah runs a desk of three for a practice of about a hundred and forty people across two floors and a model workshop. Two months ago she asked her technicians to capture every add-on at every visit. They were to put the words "desk-side add-on" and the visit's ticket number in the first line. She has just searched for the phrase. There are 140 of them, from 96 visits. She has them in a spreadsheet with the requester, the floor, the date, the first line and whether each one is still open. She had expected a list of monitors. What she has is a list of forty-one questions about where things are saved and nineteen requests from the same eleven people. There is a model workshop that has reported nothing through the queue in a year and produced a quarter of the add-ons. There are sixty tickets that are still open, most of them older than a month. None of this was visible in June. All of it was happening in June.

Measuring add-ons means counting the requests captured at desk-side visits as a group. Cut them by visit, by kind, by place and by person. Read the cuts for what they say about the desk and the building rather than about the technicians who logged them. It is the payoff for the thirty seconds the second article in our While You're Here series asked for at every visit. It is the article in the series with the most surprises in it. Add-ons are the part of the desk's work that was never in any report until somebody started writing them down.

It covers what to count and how the tickets are found, then add-ons per visit and what the number means. Next come the four kinds they fall into and what each reveals, the backlog they create, and the users who always have one. Then come done-on-the-spot against captured and the honest report line. A short war story and the add-on report line to copy finish the article, in that order.

What to Count, and How the Tickets Are Found

Three counts are needed and all three come from the ticketing tool. They are desk-side visits in the period, add-ons captured at those visits, and add-ons done on the spot and logged afterwards. The visits are the tickets with a visit booked in the period, which the calendar entry and the ticket note both record. The add-ons are the tickets with the convention in the first line, "desk-side add-on" or "done at visit", plus the visit's number. A search for the phrase returns them in any tool that can search ticket text, which is nearly all of them. The visit number is what lets the add-ons be counted per visit rather than just in total. A desk that skipped the number at capture time will have the total and nothing else.

Export the add-ons with a few columns: ticket number, visit number, requester, location, date, the first line, whether it is still open, and the category if triage set one. Then count like a desk that expects to be asked how it counted. Write the rules once on a sheet and apply them the same way every month. That is the discipline Counting Tickets Properly lays out for every ticket count. Add-ons need it more than most, because they are small, numerous and easy to lose. Decide whether a proxy request counts against the visit it was mentioned at or the requester's own desk. Decide whether the done-on-the-spot ones are in the add-on total or beside it. Decide whether a desk-raised fault the technician noticed is an add-on at all. Any answer is fine. The same answer every month is what matters.

Count after the month ends, not during it, and be honest that the first month is a floor rather than a measurement. In the first month of capture the technicians were still learning the habit. Some add-ons were still being done on the spot and forgotten, and the count is lower than the truth. Hannah's two months show 140; a third month will probably show more, not because add-ons increased but because the capture did. Say so in the report. A number that rises because the measuring got better is a good number with a confusing shape, and the confusion is removed by one sentence.

Add-Ons per Visit, and What the Number Means

Add-ons per visit is the add-on count divided by the visit count. At Penrose it is 140 over 96, which is a little under one and a half. The number is read for its direction and its spread more than its value, and the direction has two phases that look opposite and are both good. Early on, a rising number means the capture habit is taking hold. Add-ons that used to be done quietly or forgotten are becoming tickets, and the desk is seeing work it always did. Later, a falling number means users have learned that the queue works and are raising things through it before the visit. That is the outcome the whole series is aiming at. A desk that sees the number rise for three months and then drift down for six has done this right.

A very low number from the start is the one to worry about, because it almost never means the users have nothing to ask. It means the add-ons are not being captured: they are being done on the spot and not logged, or remembered and lost. One technician's visits may show no add-ons at all over a month, while two colleagues show one and a half per visit. That is a conversation about the capture habit, held kindly, with the first article in this series as the reading. It is not a performance finding. The technician with zero is very likely the one being most helpful at the desk, which is exactly the problem.

Cut the number by place before cutting it by anything else. Penrose's two floors show about one add-on per visit; the model workshop shows nearly four, from a handful of visits. That difference is the single most useful thing in the spreadsheet. A location with a high add-on rate is a location where the queue is not reaching people. They do not use the portal, or they do not know the desk's address. Or the kit there is in a state nobody has reported because everybody assumes somebody has. Hannah had never had a ticket from the model workshop that was not a printer. The workshop had not been fine. It had been waiting for someone to walk in.

The Four Kinds, and What Each Reveals

Add-ons fall into four kinds. The first article in this series named three of them: the saved-up fault, the how-do-I, and the proxy request for a colleague. Measurement adds a fourth: the fault the technician noticed and the user did not mention. Each kind reveals something different and each points at a different series in this library. That is why the cut by kind is worth the ten minutes it takes to read 140 first lines and mark each one. The table below gives the four, what a high count of each one is telling the desk, and where the answer lives.

The how-do-I pile is the one to read first, because it is the cheapest to act on. Forty-one of Penrose's 140 add-ons were questions, and nineteen of those were the same four questions in different words. That means four knowledge base articles would have answered nineteen visits' worth of "while you're here" before it was asked. What deflection is, and the difference between a question answered before it becomes a ticket and a question that was never asked at all, is the subject of What Deflection Means. The add-on pile is the best list of candidates most desks will ever get. Every one of them was asked out loud, in the user's own words, to a technician who wrote it down.

The saved-up faults are read by place and by model. That is the hotspot hunt from Finding Hotspots in the Ticket Data run on a set of tickets that the ordinary hunt never sees. That is because they were never raised. Six "monitor goes black sometimes" from one floor is six add-ons in the spreadsheet and one question about that floor's docking stations in the problem list. The ordinary ticket data would have shown none of them, since none of the six users thought "sometimes" was worth a form. The add-on count is where the desk finds out what people have been putting up with.

The Backlog They Create

Add-ons create a backlog, and it is worth saying plainly before someone uses it as an argument against capturing them. Most add-ons are low priority by any honest triage; the monitor that goes black sometimes is below the monitor that does not work at all. So they wait, and they age, and sixty of Penrose's 140 are open at the end of two months, forty of them older than thirty days. On the aging report they look like neglect. They are not neglect. They are work that used to be invisible and is now visible and waiting, which is better than invisible and forgotten. The aging report is doing its job by showing them.

Work the add-on backlog in batches rather than one at a time, because add-ons cluster. The nineteen how-do-I tickets that are four questions close together, with a link to the article that answers them, in an afternoon. The six "sometimes" monitors become one problem record and six tickets linked to it, which wait on the problem rather than on six separate diagnoses. The proxy requests are checked with their requesters, and some will say "it's fine now", which closes them honestly. A backlog of add-ons shrinks faster than a backlog of anything else, because so much of it is the same thing said by different people. If you run QuerySolv, the backlog-by-age report shows the add-ons ageing alongside everything else once they carry the phrase. That is the point: they are ordinary tickets, and they are counted as such.

Do not let the backlog become evidence against the habit. The argument "we logged all these and now the aging report looks terrible" is the argument that the desk looked better when it was not counting. It is true and beside the point. The aging report looked better because the sixty tickets were in people's heads and in the corridor, where no report could see them and no one was going to work them either. The honest reply to the argument is that the backlog is the measurement working and that it will shrink in batches. The number to watch is how many of this month's add-ons are still open next month, not how many exist.

The Users Who Always Have One

Some requesters appear again and again. At Penrose eleven people account for forty-eight of the 140 add-ons, which is the kind of finding that invites a wrong conclusion. The wrong conclusion is that these are difficult users who waste technicians' time. In my experience they are almost never that. They are the people whose kit is in the worst state, whose role depends on something nobody else uses, or who were never shown the portal. Or they sit on a floor where the technician's visit is the only contact with the desk anyone has ever had. Three of Hannah's eleven work in the model workshop. Two are new starters who were handed a laptop and a desk and nothing else. One has a specialist plotter that fails in a new way each month.

The response to a frequent add-on requester is a visit with "anything else?" and the portal walked through once, kindly, followed by watching whether their next request comes through the queue. For the model workshop it was a visit with the form open and a notice on the wall with the desk's address. For the new starters it was a question for the onboarding checklist, which had no line about showing people where to ask for help. For the plotter it was a problem record and a conversation with the vendor. None of it was a word with anybody's manager, and none of it needed one. The pattern of requests per person, and how to read it without turning it into a list of names, is in Per-Department and Per-User Patterns. The add-on version follows the same rule: the person is the signpost, the thing they point at is the finding.

Keep the per-person cut inside the desk and off the slide. A report line that says "eleven people generate a third of our add-ons" will be read, by someone, as a list of eleven people. The next thing that happens is a manager asking who they are. The honest version is "a third of add-ons come from the model workshop and from new starters in their first month, and here is what we changed". That names a place and a process and nobody. The eleven are a lead. Leads are for the desk, and findings are for the report.

Done on the Spot Against Captured

The add-ons that were done on the spot under the two-minute rule are read separately, because they answer a different question: was the rule applied honestly? Count them, and then count how many were followed by a second ticket about the same thing from the same requester within a fortnight. A done-at-visit ticket that came back was not a two-minute fix; it was a guess that held for a week. A desk where a third of them come back has a rule that is being read as "probably two minutes". The two-minute rule article earlier in this series is the reading for that conversation, and the conversation is with the desk, about the rule, not with a technician about their guesses.

The done-on-the-spot pile also holds the best self-service candidates the desk has. A fix that genuinely took ninety seconds at the user's desk, with the user watching, is a fix many users could do themselves given the same ninety seconds of instruction. The knowledge base article that gives it to them is short because the fix was. Default printers, shortcuts, the setting three clicks away: each one done at a visit is a small article waiting to be written. The add-on count is where the desk finds out which ones are asked for often enough to be worth it.

Per-technician cuts of either pile follow the rule that applies to every per-person number in this library. They are for coaching, never for ranking. They are not read at all until the technician has enough visits behind them for the number to mean something. On a small desk that is a month or two rather than a week. A technician with many done-on-the-spot tickets is probably being generous with the rule and should be shown the flow from the two-minute article. One with none may be capturing everything, or doing things on the spot and not logging them. The only way to know is to ask. If you run QuerySolv, the per-technician reports exist for exactly that conversation, held one to one. A desk that turns them into a league table has stopped measuring and started supervising.

The Honest Report Line

The add-ons earn one line in the monthly report. The line has five parts: visits, add-ons per visit, the hours they represent, the one finding that matters this month, and what the desk did or will do about it. Hours are the currency. An executive reading "140 add-ons" has no idea whether that is a lot. An executive reading "about thirty-five hours of work we were doing and not counting, most of it answering four questions" knows exactly what it is. The thirty-five is Penrose's 140 at an average of fifteen minutes. It is a worked example and should be presented as one, with a range, since add-ons vary from ninety seconds to most of an hour.

The line is honest about what the number is. It does not claim the thirty-five hours were saved, because they were not; the work was done, later, in the queue, with a note. It does not claim the add-ons were new work, because they were old work made visible. And it does not promise that the number will fall, because the next month's may rise as capture improves, and the line that promised otherwise will be quoted back. What it claims is that the desk found work it had not been counting, understood what most of it was, and changed something. Four articles were written, one floor was given a notice and a visit, and one problem record was opened. The shape of a monthly report that leadership will read, and the discipline of one finding and one action per line, belongs to The Monthly Report They Will Read. The add-on line is one of its shorter and more interesting entries.

Over a year the line tells a story that no other line in the report does, which is the story of the building learning to use the queue. Add-ons per visit rise, then fall. The how-do-I share falls as the articles are written. The model workshop's rate drops to match the floors. The open-at-thirty-days count shrinks as the batches are worked. None of that is a technician being faster. All of it is a desk that found out what people had been putting up with and stopped making them wait for a visit to say so. (It is also, quietly, the best argument for the thirty seconds that anyone will ever put in front of a technician who thinks logging is paperwork.)

A Short War Story: The Proofing Screens at Calder Print

At Calder Print, the desk lead, Lorne, began counting add-ons mainly to settle an argument with a technician. The technician said capturing them was pointless because "it's always the same stuff". After one quarter the count showed that the technician was right in a way neither of them had expected. Thirty-eight of the quarter's add-ons were the same request, "the proofing screen looks wrong", from the four shared workstations on the pre-press floor. Each one was fixed on the spot in a few minutes by re-running the colour calibration. Each one was back within a fortnight. Nobody on pre-press had ever raised a ticket for it, because the fix was quick and a technician was on the floor most days for something else. By Lorne's count, the desk had spent somewhere between fifteen and twenty hours that quarter recalibrating four monitors that were quietly failing. That cost had appeared in no report and been noticed by nobody. The pattern took one problem record, one call to the supplier, and four replacement monitors to end. After that the pre-press add-on rate fell to roughly what the rest of the building's was. The technician who had called the count pointless was the one who wrote the problem record. The lesson Lorne put in the quarterly report was that the add-ons had been telling the desk about a failing model for a year, in person, a few minutes at a time. Nobody had been able to hear it until the first lines were written down and counted together.

The Add-On Report Line

The sheet below is in two parts. The first is the counting sheet, filled in once a month from the search and the export. The rules are written at the top so that next month's count is a reproduction and not an argument. The second is the report line itself, five parts in one or two sentences. There is a worked example filled in from Penrose so that the shape is clear, and a blank one to copy. Keep the per-person cut on the counting sheet and off the report line. Keep the hours as a range. And write the action every month, even when it is small. A line with a finding and no action is a complaint, and a line with both is a desk running itself.

THE ADD-ON REPORT LINE — COUNTING SHEET AND THE LINE
Desk: ______________   Month: __________   Counted by: ______________   Counted on: __________

COUNTING RULES (written once; changed only in writing with the month noted)
  Add-ons found by: the phrase "______________" in the first line, plus the visit number
  A proxy request counts against: the visit it was mentioned at / the requester's own desk
  Done-on-the-spot tickets ("done at visit") are: in the add-on total / counted beside it
  Faults noticed by the technician are: add-ons / desk-raised, counted separately
  Average minutes per add-on, from a sample of ____ read tickets: ____ (range ____ to ____)

THE COUNTS
  Desk-side visits in the month: ____
  Add-ons captured: ____        Add-ons per visit: ____
  Done on the spot and logged: ____   Of those, back within a fortnight: ____
  By kind:   how-do-I ____   saved-up fault ____   proxy ____   noticed by technician ____
  By place:  ______________ ____   ______________ ____   ______________ ____
  Still open at month end: ____   Older than thirty days: ____
  Hours represented (count x average, as a range): ____ to ____ hours

FINDINGS (desk only; the per-person cut stays here)
  Requesters with three or more add-ons: ____ people, pointing at: ______________________
  Clusters by place or model: ______________________________________________
  The one finding that matters this month: ______________________________________

THE REPORT LINE (five parts, one or two sentences)
  Worked example:
  "Desk-side visits: 96. Add-ons captured: 140, about 1.5 per visit, representing roughly
   30 to 40 hours of work that was previously unlogged. Most were four how-do-I questions
   and a cluster from the model workshop; four knowledge base articles are now live and
   the workshop has a notice and a visit booked. 60 add-ons remain open and will be worked
   in batches; expect the count to rise next month as capture improves."

  This month:
  "Desk-side visits: ____. Add-ons captured: ____, about ____ per visit, representing
   roughly ____ to ____ hours of previously unlogged work. Most were ______________________;
   the desk has ______________________________. ____ remain open and will be ____________;
   expect the count to ______________ next month because ______________________."

Hannah's line went into the report the following Thursday, and the managing partner's only question was about the model workshop. She had never thought of it as a place that needed IT and now could not stop thinking about it. It turned out to be where the practice's most expensive machines lived, and nobody in it had known where to ask. The four articles were written by the end of the month. The add-on count rose in the third month, as predicted, and fell in the fifth, as hoped. The technician who had worried, back in June, that logging every "while you're here" would make the desk look slow, now reads the spreadsheet on Fridays before Hannah does. It is, she says, the only report on the desk that tells her something she did not already know. That is a good description of what a report is for.

Frequently Asked Questions