BeanBot, een AI-chatassistent voor The Coffee Bean & Tea Leaf
BeanBot en de no-code adminconsole zetten een statisch cafémenu om in een gesprek op basis van live data: ontdekken, aanbevelen, prijzen en bestellen in één interface, in 50+ vestigingen in India.
In één oogopslag
BeanBot is een inbouwbare AI-chatassistent met no-code adminconsole die Mindrops bouwde voor de 50+ vestigingen van The Coffee Bean & Tea Leaf in India. Gebouwd in TypeScript, Express, PostgreSQL met pgvector en React, beantwoordt BeanBot vragen over menu, winkels en merk op basis van live data en verwerkt het zo’n 10.000 gesprekken per maand en circa 50 bestellingen per dag.
De uitdaging
The Coffee Bean & Tea Leaf is een in de VS opgerichte keten van specialty koffie en thee, actief sinds 1963, met 50+ vestigingen in heel India. Cafébezoekers stellen hun vragen zoals ze denken – vanuit wat ze zoeken, hun voorkeur en hun dieetwensen – en ze maken tikfouten. Een statisch web- of PDF-menu beantwoordt daar niets van.
“Welke iced coffees hebben jullie?”, “iets zoets maar niet te zwaar”, “is de avocado toast vegetarisch?”, “welke winkel is open bij mij in de buurt?” – een menu kan daar niets van beantwoorden. Zoeken, nauwkeurigheid, bestellen en het dagelijkse beheer vielen allemaal buiten het menu; een tikfout als “lattee” leverde niets op, en elke wijziging in content of prijzen was afhankelijk van het engineeringteam. Het ontbrak aan een kanaal dat een verzoek kon begrijpen en erop kon handelen, zonder ooit een item of een prijs te verzinnen.
De oplossing
Mindrops ontwierp en realiseerde BeanBot – een full-stack TypeScript-applicatie: een inbouwbare chatwidget op een Express-API, een PostgreSQL-database met vector- en fuzzy-search-extensies, en een uitgebreide React-adminconsole. De pipeline is bewust gelaagd, zodat de meeste interacties nooit een taalmodel bereiken.
Klanten chatten zoals ze gewend zijn en krijgen rijke, gestructureerde antwoorden – gewone tekst, swipebare productkaarten met “Nu bestellen” en “Meer details”, winkelkaarten met knoppen voor route en bellen, en suggestiechips voor vervolgvragen met één tik. Het gedrag is in data vastgelegd, zodat het bedrijf de assistent vanuit de console afstemt, zonder nieuwe deployment.
Gelaagde verzoekpipeline
Verzoeken worden per type doorgestuurd. Een tik op een knop levert een vooraf ingesteld antwoord op; menu- en categoriewoorden – met tikfouttolerantie – worden rechtstreeks uit de database beantwoord. Alleen echt open vragen bereiken een taalmodel, waardoor het dagelijkse pad snel en goedkoop blijft.
Tweetraps-LLM op basis van live data
Een planner (OpenAI gpt-4.1-mini) leest het bericht en levert JSON op die beschrijft welke lookups moeten draaien – hij schrijft nooit het antwoord. Een responder (gehost via Groq) zet de resultaten om in gestructureerde blokken onder strikte anti-hallucinatieregels, en noemt alleen items die de lookup teruggaf.
Drielaagse zoekfunctie
Exacte naamovereenkomst, dan getokeniseerde relevantie, dan trigram fuzzy matching voor tikfouten (“lattee” → “Latte”) – en de zoekfunctie stopt bij de eerste passende laag. Dit pad is regelgebaseerd en statistisch, zonder modellatentie of -kosten.
Onderbouwde kennis (RAG)
Vragen over merk, beleid, het loyaliteitsprogramma en FAQ worden beantwoord met retrieval over de bedrijfswebsite. Een recursieve crawler schoont pagina’s op en deelt ze in chunks, OpenAI-embeddings voeden semantisch zoeken via pgvector, en handmatig samengestelde content wordt beschermd tegen automatische verwijdering.
Winkelzoeker & prijzen per winkel
Klanten vinden de dichtstbijzijnde winkel op geo-coördinaten of stad. Elke winkel kan basisprijzen en beschikbaarheid overschrijven, zodat de bot altijd de juiste prijs toont – ook bij dine-in, waarbij winkel en tafel uit een QR-code worden gehaald.
No-code beheer & analytics
Prompts, snelactieknoppen, begroetingen per dagdeel, welkomst- en fallbackberichten en prijsstelling per winkel staan allemaal in de database, te bewerken vanuit de console. Elke interactie wordt stap voor stap gelogd, met analytics over sessies, tokenverbruik en “Nu bestellen”-kliks.
Hoe BeanBot werkt
Elk binnenkomend bericht wordt per type doorgestuurd. De gewone route komt nooit bij een model; alleen een open vraag doorloopt de tweetrapsflow – en zelfs dan garandeert een deterministische herbouw in de backend correcte kaarten, prijzen en links.
Vooraf ingesteld antwoord
Geeft content terug die in de adminconsole is geconfigureerd. Geen model.
Drielaagse zoekfunctie
Koppelt categoriewoorden en tikfouten aan de catalogus. Geen model · tikfouttolerant.
Tweetraps LLM
Plannen → opzoeken → antwoorden, onderbouwd met de resultaten. Gebruikt LLM · onderbouwd.
Wanneer een vraag open is, beslist de planner wat er wordt opgehaald en schrijft hij nooit het antwoord voor de gebruiker; de lookup-engine draait de drielaagse zoekfunctie en past winkelspecifieke prijsstelling toe; de responder schrijft het antwoord en mag alleen verwijzen naar wat de lookup teruggaf. Als vangnet herbouwt de backend product- en winkelkaarten uit de leidende databaserecords, zodat afbeeldingen, prijzen, kaartlinks en telefoonnummers altijd correct zijn, ook als het model ze weglaat.
| Zoeklaag | Methode | Doellatentie* |
|---|---|---|
| Laag 1 – Exact | Hoofdletterongevoelige exacte naamovereenkomst (B-tree-index) | < 10 ms |
| Laag 2 – Getokeniseerd | Tokenovereenkomst over naam en beschrijving met relevantiescoring | < 30 ms |
| Laag 3 – Fuzzy | Trigram-gelijkenis (pg_trgm) voor tikfouten, bijv. “lattee” → “Latte” | < 50 ms |
*Ontwerpdoelen gedefinieerd in de implementatie, geen gemeten productiecijfers. De zoekfunctie stopt bij de eerste passende laag.
Resultaten
Het dagelijkse menu werd iets waarmee klanten kunnen praten, en het team wijzigt prijzen en prompts vanuit de adminconsole.
| Gebied | Voorheen | Nu |
|---|---|---|
| Zoeken | Door een statisch menu of PDF scrollen. | Vragen naar wat men zoekt; kaarten op basis van live data met prijzen en acties. |
| Tikfouten & vage vragen | Geen resultaten, einde zoektocht. | Getokeniseerde en fuzzy matching lossen ze op zonder model. |
| Nauwkeurigheid | Risico op verouderde of verkeerde informatie. | Antwoorden gebaseerd op live catalogus-, winkel- en websitedata. |
| Bestellen | Bladeren losgekoppeld van de bestelactie. | “Nu bestellen” bij elk product, met winkel- en tafelcontext. |
| Content & prijsstelling | Engineering-ticket plus een deployment. | Bewerkt vanuit de adminconsole, geen deployment. |
| Kosten & latentie | Elk antwoord zou via een model lopen. | De gewone route gebruikt bewust geen model. |
Voor klanten
Producten ontdekken via een gesprek, op basis van behoefte en voorkeur, tikfouttolerante zoekfunctie, aanbevelingen op behoefte (signature, gezond, vegetarisch), en een “Nu bestellen”-actie bij elk product – met dine-in-context meegenomen uit de QR-code.
Voor het bedrijf
Nauwkeurig door het ontwerp zelf, lagere modelkosten (de meeste interacties vereisen geen inferentie), omzet gekoppeld aan chat via prijzen per winkel en deep links voor bestellingen, en volledig beheer – prompts, content en prijzen wijzigen vanuit de console, met traces per bericht en analytics voor de rest.
Operationele cijfers – vestigingen, maandelijkse gesprekken en dagelijkse bestellingen – werden tijdens de opdracht aangeleverd. De voor/na-vergelijkingen weerspiegelen de proceswijziging die het platform heeft gebracht. Er is geen onafhankelijke prestatiemeting gedaan.
Gebruikte technologieën
Een op data gebaseerde, kostenbewuste architectuur: de planner geeft alleen lookup-instructies, de responder mag alleen verwijzen naar teruggegeven items, en de backend herbouwt kaarten uit databaserecords als deterministisch vangnet.
Onderbouwde antwoorden
Wat er wordt opgehaald, staat los van hoe het wordt verwoord. Strikte anti-hallucinatieregels plus een deterministische herbouw van de kaarten uit de database sluiten verzonnen producten en prijzen uit.
Zoekstrategie
Drie lagen – exact, getokeniseerde relevantie, dan trigram fuzzy – waarbij de zoekfunctie stopt bij de eerste overeenkomst, zodat tikfouttolerantie geen modelkosten met zich meebrengt. Elke query registreert laag, duur en aantal resultaten.
Kennissynchronisatie
Een nachtelijke Rista POS-sync ververst de catalogus, daarna worden embeddings en cache opnieuw gegenereerd. Een recursieve webcrawler deelt site-content in chunks en embedt deze met checksum-gebaseerde wijzigingsdetectie.
Primaire en fallback-modelroutering met health-probe-failover, hybride IP- en sessie-rate-limiting, en Helmet/CORS-hardening houden de service productieklaar – een patroon dat herhaalbaar is voor elke catalogus die een gesprek zou moeten voeren.
Veelgestelde vragen
Wat bouwde Mindrops voor The Coffee Bean & Tea Leaf?
Op welke technologieën draait BeanBot?
Hoe voorkomt BeanBot verzonnen producten of prijzen?
Welk volume verwerkt BeanBot?
Kan Mindrops een conversationele assistent voor onze catalogus bouwen?
Contact
Vertel ons wat uw klanten vragen, en wij laten u zien hoe we het zouden aanpakken. Mindrops bouwt kostenbewuste conversationele systemen met onderbouwde antwoorden op first-party data, van intentieplanning tot no-code beheer.