How a call with an AI receptionist works: from the greeting to a calendar entry

Call flow: from connection to calendar entry

A conversation with AI reception isn't one uninterrupted dialogue — it's a sequence of distinct stages, each with its own purpose and rules. Below is the full flow for a booking scenario, which is the most common case in a small service business.

That's six steps, each of which can proceed differently depending on exactly what the client wants and how they respond. Below, I discuss each step separately.

Step 1 — greeting and system introduction

The first few seconds of the conversation define the entire rest of the flow. A client hearing an unknown voice needs to know who they're talking to. This is where the AI Act requirement comes in — the regulation that, since August 2, 2026, imposes specific transparency obligations on providers and users of AI systems that people interact with.

Since August 2, 2026, the AI Act transparency requirements apply: a person using an AI system must be clearly informed that they are interacting with a machine, if it is not obvious. This applies to chatbots, virtual assistants, and automated customer service systems, among others Ministry of Digitization, gov.pl, 03.08.2026.

This means the greeting can't sound like a live human voice — the system must clearly say it's an automated receptionist. An example greeting might be:

"Good day, you've reached [company name]. You're speaking with an automated receptionist. How can I help?"

That's just two or three simple phrases. This isn't the place for lengthy explanations — the system says who it is and immediately invites the conversation. The details of what exactly the system says in the greeting are a separate configuration topic, but the principle is one: the client knows from the first second that they're talking to a machine. They don't have to guess, don't have to ask "are you there", don't have to feel something is being hidden.

What the system does in this step

The system answers the call within one or two rings — there's no room for waiting here, because every second of silence increases the chance the client will hang up. In the background, the system already knows which company this number belongs to, what services they offer, and what their business hours are. If the client calls outside business hours, the system can immediately proceed to the after-hours procedure — but more on that later.

Step 2 — establishing the call purpose

Once the client knows who they're talking to, the next natural step is understanding what they need. Not everyone calls to book an appointment — some want to reschedule, others to cancel, still others have a question about a service or a complaint. The system must distinguish between these intents and handle each differently.

This is where the classification question comes in: "How can I help?" or "Please tell me what you're calling about." The client responds freely, and the system analyzes the response and assigns it to one of the categories.

This distinction is crucial, because the entire rest of the conversation flow depends on it. The system can't assume every caller wants to book an appointment — it must first understand the intent. At the same time, certain categories — complaints, urgent matters, legal or medical questions — inherently require a human, and a good scenario recognizes this immediately, without wasting the client's time on unnecessary questions.

Step 3 — collecting minimum data

Once the system knows what the client needs, it moves to collecting the information necessary to fulfill that need. For a typical booking, these are usually four pieces of data: name, phone number, service name, and preferred time. But — and this is important — the system doesn't ask for everything at once and doesn't ask for unnecessary things.

Why this matters in the context of GDPR: the less data you collect, the less you have to protect and the lower the risk of violation. The system doesn't need the client's home address to book an appointment at a Warsaw salon, doesn't need a PESEL number for a haircut appointment, and doesn't need medical details in a phone conversation — unless those details are essential for the service itself. The data minimization principle (Article 5(1)(c) of GDPR) means you only ask for what's truly necessary.

An example dialogue might look like this:

System: "Please give your name." Client: "John Smith." System: "Thank you. Please give your phone number." Client: "[phone number]." System: "What service would you like to book?" Client: "A haircut." System: "What time works for you? I can offer Tuesday at 5 PM, Wednesday at 10 AM, or Thursday at 2 PM."

That's just four questions, simple, specific, without unnecessary details. The system doesn't ask "would you prefer morning or afternoon", doesn't ask "who referred you", doesn't ask for additional comments — unless the client brings them up themselves.

Example on hypothetical numbers — substitute your own

Let's say your salon handles 300 calls per month. The average conversation with a live receptionist takes 3 minutes. If each of those conversations were 30 seconds shorter thanks to an organized AI scenario, that would save 150 minutes per month — that's over 2.5 hours of work. Those 2.5 hours are time the employee can spend on serving clients who have already arrived, instead of talking on the phone.

