Taxi Manual Dispatch When Drivers Decline: Timeouts, Order Pool and Recovery

Declines are not rare. A driver is mid-trip, low on fuel, or simply reading a destination they do not want. If your software only “broadcasts harder,” the rider still watches a spinner. The real product question is what happens in the next few minutes: who still sees the job, when it dies, and how a dispatcher gets a person into a car without inventing a second platform.

Ptaxi’s taxi dispatch software documents push spread from dispatch configuration, a short live window on the driver home screen, an order pool for older unmatched jobs, and auto-cancel when nobody takes the trip. Phone booking remains a documented recovery path when the app loop fails. Use the checklist below in a demo — including ours — and walk one Friday-night refuse-all scenario with your own dispatchers before you promise SLA language to a city partner.

Why drivers decline (and why software must expect it)

Drivers optimize their next hour, not your conversion chart. Short hops after a long empty cruise, destinations outside their company comfort zone, or a push that arrives while they are already committed will lose to silence more often than to a polite “no.”

What the taxi line already records for ops:

• Acceptance and rejection stats in performance reporting, so you can see patterns by driver and company.
• Company range rules: a driver can only take jobs where pickup or dropoff sits inside the affiliated company scope.
• Push logs on the order detail, so you can see whether the job was offered or never reached a phone.

If you punish every decline the same way, multi-homing drivers will leave the app open but not listening. Prefer clear rules, readable stats and a second discovery surface (the pool) over silent blacklists.

Push spread is not the same as a guarantee

On confirm, the taxi passenger flow starts a call and the system pushes by dispatch configuration, including a configurable spread of how the offer expands. The rider sees wait time while calling.

Spread buys coverage. It does not buy acceptance. A wide ring that still lands on offline or out-of-range drivers just burns the clock. Pair spread settings with:

• Enough online supply near the hotspot (heatmap helps ops see emptiness; it does not invent cars).
• Training so drivers know when a push is a real-time taxi job versus a phone-dispatch style job with a simpler on-trip flow.
• An expectation that some jobs will age into the pool instead of dying on the first ring.

For how single-trip assignment is framed more broadly, see how taxi dispatch software assigns orders when that piece is live in your reading list — then come back to the timeout math below.

The five- and ten-minute windows

Documented driver home behavior is blunt and useful:

1. Go-online home shows passenger jobs that were placed within about five minutes and still have no accept.
2. Order pool holds jobs that have waited more than five minutes without an accept.
3. Jobs that remain unmatched past about ten minutes auto-cancel.

Those cutovers are the spine of “manual” recovery for taxi in the documented app path. Before five minutes, the job is still a live offer surface. After five, other online drivers can hunt it in the pool. After ten, the rider is done unless you reopen the problem through another channel (new booking, phone desk).

Trade-offs operators feel immediately:

• Short cancel windows protect drivers from stale destinations; they punish slow fleets.
• Long windows keep riders hopeful; they strand people with a fake sense of progress.
• Pool visibility without clear ETA messaging in the passenger app creates “why am I still waiting?” tickets even when the design is working as coded.

Do not publish universal minute numbers as a brand promise. Verify the configured values in your tenant, then train both sides on the same story.

Order pool as secondary discovery

The pool is where declined and ignored jobs go to get a second chance — not a black box AI. Online drivers browse unmatched work that aged past the first window. That matters when the first push set was wrong (wrong side of town, wrong company scope) but another driver is willing.

What the pool is not:

• A promise that someone will grab the job before auto-cancel.
• A replacement for enough supply at peak.
• The same thing as ride-hailing Order Dispatch, where an admin can manually assign an unmatched order (and where long-distance carpool scheduled jobs may *require* dispatch assignment).

If your RFP says “manual reassignment to a named taxi driver from admin,” ask for that screen in the demo. Documented taxi recovery leans on pool grabs, cancel rules, push forensics and phone-created orders. Do not invent a taxi-only reassignment button because a competitor brochure showed one.

Phone desk and backend-created jobs

When the app loop fails, documented taxi channels still include phone booking: the rider calls customer service, the agent creates the order in the backend (phone captured, pickup and dropoff entered), and the job enters the same operational world as other taxi work. Separate phone-dispatch style flows can settle offline with a simpler on-trip path (no navigation theater) — train drivers so they do not apply the full meter-confirm ritual to the wrong job type.

That is “manual dispatch” in the fleet sense: a human decides the job should exist and gets it into the system when the rider will not wait for another silent push cycle. It is slower than a perfect accept, and it is honest.

What drivers see while they decide

Documented taxi driver app features matter here because acceptance is a UX problem as much as a policy problem:

• Order broadcast with origin, destination and distance cues for taxi jobs (phone-dispatch jobs may require listening to a voice message before accept).
• Listening checks for network, location permission and go-online state — a “decline” that was really a broken listen is an ops false positive.
• Clear trip stages after accept: to pickup, wait, to destination, bill confirm with online pay or cash (cash still takes the platform cut from the driver wallet).

If the wallet cannot cover the cut on cash, drivers start avoiding cash-heavy zones. That looks like “declines” in your report and is actually a settlement design problem — see taxi app commission models.

Admin tools that actually help on a dead offer

When nobody accepts, useful admin work is forensic and operational, not magical:

1. Order detail: push logs, trip data, complaint hooks — prove whether anyone was offered the job.
2. Cancel before bill confirm when the rider has already walked away and you need a clean end state.
3. Abnormal-order tools (misreport, penalty, reject, refund, fare adjust) when the fight starts after a messy partial accept.
4. Driver messaging / pushes to nudge supply toward a hotspot (not a substitute for pool design).
5. Live location of online cars so a phone agent can tell a rider the truth: empty sector versus stubborn sector.
6. Performance stats on accepts and rejects so coaching targets real behavior.

SOS remains passenger one-tap emergency / police dial with alarm records in admin — not a dispatch reassignment tool. Do not conflate safety dial with getting a car.

A drill you should run before go-live

Skip vanity conversion slides. Run one tabletop:

• Rider A books a short urban hop at shift change.
• Three nearby drivers ignore; one rejects after reading the destination.
• At minute six, a fourth driver takes it from the pool — or nobody does and the job auto-cancels at the documented timeout.
• Rider B calls the desk; an agent creates a phone order and a driver is coached on the job type.

Write down who talks to the rider at each minute, what the passenger app shows, and whether finance will see a cancel fee, nothing or a new paid job. If that script is fuzzy, your “manual dispatch” story is fuzzy.

Close

Unaccepted taxi jobs are a timeout and discovery problem first. Configure spread, teach the five- and ten-minute story, keep the order pool usable, and keep a phone-create path for humans who will not wait. If you need named-driver reassignment from admin as a daily muscle, say so in the RFP and verify the screen — do not assume it from pool rules alone.

Describe the refuse-all scenario you fear most (airport queue, late-night short hop, multi-company city) and we can map which parts are configuration on taxi dispatch software versus process. Contact us.