Counting Tickets Properly: Created, Closed and Open

Monday, 09:10, at Redbrook Engineering. The operations manager, Clare, has sent the desk a one-line e-mail: "How many tickets did we do last month?" Tom, who runs the desk, has three answers in front of him and does not like any of them. The volume report says 612. The closed-tickets report says 587. The counter at the top of the queue says 168. It said 143 at the start of the month, which is a fourth number nobody asked for. Ravi, at the next desk, offers a fifth: "About seven hundred, if you count the e-mails." Tom writes back "612" and spends the rest of the morning worrying. Clare might compare it with the 587 that somebody else sent her in March.

Ticket volume is the number of tickets a desk handles in a period. The first thing to know about it is that it is not one number. It is three: how many tickets were created, how many were closed, and how many were open at a given moment. The three answer different questions and move for different reasons. They are routinely reported as if they were interchangeable, which is how a desk earns a reputation for not being able to count. This article is part of our Ticket Volume Analysis series. It is the foundation the rest of the series stands on. Before you read a trend, a pattern or a warning in the volume, you need to know exactly what you counted.

It covers the three counts and how they fit together, then the period boundary, by day, week and month. Next come resolved versus closed and what a reopen does to the count, then duplicates, merges, spam and test tickets. Then come counting by channel, the count that changes when the definition changes, and closed tickets per technician, handled carefully. The reconciliation line that proves the counts agree, a short war story, and the volume definition sheet to copy finish the article, in that order.

Three Counts, Not One

The created count is the number of tickets whose creation time falls inside the period. It measures demand: how much work arrived. Nothing the desk does changes it, apart from the way the desk logs things, which turns out to matter a great deal and has its own section below. When a manager asks "how busy were you?", created is the honest answer, because it is the one count that is about the organisation rather than about the desk.

The closed count is the number of tickets whose closing time falls inside the period, whenever they were created. It measures throughput: how much work the desk finished. A ticket created in March and closed in April is in April's closed count and March's created count. That is correct, not a mistake. Closed moves when the desk changes pace, when a backlog is dug out, when two people are on leave, and when someone decides to tidy the queue on a Friday afternoon. It is a number about the desk.

The open count is different in kind from the other two. It is not a count over a period at all; it is a snapshot, the number of tickets that were open at one instant. "How many tickets are open?" has a different answer at 09:00 and at 17:00, and neither is wrong. Open is the level in the tank; created is the water coming in; closed is the water going out. That is the whole analogy, and it gives you the only formula this article needs. The open count at the end of a period equals the open count at the start, plus created, minus closed. At Redbrook, 143 plus 612 minus 587 is 168, which is exactly what the counter said, and Tom's four numbers were never in disagreement. They were four different facts about the same month.

Report all three, say which is which, and never let one stand in for another. "We had 612 tickets" is a sentence a reader will interpret as whichever count suits them. If the open count rose from 143 to 168 in the same month, that reader is about to be surprised. "612 created, 587 closed, open rose from 143 to 168" is longer and cannot be misread. It also tells the story on its own: demand slightly outran the desk, and the queue grew by twenty-five. A number that needs a second e-mail to explain it was the wrong number.

The Period Boundary

Every count has a boundary, and the boundary is where the disagreements live. A ticket created at 23:50 on Sunday is in this week by the calendar and in next week by any desk that starts work on Monday. Take a ticket created at 17:30 on the last day of the month, by a requester in an office two time zones away. It might be in next month on the server and this month on their screen. Pick a rule, write it down, and apply it every time. The commonest sensible rule for a small desk is this: the period is defined by the server's clock. A week runs Monday to Sunday, and a month is the calendar month. The rule you choose matters less than having one.

Choose the period to match the question. A daily count is the right unit for watching the queue and spotting a spike, which is the subject of Volume as an Early-Warning System. But it is too noisy to read for anything else, because one quiet Thursday means nothing. A weekly count is the right unit for running the desk: rotas, cover, the Monday shape. A monthly count is the right unit for reporting upward, because managers think in months and because a month is long enough for the daily noise to cancel out. Keep all three; they are the same tickets added up differently.

