Multi-team jobs need more than a generic job status
A job that involves one technician on one visit can often survive with a simple status flow such as booked, in progress and complete.
A job that passes through multiple internal crews, specialist teams or subcontractors cannot.
Once several parties are involved, the real work is no longer just completing the job. It is coordinating sequence, readiness, information and ownership between stages. If the workflow does not make those things explicit, the business ends up relying on phone calls, memory and assumptions.
That is when problems start to appear:
- one team arrives before the previous stage is actually finished
- a subcontractor assumes materials are on site when they are not
- a crew marks its part complete without the photos or notes the next team needs
- admin believes the job is progressing, but it is really sitting in limbo
- everyone thinks someone else has the next action
- the whole job gets marked complete because one stage finished
These are usually not people problems first. They are workflow design problems.
If a multi-team job is managed under one generic status, the system cannot answer basic operational questions:
- Which stage is the job actually up to?
- What is waiting right now?
- What prerequisite has not been met?
- Who owns the next action?
- What information must be handed over before the next team starts?
- Is the overall job complete, or is only one work package complete?
A better design starts by treating the job as a sequence of controlled stages, not one block of work.
The core mistake: treating a multi-stage job like a single piece of work
In many businesses, a job record exists as one item with one assigned status. Everyone involved works off that same record, even though the job might include several distinct delivery steps.
For example, a job might involve:
- site inspection
- preparation or make-safe work
- installation by one crew
- specialist electrical work
- quality check
- defect rectification
- final sign-off
If all of that sits under one status called in progress, the system hides what actually matters.
The issue is not just visibility. It also affects behaviour.
A generic status allows teams to interpret progress differently. One crew might think in progress means their part has started. Admin might think it means the whole job is underway and on track. Management might assume the job is close to complete. None of those interpretations are reliable enough to run operations.
The workflow needs to reflect the real delivery structure.
Start with explicit stages, not vague progress labels
The first step is to break the job into meaningful operational stages.
A good stage is not just a label. It represents a point in the workflow where:
- ownership is clear
- entry conditions are known
- required information is defined
- completion criteria are defined
- the next action can be triggered
For a multi-team job, stages often map to actual handovers between groups. That is important because handovers are where work most commonly slows down or breaks.
A stage-based workflow might look something like this:
- ready for initial attendance
- initial attendance complete
- waiting for internal review
- ready for team A
- team A complete
- waiting on specialist subcontractor
- subcontractor booked
- subcontractor work complete
- ready for final inspection
- defects identified
- ready for close-out
- completed
That does not mean every business needs a long list of statuses. It means the workflow should be specific enough to show what the job is waiting on and who is expected to move it forward.
The key is that each stage should mean something operationally real.
Define dependencies so teams cannot start work that is not actually ready
One of the biggest causes of delay in multi-team jobs is false readiness.
A team gets scheduled because someone thinks the previous step is done. Then they arrive and discover the site is not ready, required approvals are missing, materials have not been delivered, or documentation is incomplete.
That wastes labour, creates frustration and often damages trust between office staff, field staff and subcontractors.
A better workflow uses dependency rules.
A dependency rule defines what must be true before the next stage can begin. In other words, it answers: what are the prerequisites for this team to do useful work?
Examples might include:
- team B cannot be booked until team A has marked its work complete and uploaded required photos
- the subcontractor cannot be dispatched until materials are confirmed on site
- final inspection cannot be scheduled until all defects from the previous stage are resolved
- invoicing cannot begin until all chargeable extras are reviewed and approved
- job close-out cannot occur until the final completion document is signed
These checks do not need to be complicated. But they do need to exist.
If the workflow allows the next team to start before prerequisites are met, the system is not controlling sequence. It is only recording activity after the fact.
Handover standards matter as much as the work itself
In multi-team jobs, one team rarely just finishes and walks away. They are usually handing over to someone else.
That means the handover is part of the work.
This is where many businesses run into the same pattern: the physical work may be done, but the information needed for the next stage is missing. The next crew then has to chase photos, confirm measurements, ask what happened on site, or ring the previous person for clarification.
That is not a small admin issue. It slows the whole delivery chain.
Each handover should have a minimum data requirement. In practical terms, that means defining what information must travel with the job before it can move to the next stage.
Depending on the type of work, that might include:
- completion notes
- site photos
- marked-up plans
- material usage
- defect notes
- safety documentation
- test results
- access instructions
- customer sign-off
- confirmation of what remains outstanding
- notes about variations or chargeable extras
Without this, the next team is working from assumptions.
A good workflow does not just say stage complete. It says stage complete with required handover information captured.
Make ownership of the next action visible
A job can be delayed even when everybody is technically doing their own work.
Why? Because once one stage ends, the next action is not clearly owned.
For example:
- the field team thinks the office will review and book the next trade
- the office thinks the site supervisor is still waiting on something
- the subcontractor thinks they are waiting for a purchase order
- the project manager assumes the system will flag anything outstanding
Meanwhile, the job sits still.
This is one of the most common workflow failures in operations-heavy businesses. The work does not stop because of a major problem. It stops because ownership between stages is vague.
Every stage should have an obvious answer to these questions:
- Who owns the job at this point?
- What exactly are they responsible for doing next?
- What event tells them the job is ready for that action?
- What happens if they do not act?
That ownership might sit with:
- a scheduler
- a project coordinator
- a site supervisor
- a service manager
- an internal crew leader
- a subcontractor coordinator
The important part is not the title. It is that the system makes next responsibility visible instead of leaving it implied.
Internal teams and subcontractors do not need identical visibility
Another common mistake is assuming every participant needs the same view of the workflow.
They usually do not.
Internal teams may need broad visibility across the entire job, including status history, dependencies, notes, exceptions and commercial context. Subcontractors often only need the information required to perform their allocated stage properly.
Trying to show everyone everything can create clutter and confusion. Showing too little creates risk.
A better approach is to define visibility by role.
For internal staff, useful visibility often includes:
- full job stage history
- current owner
- blockers or missing prerequisites
- documents and photos from prior stages
- upcoming dependencies
- outstanding approvals or decisions
For subcontractors, useful visibility may be narrower:
- their assigned task or stage
- the site details they need
- readiness confirmation
- required documents
- due dates
- how to submit completion information
- what conditions define their work as complete
This is not just a permissions issue. It is an operating model issue. Different participants need different levels of context to do their part without creating noise or ambiguity.
Prevent premature completion at both stage level and job level
A multi-team workflow needs two separate ideas of completion:
- stage completion
- overall job completion
If those are not clearly separated, jobs get closed too early.
A common failure looks like this: one crew finishes its part, marks the job complete, and everyone downstream loses visibility because the system now treats the entire job as finished. In reality, the next trade still needs to attend, final inspection is pending, or defects remain unresolved.
To prevent this, the workflow should distinguish between:
- a team completing its assigned work package
- the job reaching the final close-out criteria
That means stage completion should only progress the job to the next appropriate state. It should not automatically close the whole job unless defined final conditions are met.
Final completion usually needs stricter rules, such as:
- all stages completed
- no outstanding defects
- all required documentation received
- all variations reviewed
- final customer requirements satisfied
- commercial close-out ready
This is especially important where multiple contractors or crews are involved, because each party naturally focuses on its own scope. The workflow needs to protect the business from confusing local completion with total completion.
Design for exceptions, not just the ideal path
Most workflow diagrams look clean because they show the normal path.
Real jobs do not.
A team might attend and find access unavailable. A subcontractor may identify extra work. A quality check might fail. Materials may be delayed. A customer may change the timing. Weather may pause the next stage.
If the workflow only works when everything goes to plan, staff will immediately start managing exceptions outside the system. That is when visibility disappears again.
For multi-team jobs, common exception states might include:
- on hold awaiting customer
- waiting on materials
- rework required
- waiting on approval
- access issue
- variation under review
- subcontractor unavailable
These are not just descriptive labels. They should signal:
- why the job cannot move
- who owns resolution
- what event returns it to active flow
A useful workflow makes stalled work visible in a structured way. That is far better than leaving the job buried in someone’s notes or inbox.
What a practical multi-team workflow looks like
A workable design usually includes a few key elements.
1. A parent job with controlled stage progression
The job remains one overall record, but progress is tracked through defined stages rather than one generic status.
This preserves a whole-of-job view while still reflecting the true delivery sequence.
2. Entry and exit criteria for each stage
Each stage should have:
- prerequisites to start
- required actions within the stage
- completion requirements before handover
This stops teams from moving work forward on assumption alone.
3. Clear ownership at every point
At any given moment, someone should be accountable for the next movement of the job.
That ownership may change throughout the job, but it should never be unclear.
4. Required handover information
The workflow should define what must be captured before the next team can proceed.
If photos, notes or approvals matter, they should be part of the stage completion standard, not an optional extra.
5. Separate status for blocked or exception scenarios
When a job cannot progress, that should be visible in a structured way rather than hidden inside free-text notes.
6. Controlled final close-out
The whole job should only move to completed when all delivery, documentation and close-out requirements are actually met.
A simple example
Imagine a job involving three parties:
- an internal prep crew
- a specialist subcontractor
- an internal QA team
A weak workflow might look like this:
- booked
- in progress
- complete
That setup tells you almost nothing.
A stronger workflow might look more like this:
- ready for prep crew
- prep crew on site
- prep complete, awaiting review
- ready for subcontractor
- subcontractor booked
- subcontractor complete, documentation pending
- ready for QA
- QA passed
- defects to rectify
- ready for close-out
- completed
Now the operation can answer useful questions immediately:
- Is the subcontractor actually ready to attend?
- Has the prep crew supplied the information needed?
- Is the job waiting on documents rather than physical work?
- Has QA happened yet?
- Are there defects holding completion?
- Who owns the next step?
That is the difference between recording that work exists and actually managing flow.
Where automation helps, and where it does not
Once the workflow is properly designed, automation can help reduce the manual chasing around it.
For example, a system might:
- notify the next owner when a stage is completed
- stop a stage being marked complete until required fields are filled
- flag jobs stuck too long in a waiting state
- trigger subcontractor instructions once prerequisites are confirmed
- prompt QA booking when the previous stage passes review
Those are useful improvements because they reinforce a clear process.
But automation cannot fix a workflow that has not defined:
- the real stages
- the dependencies
- the handover standard
- the owner of the next action
- the exception path
If those decisions are missing, automation just moves confusion faster.
What good looks like operationally
A well-designed multi-team workflow does not eliminate every delay. Real-world delivery still has constraints.
What it does do is make the reason for delay visible and manageable.
Good looks like this:
- each stage reflects a real operational handover or milestone
- nobody can reasonably assume the next team is ready without evidence
- required job information follows the work
- the next owner is obvious
- blocked jobs are visible as blocked, not hidden as in progress
- internal teams and subcontractors see the information they actually need
- one crew finishing its part does not accidentally close the whole job
- managers can see where jobs are waiting and why
That is usually where the biggest improvement comes from. Not from adding more software, but from designing a workflow that matches how the work is really delivered.
If your jobs regularly pass between crews, trades or subcontractors, it is often worth mapping the actual delivery stages before making changes to status fields or automation. Where the process spans multiple systems, teams and exceptions, 5M Consulting can help design a workflow that gives each handover clear rules, clear ownership and far less room for work to quietly stall.