Hotel API voor OTA's: waar je op let bij het kiezen

Heb je een online reisbureau, dan bepaalt de hotel API achter je zoekvak meer dan de meeste mensen denken: welke prijzen je klanten zien, hoe snel ze die zien en of een boeking echt doorgaat. Aan de buitenkant lijkt een hotel boeken eenvoudig. Je zoekt, je klikt, je betaalt. Daarachter zitten verouderde systemen, data die niet op elkaar aansluit, time-outs en voortdurende updates.

Mrigendra (Boney) Mittal, medeoprichter en CRO van Zentrumhub, werkt sinds 2021 aan precies dat probleem voor OTA's. Zijn bedrijf zit tussen online reisbureaus en hotelleveranciers in en brengt hun API's samen in één stroom. Volgens hem is het lastige niet het koppelen zelf. Het lastige is dat de reiziger niets mag merken van alle verschillen.

Waarom een hotel API lastiger is dan hij lijkt

Elke leverancier spreekt volgens Mittal een net iets andere taal. De een stuurt prijzen in euro's, de ander in dollars. De een werkt de beschikbaarheid realtime bij, de ander in batches om de paar uur.

“Some APIs are very well documented where others feel like they were written in the nineties and never updated.”

Mrigendra (Boney) Mittal, 1:34

