Reporting by Work Type: What the Split Tells You

The termly review at Pennywell Schools Trust, six schools and a three-person desk, opened with a slide about ticket counts. Tickets had risen from 290 a month to 410. The second slide asked why everything kept breaking. Jonas, who ran the desk, knew that nothing was breaking more than before. Two schools had joined the trust in the summer. Four hundred new accounts, two hundred devices and a term's worth of "can I have access to" had arrived with them. The incidents were flat. The requests had doubled. The total, which was the only number anyone had been shown, had added the two together and told a story about fragility with complete confidence. The room had believed it, because a total has no way of saying "actually, this is mostly good news".

Reporting by work type means producing the monthly numbers for incidents, requests, problems and changes separately. Each then answers its own question, instead of one total that answers none. The four types and the case for keeping them apart are in The Four Work Types in Plain Words and Why Separating Them Matters. This article is part of our Incidents, Requests, Problems & Changes series. It is the one about the report, which is where the separation finally pays.

It covers what one total hides, then the four numbers, one for each type, and the question each answers. Next come the incident-to-request ratio and what moves it, problems opened against problems closed, and changes that caused incidents. That last number is the one most desks never compute. Reading the split over three months and building it in any tool, including a spreadsheet, follow. The article ends with the monthly work-type summary to copy, the three sentences for management, and a short war story, in that order.

What One Total Hides

A total is a count of things that happened, and the trouble is that four different things happened. A hundred and ten broken things and three hundred wanted things make a total of four hundred and ten. So do three hundred broken things and a hundred and ten wanted things. Those are two different desks in two different buildings with two different conversations ahead of them. The first needs a request form and a second clock. The second needs a problem list and probably a hardware budget. The total cannot tell them apart, so whoever reads the total supplies the story themselves. The story they supply is nearly always "things are breaking".

The total also hides direction. A total that rises is read as bad. A rising request count is usually growth, onboarding or a desk that has finally got the hallway into the queue, all of which are good. A total that falls is read as good. A falling incident count alongside a falling request count is often a department that has stopped raising tickets. That is a quiet failure the desk only ever notices from outside. Split the total and the direction of each part has a meaning. Leave it whole and the direction means whatever the room decides it means.

And the total hides the two types nobody asked for. Problems and changes are raised by the desk about its own work. They are a handful a month, and inside a total of four hundred they are rounding error. Reported on their own lines, three problems closed and six changes made is the evidence that the desk is doing more than bailing. It is the only evidence of that which a monthly report can carry. A total has never once shown that a desk fixed a cause. It only shows that the desk was busy, which everyone already knew.

The Four Numbers, One per Type

Each type gets one headline number and a few supporting ones, and each headline answers a question somebody actually asks. For incidents the question is "how fast do we get people working again, and what keeps breaking?" The headline is the count. Beneath it are the median time to restore, the number that met target and the number that breached. Then come the top three categories and the repeats. Repeats are the incidents that happened three or more times in the month about the same thing, and that line is where problems come from.

For requests the question is "how reliably do we deliver what people ask for, and where does the waiting happen?" The headline is the count by row of the standard request list. Beneath it are the median approval wait and the median fulfilment time from approval. The two medians are kept apart on purpose, because one belongs to the approvers and one belongs to the desk. Adding them produces a number that gets the desk asked why laptops take two weeks. The request lifecycle and the reason the clock starts at approval are in Requests, Approvals and Fulfilment.

For problems the question is "are we fixing causes or only symptoms?" The headline is opened against closed. It comes with the number open at month end and, for each one closed, the incidents it is expected to stop. For changes the question is "are we breaking things ourselves?" The headline is the count made. It comes with the number rolled back or failed and the number of this month's incidents that followed a change. Those last two headlines are the ones a one-pile report can never produce. They are the ones that change what the desk does next month.

The supporting numbers under each headline are deliberately few. A report with forty numbers is read for the one that is red. The one that is red is usually the breach count, which is the number least in the desk's control. Three or four lines per type, twelve to sixteen in all, fits on one page and takes four minutes to read. (The page will be read for four minutes. Plan for that, not for the hour you spent on it.)

The Incident-to-Request Ratio

