Most status problems are really workflow design problems
A lot of businesses have no shortage of statuses. The problem is that the statuses do not actually run the workflow.
You’ll see boards, job lists or project views filled with labels like:
- In Progress
- Pending
- On Hold
- Sent
- Waiting
- Review
- Complete
At first glance, that looks organised. In practice, it often creates false visibility.
Everyone can see that an item has a status, but the status does not answer the operational questions that matter:
- Who owns this right now?
- What is supposed to happen next?
- What is it waiting on?
- When should someone intervene?
- How do we know it is actually finished?
That is why work sits still while the system appears busy.
A good status model does not just describe where something is. It should define responsibility, trigger actions and make the next step obvious. That is what allows dashboards, reminders, escalations and automation to work properly later.
If statuses are vague, everything built on top of them becomes unreliable.
Why so many status models fail
Most poor status structures develop for understandable reasons.
A business adds statuses gradually over time. Someone wants a better way to sort jobs. Another person wants more reporting categories. A manager adds a label to reflect an exception. A software platform comes with default columns and everyone works around them.
The result is usually one of these problems.
Statuses describe activity without defining control
“In Progress” is the classic example.
It sounds useful, but it usually covers too much. A quote being worked on, a technician attending site, an office team waiting on supplier pricing, and a manager reviewing variations can all be described as “in progress”, even though they require completely different handling.
If one status can represent several operational realities, it becomes difficult to automate anything or hold anyone accountable.
Overlapping statuses mean different people use them differently
If you have statuses like:
- Pending
- Waiting
- On Hold
- Review
- Action Required
there is a good chance different staff interpret them differently.
One person uses “Pending” for customer approval. Another uses it for internal review. Someone else uses it when they plan to come back to it later.
Once a status can mean several things, the system stops being a reliable source of truth.
There are too many statuses because the business is trying to describe every nuance
Statuses are not there to capture every detail of a job. They are there to control movement through a workflow.
If you create a separate status for every possible circumstance, the model becomes hard to use, people stop applying it consistently, and reporting becomes less trustworthy.
Often the detail belongs somewhere else, such as a reason field, flag, checklist, date field or note.
Completion is not defined properly
A job might be marked complete when the field work is done, even though photos are missing, customer sign-off has not been captured and invoicing cannot proceed.
A quote might be marked sent, but nobody knows whether follow-up is due or whether it is waiting on information first.
If entry and exit rules are unclear, statuses become personal interpretations rather than system states.
What a status should actually do
A useful status should tell the business something operationally important.
At minimum, a status should help answer these four questions:
- Who owns this now?
- What needs to happen next?
- What event moves it forward?
- What makes it leave this status?
If a status does not help answer those questions, it is probably too vague to drive workflow.
That applies whether you are managing jobs, quotes, internal tasks, approvals, site inspections or customer requests.
A status is not just a label. It is part of the process architecture.
Design statuses around control points, not vague descriptions
The best way to design statuses is to base them on meaningful workflow states.
In most operational processes, those states tend to fall into a few practical categories.
Decision points
These are points where someone must actively decide something before work can continue.
Examples include:
- quote awaiting approval
- variation awaiting approval
- manager review required
- technical review required
These statuses should make it clear who the decision-maker is and what they are deciding.
Handovers
These happen when responsibility moves from one person or team to another.
Examples include:
- quote approved, ready for scheduling
- job ready for invoicing
- site work complete, awaiting QA
- sales handover to operations
A handover status should not just say that one step has ended. It should indicate that another team now owns the next action.
Waiting states
These are legitimate pauses where progress depends on something external or upstream.
Examples include:
- awaiting customer response
- awaiting supplier pricing
- awaiting site access
- awaiting required documents
This is different from active work. If the team is waiting, the system should say what it is waiting for.
Active work states
These are states where someone is currently expected to do something.
Examples include:
- quoting in progress
- scheduled for installation
- technician onsite
- payroll review in progress
These can be useful, but only if they are specific enough to imply actual ownership and expected activity.
Completion states
These define when the workflow, or a phase of it, is truly complete.
Examples include:
- quote won
- quote declined
- installation complete
- invoiced
- closed
Completion should reflect a clear business outcome, not just someone feeling finished with the item.
Each status should imply an owner and a next action
This is where many status models become useful or useless.
If an item is in a given status, there should be a reasonably clear answer to both of these:
- who owns it now
- what should happen next
For example:
Awaiting customer approval
- Owner: sales or account manager
- Next action: follow up by due date or move forward once approval is received
Ready for scheduling
- Owner: scheduling team
- Next action: assign date, crew or technician
Awaiting site photos
- Owner: field team or coordinator, depending on process design
- Next action: obtain missing photos so review or invoicing can proceed
Ready for invoicing
- Owner: accounts or admin team
- Next action: issue invoice based on completed and verified job details
Compare that with a status like “Pending”. It tells you almost nothing.
A good status reduces the amount of chasing people need to do. A poor status creates more chasing because staff still need to ask what “pending” actually means.
Define entry and exit criteria for every important status
One of the simplest ways to improve a workflow is to define what must be true for an item to enter a status, and what must happen for it to leave.
This does not need to become bureaucratic. It just needs to be clear enough that different staff apply the status consistently.
For example:
Ready for scheduling
Entry criteria
- quote approved
- required job details captured
- scope confirmed
Exit criteria
- installation date assigned
- resources allocated if required
Awaiting customer information
Entry criteria
- progress blocked by specific missing customer information
- request already sent to customer
Exit criteria
- requested information received
- item reassigned to active processing
Complete
Entry criteria
- all required work finished
- mandatory documentation received
- internal quality checks passed if relevant
Exit criteria
- none, unless the business allows reopening under defined conditions
Without entry and exit criteria, staff will use statuses based on habit or convenience. That is when reporting stops reflecting reality.
Separate active work from waiting states
This is one of the most important design principles.
If active work and waiting are mixed together, you lose visibility very quickly.
A board full of “In Progress” items may contain:
- work someone is doing now
- work queued for later
- work blocked by a customer
- work blocked by missing materials
- work waiting on manager approval
Operationally, those are not the same thing at all.
If you separate active states from waiting states, several things improve immediately:
- workload becomes easier to understand
- bottlenecks become more visible
- follow-ups can be triggered properly
- escalations can be based on time in status
- reporting becomes more useful
A waiting status should usually answer one extra question: waiting on what?
For example, “Awaiting customer response” is far more useful than “On Hold”.
Avoid overlapping or ambiguous statuses
A strong status model is not necessarily a large one.
In fact, fewer clear statuses are usually better than a long list of vague or overlapping ones.
Common signs of overlap include:
- multiple statuses that all mean delayed
- separate statuses that different teams use interchangeably
- labels that describe mood rather than process state
- statuses that duplicate information stored elsewhere
If you already have a messy set of statuses, a useful clean-up exercise is to ask of each one:
- What exact situation does this represent?
- Is that situation meaningfully different from another status?
- Does this status change ownership, next action or reporting?
- Could this be better captured as a tag, reason code, checkbox or date instead?
For example, “Urgent” usually should not be a workflow status. It is a priority signal.
Likewise, “Needs Attention” is often too vague to be a status. Attention from whom, for what reason, and what moves it forward?
Use statuses to support exceptions, not hide them
Real operations always have exceptions.
A technician cannot complete a job because access was denied. A quote cannot proceed because the scope is unclear. An approval sits with a manager longer than expected. A handover arrives missing key information.
The answer is not to create a new status for every rare situation. But the status model should still be able to surface exceptions clearly.
That usually means combining a clean core status structure with supporting fields such as:
- blocked reason
- approval due date
- missing information flag
- exception type
- escalation owner
For example, a job may sit in “Awaiting customer response”, while a separate field records whether the reason is access, document approval or pricing confirmation.
That keeps the main workflow readable while still allowing better reporting and targeted follow-up.
This matters because exceptions are where workflows often fail. If your status model has no practical way to represent blocked or abnormal states, staff will work around the system in notes, emails and memory.
Good automation depends on good status design
Businesses often want reminders, automatic notifications, escalations and cleaner dashboards. All of that depends on whether statuses represent real workflow states.
Automation works best when the system can trust the state of the item.
For example:
- when a quote moves to Sent, start a follow-up timer
- when a job moves to Ready for Scheduling, notify the scheduling team
- when an item remains in Awaiting Approval beyond a defined time, escalate it
- when a job reaches Completed and Verified, create the invoicing task
- when a request is marked Awaiting Customer Information, send the customer a specific prompt
Those actions only make sense if statuses are applied consistently and mean one thing.
If staff use the same status in different ways, the automation either becomes noisy, gets bypassed or creates more admin than it removes.
This is why status architecture is foundational. Reminders, escalations and dashboards are not separate features floating above the workflow. They depend on the workflow state being trustworthy.
Reporting quality depends on status discipline
A lot of reporting problems start much earlier than people think.
When management says they do not have visibility, the issue is often not the dashboard tool. It is that the underlying workflow states are inconsistent.
If statuses are unclear, reporting questions become difficult to answer reliably:
- How many quotes are genuinely awaiting customer approval?
- How many jobs are ready for invoicing?
- What work is actively being processed versus blocked?
- Where are delays occurring most often?
- Which approvals are sitting too long?
If the team uses statuses loosely, reports end up showing an approximation of reality rather than operational truth.
Good reporting depends on disciplined status use, and disciplined status use depends on a status model that is simple, clear and operationally meaningful.
People are much more likely to apply statuses properly when the statuses actually help them do the work.
A practical framework for designing a better status model
If you are redesigning statuses for jobs, quotes, tasks or approvals, start with the workflow itself rather than the current software labels.
1. Map the real process
Write down the actual movement of work from start to finish.
Include:
- where the work enters
- who touches it
- where decisions happen
- where handovers occur
- what can block progress
- what true completion looks like
Do not start by listing status names. Start by understanding the process.
2. Identify the meaningful state changes
Not every action needs a status. Focus on moments where one of these changes:
- ownership
- next action
- decision required
- waiting condition
- completion state
Those are usually the right candidates for statuses.
3. Define the minimum useful set of statuses
Aim for the smallest number of statuses that still gives clear operational control.
If two statuses do not change behaviour, ownership or reporting in a meaningful way, they may not need to be separate.
4. Define owner, next action, entry and exit criteria
For each status, document:
- what it means
- who owns it
- what should happen while it is there
- what event moves it out of that state
This is where the model becomes workable rather than theoretical.
5. Separate waiting from active work
Make sure your team can distinguish between:
- work being actively progressed
- work queued for someone else
- work blocked by an external dependency
- work complete but awaiting downstream processing
That separation creates much better visibility.
6. Decide what belongs outside the status field
Use supporting fields for:
- priority
- blocked reason
- job type
- exception category
- due date
- approval level
Statuses should control flow. They should not carry every piece of context.
7. Test the model against real exceptions
Take a few common awkward scenarios and see whether the status structure still works.
For example:
- missing site photos
- quote approved with incomplete details
- technician finished work but defect rectification required
- manager approval overdue
- customer unresponsive for several days
If the model breaks as soon as real-life exceptions appear, it needs adjustment.
What good status design looks like in practice
A good status model usually feels boring in the best possible way.
People know what each state means. Work moves predictably. Ownership is visible. Waiting items are not mixed into active workload. Reports start matching operational reality more closely. Automation becomes easier to trust.
Just as importantly, the system becomes less dependent on individuals remembering what should happen next.
That is the real point.
A status should not merely help someone sort a list. It should help the business control the flow of work.
If your current statuses are vague, overlapping or inconsistent, it is worth fixing the model before adding more dashboards, reminders or automation. Once the workflow states are clear, those tools become much more useful. If a process spans multiple teams or systems, mapping the workflow and redesigning the status architecture first is often the step that prevents a lot of downstream complexity. 5M Consulting helps businesses do exactly that when workflow visibility and system behaviour no longer match how the operation actually needs to run.