If there’s one thing I’ve learned working across different helpdesk and PSA systems, it’s that ticket statuses are almost always a mess.
When I first started managing service boards, I thought having a status for every possible situation made things more organized. Spoiler alert: it didn’t. It made things slower, more confusing, and almost impossible to report on cleanly. Over the years — through trial, error, and some truly ridiculous status lists (“Waiting on Customer Response #4” was a low point) — I realized the fewer statuses you have, the better everything runs.
Here’s the system I swear by now, and why you should seriously consider it, no matter what platform you’re using.
At its core, a ticket status should do just one thing: Tell you where the ticket is in its lifecycle — no more, no less.
But way too often, statuses get crammed with extra information: who’s working on it, how urgent it is, whether it’s waiting on a vendor for too long, how overdue it is… Before you know it, you’ve got a mess nobody can manage, and reporting is a nightmare.
I learned this the hard way when I spent days building custom workflows for 30+ ticket statuses — only for my team to ignore half of them because nobody understood when to use which.
Lesson learned: if your team can’t remember all your statuses without looking at a cheat sheet, you have too many.
After years of fighting complexity, this is the stripped-down set I recommend:
The ticket’s been created and hasn’t been touched yet. Simple. When I first started, I’d leave tickets marked “New” for days. Clients were furious. Now, I treat “New” like a flashing red light — you either move it to “Scheduled” or “Waiting” fast.
Work has actually started. Someone’s doing something. One mistake I made early on was having too many shades of “In Progress” — “Assigned,” “Working,” “Researching,” “Almost Done”… it didn’t matter. If it’s being worked on, it’s In Progress. End of story.
We’re waiting on someone else — customer, vendor, whoever. At one point, I tried having separate statuses like “Waiting on Customer” and “Waiting on Vendor.” Guess what? No one ever set them correctly. Now we just have Waiting, and whoever we’re waiting on goes into the ticket notes. So much easier.
The work is booked for a future time — remote or onsite. Initially, I lumped “Scheduled” work into “In Progress.” Big mistake.
Scheduled work is different because you’re not working yet, but you’re also not ignoring it. Giving it its own status keeps your team and your clients on the same page.
Done. Finished. Closed out.
In Rocketship, we’ve refined “Scheduled” into a few smarter buckets:
This lets us manage different types of scheduled work without needing new core statuses. The base system stays simple, but we still get the flexibility we need for day-to-day operations.
Overcomplicating statuses isn’t just confusing — it kills your efficiency.
When we simplified our statuses, everything improved: Tickets moved faster, customer updates were clearer, and management finally had clean reports to work with.
Sometimes you need a slight expansion — like splitting “Waiting” into “Waiting – Customer” and “Waiting – Vendor” only if your workflows truly depend on that distinction.
But every new status you add should go through this checklist:
If not, skip it. Keep it simple.