The incident-to-request ratio is the count of incidents against the count of requests in the same month. It describes what kind of work the desk mostly does. A desk at one to three is mostly a service counter: accounts, access, devices, questions, with a background of breakage. A desk at three to one is mostly a repair shop, and either its estate is fragile or its requests are arriving somewhere the desk cannot see. Neither ratio is right or wrong. The ratio is a description. The first time a desk computes it, the description is usually a surprise to the desk and a bigger one to its manager.

What moves it is more useful than what it is. A ratio shifting towards requests over several months has several possible meanings: growth, onboarding, or a new form that has caught work the hallway used to absorb. Or it means a problem list is working and incidents are falling. A ratio shifting towards incidents means an estate is ageing, a change is still causing trouble, or people have stopped using a request form. Or a triager is defaulting to incident. Each of those has a different fix. The ratio alone does not say which, but it says that one of them is happening. It says so two months before the breach count does.

Use the ratio for staffing, which is where it earns its place. Requests are predictable: the same ten rows, the same steps, the same expected times. That means they can be scheduled, batched into a Tuesday afternoon, and handed to the newest person with a checklist. Incidents are not: they arrive when they arrive and need someone free. A desk at one to three can schedule most of its week and keep one person loose for incidents. A desk at three to one needs the reverse, and the ratio is the number that makes the case for either in a sentence. Do not set a target for the ratio. A desk told to reach one to three will reach it by retyping. The number will then describe the triager's compliance rather than the work.

Problems Opened Against Problems Closed

Problems opened against problems closed is the pump gauge, and it has three readings. Zero and zero means the desk has no problem management. In that case, the repeats line in the incident section is the list of problems it has not opened. This is the normal reading on a desk that has just started splitting its report. It is not a criticism. It is a starting point. Opens rising with no closes means the desk has a list and not a practice. Problems are being noticed and written down, which is good. Then nobody has the Friday hour to work them, which is the thing to fix. Closes arriving with linked incidents means the practice is working, and this is the only reading that should be allowed to stay the same for a year.

For each problem closed, estimate the incidents it will stop, and be honest that it is an estimate. The method is to count the incidents linked to the problem in the three months before it was closed and divide by three. That gives a monthly figure. Write it down as "about seven a month" rather than as a decimal. The next three months' repeats line will say whether the estimate was right. A problem closed with a workaround rather than a fix still stops incidents from being expensive, even if it does not stop them arriving. The report should say which kind of close it was. The practice of working the list, in an hour a week, is in Problem Management in an Hour a Week.

Report the oldest open problem's age, in weeks, with its next review date. It is the one number on the page that keeps a problem list honest. A problem that has been open for forty weeks with no review date is a problem that has become furniture. I have had a problem record that reached a year. Its review date said "next month" for eleven of them. Putting the age on the report was what finally got it closed, with a workaround, in an afternoon.

Changes That Caused Incidents

Changes that caused incidents is the number most desks never compute. Computing it needs two things most desks do not have: a record of the changes, and a question asked at incident close. The record comes from the convention described earlier in this series, a CHG ticket or a line on a calendar page for every alteration to something live. The question is asked when the incident is closed: "did a change precede this?", answered yes or no, and if yes, which. Where the tool has a field for it, use the field. Where it does not, a line in the resolution note, "followed change CHG-41", is enough for a spreadsheet to find.

What the number says is how much of the desk's incident work the desk is generating for itself, and it is nearly always more than anyone guessed. Three incidents out of sixty following changes is a desk whose changes are reviewed and tested, or a desk that is not asking the question. Fifteen out of sixty is a desk whose Friday-afternoon alterations are its Monday-morning queue. The fix is a change review that takes fifteen minutes and a rule about Fridays, both in A Change Review That Takes Fifteen Minutes. The number also says which kind of change fails. Nine of the fifteen from one kind, driver updates say, is one procedure to fix, not fifteen incidents to apologise for.

Report the number beside the count of changes made, so that the ratio is visible. Six changes, one caused incidents, is a different desk from six changes, four caused incidents. And report changes found afterwards, the ones made without a record and discovered during an incident. That count measures whether the change convention is living in the door or in somebody's memory. A desk whose "found afterwards" line is zero for three months has either a perfect convention or nobody asking. It is usually the second, and the war story below is what the first month of asking tends to find.

