Workflow status labels: 7 clear statuses your team can share

Why unclear statuses slow work down

Vague workflow status labels create confusion that looks like busy work. People move items forward, but nobody is sure what actually changed. A ticket marked “In Progress” might mean “I started thinking about it,” “I’m blocked,” or “I’m done and waiting for review,” depending on who touched it last.

That mismatch causes three predictable problems: rework, missed handoffs, and noisy notifications. If a status doesn’t say what the next person should do, work bounces back and forth. If a handoff is hidden inside a vague label, it sits until someone notices. If everyone updates statuses just to “signal” activity, your feed becomes a blur and real changes are easy to miss.

Another common symptom is the same label being used differently across screens. One teammate uses “Ready” to mean “ready for review.” Another uses “Ready” to mean “ready to start.” A manager checking the board can’t tell whether the team is waiting, working, or finished.

The goal isn’t to describe every edge case. The goal is to make the normal path obvious with fewer statuses and clearer meaning. When statuses are consistent everywhere, you get faster handoffs and fewer questions like “Is this actually done?”

If your team isn’t sure where to start, aim for 5-7 statuses that cover most work: one for new items, one for active work, one for waiting or blocked work, one for review or approval, and one for done. Add detail only after the basics are stable and everyone uses the same meanings.

What a status label should (and should not) mean

A status label is a shared promise about what happens next. When someone changes a status, everyone should be able to predict the next step without asking a follow-up question.

Good workflow status labels describe the current reality of the work, not someone’s opinion about it. If the label is true, the team can tell whether the item is moving, waiting, or blocked, and who should touch it next.

A status is not the same thing as priority, assignee, category, or progress notes. Those fields can matter, but mixing them into the status makes the status unreliable.

It also helps to separate “state” from “stage.” State is what’s true right now (for example, “blocked on customer reply”). Stage is where the item sits in your process (for example, “review”). You can blend them, but when a single status tries to describe both, it often turns vague.

A useful status should trigger one of three things:

• A next owner (who picks it up)
• A next action (what happens next)
• A wait condition (what you’re waiting for)

Quick reality check: can someone read the label in a small list view and still know what to do next? If the answer is “it depends,” the label is probably hiding a decision that should be made elsewhere (like priority rules or assignment).

How many statuses to use and why 5-7 works

A status system should make work easier to read at a glance. Too many statuses and people stop trusting what they see. Too few and you lose the detail you need to manage handoffs.

For most teams, 5-7 statuses is the sweet spot. It fits on a single screen, works well in a Kanban board or simple list view, and gives enough signal to answer the daily questions: what’s blocked, what’s being worked on, and what’s waiting on review.

Keeping the set small also reduces “status hunting” (guessing which of 12 options is closest), makes reporting easier, and forces you to keep priority, owner, and type as separate fields.

Names can vary, and that’s fine. One team might say “In Progress,” another might say “Doing.” What can’t vary is the meaning. If “In Review” sometimes means “waiting for QA” and other times means “waiting for a customer,” your board becomes noise.

To keep meanings consistent, set up one source of truth: a short team doc with each status, what it means, and the rules for when something enters and leaves that status. Keep it short enough to read in two minutes. Then use that same set of statuses everywhere you show work.

A simple 7-status set you can start with

If you want workflow status labels that stay clear over time, start with a small set that answers three questions: who owns it right now, what happens next, and what “done” looks like.

Here’s a simple 7-status set that works for most teams without getting too detailed.

Key rule: don’t use “Waiting” by itself. If something is stuck, call it Blocked and name the dependency in the note (for example, “Blocked: customer reply” or “Blocked: access granted”).

Definitions for each status (with entry and exit rules)

Clear workflow status labels work best when each one answers a simple question: what is true right now?

New

What is true: the item was captured, but nobody has evaluated it yet.

What is not true: priority, scope, or owner is agreed.

Entry: a request is submitted.

Exit: someone reads it and moves it to Triaged.

Example: “A support agent logs a bug report with one screenshot.”

Triaged

