What a Status Is For

Monday, 08:40, and Dana has the queue open on the big screen. The new technician starts today and she wants to show him how the desk works. She clicks the status filter. In Progress: 212. Awaiting Reply: 9. On Hold: 31. New: 4. The new technician, Theo, asks the only sensible question: "Which of the 212 is anybody actually working on?" Dana opens the first three. One was last touched eleven days ago by someone who has since left. One is waiting for a part. One is a request for a monitor arm that was approved, ordered and installed three weeks ago, and nobody told the ticket.

A status is the one word on a ticket that says where it is in its life: new, being worked, waiting, finished. A ticket, for anyone handed the queue last Monday, is the record of one request from one person, with a number, a history and an owner. The status is the field that is supposed to tell you, at a glance, what happens next and who makes it happen. At Dana's desk it had stopped doing that some time ago, and the 212 were the proof. This article is part of our Ticket Workflow & Status Design series, which is about making that one word mean something again.

It covers the single question a status exists to answer, then the smallest set of statuses that can answer it. Next come the two fields a status is most often confused with, priority and category, and the test for a status nobody can explain. Then it covers what a good status does for the queue, for the requester and for the reports. A whose-move table at the end is one you can copy onto the wall. The definitions of each individual status, with entry and exit conditions, are the subject of Statuses That Mean Something; this article is about why the field exists at all.

The Question a Status Answers

A status answers one question: whose move is it? Not how important the ticket is, not what it is about, not how long it has been open. Whose move. If the answer is "the technician's", the ticket is open and somebody on the desk owes it work. If the answer is "the requester's", the desk has asked a question and is waiting for a reply. If the answer is "somebody outside the desk's", a supplier, another team, a delivery, the desk is waiting too. But it is waiting on a different person with a different kind of nudge. If the answer is "nobody's", the ticket is finished. That is the whole job of the field.

Everything else a status is asked to do is borrowed from another field. Think of a board game with four players. The status is the marker that says whose turn it is. It does not say who is winning (that is the score), or what kind of game it is (that is the box). It does not say how long the game has been going (that is the clock on the wall). A marker that tried to say all four things at once would be useless for the one thing it was for, which is telling the next player to pick up the dice.

The reason the question matters is that a help desk is a queue of unfinished conversations. The desk only has time to look at the ones where it is the desk's turn. A queue is the list of open tickets, usually sorted so the most urgent or the most neglected rise to the top. On a desk of three people with two hundred open tickets, nobody reads two hundred tickets every morning. They read the ones where it is their move. If the status cannot separate "my move" from "their move", the technician has to open every ticket to find out, and on day three they stop opening them.

I ran a desk where the status field answered a different question for every person who used it. One technician used In Progress to mean "I have read it". Another used it to mean "I am typing in it right now". A third used it to mean "I would like to look at this later", which is not a status, it is a hope. The filter counted all three as the same thing, and the count was 212.

The Minimal Set

