Simple status tracking for small teams

Statuses should show where a job stands and what it needs next. They should not become a minute-by-minute measure of whether somebody appears busy. Start with the questions the team needs answered: what is new, ready, actively being handled, blocked, awaiting the customer or finished? Use one shared board or list as the operational view. Private notes and inbox flags should not contradict the visible job state.

Status alone cannot tell the team who acts next. Each live job needs a current owner, a dated next action and, where relevant, a due or review date. Age is especially useful for received and blocked work. Avoid assigning every job to a manager as a safety net; this hides real ownership. When responsibility changes, the receiving person should accept it rather than discovering it in a crowded board.

A label is useful only when people apply it consistently. Define what must be true before a job enters ‘ready to schedule’ or ‘complete’. ‘In progress’ should mean active work has started, not that somebody intends to look at it eventually. If a stage has no meaningful entry condition or different people interpret it differently, rename, split or remove it rather than adding colour and hoping for clarity.

Do not leave a blocked job in ‘in progress’. Mark it blocked or awaiting customer and record the release condition, responsible chaser and next review date. Separate internal blocks from customer waits if they require different action. A block reason should be concise and factual, such as ‘awaiting approved drawing from AB’, not a blame-filled narrative. Review old blocks routinely so they do not become permanent storage.