What is true: the team understands the request well enough to route it and confirm it’s valid.

What is not true: it’s ready to start.

Entry: someone adds basic context (summary, impact, affected area).

Exit: it is either prepared for work (Ready) or intentionally rejected (handled outside the workflow, not as a status).

Example: “The PM marks it as a real bug and notes steps to reproduce.”

Ready

What is true: it can be started without missing info.

What is not true: work has begun.

Entry: acceptance criteria are clear and dependencies are in place.

Exit: a person starts work and makes the first meaningful change (In Progress).

Example: “The form fields and validation rules are agreed.”

In Progress

What is true: active work is happening.

What is not true: it is waiting in a queue.

Entry: someone picks it up and begins work.

Exit: it’s complete enough to be checked (In Review) or it hits a dependency (Blocked).

Example: “A developer builds the new status dropdown and saves the logic.”

In Review

What is true: it’s being checked (peer review, QA, or stakeholder approval).

What is not true: new features are still being added.

Entry: the doer submits it for verification.

Exit: it’s approved and meets the team’s definition of done (Done), or it goes back with feedback (In Progress).

Example: “QA confirms it works on both web and mobile.”

Blocked

What is true: work cannot continue due to a specific, named dependency.

What is not true: the item is simply lower priority.

Entry: the assignee hits a dependency they can’t resolve alone.

Exit: the dependency is removed and work resumes (usually In Progress).

Example: “Blocked: waiting for access to production logs.”

Done

What is true: it meets the agreed acceptance criteria and is shipped or ready to ship.

What is not true: it still needs review, testing, or follow-up.

Entry: review passes and release steps are complete (based on your team’s definition).

Exit: none; reopening starts a new cycle with a clear reason.

Example: “The fix is live and the bug no longer reproduces.”

Step by step: create your status system in 60 minutes

You can fix messy statuses in one focused meeting. The goal isn’t a perfect model. It’s a shared set of labels that match how work really moves, with rules your team can repeat.

A 60-minute working session (with one outcome)

Bring one person from each role that touches the work (requester, doer, reviewer, approver). Share a screen with your current board or list.

First, map the real workflow (not the ideal one). Pick one typical item and trace what actually happens, including wait time. Write the steps as plain verbs (“draft,” “review,” “approve”). If a step happens only sometimes, note it as a branch.

Next, remove duplicates and rename unclear labels. Merge labels that mean the same thing (“In Progress” vs “Doing”). Rename vague ones (“Pending”) into something you can act on (“Blocked: customer reply”). If you can’t explain a label in one sentence, it isn’t ready.

Then add definitions with entry and exit rules. For each status, write what must be true to enter and what must be true to leave. Keep it short. Example: “In Review enters when work is submitted, exits when feedback is addressed and the reviewer approves.”

After that, pick owners for each handoff. Every status should have a default owner (a role is fine). This prevents items from getting stuck. Example: items in “In Review” are owned by the reviewer, not the person who did the work.

Finally, test on 10 recent items and adjust. Take 10 finished or active items from the last few weeks and assign each one a status at each point in time. If you argue often, your labels overlap. If you can’t place an item, you’re missing a status or mixing two ideas into one.

After the meeting, publish the definitions in one place and make the labels match everywhere people see them.

Keep statuses consistent across web and mobile screens

If a status means one thing on the web and something slightly different on mobile, people stop trusting it. They start asking in chat, rechecking details, or creating their own “real status” in comments. The point of workflow status labels is shared truth, not decoration.

Treat the status as one shared field with one source of truth. The same label should appear with the same spelling, capitalization, and meaning everywhere: lists, detail screens, notifications, exports, and push messages.

Small-screen rules that actually work

Mobile screens punish long names and weak visual design. A status that looks fine in a desktop table can become a chopped, confusing badge on a phone.

• Keep names short (1-2 words where possible).
• Use consistent colors, but never rely on color alone.
• Design for the longest label so nothing truncates into unreadable fragments.
• Keep the order consistent across platforms.
• Avoid “almost the same” labels like “In Progress” vs “Working.” Pick one.