Months are not the same length, and the difference is bigger than it looks. A month can have anything from nineteen to twenty-three working days. So a desk with perfectly steady demand will show a swing of about a fifth between its shortest and longest month. Someone will ask what went wrong in February. The fix is to report created per working day alongside the raw count. For example, 612 tickets in a month of twenty-one working days is about twenty-nine a day. That is the number to compare between months. A short month is not a quiet month. It is a short month.

The open snapshot needs its own boundary rule: take it at the same time every day, before the desk starts work, and write that time on the report. A snapshot taken at 08:00 shows what the desk is facing; one taken at 17:00 shows what it left behind. A series that mixes the two is a graph of when people happened to run the report. I set a reminder for 08:00 and ran it myself for a year. (The reminder was more reliable than I was, which is why it was a reminder.)

Resolved Is Not Closed, and a Reopen Is Not a New Ticket

Many tools have two end states. A resolved status means the desk believes the work is done. A closed status means the requester confirmed it or a waiting period ran out. The gap between them is the confirmation window, and it is explained in Resolved vs Closed: The Confirmation Window. For counting, the question is which one your "closed" count uses, because they can differ by a week and the difference piles up at the month boundary. Resolved is the better measure of the desk's throughput, since it is the moment the technician finished. Closed is the better measure of tickets that are definitely done. Pick one, call it by its name, and use it for every period.

A reopened ticket is a ticket that was resolved or closed and then came back, usually because the requester replied to say it was not fixed. It is the same ticket, with the same number, and it must not appear in the created count a second time. Some tools do count a reopen as a new event in a volume report. Some count it as a second closure when it is closed again. Test yours by reopening a ticket in a quiet week and reading the report. Count reopens on their own line, because they are a separate and useful signal, with their own article in Measuring Reopens Honestly. In QuerySolv, as in many tools, a requester's reply reopens a resolved or closed ticket by itself. So a desk that counts closures at the moment of the resolving reply will see a handful of them quietly un-close themselves the following week. The count was not wrong. The tickets changed their minds.

Duplicates, Merges, Spam and Tests

A duplicate is a second ticket about something the desk already has a ticket for. It may be raised by the same person who did not hear back, or by a second person about the same outage. Duplicates were created, so they belong in the created count, because they are real demand on the desk: someone had to read them. What they must not do is inflate the count silently. Record a separate line, "merged into another ticket", and report created both with and without it when the difference is large. Forty duplicates in a month is normal for a desk with a shared printer. Four hundred is an outage, or a desk that does not acknowledge tickets, and either way the number is telling you something.

A merge is the act of folding one ticket into another so that one record carries the whole conversation. Tools differ in what a merge does to the count. In some, the merged-away ticket is closed with a special status and still counts as closed. In others it disappears from the open count without appearing in closed. That breaks the tank formula and leaves you hunting for twelve missing tickets at month end. Test it once: merge two tickets, run the counts, and see where the second one went. Then write the answer on the definition sheet so nobody has to find out twice.

Spam, junk, out-of-office replies and mail loops are tickets too, in the sense that the tool created a record. They must come out of the created count or be shown on their own line. Otherwise the desk looks busier every time a mailing list goes wrong. The mail-loop case is the extreme version: two systems reply to each other all night and the desk arrives to three hundred tickets. It needs its own line on the report the morning it happens. Test tickets raised by the desk itself, while trying something, are the same problem at smaller scale. Exclude them by requester or by a tag. Make the exclusion part of the definition rather than something the report author remembers to do. The report author will not remember. I did not.

Tickets opened automatically by a monitoring system or another tool are real work. But they are a different kind of demand from a person asking for help, and they arrive in floods when something breaks. Count them on their own line by channel, which is the next section, so that a bad night for one server does not read as a bad month for the organisation.

Counting by Channel

The channel is the door a ticket came in through. That could be the web form, e-mail, live chat, a phone call logged by a technician, or a walk-up logged by a technician. It could also be a social message, or an integration that created the ticket by itself. Splitting the created count by channel tells you where the work comes from, which is the first question in any conversation about forms, portals or whether the phone should still be answered. Where every door leads to the same queue, as it does in QuerySolv and most ordinary help desk tools, the channel is a field on the ticket. In that case, the split is a filter rather than a reconciliation between systems.

