Task Status Definitions: Open, In Progress, Blocked, and Done

Make statuses describe state, not mood

“Working on it” can mean started, waiting, or almost done. Define open as not started, in progress as active work, blocked as unable to proceed without a dependency, and completed as meeting the agreed finish line. Add more states only when a decision depends on them.

• Open: owner can see the work but has not begun.
• In progress: next action is underway.
• Blocked: a named dependency prevents progress.
• Completed: definition of done is met.

Keep a blocked item visible

Blocked is not a parking lot. Record who can remove the obstacle and when it will be checked. If the tool only exposes fewer status options, write the blocker in the task update and keep the item open rather than marking it complete.

Start with a shared vocabulary

A status is useful only when two people interpret it the same way. “Open,” “in progress,” “blocked,” and “completed” are enough for many small teams, provided each has a clear meaning. Open means the work is assigned but not started. In progress means the owner is actively moving toward the result. Blocked means a named dependency prevents the next useful action. Completed means the agreed definition of done has been met and any required verification is recorded.

Do not let a status stand in for the whole update. “Blocked” alone does not tell a manager what to decide. “Completed” alone may not tell dispatch which batch passed. Keep the vocabulary small and add a concise note where the state needs context. The status supports filtering; the note supports action. Together they let a manager scan a list and then open the item that needs attention.

Publish the definitions where people create and update tasks. A one-page team rule or short help text is usually better than a long policy document. Use real examples from the workflow. If workers cannot decide whether an item is blocked or in progress, inspect the next action. If no one can take it until an outside input arrives, name that input and use blocked. If work can continue, stay in progress.

Open means ready for an owner

An open task should have an outcome, owner, and due time even though work has not begun. If it has no owner, it is not simply open; it is an assignment gap that somebody must resolve. If it has no clear result, the owner may waste time discovering what the requester meant. The open state should mean the task is ready to be picked up, not that a vague idea was stored for later.

Different teams may use “to do” instead of open. The label matters less than the rule. A worker should know that open items belong in their queue and should be started in time to meet their commitments. A manager should be able to distinguish an open task due next week from one due this afternoon. The due time and priority provide that context; the status alone does not.

Move to in progress when a meaningful next action begins, not merely when the owner reads a notification. A read receipt proves awareness, not effort or result. If the worker discovers immediately that a required part is missing, a blocked state or blocker note may be more truthful than in progress. The task should reflect what can happen next, so the manager can respond appropriately.

In progress means work can move

In progress covers active work that has not yet met its finish line. It does not require constant activity every minute. A technician may be on another call while a repair remains in progress, as long as the next action and plan are clear. What matters is whether the owner can still advance the task without an unresolved external dependency. If not, blocked is a better description.

Add a meaningful update at checkpoints. “18 of 20 cartons checked; two remain before the 3 PM review” helps the manager judge whether the deadline is safe. “Working on it” may be enough earlier when the work is routine and no decision depends on finer detail. Avoid forcing long narratives just to justify the status; ask for verified facts when a handoff or promise depends on them.

If scope changes during progress, revise the task and due time explicitly. A visit may expand into a repair, or a supplier may confirm only part of an order. In progress should not hide a new customer commitment that nobody has accepted. Split independently owned results when needed. The status is a shorthand for current movement; the task body and history still carry the promised outcome.

Blocked needs a named dependency

Blocked should mean the owner cannot take the next useful step until a specific input, decision, or resource arrives. Write the missing item, who can provide it, the affected result, and when it must arrive. “Waiting for approval” is too vague; “Plant manager to choose standard or substitute belt by 2 PM so purchasing can order today” gives somebody a decision to make.

Do not use blocked as a parking lot for work that is merely low priority or inconvenient. If the owner can proceed but has chosen another task first, keep the task open or in progress as appropriate, and make the priority or schedule clear. Misusing blocked inflates the apparent number of external obstacles and makes real dependencies harder to spot. Conversely, leaving a truly blocked task in progress can make a manager think it is safely moving.

The owner of the overall outcome usually remains responsible for following the blocker until it is removed or the task is deliberately handed off. A manager may own the approval, but the repair lead still owns the repair plan. Set a checkpoint and update the state after the input arrives. An old blocked label left in place after approval can trigger unnecessary escalation and conceal that the next step is now ready.

Completed follows the finish line

