Per-Department and Per-User Ticket Patterns Without Blame

Thursday, 14:30, at Northgate Retail. Grace runs the desk that supports twenty-two stores and a head office. She has just pulled the quarter's tickets by store for the first time. One store, Harbor Street, raised 310 of the 1,400 store tickets. It has eighteen staff. One name, Femi, the assistant manager there, is on sixty-one of them. The regional manager, reading over her shoulder, says the first thing anyone says: "What's wrong with Femi?" Grace, who has been doing this longer, says the second thing, which is the right one: "What's wrong with Harbor Street?" They are about to find out that the answer is a till.

A volume pattern by department or by user is the share of tickets each group or person raises. It is set against the size of the group and the kind of work they do. The pattern is real and it is useful. It is almost always read the wrong way round the first time. That reading treats it as a fact about the people rather than about the systems the people are sitting inside. A department that raises half the tickets is not a department full of difficult people. It is a department with more kit, older kit, a job that depends on IT every minute, or a habit of logging things properly. This article is part of our Ticket Volume Analysis series. This article is about reading the pattern as information about the system, then acting on the system.

This article covers normalising by headcount before reading anything. Next come the department that raises half the tickets, and the five reasons it might. Then come the department that raises none, which is worse, and the person who raises twenty a month. We cover the reading rule that keeps the pattern useful, then a table that turns each pattern into an action. Next come the per-person caution, for requesters and for technicians, and showing the pattern to the departments. A short war story follows, then the pattern table to copy.

Normalise Before You Read

A raw count by department tells you which department is biggest, and almost nothing else. A department of two hundred people raising four hundred tickets a quarter is quieter, per person, than a department of twelve raising sixty. The first number to compute, before anyone looks at the pattern, is tickets per head per month. That is the department's tickets in the period, divided by the people in it, divided by the months in the period. In plain spreadsheet words, the department's ticket count over the quarter, divided by its headcount, divided by three. That single division turns a list of big and small departments into a list of departments that lean on the desk heavily or lightly. That is the thing you actually wanted to know.

At Northgate, the division changes the picture entirely. Harbor Street's 310 tickets across eighteen staff over three months is about 5.7 tickets per head per month. The other twenty-one stores together raised 1,090 tickets across about 357 staff, which is roughly one per head per month. Head office, a hundred and twenty people at desks all day, raised 610 in the quarter, about 1.7 per head per month. So the honest sentence is not "Harbor Street raises a quarter of store tickets". It is "Harbor Street raises tickets at five to six times the rate of every other store". That sentence has a cause, and the cause is findable.

Headcount is the awkward ingredient, because the desk does not own it and it changes. Ask HR for a headcount by department at the end of each quarter, or count active accounts in the directory by department if the directory is kept tidy. Write the source and the date on the sheet. A rough headcount is fine; a department of "about forty" produces a per-head figure good enough to read. What is not fine is a per-head figure with no headcount behind it at all, which is a raw count wearing a disguise. The second normaliser, where it applies, is devices rather than people. A warehouse with twelve people and forty scanners is a forty-device department for the purposes of scanner tickets. The per-head figure will mislead you unless you know that.

The Department That Raises Half

When one department dominates the count, even after normalising, there are five ordinary reasons, and the first job is to find out which. The first is more technology per person. For example, a department may have tills, scanners, label printers, a second screen, a laptop and a phone each, where the next department has one shared desktop. The second is older technology. The department that got the last refresh is the department that raises the fewest tickets, and the one still on the old model raises the most. The pattern will move the day the refresh does. The third is a job that cannot proceed without IT. A call centre loses a call for every two minutes of downtime, and a warehouse loses nothing for an hour. The two will report the same fault at wildly different rates.

The fourth reason is the good one, and it is routinely mistaken for the bad one: the department logs properly. A team whose manager insists that every problem goes through the desk will show a higher rate. That is compared with a team that phones a technician's mobile, fixes things themselves, or quietly works around the fault. The higher rate is the desk getting better information. A desk that treats it as a problem will teach the department to stop. The fifth reason is the one everyone assumes first and is true least often: the department's people need more training. It happens. It is also the reason that is reached for before the other four have been checked, because it is the only one that costs the desk nothing.