The channels that are logged by a machine are counted exactly. The channels that are logged by a person are under-counted, always. The under-count is the most important thing to know about your channel split. A web form cannot be used without creating a ticket. A phone call can be answered, resolved in two minutes and never written down, and on a busy desk it often is. The rule that fixes this is simple to say and hard to keep: every request becomes a ticket, including the one solved in the corridor. The table below lists where each channel's count goes wrong and the fix.

Report the channel split as counts, not just shares. "A third of tickets came by phone" is less useful than "211 by phone, 290 by e-mail, 98 by form, 13 by chat". The shares shift when any one channel's count moves and nobody can tell which one did. The counts also expose the under-count. A desk that answers the phone all day and logs thirty phone tickets a month has a logging problem, not a quiet phone. How each channel is triaged is a different subject; counting is only about getting each door's number right.

The Count That Changes When the Definition Changes

The most dramatic change in volume I have ever seen on a report was caused by a desk starting to log its phone calls. Created went from about six hundred a month to about eight hundred and twenty in a single month. Nothing in the organisation had changed. The manager who read it asked whether a system had failed. The desk had done the right thing, logging what it had always been doing, and it had done it without drawing a line on the chart. The number was true before and true after. It was simply a different number, and the chart did not say so.

Definition changes are everywhere, and each one moves the count. Adding a department to the tool brings its tickets into the created count, as if demand had risen. Switching on a spam filter drops the created count, as if demand had fallen. Connecting a monitoring system adds a flood. Changing from resolved to closed as the "done" status shifts a week of closures across a month boundary. Merging two categories, moving from one tool to another, or starting to count walk-ups all do the same. None of these is a change in demand, and every one of them will be read as a change in demand by anyone who was not told.

The rule has three parts. Write the definition down, on the sheet at the end of this article, so there is a definition to change. When it changes, date the change and say what moved, in a note that lives with the report, not in someone's memory. Then draw a line on the chart at that date, and label it. Every reader should see that the count on one side is not comparable with the count on the other. Where you can, run the old definition and the new one side by side for a quarter. Then you can say "under the old counting this month would have been about 600". A line on a chart costs nothing. Its absence costs a meeting, and sometimes a budget.

Closed per Technician, Handled Carefully

The closed count can be cut by the technician who closed each ticket, and almost every desk does it. The report offers it, and the question "who is doing the work?" is a natural one. Cut it if you must, and treat the result with care, for two reasons. The first is that closed counts favour whoever takes the quick tickets. A technician who closes sixty password resets has not done more than one who closed twelve network faults. A desk that praises the sixty will shortly have nobody willing to touch a network fault. That effect, and the others like it, are the subject of Metric Gaming and Its Cures.

The second reason is sample size. A per-person count over a short period is mostly noise: who was on leave, who was on the phone rota, which week the big rollout landed. Do not read a per-person figure at all until the person has closed a reasonable number of tickets in the period, somewhere between thirty and fifty on a small desk. Read it over a quarter rather than a month. When you do read it, read it for coaching, never for ranking. The question is "what is this person's queue made of, and do they need help with it?", not "who is top?". A per-person closed count on a wall screen is a ranking whatever you call it, and it will change behaviour within a week, in the direction of the quick tickets.

The Reconciliation Line

Once a month, before any volume number leaves the desk, check that the three counts agree with each other using the tank formula, extended for the things that leak. Open at the start of the month, plus created, minus closed, minus tickets merged away, minus tickets deleted or excluded as junk, should equal open at the end of the month. If it does, the counts are consistent and you can report them. If it is out by more than a handful, something is being counted differently on one side. The usual suspects are merges that vanish without closing, a resolved-versus-closed mismatch, and reopens counted twice. There are also tickets moved to a department the report does not cover.

At Redbrook, Tom's first reconciliation was out by nine. Seven turned out to be tickets merged during a printer outage, which the tool removed from the open count without marking as closed. Two were test tickets Ravi had raised and deleted. Both went onto the definition sheet as rules, and the counts balanced the following month. Tom's report to Clare has carried the same four numbers in the same order ever since: created, closed, open at the start, open at the end. There is a fifth line for merged and junk. Nobody has asked him to explain a number since. They have asked him to explain other things, but not that.

