Composite framing: why this is NOT a single named customer
This is a composite case study. It does not profile a single named restaurant chain, and no individual operator, brand, or location is identified by real name. Everything on this page is a synthesis drawn from operator interviews we conducted across 9 regional multi-location restaurant businesses that deployed ChatRaj for guest intake between February and May 2026. The sample includes 3 casual-dining brands, 4 fast-casual brands, and 2 full-service concepts. Site counts in the sample ranged from 4 locations at the small end to 18 locations at the large end, with a median of 11 sites per operator.
We chose the composite framing for three honest reasons. First, our paid-tier restaurant customer base is still small enough that any single named case study would carry survivor bias and would not generalise across the broader operator population. Second, restaurant operators are reasonably protective of their reservation and revenue numbers, and several operators in the sample asked specifically that their brand not be attached to public metric claims. Third, presenting one chain's headline numbers as if they were typical is the kind of marketing maths we explicitly avoid. The multi-location restaurant world has enormous variance in average check, peak hours, dayparts, and how reservation versus walk-in mix interacts with the chatbot value prop. The numbers in the Outcomes section below are typical ranges across the sample, never single-operator point values.
Wherever a metric appears in this page, it is phrased as a range. If a sentence reads like a single number, that is a writing error and not a data claim. The composite persona introduced next, Tandoori House, is a synthetic 12-location regional chain we constructed to keep the narrative concrete; it is not a real client and any resemblance to an existing brand with the same or similar name is unintentional. We reuse this composite persona repeatedly across the page so the reader is never in doubt about the framing.
The synthetic persona: "Tandoori House" 12-location chain
Tandoori House is a composite, not a real brand. It is constructed to match the modal operator in the sample so the narrative is concrete rather than abstract. The same playbook described on this page was reported, in roughly similar form, by the casual-dining, fast-casual, and full-service operators in the sample.
The composite Tandoori House is a regional Indian casual-dining chain with 12 locations across one primary metro and two adjacent metros. Average check is roughly 32 dollars per cover at dinner, 16 dollars at lunch. The chain runs full-service dine-in at 9 sites, hybrid counter-plus-table service at 2 sites, and one ghost-kitchen delivery-only site. Reservation volume averages 60 to 110 covers per location per night at dinner; lunch is mostly walk-in with a small business-lunch reservation tail. Catering is roughly 14 percent of revenue and growing, weighted heavily toward corporate lunch orders (15 to 80 covers, average 38) and small private events at three of the larger locations.
The composite Tandoori House website pulls roughly 28,000 monthly visits across all locations combined. About 41 percent of those visits arrive outside business hours, which for this chain means between 10pm and 11am the next day plus the closed Monday lunch service at 7 sites. The chain's pre-ChatRaj intake stack was a mix: OpenTable for dine-in reservations at 8 sites, Resy at 3 sites, no booking system at the ghost-kitchen site, a per-location contact form for catering inquiries, and a phone number rolling to voicemail for everything else.
Across the broader sample of 9 operators, the chains look different in cuisine and service model but similar in funnel shape. Site counts ranged from 4 to 18. Average check ranged from 14 dollars (fast-casual) to 58 dollars (full-service). After-hours website traffic share ranged from 34 percent to 52 percent. Every operator in the sample had at least one location where after-hours phone calls were rolling to voicemail and producing measurable lost revenue.
The pre-ChatRaj baseline (composite): after-hours phone-call volume, missed reservations
The pattern reported by every operator in the sample, before ChatRaj, looked like this. After 10pm, the phones at most locations stopped being answered. Some chains had a single off-hours number rolling to a corporate voicemail; others let calls die at the location level. Either way, after-hours callers got a voicemail or a busy signal. According to industry estimates we cross-checked, the average single restaurant misses roughly 150 calls per month, and roughly 60 percent of those represent actual guest intent (a reservation request, an order, or a question that would have converted). Industry analyses size the total annual revenue lost to unanswered restaurant calls in the United States at roughly 20 billion dollars (see the QSR Magazine reference linked below).
For a 12-location composite like Tandoori House, that aggregates to a meaningful drag. The operators in the sample reported pre-deployment after-hours call abandonment rates between 28 percent and 47 percent of incoming calls, with the worst sites being the suburban locations whose evening dinner-rush phone load spilled past close. The lost revenue was not only the immediate reservation; it was also the catering inquiry that called at 9:45pm Friday hoping to lock in a Monday lunch for 40 and instead called a competitor on Saturday morning.
Three failure modes appeared in every chain in the sample. First, reservation requests that arrived after the OpenTable widget's last-bookable slot for the evening simply died; the guest could not book online for that night and could not reach a human. Second, catering inquiries that landed in a generic info-at-domain email inbox often sat unread until the catering manager opened email Monday morning, by which point a competitor's catering coordinator had already returned the call. Third, basic procedural questions ("are you halal," "do you have a gluten-free menu," "is the lot free after 7pm," "do you take large parties without reservation") drove inbound call volume that the front-of-house staff was already too busy to answer reliably.
The chains in the composite sample had tried partial fixes. Most had a FAQ page. Two had tried an off-the-shelf rule-based chatbot from a hospitality SaaS vendor; both had ripped it out within 90 days because the rules-tree got brittle and the guest experience was worse than no bot at all.
What changed when ChatRaj shipped (composite)
The deployment shape was broadly consistent across the sample. Each operator created a ChatRaj account at the brand level (one bot per chain, not one per location), trained the bot on the chain website plus a per-location knowledge layer, configured the reservation-versus-catering routing logic in the Instructions panel, connected the lead-capture webhooks to the existing booking and catering systems, and embedded the script tag on the chain site. Total operator time reported across the sample was 6 to 14 hours spread over the first two weeks, with the bulk of the time spent on the per-location knowledge layer (hours, parking, dietary tags, halal or kosher certification at the sites that carry it).
By day 30, the operators in the sample reported a recognisable behavioural shift. The bot was confidently answering "are you open after 10pm at the downtown location," "do you have a vegan tikka masala," "is the patio dog-friendly at the riverside site," "can you accommodate 22 for a birthday next Friday," and "do you cater for 60 with 48 hours notice." After-hours guests who would previously have abandoned the call or sent an email into the void were instead getting an answer in 8 to 12 seconds, then opting into either a reservation handoff (OpenTable or Resy) or a catering-inquiry capture flow that wrote directly into the chain's catering CRM.
Within the composite Tandoori House narrative, the catering manager started arriving Monday morning to a queue of pre-qualified weekend catering inquiries with structured fields already populated: event date, headcount range, dietary requirements, delivery versus pickup, budget signal, location preference. The conversion rate on these structured inquiries ran materially higher than on the free-form contact-form leads the chain had been collecting before, because the bot had already filtered out tyre-kickers and out-of-service-area requests.
How the bot was trained on the location list, menu, hours, dietary tags, catering FAQ
The training set for the composite Tandoori House looked like this. The bot crawled the public chain site, including the homepage, all 12 location pages, the menu (with dietary tags exposed in the HTML, which the bot indexed cleanly), the catering page, the careers page (so the bot could politely deflect career inquiries to the right URL), and roughly a dozen blog posts about menu launches and holiday hours. The bot also ingested a structured spreadsheet uploaded through the Sources tab containing per-location data: hours by day-of-week, kitchen-close time (often 30 minutes before official close), reservation system (OpenTable URL, Resy URL, or none), catering minimums by site, halal certification status for the 3 certified sites, allergen substitution capabilities, and parking notes.
The structured spreadsheet matters more than the website crawl for a chain. Restaurant websites tend to under-document the operational details guests actually ask about. Operators in the sample reported that the spreadsheet approach let the bot answer questions like "is the Eastside location closing early on Thanksgiving Eve" with site-specific accuracy, which the crawled website pages could not have answered because the website had not been updated for the holiday yet.
The Instructions panel for the composite chain bot included a routing rules block. Reservations route to OpenTable, Resy, or a request form depending on the site. Catering inquiries route to the catering CRM webhook regardless of site, with a structured capture flow. Private-event inquiries route to a different webhook that pages the events coordinator. Job applications route to the careers URL with a polite deflection. Press inquiries route to a press email with a deflection.
Reservation handoff: bot captures the request, routes to OpenTable / Resy / Square
For dine-in reservations, the bot does not attempt to be the booking system. It is a triage layer in front of OpenTable, Resy, or Square for Restaurants. The handoff pattern that worked across the sample is: the bot asks the date, party size, time window, and any dietary or accessibility notes; confirms which location best fits the request; then deep-links the guest to the right reservation system with the date and party size prefilled in the URL. For sites without a reservation system, the bot captures a reservation request directly via webhook, which writes to the location's host email or a dedicated inbox the GM checks at open.
This handoff matters because it preserves the operator's existing booking infrastructure. Operators in the sample explicitly did not want a chatbot that competed with OpenTable; they wanted a chatbot that fed OpenTable. Industry observers note that OpenTable itself has been adding AI-driven concierge features in 2025 and 2026 (see the Restaurant Business Online reference linked below), which validates the broader pattern: an AI chat layer in front of a structured booking system, not a replacement for it.
For the composite Tandoori House, reservation-request handoff volume sat in the 1,100 to 1,700 range across the 90-day post-deployment window, centred near 1,400. Of those, roughly 78 to 86 percent completed a booking on the downstream reservation system within 30 minutes of the handoff, which operators in the sample treated as the relevant conversion metric.
Catering inquiries: high-AOV use case (the killer feature)
Catering is the use case that delivered the largest absolute revenue impact across the sample, and is the use case operators in the sample mentioned first when asked what they would not want to give up. The average catering ticket across the composite sample ran between 380 and 1,200 dollars, with corporate-lunch tickets clustering at the lower end and private-event tickets running materially higher. A single recovered catering inquiry that would otherwise have called a competitor easily paid the bot's monthly subscription for a year.
The composite catering flow looks like this. The guest lands on the chain site at 9pm Friday, navigates to the catering page or asks the bot directly. The bot asks event date, headcount range, delivery or pickup, location preference, and dietary requirements. If the headcount is below the location's minimum, the bot suggests an alternate location with a lower minimum or offers the standard family-style takeaway as an alternative. If the headcount is in range, the bot collects email, phone, and event details, then writes the structured inquiry to the catering CRM webhook. The catering manager arrives Monday morning to a populated queue with the inquiries already triaged by date and headcount.
The composite sample reported catering inquiry volume lifting in the 12 to 22 percent range over the 90-day post-deployment window relative to the 90 days before deployment, centred near an 18 percent lift. The conversion rate on these inquiries (inquiries that became booked catering events) ran 4 to 9 percentage points higher than the chain's pre-deployment baseline, which operators attributed to the structured capture and the faster first-response time. A guest who gets a structured acknowledgement at 9:01pm Friday is less likely to call a competitor at 9:15pm Friday.
The 90-day composite metrics
The numbers below are typical ranges across the sample of 9 chains, not single-operator values. We have rounded to ranges deliberately so the page does not imply false precision.
Across the sample, chains reported between 1,100 and 1,700 reservation requests captured outside business hours over a 90-day window. For the composite Tandoori House at 12 locations, the centre of the range maps to roughly 117 captured after-hours reservation requests per location per quarter, or roughly 1.3 per location per day. The lower end of the range came from chains whose dine-in mix skewed toward walk-in traffic; the higher end came from reservation-heavy full-service brands.
Catering inquiries lifted 12 to 22 percent across the sample, as described above. Median first-response latency on catering inquiries fell from 14 to 36 hours (the pre-deployment range) to under one minute (acknowledged by the bot) plus operator time to send a personal follow-up the next business day. After-hours phone-call abandonment fell roughly 45 to 60 percent, because most after-hours callers no longer needed to call: the bot answered the underlying question. Front-of-house phone load during business hours also fell, by roughly 18 to 30 percent across the sample, as recurring procedural questions were absorbed by the chat surface.
The aggregate revenue lift is harder to attribute cleanly, and we are reluctant to publish a single number. Operators in the sample reported quarterly revenue lifts in the 1.5 to 4.5 percent range attributable to chat-sourced reservations and catering, but the noise floor in restaurant revenue (weather, holidays, local sports schedules) is high enough that we would not anchor on that number without a longer time series.
What didn't work (honest): the bot can't handle modifications mid-reservation
Three failure modes appeared often enough across the sample to be worth naming directly.
First, the bot cannot reliably handle reservation modifications. If a guest has an existing OpenTable booking and wants to change it (move from 7:30pm to 8:15pm, change party size from 4 to 6, request a specific table), the bot does not have authenticated access to the booking record and cannot make the change. The pattern that worked was a polite deflection to the existing OpenTable confirmation email's modify link, plus a fallback to the location's host phone number. Operators in the sample initially expected the bot to handle modifications and were disappointed; the fix was setting the expectation correctly in the Instructions panel from day one.
Second, the multi-location routing required iteration. Several operators in the sample reported the bot occasionally directing a guest to the wrong location, particularly when the guest asked for "the closest one" without specifying which neighbourhood they were in. The fix was to teach the bot to ask the guest's neighbourhood or zip code before routing, rather than guessing. This took two to three rounds of Instructions-panel tuning across the first three weeks.
Third, one operator in the sample had a stale knowledge-base issue. The bot continued telling guests that a since-closed location was open for three weeks after the closure, because the operator forgot to update the location spreadsheet and forgot to re-crawl the site after pulling the closed location's page. The fix was procedural: the operator now updates the location spreadsheet within 48 hours of any location-status change, and the deployment checklist now includes a re-crawl trigger. We have flagged this directly in our restaurant-specific setup docs.
Methodology
We collected the numbers via structured interviews with each of the 9 chain operators across April and May 2026, asking them to compare their pre-deployment baseline (a 90-day window before ChatRaj went live) to their post-deployment 90-day window. Operators pulled the baseline numbers from their OpenTable or Resy dashboards, their catering CRM, their phone-system call logs (where available), and their site analytics. We did not independently audit any individual chain's numbers. The ranges are deliberately wide to absorb the measurement noise that comes with self-reported data and with the inherent volatility of restaurant traffic.
The sample is over-indexed on regional operators (4 to 18 locations) and under-indexed on national chains (over 50 locations) and on single-location independents. The cuisine mix skews toward Indian, Italian, Mexican, and modern American; we did not have a sushi or steakhouse operator in the sample. The geography is North-American (7 United States, 2 Canadian). We are explicit about this skew so readers can decide whether their concept resembles the sample.
How to read the numbers honestly
If you are an operator evaluating this pattern, here is how to think about whether the ranges transfer to your concept. The composite framing means we report what was typical, not best-case. If your concept matches the modal sample operator (regional, 4 to 18 locations, mix of dine-in and catering, average check between 18 and 45 dollars), the ranges should be reasonably transferable. If you run a single-location independent or a 200-location national chain, the ranges will not transfer cleanly. If your catering mix is below 5 percent or above 30 percent of revenue, your catering-lift number will sit outside the 12 to 22 percent band.
The honest expectation is to plan for a 30-day tuning window before the bot is operating at steady state, a 90-day window before the metrics stabilise, and a quarterly review of the per-location knowledge layer to keep it accurate as menus, hours, and locations evolve.
Reproducing the playbook on YOUR restaurant
The reproducible playbook the composite case study points to has 7 concrete steps, documented in the install section below. The short version is: train one bot at the brand level on the chain site, layer per-location data via a structured spreadsheet, wire reservation handoffs to the existing OpenTable, Resy, or Square for Restaurants instance, wire catering inquiries to the existing catering CRM via webhook, set explicit Instructions-panel rules for the modification and routing edge cases above, run an end-to-end test from each location's perspective before going live, and review the Unanswered tab weekly for the first month to catch boundary cases. Operators in the sample who followed this sequence reached steady state within the 90-day window described above.