Statuses That Mean Something

Friday, 16:10. Priya is covering for Marcus, who is on leave for two weeks. She has his tickets open in a tab she has been avoiding since lunch. Twenty-three of them are On Hold. She opens the oldest. It has been On Hold for twenty-six days, and the last note, from Marcus, says "waiting". Waiting for what? For whom? Until when? The ticket does not say. The status says On Hold, which she had assumed meant something. It turns out to mean "Marcus knows", and Marcus is on a beach.

A status is the one-word field that says where a ticket is in its life and, if it is any good, whose move it is. A status definition is the sentence that says what the word means on your desk. It says what puts a ticket into that status, what takes it out, and what has to travel with the change. Most desks have the first and not the second. They have labels, supplied by the tool, and a set of unwritten habits about what the labels mean, which differ by technician and drift by month. This article is part of our Ticket Workflow & Status Design series. It is about writing the second thing down so that the first thing means something.

It covers why the label and the meaning are different things, then the shape of a definition that works, with an entry condition and an exit condition. Next comes how to define the working states, the waiting states and the end states, with examples. Then comes what to do when the tool fixes the labels and will not let you change them. The article ends with how to test a definition against real tickets, and a status definition card, one per status, that you can copy. The question of why the field exists at all is answered in What a Status Is For. This article assumes you want the field to work and shows how to make it.

The Label Is Not the Meaning

The label is what the tool prints in the drop-down. The meaning is what your desk agrees it stands for, and only one of them is under your control. Tools ship with status lists because a ticket has to have some status on the day of installation, and the vendor had to pick words. Some tools let you rename them and add your own. Many small-team tools ship a fixed set of eight or ten that cannot be renamed or added to. They typically include something like On Hold, Awaiting Reply, Resolved and Closed. That sounds limiting until you notice that the desks with fully editable status lists are not, on the whole, in better shape. They have more labels. They do not have more meaning.

Meaning comes from agreement, and agreement comes from a sentence somebody wrote down. "On Hold means the desk is waiting on a party outside the desk, named in the latest note, with a date we will chase them." That sentence is the status. The word in the drop-down is a pointer to it. Marcus's twenty-six-day ticket had the pointer and not the sentence, and so the pointer pointed at nothing in particular.

The test of whether a status has a meaning is whether a stranger can act on it. Priya, covering, should be able to look at On Hold and know there is an outside party, without opening the ticket. She should know they are named, and that a chase is due on a date she can find. If the definition is written, she can. If it is in Marcus's head, she cannot, and the status is a private note that happens to be visible to everyone.

Written definitions also stop the slow drift that every unwritten convention suffers. On the day a desk starts, everyone agrees what In Progress means because they decided it that morning. Six months later two people have joined, one has left, and In Progress has acquired three shades of meaning nobody chose. A sentence on a page does not drift. It can be wrong, and then you fix the sentence, but it cannot quietly become something else over a summer.

The Shape of a Definition

A status definition has six parts, and the first three do most of the work: a one-sentence meaning, an entry condition and an exit condition. The entry condition is the one event that puts a ticket into the status. The exit condition is the one event that takes it out, and where it goes. If you cannot name a single event for each, the status is not a state, it is a mood, and a ticket cannot be filtered by mood.

The remaining three parts make the definition usable by a stranger. Who may make the move, so that a trainee knows which transitions are theirs. What travels with the move: a public reply, an internal note, or nothing. And what the status must never be used for, which is the clause that stops the drift. Every status attracts a second use within a year and the card should say no in advance. A seventh part, an example ticket number, costs one line and answers more arguments than the other six.

Here is the shape applied to the simplest case. In Progress: a ticket is In Progress when a named technician owns it and the next action is theirs. Entry: a technician claims it, or a reply from the requester or an outside party arrives on a waiting ticket. Exit: the technician asks the requester something (to Awaiting Reply), waits on an outside party (to On Hold), or sends the resolving reply (to Resolved). Travels with the entry: nothing is required, though a first reply to the requester is due within the response target. Never used for: tickets nobody is working on. That last clause is the one Dana's desk, in the previous article, never wrote, and 212 tickets later it showed.

Notice what the definition does not contain. It does not say how urgent the ticket is; that is priority. It does not say what the ticket is about; that is category or the form. It does not say how long the ticket may stay there; that is a follow-up rule, which belongs on the card but is not part of the meaning. A definition that tries to carry all of those at once is a paragraph, and nobody filters a queue by paragraph.