Completed is a claim that the result the task promised has been produced and verified to the agreed level. For an appointment, a sent offer may not be enough; the customer and technician may need to confirm the slot. For a repair, installing the part may not be enough; the machine may need to pass a normal test. For an inspection, the result may be a documented pass or fail, with exceptions assigned to separate work. Define this before assignment.

Do not close a parent outcome because one supporting task finished. Purchasing can order a belt while maintenance still waits for delivery and verification. The purchase task may be complete when the order and delivery date are confirmed, but the repair remains open. Clear task boundaries help the team use completed honestly without forcing everything into one giant status.

If work is partially done, record the portion and what remains. If a customer accepts a partial shipment, revise the promise explicitly and create a new task for the remainder. Do not close the original commitment silently to improve a completion count. Accurate completion history helps managers plan future work; inflated counts make the dashboard look healthy until the next team asks where the missing result is.

Treat waiting and review carefully

Some teams are tempted to add “waiting,” “under review,” “pending customer,” and several other states. These may be useful when different people must act on each state, but they can also make status selection ambiguous. Before adding a label, ask what new decision it supports. If the same owner and manager respond in the same way, a blocker or update note may be sufficient.

Waiting on a customer response may differ from waiting on an internal approval. The task owner may need a follow-up time rather than an immediate escalation. If that distinction changes the workflow, record it clearly in the task or add a state with a precise meaning. Do not mark the task complete merely because a message was sent unless the requested result was the sending itself. A customer acceptance task remains open or waiting until the acceptance arrives or the promise is revised.

Review is a separate result when another person must verify work. A production worker may finish packing, while quality owns inspection and release. Give the review its own owner and deadline when it can delay the final commitment. Then the packing task can be completed honestly and dispatch readiness remains open. More statuses should not replace clear ownership of sequential steps.

Define allowed changes in plain language

Most tasks move from open to in progress to completed. A blocker can interrupt either stage, then return to in progress when the dependency clears. A task can also be reassigned or canceled with a reason. The team should understand these transitions without memorizing a complex diagram. The important rule is that a status change reflects a real change in what can happen next.

If a completed task proves wrong, reopen or create a correction task according to the team's workflow. Record what failed verification and who owns the fix. Do not erase the earlier closure silently; the history helps explain why another team acted on the result. Similarly, if a blocked task is canceled because the customer no longer needs the work, record cancellation rather than calling it completed. A canceled promise and a fulfilled promise mean different things.

Make sure the tool supports the labels and transitions the article describes. If it exposes fewer statuses, use the available state plus a clear update note. A team should not teach workers to select a “blocked” option that does not exist. The operational definition matters more than the exact button names; the record must still show the blocker and next decision.

Use status with deadlines and owners

Status is only one dimension of a useful task view. An open item due next month and an open item due in an hour both say open; they demand different attention. A blocked item with a decision maker named can be acted on; one with no owner remains a risk. Pair status with the outcome, owner, due time, latest update, and next checkpoint when scanning work.

For example, a manager looking at a repair list should see that machine M4 is blocked on a belt choice due at 2 PM, not only a red badge. They should be able to open the task, review options, and record a decision. After approval, the status and note should update so purchasing can proceed. If only the badge changes, the workflow may remain stalled because no one knows what the decision was.

Avoid ranking workers by raw counts of completed tasks. A simple filing task and a complex repair are not comparable units, and a team with honest blocked statuses may look worse than one that closes unresolved work. Use status to guide action and discover process gaps. Review a sample of completed and delayed items before using totals to judge performance.

Calibrate the vocabulary with real tasks

Take five recent tasks and ask two workers independently what status each should have at specific moments. If answers differ, discuss the next action and completion condition. A machine repair might be in progress during diagnosis, blocked when a part is unavailable, back in progress after delivery, and completed after restart verification. This concrete exercise reveals whether the team has shared definitions.

Write one sentence and one example for each status. Include an exception example where the task's own work is done but a parent outcome remains open. Show workers how to record a blocker when the tool has no dedicated blocked state. Keep the language close to the team's everyday work instead of importing labels that sound formal but do not change decisions.

Revisit the definitions after a few weeks. If people repeatedly ask whether “sent to customer” is completed, the finish line for customer tasks may be unclear. If blocked tasks linger after approvals, the team needs a resume checkpoint. Fix the task design or transition rule that caused the confusion. A small, trusted status vocabulary gives the manager a more reliable view than a large set of labels used inconsistently.