(Vertaald: “Sommige API's zijn heel goed gedocumenteerd, terwijl andere aanvoelen alsof ze in de jaren negentig zijn geschreven en nooit zijn bijgewerkt.”)

Als OTA koppel je niet alleen met die bronnen. Je moet er één schone ervaring voor je klant van maken, en in zijn ervaring groeit de complexiteit met elke nieuwe koppeling. Mislukt een boeking omdat één verbinding brak, dan ziet hij dat als meer dan gemiste omzet: het schaadt het vertrouwen. De reiziger maakt het niet uit welke leverancier niet op tijd antwoordde. Hij wil direct de goedkoopste en meest kloppende totaalprijs zien.

De fouten zijn vaak klein. In het begin, vertelt hij, braken sommige koppelingen zo'n honderd keer per week, en hij weet nog dat hij om drie uur 's nachts met zijn team problemen oploste. Eén keer verscheen een hotel op Bali niet meer in de resultaten. Er was geen foutmelding. De oorzaak bleek een verschil in tijdzone in de API van de leverancier.

“Look at minute details in every API because every supplier talks in a different language, different contract.”

Mrigendra (Boney) Mittal, 27:45

(Vertaald: “Kijk naar de kleinste details in elke API, want elke leverancier spreekt een andere taal en heeft een ander contract.”)

De les voor elk team dat aan hotelconnectiviteit werkt: behandel het als loodgieterswerk, waarbij één klein detail de hele ervaring kan verpesten.

Waarom snelheid de conversie bepaalt

Reizigers die een hotel zoeken, hebben meerdere tabbladen open, zegt Mittal. Ze vergelijken prijzen op Google en lezen beoordelingen op TripAdvisor. Laden jouw resultaten vier of vijf seconden trager dan die van een concurrent, dan is de klant al weg, en dat is gemiste omzet, geen technisch detail.

Het probleem is dat leveranciers heel verschillend reageren: de een in twee seconden, de ander in vijf, weer een ander in tien. Een goede hotel API vangt dat verschil op, zodat de reiziger meteen resultaten ziet. Zentrumhub mikt op zoekantwoorden binnen 500 milliseconden. Hij noemt een reisonderzoek van Google waaruit blijkt dat één seconde vertraging bij het laden van een pagina de conversie met 20% kan verlagen. In hotelboekingen, waar de marges dun zijn, is dat volgens hem het verschil tussen een succesvolle OTA en de rest. Ook teams voor revenue management in hotels letten scherp op zulke marges.

Minder doen, maar beter

Jarenlang mat de reisbranche innovatie af aan functies, zegt Mittal: meer dashboards, meer modules, meer koppelingen. Volgens hem levert dat vaak wrijving op. Agenten wisselen tussen vijf verschillende logins, operators zijn hun tijd kwijt aan handmatig afstemmen en reizigers krijgen te veel keuzes en te veel klikken.

“Travel tech does not need to do more. It needs to do less, but better.”

Mrigendra (Boney) Mittal, 13:51

(Vertaald: “Reistechnologie hoeft niet meer te doen. Ze moet minder doen, maar beter.”)

Zijn alternatief is technologie die bijna onzichtbaar wordt. In plaats van een dozijn stappen heeft de reiziger drie klikken nodig: het hotel kiezen, de kamer boeken, de betaling bevestigen. Passende alternatieve betaalmethoden maken die laatste stap soepeler. Hij wijst op Booking.com als vroege gebruiker van A/B-testen op grote schaal. Daar concludeerden ze dat relevante inhoud en relevante prijzen belangrijker zijn dan extra functies.

Hoe kies je een leverancier voor je hotel API?

Mittal begint bij een heldere rolverdeling. Een OTA moet geen techbedrijf willen zijn, en een techbedrijf geen OTA. Voor een nieuwe of middelgrote OTA die zijn B2B-techstack kiest, noemt hij deze criteria:

• Ken je rol. Richt je op de relatie met reizigers, zorgvuldig samengestelde ervaringen en het binnenhalen van boekingen.
• Eis transparantie. Reizigers geven geld uit aan hun droomvakantie, dus data, prijzen en koppelingen horen geen zwarte dozen te zijn.
• Denk aan schaal. Hier een leverancier erbij plakken en daar nog een, levert spaghetti op die een puinhoop wordt zodra je groeit.
• Zoek ervaring. Een leverancier die met tientallen klanten heeft gewerkt, kent de problemen die jij nog tegenkomt al.
• Begin klein. Start met vijf tot zeven leveranciers, leer welke steden en hotels mensen zoeken en breid dan het aanbod uit.
• Toets de techniek en de support. Vraag hoeveel verkeer het platform aankan en of er iemand helpt om twee of drie uur 's nachts.

Dat laatste punt weegt in B2B zwaarder dan veel mensen denken. Gaat er iets mis, dan belt de reiziger de agent en belt de agent jou, vaak vanuit een ander deel van de wereld. Hotels kennen dat ook: in het callcenter van een hotel worden boekingen gewonnen of verloren.

Bouwen of kopen: eerst lanceren, dan leren

Zelf een boekingsplatform bouwen kan een jaar of twee duren, zegt Mittal, en tegen die tijd is het gedrag van reizigers misschien al veranderd. Hij kiest liever voor kopen in plaats van bouwen: de technologie bestaat al en de OTA gaat snel live. Eén klant tekende op een vrijdag en ging op maandag live. Zonder maatwerk zijn drie dagen mogelijk; een week is de gewone belofte.

Hij vergelijkt het lanceren van een OTA met het voor het eerst koken van een gerecht. Je beoordeelt het niet zelf; je laat je klanten proeven en verbetert het daarna. Zolang je niet weet wat reizigers willen, weet je ook niet of je website goed is, dus wachten op perfectie kost je echte kansen.

Transparantie en AI in boekingstechnologie voor hotels

De meeste oprichters van een OTA zijn geen technici, merkt Mittal op. Gaat er iets stuk, dan willen ze geen jargon. Ze willen weten wat er misging, hoe je dat aantoont en hoe het wordt opgelost. Zijn antwoord is volledige openheid: partners krijgen toegang tot boekingslogs, brondata en antwoorden van leveranciers, zodat ze precies zien wat van welke leverancier kwam en in welk formaat.

Over AI is hij nuchter. De eerste stap is niet glimmende functies toevoegen, maar aanpassingsvermogen in het bedrijf inbouwen. Met een platform dat meer dan drie miljoen boekingen per jaar verwerkt, kan de data betere aanbevelingen opleveren: geen duizend hotels in Dubai, maar het juiste handjevol. Hij ziet AI de reisagent ondersteunen, niet vervangen: AI sorteert en beveelt aan, de agent voegt de menselijke kant toe.

Zijn beeld van de toekomst is technologie die het boeken van een kamer net zo eenvoudig maakt als eten bestellen: laat een reiziger vijf relevante hotels zien op basis van zijn reisgeschiedenis en laat hem kiezen en boeken. Je kunt het volledige gesprek bekijken of meer afleveringen ontdekken in de serie Travel Commerce Unfiltered.

Veelgestelde vragen

Wat is een hotel API?

Het is de koppeling waarmee een online reisbureau prijzen en beschikbaarheid bij hotelleveranciers ophaalt en boekingen terugstuurt. Elke leverancier gaat anders om met valuta, voorraadupdates en documentatie, dus die laag moet alles omzetten naar één consistente stroom, zodat de reiziger één schoon en kloppend zoekresultaat ziet.

Hoe snel moeten zoekresultaten voor hotels laden?

Het platform van Mittal mikt op antwoorden binnen 500 milliseconden. Volgens hem haakt een reiziger die meerdere tabbladen vergelijkt af als jouw resultaten vier of vijf seconden later verschijnen dan die van een concurrent. Hij noemt een reisonderzoek van Google waarin één seconde vertraging de conversie met 20% verlaagt. De boekingslaag moet trage leveranciers dus opvangen.

Moet een OTA zijn boekingstechnologie zelf bouwen of kopen?

Volgens Mittal moet een OTA zich richten op het verkopen van reizen en de technologie aan een specialist overlaten. Zelf een platform bouwen kan een jaar of twee duren, terwijl een kant-en-klaar platform binnen een week live kan, en in één geval binnen drie dagen. Vroeg lanceren laat echte boekingen zien wat reizigers willen.

Wat vraag je aan een leverancier van boekingstechnologie?

Vraag hoeveel verkeer het platform aankan, hoe het meegroeit en of er op elk uur ondersteuning is, want problemen ontstaan in de tijdzone van de reiziger, niet in die van jou. Vraag ook om transparantie: toegang tot boekingslogs, brondata en antwoorden van leveranciers, zodat je ziet wat van welke leverancier kwam en waarom een boeking mislukte.