Defining the Working States

New is the easiest status to define and the one most often left undefined, because everyone assumes it is obvious. It is not. New: a ticket is New when it has arrived and no technician has read it and taken responsibility. Entry: the ticket is created, by any channel. Exit: a technician claims it, which moves it to In Progress, or routes it to a department where it is New again for them. Travels with the exit: a first reply to the requester within the response target, with a name in it. Never used for: a ticket somebody has read and decided to leave for later. That is the whole card, and the "never" clause is doing real work. A ticket that has been read and left is In Progress with no owner, which is the worst state a ticket can be in, and calling it New hides that.

In Progress is defined above, and one clause of it deserves a second look: the entry condition includes a reply arriving on a waiting ticket. When the requester answers the question, the move is the desk's again whether or not anyone changed the field. Some tools move the ticket back automatically on a requester reply; some do not. Some do it for Resolved and Closed but not for the waiting states. Find out what yours does with a test ticket. If it does nothing, the definition has to say that the technician moves it. In that case, the morning routine has to include looking for replies on waiting tickets. A status that is only true when a human remembers to set it is true most of the time. Most is not a number you want on a filter.

Some desks want a third working state, for the ticket that has been picked up but is waiting on the technician's own calendar. Think of the site visit on Tuesday, or the change window on Thursday evening. The temptation is a status called Scheduled. Resist it, and watch what happens at Harbourview Clinic further down if you want the reason. A scheduled ticket is still the desk's move, and the date belongs in a note or a due field, not in the status. If the desk genuinely needs to see "booked for a date" as a list, a custom field with a date in it gives you that list without stealing a status.

Defining the Waiting States

The waiting states are where definitions earn their keep, because a wait has a party and a party has a follow-up rule. Awaiting Reply: a ticket is Awaiting Reply when the desk has asked the requester a question it cannot proceed without. Entry: a public reply to the requester that contains the question and says the desk is waiting on them. Exit: the requester replies (to In Progress), or the agreed nudge sequence runs out (to Resolved, with a note saying why). Never used for: waiting on anyone who is not the requester. The entry condition is the strict part. The move to Awaiting Reply is only legitimate if the requester has actually been told, in words, that the desk is waiting for them. A status change with no reply is the desk waiting in secret, and the requester cannot answer a question they were not asked.

On Hold is the same shape with a different party. On Hold: a ticket is On Hold when the desk is waiting on a party outside the desk, named in the latest note, with a date the desk will chase them. Entry: an internal note naming the party, what is awaited and the chase date, plus a public reply telling the requester who the desk is waiting on. Exit: the awaited thing arrives (to In Progress), or the chase date passes without it (stays On Hold, chase, new date in a new note). Never used for: waiting on the requester, or for tickets the desk simply has not got to. That last clause is the one that would have saved Priya's Friday. Marcus's "waiting" would have failed the entry condition on the day he wrote it.

The three kinds of waiting, why they must be kept apart, and the nudge rules for each have an article of their own, Pending User vs Pending Vendor vs On Hold. The follow-up rhythm that keeps waiting tickets from fossilising is in Follow-up Cadences That Keep Tickets Moving. For the definition card, what matters is that each waiting status names a party and a chase, and that the entry condition requires the requester to have been told.

Defining the End States

Resolved and Closed are two statuses because they mean two different things, and the definitions make the difference plain. Resolved: a ticket is Resolved when the desk believes the problem is fixed or the request fulfilled and has told the requester so. Entry: the resolving reply, which says what was done and invites the requester to say if it is not fixed. Exit: the requester confirms, or the confirmation window passes in silence (to Closed); or the requester replies that it is not fixed (to In Progress, as a reopen). Never used for: a ticket where the fix has been applied but the requester has not been told. The entry condition is the reply, not the fix. A fix the requester has not heard about has not resolved anything from where they are sitting.

Closed: a ticket is Closed when the requester has confirmed, or the window has passed, and no further work is expected. Entry: the confirmation, or the end of the window. Exit: a reply from the requester reopens it, in the same ticket, to In Progress. Never used for: hiding a ticket the desk does not want to deal with. Some tools allow a ticket to be deleted and some never do. The rule is the same either way: a mistaken ticket is closed or merged, never deleted. Closed is therefore the only way a ticket should ever leave the open queue, which is exactly why its entry condition has to be strict. A ticket that is closed without the requester hearing from the desk is not finished; it is merely quiet.