Reading the Split Over Three Months

One month of the split is a description. Three months is a direction, and direction is what the desk acts on. Keep the monthly summary sheets together and read the newest against the two before it, line by line. Ask only "is this moving, and do I know why?" An incident count that rose once is a bad week; one that rose three months running is an estate or a change pattern. A request count that doubled in September at a school trust is the term starting. A problem list with the same oldest age for three months is a list nobody is reading. The pattern test on three sheets is the same one used for breach reports in SLA Breaches and What They Teach. It works for the same reason: weather does not repeat on schedule, and structure does.

Expect seasons, and write them down the first time so they do not surprise you the second. A school desk has September and January. A retailer has the weeks before its busiest trading period. A payroll firm has month end. A desk that knows its request count triples in one month can staff for it and pre-approve the rows that always come. It can tell management in August what September will look like, which is the single most reassuring sentence a desk can say to a manager. A desk that does not know reads September's total as a crisis, every year, and holds a meeting about it.

Change one thing a month on the strength of the sheet, and write on the sheet what you expect it to move. If the change was a request form default, expect the retype count to fall and the breach count with it. If it was a problem closed, expect the repeats line for that category to fall over the next three months. One change, one expectation, one comparison next month. Make two changes at once and the next sheet cannot say which worked. A sheet that cannot say which worked is a sheet that teaches nothing, however many numbers it has.

Building It in Any Tool

Most tools can group tickets by whatever carries the type, a form, a department, a category branch, a custom field or a tag. They can show created and closed counts, a first-response rate and a reopen rate for each group. Where the tool's built-in report can do that, the monthly summary is mostly reading numbers off a screen into the sheet. Where it cannot, or where the type is carried by a subject prefix, export the month's tickets to a spreadsheet. Include their logged date, closed date, type carrier, category, approval date if you record one, and the "followed change" note. Build the numbers there. The first month takes an hour; by the third it takes twenty minutes, and the twenty minutes is the report.

Two spreadsheet formulas do most of the work. A count of one type in one month is a conditional count across the type column and the date column. It has the shape of COUNTIFS(type range, "Incident", logged range, ">=" & first of month, logged range, "<" & first of next month). A median time for one type is the middle value of that type's elapsed-time column. Sort by type, select the block, and take MEDIAN of it. Or use the tool's filter and read the median off the filtered column. Use medians rather than averages throughout. A single request that waited forty days for an approver will drag an average to a number that describes nobody's experience. The median will not.

Do not report the tool's default "average resolution time" across all tickets, whatever the tool calls it. It is the one-pile number in a nicer font: it adds approval waits to restore times and divides by everything. It is the figure that produces the question Jonas was asked. If a manager has grown used to it, show it one more month beside the split, and let the split explain it. "Average resolution time rose because two schools joined and requests doubled; incident restore time was unchanged" is the sentence that retires it.

The Monthly Work-Type Summary

The sheet below is the four numbers and their supporting lines on one page. It is in plain text so it can live in the knowledge base, a shared folder or a printed binder. It can be read against last month's in a minute. Fill it from the tool's report or the spreadsheet in the order shown. Fill in the last block, the one change for next month, before you file it. A sheet with that block empty was a reading, not a review.

MONTHLY WORK-TYPE SUMMARY — ONE PAGE
Desk: ______________________   Month: ____________   Prepared by: ____________

HEADLINE
  Tickets logged: ____   (last month ____)
  Incidents ____   Requests ____   Problems opened ____   Changes made ____
  Incident : request ratio   ____ : ____   (last month ____ : ____)
  One sentence on what moved and why: ______________________________________

INCIDENTS  (speed of restore, and what repeats)
  Logged ____   Restored ____   Open at month end ____
  Median time to restore ______   Met target ____ of ____   Breaches ____
  Top three categories:  __________ ____   __________ ____   __________ ____
  Repeats (same thing three or more times): ____   Problem records opened from them: ____
  Incidents that followed a change: ____   (from one kind of change: ____ )

