Leads that sit in a queue nobody is working
The lead was assigned. It was never worked. The queue looks like backlog instead of stalled demand.
What's the leak?
The lead was assigned. It was never worked. The queue looks like backlog instead of stalled demand.
What it looks like
A batch of leads is routed to a workstation on Monday. The assignee is out Tuesday and buried Wednesday. Nothing is lost and nothing is worked — the leads simply sit, and the queue depth reads as normal volume.
Why it happens
Assignment happens once, at intake, and is never re-evaluated. Nothing distinguishes a lead that was worked yesterday from one that has never been touched.
What it costs
Demand you already paid to acquire stays untouched while the queue depth suggests the team is busy. The delay, not the lead quality, decides the outcome.
How URBLD closes the leak
Every workstation queue tracks last activity per lead. Leads past the staleness threshold surface to a manager for reassignment instead of waiting on a reminder.
Leak diagnosis
- Observed symptom
- Leads sit in a workstation queue with no next action and no owner.
- Inferred root failure
- Assignment happens once at intake and is never re-evaluated when the assignee is unavailable or overloaded.
- Lifecycle stage
- Qualification
- Financial or capacity consequence
- Queue depth hides idle demand: the business is paying for leads that no one is currently working.
Measure it yourself
Age of the oldest unworked lead per queue, and the count of leads unassigned or untouched beyond a set threshold.
Practical diagnostic
Sort each queue by last activity date. Anything older than your target response window is stagnation, not backlog.
Recommended operating response
Set an explicit staleness threshold per queue, surface breaches to a manager, and reassign rather than reminding.
Deeper explanation: Routing and assignment rules
Related Features
Related Workflows
Other leaks worth checking
See how URBLD closes every leak
One connected workflow from the first lead to the final payment.