The connected service
One intention. Many things working together.
“Take me back to my hotel” is an intention. A workable ride needs a few more answers.
3 minute read
First, establish which place.
Consider an illustrative request from someone visiting an unfamiliar district. They want to return to their hotel, but the service does not yet know which hotel they mean. A helpful response would ask them to choose or confirm the property. Guessing could produce a confident answer to the wrong request.
Natural-language requests are part of the experience we want to explore. The practical starting point can be simpler: choose a destination in the rider app and review it. The useful outcome is a clear destination, whichever input method eventually gets us there.
Then, separate the destination from the pickup.
The hotel entrance may be the rider’s destination, while the designated pod stop is around the corner. Likewise, the place where someone makes a request may not be somewhere a pod can stop. The app would need to distinguish where the rider wants to arrive from where they need to meet their pod.
Before confirmation, the rider should be able to review both points. If reaching the pickup is unclear or unsuitable for them, they need a way to ask for help or cancel. A stop name on a screen is not enough if someone cannot work out where it is.
An available pod still needs an operating plan.
A request within the service area would need an available pod and a route the service can support. District operations would coordinate that assignment and handle exceptions. A pod being nearby would not, by itself, mean the ride was confirmed.
If no pod can be assigned, the rider needs a clear status rather than an impression that something is already on its way. We have not established wait-time promises; the first service needs an understandable way to communicate what can happen next.
A changed plan tests the connection.
Now imagine the rider chooses a different hotel after confirming. The service would need to check the new destination and explain whether the request can be changed. If the original assignment no longer works, the change should not silently leave the rider following old pickup instructions.
These examples describe intended behaviour, not a deployed booking flow. They reveal the work behind the simple request: clarify the place, agree the pickup, coordinate the ride, and keep the person informed when the plan changes. The rider should see the decisions that affect them without having to manage the service behind them.
Let’s talk about useful journeys and a focused first pilot.
Bring Loope to your district