Why “on hold” becomes a problem so quickly
When a customer asks to pause a job, most businesses do the obvious thing: they change the status to On Hold and move on.
That sounds reasonable until a few weeks later when nobody is quite sure what that status actually means.
Is the job still expected to proceed?
Has scheduling been released?
Should materials still be ordered?
Does someone need to follow up?
Is it still counted in the forecast?
Can the customer restart it at any time, or does it need to be reviewed first?
This is why on-hold jobs often become a parking lot. The status exists, but the operating rules around it do not.
The result is usually a mix of problems:
- jobs quietly disappearing from active management
- schedulers keeping space blocked for work that may not resume soon
- purchasing continuing when it should have stopped
- project teams assuming someone else is following up
- revenue forecasts including work that is no longer realistically imminent
- old jobs resurfacing months later without a proper restart process
The issue is not the label. The issue is that “on hold” is being used as a vague description instead of a controlled operational state.
“On hold” needs to mean something specific
A job should only be marked On Hold if the customer has actively paused progression after the job has already entered a live delivery path.
That matters because “on hold” is not the same as every other kind of delay.
A useful status model usually distinguishes between these states:
- Waiting on customer: the job cannot move because customer input, approval, access, information or another action is still outstanding, but the job has not been formally paused.
- On Hold: the customer has explicitly asked for the job to stop or pause for a period of time.
- Rescheduled: the work is still active and intended to proceed, but the booked timing has been moved to another confirmed or managed date.
- Cancelled: the work is no longer expected to proceed.
If those states are blurred together, reporting becomes unreliable and staff start making assumptions.
For example, a job waiting on a customer decision may still need active chasing and remain commercially live. A cancelled job should come out of the delivery pipeline altogether. A rescheduled job may still require retained materials, crew allocation planning and customer communication. An on-hold job sits in a different category again: not dead, not active, and not free to drift indefinitely.
The real question is what obligations continue while the job is paused
When a customer puts a job on hold, the business needs to decide what actually stops and what does not.
This is where many workflows break down. Teams assume that putting a job on hold is a universal pause button. It rarely is.
Different parts of the operation may need different treatment, including:
- scheduling
- labour allocation
- purchasing
- subcontractor commitments
- customer updates
- approvals
- deposits or progress claims
- internal review
- forecasting
If none of that is defined, staff make local decisions. One person stops everything. Another keeps ordering materials. Someone else leaves the job in the forecast because “it might come back next month”.
That inconsistency is what causes operational noise.
A proper on-hold design answers a simple question:
When this status is applied, what should the system and the team do next?
What should be captured when a job is placed on hold
If a job can be marked on hold without additional information, it will usually become invisible.
At minimum, the person placing the job on hold should capture:
- reason for hold
- who requested or approved the hold
- date the hold started
- expected review date
- notes about any commitments already made
- conditions for reactivation
The review date is particularly important. Without one, “on hold” often means “someone should think about this later”.
The reason also matters more than people think. “Customer put on hold” is not enough. There is a big difference between:
- customer delaying due to site readiness
- customer delaying due to finance timing
- customer delaying pending internal approval
- customer delaying due to access or tenant issues
- customer delaying indefinitely with no confirmed return window
Those scenarios should not all be managed the same way.
The point is not to collect extra admin for its own sake. The point is to make the status operationally usable.
Define when a job is allowed to go on hold
Not every delay should become an on-hold state.
If staff can use the status too freely, it becomes a convenient place to move awkward jobs. That hides workflow issues rather than solving them.
You need rules for when a job can actually be placed on hold. For example:
- The customer has explicitly requested a pause.
- The request has been acknowledged by the appropriate internal owner.
- The operational impact has been reviewed.
- A review date has been set.
- The downstream actions have been triggered.
This prevents “on hold” from being used as shorthand for:
- we cannot get hold of the customer
- the quote has gone quiet
- we are not ready internally
- nobody knows what to do next
- scheduling is difficult
- approval is still pending
Those are different problems and should be visible as different states.
Decide what gets paused and what does not
A job being on hold should trigger deliberate decisions across connected workflows.
Scheduling
The first question is whether scheduled labour or field capacity should be released.
In many businesses, the default behaviour is messy. A scheduler leaves the job tentatively sitting in the calendar “just in case”, which blocks capacity and creates false load. Or they remove it entirely without any note about what happens when the customer wants to restart.
You want a clear rule such as:
- remove future scheduled work from the active run sheet
- release technician or installer capacity
- retain historical scheduled records for audit and context
- require fresh scheduling on reactivation
That keeps the live schedule accurate without losing job history.
Materials and purchasing
Materials need special attention because procurement often runs on a different timeline to delivery.
If a customer pauses a job, ask:
- should unplaced purchase orders be stopped?
- should committed orders continue because of lead times or supplier constraints?
- should stock already allocated remain reserved?
- are there return, restocking or storage implications?
A blanket pause can create supply problems later. But continuing automatically can tie up cash and inventory unnecessarily.
This is why the on-hold workflow should include a purchasing review rather than relying on assumptions.
Approvals and documentation
Some approvals may expire. Some site information may go stale. Some compliance documents may need to be rechecked before work resumes.
If a job might sit for a while, reactivation should not assume everything previously gathered is still current.
An on-hold process should therefore flag whether any of these may need review before restart:
- site access details
- drawings or scope documents
- permits
- inductions
- pricing validity
- customer contacts
- subcontractor availability
Customer communication
One of the easiest mistakes is putting a job on hold internally while the customer hears nothing for months.
A proper hold process should define:
- confirmation that the hold has been recorded
- what the customer should expect next
- when the next follow-up will happen
- what is required from them to restart
That removes ambiguity on both sides.
Every on-hold job needs an owner
The fastest way to lose control of paused work is to give the status no owner.
If the rule is simply “the job is on hold”, then responsibility becomes unclear. Operations may assume sales is following up. Sales may assume the project team owns it. Accounts may still expect a progression date. Nobody is wrong enough for the problem to be obvious, but nobody is responsible enough for the job to move.
An on-hold job should have a clearly defined owner. That owner is responsible for at least three things:
- confirming the hold was applied correctly
- reviewing it on the expected date
- deciding what happens next if the hold continues
The owner is not necessarily the person doing all follow-up manually. Some reminders can be automated. But there must be a named role accountable for the outcome.
Review dates and expiry logic stop the parking-lot effect
This is the part most businesses miss.
An on-hold job should not remain paused forever simply because the status exists. It needs review logic and, in many cases, expiry logic.
Review logic means the system prompts action on a set date. For example:
- follow up with the customer in 14 days
- review site readiness in 30 days
- escalate to a manager if there is no response after two follow-ups
Expiry logic means the job cannot remain in this state indefinitely without a further decision. For example:
- after 60 days on hold, require management review
- after 90 days, remove from short-term forecast automatically
- after a defined period, move to a dormant pipeline or closure review if no restart is likely
That does not mean the job is lost. It means the business stops pretending it is still active in the same way as live work.
Without this, on-hold jobs quietly distort everything around them.
On-hold jobs should not distort forecasting and capacity planning
A common reporting problem is that on-hold work remains mixed into active pipeline and expected delivery figures.
That creates two kinds of confusion.
The first is revenue forecast distortion. Jobs that are commercially real but operationally paused may still appear as near-term delivery revenue even though there is no confirmed path to execution.
The second is capacity planning distortion. Teams can look overbooked because future work includes jobs that are not actually ready to proceed.
The fix is not to delete those jobs from reporting. The fix is to classify them properly.
A good reporting model usually makes on-hold work visible but separate. For example:
- active scheduled work
- active unscheduled work ready for scheduling
- on-hold work with review dates
- dormant or aged paused work
- cancelled work
That gives management a clearer picture of what is actually deliverable, what may come back, and what should not be relied on for short-term planning.
Reactivation should be a defined process, not just a status change
Another weak point is what happens when the customer says they are ready to proceed again.
In many businesses, someone simply changes the status from On Hold back to In Progress or Ready to Schedule and assumes the job can carry on where it left off.
That is risky.
A job returning from hold may need revalidation before it re-enters delivery. A practical reactivation checklist might include:
- confirm the customer still wants to proceed
- confirm scope and pricing are still valid
- confirm site details and access arrangements
- check whether materials are available or need reordering
- confirm labour or subcontractor availability
- review any expired approvals or documents
- re-enter the job into scheduling using current priorities
This matters because a paused job often re-enters a business under different conditions than when it left.
For example, a customer may call after eight weeks and want the work restarted urgently. If the original crew is no longer available, materials were never ordered, and site details have changed, the job cannot simply resume as if nothing happened.
A controlled reactivation process prevents that scramble.
A simple state model for customer-paused jobs
The exact wording will vary by business, but the logic should be clear.
A practical model might look like this:
1. Active delivery state
The job is progressing through quoting, planning, scheduling or execution.
2. Customer-requested hold
The customer has explicitly paused the job. The system captures reason, owner, start date and review date. Defined workflows are paused or adjusted.
3. Hold review due
The review date arrives and triggers follow-up or internal review. The owner decides whether the job should remain on hold, be reactivated, or move toward closure or dormancy.
4. Reactivation assessment
Before resuming, the business confirms operational readiness and validates that the job can re-enter active delivery properly.
5. Return to active workflow
Once validated, the job moves back into the correct live state, such as ready for scheduling or active project delivery.
The key idea is that on hold is not a dead-end status. It is a controlled exception state with entry rules, obligations during the hold, and defined exit paths.
What good looks like in practice
If an on-hold workflow is working properly, a manager should be able to answer these questions quickly:
- why is this job on hold?
- who approved or recorded the hold?
- when is it due for review?
- what has been paused?
- what commitments remain live?
- is it still included in short-term forecast?
- what needs to happen before it can restart?
If those answers are not obvious, the status is probably too vague.
Good operational control does not require a large system overhaul. In many cases, it starts with a better state model and a few clear rules:
- only allow on-hold status for genuine customer-requested pauses
- capture reason, owner and review date every time
- define what scheduling, purchasing and communication actions that status triggers
- make follow-up automatic where possible
- separate on-hold work from active work in reporting
- require a reactivation check before the job returns to delivery
That is what turns “on hold” from a parking lot into a manageable business state.
The goal is not more statuses. It is clearer control
Adding a new status does not solve much by itself. The value comes from defining what the status means operationally.
When a customer pauses work, the business needs more than a label. It needs a controlled way to preserve visibility, release or retain the right resources, follow up at the right time, and restart properly when the job is ready.
If your jobs move across multiple teams or systems, this is usually where simple status labels stop being enough. Mapping the hold, review and reactivation workflow properly can remove a lot of hidden friction. That is the kind of workflow design 5M Consulting helps businesses sort out when jobs keep disappearing into operational grey areas.