How to Automatically Detect Jobs That Are Waiting on Another Team
Sales has finished their part.
Now operations needs to schedule the job.
Operations cannot schedule it because purchasing has not confirmed the equipment.
Purchasing thinks the job is still with sales.
Three teams are involved.
Nobody thinks the next action belongs to them.
The job sits.
This is one of the easiest ways for work to disappear inside a growing business.
The problem is not always that nobody is working.
Sometimes the problem is that nobody can clearly see the handoff.
Every Internal Handoff Creates a Risk
A workflow often moves through several teams.
For example:
Sales
↓
Purchasing
↓
Scheduling
↓
Technician
↓
Operations
↓
Accounts
Each handoff creates a moment where responsibility changes.
If that transition is unclear, jobs can stall between departments.
Sales may believe:
“We sent it to operations.”
Operations may believe:
“We are waiting for purchasing.”
Purchasing may not know they were supposed to do anything.
The job becomes everyone's problem and nobody's action.
Record Who the Job Is Waiting On
Instead of using a generic status such as:
Pending
capture the dependency directly.
For example:
Status: Waiting Internally
Waiting On Team: Purchasing
Required Action: Confirm equipment availability
Owner: Sarah
Due: Wednesday
Now there is no ambiguity.
Anyone opening the job can see exactly where the dependency sits.
Track When the Handoff Happened
The system should also know when responsibility changed.
For example:
Sent to Purchasing: Monday 9:42 AM
Now you can calculate:
Waiting on Purchasing: 2.4 days
That gives you a measurable way to identify stalled handoffs.
Without a timestamp, a job can sit between teams indefinitely while still looking active.
Set Expected Handoff Times
Different teams may need different amounts of time.
For example:
Sales to Operations
Expected handoff: same day
Operations to Purchasing
Expected response: 2 days
Purchasing to Scheduling
Expected response: 1 day
Technician to Accounts
Expected handoff: same day
These do not need to be perfect service-level agreements.
They simply give the system a baseline.
Once the expected time is exceeded, the job becomes an exception.
Flag Internal Dependencies That Run Late
For example:
Job J-8624
Waiting On: Purchasing
Action: Confirm equipment availability
Waiting: 4 days
Expected: 2 days
Status: Overdue Handoff
Now operations does not need to manually remember that someone was supposed to chase purchasing.
The system notices.
Notify the Team That Actually Needs to Act
When an internal dependency becomes overdue, the first reminder should normally go to the team responsible.
For example:
Job J-8624 has been waiting for equipment confirmation for 3 days.
Required Action: Confirm equipment availability
Scheduled Date: 29 September
That is far more useful than:
Job overdue.
The notification explains both the action and the consequence.
Escalate Without Removing Responsibility
If the delay continues, the job can become more visible.
For example:
1 day overdue
Notify owner.
3 days overdue
Notify team lead.
5 days overdue
Add to operations exception view.
The original owner should normally remain responsible.
Escalation should increase visibility, not create confusion about who now owns the work.
Create a Cross-Team Waiting View
Management could have one view showing:
Jobs Waiting on Internal Teams
For example:
J-8624 – Purchasing – 4 days
J-8630 – Scheduling – 2 days
J-8647 – Accounts – 3 days
J-8651 – Operations – 1 day
This makes internal bottlenecks much easier to see.
Instead of asking every department for an update, management can focus on the exceptions.
Measure Where Handoffs Break Down
Once internal dependencies are tracked, you can start measuring them.
For example:
84 overdue internal handoffs this quarter
32 – Purchasing
24 – Scheduling
17 – Operations
11 – Accounts
That does not automatically mean purchasing is performing poorly.
There may be another reason.
Perhaps they receive incomplete requests.
Perhaps approvals arrive too late.
Perhaps equipment information is difficult to find.
The data tells you where to investigate.
Measure Handoff Time Between Teams
You can also measure how long jobs normally spend between stages.
For example:
Sales → Operations: 6 hours
Operations → Purchasing: 1.8 days
Purchasing → Scheduling: 3.2 days
Completion → Accounts: 1.1 days
Now you can see where the workflow slows down.
That is much more useful than simply knowing the total job duration.
Automate Predictable Handoffs
Many internal transitions should not require someone to manually tell the next team.
For example:
When:
Quote = Approved
the system can automatically:
Assign Operations
and create:
Next Action: Prepare job for scheduling
When:
Equipment = Confirmed
the system can automatically:
Assign Scheduling
and create:
Next Action: Book installation date
When:
Job = Completed
the system can automatically:
Assign Accounts
once invoice requirements are satisfied.
The system becomes responsible for passing the work forward.
Start With the Handoff Everyone Complains About
Ask your team:
“Where do jobs usually get stuck between departments?”
You will probably hear something familiar.
Maybe sales says operations takes too long.
Maybe operations says purchasing is the bottleneck.
Maybe accounts says nobody tells them when jobs are finished.
Pick one handoff.
Define:
Who sends the job?
Who receives it?
What action needs to happen?
How quickly should it happen?
What should happen if it does not?
Then automate that transition.
At 5M Consulting, we help trade and service businesses build workflows where responsibility moves clearly from one team to the next.
Jobs should move between departments.
They should not disappear between them.