Categories That Make Reports Worth Reading

The monthly review at Greystone Legal, a law firm with a desk of two, has reached slide four. Anita has put up the category chart because the tool produces one and the template has a space for it. It is a pie, eleven colours, with a legend down the right-hand side. The largest slice, forty-one percent, is labelled Other. The managing partner, who has been polite through three slides, points at it. "So what is Other?" Anita does not know. Nobody knows. Other is three hundred and twelve tickets. The only thing the chart can say about them is that they were not any of the other ten things.

The slide is not wrong. Every number on it is accurate. It is a faithful picture of a category list that stopped describing the work some time ago. And the pie is doing the only honest thing a chart can do with such a list, which is to show that the list has failed. The partner's question is the right one, and the answer is not on the slide, because the answer is in the taxonomy. The taxonomy was never built with this meeting in mind.

A category report is a count of tickets by what they were about, over a period. It is arranged so that the reader can see where the desk's work comes from and whether that is changing. This article is part of our Ticket Categorization & Taxonomy series. And it is a reporting primer. It covers how to build the report, how to read it, and what the taxonomy has to be like for the report to be worth anyone's twenty minutes. It is not a deep dive into finding hotspots; that lives with problem management. This is the page before that page.

It covers the one question a category report answers and the top ten by category and how to build it. Next come the trend by category and the three shapes it takes. Then it covers what a bad taxonomy does to the report, and how to recognise each failure from the page. It covers reading for the source rather than the symptom and pairing the category with one other cut. It ends with the twenty-minute monthly read and how to show it to management without a pie. The monthly category report layout at the end is built to be copied.

The One Question a Category Report Answers

A category report answers one question: where does the work come from? Not how fast the desk is, which is the service report's job. Not who did it, which is the workload report's job. What is it about. Which kinds of tickets, in what proportion, and is that proportion moving. Every column on the page should serve that question, and anything that does not is decoration, however pretty.

The answer is useful because it is the only part of the desk's picture that points outward. Response times, backlog, reopen rate: these describe the desk. The category report describes the organisation's problems as the desk sees them, which is what the organisation wants to know and what it cannot find out any other way. A desk that can say "a third of our work is password expiries and we can remove most of it with a reminder" is a desk that has read its category report. A desk that can say "we closed 340 tickets" has read a different report, and a less interesting one.

The report is only as good as the field it counts. And the field is filled in by tired people at four in the afternoon. That is the whole reason this article sits inside a series about taxonomy rather than a series about reporting. The report cannot be better than the list, and the list cannot be better than the habit of filling it in. Why the field exists at all is in Why Ticket Categories Exist. This article assumes the field exists and asks what the report built on it should look like.

The Top Ten by Category

The core of the report is a table of the ten busiest categories for the month, sorted by count, with four columns. These are the category, the count, its share of all tickets, and the change against the previous month. That table, on its own, answers the question for most desks most months. Add a fifth column for median time to resolve if the tool gives it easily. A category that is both busy and slow is the one to look at first. It will not be the top row.

Build it from the close category, not the open one. The open category records what requesters said; the close category records what was wrong. And a report built on symptoms leads to fixes for things that were not broken. The difference, and the close routine that produces the right field, is the subject of Categorize at Close, Not Just at Open. If the desk has only recently started setting a close category, say so in a footnote on the report. In that case, the first month's table will look different from the last month's for that reason alone.

Most ticketing tools can show a count of tickets by category over a chosen period. If yours can, that is the table, and the only work is reading it. If yours cannot, or has the category on a custom field the reports do not read, export the month's tickets to a spreadsheet and count there. Use one column of categories, a count per distinct value, sorted descending. A spreadsheet formula such as =COUNTIF(C:C, "Access: password expired") counts one category; a pivot table counts them all in one step. The first month takes twenty minutes. The second takes five, because the spreadsheet is saved.

Read the table from the top and expect a shape. The top three or four rows usually hold half the tickets. The next six hold most of the rest. A long tail below the tenth row holds very little. That shape is normal and it is good news, because it means the desk's work is concentrated enough to act on. A table where the top row holds a tenth and the next nine hold a tenth each, flat all the way down, tells you something. The taxonomy is too fine or the field is being filled inconsistently. A table where the top row is Other is telling you the taxonomy has failed, which the next section is about.

