What the Queue Already Knows About the Company

Friday, 15:30, at Meridian Parts. Dana runs a desk of three and is doing the weekly tidy of the queue. That mostly means closing tickets that were fixed on Tuesday and never marked. The list happens to be sorted by the requester's department. Because of that, she notices that finance raised eleven tickets in the last two working days of the month. It did that last month, and the month before that. Sales has four tickets this week that begin "how do I" and end with the name of the new expenses system. A warehouse starter who began on Monday has a ticket from Monday asking for access to everything, still open. The quoting tool has nine tickets this month that say "frozen". Every one of these was handled properly: picked up, fixed, closed with a note. Nobody has asked what they have in common.

What they have in common is that none of them was an IT fault. The finance tickets are a month-end process colliding with a report that was never built for month-end. The sales tickets are a training gap. The warehouse ticket is a handover between HR and the desk that failed. The quoting tool is a bad tool. The desk fixed all of them, one at a time, correctly, and will fix all of them again next month. That is because the desk fixes tickets and nobody in the building is fixing the things that make them.

Organisational intelligence, as this series uses the term, is what the queue knows about the organisation rather than about the desk. It covers the processes that stall, the teams that were never trained, the tools that fail, and the departments that cannot keep up. It is read from the patterns across many tickets rather than from any one of them. This article is part of our Ticket Data as Organisational Intelligence series. The series covers the signals, the evidence for each, and how to carry a finding to the person outside IT who can act on it. It also covers the quarterly review in which leadership hears what the queue said. This first article is the overview: what the queue sees, what kinds of signal it carries, and the one rule that keeps the reading honest.

This article covers why the queue sees what nobody else sees, the ticket that is not about IT, and the five kinds of signal. Next come telling a signal from noise, the four cuts that read the queue beyond IT, and the privacy line. Then come a picture of the patterns and the faults behind them, and a first look at taking a signal to its owner. A short war story and the signal catalogue to copy finish the article.

Why the Queue Sees What Nobody Else Sees

The help desk is the only team in the organisation that talks to every other team every week, about the moments when their work stopped. HR hears from a department once a year in a survey. Finance sees it as a budget line. The management team sees it as a slide. The desk sees it on Tuesday at ten past nine, in the words of the person it happened to. The record has a timestamp, a department and the name of the system involved. No other team has that view, and most of them do not know it exists.

A ticket is a small, dated record of friction. Someone wanted to do their job and could not, and wrote down why, at the moment it happened, to the one team obliged to answer. Multiply that by every requester for a quarter and the queue is a diary the organisation keeps without knowing it. Every entry was written by a different hand about the same building. Read one entry and you have a ticket. Read the diary and you have the organisation's week.

The view is only as complete as the queue. Take a desk where half the requests arrive by a tap on the shoulder, or a direct message to the technician who fixed the scanner once. That desk is reading a diary with pages missing. The missing pages are not random: they are the departments who found a faster route. The one-queue idea in One Queue, Many Doors exists for the desk's sake. It turns out to be the precondition for this whole series. If every door into the desk lands in one place, the diary is whole. That happens in QuerySolv, where the web form, the e-mail, the chat line and the hallway request logged on the spot all become the same kind of ticket. If the doors do not all land in one place, the desk is reading the organisation through whichever departments still bother to write.

The Ticket That Is Not About IT

Most tickets are about IT, and this series is not about those. A broken laptop, a failed update, a printer that jams, a password forgotten: the desk owns them, fixes them, and reads them with the methods in the hotspot articles. The tickets this series is about are the ones wearing an IT costume. The subject line says "can't get into the system"; the cause is that the access request was never sent. The subject line says "report won't run"; the cause is a report being run on the one afternoon a month the system is busiest. The subject line says "how do I"; the cause is that nobody was shown. Each arrives at IT because IT is the place you can raise a ticket. You cannot raise a ticket against your own department's process. (People have tried. The desk gets those too.)

The desk fixes the ticket and the cause stays where it was. This is not a failure of the desk; fixing the ticket is the job and should be done well. The failure is that nobody reads the fixes together. Twelve "can't get into the system" tickets from twelve new starters are twelve tickets to the technician who took them. They are one finding to anyone who lines them up. The finding is that starters arrive before their access does. The finding has an owner. The owner is not in IT, and the owner has never seen the twelve tickets because they went to the desk.

