04 / voice
AI Receptionist
The front desk: greet, route, schedule.
Clinics, practices and offices where the front line is one person who also has another job.
- Phone
- Calendar
- CRM
- Greet
- Route intent
- Book or transfer
- Log outcome
Anything medical, legal, or a complaint goes straight to a named person. It does not try to judge what it is not qualified to judge.
The front desk, when the front desk is busy or closed. It answers, works out who is calling and why, books or routes them, and leaves a record the office can read in the morning.
How this one gets built
What the job looks like in practice
Most reception traffic is a small number of intents repeating: booking something, moving something, asking whether you do a thing, and needing a person. An agent that handles the first three cleanly and passes the fourth on straight away covers the bulk of the volume, and that is the version worth building first.
What it plugs into
The calendar or practice system it books against, and wherever contact details are supposed to live. The constraint worth surfacing early is which system is authoritative: plenty of offices run a diary and a CRM that disagree, and an agent forces that question because it has to write to one of them.
What the office notices
The visible change is that mornings open on a list where a voicemail box used to be, each entry carrying who called, what they wanted and what was already promised. The less visible one is that the desk stops being interrupted mid-task by calls it was always going to hand on.
When this is the wrong answer
A practice where most calls are clinically sensitive should keep a person on the line and use an agent only for the clearly administrative traffic, if at all. Read the piece on AI receptionists before deciding — it sets out the cases where the honest answer is no.
FAQ
Questions about this one
Will callers know it is not a person?
Yes, because the greeting tells them. That is a fixed condition of the work and not a setting: a caller who realises later has stopped trusting the practice rather than the software.
Can it handle Dutch callers?
The models handle Dutch. The design question is what it does when a caller opens in Dutch and the business runs in English, and it gets decided deliberately during scoping, never left to a default.
What if two callers want the same slot?
It holds the slot inside the call, reading and writing the live calendar, so the second caller is offered something else. Any design that proposes a time and confirms it later has a gap where the double bookings live.
Last reviewed