Here is a top ten from a desk of four at a two-hundred-person company, with the numbers rounded. Access: password expired, 61 tickets, 18 percent, up 9 on last month. Printing: cannot print, 38, 11 percent, down 4. E-mail: mailbox size, 29, 9 percent, up 12. Devices: laptop, 27, 8 percent, flat. Business application: finance system, 24, 7 percent, up 15. Access: permissions, 22, 7 percent, flat. Network: remote access, 19, 6 percent, down 3. New equipment, 17, 5 percent, flat. Information request, 15, 4 percent, flat. Other, 14, 4 percent, down 2. Three rows have moved by more than ten, and those three are the whole of this month's reading. The rest is confirmation that nothing else changed, which is also worth knowing. (It is the only kind of good news a report ever brings, so take it.)

Trend by Category

The second element is the trend: the same categories over three months or more, so that a count becomes a direction. One month's number is a position; three months' numbers are a slope. The slope is what tells you whether something is getting worse, has got worse and stopped, or spiked once and is already over. The trend needs a stable taxonomy to work at all, which is the quiet reason that renaming a category mid-quarter is so expensive: it breaks the line.

Trends take three shapes, and each means something different. The step is a category that was flat, jumped, and stayed at the new level. Something changed in the environment: a new application, a new policy, a new building. And the desk now has a permanent new kind of work. The drift is a category rising a little each month with no single cause. That could be a growing population, an ageing fleet, a slow degradation that nobody would notice week to week. The spike is one bad month that goes back down: an outage, a mass e-mail, a migration weekend. The step needs a decision. The drift needs a plan. The spike needs a sentence in the notes and nothing else.

Show the trend as a small table or a sparkline per category, five or six categories at most, chosen because they moved. A chart of all twenty categories over twelve months is a bowl of coloured spaghetti and nobody has ever read one. The categories that did not move do not need a line; they need a sentence saying they did not move. The report reader's time is the scarce thing on the page, and a trend chart that takes two minutes to decode has spent it.

The finance-system row in the example above is a step. It was at nine for three months, then fifteen, then twenty-four. And a glance at the close notes shows a version upgrade in the middle month that changed the way exports work. That is a decision: a knowledge article today, and a conversation with the vendor about the export. The mailbox-size row is a drift, up two or three a month for half a year as mailboxes fill. And it needs a plan rather than a fix: a warning at eighty percent of quota and an article on archiving. The two rows look similar in one month's table. They look nothing alike over six.

What a Bad Taxonomy Does to a Report

A bad taxonomy does not produce a wrong report. It produces a report that cannot say anything. The ways it fails are visible on the page if you know what to look for. The table pairs each symptom in the report with what it says about the taxonomy underneath and the fix, which is always to the list rather than to the report. Reformatting the chart has never once improved a category list.

Everything-is-Other deserves a closer look because it is the commonest failure and the one management notices first. Other above about a tenth of tickets means the report is describing the list's gaps rather than the organisation's problems. The honest response in the meeting is to say exactly that: "Other is forty percent, which tells us the category list needs work, and here is the plan." That is a better answer than a guess, and it is the answer that leads to the pruning review in Avoiding the 400-Category Monster. The report cannot be fixed on the slide. It is fixed in the list, and then the slide fixes itself.

The dropped line is the subtlest failure, and it looks like success. A category that was at forty a month shows zero this month, and the first reading is that the problem was solved. Usually it was renamed at the pruning review and its tickets are now counted under a different row. In that case, the report reader, who was not at the review, has no way to know. The mapping table and the footnote that prevent this are the subject of Retiring, Merging and Renaming Categories Without Losing History. Here the rule is only this: a report with a line that went to zero carries a sentence saying why.

Reading for the Source Rather Than the Symptom

Read the top ten looking for the source of the work, not the shape of the complaint, because the source is the thing that can be removed. "Access: password expired, 61 tickets" is a source. Passwords expire on a schedule, people forget, and a reminder five days before expiry removes most of the sixty-one. "Access, 61 tickets" is a shape: it tells you people have access problems, which you knew. The difference is one level of the tree and the habit of setting it at close. And it is the difference between a report that leads to an action and a report that leads to a nod.

Three questions turn a row into a source. What was the cause, in the words of the close notes? Is it one cause or several? And could a change outside the desk remove it: a setting, a reminder, an article, a purchase, a conversation with a vendor? A row where the answers are "one cause, yes" is a fix waiting for an owner. A row where the answers are "many causes, no" is the ordinary cost of running computers and belongs in the report as context, not as a problem. Most top-ten tables contain two or three of the first kind, and finding them is the twenty minutes.

