# 06 — After-hours behaviour (restaurant-v1)

**Why this file exists separately:** after-hours is not a degraded mode — it is the *reason the client is paying us*. The missed-call audit that sells the pilot (`docs/SALES_PLAYBOOK.md` §1) is a recording of their phone ringing into nothing at 9pm. If our after-hours behaviour is a polite "we're closed, call back tomorrow", we have sold them a nicer voicemail.

QA case 9 tests this. `docs/SPEC.md` §3.1: *"After-hours: take reservation for future slots; messages for the rest; morning summary to owner."*

---

## What "after hours" means

Driven by the **business-hours schedule** in the platform (from knowledge pack §B), not by the prompt. Three states:

| State | When | Behaviour |
|---|---|---|
| **Open** | Inside opening hours | Full flows, transfers available if inside *staffed* hours |
| **Closed** | Outside opening hours | This document |
| **Open but unstaffed** | Open, but the transfer number's staffed hours have ended | Full booking flows; escalation uses the *after-hours* path (message + instant alert) |

The third state is the one that gets misconfigured. **Opening hours and staffed hours are different fields** and usually different times — the kitchen is open until 11pm; nobody is answering the manager's mobile at 11pm. Knowledge pack §G captures them separately for exactly this reason.

## What still works when closed

| Capability | Closed behaviour |
|---|---|
| **Booking a future slot** | ✅ **Fully works.** This is the point. A caller at 11pm booking Saturday lunch gets a real booking in the real calendar with a real confirmation |
| Booking for *today* | Only if the client's same-day cut-off (knowledge pack §D) has not passed. Otherwise → next available |
| Questions from the knowledge pack | ✅ Works — hours, location, parking, price range, menu link |
| Reschedule / cancel | ✅ Works |
| Takeaway intent | ⚠️ Capture only, and say so plainly: "The kitchen's closed now — I'll pass this to the team and they'll call you when they open at {{OPENING_TIME}}." Never imply food is coming |
| Message capture | ✅ Works |
| **Warm transfer** | ❌ Nobody to transfer to. Falls to structured message + instant alert |
| Complaints | Captured, `intent: complaint`, **instant alert** regardless of hour — the owner decides whether to wake up for it, not us |

## The after-hours greeting

Variant C from `01-identity-and-tone.md`:

> "Thanks for calling {{BUSINESS_NAME}}, this is {{ASSISTANT_NAME}}, the automated assistant — {{DISCLOSURE_CLAUSE}}. We're closed right now, but I can still take a reservation or a message. What can I do for you?"

Two things it does deliberately:

1. **States the closure immediately** — a caller who thinks they reached an open restaurant and discovers otherwise three turns in is a worse experience than voicemail.
2. **States what is still possible in the same breath** — "closed" alone invites a hang-up. "Closed, but I can still book you in" keeps the booking.

If asked when they open, the assistant gives the **next** opening time from the schedule, not a generic list of hours.

## The morning summary

Per `docs/API_CONTRACT.md` §4, generated from call-ended webhooks by the **shared n8n flow, parameterized per client — never a bespoke flow per client**. That rule is a kill-criterion defence: bespoke flows are how a 2h/month client becomes a 10h/month client.

Delivered as one WhatsApp/email message at a time the owner chooses (default: 30 minutes before opening — actionable, not just informational):

```
{{BUSINESS_NAME}} — overnight, {{DATE}}

Bookings taken          3   (Sat 8pm ×4 · Sun 1pm ×2 · Sat 9:30pm ×6)
Messages needing you    1   ← Karim, 01711-xxxxxx, asking about a birthday setup
Complaints              0
Calls answered          7
Minutes used            14  (of 500 this month)
```

- **Messages needing action come first**, with the phone number in the message itself so the owner can act from the notification without opening anything.
- A complaint, if present, is at the very top with the urgent flag — and it will already have been sent as its own instant alert hours earlier. The summary is a second sighting, never the first.
- Minutes-used is in the daily summary on purpose: it makes the cap visible continuously, so the upsell conversation (`docs/SALES_PLAYBOOK.md` §6) is never a surprise. `docs/PRICING.md` §1: *"you'll see it coming in your weekly report."*

## Configuration checklist

☐ Business hours entered with the correct weekend pattern (BD: Fri · Gulf: Fri–Sat · US: Sat–Sun)
☐ Staffed hours entered **separately** from opening hours
☐ Timezone set once, matching knowledge pack §A
☐ Same-day booking cut-off configured
☐ Holiday closures for the next 90 days loaded
☐ Morning summary time agreed with the owner
☐ QA case 9 run with hours temporarily shifted, then hours restored **and re-verified**