Step 4 — calendar and time confirmation

Once the system knows what the client needs and has the basic data, it moves to the most important moment: setting the time. Here, AI connects directly with the company's calendar and sees actual, up-to-date time slots.

The system doesn't propose times that are already taken — the calendar is a single source of truth, with no double bookings, no manual checking whether someone in the meantime took that same slot. That's one of the biggest advantages of automation: eliminating the human error of having an outdated schedule.

Time selection usually proceeds like this: the system proposes two or three available slots, the closest possible, and waits for the client's choice. If none of the proposed times work, the client can suggest their own — the system then checks if it's available and either confirms or informs that time is taken and proposes an alternative.

After selecting a time, the system repeats it aloud to the client: "Do you confirm Tuesday at 5 PM?" This is the confirmation moment that eliminates misunderstandings — the client hears exactly what will be recorded and can correct any error before anything goes into the system.

What happens when there are no available slots? In a well-configured scenario, the client isn't left with an empty promise. The system can propose joining a waitlist, which is used when someone cancels their appointment. Or — if the company has it set up — the system offers a callback when a slot opens that matches the client's preferences. This depends on how the company configured their service flow, but the principle is always the same: the client always knows where they stand.

Step 5 — conversation pace and interaction quality

Speed and fluidity of the conversation have a huge impact on whether the client feels comfortable. A system that stays silent too long after a question, interrupts the client mid-sentence, or itself interrupts too often — discourages them. OpenAI's documentation on voice agents points to specific parameters worth paying attention to when testing and optimizing the scenario.

Comparative tests include task completion, audible response latency, interruptions, and unwanted silence. For each latency metric, you define the observed start and end events and report the median and tail of the distribution OpenAI, Voice agents docs.

What this means in practice: if after a system question the client says "actually, I wanted to...", the system should detect this interruption and allow the client to finish their thought — not cut off the sentence and proceed. Similarly, if the client remains silent for more than a few seconds after a question, the system should react gently — repeat the question or ask if the client is still on the line. These aren't obvious behaviors — each requires deliberate configuration and testing.

What scenario testing involves

Testing isn't about checking once whether it "works." It's about repeatedly running the same scenarios with different variants: booking, rescheduling, cancellation, complaint, "I want to talk to a person," conversation in Polish, conversation in English, conversation in noise, conversation outside business hours. For each variant, you measure: time to completion, number of interrupted sentences, number of repetitions from the client, and whether the conversation goal was ultimately achieved.

The results of these tests allow you to fine-tune parameters: how many seconds of silence is too much, how aggressively the system can interrupt repetitions, when it's better to immediately transfer to a human. This isn't a one-time configuration — it's a continuous improvement process, because client behaviors change too.

Step 6 — transferring to a human

Despite the best configuration, there are situations where the automation doesn't cope or shouldn't make decisions on its own. In such moments, the scenario must anticipate transferring the call to a live employee — either in real time if someone is available, or in the form of a callback with a full summary.

When should the system hand the call to a person:

When the client explicitly asks for it. The simplest rule: if someone says "I want to talk to a live person" or "connect me to someone," the system shouldn't insist on automation.

When a complaint appears. A complaint is a delicate, emotional matter that requires human approach — empathy, understanding context, conflict de-escalation skills. The automation can receive and register it, but shouldn't resolve it independently.

When the topic goes beyond the system's knowledge. If the client asks about something not in the knowledge base — a new service, a special case, a non-standard request — the system should recognize this and transfer.

When an urgent or legal matter appears. In high-stakes domains where a mistake can have serious consequences, OpenAI recommends having a human review the model's outputs before they are used in practice OpenAI, Safety best practices. This is the human-in-the-loop principle — the human in the decision loop.

When the system is uncertain. If speech recognition has failed multiple times, if the conversation context is unclear, if the client is clearly frustrated — better to transfer the call than further deepen the problem.

What the transfer looks like

