How Taxi Dispatch Software Assigns Orders: Radius and Timeouts

Most buyers compare taxi dispatch software by looking at the passenger app. That is the wrong end of the product. The passenger app is a map, a button and a payment form, and every vendor's version looks roughly alike. What decides whether your drivers earn a living and your riders stop canceling is a handful of unglamorous rules inside the dispatch engine: who gets offered an order, for how long, and what happens when that driver says nothing.

This article walks through those rules the way an operator ends up having to configure them. The numbers are typical ranges from the ride-hailing industry, not measurements from any particular platform, and your city will push them up or down.

Start with the offer, not the match

"Dispatch" sounds like a single decision. In practice it is a loop. A rider requests a trip, the system builds a list of candidate drivers, offers the order to one of them (or several), waits, and gets back an accept, a reject or silence. Silence is the common case, and most of the design effort goes there.

Candidate selection starts with a search radius around the pickup point. In a dense city center 1 to 3 km is common. In a suburb or a smaller city you may need 5 km or more before a single car appears. A fixed radius is the first thing to break. At 2 a.m. downtown, three drivers inside 2 km is plenty. At 6 p.m. in the rain the same circle holds fifty cars and nearly all of them are already on a trip. Better setups widen the radius in steps, say 1 km, then 2, then 3, each time an offer round fails, rather than starting wide. Starting wide sends a driver on a twelve-minute empty drive just because he was technically eligible.

Straight-line distance is also a poor ranking signal. A car 600 meters away on the far side of a river, a rail line or a one-way system can be fifteen minutes from the pickup. Route-based ETA from your map provider is the number you actually want to rank on, but it costs a request per candidate. The usual compromise is to shortlist by straight-line distance and then ask for route ETA only for the top handful. That keeps both the answer and the map bill reasonable.

Push, grab, or both

There are two basic ways an order reaches a driver. In push dispatch the system picks one driver and sends the order to him alone, and he has a few seconds to accept. In grab mode, usually called order grabbing, the order appears for every eligible driver nearby and the first one to tap wins.

Push is better for riders. The nearest car is offered first, so pickups are shorter, and the operator keeps control of who gets what. It is worse for driver morale. Where drivers are independent and have two or three other apps open, a driver who gets three unwanted pushes in a row will go offline or stop looking at the phone. Grab mode feels like a marketplace to drivers, which they tend to like, but it rewards fast thumbs instead of proximity. Average pickup distance gets worse, and drivers learn to park next to hot spots and wait.

Most platforms that have been live for a while end up with a hybrid: push to the best one or two candidates with a short window, then open the order to a wider pool if nobody takes it. The Ptaxi driver app supports both smart dispatch and real-time order grabbing, along with per-driver settings for the order scope and the time periods a driver is willing to work. Those settings do more than they sound like. A driver who has told the system he only wants trips in his own district between 6 and 10 in the evening is a driver who stops rejecting everything else.

The timeout is a business decision

How long does a driver get to answer an offer? For push offers somewhere between 10 and 20 seconds is the usual range. Shorter and drivers who are reading a street sign miss orders. Longer and the rider stares at "finding your driver" while a phone buzzes in a cup holder. It also multiplies. Three rounds at 15 seconds means the rider has waited 45 seconds before the system gives up on the first batch.

What you do with silence matters more than the number itself. Treating a timeout as a rejection and quietly lowering that driver's priority is tempting, and we think it mostly backfires. The driver does not know he is being penalized and cannot fix it. Something more honest works better: show a clear counter in the driver app, and after a set number of consecutive misses, switch the driver to offline so that he is not being offered trips while asleep in the car. It protects riders and drivers at once.

Rejections need the same treatment. If one driver turns down eight orders in a row, either the order scope is wrong for him or he is cherry-picking short trips. Both are useful to know, and neither is visible unless the platform logs offers and responses per driver. That log is the single most valuable debugging tool in the whole system, and it is the first thing we would ask a vendor about.

Reserved trips are a different problem

A real-time request is about the next minute. A reserved trip is about tomorrow morning. If you dispatch a 7 a.m. airport run at 6:50 you will miss it, probably half the time.

Reserved orders are normally assigned well ahead of pickup. For city trips that might be 30 to 60 minutes before, and for airport runs earlier, with a reminder to the driver and a rule for what happens if he cancels late. The failure to design for is the driver who accepted at 9 p.m. and is not there at 6 a.m. Software cannot fix reliability, but it can make unreliability visible early enough to fix. A check-in step, where the driver confirms 30 minutes before pickup and the operator sees a red flag if he does not, costs almost nothing to build. A manual reassign button for the operator costs a little more and is worth every bit of it.

If you are planning an airport-heavy service, read our note on airport transfer and fleet operations, because most of the pain there is in scheduling and not in routing.

Using the heat map without fooling yourself

The order heat map in the driver app is easy to demo and easy to misuse. It shows where demand has been, so drivers can reposition. The trap is the herd effect: if every driver sees the same red patch and drives toward it, the patch is saturated within ten minutes and the neighboring area, which now has no cars, goes unserved. Operators handle this in a few ways. They smooth or delay the heat data, they show relative demand per available driver instead of raw order counts, or they accept some inefficiency in exchange for simplicity. There is no perfect answer, only a decision about how much to trust drivers to spread themselves out.

What to ask a vendor, or your own developers

Whether you are buying a platform or having one built, five questions separate real dispatch engines from demos:

• Can I change search radius steps and offer timeouts from the admin console, without a code change or a redeploy?
• Is every offer, accept, reject and timeout logged so I can reconstruct why a driver was or was not offered a trip?
• Can an operator reassign an order by hand, including a reserved one, and what does the driver see when that happens?
• What happens to orders in flight if the dispatch service restarts?
• Which parts are configuration and which need a custom change? A straight answer here, including "that one needs custom work", is a good sign.

The last question matters most if you plan to run on your own servers. When the source code is yours, a custom rule such as favoring drivers with a higher completion rate at certain hours is an engineering task, not a feature request in someone's backlog. You can read what Ptaxi covers on the taxi dispatch software page, and the full list of passenger, driver and admin functions is on the features page. If you would like to see the dispatch and driver app running before you decide, get in touch and we will arrange a demo.

A small test you can run before launch

Before you go live in a new city, run a dull test. Put five or six cars on the map (staff cars are fine), request fifteen or twenty trips from different corners, and write down three numbers: time from request to a driver accepting, time from acceptance to arrival, and how many requests needed a second round. If the first number is above about 30 seconds in a quiet test, something in your timeout or radius settings is wrong, and no amount of marketing will fix it later. The test costs an afternoon. Skipping it costs your first month of reviews.