This is where the category report hands off to problem management, and the handoff should be deliberate. A problem, in help desk terms, is the underlying cause behind a cluster of tickets. And the category report is how a small desk finds one without a module. The busy row with a single cause in the notes is the problem. And the row's count is the business case for fixing it. What to do once the row is found, how to confirm the cause, and how to get the permanent fix done are the subjects of Finding the Repeat Tickets. The report's job ends at pointing.

Resist the urge to read every row this way every month. Three rows, the ones that moved most or hold the most, get the three questions; the rest get a glance. A category report read exhaustively takes two hours and produces a list of fourteen things nobody will do. Read for the three that will be done, write them at the bottom of the page with a name beside each, and stop. The report that produces one fix a month beats the report that produces an inventory.

Pairing Category With One Other Cut

A category on its own says what; paired with one other field it says where, when or how. One pairing a month is enough. Category by department, or by requester group if the tool has no departments, says where the work comes from. For example, forty of the sixty-one password tickets are from the warehouse, whose staff share terminals and do not see the expiry warning. Category by hour of day says when. For example, the finance-system tickets cluster at 09:00 on the first working day of the month, when the export runs. Category by channel says how. For example, the printing tickets all arrive by walk-up, which means the self-service article nobody reads is in the wrong place.

Pick the pairing by the question, not by what the tool offers. If the question this month is "why did password expiries jump", pair with department and the warehouse appears. If it is "why does the finance system break", pair with day of month and the export appears. One pairing, chosen for a reason, read for ten minutes. A report that pairs category with everything is a cube, and cubes are for people with a week. Breaches by category is another useful cut and belongs to the SLA review rather than here. It is one of the four reads in SLA Breaches and What They Teach.

Most tools can do one pairing in their reports. And a spreadsheet can do any pairing from an export with a pivot table that has the category down the side and the second field across the top. The second field should have few values: departments, hours, channels, days of the week. Pairing category with requester name produces a table with two hundred columns, which is a list of who has the most problems. That list helps nobody and offends one person. Pair with groups, never with individuals.

The Twenty-Minute Monthly Read

The report is read once a month, in twenty minutes, in a fixed order, by the person who owns the category list, with last month's page beside it. Minutes one to three: the total ticket count and the Other share, against last month. If Other has risen, the first action is already known. Four to nine: the top ten, from the top, marking the three rows that moved most or hold the most. Ten to fourteen: the trend table, naming the shape of each marked row: step, drift or spike. Fifteen to eighteen: the three questions on each marked row, from the close notes. Nineteen and twenty: write the actions, with names, at the foot of the page. File it.

The output is one to three actions, and three is the ceiling. An action is a sentence with an owner and a date: "Set password-expiry reminder to five days; Sam; by the fifteenth." A finding without an owner is an observation, and observations accumulate in folders. If the month's reading produces nothing, write "no change; shapes stable". Three "no change" months in a row are evidence that the desk's work is steady. A steady desk should be able to prove it.

Keep the pages. Twelve monthly pages are the annual review, already written, and they are the record of which actions were taken and whether the row they targeted fell. The password-reminder action from month three should show in month four's table as a drop in the password row. If it does not, that is a reading too. The monthly read is how the desk closes its own loop. Without the pages there is no loop, just a series of meetings about pies.

Showing It to Management

Management gets one page, and the page has three parts. There is a sorted bar chart of the top ten, and a short trend table of the rows that moved. There are also three sentences at the top saying what changed and what the desk is doing about it. The three sentences come first because they are the only part that will certainly be read. "Password expiries rose to sixty-one and are now a fifth of our work; we are adding a five-day reminder; expect the row to halve by next month." That is the report. The chart is the evidence.

No pie charts. A pie with ten slices cannot be read for size without the legend, cannot show change at all, and puts Other in a colour. That is a way of making a failure look like a category. A horizontal bar chart sorted by count, longest at the top, with the count printed at the end of each bar, is read in four seconds without a legend and shows the shape at a glance. If the tool only draws pies, draw the bars in the spreadsheet. The partner at Greystone Legal was not asking for a prettier pie. He was asking for the shape, and a pie hides it.

Say what the report cannot say, every time. If the close category has only been set for two months, say so, and that the trend starts from there. If a category was renamed at the quarter, say so, and point to the mapping. If Other is above a tenth, say so first, and say what the pruning plan is. A report that admits its limits is believed. A report that does not is believed until the first time someone checks. After that it is a slide. The short version of all this is one line at the foot of the page: what changed in the list since last time, or "nothing".

A Short War Story: The Pie Chart at Tollgate Foods

