A customer who does not turn up and does not warn you costs the business twice over: the slot is gone, and somebody else was turned away earlier because the diary looked full. A phone call the day before solves most of those situations, except that reception rarely has time to make it. This is exactly the kind of work you can hand over to a voicebot, and you do not need to replace your booking system to do it.
An empty slot is a loss nobody sees in the reports
A missed appointment looks harmless because it never shows up in a cost breakdown. There is no invoice, no complaint, just an hour in which a treatment room, a work bay or an adviser does nothing. The problem is not that the customer changed their plans, because that will always happen. The problem is that the company finds out at the exact moment when nothing can be done with that slot any more.
If the same information arrived a day earlier, the free time would go to somebody on the waiting list, or to a customer who was offered a distant date when they booked. The whole mechanism comes down to one thing: you have to find out sooner. And to find out, somebody has to call and ask.
In practice reception works through the diary only on the quieter days. With a few dozen bookings a day, manual confirmation loses out to the customers standing at the desk or waiting on the helpline. A reminder text helps, but it only goes one way: the customer reads it, usually does not reply, and the company still has no idea whether the appointment stands.
What the call the day before actually sounds like
The voicebot dials within an agreed time window, gives the company name, states the date and time of the appointment and asks a single question: is the booking still good. The conversation is short because it has only one job. All the value sits in what happens after the customer answers, because every branch has to end in a concrete action in the system rather than a note somebody retypes later.
The customer confirms
The simplest case to handle. The booking gets a confirmed status and in the morning the team sees a list showing who is definitely coming. That changes how the day is planned, because unconfirmed slots can be treated as risky from the outset and given a fallback plan.
The customer cancels
This is where it gets interesting, because a cancellation accepted automatically frees the slot immediately. The voicebot switches the booking status to cancelled and records it in the calendar or in the booking system. In parallel, a notification goes to the member of staff who owns that diary: by email, text message or a message to the team channel. Nobody on reception has to retype anything, they simply get the information that the hour is free and can be offered to someone else.
The customer wants to reschedule
Rescheduling is harder than cancelling because it requires knowing what is available. There are three sensible variants and you pick one depending on how complex the schedule is. The voicebot can offer free slots straight from the calendar and book the new time during the call. It can take the request alone and pass it to a member of staff who will call back. Or it can transfer the call to an agent right away, before the customer hangs up, which usually works best because the new date is agreed in a single contact.
Nobody picks up
This needs planning, because it affects a sizeable part of the list. You set the number of attempts and the gap between them, for example two attempts at different times of day, so that you catch a moment when the person can talk. If contact fails, the booking stays unconfirmed and the system can additionally send a text asking for a reply. Sending those messages runs through SMS API, so the call and the message work inside one process. The message can be as short as: "Hello, this is a reminder of your appointment on 22 July at 10:00. Reply YES to confirm or NO to cancel."
The simplest setup: a calendar and a booking sheet
The biggest barrier in projects like this is imaginary. Companies assume they first have to buy a new booking system or commission an integration written from scratch. You do not. All you need is one place where bookings can be read by a machine and where the outcome of the call can be written back.
In its simplest form that means two tools the company usually already has:
- an ordinary calendar – Google Calendar for instance, the one you already keep the appointment diary in,
- a sheet with the booking list – a Google Sheet holding the date, time, customer name, phone number and a status column,
- agreed calling hours – the window in which the voicebot places calls the day before an appointment.
The voicebot reads the next day's appointments from that source, makes the calls and writes the result back into the same status column. Staff do not have to learn a new tool, they just look at the sheet they already know each morning. A setup like this can go live quickly and be treated as a trial on one branch or one group of services before anything bigger is decided.
The variant with an integration into your own system
When a company runs a dedicated booking system, a clinical system or a CRM, a sheet stops being enough, because the status has to change where the whole team is looking. In that case the voicebot connects to the system through its API and performs the same operations a person would: it reads the next day's appointments, marks a booking as confirmed, cancels it, or adds a note about a reschedule request.
The difference against the simple variant is mostly about implementation. You have to establish which fields describe the status and where the phone number comes from, check what the system does on cancellation, and test the whole thing on a few dozen bookings before full traffic starts. The telephony layer stays the same, and calls run through a virtual PBX, so handing a customer to an agent is an ordinary transfer to a queue rather than a separate system sitting alongside. We describe the technical side of deployments like this in more detail on our page about AI solutions in communications.
This is not telemarketing, it is part of the service
This point decides whether the project starts at all, because the first question inside the company is usually: are we even allowed to call these people. It helps to separate two completely different situations. A call in which you offer somebody a new service is a marketing activity and rests on consent. A call in which you confirm an appointment that has already been booked is part of delivering the service the customer signed up for and gave their number for in the first place.
The practical rule is simple: the conversation must relate solely to that one booking. The moment the voicebot also pitches a package, a promotion or another service, the nature of the call changes and you are back in consent territory. That is why the script stays on one topic, and the purpose of the call is stated in the opening sentence.
We are not quoting specific regulations here, because their wording and the way they are interpreted vary between markets and change over time, while responsibility stays with the data controller. The principle is described above, but your specific case, especially in healthcare and wherever sensitive data is involved, is worth confirming with your own legal team or data protection officer before the first calls go out.
Who this makes sense for
There is one criterion: the company works on appointments, and a customer's absence means an hour that cannot be resold. In practice that covers:
- clinics and practices – dental, physiotherapy, veterinary, diagnostic, where the diary is dense and the waiting list is long,
- garages and service centres – a bay reserved for a car that never arrived stands empty for half a day,
- salons – hairdressing, beauty, barbering, where a stylist is measured on chair occupancy,
- advisers and service desks – branch meetings, accounting and legal consultations, engineer visits at the customer's site,
- field services – where sending a crew to a locked door costs more than the visit itself.
The more an hour of work is worth and the longer the waiting list, the faster confirmation calls justify themselves. With a handful of bookings a day, reception will cope on its own and there is nothing worth automating.
What you need to prepare before you start
The list is shorter than it looks, and most of it is decisions rather than technical work:
- a booking list with phone number and appointment time – a calendar, a sheet or a system, as long as the data sits in one place and is up to date,
- a decision on what the system does in each scenario – confirmation, cancellation, reschedule request and no contact, each with an action attached,
- calling hours and the number of attempts – a window that suits customers rather than the rota, plus a rule for retrying,
- a person and a notification channel – who gets told about a cancellation and where they will see it,
- a route to a live agent – the number or queue the voicebot transfers a customer to when they want to agree a new date,
- the script – a few sentences carrying the company name, the reason for the call and the confirmation question.
A sensible start is one group of services or one location for two weeks. After that you can see how many customers answer, how many slots come back into the pool and which phrases in the script need reworking. Only then is it worth extending the scope to the whole diary.
Summary
Appointment confirmation is one of those voicebot use cases where the benefit is visible straight away without complicated analytics: either the slot comes back into the diary a day early, or it is lost. Deployment does not require replacing the booking system, because in its simplest form it runs on the calendar and the sheet the company already keeps. It usually does not require marketing consent either, as long as the conversation covers only the booked service, although the legal basis is worth confirming on your side. If you want to see how this flow would look against your own diary, describe your current booking process through our contact form or take a look at the wider set of AI solutions in communications.