Chat with us, powered by LiveChat

Settings Get Support 24/7

Booking Allocation

The Pickup Orders Allocation screen lets you choose how orders are dispatched to your drivers.

Allocation Algorithm Options:

  • Send to All: Sends the pickup request to all nearby drivers at once. The first to accept gets the job.
  • Nearest Available: Sends the request only to the driver closest to the pickup point. Fast and efficient.
  • One By One: Sends the request to drivers one at a time, based on proximity or priority. If one rejects or doesn’t respond, it moves to the next.

Assignment Time (in seconds):

Right below the options, there’s a field to input how long a driver has to accept a request (e.g., 30 seconds). Once that time is up, it moves on to the next driver or drops the request, depending on the method selected.

Hit Save Button!

FAQ's

A Booking Allocation Algorithm determines how ride requests are assigned to drivers when a customer books a trip. It controls who receives the request first, based on logic defined by the dispatcher.

Dispatchers can configure the algorithm directly from the dispatcher dashboard under the Booking Allocation Settings section. It only takes a few clicks to choose and save the preferred method.

There are three allocation options available:

  • Send to All: Sends the booking to all available drivers within the geo-fence at the same time. 
  • Nearest Available: Sends the request first to the closest driver, then gradually to others if not accepted. 
  • One by One: Sends the request sequentially to drivers, starting from the nearest to farthest, one at a time.

With Send to All, any booking made on the platform will trigger a notification to all drivers in the vicinity. The first driver to accept gets the booking. This method ensures faster booking but can lead to competition among drivers.

Nearest Available sends the booking request only to the nearest driver first. If that driver doesn’t accept within a specific time window, it goes to the next closest driver, and so on. This ensures priority is given based on proximity.

In One by One, booking requests are sent individually in a sequence:

  1. First to the closest driver
  2. Then to the second-closest
  3. Then to the third, and so on

This reduces simultaneous notifications and prioritizes fairness and clarity.

  • Use Send to All if you want fastest assignment and can manage competition among drivers. 
  • Use Nearest Available to ensure the closest driver gets the chance first. 
  • Use One by One if you prefer a controlled, fair, and sequential distribution of bookings. 

You can experiment and switch between them anytime based on operational needs.

Yes. Dispatchers can change the booking allocation method at any time. Just choose the preferred mode and click Save—the change takes effect immediately.

It depends on the algorithm:

  • In Send to All, the request remains open until any driver accepts or it expires. 
  • In Nearest Available, it automatically moves to the next nearest driver. 
  • In One by One, it will sequentially move to the next driver after a timeout. 

Timeout duration can be configured by the system admin.

Yes. All three algorithms respect the geo-fenced zones, so only drivers within the defined area receive booking requests.

Yes:

  • Send to All: All drivers receive a notification at the same time. 
  • Nearest Available / One by One: Only one driver at a time gets the notification, depending on their proximity and response.

Yes. Each booking log shows which drivers were offered the booking, in what order, and who accepted. This helps in analyzing driver responsiveness and efficiency.

If no driver accepts, the booking will be marked as unassigned or expired. The dispatcher may choose to:

  • Reassign manually 
  • Notify more drivers 

Switch to a different algorithm temporarily

By default, the setting is global. However, if your platform supports advanced regional settings or time-based rules, you can create zone-specific algorithms. (This may require a custom configuration.)

No. The allocation logic is handled in the backend and is transparent to drivers. They only receive booking notifications based on the active logic.