If an employee is available right now, the system can connect the call in real time — the client hears a brief introduction "please hold on, connecting you to an advisor" and the conversation continues in voice mode. If no one is on site, the system can schedule a callback: "Would you like us to call back within [X] minutes? I will then present your case to an advisor."

The key is that transfer isn't a failure — it's a deliberate element of the scenario. A good automation doesn't try to be universal; it knows its limits and respects them.

Step 7 — after the call: SMS, CRM, and transcript

When the conversation ends, automation doesn't end with it. There are still a few steps the system performs before considering the case closed.

First, a confirmation SMS. The client receives a message with the summary: date, time, service name, and possibly preparation instructions for the appointment. This isn't a generic "thank you for contacting us" auto-reply — it's specific information the client can save in their phone without needing to write it down.

Second, an entry in CRM. The system records all collected data along with a summary of the conversation: what the client wanted, what was agreed upon, how many times the client repeated information, whether the call was transferred to a human. This last field is important from an analysis perspective — if every third call from a given category ends in transfer, it's worth checking whether the scenario needs correction.

Third, the conversation transcript. In a staged variant, you can store the transcript, run policy checks before the text agent responds, call internal systems, and only then generate speech OpenAI, Voice agents docs. This means every conversation is archived and available for later review — by a person who might want to check the details, or by a system that analyzes service quality.

Who is responsible for transcript data

A transcript is a record of the conversation, and therefore contains client personal data — name, phone number, conversation topic. This data must be processed in compliance with GDPR. If you're using an external AI system provider for transcription, you must enter into a written data processing agreement with them — this isn't an option, it's an obligation. The Personal Data Protection Office (UODO) imposed an administrative fine of 2.5 thousand PLN on the Sułkowicki Cultural Center for entrusting personal data processing without a written processing agreement and without verifying whether the processor provided sufficient guarantees of implementing appropriate technical measures UODO, decision from 21.09.2022. The processing agreement is the foundation — without it, you're responsible for the processing as if you were doing it yourself, and bear full responsibility for any violations.

Typical failure situations and how a well-configured scenario handles them

Even the best scenario encounters situations that require flexibility. Below are the most common cases and how to handle them.

System didn't recognize the name or street name

If the client speaks unclearly, has an accent, or there's noise in the background, the system might not understand the client the first time. A good scenario in such a situation doesn't ask the same question repeatedly — it proposes an alternative: "could you spell the name?" or "would you prefer I read back what I wrote and correct any mistakes?"

Client speaks in a different language

If the system detects a language other than configured (e.g., client starts in English at a company that operates in Polish), the scenario can have universal messages prepared: "I'm sorry, we handle calls in Polish — can I help in Polish?" If the client doesn't speak Polish, the system transfers to someone who can handle that language, or informs that the company doesn't support that language.

There's noise in the background

When the system detects high noise levels — conversation in the background, music, street traffic — it can ask for better conditions: "I'm sorry, I hear a lot of background noise. Could you move to a quieter place?" This is a simple intervention that often solves the problem without needing to transfer to a human.

Client asks for a live person

This event is anticipated in every good scenario. The system shouldn't argue, convince, or ask additional questions — it simply fulfills the request: "certainly, connecting you to an advisor" or "please hold, we'll call back within [X] minutes."

Two clients want the same slot

If in the meantime someone else booked that same time slot, the system must detect this and propose a solution: a new time, a different day, or adding to a waitlist. The client shouldn't find out about the conflict only after arriving at the company.

Check it yourself: a list of 10 test calls

Before implementing AI reception in your company, test the scenario with a set of typical situations. Below is a list of 10 calls worth conducting — either yourself, with help from someone on your team, or using automated testing tools.

1. Booking an appointment in a standard scenario.
2. Rescheduling an existing appointment to a different day.
3. Cancelling an appointment with a given reason.
4. Asking about a new service not in the knowledge base.
5. Complaining about the quality of service from a previous visit.
6. Explicit request to talk to a live person.
7. A conversation conducted in noisy conditions (e.g., from the street).
8. A conversation conducted in English at a company operating in Polish.
9. A conversation outside the company's business hours.
10. A conversation where the client repeatedly repeats and makes mistakes in details.