The move this series teaches is small. Keep fixing the tickets. Once a month, or once a quarter, line them up and ask of each pile: if the organisation were working as designed, would this pile exist? Where the answer is no, the pile is a signal, and the rest of the series is about what to do with it.

The Five Kinds of Signal

Five kinds of signal account for nearly everything the queue says about the organisation. Three of them, the broken process, the training gap and the bad tool, get an article each in this series. The other two, the under-resourced team and the wave of starters, are read the same way and handed to different owners. They are covered here.

The broken-process signal is a run of tickets caused by a step in some department's way of working rather than by anything technical. It might be the approval that sits in one inbox for a week, or the form nobody can find so the request arrives as a free-text e-mail. It might be the month-end crunch, or the handover between two teams in which the ticket is the thing that fell through the gap. In the queue it looks like tickets whose age is spent waiting on someone outside IT, tickets that cluster on the same working days each month, and fixes that are never technical. The Broken-Process Signal owns it.

The training-gap signal is the same how-do-I question from the same team about the same task, with nothing broken and the answer identical every time. It arrives after a rollout whose training was a video sent on launch day, from a team whose one expert left, and from every new starter in their first week. In the queue it is the subject line that begins "how do I", "where is" or "is it possible to", and a resolution note that is an explanation rather than a change. The Training-Gap Signal owns it.

The bad-tool signal is one application generating a share of the tickets out of all proportion to the number of people who use it. There is the same error text, the same workaround in every resolution note, and a fix the desk could do in its sleep. That fix never prevents the next one. Finding the application in the numbers is the subject of Application and Process Hotspots. What to do when the owner is outside IT and the vendor is outside the building is the subject of The Bad-Tool Signal.

The under-resourced team is the signal nobody expects the help desk to carry. A team that is short of people raises more tickets per head than its neighbours, of every type. There are more how-do-I because there is nobody beside them to ask, and more "urgent" because every deadline is already late. There are more access requests because people are covering roles that are not theirs, and more tickets at seven in the evening. No single ticket says "we are three people short". The per-head rate says it, and the desk is usually the first place it is visible as a number rather than a mood. This one goes to the team's manager as a count, gently, and then, if it persists, to the quarterly review. The method for the per-head cut is in Per-Department and Per-User Patterns.

The starter wave is the burst of tickets that follows every intake of new people. It includes the access that arrived after the start date and the laptop that was not ready. It includes the five how-do-I questions everyone asks in week one and the manager who did not know what to request. It is partly a process signal and partly a training signal. It earns its own place because its owners are different, HR and the hiring managers. It also earns its place because it is the easiest of the five to predict. The start dates are known weeks ahead. The tickets arrive on schedule.

Signal or Noise

Not every pile is a signal, and a desk that announces one at every bump will be ignored by the second quarter. Three tests separate a pattern worth carrying from one worth watching. It repeats: the same pile in two consecutive periods, or two runs of the same process, not one bad week. It clusters: on a team, a system, a task or a time, so that the pile has a shape you can name. And it survives normalisation. A department that raises more tickets because it has more people is not a finding. So divide by headcount before deciding anything, and divide by the number of users of a system before blaming the system.

Four things look like signals and are not. A bad week is a bad week: a storm, a failed update, a flu that took out half of accounts. A rollout you did yourself produces a wave that is yours, not the organisation's. The desk should expect it and plan for it rather than report it. Seasonality, the September hill and the quiet August, is a pattern in the calendar rather than a fault, and Trends and Seasonality shows how to see it coming. And one heavy requester is a person, not a pattern. Reading them as a pattern crosses the privacy line below before the reading has begun.

The table is a filter, not a verdict. A pile that passes becomes a candidate finding, with the evidence still to be gathered the way the signal articles describe. A pile that fails goes on the watch list and gets looked at again next quarter. Most of what the queue says in any one month is noise. The patient part of this work is waiting for the second month.

Reading Beyond IT: The Four Cuts

