Eight statuses isn't bureaucracy — it's precision. Every ticket lives in a clear state, visible to everyone, with no ambiguity about where work stands.
A ticket status is a named workflow state that tells everyone where work stands at a glance. Most teams use three statuses — To Do, In Progress, Done — which collapses three distinct situations into one label: work actively being done, work that is paused, and work that is blocked.
"In Progress" as a single status cannot distinguish between a ticket someone opened this morning and a ticket that has been blocked for a week. The 8-status workflow in ticket management software exists to solve this: precise status labels that tell you exactly where work stands, without having to ask.
Here's the full workflow in Sunday's ticket management platform:
Backlog — New ideas, requests, and planned work that hasn't been reviewed yet. This is where work enters the system. Nothing has been decided about it yet.
New — Accepted and ready to be worked on. Someone has reviewed the ticket, confirmed it's valid work, and it's prioritized. But no work has started.
Documenting — Gathering requirements, details, or context. This status exists for work that requires research or input before actual execution can begin. Common for complex projects where scope isn't fully defined.
Working — Actively in progress. Someone is doing the work. This is the "moving" state — the status where most of the work happens.
Blocked — Work has stopped, waiting on something. Blockers are temporary states — the goal is always to unblock and resume. Internal blockers (team member) vs external blockers (vendor, client).
On Hold — Work is paused, but not blocked by a specific deliverable. Maybe the client asked to pause. Maybe the priority changed. Maybe the dependencies aren't ready. On Hold is a deliberate pause, not an accidental stop.
Done — Work is complete, awaiting beneficiary feedback. The assignee says it's done. Now the beneficiary needs to review and rate before it closes.
Closed — Work is finalized. Beneficiary accepted the deliverable. Ticket is archived. This is the terminal state.
This is the most common confusion in ticket status design: aren't Blocked and On Hold the same thing?
No. And the difference matters.
Blocked is a problem. Work wants to move but can't. There's a specific deliverable missing — vendor contract, design assets, client approval, server access. The ETA tells you when the blocker resolves. The required action tells you who's responsible.
On Hold is a decision. Work was deliberately paused. The client asked to pause the project. The priority changed and you deprioritized. The dependencies aren't ready and you chose to wait rather than push. On Hold implies active decision-making, not a stuck state.
When you conflate Blocked and On Hold, you lose the ability to distinguish between "we're waiting on someone" and "we chose to stop." This affects how you manage the work, how you communicate with stakeholders, and how you identify bottlenecks.
Here's what changes when every ticket has a precise status:
Standups are faster. Instead of "what's everyone working on?" you ask "any blockers?" — and you can see the blockers in your dashboard before the meeting starts.
Deadlines are visible. A ticket in Documenting with a deadline next week is at risk. A ticket in Working with a deadline next week is normal. Same deadline, different risk profile based on status.
Work doesn't get lost. When a ticket moves to Blocked, it stays visible in the Blocked view. It doesn't disappear into "in progress" where nobody knows it's stuck.
Closure is explicit. The Done → Awaiting Feedback → Closed flow means work doesn't get marked complete until the beneficiary accepts it. No more "I thought we were done with that."
Patterns emerge. Over time, you see patterns: "Why do we always get stuck in Documenting?" or "Our On Hold tickets never come back." These patterns reveal process problems you can fix.
A marketing team was running a product launch campaign. Twenty-eight tickets across content, design, development, and PR.
Without the 8-status workflow, status looked like this: 15 "in progress," 8 "done," 5 "to do." The PM had no visibility into what was actually moving, what was blocked, or what was at risk.
With the 8-status workflow, status looked like this:
The PM could see: two tickets were blocked on the same vendor (same blocker, might affect both deadlines). The On Hold ticket was a deliberate client decision, not a forgotten item. The Done tickets were waiting on beneficiary reviews — not forgotten, just pending sign-off.
This visibility transformed the weekly status meeting from a guessing game into a tactical review.
Mistake 1: Using only 3-4 statuses. If you only have To Do, In Progress, Done, you can't distinguish between "waiting on internal team" and "waiting on external vendor" — they're both "in progress." The granularity is lost.
Mistake 2: Treating Blocked and On Hold as the same. Conflating these two removes the ability to manage blockers proactively. If Blocked and On Hold look the same, you can't distinguish between "waiting on someone" and "chose to pause."
Mistake 3: Skipping Awaiting Feedback. Marking tickets Done without beneficiary review means work can be "complete" without the beneficiary's acceptance. The feedback loop exists for a reason.
Mistake 4: Not using Backlog. Backlog isn't just "things we might do someday." It's the intake layer — where new requests enter, get reviewed, and get prioritized before moving to New. Skipping Backlog means everything goes directly to "to do" without prioritization.
Here's how to start:
Configure the statuses in your ticket management software. In Sunday, the 8-status workflow is built in. You can customize status names and add transitions if needed.
Train the team on what each status means. Not every team member will intuitively understand the difference between Documenting and Working, or Blocked and On Hold. Spend 15 minutes in a team meeting explaining the workflow.
Start using Blocked and On Hold immediately. These are the statuses most teams skip. Start marking tickets as Blocked when work stops for a known reason. Start using On Hold when work is deliberately paused.
Build a "Blocked tickets" saved view. This is your first workflow view. Check it every morning. If you see blockers, you know work has stopped and needs attention.
Review status distribution weekly. At the end of each week, look at how many tickets are in each status. Patterns tell you about process health.
The 8-status workflow isn't bureaucracy. It's precision. Every ticket lives in a clear state, visible to everyone, with no ambiguity about where work stands. That's the foundation of real team accountability.
Want to see the 8-status workflow in action? <a href="/dashboard" className="text-[#D6BFA3] hover:underline">Try Sunday's ticket management platform</a> — set up your first ticket with the full workflow today.
Try Sunday's ticket management platform — start free, upgrade when you're ready.
Start for free