Every ticket moves through states from the moment it arrives to the moment it closes. Those states are your status workflow, and they are quietly the most important configuration decision in your helpdesk. Get them right and a glance at the board tells you exactly where work is stuck. Get them wrong and "Open" becomes a 400-ticket junk drawer nobody trusts.

The core lifecycle

Almost every support workflow reduces to five honest states:

  • New — arrived, nobody has looked yet. The clock on your first-response SLA is running.
  • Open — an agent owns it and is actively working it.
  • Pending — you are waiting on the customer. Your SLA clock should pause here.
  • On hold — you are waiting on something internal: a bug fix, a vendor, a deploy. The customer is blocked but the delay is yours to own.
  • Resolved / Closed — done, pending confirmation or fully shut.

The hard line to draw is between Pending and On hold. Conflating them is the single most common workflow mistake, because it hides whether a delay is the customer's or yours — and that distinction is exactly what your SLA policies need to measure fairly.

Why "Pending" must pause the clock

If a customer takes three days to send you a screenshot you asked for, that is not an SLA breach. A status workflow that keeps counting against you during customer waits will make your metrics lie and demoralize your team. Make sure your Pending status stops the resolution clock, and that the clock resumes the instant they reply.

Resolved is not Closed

Keep them separate. Resolved means "we believe this is fixed"; Closed means "confirmed, and the window to reopen has passed." The gap between them is where you catch the fixes that did not actually land:

  • Auto-move Resolved tickets to Closed after a few days of silence.
  • Auto-reopen if the customer replies to a resolved ticket — a reply is a signal it was not really solved.
  • Measure your reopen rate. A high one means agents are resolving to hit a number, not to fix the problem.

Resist status sprawl

Every status you add is a decision an agent has to make on every ticket. "Waiting on engineering," "waiting on billing," and "waiting on vendor" do not need three statuses — they need one On hold status plus a tag or field for who. Statuses describe where a ticket is in its lifecycle; tags and custom fields describe everything else.

Map statuses to who is accountable

A clean way to audit your workflow: for every status, ask "whose move is it?" If the answer is "the agent," the SLA clock runs. If it is "the customer," it pauses. If it is "someone else internally," it pauses for SLA but still shows up on an aging report so it cannot rot silently. Tie this back to your escalation workflows so on-hold tickets do not quietly age past the point of no return.

The test of a good workflow

Stand in front of your board and read only the statuses. If you can tell, without opening a single ticket, what is waiting on you versus waiting on someone else — and what is at risk — your workflow is doing its job. If you cannot, you have either too many statuses or the wrong ones.