Ride example
The following example illustrates ride logic for an ad hoc booked ride with a station-to-station matching mode. It also assumes that the product feature prohibit parallel rides is not active.
In the currently active matching configuration for this example, maximum time deviation to request is set to 1 hour, and allowed travel time in relation to direct travel time is set to 150%. In addition, assume that minimum tolerable timely detour and maximum tolerable timely detour are both less than 10 minutes.
1. From request to offer (from searching to ready)
It’s exactly 3 pm. The user Fynn, an adult passenger without accessibility-related passenger options, wants to book a ride from geopoint A to a station named Station B. He opens the Kompendiumshuttle app, enters his current position and destination, and sends the request.
This is the moment the ride is initiated internally.
The state of the ride is searching.
A direct routing calculation shows that if Fynn traveled directly from A to Station B by car, the journey would take 20 minutes.
With the matching parameters defined above, the ride, including Fynn’s walk to the pickup station, may take up to 30 minutes and must start between 3 pm and 4 pm.
Now, the matching algorithm checks all active Vehicle Plannings for the following options.
If no suitable vehicle planning is found during matching, the ride is cancelled and Fynn is informed that either no vehicle is available or the booking is outside the service times.
Assume that matching returns a winning solution within an active vehicle planning, with a pickup at 3:10 pm and a drop-off task at 3:28 pm. Since the matching mode is station-based, the pickup task is redirected from geopoint A to a nearby Station A. Fynn’s walk from A to Station A is calculated as 5 minutes.
Assume for this example that there are no current tasks in this vehicle planning, but the routing shows that the driver needs ten minutes to reach Station A.
The state of the ride is now set to ready and is reserved for Fynn.
In Control Center, time windows are displayed as follows:
[ minimum | currently planned | maximum ],
The same notation is used here for clarity.
At this point, the ride contains the following information:
- 1 passenger, adult
- Requested Points:
Geopoint A, with requested time 3pm,[ - | 3:00 | - ]
Station B - Calculated Points:
Pickup Station A, with time 3.10 pm,[ 3:10 | 3:10 | 3:10 ]
Dropoff Station B, with time window 3.35 pm - 3.40 pm,[ 3:28 | 3:28 | 3:35 ] - Negotiation Times:
Pickup Station A, time window: 3.10 - 3.15 pm,[ 3:10 | 3:10 | 3:15 ]
Dropoff Station B, time window: 3.25 - 3.40 pm,[ 3:28 | 3:28 | 3:35 ] - State: ready
2. Waiting for the acceptance of the passenger (from ready to passenger accepted)
This ride is now offered to Fynn, who can decide whether to accept it. This is done in the app and only within the time span specified in the passenger-related settings of the product. If he decides that he cannot wait ten minutes, he can cancel the ride, which sets the ride status to cancelled and ends the process.
For now, we assume that Fynn accepts directly. Then, the state switches to passenger accepted and the system now waits for the acceptance of the driver.
3. Waiting for the acceptance of the driver (from passenger accepted to driver accepted)
If the ride is not accepted automatically by the system (see automatic driver acceptance), the incoming tasks appear in ioki Vehicle App of the driver who is currently connected to the vehicle through the relevant vehicle occupation. The driver can then accept or reject the request.
If the driver rejects the ride, the status is set to cancelled, the process ends, and Fynn is informed.
In this example, the driver accepts the ride in time, and the ride status is therefore set to driver accepted. The driver then starts the ten-minute journey to Station A to pick up Fynn.
4. Waiting for the pickup task (from driver accepted to picked up)
On the way to Station A, the driver encounters a minor delay. A recalculation of the task list results in a delay of one minute. This updates the calculated points as follows:
- Calculated Points:
Pickup Station A, with time 3.10 pm,[ 3:11 | 3:11 | 3:11 ]
Dropoff Station B, with time window 3.35 pm - 3.40 pm,[ 3:29 | 3:29 | 3:35 ]
Because the delay is small enough that the pickup and drop-off tasks remain within the negotiated time windows, Fynn is not informed.
When both parties have arrived at Station A, Fynn identifies himself with his booking code and boards the vehicle. The driver then checks that the pickup task is completed.
The state of the ride is now picked up.
If Fynn violates the terms of service, the driver does not have to complete the pickup task and can cancel the ride with the reason Passenger violated ToS. In this case, the state is set to cancelled. This is only one possible driver-side cancellation reason. For more information, see Cancellation.
5. On the road (from picked up to dropped off)
Once Fynn is on board, only a few factors can still affect when he reaches his destination. One of them is an additional pooling event.
In this scenario, Attanaljide looks for a ride shortly after Fynn has boarded the vehicle. The closest station to her requested destination is also Station B. After checking all relevant constraints, Attanaljide is matched into the same vehicle as Fynn.
However, this means that the journey now includes a five-minute detour to pick up Attanaljide. Fynn receives a notification on his phone informing him about the additional pooling.
Note that the matching algorithm takes the detour into account before matching Attanaljide into the vehicle. Fynn is still expected to reach the drop-off point within his negotiated time window. Only the calculated drop-off changes:
- Calculated Points:
Pickup Station A, with time 3.10 pm,[ 3:11 | 3:11 | 3:11 ]
Dropoff Station B, with time window 3.35 pm - 3.40 pm,[ 3:34 | 3:34 | 3:35 ]
Fynn and Attanaljide then share the journey until they are dropped off at Station B.
If the ride continues without further issues and neither passenger violates the terms of service, the driver selects Passenger dropped off in ioki Vehicle App, which sets the state to dropped off.