Talk track

1. The generic shape is 'something scheduled breaks, the organisation notices before the customer does, and reaches out with options' — the sibling story to scenario 1's 'something is on its way and there's a paid option to speed it up.' Together they're the same proactive-contact platform claim from two different directions: expedite and recover.
2. The fan-out is the technical depth story: flipping one flight to delayed fires a single Postgres trigger that writes disruption_events, rebook_options, and notifications in one transaction — atomically, not via a queue or an edge function that could fail independently and leave the customer notified but the booking data stale, or vice versa. Say this plainly if asked how reliable the notification path is: it's a database guarantee, not an application-level one.
3. Walk the actual sequence live: ops console flips the flight, the mock handset lights up, the passenger taps the deep link, and the agent opens already knowing the booking via get_booking and get_disruption — no 'what's your booking reference' small talk. That's the same 'agent opens with context' story as every scenario, just with the added beat of the organisation reaching out first.
4. confirm_rebooking is the Workflow-gated action here — same deterministic-gating pattern as scenario 1's shipping upgrade, now on a rebooking decision instead of a paid upgrade. Each rebook option carries a pre-written route_summary rather than something composed at runtime, because a flight has an origin and destination and a telco engineer visit doesn't — call that out if asked how the telco skin differs.

Discovery questions

• When something you've scheduled for a customer changes today — a delay, a missed slot, a cancelled visit — who notices first, you or the customer?
• What's your current time-to-notify once your own systems know something has gone wrong, and how many separate systems does that notification pass through?
• How do you handle the case where the fix requires a real decision from the customer (rebook, reschedule, refund) rather than a one-way notification?
• What's the actual cost to you today of a customer who calls in about a disruption you already knew about but hadn't told them yet — in inbound contact volume, and in retained trust?

Objection handling

If a tool call fails or times out

1. The ops console flip doesn't produce a notification (handset stays dark): before assuming the trigger failed, check the events table for disruption.detected — if the row is there but the handset didn't update, it's a Realtime subscription issue, not a data issue, and the known fix is a fresh page load rather than re-flipping the flight (re-flipping can leave the demo in a confusing half-reset state).
2. get_rebook_options returns nothing: don't let the agent invent an option — have it acknowledge it's still pulling options and check the rebook_options table directly for that disruption_event_id while narrating what should be there.
3. confirm_rebooking fails after the passenger has verbally chosen an option: same rule as every other gated action in the kit — don't re-ask for the choice, acknowledge the delay, retry once, and if it still fails, confirm the rebooking from the ops console and say out loud that's what happened. This is the scenario CLAUDE.md calls the strongest moment in the demo — a visibly broken confirm here is the single worst place in the whole kit for a silent failure, so over-narrate rather than under-narrate it.