We bouwden een AI-aangedreven reisinterface vanaf nul. Geen chatbot. Geen widget. Geen GPT-wrapper met een smiley op een website geplakt. Een volledige conversationele interface met een eigen vector database, een eigen retrieval pipeline, een eigen geheugensysteem en real-time streaming over WebSockets. Niet om iets te vervangen. Om te testen of conversationele AI er echt klaar voor is om een betekenisvol kanaal voor reizen te zijn. Dit is wat we ontdekten, wat het kostte, en waarom we denken dat het meeste van wat er nu is ruis is.
Dit is een verhaal in twee delen. Dit eerste deel gaat over het waarom: welk probleem we oplossen, wat we leerden van eerdere mislukkingen, en waarom een plugin je hier nooit zal brengen. Deel 2 gaat dieper in op de architectuur: de RAG pipeline, het geheugensysteem, de UI/UX-beslissingen en de technische afwegingen die we maakten.
Wat probeer je eigenlijk op te lossen?
Dat is de vraag waar ik steeds op terugkom. Elke keer als een bedrijf zijn nieuwe “AI-powered” feature aankondigt. Elke keer als iemand me vraagt wat wij met AI doen. Elke keer als een leverancier weer een plugin komt pitchen.
Het is op dit moment de belangrijkste vraag in tech. En bijna niemand stelt hem.
In plaats daarvan werkt de hele industrie achterstevoren: men begint met “we moeten iets met AI doen” en gaat dan op zoek naar een plek om het neer te zetten. Bedrijven horen “AI” en horen “innovatie” en denken dat ze achterlopen als ze niet nú iets doen.
De druk om “iets met AI te doen” is luider geworden dan de vraag wat je eigenlijk wilt bereiken.
En wat gebeurt er dan? Bedrijven grijpen de meest zichtbare, meest verkoopbare toepassing die ze kunnen vinden: een chatbot. Op de website plakken. Een naam en een vriendelijk gezichtje geven. Verbinden met een kennisbank. Klaar. “Wij doen nu AI.”
Het probleem: de integratie is altijd beperkt. Sommigen koppelen aan een productdatabase. Sommigen halen live beschikbaarheid op. Maar als plugin is er een plafond aan hoe diep die integratie gaat. Hij werkt altijd met de data die hij krijgt, in het formaat dat de API levert, met de context die de leverancier voldoende vond. Het resultaat is een interactie die aan de oppervlakte conversationeel oogt, maar fundamenteel beperkt blijft in wat hij kan.
En omdat het een plugin is, kan het nooit volledig naadloos zijn. Het blijft altijd een aparte laag bovenop je website, geen onderdeel ervan. Een andere designtaal. Een ander interactiemodel. Een andere ervaring. De klant voelt dat, ook al kan hij het niet onder woorden brengen. Het is het verschil tussen een kamer die als geheel is ontworpen en een kamer waar iemand een kiosk in de hoek heeft gezet.
Een slimmere poortwachter is nog steeds een poortwachter. Je klanten wilden een deur.
We zijn zelf deze weg gegaan. In 2019 bouwden we de eerste versie van Joy op Flow.ai. Een intent-gebaseerde chatbot die natuurlijke taal begreep, reisvoorkeuren uit één zin kon halen en leads genereerde voor onze specialisten. Het werkte. Technisch gezien. Maar de klantbetrokkenheid was te laag om hem in leven te houden. Begin 2022 hebben we Joy uit dienst genomen.
De les was niet dat de technologie slecht was. De les was dat mensen hebben geleerd chatbots te wantrouwen. En terecht. Jarenlang hebben bedrijven chatbots gebruikt als barrière om contact te maken, ook toen ze het tegendeel beweerden. Klanten weten dat. Ze hebben het meegemaakt. Na drie foute antwoorden denk je niet “even opnieuw proberen.” Je denkt “hoe kom ik bij een echt mens?” Sommige mensen doen niet eens de moeite. Ze zien een chatbelletje met een gezichtje en hun eerste reactie is: weg ermee. Niet omdat ze ongeduldig zijn, maar omdat de ervaring hun heeft geleerd dat het tijdverspilling is.
Dat is geen technologieprobleem. Dat is een vertrouwensprobleem. En dat los je niet op door hetzelfde formaat slimmer te maken.
Daar komt bij dat de interface van een chatbot-plugin simpelweg beperkend is. Een klein venster in de hoek van je scherm. Een paar regels tekst. Misschien een knop of twee. Daarin kun je geen rijke productkaarten tonen. Je kunt geen kaart van een reis laten zien. Je kunt iemand niet laten browsen, vergelijken, reizen bewaren voor later. Het formaat dicteert de ervaring, en het formaat is een doos.
Die ervaring is precies waarom we geen nieuwe chatbot hebben gebouwd. Geen slimmere. Geen betere. Iets fundamenteel anders. Een volledige conversationele interface, vanaf nul gebouwd, ontworpen om te inspireren. Waar iemand bestemmingen kan verkennen, reizen kan ontdekken waarvan hij het bestaan niet kende, en waar hij — als hij er klaar voor is — na een gesprek dat echt goed voelde in contact komt met een specialist. Niet na drie mislukte pogingen om langs een poortwachter te komen.
De echte vraag was nooit “hoe voegen we AI toe aan onze website?” De echte vraag is: waar creëert AI echt waarde die eerder niet mogelijk was? Dat zijn we gaan testen.
Waarom ik bouwde wat ik bouwde
Ik heb dit niet gebouwd omdat ik denk dat websites dood zijn, of omdat ik wilde kunnen zeggen dat we “iets met AI doen”. Ik heb eerder geschreven over hoeveel ik een hekel heb aan die mentaliteit.
Ik heb dit gebouwd vanwege een vraag die ik al meer dan een jaar toets: is conversationele AI er echt klaar voor om een echt kanaal te zijn?
In mijn Web 4.0-post schreef ik over het autonome web, een wereld waarin AI-assistenten niet alleen informatie ophalen, maar optreden als onafhankelijke digitale consumenten namens hun mensen. Waar Lisa tegen haar AI-assistent zegt “zoek een reis van twee weken naar Thailand” en de AI via MCP-interfaces contact opneemt met reisorganisaties, onderhandelt, verfijnt en opties presenteert. Zonder dat Lisa ook maar een browser opent.
Dat klinkt misschien alsof de mens uit het plaatje verdwijnt. Dat is niet zo. De techniek maakt volledige autonomie mogelijk. Maar dat betekent niet dat we de mens willen weghalen. Het betekent dat de klant mag kiezen. En onze default is en blijft: naar een mens leiden. Daar later meer over.
Die toekomst komt. Misschien niet morgen, maar hij komt. En als je een reisorganisatie bent die zichzelf serieus neemt, kun je er maar beter op voorbereid zijn.
Dus bouwde ik Joy, een AI-reisassistent voor 333travel. Niet als productlancering, niet als marketingstunt, maar als een serieuze test. Kunnen we een conversatie-interface bouwen die écht waarde toevoegt? Die onze producten begrijpt? Die minder hallucineert? Die een echt nuttige ervaring neerzet als extra kanaal naast onze website, telefoon en e-mail?
Ik heb dit niet gebouwd om onze website te vervangen. Ik heb dit gebouwd om een vraag te beantwoorden: kan een gesprek een betekenisvol kanaal zijn voor gepersonaliseerd reizen?
Wat het eigenlijk is
Laat me concreet zijn over wat Joy doet:
Joy zit bovenop onze volledige productdatabase. Elke rondreis, elk hotel, elke excursie, elke bestemming, allemaal als vectoren geëmbed in een eigen database. Als een klant zegt “ik wil iets avontuurlijks in Zuidoost-Azië, zo’n twee weken, niet te toeristisch,” dan gaat Joy niet keyword-matchen tegen een PDF. Ze doorzoekt semantisch honderden producten, rerankt de resultaten op werkelijke relevantie en komt met opties die echt aansluiten bij de intentie.
En ze onthoudt het gesprek. Niet alleen het laatste bericht, de hele thread. Ze weet welke reizen besproken zijn, wat bewaard is, wat verworpen. Als je zegt “die reis die je eerder noemde met de kookles,” snapt ze wat je bedoelt, ook al noemde ze het zelf een “culinaire ervaring.”
Maar hier zit het cruciale verschil met elke willekeurige chatbot: ze weet niet alleen iets van reizen in het algemeen. Ze kent ónze reizen. Onze specifieke producten. Onze specifieke reisschema’s. Onze bestemmingen die ons team zelf heeft bezocht. Dat kun je niet zomaar met een plugin erop plakken, hoe slim de LLM erachter ook is.
En op het moment dat je menselijk contact wilt? Dan geeft Joy de volledige context door aan een echte reisspecialist die precies weet wat je hebt verkend. Geen “kun je je vraag nog eens omschrijven.” Geen koude overdracht. Volledige continuïteit.
Joy vervangt gesprekken met specialisten niet. Ze maakt ze beter.
Wat ze (nog) niet doet: klantenservicevragen, luchtvaartinformatie of support na boeking afhandelen. Dit is puur een kanaal voor productontdekking en inspiratie. Daar komen we nog wel. Maar we gaan niet doen alsof ze dingen kan die ze niet kan. En eerlijk gezegd: als iemand bij de klantenservice terechtkomt, is er al een probleem. Dat is het slechtst denkbare moment om een machine tussen jou en je klant te zetten. Dan moet je er zelf zijn. Persoonlijk. Dus we zijn nog steeds aan het discussiëren over wat we haar daar laten doen. De nuance zit altijd in de details.
Waarom je hier niet komt met een plugin
Wat wij gebouwd hebben, bereik je niet door een plugin te installeren. Niet met ChatGPT. Niet met een of andere standaard “AI-widget.” Niet met een SaaS-tool die belooft “je website in minuten slimmer te maken.”
En dat komt niet doordat de AI-modellen niet goed genoeg zijn. De modellen zijn prima. Het probleem zit in alles eromheen.
Het hele systeem draait op data die wij zelf bezitten, structureren en beheersen. Elke reis in onze database is door ons eigen team bezocht. Elk reisschema is onze eigen creatie. Elk stuk bestemmingenkennis leeft in onze eigen systemen. Dit is geen data die we van een derde partij licentiëren of uit een brochurecatalogus trekken.
Dat betekent dat we het kunnen embedden. Dat we het precies zo kunnen structureren als we nodig hebben voor semantisch zoeken. Dat we het kunnen bijwerken op het moment dat er iets verandert. Wij beheersen de volledige pipeline, van ruwe productdata naar vector embedding naar retrieval naar antwoord.
Je kunt geen slimme interface bouwen bovenop bergen domme data.
Als je productdata in andermans systeem leeft, als je reizen uit een catalogus doorverkoopt, als je “database” een verzameling PDF’s van touroperators is, dan ben je afhankelijk van welke structuur iemand anders heeft bedacht. Je kunt geen intelligentie bouwen op data die je niet begrijpt of beheerst.
En veel bedrijven starten niet alleen vanaf nul, ze starten met een achterstand. Hun bestaande systemen zijn al onvoldoende. De booking engine is verouderd. De productdata ligt verspreid over spreadsheets en PDF’s. De customer journey heeft overal gaten. En in plaats van die fundamenten te fixen, vinden ze het slim om er een AI-chatbot bovenop te leggen. Alsof intelligentie bovenop disfunctie iets functioneels oplevert. Doet het niet. Het maakt de disfunctie alleen moeilijker te diagnosticeren.
Je lost geen probleem op. Je versiert het.
Wat wij gebouwd hebben, vereiste drie dingen:
Onze eigen data. Elke reis is van ons. Bezocht door ons team. Gestructureerd in onze database. Embedded in onze vector store. Je kunt geen semantic search bouwen over data die je niet zelf structureert.
Onze eigen systemen. Onze eigen backend, frontend, deployment pipeline. Toen we een dual reranker nodig hadden, bouwden we die. Toen we semantic conversation memory nodig hadden, bouwden we het. Toen we een MCP server nodig hadden voor Web 4.0-readiness, bouwden we die. Geen goedkeuring van een vendor nodig. Geen feature requests. Geen afhankelijkheid van andermans roadmap.
De hele keten in eigen hand. Van het moment dat een klant de chat opent tot het moment dat ze met een specialist praten, is elke stap van ons. De AI kent onze producten omdat we de producten zelf hebben gemaakt. De specialist kent het gesprek omdat ons systeem het aan hen doorgeeft.
De AI is de laatste 10% van het werk. De eerste 90% is een bedrijf bouwen dat het kan dragen.
In deel 2 laat ik zien hoe het onder de motorkap echt werkt. De architectuur, de search pipeline, het geheugensysteem dat vele pogingen kostte om goed te krijgen, en waarom 25 seconden wachten aanvoelt als 5 als je het goed ontwerpt.
All Subjects MatterRemco Loup.