Tell the five apart by reading the categories inside the department's tickets, not the total. Harbor Street's 310 tickets included 190 about the till or the card terminal, which is two-thirds of them about one thing. The store had the last six tills of the old model left in the chain. They were kept because it was the flagship and had been due a refit that kept slipping. The card terminals ran over a line that dropped under load. That is reason two, older technology, with a little of reason three, since a till that fails at the counter is a ticket within the minute. The remaining 120 tickets, spread across the usual categories, put the store at about 2.2 per head per month. That was still higher than the other stores, but close enough to be reason four, since Femi logged everything. The category split is the whole diagnosis, and it took twenty minutes. Which is the subject of Volume by Category Over Time, and of the hotspot method it leads to.

The Department That Raises None

The department that raises almost no tickets is a worse sign than the one that raises half. It is the one nobody looks at, because an absence does not appear on a chart. Forty people in a department raising three tickets in a quarter are not forty people without problems. They are forty people solving their problems somewhere else. That could mean a local fixer who knows a bit about computers and has become the department's unofficial desk. It could mean a manager who has told the team not to bother IT, or a technician whose mobile number got passed around. Or it could mean a set of tools the desk does not know about and does not support. That last case is the subject of Unsupported Software and Shadow IT. The silence is data. It is just data about something the desk cannot see.

Find the silent departments by sorting the pattern table by tickets per head, ascending, and reading from the top. Then go and ask. Do not ask by e-mail, which the silent department will not answer. Walk over, or phone the manager, with one question: "we hardly hear from your team; is everything working, or are you fixing things yourselves?" The answer is usually the second, delivered slightly apologetically. It is followed by a list of problems that have never been tickets, some of which have been going on for a year. A desk learns more from one visit to its quietest department than from a month of reading its busiest.

A department that was normal and went quiet is a different and more urgent case, because something changed, and the change was usually the desk. The cause could be a response time that slipped, a reply that went badly, or a reorganisation that moved the team under a manager who distrusts IT. Any of these turns a department silent within a quarter, and the drop looks like good news on the volume chart. Catching that drop as it happens is the job of Volume as an Early-Warning System. Reading it after the fact, in the pattern table, is this article's job. Either way, the quiet department has not stopped having problems. It has stopped telling you about them.

The Person Who Raises Twenty a Month

Sort tickets by requester and one name will sit at the top with a count that looks absurd. The first reading is that this is a difficult or careless person. That is wrong often enough that you should assume it is wrong until the tickets say otherwise. There are four ordinary reasons for a heavy requester, and only one of them is about the person. The first and commonest is the proxy requester: someone whose role is to log problems for other people. The office manager, the ward clerk, the assistant manager, the receptionist, the executive assistant: each raises tickets on behalf of a dozen colleagues. The count is a dozen people's demand under one name. Femi at Harbor Street was this. Of his sixty-one tickets, fifty-four were about the tills and the terminals. He raised them because he was the person standing nearest the phone when a cashier called across the shop floor.

The proxy requester distorts the count and, worse, hides the real requester from the ticket. So every reply goes to the proxy and the person with the problem never hears anything. The ticket is also now impossible to find by the real person's name, which is one of the four hiding places described in Keeping Tickets From Hiding. The fix is the same in both cases: correct the requester to the person with the problem at first touch. Give the proxy a form with a field for it. Do that and the heavy requester's count will fall to their own problems, which will be ordinary. A dozen other names will appear in the count where they belong.

The second reason is that something of theirs is genuinely broken, repeatedly. That might be a laptop that fails every week, or a desk on the one network port that drops. It might be a role that uses a system nobody else uses and that fails often. Read the categories of their tickets. If they are all about one thing, the person is not a heavy requester. In that case, they are a persistent fault reported persistently, and the fault is the ticket. If it is a device, the device goes on the list of equipment that keeps coming back, which is built in Tickets as Asset Intelligence. The third reason is the role itself. Some jobs touch ten systems a day and some touch one. The person running the finance month-end will raise more tickets than the person on the loading bay in any month, forever, without anything being wrong.

