TripPlanner levert prijsinformatie – snel en flexibel

Op Schiphol, boven je hoofd en op de Randstedelijke treinstations zie je veel KLM-blauw. Maar wist je dat er zich ook achter de schermen van KLM een hele blauwe wereld afspeelt? In de reeks Mooi Werk! laten we de projecten en plekken zien waar het minder zichtbare KLM-werk zich afspeelt. Deze keer spreken we decision support consultant Wieberen. Over TripPlanner – het systeem achter onze ticketprijzen.

Vertel eens, wat houdt TripPlanner in?

‘TripPlanner is hét interne IT-systeem achter de prijstooling van KLM.com. Zoek je een vlucht van Amsterdam naar Barcelona? Dan is de prijsinformatie die je online ziet afkomstig van TripPlanner. Alle data van pricing, netwerk en stoelbeschikbaarheid komt hier samen en geneert prijsinformatie voor de klant.’

Welke impact heeft dit systeem op de KLM-operatie?

‘Door dit systeem zijn we veel sneller en flexibeler in het aanleveren van prijsinformatie dan voorheen. Wij leveren prijsinformatie aan een groot deel van onze online verkoopkanalen, zoals de Air-France- of KLM-website, NDC, metasearchpartijen als SkyScanner en Kayak, maar ook voor advertenties op bijvoorbeeld Google en campagnepagina’s. Dagelijks handelt ons systeem rond de 70/80 miljoen requests af. Hierdoor is het van groot belang dat de responsetijden van ons systeem goed zijn en de prijsberekening klopt!’

Welke technologie gebruiken jullie in je aanpak?

‘Onze applicaties zijn gemaakt met de programmeertalen C++/C# en draaien op Windows servers. We gebruiken MongoDB als cache voor het opslaan van een deel van de prijsinformatie; dit zorgt voor snellere responsetijden. Superbelangrijk voor ons! En Real-time messaging regelt de updates van de stoelbeschikbaarheid.’

Zijn er andere terreinen waarin deze tool ook bruikbaar is?

‘Data is key. Dus ook intern gebruiken afdelingen graag onze gegevens. Om prijsvergelijkingen te maken met de concurrentie bijvoorbeeld. Of we bepalen op basis van gegevens uit TripPlanner – samen met de afdeling Netwerk – welke partner vlucht een zogeheten ‘codeshare’-code krijgt. Zodat wij een zo goed mogelijke selectie van vluchten maken aan “de achterkant” en de klant een zo goed mogelijke (door)verbinding heeft. We merken ook dat we data vanuit de tooling nóg beter kunnen gebruiken, bijvoorbeeld door informatie uit andere search engines. Op welke routes zoekt een klant en zijn dat routes die wij toevallig dan niet in ons netwerk hebben?‘

Heeft deze oplossing geleid tot onbedoelde effecten?

‘In ieder geval wel tot het inzicht dat wij met ons systeem een grootverbruiker zijn op de servers. Door het enorm aantal requests per dag en de vele (batch) processen gebruiken we momenteel ruim 150 servers. Dat betekent nogal wat voor onze sustainability. Daarom onderzoeken we nu of we groene KPI’s kunnen opstellen voor onszelf, en bijvoorbeeld de applicatie deels naar de cloud kunnen brengen. Dat is dynamischer, flexibeler en duurzamer!’