Four cuts turn a quarter of tickets into a reading of the organisation. All four are a spreadsheet exercise on an export. Include ticket number, opened and closed dates, the requester's department, the system or application named, the ticket type, and the subject line. Include the time spent waiting on someone outside the desk if the tool records it. If you run QuerySolv, the REST API will hand that quarter to a spreadsheet or a script. Most tools have an export of some kind, and the reading is the same however the rows arrive.

The first cut is by department, divided by headcount. A department raising three tickets per person per quarter beside departments raising one is telling you something. The something is one of the five signals. The per-head table and its cautions are in the per-department article linked above, which this cut leans on rather than repeats. Read the department's tickets by type next. All how-do-I is a training gap, all access is a process, all one application is a tool, and all of everything at once is a team under strain.

The second cut is by system. Every ticket that names an application gets the application's name in a column. The pile per application, divided by the number of people who use it, is the bad-tool reading. One application at the top with a repeating error is a fault. One application at the top with requests rather than faults is a design that makes tickets. The distinction, with the method for finding it, belongs to the hotspot article linked above.

The third cut is by calendar: working day of the month, day of the week, and week of the year. A hill on the same working days every month is a process with a deadline. A hill every Monday is a weekend job or a Monday process. A hill in September is enrolment, or the starter wave, or both. The calendar cut is the one that finds broken processes, because a process is a pattern in time and leaves its footprints on the same dates.

The fourth cut is by wording, and it is the one most desks skip because it is not a column. Search the subject lines and first messages for "how do I", "how can I", "where is", "is it possible", "still waiting", "again", "as discussed" and "urgent". The first four are training. "Still waiting" and "again" are process, or a desk problem of your own, and either way worth knowing. "As discussed" means the request was made somewhere the queue cannot see. "Urgent" from one team, every week, is a team under strain or a process that makes every deadline late. A subject line that just says "again" is a one-word audit report. Tagging these at close is the cheapest way to make the fourth cut a column by next quarter, and Categorize at Close, Not Just at Open says how.

The Privacy Line

The line is absolute: the reading names patterns, categories, teams and systems, and never a person. Not the requester who raised the most tickets. Not the manager whose inbox holds the approvals. Not the technician who closed the fewest. Not as an aside, not in a meeting, not in the appendix. A finding that cannot be stated without naming a person is not a finding yet; it is gossip with a chart.

The reason is not politeness, though politeness would be enough. The queue works because people trust it. They write down what went wrong, in their own words, at the moment it went wrong, because they believe the record exists to get the thing fixed. The first time a finding is read aloud that says "Priya in lending raised nineteen tickets", every requester in the room learns that the queue is a file on them. The diary stops being written honestly. The signal dies with the trust, and it does not come back for the asking. A desk that names one person has traded a quarter's insight for a year's silence.

Two rules make the line practical. First, the smallest unit a finding names is a team, a role, a process or a system. Where a team is so small that naming it names a person, the finding names the process or the system instead. "Approvals for the warehouse stall for a week" is a finding. "Marcus takes a week to approve" is not, even when both are true. The first will get the step fixed while the second gets the desk uninvited. Second, per-person counts exist only inside the coaching rule for the desk's own technicians, read with the person, never ranked, and never below a minimum sample. Dashboards That Motivate Instead of Surveil holds that rule, and nothing in this series loosens it.

Expect to be asked for names, kindly, by people who mean well. "Which person is it?" is the most natural question in the room. The answer is prepared in advance: "The review reads patterns, not people, because the queue only works if people trust it. Here is the process, here is the count, here is the ask." Say it the same way every time and after two quarters nobody asks. The last article in this series restates the line because the quarterly review is the moment it is most tested.

Patterns and the Faults Behind Them

The picture below lays the common patterns beside the faults that usually sit behind them, with the owner of each fault written on the arrow between. Six patterns are drawn for five signals because the broken process shows up in the queue in more than one shape. The hill on the same days, the ticket stuck waiting on an approval, and the starter idle on day one are all process faults with different owners. Read it left to right: what the queue shows, who can change it, what it usually means. The word "usually" is doing honest work. Every arrow is a hypothesis until the evidence in the signal articles confirms it.