The fourth reason, finally, is the person, and it does exist. It might be someone who raises a ticket for every question that could be answered by the article they were sent last week. Or it might be someone who reports the same thing three times before the first reply arrives. Even then the useful question is not "why are they like this?" but "what is the desk doing that makes this the sensible choice for them?" A requester who raises three tickets about one problem has usually not been told the first one was received. A requester who asks the same question monthly has usually not been given anything they can find again. The pattern is about the person in the sense that the fix is a conversation with them. It is about the system in the sense that the conversation is almost always "here is how to find the answer", not "please stop".

Reading the Pattern as Information About the System

The reading rule is this: a per-group or per-person figure describes the system that group or person is inside. The desk's first move is to ask what the system is doing to them. Never name an individual requester in anything that leaves the desk. Not in the monthly report, not in the chart for the steering committee, not as a "top requesters" list on a wall screen, not as a joke in a meeting. The names belong on the desk, where they are used to correct requester fields and spot broken laptops, and nowhere else. That is because a name on a report becomes a reputation within a week and the reputation outlives the broken till by years.

Outside the desk, report by role and department, and report the reason, not the count. "Harbor Street raised tickets at five times the chain rate, two-thirds of them about the six remaining old tills; a refit would remove about 190 tickets a quarter" is a sentence a regional manager can act on. "Harbor Street raised 310 tickets and Femi raised 61 of them" is a sentence that gets Femi a conversation he did not earn and gets the tills nothing. The count is the evidence. The reason is the report.

From Pattern to Action

Each shape in the pattern table points at a small number of likely causes and a two-minute check that tells them apart. The table below lists the ones that come up on almost every desk. The check column is the thing to do before anybody forms a view. Most of the checks are a filter on the department's or person's tickets by category. The action column is deliberately modest: a visit, a form, a refresh request, a problem record. Big actions come later, from the hotspot work; this table is for the first afternoon.

When one category dominates a department and the count is large, the pattern table has done its job. The work then moves to a different method. That is the systematic cut across devices, applications, processes and groups that finds the handful of sources behind most of the tickets. That method is the subject of What a Hotspot Is and its series. This article hands over to it at the point where "Harbor Street raises tickets at five times the rate" becomes "the six old tills are the hotspot".

The Per-Person Caution, in Both Directions

A per-person figure is noise until the person has enough tickets behind it, and the threshold is higher than it feels. For a requester, do not read anything into a count below about ten to fifteen tickets in a quarter. Below that, one bad week with a laptop makes a heavy requester out of anyone. For the person at the top of the list, with sixty or eighty, the count is meaningful and the reasons above apply. In between, read the categories before the count, and read the count over two quarters before forming a view. A quarter of data is one season. A person's count can double between the quiet month and the busy one without anything about them changing.

The same caution applies, with more force, when the cut is by technician rather than by requester. That cut will happen the moment someone maps departments to the technicians who serve them. A technician's ticket count, by department or in total, is for coaching and never for ranking. It depends on which department they cover, which weeks they were on the phone rota, which rollout landed on their patch, and how many quick tickets their patch happens to generate. Do not read a per-technician figure at all until it rests on somewhere between thirty and fifty closed tickets in the period. When you do read it, read it with the person, as a question about their queue: "your patch is two-thirds till tickets; do you need the till runbook, or does Harbor Street need new tills?" The number is a place to start a conversation about the work. It is not a score, and a desk that treats it as one will shortly have technicians choosing their tickets by how fast they close.

Showing the Pattern to the Departments

Department heads should see their own department's figures, because the department is usually where the fix is. That could be the refit, the training session, or the decision to stop using the tool nobody supports. Show them the per-head rate against the organisation's average, the category split, and the reason you think explains it. Show them in a conversation rather than in a report that arrives unannounced. A per-head figure that arrives by e-mail with no explanation will be read as an accusation by a manager who was already busy. The next thing that happens is a quiet instruction to the team to raise fewer tickets, which produces the silent department of two sections ago. The figures are a reason to talk. They are not the talk.

