Start with a small inbound job
A sensible first scope might collect a routine callback request, confirm a service location and identify what the caller wants help with. The assistant can prepare a structured record so the person who returns the call does not need to start from nothing.
Define the approved questions and the claims the assistant may make. If it cannot read authoritative availability and complete the required reservation action, it should collect a preferred time and call it a request. Fluent speech does not turn a preference into a booking.
Keep high-consequence decisions with the appropriate person. The proposed assistant should not improvise clinical, legal or financial advice, make an unapproved price commitment or pretend to have emergency-service capability. Agree an appropriate escalation and fallback before considering a live pilot.
Have the caller confirm the details that matter
Spoken information can be incomplete or misheard. Ask the caller to confirm the relevant name, service address and requested window before preparing the handover. Keep uncertain details labelled rather than silently correcting them to something plausible.
If the caller changes the request, preserve the change explicitly. In the fictional exchange, a general maintenance enquiry becomes a report that access to the site is blocked. The ordinary visit-request path stops and the assistant offers a human handover under the hypothetical business's policy.
The receiving person needs the caller's actual words, confirmed facts, uncertainties and the reason for transfer. A long polished summary can hide the important change. Use a compact request packet with references back to the relevant transcript excerpt if transcripts are part of the approved design.
Design the unanswered transfer as carefully as the answered one
A transfer is an attempted connection until the receiving person answers. Twilio's documented Dial operation can connect an active caller to another party and reports outcomes that a call flow can handle. It does not guarantee that someone is available to receive the call.
The design needs an explicit path for busy, unanswered or failed transfers. That may be an approved callback request with the caller's agreement, an existing business fallback or another authorised destination. Do not let a failed connection become a claim that a human has received the request.
When a required system is unavailable, say which part cannot be confirmed. The fictional flow can retain a draft for review if the agreed storage path is available, but it does not claim a confirmed appointment or a successful CRM update. Unknown state stays unknown until the authoritative record can be checked.
Set the information and recording boundaries before a pilot
Decide whether calls would be recorded, whether transcripts would be kept, which providers would process the audio and who could access the resulting records. A recording is not necessary merely because the interface is voice. Do not enable collection just to make an impressive demo.
Your organisation needs to settle the applicable notification, consent, privacy and retention requirements for its own context before a live implementation. We do not claim that a particular opening line, Australian number or hosting choice makes the system compliant. Keep the data path and retention decisions visible in the scope.
Use synthetic calls and fictional records for initial evaluation. Test interruptions, repeated corrections, unclear speech, a changed request and a missing dependency. Any later use of real customer information needs the agreed permissions and controls. Agree the evaluation boundary before introducing real calls.
Check the call path before committing to a build
A discovery conversation should establish call types, opening hours, transfer destinations, allowed statements and the exact systems involved. Then confirm provider capabilities, account permissions, number requirements and the cost of a representative call path. Those checks establish the provider costs and implementation scope before we quote.
Evaluate whether callers can complete the narrow task and whether the receiving team can trust the handover. Count abandoned paths, corrections and review work. Keep the ability to fall back to the business's existing phone process during any separately approved pilot.
Only then decide whether a live build is worth scoping. Voice may be unnecessary if a simpler form, clearer callback process or better internal handover solves the problem. Start with a feasibility discussion about the task and the people who would rely on its result.
Before you decide
Your questions, answered
Do you currently sell a packaged AI receptionist?
No. Voice would be a custom engagement. We would first establish feasibility, scope, permissions, provider costs and acceptance for your call path.
Can I listen to the call shown here?
No call was recorded or generated. The transcript is original fictional text showing a possible confirmation and human-handover boundary.
Can the assistant confirm appointments?
Only a separately scoped implementation with authoritative availability, permitted reservation actions and confirmed saved results could do that. The example collects a request and explicitly leaves the appointment unconfirmed.
What happens if the human does not answer?
The design needs an agreed unanswered-transfer path. It must not say the person received the call. A callback request or another approved fallback depends on your business's rules and the systems available.
Sources and checks
References support the specific facts discussed above. Check dates show when each source was consulted. Vendor features and rules can change.