REQUESTS  (approval wait and fulfilment time, kept apart)
  Logged ____   Delivered ____   Declined ____   Open at month end ____
  Median approval wait ______   Longest approver: __________ ____ days
  Median fulfilment, approval to delivery ______   Past expected time ____
  Top three request rows:  __________ ____   __________ ____   __________ ____
  Reopened after delivery: ____

PROBLEMS  (causes fixed, or only symptoms)
  Open at start ____   Opened ____   Closed ____   Open at end ____
  Closed this month:  PRB ____  cause: __________  fix or workaround: ______
                      incidents linked over three months: ____  (about ____ a month)
  Oldest open problem: ____ weeks   Next review date: ____________

CHANGES  (how many, and how many caused incidents)
  Made ____   Rolled back or failed ____   Emergency ____
  Changes that caused incidents: ____   kind: ____________________
  Changes found afterwards, made without a record: ____

THREE-MONTH CHECK
  Line that moved the same way three months running: ____________________
  Season or known cause?  [ ] yes: ____________   [ ] no: structural

THE ONE CHANGE FOR NEXT MONTH
  What: __________________________________________________________________
  Expected to move: ______________ from ____ to about ____
  Owner: __________   Done by: __________   Review on next sheet: [ ]

Two blocks of the sheet earn their place more than the rest. The two medians under requests, kept apart, because that is the pair that stops the desk being measured on its approvers. And the "found afterwards" line under changes, because it is the only number on the page that measures whether the other numbers can be trusted. A desk that is honest on that line will be honest on the rest.

The Three Sentences for Management

The sheet is for the desk. Management gets three sentences, one per paragraph, in a message or at the top of the page. Those cover what moved, why, and what the desk is doing about it. "Tickets rose from 290 to 410 this term. Incidents were flat at about 105 a month; the rise is requests, which doubled because Hillside and Oakmead joined the trust and brought four hundred new accounts and two hundred devices. We have put the five commonest onboarding requests on a pre-approved list, and expect the request count to fall back to about 220 by the spring term." That is the whole briefing. The sheet is attached for anyone who wants the numbers behind it, and about one manager in three will open it.

The three sentences work because each number arrives with its question answered. A manager handed "410 tickets" has to supply the meaning, and will. A manager handed "incidents flat, requests doubled because two schools joined" has been given the meaning and the number together. That manager has nothing left to supply except "good, carry on". The trick here is small: never hand over a count without its type, and never hand over a type without its question.

A Short War Story: Friday Evenings at Copperfield Print

Copperfield Print, a commercial printer with a hundred and twenty staff and a desk of three, reported a rising incident count for three months. It spent the quarter looking for a failing server, because a rising incident count means something is breaking. Mira, the desk lead, started asking "did a change precede this?" at every incident close. The first month's answer was eleven out of fifty-eight, and nine of the eleven followed the same kind of change. These were printer-driver updates that a technician pushed to the print room's workstations on Friday evenings, when nobody was printing. That was considerate and also meant that nobody found out until Monday at seven. None of the nine updates had a change record, so none had appeared in any report. The Monday-morning incidents had been diagnosed from scratch nine times by three people, at roughly four hours of desk time each, before anyone connected them. The cost was a quarter of searching for a server that was fine, and around thirty-six hours of repeated diagnosis. It also included a print room that had started keeping its own log of "IT Mondays". Copperfield gave driver updates a change record and moved them to Tuesday mornings with a technician present. It put "changes that caused incidents" on the monthly sheet, where it read nine, then two, then zero. A report that counts incidents without counting changes will never find the ones the desk caused itself.

Jonas, at Pennywell, took the four hundred and ten tickets home over a weekend, which he does not recommend. He came back with the split: incidents 104, requests 298, problems opened two, changes six. The incidents were, as he had known, flat. The second slide at the next review said so, with the two schools' names beside the request number. The question about everything breaking did not get asked. In its place came a better one, from the finance director. Why had two hundred and ninety-eight requests needed a hundred and forty separate approvals from eleven different people, and was that necessary? It was not. That is the kind of question a split report produces, and the kind of question a total never will.

Frequently Asked Questions