Tollgate Foods, a food distributor with a desk of five, presented a category pie to its operations director every month for a year. Every month the largest slice was "Software" at around a third. The director took that to mean that the company's applications were poor. That interpretation eventually became a budget line for replacing the warehouse management system. Marcus, who inherited the desk in the spring, exported a quarter of tickets and read the close notes behind the Software slice over two evenings. About half were permission requests for the warehouse system from staff who had moved roles, filed under Software because the list had no entry for access. A quarter were a nightly export failing when the previous day's data was large. A scheduled job restart would have fixed that in an afternoon. The rest were scattered. He split the slice into Access: permissions, Warehouse system: export, and Warehouse system: other. He set the close category as required. He presented the next month's report as a sorted bar chart with three sentences at the top. The permission row went to a role template at onboarding and fell by two thirds in two months. The export row went to zero after the restart job. And the replacement project, which had been budgeted at a figure Marcus preferred not to repeat, was quietly shelved. The lesson he gave the director was the one the pie had hidden for a year. The system was not the problem. The list was. A report cannot be more specific than the field it counts.

The Monthly Category Report Layout

The layout below is the one page, in the order it is read. Fill it from the tool's category count or the spreadsheet, top down, with last month's page open beside it. The actions section at the bottom is the only part that matters by the following month, so fill it in last and fill it in with names. Keep the pages together; twelve of them are the year.

MONTHLY CATEGORY REPORT — ONE PAGE
Desk: ______________   Month: ______________   Prepared by: ______________
Category set at close since: ______________   List last changed: ______________

HEADLINE (three sentences, written last, read first)
  1. ____________________________________________________________________
  2. ____________________________________________________________________
  3. ____________________________________________________________________

TOTALS
  Tickets this month: ______   Last month: ______   Change: ______
  Other: ______ tickets, ____%   (last month ____%)   Target: under 5%

TOP TEN BY CLOSE CATEGORY (sorted by count)
   #  Category                          Count   Share   vs last month   Median days
   1  ______________________________    _____   ____%   ______          _____
   2  ______________________________    _____   ____%   ______          _____
   3  ______________________________    _____   ____%   ______          _____
   4  ______________________________    _____   ____%   ______          _____
   5  ______________________________    _____   ____%   ______          _____
   6  ______________________________    _____   ____%   ______          _____
   7  ______________________________    _____   ____%   ______          _____
   8  ______________________________    _____   ____%   ______          _____
   9  ______________________________    _____   ____%   ______          _____
  10  ______________________________    _____   ____%   ______          _____
  Shape of the table:  [ ] top three hold about half   [ ] flat   [ ] one row dominates

TREND (rows that moved; three to six months; shape named)
  Category                       M-5   M-4   M-3   M-2   M-1   Now   Shape
  ____________________________   ___   ___   ___   ___   ___   ___   [ ] step [ ] drift [ ] spike
  ____________________________   ___   ___   ___   ___   ___   ___   [ ] step [ ] drift [ ] spike
  ____________________________   ___   ___   ___   ___   ___   ___   [ ] step [ ] drift [ ] spike

ONE PAIRING THIS MONTH
  Category: ______________  paired with:  [ ] department  [ ] hour  [ ] channel  [ ] day
  What it showed: _______________________________________________________

THE THREE QUESTIONS (on the marked rows)
  Row: ______________  Cause in the notes: ______________  One cause? [ ]  Removable? [ ]
  Row: ______________  Cause in the notes: ______________  One cause? [ ]  Removable? [ ]
  Row: ______________  Cause in the notes: ______________  One cause? [ ]  Removable? [ ]

ACTIONS (at most three; owner and date each)
  1. ______________________________________  Owner: ________  By: ________
  2. ______________________________________  Owner: ________  By: ________
  3. ______________________________________  Owner: ________  By: ________
  Last month's actions: [ ] done, row fell   [ ] done, row did not fall   [ ] not done

WHAT THE REPORT CANNOT SAY THIS MONTH
  ______________________________________________________________________
  (new close category, renamed entries, a gap in data, a partial month)

Anita's slide four at Greystone Legal, rebuilt on this layout, would have started with three sentences. One of them was "Other is forty-one percent, which means our category list is not describing our work, and the pruning review is on the twelfth". The partner would have had his answer, which was that nobody knew yet and here was the plan for knowing. That is a better meeting than the one with the pie. It is also a shorter one, which, in a room of lawyers, is its own kind of report.

Frequently Asked Questions