Lead time

The product feature lead time offers more advanced options compared to the standard prebooking functionality.

🌐 Translations

“Prebooking” is translated to German as Vorbuchung or Vorausbuchung, whereas “lead time” corresponds to Vorlauf or Vorlaufzeit.

The standard prebooking functionality is a product-wide setting available for every product. It is defined by a single product-wide parameter, the minimum threshold for prebooking (default: 3 minutes). Any ride request is triaged against this threshold and marked as either a “prebooked” ride request or an “ad-hoc” ride request. A request whose pickup time is further out than this threshold counts as a prebooking; a request whose pickup time is closer than the threshold is an ad-hoc request.

  • Prebooking can be toggled globally (on/off) for the product.
  • Additionally, prebooking/ad-hoc booking can be enabled/disabled for individual vehicles.
  • Prebooking is always calculated based on the request time, that is, the difference between the request moment and the requested rides time.

To address diverse operational needs without overcomplicating prebooking, the dedicated feature lead time is available.

Scope and limitations

Lead times per vehicle planning

Instead of one global product-wide setting, it is possible to define specific lead times per vehicle planning (and also per matching configuration to cover groups of vehicle plannings). This is a fundamental breakthrough as a static fact like prebooking can be checked during ride create. If the criteria is not met, the ride is not even created. The lead time feature however is evaluated per vehicle planning dynamically and is therefore properly integrated into the ride inquiry and into the matching process.

Flexible calculation modes

There are multiple ways to define lead time. The feature uses an adapter-based architecture: the algorithm that determines the lead time is encapsulated and selectable through a dropdown. ioki Platform provides default calculation modes, and tenant-specific custom adapters can be added when needed.

The default calculation modes are:

  • Requested time. Enforce a minimum notice between the booking moment and the requested pickup time. The lead time is measured back from the requested ride time.
  • Calculated pickup time. Enforce a minimum notice between the booking moment and the actual matched pickup time. The lead time is measured back from the pickup time produced by matching, which can differ from the requested time once the ride is routed onto a vehicle. Before a ride is matched, the requested time is used as a stand-in, so early checks do not reject rides that may still work out once routed.
  • Shift start. Enforce a minimum notice between the booking moment and the start of the shift. The lead time is measured back from the start of the vehicle planning.

Adapter-based lead time logic

Lead time is implemented through configurable adapter logic, not a single parameterized algorithm. Each adapter is selected per vehicle planning, so different plannings can use different calculation modes. When an operation needs rules that go beyond the default modes, a custom adapter can be added.

Vehicle plannings support custom tags for rule mapping

Real-world line-based services often use schedule annotations, such as runs labeled “a1” or “a2”, with footnotes like “a1: book one day earlier” or “a2: book 2 hours in advance.” ioki Platform supports this pattern with the product feature custom tags for task lists. Lead time adapters can use these tags to determine the required lead time.

Technical details

Lead time is evaluated per vehicle planning but the settings are typically stored on the matching configuration rather than directly on each vehicle planning. In practice, most operators set lead times once per product or a few times on the matching configuration, which is shared by multiple vehicle plannings. If needed, singular vehicle plannings can then override these settings individually.

Inheritance is three-tiered by default:

  • A vehicle planning’s lead time strategy defaults to Inherit from Matching Configuration (use the lead time settings defined on the matching configuration).
  • A matching configuration’s lead time strategy defaults to Inherit from Product (use the lead time settings defined on the product).
  • A product’s lead time strategy defaults to Off, which enforces no lead time. A product cannot inherit, because it is the root of the resolution chain.

Each calculation mode also carries a relative lead time value, which sets how much notice is required. The default relative lead time is 30 minutes.

Activate this feature

Roles: Super Admin

Enable prebooking before enabling and configuring lead times. Lead times only make sense when a passenger can first prebook a ride.

  1. Navigate to the management settings of the product.
  2. Within the Product features section, select the checkbox Lead time.
  3. Select Save.

Configure this feature

This feature can be configured within the section Lead time settings in the tenant settings of a product.

After feature activation, Product Admins can configure lead times per vehicle planning or per matching configuration when creating or editing them.