The owner column is the point of the picture. None of those owners is in IT. The desk's job is to see the pattern, prove it, and carry it across. The fix belongs to someone who has never opened the queue and should not have to.

From a Signal to Its Owner

A signal that stays on the desk is a hobby. Every finding in this series ends in the hands of a person outside IT who can change the thing. That might be the manager who can schedule training, or the process owner who can move a deadline or add a role to an approval list. It might be the application owner who can call the vendor with some weight behind the call, or HR who can send the access request a week early. The desk brings a count, a cost in hours, three example tickets with the names removed, and one small ask. The craft of doing that without making an enemy, which is most of the craft, is Taking the Signal to the Owner.

The desk also does its own part first, every time. A knowledge base article for the how-do-I, a request form with a start-date field for the starter, a known-error note for the tool's workaround. These make the tickets cheaper and they do not make them stop. The trap is that a desk efficient enough at absorbing a fault makes the fault invisible to the only person who could remove it. Do the desk's part. Then carry the signal anyway. The queue has never once asked why a ticket exists; that is your job.

A Short War Story: The Monday Records at Harbourview Clinic

Harbourview Clinic's desk of two closed between twenty-five and thirty tickets a quarter from reception that read "patient record won't save", for three quarters. Each one was fixed by clearing a stuck form and re-entering the record. That took the technician about twenty minutes and the receptionist about the same. Yusuf, the newer of the two, put a quarter's tickets in a spreadsheet to practise the calendar cut. Every one of them was from reception, every one was on a Monday, and all but two were between eight and half past nine in the morning. The records system had gained a mandatory field, added by the clinic's own practice administrator to satisfy an audit. The weekend's paper notes, typed up first thing on Mondays, had been failing on it ever since. Nobody had told reception the field existed, because the administrator had assumed the system would. Yusuf took the count and three example tickets to the practice manager, who sent a two-line note to reception that afternoon. The following quarter the desk closed four. The cost was roughly thirty hours of desk time and as many of reception's over nine months. That was for a fault that took one sentence to fix once anyone saw it as one thing. The desk had been closing a training gap one Monday at a time, and had become very good at it.

The Signal Catalogue

The catalogue below is the reference. It covers the five signals, what each looks like in the queue, the test that confirms it, who outside IT owns it, and the shape of the ask. Under it is the one-page sheet to fill in each quarter, one line per candidate finding. That is the working document the rest of this series builds on. Fill the sheet from the four cuts, run each line through the signal-or-noise tests, and carry the survivors into the signal articles for their evidence.

SIGNAL SHEET — ONE QUARTER, ONE PAGE
Desk: ______________   Quarter: ____________   Read by: ______________   Tickets in export: ______

A. THE FOUR CUTS DONE
   [ ] by department, divided by headcount
   [ ] by system, divided by the number of users
   [ ] by calendar: working day of month, weekday, week of year
   [ ] by wording: how do I / where is / still waiting / again / as discussed / urgent

B. CANDIDATE FINDINGS (one block each; a team, system or process, never a person)
   Pattern seen: ________________________________   Count: ______   Period: ___________
   Repeats in two periods? Y / N      Clusters on: ______________________
   Survives per-head or per-user check? Y / N
   Likely signal: process / training / tool / team / starters
   Owner (role, not name): ______________________   Desk's own part done? Y / N
   (repeat for each candidate; expect three to eight)

C. SURVIVORS CARRIED FORWARD
   To evidence (which signal sheet): ________________________________
   To the watch list (look again next quarter): ______________________

D. THE PRIVACY CHECK, BEFORE THIS SHEET LEAVES THE DESK
   [ ] no requester named anywhere on the sheet
   [ ] no approver or manager named; roles only
   [ ] no per-technician figure outside the coaching rule
   [ ] any team small enough to identify a person is replaced by its process

Dana filled in the first sheet at Meridian Parts the following Monday, from the export she already had. Four candidates; three passed. The warehouse starter was one ticket and went on the watch list, where two more joined it at the next intake and made it a finding. None of the four had ever been an IT problem, and all four had been the desk's problem for a year.

Frequently Asked Questions