Settings for prebooking and ad hoc booking

Permissions: manage_products

Ad hoc booking explained
An ad hoc booking refers to a ride request where the requested time is not set far into the future. Technically, this happens in one of two ways:
No requested time is provided during ride creation.
A requested time is provided, but it is very close to “now.”
Once either of these applies, ioki Platform considers it an ad hoc booking.
Important: This does not mean the ride will be picked up immediately. It indicates only that the search was made for a ride starting now. The calculated pickup time may still be significantly later. In technical terms: Requested Origin Time ≠ Calculated Pickup Time
Even if “now” is requested, ioki Platform may calculate a pickup time several minutes into the future.
Ride creation is handled as follows:
If no time is specified, the request is treated as if the ride were requested for “now.”
Any requested time (whether explicitly set or defaulted to “now”) that is closer than the minimum threshold for prebooking (3 minutes by default) is classified as an ad hoc booking.
Key point: Ad hoc bookings and prebookings are mutually exclusive. You can have either one or the other.
Prebooking: the requested time is further into the future than the minimum threshold for prebooking.
Ad hoc booking: the requested time is omitted or within the minimum threshold for prebooking.
The distinction between ad hoc and prebooking is determined during ride creation, not during matching. As soon as the ride search is submitted, the request is classified as either ad hoc or prebooking.
The distinction between these two categories is technically insignificant. Matching does not use this distinction and operates independently of any timeline. The split exists mainly for business purposes, such as reporting, to segment ride requests into two separate buckets.

In the Settings for prebooking and ad hoc booking section of a product’s tenant settings, you can enable or disable prebooking and ad hoc booking, and set the thresholds that govern prebooking:

Prebooking. When selected, the product accepts prebooked rides (rides requested for a time further into the future than the minimum threshold for prebooking).
Ad hoc bookable product. When selected, the product accepts ad hoc rides (rides requested for now, or for a time within the minimum threshold for prebooking).

When Prebooking is enabled while Ad hoc bookable product is disabled, the Ride is prebooked option is locked and cannot be deselected in the Booking Wizard.

The three threshold settings below are measured in seconds and set as durations. Each threshold has a default value that applies until you change it.

Which setting takes precedence when ad hoc booking or prebooking is configured on the product, vehicle, and vehicle planning?
These settings do not strictly override each other; they apply at different levels:
Vehicle: Ad hoc bookable default (for example) only defines the default value when creating a vehicle planning. It does not make the vehicle itself ad hoc bookable.
Vehicle planning: Determines whether a specific shift is ad hoc bookable or prebookable.
Product: Acts as a global constraint. If ad hoc booking is disabled at the product level, ad hoc bookings are not possible, even if vehicle plannings are marked as ad hoc bookable.

Min threshold for prebooking

Specifies how far into the future the requested ride must be in order for prebooking to be possible. A requested time that is closer than this threshold is classified as an ad hoc booking instead. The default is 3 minutes. You can set any value from 0 up to 7 days, in 1-minute steps.

Min threshold for prebooking
With this threshold set to ten minutes, a ride requested more than ten minutes ahead is treated as a prebooking. A ride requested within ten minutes of now is not rejected, it is handled as an ad hoc booking instead.

Threshold for prebooking automation

This threshold is measured as the time between the moment a ride is booked and its requested pickup time. If a prebooked ride’s pickup lies further in the future than the threshold, ioki Platform automatically accepts the ride on the driver’s behalf, so the ride skips driver negotiation. If the pickup lies within the threshold, the ride is offered to the driver instead, and the driver-related settings apply. The default is 4 hours. You can set any value from 0 up to 1 month, in 15-minute steps.

What is the difference between prebooking automation and the “Driver client automatically accepts ride requests” setting?
Both accept a ride without a driver tapping Accept, but they act at different stages and in different places:
Prebooking automation (this setting) is handled by ioki Platform (server-side). If a prebooked ride’s pickup lies beyond the threshold, the ride is accepted on the driver’s behalf when it is booked. This does not depend on ioki Vehicle App being open.
“Driver client automatically accepts ride requests” is handled by the driver app (client-side). For prebooked rides within the threshold, and for ad hoc rides, the ride is offered to the connected driver as usual; if this driver-related setting is enabled, ioki Vehicle App accepts the offer automatically instead of the driver tapping Accept. It only works while the driver is on shift with the app connected.
In other words: beyond the threshold ioki Platform auto-accepts; within the threshold the driver-related settings apply, where the client can auto-accept. If neither applies, the driver accepts manually before the Waiting for driver acceptance until the system cancels time elapses.

Max threshold for prebooking

The maximum amount of time a prebooked ride can be in the future. For example, the passenger is only allowed to book seven days in advance. The default is 7 days. You can set any value from 0 up to 6 months, in 15-minute steps.

How are prebookings handled during the switch from summer time to winter time (DST change)?
When daylight saving time (DST) ends, for example on the night from Saturday 25th to Sunday 26th, 2025, the clocks are set back from 3:00 a.m. to 2:00 a.m., so the time between 2:00 and 3:00 a.m. occurs twice. If a passenger pre-books a ride at 2:40 a.m. during this period, it may be unclear whether this refers to the first 2:40 (summer time) or the second 2:40 (winter time). All timestamps are calculated and stored in UTC, which ensures that each point in time is unique and unambiguous. Times are displayed to users in local time for simplicity, and the display does not include DST information. In most cases, the intended time is clear from context, for example through hints such as “in 8 minutes” for ad hoc bookings. If there is still uncertainty, passengers should contact the operator for clarification.

The management setting Arrival based booking for this section is changed by Super Admins; see Settings for prebooking and ad hoc booking in the Management Area.