The reconciliation is also the point at which to decide which counts go upward and which stay on the desk. For a brand-new desk, the first three numbers worth tracking at all are set out in First Metrics, and created, closed and open are among them. For an established desk, volume is one line on a scorecard whose other lines, and how to read them against each other, are owned by Defining Each Metric Exactly. This article's job ends when the three counts are right and agree. What they mean, over months and across departments, is the rest of the series.

A Short War Story: The Two Reports at Tollgate Foods

At Tollgate Foods, a new desk lead called Marcus inherited a monthly report whose headline figure was labelled "Tickets". It was, though nobody had written it down, the closed count. In his second month he began a backlog dig-out, and for two months the desk closed about three hundred more tickets than it received. The report went upward showing "Tickets" rising from 540 to 870. The operations director read it as demand surging. An outsourcing review was commissioned that took four people about forty hours of meetings. In the fourth month the dig-out finished, and closed fell back to match created. The report showed "Tickets" collapsing to 560. The same review concluded that the desk was now over-staffed for its workload. Marcus spent a fortnight rebuilding the report with three labelled counts and a reconciliation line. He spent a further afternoon explaining to the director that demand had been flat at about 550 throughout. A count that does not say which of the three it is will be read as whichever one suits the reader that month.

The Volume Definition Sheet

The sheet below is the written definition that the rest of the series assumes you have. Fill it in once, keep it with the reports, and change it only by adding a dated line to section F. It takes about an hour the first time, most of which is spent testing what your tool does with merges and reopens. The sheet is deliberately plain. Anyone who picks up the report after you should be able to read it and produce the same numbers.

VOLUME DEFINITION SHEET — ONE PAGE
Desk: ______________________   Prepared by: ______________   Date: ____________

A. THE THREE COUNTS
   A1 CREATED  = tickets whose creation time is in the period
      Includes:  [ ] duplicates   [ ] later merged   [ ] monitoring/integration tickets
      Excludes:  [ ] spam/junk    [ ] test tickets   [ ] mail loops and auto-replies
   A2 CLOSED   = tickets whose [ ] resolved / [ ] closed time is in the period
      A reopen counted as a new closure when closed again?  [ ] yes  [ ] no
   A3 OPEN     = snapshot of tickets not in a done status, taken at ____:____ each day
      Done statuses for this purpose: __________________________________

B. THE PERIOD
   B1 Clock used for boundaries: [ ] server  [ ] requester's local  [ ] other: ________
   B2 Week runs from ________ to ________     B3 Month = [ ] calendar month  [ ] other
   B4 Working days this month: ____   Created per working day reported?  [ ] yes

C. WHAT THE TOOL DOES (tested, not assumed)
   C1 A merged-away ticket: [ ] counts as closed  [ ] vanishes from open  [ ] other: ______
   C2 A reopened ticket:    [ ] appears again in created  [ ] does not
   C3 A deleted ticket:     [ ] deletion allowed  [ ] not allowed; excluded how: ________
   C4 Tested on: ____________  by: ____________

D. CHANNELS (one line each, counted separately)
   Web form ____   E-mail ____   Chat ____   Phone ____   Walk-up ____   Integration ____
   Rule: every request becomes a ticket, including phone and walk-up, logged the same day

E. THE RECONCILIATION (monthly, before anything is reported)
   Open at start ____ + created ____ - closed ____ - merged away ____ - junk ____ = ____
   Open at end (snapshot) ____      Difference ____      Explained by: ____________________

F. DEFINITION CHANGES (dated; draw a line on the chart at each)
   Date ________  What changed ______________________________  Effect on count ________
   Date ________  What changed ______________________________  Effect on count ________

Tom filled the sheet in on the Tuesday, which took him most of the morning. He had to test what a merge did and did not believe the answer the first time. Clare's next question, in May, was "why did open go up in April?" That is a question about the desk rather than about the arithmetic, and is the right kind of question to be asked. The three counts had stopped being the subject. They had become the evidence.

Frequently Asked Questions