# 03 — Call flows (restaurant-v1) **Source of truth:** `docs/SPEC.md` §3.1. These flows are identical for every restaurant client. Client-specific values come from the knowledge pack. **The universal rule:** *every call ends with one of exactly four outcomes* — a **booking**, a **message taken**, a **transfer**, or a **clear answer**. There is no fifth. If the assistant cannot reach one of the four, it falls to message capture. QA's global expected result checks this on all 20 calls. --- ## Flow 1 — Reservation (the money flow) **Budget: ≤ 8 conversational turns** (SPEC §3.1). A turn = one assistant utterance + one caller reply. ``` caller states booking intent ↓ T1 ask party size + day/time TOGETHER ──── (skip any part already given) ↓ T2 check_availability ├── free → offer the slot └── busy → offer ≥ 2 real alternatives ← QA case 2 ↓ T3 caller picks a slot ↓ T4 ask name + phone TOGETHER ↓ T5 read back once: name, party size, day, time ↓ T6 create_booking ├── success → confirm + send_confirmation └── failure → "I'll have someone confirm by message" + capture_lead ← never silent ↓ close: thank, state the confirmation is on its way, offer nothing more ``` ### Rules that keep it inside 8 turns 1. **Harvest everything the caller volunteers.** If they open with *"It's Karim, table for four, Friday nine pm"*, the assistant has party size, day, time and name already. It asks only for the phone number. Re-asking for a detail already given is QA case 15 and a straight fail. 2. **Pair the asks.** Party size + time is one turn. Name + phone is one turn. Never four single-field questions. 3. **Confirm once, at the end.** Not after each field. 4. **Never ask for an email.** Confirmation goes by SMS (US) or WhatsApp (BD/Gulf). 5. **Never ask why they're coming** unless the client's policy needs it (private room, set menu). Curiosity costs turns. 6. **Do not upsell.** Restaurants are not salons; SPEC gates the upsell line to salon/spa and only on owner opt-in. ### Availability behaviour - The assistant offers **only slots the tool returns as free**. It may not reason about availability, estimate, or say "that's usually quiet". - When the requested slot is busy: name it as unavailable, then offer **two real alternatives** — one earlier, one later where possible. "We're full at eight, but I have seven-fifteen or nine — which suits you?" - If nothing is free that day, offer the nearest free day, then fall to message capture if refused. - **Never say "fully booked"** if the knowledge pack §I says otherwise; some owners require "heavily booked". ### Party size gate If party size > `MAX_SELF_SERVE_PARTY` from the knowledge pack (default 6) → this is not a booking, it is a **large-party escalation** (`04-escalation.md` trigger 3). Do not attempt to book it. Do not check availability for it. ### Special requests during booking Birthday, anniversary, high chair, wheelchair access, outdoor seating, allergy: capture as a **free-text note on the booking**, acknowledge neutrally ("I've noted that for the team"), and never promise the restaurant will act on it. Allergies additionally follow the allergy rule — state policy, never clear a dish. --- ## Flow 2 — Reschedule / cancel (QA case 14) ``` caller asks to change or cancel ↓ identify by phone number (ask for it; it is the booking key) ↓ find_booking ├── found → read it back, confirm the change, then modify or cancel └── not found → "I can't find it under that number" → capture_lead → message to staff ↓ send_confirmation of the change ``` - **Never create a second booking to effect a change.** Modify or cancel-then-create — one event must remain. Orphan and duplicate events are a QA case 14 failure and a real-world double-booking. - A cancellation inside the client's cancellation window: state the policy in the owner's own words from the knowledge pack, do not negotiate it, do not waive it. Any pushback → escalation trigger 4 (booking dispute). --- ## Flow 3 — Questions from the knowledge pack (QA cases 11–12) ``` caller asks a question ↓ is the answer in the knowledge pack? ├── YES → answer plainly, one sentence, offer the menu link if menu-related └── NO → "I'm not sure about that — let me take your number and someone will confirm." → capture_lead ``` This is the flow with the lowest tolerance in the entire QA sheet. **Case 11 requires 5/5 correct on knowledge questions; a single invented fact fails the whole 20-call sheet, not just the case.** Case 12 requires the assistant to decline a plausible-sounding question that is *not* in the pack. The pressure that produces hallucination is a caller who sounds certain: *"You do keratin treatments, right?"*, *"Your Sunday brunch is 1,200 taka, isn't it?"* The prompt must make "I'm not sure" cheaper than agreeing. **Menu questions specifically:** answer the pack-approved facts (price range, vegetarian, halal), then offer to send the menu link. Do not read the menu aloud — it burns minutes and invites the assistant to improvise dish names. --- ## Flow 4 — Takeaway intent (v1: capture only, no POS — SPEC §3.1) ``` caller wants to order takeaway ↓ "I can take your order down and send it straight to the kitchen team — they'll call you back to confirm and take payment." ↓ capture: name, phone, items as spoken, pickup-or-delivery, requested time ↓ capture_lead → staff WhatsApp, INSTANT delivery ↓ close: "That's with the team now — they'll call you back shortly to confirm." ``` - The assistant **does not** quote a total, confirm stock, promise a time, or take payment. Payments over the phone are out of scope (`docs/SPEC.md` §5). - Items are captured **as spoken**, verbatim-faithful. The assistant does not "correct" a dish name into something from the menu — a wrong correction is worse than an odd transcription, because staff can read an odd transcription. - If the client does not do takeaway (knowledge pack F), this flow is replaced by a plain "we don't do takeaway" and, if they do delivery via a platform, the platform's name. --- ## Flow 5 — Message capture (QA case 10 — the universal fallback) Triggered by: anything the assistant cannot do, any failed tool, any out-of-knowledge question, any caller who wants to be called back. ``` "I can't help with that one myself, but I'll take your details and make sure the right person gets it." ↓ capture: name, phone, what it's about ← in the caller's own words ↓ capture_lead → destination per API_CONTRACT §3 ↓ tell the caller WHEN to expect a response (from the knowledge pack, not invented) ``` - **Verbatim-faithful.** The summary field may be a two-sentence paraphrase; the subject must reflect what the caller actually said. QA case 10 checks this against the recording. - Read back the phone number digit by digit. It is the single field whose corruption makes the whole message worthless. - Never end a message-capture call without saying what happens next. --- ## Flow 6 — Silence, noise, and broken calls (QA cases 16, 18) | Situation | Behaviour | |---|---| | Caller says nothing | Re-prompt twice ("Hello? I can't hear you — are you still there?"), then close politely and end. **Never hold an open line**; it bills by the minute | | Heavy background noise / strong accent | Confirmation loops: "Just to confirm — Friday at nine, party of four?" Confirm rather than guess | | Phone number unclear | Read it back digit by digit and ask for a correction. Two failed attempts → ask them to spell it or take the call to message capture | | Caller hangs up mid-booking | **No phantom booking.** If name + number were captured, log a partial lead; otherwise nothing | | Caller talks over the assistant | Stop speaking immediately, respond to what they said. Do not finish the sentence, do not restart it | --- ## Flow 7 — After hours See `06-after-hours.md`. Summary: bookings for future slots still work; everything else becomes a message; the owner gets it in the morning summary.