This one’s locked.
This one isn’t public. Booking.com for Business App requires a passcode.
This one isn’t public. Booking.com for Business App requires a passcode.
The desktop product supported booking — but the experience stopped the moment travelers were on the move. I led the design of a new mobile touchpoint that extends the journey beyond booking.
Booking.com for Business handled booking well on desktop — then went silent for the entire trip and the expense chaos that followed. This case study covers how I framed that gap, shaped the concept, and defined what to build first under ambiguity.
Business travelers could book on desktop, but had no product in their pocket during the trip — and faced fragmented, manual expense workflows after it.
A lightweight mobile layer focused on one critical job: capturing and organizing expenses during the trip — powered by AI receipt automation.
Shipped as a beta to 20,000 business users in 3 months, introducing an entirely new in-trip behavior for the product line.
Two products, two realities: the leisure app was mature and loved, while the business product lived only on a desktop portal. For anyone mid-trip, B4B simply wasn't there.
Mapping the business trip end-to-end reframed the brief: this wasn't just a missing app. Booking was the comfort zone — everything the traveler actually does on the road, and the expense work that follows, had no product at all.
Search. Book.
Desktop booking worked well. This was the product's comfort zone.
Navigate. Track.
No product in the traveler's pocket. Trip details lived in email threads.
Reconcile. Report.
Receipts in camera rolls, spreadsheets, and reimbursement portals — all manual.
The biggest gap appeared after booking.
The easy read was "we need an app." Research pointed somewhere more specific — and more valuable.
The problem wasn't "no app."
The real issue was a broken post-booking workflow.
Each expense round-trip crossed five disconnected surfaces:
"I lost my invoice, so I cannot get reimbursed."
— Business traveler, user interview"I always need to collect receipts, take photos, and email them to my admin."
— Business traveler, user interviewRebuilding the entire desktop product would take 12+ months — mostly features travelers don't need mid-trip.
The highest-pain, highest-frequency moment. Where the product was absent and behavior already existed.
A scope we could ship fast, validate with real users, and carry lower partner risk.
A mobile layer — not a desktop mirror.
The MVP was narrowed to a single critical job: capturing and organizing expenses during the trip — not after it.
Architecture, build strategy, components, and flows were each treated as an explicit design decision with a rationale.
The leisure app shell was reused; the "Explore" tab was replaced with "Expenses" — putting the new job one tap from home.
| Fully native | Hybrid wrapper + native expense | |
|---|---|---|
| Experience | Consistent design end-to-end | Web wrapper for booking; native where interaction quality matters most |
| Time to ship | 6–12 months | ~3 months |
| Risk & learning | Higher upfront risk, slow feedback | Lower risk, faster iteration on the core hypothesis |
A single card had to communicate where each expense sits in its lifecycle. Tap a status to see the design intent:
Both flows were prototyped and compared on friction, cognitive load, and error recovery.
Trade-off: guarantees clean data early, but interrupts users mid-capture — high friction at the worst moment (standing at a counter, receipt in hand).
Snap a receipt — AI extracts the fields.
Confirm vendor, price, date, category.
Share the claimable report — PDF or CSV.
The shipped flows, recorded from the live build — capture, review, export.
Snap a receipt and the app auto-creates the expense — vendor, price, currency, transaction date, category, and city extracted automatically. The design principle: automate extraction, never automate accountability. Review stays a human act, and only reviewed expenses can enter a claimable report.
Take a photo, pick from the gallery, upload a file, or enter manually — capture meets users wherever the receipt is.
Fields are pre-filled from the scan and the expense lands in the list as "To be reviewed" — zero typing at the counter.
Users double-check AI output on their own schedule, then export a claimable report from reviewed expenses only.
I triaged everything testing surfaced into one question: does this block the core loop? Two issues did. Each shipped as a concrete fix in the same release — observed problem in, design decision out.
Users wanted the claimable report — it was the reason they'd adopt the app — yet consistently failed to find where to generate it.
Export promoted to a primary action directly on the expense list screen, so the feature's value is visible at the exact moment of need.
Users didn't understand why some expenses couldn't be exported, or what "reviewing" actually unlocked — the system had rules it never explained.
An explicit rule banner — "Only reviewed expenses can be included in your report" — plus persistent Reviewed status tags on every card.
Validated flows aren't a launch. I ran three tracks alongside the build — experience quality, distribution, and the new behavior story — so day one felt like a product, not a beta.
The wrapper view is where hybrid apps usually fall apart. We re-styled the shared web surfaces — starting with the home page — so the seam between native and web was nearly invisible.
Discoverability decides adoption: if travelers can't find the feature at the right moment, it doesn't exist. We shipped an in-product banner on the desktop portal and a GTM landing page with QR download.
The MVP's real promise was a behavior change: manage expenses while traveling instead of reconstructing them after. Every launch message led with that shift.
Book on the Booking.com for Business app and let our AI automatically turn your receipts into expense reports.
Launch messaging · in-product bannerNarrowing to one job was the highest-leverage decision of the project — more than any screen or component.
Users were already capturing receipts on mobile. We didn't have to invent a behavior — just meet them where it happened.
Hybrid bought us speed to validate; native expense capture bought us credibility. Technology choices served the learning goal.