Evidence Over Anecdote: Why 'We Are Swamped' Never Wins
Tuesday, 14:10, in the small meeting room at Tollgate Foods. Marta runs the support desk, two technicians and herself, and she has been given eight minutes of the budget round to make the case for a third person. She has prepared, in the sense that she has thought about it on the way in. "We're swamped," she says. "The queue never goes below a hundred, people are staying late, and if we don't get another pair of hands we're going to lose someone." Gareth, the finance director, nods, because he has nodded at this sentence four times since Monday. "Everyone who has sat in that chair this week has been swamped," he says, not unkindly. "How many tickets did you get last month, and how long does one take?" Marta says "a lot" and "it depends", both of which are true, and the meeting moves on to the warehouse's forklift.
An anecdote is a true story about one moment: the Friday the queue hit two hundred, the director who waited four days for a laptop, the technician who was still there at eight. It is vivid, it is uncheckable, and it has a short life, because the next person in the chair has one too. Evidence, in this series, is a number that comes out of the ticket system, covers a stated period, and could be recomputed by anyone with access to the same tickets. Anecdotes illustrate. Evidence decides. This article is part of our Using Ticket Data to Justify Resources series. It is the foundation the other five stand on: what to count, how to count it honestly, and how to say it. The result is one paragraph a finance director can check.
It covers why the feeling fails and the sum does not, then what a capacity sum is. Next come the five numbers that make up the evidence set, each in turn, and a worked example from one fictional desk, in hours. Then it covers how the five become one paragraph. A short war story and the evidence list to copy finish the article.
Why "We Are Swamped" Fails
"We are swamped" fails because it is a feeling, and nobody across the table is funded to buy feelings. Sales is swamped. The warehouse is swamped. The finance director, who has been in budget meetings since Monday morning, is more swamped than any of them and would like that noted. The sentence is true of the desk, and it is also the one sentence that cannot tell the desk apart from anyone else asking for money this week.
The second failure is that a feeling cannot be checked, and a decision-maker is right to distrust what cannot be checked. Gareth cannot open the feeling, look at the months it covers, and see whether it is getting worse. He can do all of that with a number. A desk that offers a feeling is asking him to take its word for it, which he might. A desk that offers a number is asking him to do arithmetic, which he can do alone at his own desk. People believe their own arithmetic in a way they never believe anyone's word.
The third failure is the one nobody says out loud in the meeting: "swamped" has no size. Is the answer one more person, or two, or a different tool, or a protected week for one technician to fix the thing that generates a third of the tickets? A feeling cannot be sized, so the ask attached to it is a guess. A guess with a salary attached to it is the easiest thing in the building to decline. Finance directors decline guesses for a living. They have had practice.
None of this means the feeling is wrong. In my experience it is usually right, which is what makes losing the argument so irritating. The desk is swamped. The numbers that prove it have been sitting in the ticket system the whole time, and nobody asked them to come out.
What a Capacity Sum Is
A capacity sum is one line of arithmetic: the hours of work the tickets needed in a month, set against the hours the desk had to do them. The hours needed are tickets opened times the typical hands-on time of one ticket. The hours available are what is left of the technicians' month after leave, meetings, projects and everything that is not a ticket. If the first is bigger than the second, the difference is the gap, and the gap does not vanish. It becomes backlog, unpaid evenings, or fixes done faster than they should have been, in some mixture the desk can usually estimate.
The sum works because it can be wrong. Gareth can look at each term and ask how it was measured, and the desk can show him. He can argue that forty minutes a ticket is high, and the desk can show the sample it came from. He can argue that the technicians should have more hours available, and the desk can show the leave calendar. A number that can be argued with is a number that can be agreed with. A feeling can only be shared or not.
The sum also sizes the ask, which the feeling never could. A gap of ten hours a month is not a hire; it is a conversation about which small thing to stop doing. A gap of ninety hours a month is most of a person, and the case writes itself. The full arithmetic, including what one more person actually changes, is the subject of The Headcount Case. This article is about where the inputs come from and how to get them without fooling anyone, yourself included.
The Evidence Set: Five Numbers, Five Questions
The evidence set is five numbers, each answering one question the person across the table will ask, whether or not they say it aloud. Volume answers "how much work arrives?". Hours per ticket answers "how much work is each one?". Backlog growth answers "are you keeping up?". Response decay answers "are the users feeling it?". The oldest ticket answers "what does falling behind look like in one real case?". The first two make the capacity sum. The next two prove the gap is real and not a rounding error. The last one turns it into something the room will remember.
| Number | The question it answers | Where it comes from | What it must not be |
|---|---|---|---|
| Volume | How much work arrives each month? | Tickets opened per month, every channel, at least three months | Tickets closed; a single busy month; a count that leaves out walk-ups |
| Hours per ticket | How much work is each one? | Median hands-on minutes from a random sample of closed tickets | Elapsed time from open to close; an average pulled up by three monsters |
| Backlog growth | Are you keeping up? | Tickets open at each month end, month over month | The size of the pile on one day; tickets parked waiting on a vendor |
| Response decay | Are the users feeling it? | Median time to the first human reply, per month, over the same months | The automatic acknowledgement; a target you have not agreed |
| The oldest ticket | What does falling behind look like? | The oldest open ticket that is old for lack of hours, with its story | One the requester abandoned; one waiting on a supplier |
Five is enough, and the temptation to add a sixth should be resisted. The evidence set is not a scorecard; the scorecard for running the desk is a different document with a different purpose, and the metrics series in this library owns it. The evidence set is a case, and a case has exactly as many numbers as the argument needs. A case with twelve numbers is a report, and reports get filed.
Volume, Counted the Same Way Every Month
Volume is tickets opened per month, over at least three months and preferably six, counted the same way each time. Opened, not closed: the closed count depends on how hard the desk worked, which is the thing under discussion, while the opened count depends only on what arrived. The rules for a count that two people would get the same answer to are in Counting Tickets Properly. They include what to do with duplicates, merges and spam. The evidence set follows them exactly, because the first question Gareth will ask about four hundred tickets is "what counts as a ticket?".
Count everything that was work. There is the walk-up at the desk, the phone call, the chat message. There is the e-mail sent to a technician's own address because the technician was helpful once. All of it is work the desk did and none of it is in the count unless somebody logged it. The number that proves the desk needs help is, reliably, the number nobody wrote down, a failure described in The Seven Ways Support Quietly Fails. If the desk has not been logging walk-ups, start on the day you read this, and say in the case that the earlier months are undercounted. An honest undercount strengthens a case. It does not weaken it.
Separate the tickets that were never touched by a person. Alerts that the monitoring opened and closed on its own, automatic notices, test tickets: show them on their own line, excluded from the hours. Tickets opened by one computer and closed by another are a conversation between two computers, and should be counted as such. Then give the volume as a range with its wobble: "about four hundred a month, between three hundred and eighty and four hundred and twenty". A single figure makes every later comparison look sharper than the data is.
Hours per Ticket, From a Sample
Hands-on time is the number of minutes a technician actually spent on a ticket, across every touch, from the first read to the closing note. It is not the elapsed time from opened to closed, which includes nights, weekends, and four days waiting for the requester to say whether the fix worked. The distinction is the one most often got wrong, and getting it wrong in either direction loses the argument. Elapsed time makes every ticket look like a week, which nobody believes. A guess makes the whole sum a guess.
Most ticket systems do not record hands-on time unless technicians log it, and most technicians will not, so take a sample. Pick thirty to fifty closed tickets at random from an ordinary month, not the easy ones and not the famous ones. For each, reconstruct the minutes from the ticket's history. Each reply, note and status change carries a time. The technician who did the work can say "that was ten minutes" with reasonable accuracy if asked within a month. Write the minutes beside each ticket, sort the list, and take the middle value. That is the median, and it is the figure to use, because an average is dragged upward by the three tickets that took a day each. The case for medians over averages is made fully in Median and Percentiles, Not Averages, and it applies to effort as much as to elapsed time. Marta's sample of forty came out at a median of forty minutes, with a spread from eight minutes to just under six hours.
If you run QuerySolv, the event history on every ticket already holds each reply, internal note and handoff with its time. So the sample is a reading exercise rather than a reconstruction from memory. In any tool, write down the sample's date and size on the sheet, because the median drifts as the ticket mix changes. A figure sampled a year ago is a figure a sceptic can reject.
Keep the hands-on figure apart from the loaded one. The loaded figure spreads the desk's whole working month, meetings and all, across its tickets. It has a proper job in cost-per-ticket arithmetic, laid out in What ROI Means for a Help Desk. The capacity sum uses hands-on time on the needed side and puts the non-ticket hours on the available side, as a deduction. Using the loaded figure for the needed side counts the meetings twice, once in each column, and a finance director will find that in about a minute.
Backlog Growth, the Slope Not the Pile
The backlog is the set of tickets open at a moment in time, and its size on any one day says little by itself. A desk that opens four hundred tickets a month and holds sixty open is in good shape; the sixty are simply this week's work. What the evidence set wants is the slope: the open count at the end of each month, set beside the month before. If the line rises steadily, the desk is doing less work than arrives, and the slope is the gap measured in tickets rather than hours.
Check that the growth is real before you present it. Tickets waiting on a requester who has gone quiet, or on a vendor, are open but are not waiting for the desk's hours. A reviewer who finds forty of them in the backlog will discount the rest. Show them on their own line, in the same age bands the desk's aging report already uses. The backlog growth figure the case uses is the growth in tickets that are waiting for a technician. It is a smaller number than the raw count and a far harder one to argue with.
Then cross-check it against the capacity sum, because the two measure the same gap in different units. At Tollgate the backlog was growing by about nineteen tickets a month, which at forty minutes each is about thirteen hours. The capacity sum said the gap was around twenty hours in an ordinary month. The seven-hour difference is the overtime and the hurried fixes, which is plausible and which Marta wrote down as such. If the two figures disagree wildly, one input is wrong, and better that the desk finds it than the meeting does. The cross-check is the evidence auditing itself, and it is free.
Response Decay, the Number the Users Feel
First response time is the time from a ticket being opened to the first reply from a person, not the automatic acknowledgement, which is a receipt rather than a response. Take the median per month, over the same months as the volume. When a desk falls under capacity, this is the first number to slip. Reading and acknowledging new tickets is the task that gets deferred when everyone is heads down in old ones. The decay is slow and nobody on the desk notices it, which is precisely why it is in the set.
Response decay matters to the case because it connects the gap to people outside the desk, including the people in the meeting. A gap of twenty hours is abstract. "A person in finance who raises a ticket at nine now hears from a technician after lunch; in the spring it was before the morning break" is not abstract, and it is Gareth's own staff. At Tollgate the median had gone from an hour and a half to over three hours in six months. Nobody had complained. People rarely do; they stop raising tickets instead, and then the volume figure starts lying too.
Show the trend, not a target. The evidence set is not the place to propose what the response time ought to be, and the case does not need it to; the decay itself is the point. Where the desk has agreed targets, the gap between them and the trend is useful. But designing those targets is a separate subject with its own series, and a budget meeting is not where it should start.
The Oldest Ticket, With Its Story
The oldest open ticket is the one piece of the evidence set that is a story, and it is there on purpose. Four numbers persuade the head; one specific ticket persuades the room. At Tollgate it was ticket 20318, a request for a shared mailbox for the new depot team, raised ninety-four days earlier. It had been touched four times, each time put back down for something more urgent. The depot had been running its deliveries from one driver's personal address for a quarter. That sentence did more in the meeting than the table did, and the table is what made the sentence safe to say.
Choose it carefully, because the wrong oldest ticket loses the room as fast as the right one wins it. Not the one that is old because the requester never answered. Not the one waiting on a supplier's part. Not the one that is open because nobody can decide whether it is in scope. The ticket you want is old for one reason only: the desk did not have the hours. Tell it in three sentences, with the number, what it is, and what the delay has cost the person who raised it. Every budget meeting remembers one thing, and it is never the median.
Remember: every number in the evidence set comes from the desk's own tickets and covers a stated period of at least three months. Anyone with access to the same tickets could recompute it. Hands-on time, not elapsed time. Medians, not averages. Ranges, not points. No number from anywhere else.
The Worked Example at Tollgate Foods
Here is Marta's evidence set for the six months before the second meeting, at Tollgate Foods, the fictional desk this article uses for its arithmetic. Hours needed are tickets opened times the sampled median of forty minutes, which is two thirds of an hour. Hours available are two technicians at about a hundred and thirty hours each for ticket work after leave, meetings, projects and the daily admin. That total drops to about two hundred and five in a month when one of them takes two weeks off. Month four was that month.
| Month | Tickets opened | Hours needed | Hours available | Gap (hours) | Open at month end | Median first response |
|---|---|---|---|---|---|---|
| 1 | 395 | 263 | 260 | 3 | 61 | 1.5 h |
| 2 | 405 | 270 | 260 | 10 | 78 | 1.7 h |
| 3 | 410 | 273 | 260 | 13 | 99 | 2.1 h |
| 4 | 398 | 265 | 205 | 60 | 117 | 2.6 h |
| 5 | 420 | 280 | 260 | 20 | 140 | 2.9 h |
| 6 | 412 | 275 | 260 | 15 | 156 | 3.2 h |
Read it as a sceptic would. Volume is steady, around four hundred, so nothing unusual arrived; the desk is not recovering from an outage. The gap is small in an ordinary month, ten to twenty hours, and large in the leave month. It is never negative, which is the problem. A desk with no slack in a good month has nowhere to put a bad one. The backlog rises every month by about nineteen tickets, and the first response median doubles. The oldest ticket is ninety-four days old. Each column alone could be argued away. Together they describe one desk doing slightly less than arrives, every month, and the arithmetic of "slightly less, every month" is the whole case.
Notice what the table does not contain. There is no salary and no rate, because hours are what the desk can prove and currency is what finance can add. There is no comparison with other organisations, because the moment a number from elsewhere enters the argument moves to whether elsewhere is like here, and it never is. There is no satisfaction score, because Tollgate's had not moved yet. And there is no percentage of anything, because "the backlog has grown by a hundred and fifty-six percent" is the kind of sentence that gets asked "of what?".
Turning Five Numbers Into One Paragraph
The evidence set is presented as one paragraph, spoken or written, and it should fit in a single breath. Marta's was: "The desk received about four hundred and ten tickets a month over the last six months, each taking a median of forty minutes of technician time, which is roughly two hundred and seventy-five hours of work a month. Two technicians have about two hundred and sixty hours a month for ticket work after leave, meetings and projects, and about two hundred in a month when one is away. The backlog has grown by about nineteen tickets a month for five months, from sixty-one to a hundred and fifty-six, and the median time to a first human reply has doubled since the spring, from an hour and a half to over three. The oldest open ticket is the depot team's shared mailbox, raised ninety-four days ago."
There is no adjective in it, and every number can be traced to a line on the sheet. It is longer than "we're swamped" and it is the version that survives the question "how do you know?", because the answer to that question is "here is the sheet". How do you say it so that a non-technical reader hears a business problem rather than a queue problem? That craft is in Translating Tickets Into Business Language. The evidence paragraph is the raw material for it.
Keep the evidence and the ask in separate sentences. The paragraph above contains no request; it describes a gap and stops. The ask, whether it is a person, a tool, or a protected week, comes next and is built in the three articles that follow this one, each on its own arithmetic. A paragraph that mixes the evidence with the ask invites the listener to argue with the ask while the evidence is still being read. The evidence deserves a moment of silence first. (It rarely gets one. Ask for it anyway.)
A Short War Story: The Second Ask at Ashgrove Housing
At Ashgrove Housing, a desk lead called Dev asked for a third technician in the spring budget round. His case was "the team is drowning and we are going to lose people". He was told, reasonably, that the whole organisation was under pressure and he should come back with a case. He came back in the autumn with six month-end counts. They showed tickets opened, a sampled median of thirty-five minutes a ticket, and a backlog that had grown from forty to two hundred and ten. The first-response median had gone from under an hour to most of a working day. The hire was approved in the same meeting, by the same people, without a follow-up question. The six months between the two asks had cost the desk about a hundred and seventy tickets of backlog. They had cost something over a hundred hours of unpaid evenings. And they had cost one technician who left in August and whose replacement took a quarter to become useful. Every number in the autumn case had been in the ticket system in the spring. The case that wins in the autumn would have won in the spring, if anyone had counted.
The Evidence List
The sheet below is the evidence set as a form, one page, filled in at each month end. The first time takes an afternoon, mostly for the hands-on sample and for working out which saved searches give the counts. After that it is ten or twenty minutes a month. Fill it in for at least three months before any ask, six if you can, and keep the completed copies. The stack of them is the trend, and the trend is what the headcount, tooling and time cases are built from. Section G is the checklist that stops the sheet lying, and a sheet does not leave the desk until every box is ticked.
THE EVIDENCE LIST — ONE PAGE, FILLED AT MONTH END Desk: ______________ Month: ____________ Prepared by: ______________ A. VOLUME A1 Tickets opened this month (every channel, walk-ups logged) ..... ____ A2 Of which opened and closed by a system, shown but excluded ..... ____ A3 Six-month range: lowest ____ highest ____ middle ____ B. HOURS PER TICKET B1 Sample size (random closed tickets, an ordinary month) ......... ____ B2 Median hands-on time per ticket ................................ ____ min B3 Spread: shortest ____ longest ____ B4 Date the sample was last redone ................................ ________ C. THE CAPACITY SUM C1 Hours needed (A1 minus A2, times B2 in hours) .................. ____ h C2 Technicians ____ times hours each for ticket work ____ ........ ____ h C3 Leave, training, projects, admin taken off this month .......... ____ h C4 Hours available (C2 minus C3) .................................. ____ h C5 Gap (C1 minus C4; a negative gap is slack) ..................... ____ h D. BACKLOG D1 Tickets open at month end ...................................... ____ D2 Same figure last month ____ change ____ D3 Of D1, waiting on a requester or a vendor ...................... ____ D4 Six-month trend, change per month in tickets ................... ____ D5 D4 times B2 in hours, compared with C5 ......................... ____ h E. RESPONSE E1 Median time to first human reply this month .................... ____ E2 Same figure six months ago ..................................... ____ F. THE OLDEST TICKET F1 Ticket number ________ age ____ days F2 What it is, in one line ........................................ ______________ F3 Why it is old (lack of hours, not waiting on anyone) ........... ______________ F4 What the delay has cost the requester .......................... ______________ G. BEFORE THIS LEAVES THE DESK [ ] Every number can be recomputed from the ticket system [ ] Walk-ups and direct messages are in A1, or the undercount is noted [ ] B2 is hands-on time, not elapsed time, and B4 is within a year [ ] D5 and C5 roughly agree, or the difference is explained [ ] F1 is old for lack of hours, not because someone went quiet [ ] No number from outside this desk
Marta filled the sheet in for six months, back-dated from the month-end reports, in one long afternoon, and read the paragraph above at the next budget round. Gareth asked how the forty minutes had been measured, and she passed him the sample list. He did not say yes in that meeting. He said "bring me the headcount sum", which is the next article in this series. From a finance director, that is what the beginning of a yes sounds like.
Frequently Asked Questions
We only started using a ticket system recently. How much history do I need?
Our ticket system does not record time spent. How do I get hours per ticket?
Should alerts that the monitoring opens and closes automatically be in the volume?
Why the median rather than the average for hours per ticket?
Do my own hours as the desk lead count in hours available?
What if the finance director says the numbers are self-reported?
From the QuerySolv team: we build self-hosted help desk software for Windows. QuerySolv runs as one Windows service on your own network. It takes requests by web form, e-mail, live chat, social messages and REST API. It is licensed once per installation rather than per agent per month. The free trial runs the full product for 30 days.
