BeanBot, ein KI-Chat-Assistent für The Coffee Bean & Tea Leaf
BeanBot und die No-Code-Admin-Konsole verwandeln eine statische Café-Speisekarte in ein faktenbasiertes Gespräch: Entdecken, Empfehlungen, Preise und Bestellung auf einer Oberfläche, in mehr als 50 Filialen in Indien.
Auf einen Blick
BeanBot ist ein einbettbarer KI-Chat-Assistent mit No-Code-Admin-Konsole, den Mindrops für die 50+ Filialen von The Coffee Bean & Tea Leaf in Indien entwickelt hat. Auf Basis von TypeScript, Express, PostgreSQL mit pgvector und React beantwortet er Fragen zu Speisekarte, Filialen und Marke aus Live-Daten, führt rund 10.000 Gespräche im Monat und generiert etwa 50 Bestellungen pro Tag.
Die Herausforderung
The Coffee Bean & Tea Leaf ist eine in den USA gegründete Spezialitätenkette für Kaffee und Tee, seit 1963 am Markt, mit 50+ Filialen in ganz Indien. Café-Gäste fragen so, wie sie denken – nach Absicht, Vorliebe und Ernährungsweise – und sie vertippen sich. Eine statische Web- oder PDF-Speisekarte beantwortet nichts davon.
„Welche Eiskaffees haben Sie?“, „etwas Süßes, aber nicht zu schwer“, „ist der Avocado-Toast vegetarisch?“, „welche Filiale in meiner Nähe hat geöffnet?“ – eine Speisekarte kann nichts davon beantworten. Entdecken, Genauigkeit, Bestellung und die tägliche Pflege lagen alle außerhalb der Speisekarte, ein Tippfehler wie „lattee“ führte bei der Suche ins Leere, und jede Änderung an Inhalten oder Preisen hing an der Entwicklung. Es fehlte eine Oberfläche, die eine Anfrage verstehen und danach handeln kann, ohne je einen Artikel oder einen Preis zu erfinden.
Die Lösung
Mindrops hat BeanBot konzipiert und umgesetzt – eine Full-Stack-Anwendung in TypeScript: ein einbettbares Chat-Widget auf einer Express-API, eine PostgreSQL-Datenbank mit Vektor- und Fuzzy-Search-Erweiterungen sowie eine umfassende React-Admin-Konsole. Die Pipeline ist bewusst gestuft, sodass die meisten Interaktionen nie ein Sprachmodell erreichen.
Gäste chatten ganz natürlich und erhalten reichhaltige, strukturierte Antworten – Gesprächstext, wischbare Produktkarten mit „Jetzt bestellen“ und „Mehr Details“, Filialkarten mit Karten- und Anrufaktionen sowie antippbare Vorschlags-Chips für Folgefragen mit einem Fingertipp. Das Verhalten ist in Daten hinterlegt, sodass das Unternehmen den Assistenten über die Konsole justiert, ohne ein Deployment.
Gestufte Anfrage-Pipeline
Anfragen werden nach Typ geroutet. Button-Taps liefern voreingestellte Antworten; Speisekarten- und Kategoriebegriffe – mit Tippfehlertoleranz – werden direkt aus der Datenbank beantwortet. Nur wirklich offene Fragen erreichen ein Sprachmodell, was den alltäglichen Pfad schnell und kostengünstig hält.
Zweistufiges, faktenbasiertes LLM
Ein Planer (OpenAI gpt-4.1-mini) liest die Nachricht und gibt JSON aus, das beschreibt, welche Abfragen auszuführen sind – er schreibt nie die Antwort. Ein Responder (Groq-gehostet) formt die Ergebnisse unter strengen Anti-Halluzinations-Regeln in strukturierte Blöcke und nennt nur Artikel, welche die Abfrage zurückgab.
Dreistufige Suche
Exakter Namensabgleich, dann tokenisierte Relevanz, dann Trigramm-Fuzzy-Matching für Tippfehler („lattee“ → „Latte“) – mit Abbruch auf der ersten passenden Stufe. Dieser Pfad ist regelbasiert und statistisch, ohne Modell-Latenz oder -Kosten.
Faktenbasiertes Wissen (RAG)
Fragen zu Marke, Richtlinien, Treueprogramm und FAQ werden per Retrieval über die Unternehmenswebsite beantwortet. Ein rekursiver Crawler bereinigt und zerteilt Seiten in Chunks, OpenAI-Embeddings ermöglichen die semantische Suche über pgvector, und kuratierte Inhalte sind vor automatischer Löschung geschützt.
Filialfinder & Preise je Filiale
Kunden finden die nächste Filiale per Geokoordinaten oder Stadt. Jede Filiale kann Basispreise und Verfügbarkeit überschreiben, sodass der Bot stets den richtigen Preis zeigt – inklusive der per QR-Code erfassten Filiale und des Tisches für den Verzehr vor Ort.
No-Code-Steuerbarkeit & Analytics
Prompts, Schnellzugriffs-Buttons, tageszeitabhängige Begrüßungen, Willkommens- und Fallback-Nachrichten sowie Preise je Filiale liegen alle in der Datenbank und sind über die Konsole editierbar. Jede Interaktion wird Schritt für Schritt nachverfolgt, mit Analytics zu Sitzungen, Token-Verbrauch und „Jetzt bestellen“-Klicks.
So funktioniert BeanBot
Jede eingehende Nachricht wird nach Typ geroutet. Der häufigste Pfad kommt ganz ohne Modell aus; nur eine offene Frage durchläuft den zweistufigen Ablauf – und selbst dann garantiert ein deterministischer Neuaufbau im Backend korrekte Karten, Preise und Links.
Voreingestellte Antwort
Liefert in der Admin-Konsole konfigurierte Inhalte. Kein Modell.
Dreistufige Suche
Ordnet Kategoriebegriffe und Tippfehler dem Katalog zu. Kein Modell · tippfehlertolerant.
Zweistufiges LLM
Planen → Abfragen → Antworten, gestützt auf die Ergebnisse. Nutzt LLM · faktenbasiert.
Ist eine Frage offen, entscheidet der Planer, was abzurufen ist, und schreibt nie die an den Nutzer gerichtete Antwort; die Lookup-Engine führt die dreistufige Suche aus und wendet filialspezifische Preise an; der Responder schreibt die Antwort und darf nur auf das verweisen, was die Abfrage zurückgab. Als Sicherheitsnetz baut das Backend Produkt- und Filialkarten aus den maßgeblichen Datenbankeinträgen neu auf, sodass Bilder, Preise, Kartenlinks und Telefonnummern stets korrekt sind, selbst wenn das Modell sie auslässt.
| Suchstufe | Methode | Ziel-Latenz* |
|---|---|---|
| Stufe 1 – Exakt | Exakter Namensabgleich ohne Beachtung der Groß-/Kleinschreibung (B-Tree-Index) | < 10 ms |
| Stufe 2 – Tokenisiert | Token-Abgleich über Name und Beschreibung mit Relevanzbewertung | < 30 ms |
| Stufe 3 – Fuzzy | Trigramm-Ähnlichkeit (pg_trgm) für Tippfehler, z. B. „lattee“ → „Latte“ | < 50 ms |
*In der Implementierung definierte Designziele, keine gemessenen Produktivwerte. Die Suche bricht auf der ersten passenden Stufe ab.
Ergebnisse
Aus der alltäglichen Speisekarte wurde etwas, mit dem Gäste sprechen können, und das Team ändert Preise und Prompts über die Admin-Konsole.
| Bereich | Vorher | Nachher |
|---|---|---|
| Entdeckung | Eine statische Speisekarte oder PDF durchscrollen. | Nach Absicht fragen; faktenbasierte Karten mit Preisen und Aktionen. |
| Tippfehler & vage Anfragen | Sackgasse, keine Ergebnisse. | Tokenisiertes und Fuzzy-Matching lösen sie ohne Modell auf. |
| Genauigkeit | Risiko veralteter oder falscher Informationen. | Antworten gestützt auf aktuelle Katalog-, Filial- und Website-Daten. |
| Bestellung | Stöbern getrennt von der Bestellaktion. | „Jetzt bestellen“ bei jedem Produkt, mit Filial- und Tischkontext. |
| Inhalt & Preise | Entwicklungsticket plus ein Deployment. | Über die Admin-Konsole bearbeitet, ohne Deployment. |
| Kosten & Latenz | Jede Antwort würde ein Modell aufrufen. | Der häufige Pfad ist konstruktionsbedingt modellfrei. |
Für Kunden
Gesprächsbasierte Entdeckung nach Absicht und Vorliebe, tippfehlertolerante Suche, Empfehlungen nach Bedarf (Signature, gesünder, vegetarisch) und eine „Jetzt bestellen“-Aktion bei jedem Produkt – mit dem aus dem QR-Code übernommenen Kontext für den Verzehr vor Ort.
Für das Unternehmen
Konstruktionsbedingt genau, geringere Modellkosten (die meisten Interaktionen brauchen keine Inferenz), Umsatz an den Chat gekoppelt über Preise je Filiale und Bestell-Deeplinks sowie volle Steuerbarkeit – Prompts, Inhalte und Preise ändern sich über die Konsole, mit Traces je Nachricht und Analytics für den Rest.
Betriebszahlen – Filialen, monatliche Gespräche und tägliche Bestellungen – wurden vom Auftraggeber bereitgestellt. Vorher-nachher-Einträge spiegeln die durch die Plattform gelieferte Prozessänderung wider. Eine unabhängige Leistungsmessung gab es nicht.
Eingesetzte Technologien
Eine faktenbasierte, kostenbewusste Architektur: Der Planer gibt nur Abfrageanweisungen aus, der Responder darf nur auf zurückgegebene Artikel verweisen, und das Backend baut Karten als deterministisches Sicherheitsnetz aus Datenbankeinträgen neu auf.
Grounding-Modell
Die Entscheidung, was abgerufen wird, ist von der Formulierung der Antwort getrennt. Strenge Anti-Halluzinations-Regeln plus ein deterministischer Karten-Neuaufbau aus der Datenbank schließen erfundene Produkte und Preise aus.
Suchstrategie
Drei Stufen, die beim ersten Treffer abbrechen – exakt, tokenisierte Relevanz, dann Trigramm-Fuzzy –, sodass Tippfehlertoleranz keine Modellkosten verursacht. Jede Abfrage erfasst Stufe, Dauer und Trefferanzahl.
Wissens-Sync
Ein nächtlicher Rista-POS-Sync aktualisiert den Katalog, dann werden Embeddings und Cache neu erzeugt. Ein rekursiver Web-Crawler zerteilt Website-Inhalte in Chunks und bettet sie ein, mit Prüfsummen-basierter Änderungserkennung.
Primär- und Fallback-Modell-Routing mit Health-Probe-Failover, hybrides IP- und Session-Rate-Limiting sowie Helmet/CORS-Härtung halten den Dienst produktionsreif – ein Muster, das sich für jeden Katalog wiederholen lässt, der ein Gespräch führen sollte.
Häufige Fragen
Was hat Mindrops für The Coffee Bean & Tea Leaf entwickelt?
Welche Technologien stecken hinter BeanBot?
Wie verhindert BeanBot erfundene Produkte oder Preise?
Welches Volumen bewältigt BeanBot?
Kann Mindrops einen Chat-Assistenten für unseren Katalog entwickeln?
Kontakt
Sagen Sie uns, was Ihre Kunden fragen – wir zeigen Ihnen, wie wir es angehen würden. Mindrops entwickelt faktenbasierte, kostenbewusste Dialogsysteme auf First-Party-Daten, von der Absichtsplanung bis zur No-Code-Steuerbarkeit.