Jobs sit in the unassigned queue until a customer calls to ask

A job that never reaches a technician is almost never a job that failed loudly. It is a job that entered a state nobody watches, and stayed there because nothing in that state has a clock attached. The unassigned queue is where those jobs live, and in most operations it is the only object on the board with no ageing, no owner and no alert.

That is why the customer finds out first. When the only detector for an undispatched job is a phone call from the person waiting for it, you have outsourced monitoring to the least forgiving auditor available — the same structural mistake as trusting a notification you never confirmed was delivered, described in customers say the on-my-way text never arrived.

Read the queue by its oldest job, not by its size

Queue size is the number everyone reports and it is close to useless. A queue holding 40 jobs created this morning is healthy; a queue holding 6 jobs, one of which arrived 11 days ago, is a complaint that has not been made yet. Age is the diagnostic, and it has to be sampled rather than glanced at.

1. Snapshot the queue twice daily, at 07:00 before the board is worked and at 16:00 after it should have been. One row per unassigned job: id, created timestamp, job type, priority tier, business unit, arrival channel.
2. Compute 4 numbers per slice, not one: count, oldest age in hours, the 90th percentile age, and the number already past its tier's limit.
3. Slice by priority tier first, then job type, then business unit. A blended figure hides the only case that matters — one obligation-driven job aged past its due date inside a pile of flexible ones.
4. Add arrival and drain counts for the window. A queue that grows by 12 and drains 12 is stable at whatever depth it has; one draining 9 is compounding, and the oldest-age line says when customers will notice.
5. Run it for 10 working days before changing anything. Two of those will be atypical, and a rule tuned on an atypical day is the rule everybody switches off in week three.

Nobody's name is on the queue

The most common cause is also the least technical. Every other object in a service business has an owner — the job has a technician, the invoice has a controller, the callback has whoever promised it — and the unassigned queue has a team. A team is not an owner. When 3 dispatchers can all see the queue and none of them is accountable for its oldest row, the queue is worked opportunistically, which means newest-first, which means the difficult jobs at the bottom are permanently deferred.

The difficult ones share a profile, which is why the same jobs rot: a licence only 2 technicians hold, a site with restricted access hours, a customer already rescheduled twice, a job nobody can price. Each takes 15 minutes of thought rather than 15 seconds of drag-and-drop, so each loses to whatever arrived at 08:40.

The fix is boring and it works: one named person per business unit owns the queue for the day, works it oldest-first before anything else, and hands over an explicit list of what they could not place. That list is the input to every other fix here.

Auto-assign ran, found nobody, and said nothing

Where automatic assignment exists, the failure is rarely a crash. It evaluates a constraint set, finds zero eligible technicians, and returns an empty result the system treats as a non-event. No error is logged and the queue absorbs the job silently. An empty result is information, and discarding it is the most expensive line of code in most dispatch integrations.

So instrument the empty case. Every run that assigns nobody should write a row naming which constraint eliminated the last candidate:

• No technician holds the required licence or certification, or the only one who does has it expiring before the scheduled date.
• Every eligible technician is already committed for the requested window, so the constraint is capacity rather than skill.
• The site falls outside every eligible technician's working geography, which is a service-area question wearing a dispatch costume.
• The job carries a customer-preferred technician who is unavailable, and the rule treated a preference as a hard constraint.
• Required parts are not on any eligible van, so the assignment engine correctly refused and incorrectly stayed quiet.

Those five reasons are the ranked backlog for whoever is improving dispatch, because they name which constraint actually binds. Showing a dispatcher a shortlist with the failing component visible, rather than a blank result, is the argument made in an assignment a dispatcher can argue with. Whether engine or dispatcher gets the final say is settled in auto-dispatch or dispatcher override; either answer still requires the engine to explain itself.

An assignment engine that finds no eligible technician has learned something. Discarding that result is how a constraint problem becomes a backlog nobody can explain.

The job exists in a status the board never draws

Dispatch boards render a subset of job statuses. Whatever platform you run — ServiceTitan, Jobber, Housecall Pro, Simpro or something in-house — somebody once chose which statuses appear in the unassigned view, and that choice is now years old and undocumented. Jobs created in any other status are not hidden by a bug. They are working exactly as configured, and configuration is invisible.

Three creation paths reliably produce jobs outside the rendered set. A won estimate converting to work in a needs-scheduling status of its own. A recurring agreement releasing visits into a future-dated status the day view filters out, which is how the tune-ups that were due never got booked. And a technician raising follow-up work from the field, which often lands in a status the office board was never told about.

The check takes an afternoon: count every job created in the last 30 days grouped by status, then compare that list against the statuses the unassigned view renders. Anything in the first list and not the second is a leak, and the count sizes it.

Parts holds and saved filters, hiding rows in plain sight

Two things make a job invisible while sitting in the queue you are looking at. The first is a job waiting on a part, parked in the same pile as jobs waiting on a decision. Those are different states with different clocks — one waits on a supplier, the other on a person — and merging them means aged parts jobs pad every count until nobody trusts the number. Giving that job its own state with a re-entry trigger is the argument of the job that should not be on the board yet.

The second is the saved filter. Multi-location operations set a default business unit per user, and a job booked by a central call centre into a unit nobody has open is technically in the queue and practically gone. It surfaces in no default view until someone runs an unfiltered report — a consequence of how the business unit is modelled, covered in the business unit as a data model decision.

An ageing limit per tier, and an escalation with a name on it

The prescription is a maximum age per priority tier, measured from job creation rather than from when somebody noticed, with a defined action at each breach. Tiers below are illustrative shapes rather than industry limits; set yours from your own promises.

The obligation-driven tier deserves care, because its clock is not yours. Work carrying a legally mandated deadline — a periodic device test, an inspection, a certification retest — ages against that external date, and an unassigned job in that tier is a compliance problem before it is a scheduling one. The evidence trail those jobs must produce is a separate discipline, set out in before a backflow test report leaves the truck.

Two rules make the escalation real. It goes to a person, not a role inbox, with a fallback name for leave. And it demands a disposition rather than an acknowledgement: placed, deferred with a date, or escalated further. An alert that can be dismissed will be, and a queue whose alerts are dismissed is the queue you started with.

Mechanically this is small — a scheduled unfiltered query, an ageing calculation, a rules table and a notification path — sitting alongside the assignment engine rather than inside it, which is the shape of work we describe under AI agents and automation. If you are commissioning it, the questions to ask first are in choosing an AI development partner. It belongs with dispatch, scheduling and route sequencing, inside our field service work.

• dispatch
• backlog
• queue design
• escalation