Taxi Order Pool and Unaccepted Timeout: What Drivers See After Five Minutes

Most taxi fleets start with a clean story: passenger books, system pushes nearby drivers, someone accepts, trip starts. The story breaks on slow nights, thin sectors, and drivers who ignore the first push because the pickup is ugly. If your product only has “push again harder,” passengers stare at a spinner and ops invents a spreadsheet of abandoned jobs.

On Ptaxi’s taxi dispatch software, the driver go-online surface already encodes a second chance: jobs still open under about five minutes sit on the driver home, older open jobs move into an order pool, and jobs that sit too long auto-cancel. This piece stays inside the taxi feature docs — not a generic “marketplace liquidity” essay — so you can demo the same screens without inventing surge algorithms or fake acceptance SLAs.

Why push-only dispatch fails quietly

Push dispatch is efficient when density is high. The first ring of drivers hears the job; one accepts; everyone else stops hearing it. When density drops, the same design becomes a silent failure mode. Drivers mute the broadcast, finish a cash settle, or park just outside the useful ring. The passenger still sees “calling.” Ops still sees “open.” Nobody owns the middle.

Fleets that only measure first-push accept rate will miss the real ops question: what happens to a job that nobody took in the first few minutes? Do you keep spamming the same ring? Expand forever? Cancel and force a rebook? Or put the open job somewhere drivers who *are* hunting can claim it?

The taxi docs answer with a staged surface, not a slogan.

What the driver home actually lists

On the go-online home, the product shows passenger jobs that were placed within about five minutes and still have no driver acceptance. That is the hot list — recent demand that still feels fair to chase as a near-real-time push.

Two constraints sit next to that list:

• Drivers only see / can take jobs where pickup or dropoff sits inside the joined company range. Geography is not a soft suggestion.
• The home is for the fresh window. It is not a graveyard of every unpaid hope from the last half hour.

Train drivers on that distinction. If they treat the home like an infinite auction board, they will complain that “old jobs disappeared.” They did not disappear into a bug. They aged into the next surface.

How the order pool takes the next five minutes

When a passenger job has been open more than five minutes with no acceptance, it lands in the order pool: jobs older than that window that still have no driver. The pool is the recovery lane. Drivers who finished a trip, came back online, or are hunting between sectors can grab work that the first push missed.

Ops tradeoffs show up immediately:

• Pool too aggressive (short hot window): almost everything falls to the pool. Drivers learn to ignore first push and cherry-pick the pool. Passenger wait time on the first surface looks worse even when total accept time is fine.
• Pool too timid (long hot window with no pool behavior): drivers who missed the first ring never see a second chance. You get cancels that a nearby free driver could have saved.
• No clear cancel after the pool: stale jobs sit forever. Passengers lose trust. Heatmaps lie about demand that is already gone.

The documented auto-cancel rule closes that third hole: jobs without a driver for more than about ten minutes auto-cancel. Roughly: five minutes of “fresh home,” then pool eligibility, then cancel if still empty. Exact wall-clock behavior belongs in tenant QA; the feature list is the contract you demo.

Auto-cancel is a product feature, not a failure badge

Passenger-facing teams hate cancel language. Product people sometimes hide it. That is a mistake. An unaccepted job that never dies becomes:

• A complaint ticket (“I waited twenty minutes and nobody came”).
• A ghost pin on heat / demand views.
• A driver who grabs a dead job after the passenger already walked away.

Auto-cancel after the documented timeout resets the loop. The passenger can rebook with fresh location and time. Ops can measure true miss rate (canceled without accept) separately from completed trips. Finance is not arguing about phantom open orders.

Pair cancel policy with passenger messaging that says the request timed out — not that “no taxis exist in your city.” Tone matters; the timeout is operational truth.

Company range still bounds who can save the job

The home rule is explicit: a driver can only take jobs where at least one of pickup or dropoff sits in the company range for the company they joined. When you sell multi-company city setups, that line stops cross-company poaching and also stops heroic saves that would break franchise contracts.

