A retailing platform for a global tour operator
A commerce spine that held through peak season, and grew.
- Client
- Voya Travel Group
- Industry
- Travel
- Year
- 2024
- Engagement
- 8-month engagement
- Mobile conversion
- +34%
- Booking latency
- 4.2s → 0.9s
- Peak traffic held
- 12× baseline
The challenge
Voya's peak season traffic runs twelve times its baseline. Mobile was where most of their new customers landed, and their mobile conversion rate had been stuck under 1.4% for two years.
The booking flow ran across three vendors (one for search, one for pricing, one for checkout) and none of them talked to each other cleanly. Supplier inventory refreshed every six hours, not in real time, so half the trips shown as available at the search step were unavailable at the pay step.
They had one shot to fix it before the next peak season. Miss the window and it was a lost year.
Our approach
We rebuilt the mobile app in React Native on top of a single GraphQL commerce layer, so search, price and checkout finally spoke the same language. Redis backed the dynamic offer engine so pricing decisions ran in-memory and personalised in real time.
The vendor tangle came out. We built direct supplier integrations where volume justified them, and consolidated the rest under a single API. Inventory now refreshes in seconds, not hours.
We shipped in twelve weekly increments; every Friday a new slice of the flow behind a feature flag. Voya's product team was in every review. By month six, the entire booking path was on the new platform.
The outcome
Mobile conversion is up 34% and holding. Peak season came and went without a single incident escalated past on-call. The platform cost per booking dropped 40% because we killed two of the three vendor middle-layers.
Voya's product team now ships pricing experiments on their own, no engineering ticket required, because the platform was built with them running it, not us.
The engagement ended in October. Voya's peak season started in November. Everything they'd built worked, and everything since has held.
What people ask about this engagement.
01How do you handle peak-season traffic without over-provisioning all year?
By load-testing against your real historic peak rather than a generic curve, then designing what degrades first when the ceiling is hit. Search can get slower before booking does; booking must not fail. Autoscaling covers the rest. The platform held twelve times baseline because that number came from the client's own worst week, not from a round figure.
02Why does booking latency matter this much?
Because in travel it converts directly into revenue. Inventory is held, priced and released in real time across several suppliers, and every second of latency is a window where availability changes underneath the traveller. Taking the booking path from 4.2 seconds to under one second was the single change with the clearest effect on conversion.
03How do you integrate suppliers that each behave differently?
With an anti-corruption layer, so supplier quirks stay at the edge instead of leaking into the booking domain. Each integration normalises into one internal model, and a supplier that is slow or down degrades its own results rather than the whole search. Adding a supplier then becomes a contained piece of work instead of a release-wide risk.
04Was this a rebuild or an incremental change?
Incremental, routed behind a facade. Traffic moved journey by journey, so at any point we could send a share of users back to the old path. A travel platform that trades daily cannot afford a date on which everything changes at once.
What we shipped it on.
- React Native
- GraphQL
- Node.js
- Redis
- GCP
Bring us the hard part.
A short conversation is usually enough to know if we are the right team. If we are not, we will tell you.