Implementation Guide
How to Write Call Scripts for an AI Receptionist
A good AI call script is not a word-for-word monologue. It is a set of instructions describing what the receptionist must find out, what it may say, what it must never attempt, and what a finished call looks like.
Scripts, or instructions?
Write instructions, not a screenplay. Fix the parts that must be identical on every call, such as the greeting, the business name, confirmation wording and the closing, then describe the rest as goals: establish what the caller needs, capture these details, reach one of these outcomes.
Rigid scripts break the moment a caller answers two questions at once or asks something in the wrong order, which real callers do constantly. Instruction-led design handles that naturally while keeping the language and boundaries under your control.
Everything you write should be traceable to a business outcome. If a line does not help book an appointment, answer an enquiry, qualify a lead, route a call or record an outcome, it is decoration and it lengthens the call.
The six parts of a call
Write each enquiry type against this structure. It keeps calls short and makes gaps obvious.
Greeting
Business name, a brief offer of help, and clarity about who the caller has reached. Keep it to one sentence; long greetings make callers interrupt.
Intent
Find out what the caller wants in their own words before offering options. Menu-style questions belong only where the enquiry types are genuinely distinct.
Qualification
Ask only what changes the outcome: new or existing customer, service required, location, urgency, preferred timing. Every additional question costs you completions.
Action
Book, answer, transfer, take a callback or log an enquiry. Each enquiry type should have one primary action and one defined fallback.
Confirmation
Read back the details that matter: name, contact number, date, time, location and what happens next. Confirmation is where most avoidable errors are caught.
Close
State the next step plainly, including who will contact the caller and roughly when, then end. Do not add offers the caller did not ask for.
Writing for Singapore callers
Language handling is a design decision, not an afterthought. Decide which languages you will genuinely support end to end, and what happens when a caller uses one you have not configured.
Language and code-switching
Many callers switch between English, Mandarin, Malay, Tamil and dialect within a single sentence, and older callers may prefer dialect entirely. Decide in advance whether an unsupported language triggers a transfer, a callback or a message, and say so clearly to the caller rather than persisting in English.
Local detail
Write prompts that match how people here actually give information: block and unit numbers, postal codes rather than full street addresses, MRT stations as landmarks, and mobile numbers as the default contact. Ask for a postal code and unit rather than a long spoken address.
Names and spelling
Singapore names vary widely in structure and spelling. Confirm by reading back rather than guessing, and capture the name as given instead of forcing it into first and last name fields that do not fit.
Calendar realities
Public holidays, eve-of-holiday hours and seasonal peaks change what the receptionist should offer. A script that promises a next-day callback during a long weekend creates a complaint rather than a lead.
Phrasing that works, and phrasing that does not
| Situation | Weak phrasing | Better phrasing |
|---|---|---|
| Opening | An extended welcome listing services before the caller speaks | Name the business, then ask how you can help |
| Capturing a number | Asking for a contact number with no read-back | Ask, then repeat the number digit by digit for confirmation |
| Offering times | Asking an open question about preferred timing | Offer two specific available slots, then widen if neither suits |
| Unknown answer | Guessing, or repeating the question differently | Say plainly that a colleague will confirm, and capture the question verbatim |
| Pricing | Quoting a figure the business has not authorised | Explain how pricing is structured and route the quote request to a person |
| Ending | Closing without stating the next step | State who will call back, on what number, and in what timeframe |
What must never be scripted
Some subjects must leave the automated flow immediately, no matter how the caller phrases them and no matter how convenient a scripted answer would be. These are fixed exclusions rather than settings.
- Any matter concerning an individual child, including safeguarding concerns
- Clinical triage, symptom assessment or advice on whether to seek treatment
- Security incidents, threats, or reports of harm
- Allergen confirmation and food safety assurances
- Callers in distress or expressing crisis
- Grievances, disciplinary matters and personal HR issues
- Regulated legal, medical, financial or immigration advice
Write the exit, not the answer. For each exclusion, script a short acknowledgement and an immediate route to a person. The receptionist should not attempt reassurance, assessment or advice, and it should never imply that the matter has been resolved.
The same principle applies to commitments. Do not script promises about prices, refunds, availability, timelines or outcomes that your business has not authorised, because callers will reasonably treat them as binding.
Script review checklist
- Every enquiry type has one primary action and one defined fallback
- No question is asked unless the answer changes what happens next
- Contact details are read back before the call ends
- Unsupported languages have a stated route rather than a repeated apology
- Hard exclusions exit to a human without attempting an answer
- No price, availability or outcome is promised without authorisation
- Wording has been read aloud, not only read on screen
- The greeting is honest about the caller reaching an automated receptionist
- Every branch ends with a clearly stated next step
Once the wording is drafted, put it through structured testing rather than a quick internal read. Our guide to testing an AI receptionist before go-live sets out the scenarios to run.
Frequently asked questions
How long should a call script be?
Long enough to cover your common enquiries and their fallbacks, and no longer. Most businesses find that ten to fifteen well-written enquiry paths cover the large majority of calls, with everything else routed to a person.
Should the receptionist say that it is automated?
We recommend it. Callers usually work it out anyway, and being straightforward from the first sentence sets expectations and reduces frustration when a request needs a person.
Can the wording be changed after go-live?
Yes. Wording changes are configuration changes and apply to every subsequent call at once, which is one of the practical advantages over retraining a team of operators.
How do we handle callers who speak dialect?
Decide the route in advance: transfer to a colleague who speaks it, offer a callback, or take a message. What matters is that the caller is told clearly what will happen rather than being asked to repeat themselves.
Should we ask for a name at the start or the end?
Ask early enough to use it naturally, but after the caller has stated their reason for calling. Leading with a name request before understanding the enquiry tends to feel like a form rather than a conversation.
What if callers ask about price?
Explain how pricing is structured and route the request to a person unless you have authorised specific figures. See the pricing page for how we describe cost structure ourselves.
Related reading
More writing and call design guidance is in the AI receptionist resources library.
See your own enquiries written as a call flow
Send us your three most common calls. We will show the wording, the questions asked and the outcome recorded, so you can judge the fit before committing to anything.