For each of these conversations, note: how many times the client had to repeat the same information, how long it took to achieve the goal, whether the call was transferred to a human, and what the final assessment was — whether the client achieved what they called for.

After conducting these tests, you'll have a concrete picture of where the scenario works well and where it needs fixing. The tests aren't meant to prove that automation works — they're meant to show where it doesn't yet work.

What it looks like when the system handles calls

When you implement AI reception, daily phone work changes in a way that's hard to appreciate without knowing the details. It's not about "the robot takes over the phone" — it's about organizing the process that previously depended on the mood, fatigue, and attention of a specific person.

In a typical day with AI reception, it looks like this: client calls, system answers and introduces itself as an automated receptionist. Client says what they need — for example, wants to book an appointment. System asks for name, phone, and preferred time. Proposes available slots. Client chooses. System sends confirmation SMS and records everything in CRM with a summary: what the client wanted, when they were booked, if anything needs to be prepared. You as the owner or manager see a list of new entries in the morning and only check those that require attention — complaints, questions beyond the system's knowledge, unusual requests.

This isn't magic or a promise of big savings. It's simply an organized process that eliminates the most common errors: forgotten entry, unconfirmed appointment, unhandled complaint, missed client question.

If you want to see how this scenario works in your specific case — what questions the system asks, what data it collects, how it integrates with your calendar — you can check it in action. Aura builds a phone layer where AI answers: knows your services, prices and schedule, and can close the deal. More details are on the AI reception and telephony page.

Also check how the full ecosystem works: with Booking Systems, the client can choose a time without a phone conversation, and Automatic messages send confirmations and reminders by SMS, email, or WhatsApp — always with client consent and opt-out option. Together, these three services create a closed service cycle where phone, calendar, and client communication work as one coherent layer. If you want all client data in one place, add CRM and automations — phone, form, messengers and Google Business card record in one place. And if you handle many conversations at once and need help with lead qualification, AI lead qualification evaluates and tags inquiries by potential.

Read more about automation in business from our articles: Query handling automation: one queue instead of five inboxes, Process automation in a company: what can realistically be handed over to a system and what cannot, Automation and GDPR: where your customer data physically ends up, Errors when implementing automation: five situations where we advise against starting.

Frequently asked questions

Won't the client get angry that they're talking to a robot?

It depends on how the scenario is configured. A client will get angry if the robot doesn't understand what they're saying, constantly asks for repetition, can't answer a simple question, and won't connect them to a human. A well-configured scenario clearly says at the start that it's an automation, doesn't pretend to be a live human, collects minimum data, and doesn't waste the client's time on unnecessary steps. Many clients prefer a quick conversation with an automation that handles things in 60 seconds over waiting on the line for a live receptionist who'll answer in three minutes.

What if AI doesn't understand the client?

A good scenario has contingency procedures: repeating the question in different words, asking for information letter by letter, switching to human transfer mode. The client shouldn't be forced to repeat the same thing endlessly — after the second failed attempt, the system should propose transferring.

Are calls recorded and who has access to them?

Transcripts are saved if you configure the system that way. Access is held by the person you designate in the company. If you're using an external AI provider, you must have a data processing agreement with them — without it, you're responsible for GDPR compliance as if you processed that data yourself.

How much does it cost?

The cost depends on the number of calls the system handles and the selected functionality range. We don't give specific prices. More about how to calculate the cost of missed calls can be found in the article How much do missed calls cost in a company – a formula to calculate with your own numbers.

Can I test before implementation?

Yes, before deciding on full implementation, it's worth testing the scenario on live conversations or simulations. Conduct the 10 test calls from the list above and see how the system handles each situation. Based on the results, you can fine-tune the questions, add missing paths, and establish which calls should always go to a human.

Can AI handle multiple companies at once?

Technically yes, but from a quality perspective, it's better if each company has its own dedicated scenario. A different set of services, different schedule, different business hours, different knowledge base — all of this requires individual configuration. One system can handle multiple companies, but each should have its own flow tailored to itself.