Identifies the patient
By the number that is writing, by the national ID or by name plus date of birth. If the record does not exist, it does not invent one: it asks for what is missing and opens the record through the same path.
Hal-AI for hospitals · Outpatient schedule
Booking, rescheduling and cancelling appointments
The agent does not write the request down for the front desk to sort out tomorrow. It opens the hospital's official schedule, sees the slot that exists right now, checks what the patient's health plan covers, offers the real options and writes the booking — into the same system the front desk works in.
Meta's official WhatsApp · every schedule operation goes through your hospital system's API · no spreadsheet in the middle.
The mechanism
From “I need an appointment” to a booking reference, without leaving the chat
Booking an appointment is not answering a question: it is a sequence of checks that has to end inside a system. The agent runs that whole sequence in the same conversation, and it only names a slot after the hospital has confirmed that the slot exists.
Checks the health plan and eligibility
Plan active, card valid, coverage for that specialty, and whether the procedure needs prior authorization. This is where the wrong booking stops being born.
Works out what the patient needs
“I need a cardiologist”, “it's the follow-up with the doctor I saw last week”, “the referral says echocardiogram”. The agent turns the request into a specialty, a visit type and a procedure.
Reads real availability
It asks the hospital system which slots exist in that specialty, at that site, inside the day window the hospital opened. It never works from a copy of the schedule.
Offers what exists
Two or three options, with day, time and site. If there is nothing inside the window, it says so — and asks whether the patient wants to join the waiting list for that specialty.
Writes the booking
The patient's choice becomes a record in the official system. The reference the agent hands back is the one the hospital itself generated, not a number the conversation made up.
Step 7
Returns the reference and the prep instructions
Along with the reference goes what the patient needs to know before leaving home: ID, insurance card, referral, fasting when the procedure calls for it, what time to arrive and which entrance to use at that site.
The prep instructions are not invented by the agent. They come out of the hospital's Knowledge Vault — the texts the institution itself published, procedure by procedure. If the prep for that exam is not registered, the agent says it will check and hands the chat over, instead of writing a plausible instruction.
Prep instructions are logistics, not clinical advice. The agent does not assess symptoms, does not suggest a diagnosis and does not comment on medication.
Files it in the CRM with no typing
The whole conversation becomes a record: who asked, what they asked for, what was offered, what was accepted and which reference came out. When the same person comes back in three months, the agent already knows where they were seen and what was left open.
It is the same funnel the rest of the operation uses — the agent fills it on its own, the front desk reads it, the manager asks it questions.
Nobody types the record up afterwards. It is born from the conversation.
The six tools below are what the hospital hands the agent. Each one is an endpoint of the API you already run, registered once, with a declared scope — and each one has a defined behavior for when the system on the other side does not answer.
| Tool | What it does | If the call fails |
|---|---|---|
| api_get_patient | Finds the patient record by phone number, by national ID or by name plus date of birth. | The agent asks for the details and opens the record through the same path. Two people with the same name stop the booking and go to the front desk. |
| api_get_plan_eligibility | Checks that the plan is active, that the specialty is covered and whether prior authorization is required. | It says it could not confirm coverage right now and offers either self-pay or a call back from the booking center — it never states that something is covered. |
| api_get_schedule_availability | Returns the slots that exist, by specialty, by site and by day window. | No answer means no offer. The agent says the schedule is unavailable and puts the request in the front desk queue, with the context attached. |
| api_post_appointment | Writes the booking and receives back the reference the hospital generated. | Nothing is confirmed to the patient. The agent retries and, if the error persists, hands the case over with the slot still open. |
| api_put_appointment | Reschedules: swaps the time on an existing booking, in a single operation. | The old slot stays valid. The patient is told the swap did not go through and the original appointment still stands. |
| api_delete_appointment | Cancels and returns the slot to the grid in the same operation. | The cancellation is only confirmed after the system returns the new state. With no confirmation, the agent does not say it cancelled anything. |
If the hospital system did not answer, there is no slot to offer. The agent would rather say that than promise a time.
Order of magnitude
The hospital in the example
A mid-to-large hospital network · 28 outpatient specialties · around 60,000 outpatients a year · roughly 2,500 consultation slots offered per week · official WhatsApp carrying about 23,000 conversations a month · 14 contracted payers, the health plan operators the hospital bills.
10,400
schedule operations a month — bookings, reschedules and cancellations
91%
completed on the first attempt, with no hand-off to the booking center
2 min
typical length of the whole conversation, from “I need an appointment” to a confirmed slot
There is one detail that only shows up at the end of the month: 1 in every 5 bookings happens outside front desk hours — evening, small hours, Sunday. Those are the requests that used to turn into a missed call on Monday, once the slot was already gone. The same number handles questions, exam prep and health plan coverage; booking is one of the things it settles. See patient service on official WhatsApp
Point of trust
Never a parallel schedule
This is the question every outpatient director asks in the first meeting, and the answer is short: the agent has no schedule of its own. It writes into yours.
Most booking bots work like a fancy form: they collect the request, keep it in a database of their own and hand it back for somebody at the hospital to retype. The result is familiar — two schedules that disagree, a slot sold twice, a patient who arrives with a reference the front desk cannot find.
Here the booking is born and dies inside the hospital system. The slot is held by that system, which is the only party that knows whether it is still free at the moment of writing. Two simultaneous conversations asking for the same time do not produce two bookings: the second one gets the system's refusal and the agent offers another option, still inside the chat.
- The front desk sees it on the same screen. No new screen to check, no report to import. What the agent wrote at 11:40 PM is in the next morning's grid like any booking made at the counter.
- There is no spreadsheet in between. No intermediate file, no overnight export, no “the bot sends the list and we key it in”.
- The reference is the hospital's. The number the patient receives is the one the front desk reads in the system. Every future conversation is traced by it.
- Every operation leaves a trace. What was read, what was decided and what was written are logged in the run — with the time, the tool called and the response received.
- Declared scope. The agent sees availability and bookings. Patient charts, clinical notes and exam results are not among the tools it was given.
What does not change
One grid, with one owner
The hospital system stays in charge of the schedule. The agent is one more client of that API — like the front desk, like the patient portal, like the kiosk in the lobby.
- Zero bookings in a parallel schedule
- Slot held by the hospital system itself
- Reference generated by the hospital, not by the chat
- Audit trail on 100% of operations
- No patient data in the aggregate dashboard
A bot that takes down the request
- Collects the intent and hands it back for someone to key in later
- Works on a copy of the schedule that ages between one sync and the next
- Confirms a slot to the patient that may not exist any more
- Generates a ticket number of its own that the front desk cannot find
- A cancellation becomes a notice: the slot only returns when somebody remembers
- When the integration goes down, it keeps on promising
An agent on the official schedule
- Reads, holds and writes inside the hospital system, in the same turn as the conversation
- Works on the availability of the moment — no copy, no lag
- Only confirms after the write came back successful
- Hands back the reference the hospital generated
- Cancel it, and the slot returns to the grid in the same operation
- When the integration goes down, it says so, logs the request and hands over
On screen
One booking in progress, as the hospital sees it
On the patient's side it is a conversation. On the inside it is this screen: the record checked, eligibility answered by the payer, the slots the API returned and the write that just came back with a reference.
Booking in progress
Conversation 8,412 · official WhatsApp · agent Outpatient Front Desk
Open conversation
Steps already completed in this conversation
PatientRecord 44,812 · found from the number that is writingapi_get_patient returned a single record. A namesake or a duplicate stops the booking and sends the case to the front desk.
Health planPayer 07 · plan active Eligibleapi_get_plan_eligibility: coverage confirmed for a Cardiology consultation. Procedures that need prior authorization do not come through this path.
RequestFirst consultation in Cardiology · no procedure attached
Window queried14 days from today · Central Outpatient and North Site
Rules applied
Slots returned by the schedule — api_get_schedule_availability
| Day | Time | Site | Room | State |
|---|---|---|---|---|
| Thu · Sep 24 | 9:20 AM | Central Outpatient | Cardio 3 | Open |
| Thu · Sep 24 | 3:40 PM | Central Outpatient | Cardio 1 | Open |
| Fri · Sep 25 | 8:00 AM | North Site | Cardio 2 | Holding |
| Fri · Sep 25 | 11:10 AM | North Site | Cardio 2 | Follow-up only |
| Mon · Sep 28 | 7:40 AM | Central Outpatient | Cardio 3 | Open |
| Mon · Sep 28 | 2:00 PM | Central Outpatient | Cardio 1 | Taken 2 min ago |
| 6 slots in the 14-day window = 3 open + 1 being held + 1 restricted to follow-ups + 1 taken during the conversation. Only the open ones are offered to the patient. | ||||
What was offered in the conversation
Thu · 9:20 AM · Central Thu · 3:40 PM · Central Fri · 8:00 AM · North 3 of 6 eligible
Writing the booking
Running
api_post_appointment → reference AMB-44812 · Fri Sep 25, 8:00 AM · North Site
Booking completed
Written to the official schedule
Record 44,812
Cardiology · Fri Sep 25 at 8:00 AM · North Site · arrive 20 minutes early, with ID and insurance card.
1 min 51 s conversation
Not booked by the agent
Record 51,207
The procedure needs an authorization code from the payer. The agent explained it, offered no slot and handed the case over with the history attached.
6 min in the queue
AI paused automatically — record 51,207 was taken over by Booking Center · afternoon shift
Release AI
Trail for this conversation
Intact
patient → eligibility → availability → write → reference returned to the channel
What you are looking at
A booking halfway through. On the left, the specialties with the window each one opens — including the one only the booking center may write to. In the middle, the record already identified, eligibility answered by the payer and the rules the hospital switched on for that schedule. Below, the six slots the API returned, with what happened to each, and the write going out with a reference.
The advantage
Look at the Monday 2:00 PM line: it was taken by somebody else while this conversation was running, which is why it was never offered. That is the difference between reading the schedule at the moment of the offer and working from a copy made that morning. Of the six slots in the window, three reached the patient — the other three were ruled out by policy, not by chance.
Only at Hal-AI
Look too at what the screen does not show: no clinical data. The columns are day, time, site, room and state — no symptom, no history, no exam result, because the agent was never given a tool for that. And the second card is a case it decided not to book: it explained why, offered no slot and handed the chat to a person, with the whole conversation attached.
Without calling the booking center
Rescheduling and cancelling, by the patient
Half the phone queue in an outpatient clinic is people trying to move an appointment. It is the simplest operation in the world and the most expensive to answer — because it takes a person, a line and a wait.
The patient writes “I won't make it on Friday”. The agent finds the booking from the record, confirms which one it is — asking if there is more than one — reads availability in the same specialty and offers the options that exist. The swap is a single operation in the system: the new slot is held and the old one released in the same move, with no window in which both are occupied.
Cancellation follows the same path, with one important difference: the released slot goes back into the grid immediately. It does not wait for an overnight job, it does not wait for somebody to remember. Whoever cancelled at 2:00 PM handed the hospital a slot there is still time to fill — and that is exactly what the waiting list does next.
- Reschedule: the agent calls the update tool on the booking and returns the reference, which is still the hospital's own.
- Cancellation: the slot goes back to the grid in the same operation, and the state is only communicated to the patient once the system has confirmed it.
- Swap limit: the hospital sets how many reschedules each patient may make. Past the limit, the agent explains the rule and hands over.
- Minimum notice: below the defined threshold, the swap stops being automatic. The agent does not bend the rule, and it does not pretend the rule is not there.
- The front desk sees everything: a cancellation made at 11:00 PM shows up in the next morning's grid like any other.
Outpatient Front Desk
online
Good evening. I can't make Friday morning — is there any way to move it?10:37 PM
Good evening! I found your Cardiology appointment on Friday, Sep 25, at 8:00 AM, at the North Site. Is that the one?10:37 PM
That's the one.10:38 PM
In the same specialty I have Monday Sep 28 at 7:40 AM at Central Outpatient, or Thursday Oct 1 at 3:10 PM at the North Site. Does either work?10:38 PM
Monday, please.10:39 PM
Rescheduled. Monday, Sep 28, at 7:40 AM, Central Outpatient — reference AMB-44812. The Friday slot is already back on the schedule. Bring your ID and insurance card, and arrive 20 minutes early.10:39 PM
That was your first reschedule. The hospital's rule allows one more.10:39 PM
The wording and the rules quoted depend on what each hospital configures in the agent.
A swap is not a cancel plus a new booking
Two separate operations open a gap: between releasing the old slot and writing the new one, somebody else can take it and the patient ends up with neither. That is why a reschedule is a single operation, decided by the hospital system.
Cancelling is cheap — for everyone
When cancelling costs a phone call during business hours, the patient simply does not cancel: they no-show. Cutting the cost of a cancellation is the most direct way to turn a no-show into a slot somebody uses.
The small hours count
A good share of cancellations arrive at night, once the patient's day is over. If nobody is on duty to record them, the slot only surfaces the next morning — too late to offer to the queue.
An appointment cancelled in advance is a slot. An appointment abandoned is a hole in the grid.
Slot recovery
The slot that opens up does not stay empty
Cancelled at 2:00 PM. Under normal conditions that Thursday slot dies right there: nobody has time to work the waiting list looking for someone who can take it. The agent does.
When the cancellation is written, the slot returns to the grid and triggers a second routine: the agent reads the waiting list for that specialty, orders it by time waited and starts offering — oldest first, one at a time or in small batches, whichever the hospital prefers.
The approach respects the channel's rule. If that person wrote to the hospital in the last 24 hours, the conversation carries on normally. If they did not, the only way to start contact is through a Meta-approved template — and that is what the agent uses, with the text the hospital registered. Whoever answers first takes the slot; the others are told it has been filled and stay in the queue, in the same position.
- Ordered by time waited, inside the specialty — not by who replies fastest overall.
- Short offer window. With no answer in a few minutes, the agent moves to the next person, so the slot is not held until it expires.
- Immediate confirmation. Whoever accepts is written into the schedule in the same turn, with reference and prep instructions.
- No ghost queue. People already seen, people who booked elsewhere and people who asked to leave drop off the list automatically.
- The hospital chooses the reach. In some specialties recovery is automatic; in others the slot goes back to the booking center to decide.
This is the gear that changes how full the grid runs without opening a new consulting room. The cumulative effect — capacity, slot-to-visit conversion and the queue per specialty — is laid out on the schedule page. See schedule, capacity and no-shows
Running Slot recovery · Cardiology Step 5 of 7
14:02:11Cancellation received in the conversation — Thu Oct 1, 9:20 AM, Cardiology
14:02:12api_delete_appointment(reference="AMB-43907")
14:02:13Slot returned to the grid and confirmed to the patient
14:02:14api_get_schedule_availability(specialty="Cardiology", days=1)
14:02:16Waiting list for the specialty: 34 people · ordered by time waited
14:02:17The first 3 are outside the 24-hour window — contact only by approved template
14:02:19Template slot_offer sent to 3 contacts, oldest to most recent
14:09:44First reply accepted — api_post_appointment → reference AMB-44903
14:09:45Telling the others the slot has been filled
1 slot released · 3 contacts reached · 1 booking written · 7 min 34 s between the cancellation and the new appointment Done
Outside the 24-hour window
Approved template
anyone who has not written in the last 24 h can only be contacted through a Meta-approved template
Whoever did not answer stays in the queue
No penalty
not answering an offer takes nobody off the waiting list
Joining the queue is part of the conversation
When there is no slot in the window, the agent does not close the subject with “nothing available”. It offers the waiting list for that specialty, records the preferred shift and site and explains how the person will be called. The queue stops being a notebook at the front desk and becomes a state in the system.
The Squad sweeps up what is left
Beyond recovery in the heat of a cancellation, an orchestrating agent wakes up at the scheduled time, looks at the next day's grid, finds the slots still open and tells the channel agent to offer them to the queue. Same mechanism, running on a routine instead of on an event.
Active confirmation
Who confirms, who goes silent and who reschedules
Confirming is not sending a reminder. It is splitting tomorrow's schedule into three piles — what still stands, what turned into silence and what needs to move — and acting on each one before the day starts.
Inside the window
If the patient wrote to the hospital in the last 24 hours, the conversation is open: the agent asks, hears the answer and updates the state of the booking in the official schedule.
Outside the window
After 24 hours with no message from the patient, contact can only start through a Meta-approved template — with the text the hospital registered and got approved beforehand. There is no shortcut here, and the agent does not try one.
Three outcomes, three actions
Confirmed: the slot holds. Rescheduled: it goes down the reschedule path and releases the slot. No answer: the person is approached again and, close to the day, the slot joins the risk list the booking center watches.
Lead time predicts the no-show: a booking made more than 30 days out is missed about 2× as often as a same-day one.
That is the figure that changes how confirmation is designed. If the chance of a no-show grows with the distance between the booking and the visit, confirming everyone the same way wastes effort: the confirmation queue is not chronological, it is ordered by risk. Someone who booked two months ago is approached earlier and more often; someone who booked this morning for tomorrow barely needs a reminder.
Outpatient Confirmation
Month close — what the schedule took in and what confirmation gave back
Document published by the Squad at the end of the daily 7:30 AM run, consolidating the outpatient month to date.
01Schedule operations in the month
The channel ran 10,400 schedule operations — bookings, reschedules and cancellations combined. Of those, 91% finished on the first attempt, with no hand-off to the booking center. The rest stopped at one of the hospital's rules or at a silent external system, and were handed to a person with the context attached.
Schedule operations
10,400
bookings, reschedules and cancellations
On the first attempt
91%
no hand-off to the booking center
Outside front desk hours
1 in 5
evenings, small hours and weekends
02Before and after, on the same grid
No new consulting room, not one extra slot offered: the same 2,500 slots a week. What changes is how much of the grid gets used, how much of what was booked becomes a visit and how much disappears on the day.
Capacity, conversion and no-shows — order of magnitude
Figure 1 — grid capacity, slot-to-visit conversion and no-show rate, before and after booking and confirmation through the channel.
03How the confirmation queue is ordered
The ruler is lead time. The older the booking, the earlier and the more often the agent reaches out — and the more likely that outreach has to go out as an approved template, because that person has not written to the hospital in weeks.
| Booking lead time | Relative no-show risk | When the agent reaches out | Path |
|---|---|---|---|
| More than 30 days | about 2× the same-day rate | 7 days out, 48 h out and the day before | approved template |
| 8 to 30 days | intermediate | 48 h out and the day before | approved template |
| 2 to 7 days | lower | the day before | 24-hour window |
| Same day | the lowest of the group | no outreach — the conversation is recent | 24-hour window |
What the manager has to decideThe bands, the number of touches and the wording of each template are hospital configuration, not agent behavior. Changing the ruler changes how many messages go out in the month — and that is an operational decision, taken by people.
The full picture of capacity, no-shows and the queue per specialty lives on the schedule page. See schedule and capacity · See how the panel is written and sent
Transparency and governance
Where the agent stops — and who decides that
An agent that books everything is an agent that will book the wrong thing. The cases below are deliberate refusals: it explains the reason to the patient, offers no slot and hands the chat to a person with the whole conversation attached.
First consultation with prior authorization pending
When the referral still depends on approval, booking creates an expectation the hospital cannot meet — and a slot that will probably be lost. The agent explains what is missing, says whose move is next and hands the case to whoever tracks authorizations.
A procedure that needs an authorization code from the payer
No code, no booking. The agent makes no exception, does not “hold it provisionally” and does not promise to call back. It logs the request, tells the patient and puts the case in the booking center queue, with the health plan and the procedure already identified.
A minor with no identified guardian
If the conversation is about a minor and the agent cannot identify the guardian on the record, the booking stops. It is a protection rule, not a form detail: the chat goes to a person, who handles identification through the hospital's own channels.
Anything the hospital flagged as “needs human triage”
There are specialties, procedures and patient profiles where the hospital itself decides the call is too clinical or too administrative to be automatic. Flagging it in the configuration is enough: the agent recognizes it, says so and hands over, without arguing with the rule.
And always: no clinical advice
The agent does not assess symptoms, does not suggest a diagnosis, does not recommend treatment, does not comment on medication and does not decide urgency. If the conversation heads that way, it points the patient to care and hands over. Booking an appointment is logistics; what happens inside the appointment belongs to the clinical team.
The hospital's rules
What you switch on, switch off and cap
None of this is code. These are configuration switches per specialty and per site, changed by whoever answers for the schedule — and the agent starts obeying in the next conversation.
- Minimum notice. How many hours before the appointment the agent may still book, reschedule or cancel on its own.
- Reschedule cap. How many swaps each patient may make on the same booking or in the same period.
- Squeeze-ins blocked. Whether the agent may take same-day squeeze-in slots — the extra ones added on the day. In most hospitals it may not: a squeeze-in is a call for whoever is on site.
- Specialties only the booking center writes to. The schedule stays visible for reading, but the write is reserved for a person.
- Offer window. How many days ahead the agent may see and offer, per specialty.
- Offerable sites. Which sites enter the search and in what order they are suggested.
- Reserved by visit type. Slots held for follow-ups, for first consultations or for referred demand, which the agent does not touch.
Minimum notice24 hours to book, reschedule and cancelBelow that, the agent explains the rule and hands over to the booking center, instead of refusing with no context.
Reschedule cap2 per bookingOn the third attempt the case goes to a person, with the swap history in view.
Offer window14 days ahead
Offerable sites
Change logged
Applies from the next conversation
who changed it, what they changed and when — every schedule rule has a history
Questions
Questions from whoever answers for the schedule
The five that come up in every rollout meeting.
Does the agent book into a schedule of its own or into the hospital's?
Into the hospital's, always. It reads availability through your system's API and writes the booking into that same system, receiving back the reference the hospital generated. There is no database of its own, no copy of the grid and no spreadsheet in between.
The practical consequence is that the front desk sees the booking on the usual screen, at the same moment — and the patient who walks up to the counter is found by the reference they received on WhatsApp.
What if the scheduling system goes down mid-conversation?
With no answer from the API there is no slot to offer, and the agent offers none. It tells the patient the schedule is unavailable at that moment, logs the request in the front desk queue with the full context of the conversation and says somebody will come back to them.
If the failure happens at the moment of writing, nothing is confirmed: the agent retries and, if the error persists, hands the case over with the slot still open. The principle is the same across the platform — never assert what could not be verified.
Can two patients book the same slot at the same time?
No. The hospital system holds the slot, and it is the only source that can know whether that time is still free at the moment of writing. If two simultaneous conversations ask for the same slot, the second one gets the system's refusal and the agent offers another option inside the chat, without the patient ever seeing an error.
Can a patient cancel at 3 AM? Does the slot really come back right away?
They can, and it does. The cancellation is written to the system at the same moment as the conversation, and the slot returns to the grid in the same operation — there is no overnight job and no manual entry the next day.
When automatic recovery is on for that specialty, the cancellation then triggers the offer of the slot to the waiting list. Outside WhatsApp's 24-hour window, that offer goes out as a Meta-approved template.
How do we stop the agent booking a case that needs human review?
By flagging the specialty, the procedure or the profile as requiring human triage in the schedule configuration. The agent then recognizes those cases, explains to the patient what happens next and hands the chat over, without offering a slot.
There are also the refusals that ship by default: prior authorization pending, a procedure that needs an authorization code from the payer, and a minor with no identified guardian. And the rule that cannot be switched off: the agent gives no clinical advice under any circumstances.
Bring us your outpatient schedule and we'll design the booking together
Tell us which specialties jam up on the phone today, which rules your schedule carries and which system holds the grid. From there we design the agent that books, reschedules, cancels and confirms inside your system — with the limits you set.