BeanBot, an AI chat assistant for The Coffee Bean & Tea Leaf
BeanBot and its no-code admin console rebuild a static café menu as a grounded conversation: discovery, recommendation, pricing and ordering in one surface, across 50+ outlets in India.
At a glance
BeanBot is an embeddable AI chat assistant and no-code admin console that Mindrops built for The Coffee Bean & Tea Leaf's 50+ outlets in India. Built in TypeScript on Express, PostgreSQL with pgvector and React, it answers menu, store and brand questions from live data, handles about 10,000 conversations a month and around 50 orders a day.
The challenge
The Coffee Bean & Tea Leaf is a U.S.-founded specialty coffee and tea chain, operating since 1963, with 50+ outlets across India. Café customers ask the way they think — by intent, preference and dietary need — and they mistype. A static web or PDF menu answers none of that.
“What iced coffees do you have?”, “something sweet but not too heavy”, “is the avocado toast vegetarian?”, “which store is open near me?” — a menu can’t answer any of it. Discovery, accuracy, ordering and day-to-day control all sat outside the menu; a misspelling such as “lattee” dead-ended discovery; and every change to content or pricing depended on engineering. What was missing was a surface that could understand a request and act on it, while never inventing an item or a price.
The solution
Mindrops designed and delivered BeanBot — a full-stack TypeScript application: an embeddable chat widget on an Express API, a PostgreSQL database with vector and fuzzy-search extensions, and a comprehensive React admin console. The pipeline is deliberately tiered so that most interactions never reach a language model.
Customers chat naturally and receive rich, structured replies — conversational text, swipeable product cards with “Order Now” and “More Details”, store cards with map and call actions, and tappable suggestion chips for one-tap follow-ups. Behavior is stored as data, so the business tunes the assistant from the console without a deploy.
Tiered request pipeline
Requests are routed by type. Button taps return pre-set responses; menu and category words — with typo tolerance — are answered straight from the database. Only genuinely open-ended questions reach a language model, keeping the everyday path fast and inexpensive.
Two-stage grounded LLM
A planner (OpenAI gpt-4.1-mini) reads the message and emits JSON describing which lookups to run — it never writes the reply. A responder (Groq-hosted) turns the results into structured blocks under strict anti-hallucination rules, naming only items the lookup returned.
Three-tier search
Exact name match, then tokenized relevance, then trigram fuzzy matching for typos (“lattee” → “Latte”) — exiting at the first matching tier. This path is rule-based and statistical, with no model latency or cost.
Grounded knowledge (RAG)
Brand, policy, loyalty and FAQ questions are answered with retrieval over the company website. A recursive crawler cleans and chunks pages, OpenAI embeddings power semantic search via pgvector, and curated content is protected from auto-deletion.
Store locator & multi-store pricing
Customers find the nearest store by geo-coordinates or city. Each store can override base pricing and availability, so the bot always shows the right price — including the store and table captured from a QR code for dine-in.
No-code operability & analytics
Prompts, quick-action buttons, time-of-day greetings, welcome and fallback messages and per-store pricing all live in the database, editable from the console. Every interaction is traced step by step, with analytics on sessions, token usage and “Order Now” clicks.
How BeanBot works
Every incoming message is routed by type. The common path never touches a model; only an open-ended question runs the two-stage flow — and even then a deterministic backend rebuild guarantees correct cards, prices and links.
Pre-set response
Returns content configured in the admin console. No model.
Three-tier search
Maps category words and typos to the catalog. No model · typo-tolerant.
Two-stage LLM
Plan → lookup → respond, grounded in the results. Uses LLM · grounded.
When a question is open-ended, the planner decides what to fetch and never writes the user-facing reply; the lookup engine runs the three-tier search and applies store-specific pricing; the responder writes the reply and may reference only what the lookup returned. As a safety net, the backend rebuilds product and store cards from authoritative database records, so images, prices, map links and phone numbers are always correct even if the model omits them.
| Search tier | Method | Target latency* |
|---|---|---|
| Tier 1 — Exact | Case-insensitive exact name match (B-tree index) | < 10 ms |
| Tier 2 — Tokenized | Token match across name and description with relevance scoring | < 30 ms |
| Tier 3 — Fuzzy | Trigram similarity (pg_trgm) for typos, e.g. “lattee” → “Latte” | < 50 ms |
*Design targets defined in the implementation, not measured production figures. Search exits at the first matching tier.
Results
The everyday menu became something customers can talk to, and the team changes prices and prompts from the admin console.
| Area | Before | After |
|---|---|---|
| Discovery | Scroll a static menu or PDF. | Ask by intent; grounded cards with prices and actions. |
| Typos & vague asks | Dead-end, no results. | Tokenized and fuzzy match resolve them without a model. |
| Accuracy | Risk of stale or wrong information. | Answers grounded in live catalog, store and website data. |
| Ordering | Browsing separate from the order action. | “Order Now” on every product, with store and table context. |
| Content & pricing | Engineering ticket plus a deploy. | Edited from the admin console, no deploy. |
| Cost & latency | Every answer would hit a model. | Common path is model-free by design. |
For customers
Conversational discovery by intent and preference, typo-tolerant search, recommendations by need (signature, healthy, vegetarian), and an “Order Now” action on every product — with dine-in context carried from the QR code.
For the business
Accurate by design, lower model cost (most interactions need no inference), revenue tied to chat through per-store pricing and order deep links, and full operability — prompts, content and pricing change from the console, with per-message traces and analytics for the rest.
Operating figures — outlets, monthly conversations and daily orders — were supplied during the engagement. Before/after positions describe the change in process delivered by the platform. No independent performance measurement was made.
Technologies used
A grounded, cost-aware architecture: the planner emits only lookup instructions, the responder may reference only returned items, and the backend rebuilds cards from database records as a deterministic safety net.
Grounding model
What-to-fetch is separated from how-to-say-it. Strict anti-hallucination rules plus a deterministic card rebuild from the database eliminate fabricated products and prices.
Search strategy
Three tiers exit at the first match — exact, tokenized relevance, then trigram fuzzy — so typo tolerance carries no model cost. Each query records tier, duration and result count.
Knowledge sync
A nightly Rista POS sync refreshes the catalog, then regenerates embeddings and cache. A recursive web crawler chunks and embeds site content with checksum-based change detection.
Primary and fallback model routing with health-probe failover, hybrid IP and session rate limiting, and Helmet/CORS hardening keep the service production-ready — a pattern repeatable for any catalog that should hold a conversation.
Frequently asked questions
What did Mindrops build for The Coffee Bean & Tea Leaf?
Which technologies power BeanBot?
How does BeanBot avoid inventing items or prices?
What volume does BeanBot handle?
Could Mindrops build a conversational assistant for our catalog?
Contact us
Tell us what your customers ask, and we’ll show you how we’d approach it. Mindrops builds grounded, cost-aware conversational systems on first-party data, from intent planning to no-code operability.