Objective
What you're building
A conversation flow mapped on paper first, then a system prompt implementing it, tested against at least 5 caller scenarios that deliberately include off-script behavior — not just the happy path of a caller who answers every question exactly as expected.
Map the flow before writing any prompt
greeting
│
▼
intent detection ──┬── "book an appointment" ──▶ collect details ──▶ check calendar (Lesson 4)
├── "ask a question" ────────▶ knowledge base lookup (Lesson 5)
└── "request a callback" ────▶ collect name/number ──▶ log for follow-up
│
└── unclear/off-topic ────────▶ clarify once, then offer callback option
Voice intent detection is harder than text intent detection, and that's not a minor footnote
A text chatbot has clean, typed input to classify. A phone caller mumbles, talks over themselves, says "uh, yeah, I guess I wanted to, um, ask about—" and changes their mind mid-sentence. Your conversation design needs an explicit path for "I'm not sure what they want yet, ask one clarifying question" rather than assuming intent is always immediately clear, which is a luxury text interfaces have that voice mostly doesn't.
Writing the phone-specific system prompt
You are the AI receptionist for Apex Consulting. Your job:
1. Greet callers warmly and briefly -- this is a phone call, not an email
2. Determine intent: booking, question, or callback request
3. For booking: collect name, phone number, and preferred day/time before checking availability
4. For questions: use the knowledge base; if you don't know, offer a callback instead of guessing
5. Speak in short sentences. Avoid lists, jargon, or anything hard to follow by ear alone
6. If the caller is unclear, ask ONE specific clarifying question -- don't guess, don't ask multiple questions at once
7. If you truly can't help, offer to have someone call them back
Rule 5 matters more in voice than almost anywhere else in this whole curriculum: a bulleted list read aloud is nearly impossible to follow, and jargon that reads fine in text can sound completely opaque spoken quickly by a TTS voice. Every instruction here is voice-specific, not a generic "be helpful" system prompt borrowed from a text chatbot.
Test against real messiness, not a clean script
If you only test with yourself reading a script, you haven't actually tested this
Run at least 5 scenarios: a caller who answers everything cleanly (the easy case), one who mumbles and needs a repeat, one who changes their mind mid-booking, one who asks something totally off-topic, and one who goes silent for a few seconds. Each of these is a real, common phone behavior — if your conversation design only handles the first, it will feel broken to most real callers, not just edge-case ones.
During testing, a caller says "actually, never mind about the appointment, can you tell me your hours instead?" mid-way through the booking flow. Your assistant is designed with rigid, linear booking steps and doesn't handle this. What's the fix?
People change their minds mid-conversation constantly — this isn't an edge case, it's normal human behavior on a phone call. A rigid, linear flow that can't gracefully redirect when the caller's actual need shifts will feel broken to a meaningful fraction of real callers. The system prompt needs explicit instruction to recognize and follow a topic change, not force the caller back onto a script they've already abandoned.
What you're building today
conversation_flow.md (the mapped diagram) and the phone-specific system prompt implementing it — tested against 5 scenarios including mumbling, mid-conversation topic changes, off-topic questions, and silence, with the prompt iterated based on what actually happened in each test call.