How long the window is, what notice the requester gets, and how a reopen is handled from each end state are the subject of Resolved vs Closed: The Confirmation Window. The content of the resolving reply itself, what a good resolution note says and how to ask for confirmation without chasing forever, belongs to the Closing Tickets Properly series. The definition card only needs the shape: Resolved is entered by a reply and left by the requester or the clock.

When the Tool Fixes the Labels

When the tool will not let you rename a status, you map your meanings onto its labels and write the map down. The map becomes part of the definition. This is less of a compromise than it sounds. Your definition of "the desk is waiting on an outside party" does not care whether the drop-down says On Hold, Pending or Waiting. It cares that everyone on the desk picks the same label for that meaning. It also cares that the label is written on the card next to the sentence. The label is the handle. The sentence is the thing.

The table below is a typical map for a desk that uses six meanings in a tool with fixed labels. The right-hand column is the honest answer to "what if the tool has no label for this". You borrow one and say so on the card, or you carry the distinction in a note or a custom field. What you do not do is pretend the distinction does not exist because the drop-down lacks a word for it.

Extra labels in the drop-down are retired rather than deleted. Retired means: written on the page as "not used", emptied once, and watched. In a tool with a fixed list, six or so of the labels will map to your meanings. The remaining labels simply go unused. The count beside each status in the queue filter will show you within a week if anyone is still reaching for one. A retired status that keeps acquiring tickets is not a tool problem. It is a training problem with a filter attached.

Testing a Definition Against Real Tickets

A definition is tested by applying it to tickets that already exist, and the test takes an hour. Pull ten tickets at random from each status in the drop-down. For each one, read the latest note and reply, and ask whether the ticket passes the entry condition of the status it is in. Count the failures. A status where eight of ten pass has a definition people are following. A status where four of ten pass has a label and a habit, and the definition is about to teach you which of the two needs changing.

The failures sort into three piles. The first is tickets in the wrong status under a right definition, which is a training pile. The definition is fine and somebody did not follow it, usually because they had not read it. The second is tickets that fit no status, which is a definition pile. There is a kind of ticket the six sentences do not cover. You either widen a sentence or, rarely, add a seventh card. The third is tickets that fit two statuses at once, which is the most useful pile. It means two definitions overlap and one of them needs a sharper "never used for" clause.

The three-technician test from the previous article works on definitions as well as on labels. Give each technician the card for one status with the example ticket number blanked out, and ask them to find a ticket in the queue that fits it. If the three come back with tickets that all pass the entry condition, the card works. If one comes back with a ticket that is really Awaiting Reply and says "well, it is sort of On Hold", the card has a gap. The gap is wherever "sort of" lives.

Repeat the ten-ticket test a month after the cards go up, and then quarterly. The first run is always humbling. I once found a Resolved status in which three of ten tickets had never been told they were resolved. That is to say three of ten had not met the one entry condition the status had. The second run is better. By the third the test is boring, which is the correct outcome for a test.

A Short War Story: The Scheduled Status at Harbourview Clinic

Harbourview Clinic's two-person desk had a status called Scheduled. One technician, Omar, used it to mean "I will do it on my next site day". The other, Jess, used it to mean "a visit has been booked and the requester knows the date". Omar put the reception printer ticket into Scheduled on a Thursday, intending to fix it on Tuesday, then went on unplanned leave on the Monday. Jess saw Scheduled, read it the only way she knew, and assumed the requester had a date. The requester, the practice manager, saw no visit and assumed the desk had forgotten. Reception hand-wrote appointment slips for three weeks before the practice manager phoned the IT director directly, which is a call no desk wants to be the subject of. The clinic retired Scheduled and moved booked visits into a date field with the requester told in a reply. It wrote one card per status with a "never used for" line. The lesson Jess put at the top of the page was that a status with two meanings has none.

The Status Definition Card

The card below is one page per status, filled in once and kept together as the desk's set of status cards. Fill in the tool's label and your meaning first, then the entry and exit, then the rest. The "must never be used for" line is the one to spend time on; it is the clause that stops the drift. Keep the completed cards where every technician can find them in ten seconds, which in most tools means an agents-only knowledge base article rather than a shared folder.

