Booking flow design
Concierge booking platform
Reducing declined taxi bookings in a concierge booking flow
Drivers were declining bookings, and the cause turned out to be addresses without house numbers. A short step that asks for the missing number only when it's needed means drivers receive addresses they can act on, and fares are estimated accurately.
- Role
- Senior UX Designer
- Year
- 2025
- Scope
- UX, form design, UI design, front-end build
At a glance
A concierge platform where most bookings are taxis, running in five languages across European markets, with more than 95% of bookings made on mobile.
- Team
- I led the design and built the front end, working with the studio's development team.
- Platform
- Mobile-first web, with the booking widget built into the homepage hero
The problem
The booking flow was already short: pickup, destination, now or later, and a price. But some bookings were never accepted by a driver, and the problem was showing up everywhere at once. Customers raised support tickets about bookings that went nowhere. Drivers reported jobs they couldn't act on. Our operations team flagged it, and the booking data confirmed a pattern of declined jobs.
All four signals pointed to the same cause: the addresses themselves. Our address autocomplete, built on OpenStreetMap, only suggests a full address when the passenger starts by typing a house number. Otherwise it suggests the street alone, and lets them choose it as a pickup or drop-off point. The booking looks complete to the passenger, but a driver receives an address they can't act on, so they decline it. A drop-off point that broad also makes the fare estimate less accurate.
The brief
Make sure every booking reaches a driver with an address they can use, and gets an accurate fare, without adding a single step for passengers whose address is already complete.
Constraints
- Mobile, and in a hurry. More than 95% of bookings are made on a phone, often by someone who needs a taxi soon.
- Incomplete address data. OpenStreetMap is detailed in places and patchy in others, and we couldn't change the source.
- Five languages. Every message had to work clearly across all of them.
- Drivers decide. A driver can decline any job, and they won't accept one they can't trust.
- No added friction. The flow had to stay as short as it already was for most passengers.
The work
- 01Pickup, located for you With the passenger's permission, pickup is set from their current location. If they decline, an OpenStreetMap autocomplete takes over.
- 02Destination The same autocomplete, with suggestions as they type.
- 03Missing number detected If the chosen address has no house number, a short step asks for it. If the address is complete, the passenger never sees this step.
- 04A clear price upfront AI estimates the fare from the route, distance and timing, so the passenger sees a realistic price before booking.
- 05Sent to drivers The booking goes out with a complete address, and a live status card shows its progress.
Why a conditional step
The obvious fix was a house number field for everyone. But that would slow down the majority to fix a problem affecting a minority. Instead, the step appears only when the chosen address is missing a number, which happens for roughly 10 to 25% of bookings. Everyone else books exactly as before, and the passengers who do see it are asked for one small detail at the moment it matters.
Other details
A "now or schedule" choice comes first, the booking widget sits in the homepage hero so booking starts immediately, and new customers get a short onboarding the first time they log in.
What changed
Declined or failed bookings fell by roughly a quarter to a half after the step launched. Fare estimates also improved, because every journey now starts and ends at a precise address. At least three in four passengers never see the extra step, so the flow stayed as fast as it was for the majority. And with complete addresses arriving, drivers could accept jobs with confidence.
Looking back
The clearest lesson was how much a small detail can matter. The problem looked like a driver issue, then a support issue, but it came down to a single missing number in the address data. Listening to all four signals together is what led us to the real cause.
Next, I'd look for a more complete address data source. The conditional step works around gaps in OpenStreetMap; better data would close many of those gaps at the source, so even fewer passengers would ever need to be asked.
More work
All work- UX, form design, service design, UI design, A/B testingTravel authorisation serviceUX, form design, service design, UI design, A/B testing
- Support designBooking assistance serviceConversation design, UX and UI designSupport design
- Product strategy, UX and UI design, front end, back end, integrations and AI workflowsRhea AgenticProduct strategy, UX and UI design, front end, back end, integrations and AI workflows