Six statuses answer the whose-move question completely, and most desks need no more than six. They start with New (nobody has looked at it yet) and In Progress (the desk's move). Then come Awaiting Reply (the requester's move) and On Hold (somebody else's move, outside the desk). Resolved means the desk believes it is finished and is waiting for the requester to agree or for a short window to pass. Closed means finished, agreed, nobody's move. Every ticket is in exactly one of those at every moment, and the move belongs to exactly one party.

Read the six as a path rather than a list. A ticket arrives as New. Somebody claims it and it becomes In Progress. If the technician needs something from the requester, it goes to Awaiting Reply and comes back to In Progress when the answer arrives. If the technician needs something from outside, a part, a vendor, a date, it goes to On Hold and comes back the same way. When the technician believes it is fixed, it goes to Resolved. When the requester confirms, or stays silent for an agreed number of days, it goes to Closed. The path has loops, but it has one direction of travel, and every loop passes back through In Progress.

Your tool will not necessarily call them these names, and may not let you change what it calls them. Many small-team tools ship a fixed list of eight or ten statuses that cannot be renamed or added to. The list usually contains something like On Hold, Awaiting Reply, Resolved and Closed. That is normal, and it does not matter much. The names belong to the tool; the meanings belong to you, and the meanings are what this series is about. Where the tool offers more statuses than six, pick the six you will use and write down which ones they are. The others can sit in the drop-down unused, which is where most of them belong.

Resist the urge to add a seventh on the first day. Every status after six should be added only when someone can name the whose-move answer it gives that none of the six already give. "Assigned" is In Progress. "Acknowledged" is In Progress. "Escalated" is In Progress with a flag on it. Escalation is a question of attention, not of turn, and What Escalation Means makes that argument properly. "Pending" is the one to be most careful of, because it means the desk is waiting but declines to say for whom. A waiting status that does not name the party being waited for is a shrug with an icon.

Status Is Not Priority

The field a status is most often confused with is priority, and the confusion runs in both directions. Priority is the rank that says how soon the ticket must be dealt with, usually set from how many people it affects and how badly. It answers "how urgent", and it drives the targets: a High ticket is due a reply in an hour, a Low ticket by tomorrow. Status answers "whose move". A ticket can be High and Awaiting Reply, because the requester has not sent the screenshot you asked for. It can be Low and In Progress, because you are working through the easy ones on a quiet Friday. The two fields are independent, and a desk that treats them as one loses the use of both.

The usual symptom is a status called Urgent, or a priority called Waiting. I have seen both. A status called Urgent tells you nothing about whose move it is, so the technician has to open the ticket to find out. That is the exact failure a status exists to prevent. A priority called Waiting tells you nothing about how urgent the ticket is, so the response clock has nothing to run against. (A service level agreement, or SLA, is the written promise of how fast the desk replies and resolves, by priority; SLA in Plain Words covers it from the beginning.) The two fields do different work and should never share a word.

The deeper confusion is using status as a sorting trick. Somebody wants the important tickets at the top of the list. The tool happens to sort by status, so they invent a status that sorts first. Now the field carries an urgency signal for one person and a whose-move signal for everyone else. The honest fix is a filter or a sort on priority, which is what priority is for. Priority Is Not the Order of Work is the place to read about what happens after that.

Status Is Not a Category

The second field status gets confused with is category, and this one is subtler. A category is what the ticket is about: password, printer, new starter, software request. It answers "what kind", and it drives routing and reporting: printer tickets go to the person who knows the printers, and the monthly report says how many there were. Status answers "whose move". A password ticket can be New, In Progress or Closed; the category does not change as the ticket moves, and the status does not change what the ticket is about.

The confusion shows up as statuses with nouns in them. "Awaiting Parts" is a kind of wait wearing a status badge. "Vendor" is a kind of party being waited on. "Project" is a kind of work. Each one started because somebody wanted to filter the queue by a kind of wait. The tool only let them filter by status, and so the status list grew a noun. Six months later the list has eleven entries, four of which mean On Hold, and the filter is less useful than it was before the noun arrived.

Keep the noun somewhere else. If the tool has a category field, or a custom field on the request form, put the kind of wait there. Or put it in the first line of an internal note where a search will find it. The status stays On Hold, which says whose move it is, and the note says "waiting on supplier for replacement screen, chased Tuesday, promised Friday", which says everything else. The status is a traffic light. It has three colours for a reason, and the reason is that drivers do not read paragraphs at junctions.

The Status Nobody Can Explain

Every desk that has run for more than a year has at least one status nobody can explain, and the test for finding it takes five minutes. Ask three technicians, separately, to define each status in the drop-down in one sentence. Each sentence should include the one thing that moves a ticket into it and the one thing that moves a ticket out. Write the answers side by side. Any status with three different answers is not a status; it is three private conventions sharing a label. Any status with no answer at all is a drawer nobody has opened in a while.

The usual suspects have names like Pending, Assigned, Acknowledged, Deferred, Scheduled and Reviewed. Each one made sense to the person who added it, on the day they added it, for the ticket they were holding. Pending was added by someone waiting on a vendor. Scheduled was added for a site visit the following Tuesday. Deferred was added by a manager who wanted a polite word for "no". None of the three people who added them still works on the desk, and the statuses have outlived their authors in the way that cables outlive the equipment they were bought for.

What a status nobody can explain costs you is the filter. The moment one status has three meanings, a technician looking for "my move" cannot trust the filter to find it. So they stop using the filter and start opening tickets one by one. Or worse, they start keeping a private list in a text file of the tickets they really own. The private list is where tickets go to hide, and Keeping Tickets from Hiding is largely a tour of the places those lists live.

The fix is not to delete the status, which the tool may not allow, but to stop using it and say so. Write the six you use on one page, with one sentence each, and declare the rest retired. Move every ticket sitting in a retired status into one of the six, which is tedious for one afternoon and then over. Then watch the filter counts for a month. If a retired status gets a new ticket, somebody did not get the page, and the page is the thing to fix.

What a Status Does for the Queue

A status that answers whose-move turns the queue into three short lists instead of one long one. The first list is "my move": New plus In Progress, which is the work. The second is "their move": Awaiting Reply plus On Hold, which is the follow-up. The third is "nobody's move yet": Resolved, which needs a confirmation or a close. A technician at 08:30 looks at the first list, and the first list is short, because everything waiting on someone else has been moved out of it. That is the entire productivity gain of a status field, and it is a large one.

The counts become honest when the statuses do. If In Progress holds forty tickets, that is forty things the desk owes work on, and forty is a number you can staff for. If it holds 212 because a third of them are waiting on parts and a third are finished-but-untold, the number is noise, and the desk will be judged on the noise. Tools lean on this. Most dashboards keep separate counters for tickets waiting on the desk and tickets waiting on the requester. Most queue filters show a count beside each status. Those counters are only as truthful as the statuses behind them. Set the status wrong and the dashboard will tell you a wrong number, confidently, every time it refreshes.

The follow-up list is the one most desks never had before. Awaiting Reply tickets older than three days need a nudge to the requester; On Hold tickets older than a week need a chase to the supplier. Neither nudge is possible without knowing which tickets are waiting on whom, and with a whose-move status it is a filter and a sort. Follow-up Cadences That Keep Tickets Moving describes the rhythm; the status is what makes the rhythm possible.

A Status Change Is Not a Message

The status is for the desk; the requester never sees it, and setting it tells them nothing. This is the mistake that costs the most goodwill per click. A technician fixes the problem, sets Resolved, and moves on. The requester finds out when they try the thing again. Or they do not find out, and raise a second ticket the following week. In many tools a status change alone sends nothing to the requester, not even when the ticket is marked Closed. So a status set without a reply is a status set in private. Check what yours does with a test ticket; the safe rule everywhere is that the status change travels with a reply. The requester hears from the desk only when the desk writes to them.

So every status change that moves the turn to the requester travels with a reply. Awaiting Reply travels with the question. Resolved travels with the note that says what was done. On Hold travels with a sentence naming who is being waited on and when the desk will next check. The status is the desk's bookkeeping; the reply is the conversation, and the conversation is the only part the requester experiences. Avoiding the Silent Close is the long version of this paragraph.

The reverse is also true: a reply from the requester is a status change, whether or not anyone sets one. When the screenshot arrives, the turn is the desk's again, and the ticket should leave Awaiting Reply the moment the reply lands. The tool should change it if it does that automatically, and the technician should change it if it does not. Check what yours does. A ticket sitting in Awaiting Reply with an unread answer underneath it is the desk's move, mislabelled. It will sit there with a clear conscience for as long as the label lets it.

What a Status Does for the Reports

The second thing a good status gives you is time: how long tickets spend in each state, which is a different number from how long they spend open. A ticket open for twelve days that spent ten of them Awaiting Reply is a slow requester. One that spent ten days In Progress is a slow desk, or a hard problem. One that spent ten days On Hold is a slow supplier. All three look identical on an age report. They look completely different on a time-in-status report, and only the second one is the desk's to fix.

Most tools record every status change with a timestamp in the ticket's history. Many can report how long a ticket spent at each status and how often it changed hands. Where yours cannot, the status-change log exports to a spreadsheet and the report takes twenty minutes a month. The report is worth nothing if the statuses were set by habit rather than by whose move it was. Then time In Progress includes all the waiting that nobody bothered to mark. The desk that sets status carefully for a month gets, at the end of the month, the first honest answer to "where does the time go". It is usually not where anyone guessed.

The number worth watching is the share of open tickets in "their move" states. On a healthy desk it is sizeable, because the desk asks questions, chases suppliers and does not sit on work. On a desk where everything is In Progress it is near zero, not because nothing is waiting, but because nobody said so. A near-zero waiting share beside a large backlog is a desk carrying other people's turns as its own.

A Short War Story: The Pending Pile at Meridian Parts

Meridian Parts, a distributor with a four-person desk, used a status called Pending for anything that was not being typed in at that moment. After two years it held 340 tickets. Ravi, who took over the desk, assumed Pending meant waiting on the requester and sent a polite "are you still having this problem?" to all 340 in one morning. About ninety replied "it was fixed months ago". About sixty replied "I have been waiting for you". One, from the warehouse, replied with a photograph of a label printer that had been sitting in its box for seven weeks, waiting for the status to change. The desk spent eleven working days sorting the pile into four real states, and two of the sixty had quietly bought their own equipment in the meantime. The lesson Ravi wrote on the wall was short: a waiting status that does not say who you are waiting for is not waiting, it is forgetting.

The Whose-Move Table

The table below is the minimal set with the question answered for each row, plus what a technician does when they see it and what the requester is entitled to expect. Copy it, replace the status names with whatever your tool calls them, and put it where the queue is looked at. If a status in your drop-down does not fit a row, it is either a duplicate of one that does or a status nobody can explain. Either way it should not be used.

Two rows deserve a sentence. The "what the requester should expect" column is there because a status is a promise to the person on the other end as much as a flag for the desk: Awaiting Reply means "we are waiting for you", and the requester should have been told so in words, not left to infer it from a field they cannot see. And the Resolved row says the move is the requester's, which surprises people; the desk has done its part, and the turn belongs to the requester until they confirm or the window closes. Resolved vs Closed: The Confirmation Window is about how long that is.

Status, Priority and Category Side by Side

When a technician is unsure which field a piece of information belongs in, the question is which of three questions it answers. The decision table below settles most arguments in a sentence. "Whose move" is status. "How soon" is priority. "What kind" is category. Anything that answers none of the three is a note.

If your tool has no category field, the kind-of-ticket information still exists. It lives in the form the requester filled in, the department the ticket landed in, or a custom field on that department's form. The point of the table is not that every tool has all three fields. It is that each piece of information has one home, and the status is not a spare room.

Theo, the new technician, got through his first week with a printed copy of the whose-move table beside his monitor. The 212 In Progress tickets were sorted into about fifty that were genuinely the desk's move, ninety that were waiting on someone, and seventy that were finished and had never been told. By Friday the In Progress filter said fifty-four, and the desk, for the first time in a year, knew what it owed. The status field had been asked one question again. It turned out to be quite good at answering it.

Frequently Asked Questions