Initial IAExplore the service ↗
← All resources

Working methods · Article

AI receptionists: which calls should they handle, and when should a person take over?

Which calls should an AI receptionist handle? Separate information, request collection, confirmed bookings and successful transfers to a person.

Verify the completed action, human contact or fallback after failure.

An AI receptionist can explain opening hours, collect a request or route a call. It should confirm a booking, price or service visit only when it has the information and authority required to do so. Start with a frequent type of call whose outcome is easy to verify.

The first selection criterion is not how natural the voice sounds. It is how the call ends: did the caller receive accurate information, a completed action or contact with an available person?

Taking a message does not confirm an appointment

Consider a fictional maintenance business. A customer calls because equipment has stopped working. The assistant collects contact details and a description of the problem. It cannot see a confirmed slot in the schedule.

“A technician will come tomorrow morning” would be an invented promise. “Your request has been sent” is accurate only if transmission succeeded. If it failed, the system needs to offer another route rather than end the call as though everything were settled.

The permitted wording should reflect that difference. “I can record your preference for tomorrow morning” does not mean “your appointment is confirmed.” The caller must understand which event has actually occurred.

Choose calls according to the action required

Call type Possible AI role Decision that needs a clear owner
Hours, address, service area Answer from approved information Who keeps that information current?
Callback request Collect and forward useful details How is successful receipt verified?
Appointment booking Offer and reserve an authorised slot What confirms the booking?
Complaint or unusual situation Recognise the limit and route the call Who takes over, and when are they available?
Emergency outside the service’s scope State the limit and use a predefined appropriate route Do not imply suitable help is already being arranged

Information and request collection are often simpler starting points. They reduce irreversible actions, but contact details, routing and message receipt still need checking.

If calls go unanswered because nobody can handle callbacks, automating reception does not solve the capacity problem. Establish who will act on messages first. For a few simple calls, also compare voicemail with an organised callback process: a longer conversation adds little if it produces the same incomplete message.

Design the transfer separately

“Callers can speak to a person” is a fragile promise if the destination rings unanswered. Define what happens outside opening hours, after several rings and when the recipient declines the call.

Some tools support several transfer conditions. Aircall documents transfers requested by callers or following specified information collection, depending on configuration. An available feature does not establish that your particular route is configured correctly. Aircall AI Voice Agent configuration.

Provide an understandable outcome: a person answers, a callback request is successfully recorded, or the caller receives another contact method. Avoid loops where someone repeatedly asks for an adviser and returns to the same menu.

Allow people to choose another channel too. A misunderstood name, accent or noisy line should not turn a simple request into an interrogation.

Write the call’s ending before its greeting

Here is a fictional callback sequence. The assistant confirms the number and reason, attempts to send the request and waits for the result. There are three possible endings:

Observed event Appropriate wording Wording to avoid
The request was successfully recorded “Your callback request has been recorded.” “We will call within ten minutes” without an approved commitment
A person actually answers the transfer Briefly introduce the reason to the receiving person Calling a transfer successful as soon as ringing starts
Neither recording nor transfer succeeds Explain the failure and offer the defined backup contact route “Everything is being taken care of.”

Three call outcomes: a confirmed action, a person actually reached, or a disclosed failure with another contact route.

Caller ID alone does not establish permission to access an account. Sharing private information or changing an order requires suitable identity and authorisation checks. Otherwise, limit the assistant to taking a request without disclosing account contents.

During initial trials, pay attention to silence and interruptions as well. If every correction makes the system restart its entire question, a “handled” call may be more frustrating than ordinary message-taking. Do not judge only the transcript: listen to the authorised test call’s progression.

Collect information that serves the request

A callback may need only a name, telephone number and reason. Routinely collecting a full address, date of birth or lengthy history increases the information requiring protection without necessarily improving service.

Clearly identify the virtual assistant. If calls are recorded, provide the appropriate information. In France, the CNIL says customers must be informed about matters including the recording’s purpose and their rights; an announcement at the start of the call can point to fuller information elsewhere. CNIL guidance on informing callers.

Needing to forward a summary is different from needing to retain all the audio. Establish what is useful, who can access it and how long each kind of information should remain available.

Six calls to try before making the number public

Use a test number and fictional details. Call from an external telephone, then inspect where the request actually arrives. These are proposed test scenarios, not completed experiments.

Scenario Expected observable outcome Reason to hold the launch
“I want to speak to someone” Human routing starts without requiring the full questionnaire The caller returns to the menu or must repeat the request
The recipient does not answer The configured timeout leads to an explained, usable fallback Endless ringing or a transfer reported as successful
The caller corrects a digit in their number The corrected number is read back and saved at the destination The message retains the old value
The requested slot is unavailable No booking is announced without confirmation from the schedule A promised appointment does not exist in the schedule
Saving the message fails The assistant discloses the failure and gives the backup contact “Your request was sent” despite the error
The caller interrupts or there is background noise The assistant accepts a correction or offers another channel It restarts repeatedly or invents what it did not understand

Aircall states that its simulator does not test real transfers or integration logging. A convincing simulated conversation therefore does not replace this complete journey. Aircall test coverage.

Prepare fallback wording too. Adapt this example: “I could not send your request. You can reach our team at [approved contact]. No appointment has been confirmed.” Replace the contact before testing; mention a callback only when the request was actually recorded.

Measure the outcome and the work still pending

Separate attempted transfers from conversations actually taken over by a person. For callbacks, distinguish request received, owner assigned and callback completed. A recorded request can still go unanswered.

Here is a fictional calculation: out of 20 test calls, 8 require transfer and 6 reach a person. That is 6/8, or 75% of required transfers, not 6/20. This small set does not predict production performance; the two failures should primarily prompt examination of the fallback offered.

For each trial, record the time, scenario, expected outcome, observed outcome and evidence in the schedule or message system. Repeat the relevant scenarios after changing routing. If the team cannot process incoming requests, narrow the scope before increasing the number of calls handled by AI.

Sources checked on 16 October 2026. The example is fictional; no voice-agent trial or customer results are claimed.