Several providers, the same hotel, four different names for it. And a second product riding along inside the same flow.
Two problems in one interface
atBeds needed a booking engine, and its name is myHotels. The obvious problem is the one every multi-source hotel search has: the same property arrives from three bedbanks under three identifiers, with different room descriptions, different cancellation logic and prices that are only comparable once you already know what is included. Most booking engines answer that by not asking. They show one source and hide the rest.
The less obvious problem was scope. Midway through, the brief grew to include activity discovery through the Amadeus Activities API, so a guest booking a hotel could add things to do at the same destination in the same flow. That turns a room search into a trip search, and it changes what the interface has to hold at once.
What I led
Not a single-company build. Providers, technical partners and our own teams each owned a piece, and my job was the whole path rather than any one part.
The flow. Where search starts, at which point a price becomes binding, and what a failed provider call does to the rest of the screen. Multi-source search fails partially, almost never completely, and an interface that treats partial failure as total failure loses bookings it already had.
The data. Matching properties across bedbanks so a comparison is a comparison and not a list. Normalising what "included" means when four suppliers define it differently. And deciding how activity results relate to a hotel search rather than sitting next to it as an unrelated widget.
The interface. Map view and list view as two ways into the same inventory. A comparison that puts differences where the eye already is. And a path from "here is a hotel" to "here is something to do nearby" that does not feel like a second website bolted onto the first.
What made it hard
Not the integrations. The coordination. Every party had a working answer for their own piece, and none of those answers assumed the others existed. Leading that means holding a picture of the whole thing while each party optimises their part, and being the one who says no when a locally sensible decision breaks something two steps downstream.
Adding activities partway through was the clearest version of that. It would have been easy to ship as a tab: hotels here, activities over there, no relationship between them. The useful version is one where finding a hotel and finding something to do at the destination feel like the same task, because for the person booking, they are.