What should an AI receptionist handle, and when should a human take over?

1. Decide what the receptionist is allowed to do

Before choosing a voice, list the calls your business receives. For each one, ask: does the answer come from an approved fact, does it require a system action, or does it need someone’s judgement?

We would use three levels of permission:

• Answer: explain current opening hours, describe an agreed service or provide an approved next step. Someone must own the information and keep it current.
• Capture: record the purpose of an enquiry and the minimum callback details. Make clear that a request has been received, not that work has been accepted or an appointment confirmed.
• Act: make a booking or update a record only through a deliberately connected system, within explicit permissions, with the result checked before confirming it. Verify the caller’s authority before accessing or changing an existing customer record.

Reading availability is not the same permission as changing a booking. Explaining a published price is not permission to negotiate a discount. Treat those as different jobs rather than assuming a conversational interface can do both.

2. Define the moments a person takes over

The handover rules should be written before launch. OpenAI’s practical guide to building agents identifies repeated failures and high-risk actions as reasons to involve a human. For a receptionist, we would turn that principle into explicit triggers:

• The caller asks to speak to a person. Do not make them argue with the system first.
• The request is still unclear after a limited clarification attempt, or the caller keeps correcting important details.
• A complaint, disputed charge, exception or sensitive circumstance needs someone authorised to exercise judgement.
• The request asks for advice or a decision outside the receptionist’s agreed role.
• The required information is missing, a connected system is unavailable, or the result of an attempted action cannot be verified.

These are proposed operating rules, not a universal standard. An urgent or safety-related call also needs an agreed response appropriate to the business, rather than improvised advice from a general-purpose receptionist.

Sources: OpenAI: A practical guide to building agents, human intervention (page 31)

3. Make the handover real, not just reassuring

“I’ll pass that on” is not a complete process. Decide who receives the enquiry, what they need to know, how they notice it and what happens if nobody is available.

A useful handover note might contain the caller’s preferred contact method, a short description of the request, what has already been checked and what remains unresolved. It should not include an unnecessary transcript full of personal detail.

Distinguish a transfer attempt from an answered transfer, and a callback request from a callback commitment. If no person is available, explain that honestly and offer the actual alternative. Only promise a response time if the business has agreed to it and can support it.

This is our practical application of NIST’s voluntary AI Risk Management Framework, which calls for defined human oversight and clear responsibility for intervening when a system diverges from its intended use.

Sources: NIST: AI Risk Management Framework Core, MAP 3.5 and MANAGE 2.4

4. A booking example: request is not confirmation

Imagine a caller asking a service business for an appointment next Tuesday. This is an illustrative scenario, not a No Staff deployment.

If the receptionist can only take messages, the outcome is an appointment request for the team to review. It should not say the caller is booked in.

If booking has been authorised and connected, the receptionist should check the relevant availability, confirm the important details with the caller, attempt the booking and check the saved result. If the system times out, it should report that the booking is unconfirmed and follow the agreed recovery path. Check for an existing booking before retrying so an uncertain result does not become a duplicate.

The distinction is simple: what the receptionist says should match what the business system actually did.

5. Be clear about AI and careful with information

Introduce the system as AI rather than letting a natural-sounding voice imply it is a person. The Australian privacy regulator, the OAIC, recommends clearly identifying customer-facing AI tools. Its guidance also addresses collecting only personal information reasonably necessary for the relevant purpose where the Australian Privacy Principles apply.

Our design recommendation is to collect enough information to help, not everything a caller is willing to share. For a simple callback, detailed financial, health or identity information may be unnecessary. Do not make passwords, full payment-card details or identity documents part of a general receptionist enquiry flow.

Before a pilot, decide whether audio or transcripts are retained, who can access them, which providers receive information and how long it is kept. Recording and transcription need a separate privacy and legal review for the actual circumstances; an AI announcement alone does not settle those questions.

Sources: OAIC: Guidance on privacy and the use of commercially available AI products

6. Test the awkward calls, not just the polished demo

A pleasant conversation is only one part of a working receptionist. OpenAI’s current voice-agent guidance recommends testing both the conversation and the completed task, including whether spoken confirmations match the final state of the connected system.

For an initial test plan, use invented details and check:

• Names, dates and numbers that are misheard or corrected mid-call.
• Background noise, interruptions and a caller changing their mind.
• A request for a person, including when the transfer cannot be completed.
• An unavailable calendar or a timeout after a booking attempt.
• Questions outside the approved information and requests to ignore the receptionist’s rules.

Write the expected outcome before each test. Listen to the call and inspect the resulting message, booking or handover. Record failures as well as successes. Real recordings, if later used, need appropriate permissions and handling; do not quietly turn ordinary customer calls into test material.

Sources: OpenAI: Voice agents, evaluating the conversation and completed task

The aim is a better front door, not a barrier to people

We would judge a receptionist by whether enquiries reach the right next step, details are accurate and staff receive something useful to work with. The share of calls handled without a person is not a sufficient success measure on its own.

That fits how we think about No Staff: software should strengthen the team, not hide it. Start with a narrow, useful role. Make uncertainty visible. Give a person a clear way to take over. Expand only when the evidence supports it.