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.
What Is a Ticket Status Actually For?
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.
The 5 Universal Ticket Statuses That Work Everywhere
After years of fighting complexity, this is the stripped-down set I recommend:
New
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.
In Progress
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.
Waiting
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.
Scheduled
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.
Complete
Done. Finished. Closed out.
How We Expand on This in Rocketship
In Rocketship, we’ve refined “Scheduled” into a few smarter buckets:
- Scheduled Flex: Flexible, auto-managed tasks.
- Scheduled Remote: Booked remote sessions.
- Scheduled Onsite: Booked onsite appointments.
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.
Why Keeping Statuses Simple Actually Saves You Time
Overcomplicating statuses isn’t just confusing — it kills your efficiency.
- Training new techs takes forever.
- Automation breaks down because workflows can’t keep up.
- Reports become useless without complicated CASE statements.
- Clients get confused when they see your status spaghetti in the portal.
When we simplified our statuses, everything improved: Tickets moved faster, customer updates were clearer, and management finally had clean reports to work with.
When You Might Need More (And How Not to Screw It Up)
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:
- Is it absolutely necessary?
- Is it crystal clear when to use it?
- Will it improve automation or reporting meaningfully?
If not, skip it. Keep it simple.