Do not train pool pickup as “anyone online can grab anything.” If your commercial model is company-scoped, the pool is a second surface inside the same geography rules — not a citywide free-for-all. When demos skip this, partners later ask why a downtown driver cannot snatch a suburban pool job that never belonged to their company.

What this is not

Stay honest in sales calls:

• This is not a promise that every job accepts in under five minutes. The surfaces exist because some jobs will not.
• This is not a replacement for manual dispatch when you need a named driver on a VIP or phone-desk job. Admin-side manual assign is a different tool for a different failure mode.
• This is not WeChat / official-account / phone-desk channel design. Those passenger entry points exist on the taxi line in source docs for some markets; overseas product pages and this blog keep the focus on app dispatch surfaces and the driver home / pool / timeout chain.

Also do not invent map-vendor names, Stripe card flows, or tip prompts. Taxi settlement in the docs still centers meter / bill confirm with online or cash paths and wallet commission behavior — separate from the accept-timeout story.

How ops should configure and coach around the windows

Practical checklist before you go live in a new city:

1. Walk the five-minute home list with real drivers. Confirm they understand “fresh” vs “pool.” Record a screen video for onboarding.
2. Decide who watches cancel volume. If auto-cancel spikes in one sector every evening, that is a supply problem or a range / fence problem — not a reason to disable cancel.
3. Align phone-desk / admin-created jobs with the same expectations. A desk that promises “someone will take it” while the job sits past cancel needs a manual-dispatch playbook, not louder push.
4. Keep listening / go-online health checks visible. A driver who is “online” with broken location or muted broadcast will never save pool jobs. The taxi line documents listening checks and go-online / go-offline — use them in coaching, not only in FAQ pages.
5. Measure three rates, not one: first-window accept, pool accept, timeout cancel. One blended “accept %” hides whether the pool is doing real work.

Passenger wait UX and rebook behavior

From the passenger side, the calling state shows wait time while drivers are being reached. When the job ages into pool and then cancels, the clean path is a clear timeout and a one-tap rebook with the same addresses if still relevant. Forcing passengers to rebuild the trip from scratch after every miss trains them to call a competitor.

If your city still runs heavy phone intake alongside the app, train agents not to leave duplicate open jobs when the passenger already has an app request in the pool. Duplicate demand inflates cancel stats and confuses drivers who see two near-identical pickups.

Driver psychology on the pool

Drivers treat the pool like leftover pizza: sometimes great, sometimes cold. Reduce that stigma with facts:

• Pool jobs are often the same passengers who would have paid a first-ring driver — they just missed the first ring.
• Company-range filtering still applies, so pool quality is not random city junk.
• Auto-cancel means hesitation has a deadline. Grabbing a six-minute-old job can still beat empty cruising.

If you see drivers only living in the pool and ignoring home pushes, shorten coaching cycles: first-ring accept bonuses (configured in your commercial policy, not invented as undocumented product magic) or simply clearer broadcast content (pickup, dropoff, distance) so the first surface feels actionable. Taxi broadcast content for metered jobs includes origin, destination, and distance cues — use that clarity; do not bury it.

Where this sits next to other taxi tools

Order pool and timeout are acceptance-layer tools. They sit beside:

• Heatmaps for where demand clusters.
• Go-online / listening checks for whether the driver can actually hear work.
• Bill confirm and cash-vs-online settle for what happens after the trip.
• Manual dispatch when a human must place a specific car.

Do not sell the pool as a full replacement for any of those. Sell it as the documented bridge between “we pushed” and “we gave up.”

Closing for buyers evaluating dispatch software

If you are comparing taxi apps, ask vendors to show the driver home under five minutes, the order pool after five, and the auto-cancel after ~ten on a live or staged build — not a slide. Ask what happens to company-range rules inside the pool. Ask how cancels appear in reports.

Ptaxi’s taxi line documents that chain explicitly. That is the difference between a pretty push animation and an ops-ready accept path when the first ring stays quiet.