Case study · Travel & hospitality
Book a hotel in a few taps, plan the rest of the trip in the same place
Travel apps lose people between searching and booking. The work here was to shorten that path: fast search, a booking flow that fits on a phone, personalised suggestions, and help available at the point where travellers actually need it.
Engagement · Product development
A consumer travel product across three platforms.
- Industry
- Travel & hospitality
- Solution
- Hotel booking & trip planning
- Engagement model
- Product team
- Market stage
- Consumer product
- Client
- TUI Travel
- Scope
- Mobile & web app development
- Platform
- iOS · Android · Web
- Focus
- Search, booking, support
Outcomes
Where travel products lose people, and what we did about it
The gap between finding a hotel and paying for it is where bookings die. Every figure here is about closing it.
-
47%
More bookings completed
Nothing asked twice, no surprise at payment and support inside the flow — the three reasons travellers abandon a booking, removed.
Measured from booking started to booking paid
-
35%
Reduction in drop-off at checkout
Price and availability are confirmed before the traveller is asked for money, so the moment that used to break trust now builds it.
Measured at the payment step
-
60%
Growth in repeat bookings
A traveller whose trip details worked on the day of travel comes back. The day-of-travel experience is what sells the next booking.
Measured across returning travellers after launch
Context
The situation before the app
Why search, booking, planning and support needed to be one product rather than four.
The business
A travel business selling hotel stays and trips to consumers who research on a laptop, book on a phone, and travel with neither to hand.
The starting point
Search, booking, trip details and customer support each lived somewhere different. A traveller with a question had to leave what they were doing to ask it.
The trigger
Travellers abandon between search and payment: too many steps, details asked twice, prices that move between screens, and no way to ask a question without starting again.
What they wanted
One product where search, booking, trip planning and support live together, on a phone as comfortably as on a laptop, with recommendations reflecting what the traveller has actually looked at.
Constraints
Availability and price change while the user is deciding · dates, rooms and guests interact in ways that confuse people · a booking has to survive a dropped connection mid-payment · the same journey has to work on a phone and a laptop.
System
What it runs at today
The product as delivered across mobile and web.
-
4
Stages in the booking journey
Search, select, confirm, pay — with nothing repeated between them
-
1
Booking engine
Search, availability and rules on the server, shared by all three clients
-
24/7
Support inside the journey
Reachable with the booking context attached rather than on a separate page
-
0
Connection required for trip details
The day-of-travel view works offline
The engineering problem
Four problems between searching and travelling
Travel products fail between screens rather than on them. These four gaps shaped the build.
-
Price and availability move while the traveller decides
Someone searches, thinks about it, comes back and books. In between, the room went or the price changed. Discovering that after entering card details is the fastest way to lose a customer permanently.
What we did
Price and availability confirmed against the booking engine immediately before payment, with any change shown plainly and the traveller given the choice rather than a failure message.
-
Dates, rooms and guests confuse people in combination
Each field is simple alone. Together — two rooms, four guests, one of them a child, arriving late — they produce states travellers do not expect and cannot correct without starting again.
What we did
The whole party and stay handled as one coherent step with the implications shown as they are chosen, rather than as separate fields that only conflict at the end.
-
A booking must survive a dropped connection mid-payment
Mobile payment happens on trains and in airports. If the connection drops between charge and confirmation, the traveller does not know whether they have a booking, and neither does the support agent they call.
What we did
Payment and booking made idempotent with immediate unambiguous confirmation, so a retry resolves to the same booking rather than a second charge.
-
Support sits outside the product, so people leave to use it
A traveller with a question mid-booking has to open a contact page, explain who they are and what they were doing, and start the booking again afterwards. Most simply stop.
What we did
Support reachable inside the flow, carrying the booking context with it, so the traveller does not have to explain what they were in the middle of.
Architecture
How it fits together
Simplified — the shape of the system rather than every service in it.
-
Clients
- iOS app
- Android app
- Responsive web
- Offline trip details
Three front ends over the same booking journey, with the day-of-travel view held locally so it works without a connection.
-
Gateway
- Booking API
- Session & traveller state
- Idempotent payment
One API surface carrying the traveller's state through the journey, with payment endpoints safe against interruption and retry.
-
Services
- Search & availability
- Booking engine
- Recommendations
- Support routing
Search, availability and booking rules on the server so all three clients tell the traveller the same thing at the same moment.
-
Data & infrastructure
- Booking records
- Traveller history
- Notification delivery
Bookings and traveller history in one store, which is what allows recommendations drawn from real behaviour rather than guesses.
Everything that could differ between platforms — availability, pricing, booking rules — was put on the server. The apps decide how to show a thing, never what is true about it.
Solutions
From search to a booked trip
Each screen was measured against one thing: does it move the traveller closer to a confirmed booking, or does it give them a reason to stop?
-
Search and results
Fast search across destinations and dates, with results that stay readable on a phone and filters that narrow without hiding what is left.
-
Booking flow
Dates, rooms and guests handled in one coherent step, with price and availability confirmed before payment rather than after.
-
Personalised recommendations
Suggestions shaped by what the traveller has searched and viewed, presented as options rather than as a wall of promotions.
-
Trip planning
Bookings gathered into a trip, with the details a traveller needs on the day in one place and reachable offline.
-
In-app support
Help available inside the flow, carrying the booking context with it so the traveller does not have to explain what they were doing.
-
Payments and confirmation
Payment handled securely with immediate, unambiguous confirmation, and a booking record that survives a lost connection.
Key capabilities
What it does day to day
Six capabilities across the traveller's journey.
| Capability | Runs | Refresh | What it does |
|---|---|---|---|
| Search & results | Traveller | Real time | Search across destinations and dates, with filters that narrow without hiding what remains |
| Booking flow | Traveller | On submit | Dates, rooms and guests in one step, with price confirmed before payment |
| Recommendations | Automatic | Per session | Suggestions shaped by what the traveller has searched and viewed |
| Trip planning | Traveller | On booking | Bookings gathered into a trip, with day-of-travel details available offline |
| In-app support | Traveller | On demand | Help inside the flow, carrying the booking context with it |
| Payments | Automatic | Per transaction | Secure payment with immediate confirmation and a booking that survives interruption |
Integrations
How the moving parts plug in
Search, payment and support all reach the traveller through one booking layer rather than as separate products.
Traveller actions
- SearchDestination, dates, party
- BookingSelection and confirmation
- QuestionsAt any point in the journey
Booking layer
- Availability & pricingConfirmed server-side
- Traveller stateCarried, never re-asked
- Idempotent paymentSafe against interruption
Services & records
- Booking records
- Trip view
- Recommendations
- Support with context
Because support reads the same booking state the traveller is looking at, an agent starts the conversation already knowing where the person is stuck.
Security & data
What protects travellers and their payments
The product holds travel dates, addresses and payment activity — information that is sensitive both financially and personally.
-
Payment handling
Card details are handled by the payment provider; the product holds a reference and a confirmation, never a card number.
-
Booking integrity
Idempotent payment means an interrupted transaction resolves to one booking and one charge, never two of either.
-
Traveller privacy
Trip details and travel dates are visible to the traveller and to support acting on their behalf, not exposed in links or query strings.
-
Confirmed before charged
Price and availability are re-verified immediately before payment, so a traveller is never charged for something that is no longer available.
The brief
Travellers abandon a booking somewhere between search and payment
The gap between finding a hotel and paying for it is where travel products lose their customers. Too many steps, details asked twice, prices that change between screens, and no obvious way to ask a question without leaving the app.
The aim was a single product where search, booking, trip planning and support live together, on a phone as comfortably as on a laptop, with recommendations that reflect what the traveller has actually looked at.
- Search that returns useful results before the user gives up
- A booking flow short enough to finish on a phone
- Recommendations based on real behaviour, not guesses
- Support reachable without leaving the booking
What makes travel harder than it looks
- 01Availability and price change while the user is deciding
- 02Dates, rooms and guests interact in ways that confuse people
- 03Bookings have to survive a dropped connection mid-payment
- 04The same journey has to work on a phone and on a laptop
Process
Designing the journey before designing the screens
We mapped the traveller's path end to end first, because the failures in travel products are almost always between screens rather than on them.
-
Journey mapping
The whole path from first search to the day of travel, marking every point where a traveller currently has to repeat themselves or leave the app.
-
Interface design
Phone-first design for search and booking, then the wider layouts, keeping the sequence identical so the two never diverge.
-
Build across platforms
iOS, Android and web over shared booking logic, so availability, pricing and rules behave the same everywhere.
-
Payments and resilience
Payment integration with careful handling of interruptions, duplicates and confirmations — the failure modes that cost the most trust.
-
Launch and iteration
Refinement driven by where travellers actually stopped, rather than where we expected them to.
Technology
One booking engine, three front ends
Search, availability and booking rules live on the server so every platform tells the traveller the same thing.
Mobile
- iOS app
- Android app
- Offline trip details
- Push notifications
Web
- Responsive web app
- Shared design system
Booking services
- Search and availability
- Booking engine
- Recommendation service
Payments and support
- Payment processing
- Confirmation and receipts
- In-app support
Business impact
What changed for travellers
Three things that follow from putting the whole journey in one product.
-
Fewer abandoned bookings
Nothing asked twice and no surprise at payment removes the two most common reasons people stop halfway.
-
Details when they matter
The day-of-travel view works without a connection, which is exactly when a traveller has no signal and needs it most.
-
Questions answered in place
Support with the booking context attached means a traveller asks and continues, rather than asking and starting over.
The result
Search, book, plan and get help without leaving the product
Travellers search, book and keep their trip details in one product across iOS, Android and web, with recommendations drawn from what they have actually looked at.
Support sits inside the journey rather than on a separate contact page, which is where travel products usually send people away.
- One booking journey across three platforms
- Price and availability confirmed before payment
- Trip details available on the day, offline
- Support reachable with the booking context attached
What we would carry into another travel product
- 01Map the journey before designing any screen
- 02Confirm price and availability before asking for money
- 03Never ask a traveller for something they have already given
- 04Make the day-of-travel view work without a connection
Verified reviews
What clients say about our mobile app work
Verified reviews from clients of ours on similar work, published on Clutch. They are not from this project.
-
Mobile App Development
Web & Mobile App Development for a Software Company
Their communication skills and industry knowledge have left a strong impression on us.
Alec Wenzowski
President, Button Inc. Jan 2022 – Ongoing
-
Mobile App Development
Software & Mobile App Development
They were great people with great work ethic.
Henry Popp
Co-Founder, Codedge LLC Aug 2021 – Jan 2023
-
Mobile App Development
Mobile App Development for an IoT Company
The project manager does an excellent job, and the team is always available during the project.
Arjen Schoneveld
Co-Founder, Dexels BV Jun 2021 – Oct 2022
Free discovery call
Have an idea? Let's turn it into AI-powered software.
Book a free discovery call with our experts. Share your idea and we will help you shape the scope, timeline and budget, under NDA.
- Free consultation
- NDA before we talk
- Transparent estimate