STATUS DEFINITION CARD — ONE PER STATUS
Tool's label: ______________________    Our meaning (two words): ______________
Whose move:  [ ] the desk   [ ] the requester   [ ] an outside party   [ ] nobody

ONE-SENTENCE DEFINITION
  A ticket is in this status when ____________________________________________
  ____________________________________________________________________________

ENTRY CONDITION (the single event that puts a ticket here)
  ____________________________________________________________________________
  Travels with the move:  [ ] public reply   [ ] internal note   [ ] both   [ ] nothing
  The requester is told:  ______________________________________________________

EXIT CONDITION (the single event that takes a ticket out)
  ____________________________________________________________________________
  Goes to: ______________     Or, if the wait runs out: ______________

WHO MAY MAKE THE MOVE
  Into this status: ______________________    Out of it: ______________________

FOLLOW-UP RULE WHILE HERE
  Check every ____ working days   By: ______________   Record the check as: ________

MUST NEVER BE USED FOR
  ____________________________________________________________________________

EXAMPLE TICKET
  #________  ____________________________________________________________________

Card owner: ______________    Last reviewed: ______________

Here is a filled card for one status, so the blanks have something to stand next to. It is for Awaiting Reply on a four-person desk; your desk will fill the follow-up line differently, and the labels will be whatever your tool calls them.

STATUS DEFINITION CARD — AWAITING REPLY
Tool's label: Awaiting Reply            Our meaning (two words): requester's move
Whose move:  [ ] the desk   [x] the requester   [ ] an outside party   [ ] nobody

ONE-SENTENCE DEFINITION
  A ticket is in this status when the desk has asked the requester a question
  it cannot proceed without and has told them so in a reply.

ENTRY CONDITION
  A public reply containing the question and the words "waiting on you for".
  Travels with the move:  [x] public reply   [ ] internal note   [ ] both   [ ] nothing
  The requester is told:  what we need, why, and that the ticket waits for them

EXIT CONDITION
  The requester replies by any channel.
  Goes to: In Progress        Or, if the wait runs out: Resolved, with a note

WHO MAY MAKE THE MOVE
  Into this status: the owning technician    Out of it: anyone who sees the reply

FOLLOW-UP RULE WHILE HERE
  Check every 3 working days   By: the owner   Record the check as: a public nudge
  Two nudges, then the "closing unless we hear" reply, then Resolved.

MUST NEVER BE USED FOR
  Waiting on a supplier, another team or a date. Those are On Hold.

EXAMPLE TICKET
  #4471  Asked for the error text and a screenshot; no reply yet; nudge due Thu.

Card owner: Priya    Last reviewed: at the quarterly status review

Keeping the Cards Honest

The cards need an owner and a review, or they become the second generation of the thing they replaced. The owner is whoever runs the desk. The review is quarterly, timed with the ten-ticket test, and short. It asks whether each card still describes what the desk does, and whether the desk still does what each card says. Where the two disagree, decide which one is wrong. Sometimes it is the card, because the desk found a better convention. More often it is the desk, because habits drift and cards do not.

Keep the cards where the queue is. A knowledge base article visible to agents and not to requesters is the right home. It is searchable from the same screen as the tickets, and requesters do not need to read it. Most knowledge bases have an agents-only or internal visibility setting, and that is where the cards should stay. A shared document in a folder is the second-best home, and a laminated sheet beside the monitors is a perfectly respectable third. A page nobody can find in ten seconds is a page that does not exist.

Tie the cards to the record. Most tools log every status change in the ticket's history with who made it and when, and some write the same line to an audit log as well. That history is the evidence for the ten-ticket test and for the quarterly review. It is what lets you say "On Hold tickets this quarter waited a median of nine days, all with a party named" rather than "I think it has got better". A definition you can check against a log is a definition. A definition you cannot is a preference.

Priya spent the first hour of Monday writing six cards from the tickets in front of her. She spent the second hour moving Marcus's twenty-three On Hold tickets into the states the cards said they were really in. Nine were waiting on suppliers, with the supplier named for the first time in a note. Six were waiting on requesters who had never been asked anything, and were asked. Five were finished and had never been told. Three were genuinely On Hold with a date. When Marcus came back from his two weeks he read the cards and said "that is what I meant". For the first time it was also what the ticket said.

Frequently Asked Questions