Where the department field is set by the route the ticket came in through, the department pattern is cheap to produce and reasonably trustworthy. If you run QuerySolv, each department has its own mailbox and form. In that setup, the department on a ticket is set by the door it arrived through rather than by whatever the requester typed. The same is true of most tools that route by department. The requester field is the one that needs human correction, at first touch, because no tool can tell that the assistant manager is logging on behalf of a cashier. That correction is a thirty-second habit for the triager. It is the single thing that most improves the per-user pattern, because it puts the tickets under the names of the people who actually have the problems.

A Short War Story: The Difficult User at Bluewater Bank

At Bluewater Bank, a branch cashier called Ruth raised twenty-three tickets in two months. They said that her counter terminal froze for a minute or two several times a day. Each was closed within the hour with "could not reproduce; restarted; monitoring". That was because the technician dialling in from head office never caught it frozen. Her name went to the top of the requester count and stayed there. The desk started to refer to "another one from Ruth". Her branch manager was asked, lightly, whether she might be "a bit quick to log things". The fault was a network switch in the branch's back room, failing under load for ninety seconds at a time. That hit every terminal in the branch. Ruth was simply the only person who had been told, on her induction, to report every fault, and the only one who did. The week the switch failed outright, the branch closed its counters for a day. The desk spent roughly sixty hours across the twenty-three tickets and the outage on a fault that the first ticket had described accurately. Twenty tickets from one person about one thing is one problem reported twenty times, and the report was right the first time.

The Pattern Table

The table below is the quarterly sheet. It has one row per department or site in the top section and one row per heavy requester in the bottom section. The latter section is kept on the desk and never circulated. Fill the people column from HR or the directory with the date, then compute tickets per head per month. Filter each row's tickets by category to find the top one and its share. Then write a reading and an action in plain words. The reading column is the only one that needs judgement, and the action table above is the guide. Keep the completed sheets. The same row a year later is the trend. The row that moved after an action is the proof the action worked.

PATTERN TABLE — ONE QUARTER, ONE PAGE
Desk: ______________________   Quarter: ______   Headcount source and date: ______________

A. BY DEPARTMENT OR SITE (circulate to department heads with the reading, never the raw list alone)
Department / site     People   Tickets   Per head    Top category        Share    Reading                  Action
                                         per month                        of top
____________________  ______   _______   _________   _________________   _____    ______________________   __________________
____________________  ______   _______   _________   _________________   _____    ______________________   __________________
____________________  ______   _______   _________   _________________   _____    ______________________   __________________
____________________  ______   _______   _________   _________________   _____    ______________________   __________________
____________________  ______   _______   _________   _________________   _____    ______________________   __________________
Whole organisation    ______   _______   _________   _________________   _____    (the line everyone is compared against)

Lowest three per head (go and ask):   ______________   ______________   ______________
Largest fall since last quarter:      ______________   checked by: ____________  on: ________

B. HEAVY REQUESTERS (desk only; minimum 10-15 tickets in the quarter before reading a row)
Requester (desk use)  Dept      Tickets   Categories: one / spread   Proxy?   Reading                  Action
____________________  _______   _______   ________________________   ______   ______________________   __________________
____________________  _______   _______   ________________________   ______   ______________________   __________________
____________________  _______   _______   ________________________   ______   ______________________   __________________
Requester fields corrected at first touch this quarter: ______

C. BEFORE THIS LEAVES THE DESK
   [ ] Every department row has a headcount and the source is dated
   [ ] Every reading rests on the category split, not the total
   [ ] No requester is named in anything circulated
   [ ] The quietest departments have been visited or phoned, and the answer recorded
   [ ] Technician-level cuts, if any, rest on 30-50 closed tickets and are for coaching

Grace took the department section of the sheet to the regional manager the following week. Harbor Street's row read "six old tills; 190 of 310 tickets; refit removes most of it" and there were no names on the sheet anywhere. The refit, which had slipped twice, was scheduled within the month. The store's count fell to a little under the chain rate by the end of the next quarter. Femi was still logging everything, now with the cashier's name in the right field. Nobody ever asked what was wrong with him again, which was correct, because nothing had been.

Frequently Asked Questions