Placement matters too. Put status near the title on the detail view so it’s seen before someone reads the full description. In list views, show it in the same position every time.

Accessibility basics help everyone. Color is a hint, not the message. Always show the text label, and consider a simple icon (like a check for Done) so people who use screen readers or have color vision issues still get the meaning quickly.

Common mistakes that make statuses drift

Statuses drift when they stop meaning “where the work is” and start meaning “how people feel about the work.” Once that happens, your board looks busy, but nobody can trust it.

One common cause is too many labels that match every tiny step. If a task can move three times in an hour, people stop updating it, or they pick a “close enough” status. A small set works best when each move is a real change in readiness or responsibility.

Another drift point is mixing different dimensions into one field. Priority and urgency matter, but they belong in separate fields, not in the status. If “Urgent” is a status, it will compete with “In Review,” and your reporting won’t mean much.

Watch for these patterns:

• Multiple “done-ish” labels with no clear difference
• One-off personal labels (“Waiting for Sam”)
• “In Progress” becoming a parking lot
• No written entry and exit rules
• New screens showing different status names or order

To prevent drift, set one owner for the status set and make changes rare. When you do change something, write down what changed, why, and what it replaces.

Example: one request from start to done

A customer writes support: “On mobile, the order history page shows an empty state even when I have orders.” Support logs one item that will become a product fix and then a release.

New: Support captures screenshots, device details, and what “correct” should look like.

Triaged: The product owner confirms it’s a real bug, chooses where it belongs (mobile app, not backend), and clarifies the impact.

Ready: Steps to reproduce are confirmed and the acceptance criteria are clear.

In Progress: An engineer reproduces the issue, finds that the API returns data but the screen filters it incorrectly, and starts the fix.

Blocked: The engineer discovers the UI depends on a field missing from older accounts and needs a backend change. The item is marked Blocked with one clear note: “Blocked: backend needs legacy field mapping.”

In Review: After the dependency is solved, QA checks iOS and Android and verifies the empty state still works when there are truly no orders.

Done: The fix is approved and released (or queued for the next release window, if that counts as done for your team). Support confirms it’s live and replies to the customer.

Notice what prevents confusion: “Blocked” has one reason and one next action, and ownership doesn’t bounce around. Anyone can open the item and understand who has the ball.

Quick checklist to keep the team consistent

If your board feels messy, you can usually spot why in 10 minutes.

10-minute board scan

Walk the board and look for these signals:

• Every status answers: “What is true right now?”
• Each status has a default owner (role is fine) and a clear next action
• No two statuses could describe the same item at the same time
• Items aren’t parked with no decision point (if it can sit for days, add an exit rule)
• The same work types move through the same core steps, unless there’s a written exception

If people disagree on where a card belongs, that status overlaps with another or isn’t defined enough.

Web + mobile consistency check

Open the same workflow on a phone and confirm the labels still work in tight spaces.

• Labels are short and readable in list views (no truncation)
• Text is clear without relying on color
• Status changes are approved by one owner (team lead or ops), not decided per person
• Changes come with a brief note so definitions don’t drift

Next steps: maintain, measure, and improve over time

Status systems stay useful when you treat them like a rulebook: stable, but reviewed. The goal isn’t constant change. It’s consistent use.

Set a lightweight cadence, like a 30-minute monthly review with one person from each role that touches the board. Bring 5-10 recent items and look for exceptions you can fix.

A few simple signals worth tracking:

• Time spent in Blocked (and the top reason)
• Items that bounce between two statuses
• Items that sit untouched past your normal cycle time

When something feels off, resist adding a new status right away. Add a status only when the new state is truly different, changes what people do next, and happens often. Most of the time, the fix is simpler: tighten the definition, add an entry rule, or clarify ownership.

If you’re building the workflow into an internal tool, treat statuses as shared data rather than screen-specific text. In AppMaster (appmaster.io), for example, you can define the status field once in the Data Designer and reuse it across web and native mobile apps, which helps prevent “it means something different on my phone” drift.