Taxi Dispatch Tablet — Fleet Scheduling & Order Assignment Case Study

1. The Operation Before Deployment

The operator runs a mixed fleet of 180 vehicles across a metropolitan area and the surrounding suburbs. Drivers are independent contractors who lease the vehicle and pay a daily fee to the operator. The operator provides the dispatch service and takes a commission on each assigned order. Some drivers also accept orders from a third-party ride-hailing platform through a personal phone.

The dispatch center operates from a single office with four dispatchers on rotating shifts. Orders arrive by phone call and, increasingly, through a mobile app used by regular customers. The dispatcher assigns each order to a driver based on proximity and availability. The assignment is communicated by radio.

Radio dispatch has three structural limitations in a fleet of this size. The radio channel is a single shared medium — only one conversation can take place at a time. The dispatcher cannot see where vehicles are located without asking. And the paper log records the assignment after the fact, not at the moment the order is accepted. Each of these limitations becomes visible when call volume increases.

2. Where Radio Dispatch Failed

The most visible failure was channel congestion during peak hours. When three or four orders arrived within a few minutes, the dispatcher could only handle one radio conversation at a time. The other orders were queued verbally — the dispatcher remembered them and assigned them sequentially. Under sustained peak load, this queue exceeded the dispatcher's ability to track it accurately. Orders were assigned late, assigned to the wrong zone, or dropped entirely.

The second failure was dispatching accuracy. Because the dispatcher could not see vehicle positions on a map, assignments were made based on the driver's last reported location or their assigned zone. A driver who had just completed a drop-off in a neighboring zone might be the closest vehicle to a new pickup, but the dispatcher had no way to know this without a radio call. The result was dispatching inefficiency — vehicles sent from further away than necessary, longer pickup times, and customer complaints about arrival time.

The third failure was driver experience. Radio dispatch required the driver to be listening to the radio at all times. A driver who was helping a passenger with luggage, or who had stepped out of the vehicle, might miss an assignment. The paper log at the office recorded what was assigned, but not what was actually accepted. Disputes over missed orders were common, and the operator had no reliable record to resolve them.

3. The Tablet-Based System

The operator evaluated several options before selecting a tablet-based system. A smartphone app was considered first — it would have been the simplest deployment. The problem was screen size. The driver needs to see the pickup address, the customer name, the destination, and the route preview at a glance, while the vehicle is in traffic. A 5-inch phone screen requires the driver to focus on the device for several seconds. A larger screen can be read in a fraction of that time.

The deployed configuration per vehicle:

The tablet is not a handheld device. It stays in the dock during the shift. The driver interacts with it through touch and voice — the voice announcement feature reads new orders aloud so the driver does not need to look away from the road when an assignment arrives. The GNSS hardware selection guide covers the positioning architecture for urban fleets.

4. Real-Time Positioning & Dispatch Logic

The tablet reports its position to the dispatch center over the 4G network. The reporting interval is configurable — the operator set it to 10 seconds while the vehicle is moving and 60 seconds when stationary. This balances position accuracy against data consumption. The dispatch center displays every vehicle on a map, updated in real time.

When a new order arrives, the dispatch logic identifies the nearest available vehicle by straight-line distance and assigns the order. The dispatcher sees the assignment on the map and can override it if the driver is known to be on a break or otherwise unavailable. The driver receives the order on the tablet — not by radio.

The positioning accuracy matters more in the urban core than in the suburbs. Tall buildings reflect satellite signals before they reach the antenna, causing the position to shift by tens of metres. In a taxi application, a 30-metre position error places the vehicle on the wrong side of an intersection or the wrong block. The operator selected tablets with dual-band GNSS receivers for the urban vehicles in the fleet — the L1+L5 architecture reduces multipath error to the metre level, which is sufficient for accurate dispatching. The GPS tracking hardware guide covers the receiver architecture in more detail.

5. In-Cab Order Display & Acceptance

When an order is assigned, the tablet displays the pickup address, the customer name, and the destination. The screen layout is designed for quick reading — the pickup address appears in large text at the top, and the destination below it. A route preview shows the path to the pickup. The voice announcement reads the same information aloud through the tablet's speaker.

The driver accepts the order with a single touch. The tablet sends the acceptance back to the dispatch center, and the order status changes from "assigned" to "accepted." If the driver does not accept within 15 seconds, the order returns to the dispatch queue and is reassigned to the next nearest vehicle. This automatic timeout prevents orders from being held by a driver who has stepped out of the vehicle or is otherwise unavailable.

The driver can also reject an order with a single touch — for example, if the driver is about to end a shift and the pickup is in the opposite direction. Rejection is recorded in the system. If a driver rejects more than a configurable threshold of orders in a shift, the dispatch center is notified. This provides a data record for the disputes that had previously been resolved by argument.

6. Outcome After Deployment

The system was deployed across the fleet over a two-week period. The most visible change was the elimination of radio congestion. Orders are assigned by the dispatch logic and delivered to individual tablets — there is no shared channel to congest. The dispatcher's role shifted from manually assigning each order to monitoring the map and handling exceptions.

The second change was dispatch accuracy. The dispatch logic assigns orders based on actual vehicle positions rather than reported zones. The average pickup time reported by the system decreased after the deployment — vehicles arrive closer to the customer's location on the first assignment, and fewer reassignments are required.

The third change was driver accountability. Every order assignment, acceptance, and rejection is recorded on the server with a timestamp. Disputes that had previously been resolved by argument are now resolved by log review. The operator reports that driver behaviour has become more consistent — the data record changes how both parties engage with the dispatch process.

7. Frequently Asked Questions