Er ontstaat een nieuw distributiekanaal: je dienst draait niet op je eigen site maar binnen een AI-assistent. Eurostar bracht deze maand een app uit in ChatGPT waarin je reizen kunt zoeken en boeken. Hieronder wat je daarvoor moet bouwen, waarom het iets anders is dan een chatbot op je eigen site, en wanneer het de moeite waard is.
Niet je gebruiker komt naar jouw scherm, jouw functionaliteit gaat naar zijn gesprek.
Tot nu toe was de vraag hoe je mensen naar je app of site kreeg. Bij dit kanaal draait dat om. De gebruiker zit al in een gesprek met een assistent, stelt daar een vraag, en jouw dienst wordt binnen dat gesprek aangeroepen om iets op te zoeken, te berekenen of vast te leggen. Hij verlaat de assistent niet.
Technisch betekent dat: je bouwt geen interface maar een set acties. Je beschrijft wat je product kan ("zoek een reis", "controleer beschikbaarheid", "maak een reservering"), welke gegevens elke actie nodig heeft en wat ze teruggeeft. De assistent bepaalt vervolgens zelf wanneer hij welke actie aanroept, op basis van wat de gebruiker zegt. Voor wie gewend is de gebruikersreis te ontwerpen, is dat even wennen: jij levert de bouwstenen, iemand anders bepaalt de volgorde.
Het protocol daarvoor is het Model Context Protocol. Wat dat is en hoe het werkt staat in wat is MCP. Deze pagina gaat over de vraag daarboven: is dit een kanaal waar jouw product iets te zoeken heeft, en wat kost het je om er te staan.
Het kanaal is niet neutraal. Sommige diensten passen er natuurlijk in, andere verliezen juist waar ze het van moeten hebben.
In de kern een server die acties aanbiedt, met drie dingen die je zorgvuldig moet doen.
Elke actie krijgt een naam, een omschrijving in gewone taal en een schema van de gegevens die erin en eruit gaan. Die omschrijving is geen documentatie maar functionaliteit: de assistent kiest op basis daarvan of hij je actie aanroept. Vage omschrijvingen leiden tot een dienst die nooit wordt gebruikt of juist op de verkeerde momenten.
De gebruiker moet zijn account bij jou koppelen, en jouw server moet weten namens wie er wordt gehandeld. Dat loopt via een standaard autorisatieflow. Belangrijker dan de techniek is de vraag welke acties je überhaupt aanbiedt: alles wat geld kost of onomkeerbaar is, hoort een expliciete bevestiging te krijgen.
Een assistent kan je acties vaker en sneller aanroepen dan een mens ooit zou doen, en soms in een lus. Bouw limieten per gebruiker en per tijdvak, en zorg dat een mislukte aanroep niet stilletjes opnieuw wordt geprobeerd. Dit is het onderdeel dat in prototypes standaard vergeten wordt.
Drie problemen die je pas tegenkomt als je het echt aanzet.
Het eerste is dat je de presentatie kwijt bent. Wat de gebruiker ziet is wat de assistent van je antwoord maakt, en dat kan samenvatten, weglaten of herformuleren. Voorwaarden, annuleringsregels en prijsopbouw die je op je eigen site zorgvuldig toont, kunnen in de samenvatting verdwijnen. Wat juridisch moet worden getoond, moet je dus afdwingen in de flow zelf, bijvoorbeeld door een bevestigingsstap die naar je eigen omgeving leidt.
Het tweede is dat je niet weet waarom je wel of niet wordt aangeroepen. Er is geen ranking die je kunt inzien en geen dashboard dat vertelt dat je omschrijving te vaag was. Je merkt het aan het uitblijven van verkeer. De enige knop die je hebt is de omschrijving van je acties zelf, en die moet je behandelen zoals je een advertentietekst behandelt: testen en bijstellen.
Het derde is de aanname dat dit je site vervangt. Dat doet het niet. Het is een extra ingang voor mensen die toch al in een assistent zitten, naast je bestaande kanalen. Wie merkt dat organisch zoekverkeer terugloopt doordat AI-assistenten antwoorden geven, leest ook vindbaar blijven nu AI de antwoorden geeft; dit kanaal is daar een deel van het antwoord op, geen vervanging.
Voordat je hier serieus in investeert, is dit het minimum dat je wilt weten.
Het betekent dat jouw functionaliteit binnen het gesprek met de assistent beschikbaar is. De gebruiker stelt een vraag, de assistent roept jouw dienst aan om iets op te zoeken of vast te leggen, en het antwoord verschijnt in het gesprek. Er is geen aparte app die iemand installeert; er is een koppeling die de gebruiker een keer goedkeurt.
Nee, en het verschil is groter dan het lijkt. Bij een chatbot op je eigen site bepaal jij de omgeving, de vormgeving en het gesprek. Hier ben je te gast in het gesprek van iemand anders: je levert acties aan, de assistent bepaalt wanneer hij ze gebruikt en hoe hij het resultaat presenteert.
In de kern een server die je acties aanbiedt volgens het Model Context Protocol, met per actie een naam, een omschrijving in gewone taal en een schema voor de invoer en de uitvoer. Daarbij komt een autorisatieflow zodat de gebruiker zijn account koppelt, en beperkingen op hoe vaak en hoe snel acties mogen worden aangeroepen.
Meestal grotendeels wel. Als je al een koppelvlak hebt met duidelijke eindpunten, is het werk vooral het beschrijven van die acties in taal die een model begrijpt, en het inbouwen van de autorisatie en de limieten. Dat maakt de stap veel kleiner dan mensen verwachten.
Door ze niet aan de samenvatting van de assistent over te laten. Wat de gebruiker moet zien voordat hij zich ergens aan bindt, dwing je af in de flow: laat de laatste bevestigingsstap plaatsvinden in je eigen omgeving, of geef de assistent een antwoord waarin de kernvoorwaarden niet weg te laten zijn zonder de betekenis te veranderen.
Alleen door het zelf te tellen. Er is geen extern dashboard dat vertelt hoe vaak je bent overwogen of waarom je niet bent gekozen. Log per actie het aantal aanroepen, de uitkomst en de vervolgstap, want dat is het enige signaal dat je hebt om je omschrijvingen bij te stellen.
Het onderliggende protocol is niet aan één aanbieder gebonden, en meerdere partijen ondersteunen het inmiddels. Salesforce kondigde bijvoorbeeld aan dat zijn agentplatform aanroepbaar wordt vanuit zowel Claude als ChatGPT. Bouw je het één keer goed, dan is de stap naar een tweede assistent klein.
Dat hangt ervan af of jouw waarde in een handeling zit of in een scherm. Kun je in drie acties uitdrukken wat mensen bij je komen doen, dan is de bouw beperkt en het kanaal een reële kans. Zit de waarde in wat de gebruiker ziet en doorloopt, dan verlies je juist datgene waar je het van moet hebben.
Stuur ons je idee. Wij kijken in een intake mee welke flow je wilt testen en leveren in één werkdag een klikbaar prototype, met de juiste tools voor jouw geval.
Een korte intake volgt na je inschrijving. Daarna stemmen we scope en datum af.
We nemen contact op om de intake in te plannen.
We gebruiken cookies om je ervaring te verbeteren en het gebruik van de site te meten.