A guide for clinic operations

How to automate appointment confirmations?

Use up to five reminder lead times chosen by the clinic (such as 72, 48, 24, 3, 2 or 1 hours), with clear copy, quiet hours and eligibility checks; Bia sends the notice, but it does not yet store a persistent RSVP.

Confirming an appointment is more than sending a message. The clinic owner needs to know which appointment is involved, when the notice should go out, which channel can receive it and what the team will do if the client replies, cancels or stays silent. Bia schedules up to five lead times chosen by the clinic, cancels old jobs when a time changes and avoids sending to ineligible contacts. This guide turns those real behaviors into a practical routine. It does not call a reminder acceptance, invent a response rate or promise a public confirmation button that the product does not have today.

Published: 2026-08-14Updated: 2026-08-31

Up to five reminder lead times chosen in clinic settings
An idempotency key prevents the same job from being created twice
An editable template keeps the service and appointment time clear
Quiet hours, opt-out and blocking are checked before delivery
Cancellation and rescheduling stop messages for the old time
An explicit boundary: a sent notice is not persistent RSVP

1. Define what your team calls a confirmation

Before automating, separate three facts: the appointment was created, the client received a notice and the client replied that she will come. They are not the same. In Bia's schedule, `confirmed` describes an active appointment used by reports, availability and NPS; it is not a client-response column. If the team calls every confirmed status an RSVP, the dashboard will look more certain than the data allows.

Write the clinic rule in one sentence the front desk can repeat. For example: a message reminds the client of the time and invites her to ask for a cancellation or reschedule; the team still owns the reply. A “yes”, a “cannot make it” and no reply require different actions. Automation organizes the first contact, but it cannot decide on its own whether the chair will be occupied.

This distinction also prevents a dangerous database shortcut. The `status` field already means an active appointment and is used by old constraints and routines. Reusing it for “accepted”, “declined” or “no answer” would silently break reports. The need for a separate RSVP state is recorded as product opportunity OPP-001, outside this guide and this stage.

A notice does not prove that a client replied.
A reply still requires an action in the schedule.
Persistent RSVP is a gap, not a sales promise.

2. Record the data the reminder really uses

A useful message starts with a complete appointment. The workflow knows the client, service, professional, start and end, plus the clinic time zone. The schedule may also use a room or equipment to check availability. Before enabling a cadence, verify the time, a valid channel and the service that the front desk expects to deliver.

The backend builds the work from the confirmed appointment and clinic settings. New jobs use the `reminder` type and store the lead time in hours, plus an idempotency key that prevents duplication when the same operation repeats; legacy 24-hour/2-hour jobs remain recognised during compatibility. That does not remove human review: a job can be skipped because the time passed, because it falls in quiet hours or because the appointment changed state.

Use the template to guide a reply, not to collect clinical information. The text can show the service, date, time and available contact channel. Do not put a record, allergy, diagnosis, password or other sensitive data in a public page or a message that does not need it. When in doubt, keep only what lets the team locate the appointment.

Check client, service, professional, start, end and time zone.
Repeating an operation must not create duplicate jobs.
Keep the message in the schedule context, not the record.

3. Choose the reminder lead times

Clinic settings let you choose up to five lead times from 72 hours, 48 hours, 24 hours, 3 hours, 2 hours and 1 hour. You can combine them or turn them all off. The decision should match the clinic's routine and its ability to read replies, not a promise that more messages always create more attendance. The product does not publish a universal conversion percentage.

When a confirmed appointment is created or rescheduled, the service calculates future times and queues only enabled types. If the target has passed, the work is marked skipped; if the time policy does not permit delivery, the state records suppression. The key contains the appointment, time and type, so repeating creation should not send two identical copies.

Start with a policy the clinic can follow. A 72-hour or 24-hour lead time gives more time to reorganise; a 3-hour, 2-hour or 1-hour reminder needs someone available to read the reply. Compare weeks with the same settings and write down the change before interpreting any result.

Choose up to five lead times or turn them all off.
Compare periods with the same sending policy.
Message volume is not an attendance target.

4. Write a clear request, not a promise

The configurable template should make three things easy to find: which appointment is scheduled, when it happens and how the client can ask for help. A short sentence reduces replies to the wrong number. Say that the team can cancel or reschedule through the available channel, but do not offer self-service if that public flow does not exist in the application.

The message may invite a “yes” or a change request, but the team must check the channel and operate the schedule through its own workflow. Bia has separate actions for rescheduling, cancelling, completing and recording a no-show; a WhatsApp reply does not automatically move the appointment. Naming this boundary prevents the front desk from waiting for an update that will never happen.

Review the copy with an operational question: would someone who reads only this message know what to do next? Remove artificial urgency, a guaranteed slot and unsupported results. If the clinic has a deposit or cancellation policy, it must match the Terms and real procedure; this guide does not invent billing or turn a reminder into legal acceptance.

Show service, date, time and reply channel.
An invitation to reply does not change the schedule alone.
Do not promise nonexistent self-service, availability or results.

5. Respect quiet hours and eligibility

An appointment can be correct and still not be ready for a message. Clinic settings store the start and end of quiet hours in the clinic time zone. Processing checks the time before delivery and records when work was suppressed. This protects the client experience and gives the team a verifiable reason not to push a notice at the wrong hour.

Eligibility is checked again close to delivery. Opt-out, blocking, a missing phone or an appointment that is no longer confirmed can prevent sending. The schedule distinguishes pending, sent, quiet-hour suppression, skipped because it is past and cancellation after rescheduling or cancellation. An empty message list does not automatically mean that the server failed.

When a reminder does not arrive, first inspect the job state, configured lead times, time zone, quiet hours and connected channel. Only then investigate a provider failure. Repeating a send without understanding the state can duplicate contact or violate an opt-out. Record the exception and hand it to a person when the operation needs judgment.

Read the job state before sending again.
Opt-out and blocking override the automatic cadence.
Quiet hours are policy, not a delivery bug.

6. Treat cancellation and rescheduling as new facts

An appointment that changes time should not keep receiving the old reminder. The rescheduling flow checks lead time, availability and conflicts, updates the date and increments the reschedule count. It then marks pending jobs for the old time as cancelled by rescheduling, while the new appointment calculates the reminders allowed by policy.

On cancellation, the operation writes its own state, stores a reason when supplied, cancels pending jobs and may begin an offer for a compatible waitlist entry. That is different from recording a no-show after the start time. Choose the right fact so the schedule, reports and old messages do not count the same situation twice.

The product applies a rescheduling limit when settings define one; it does not turn a conversation into automatic confirmation. If a client asks for another day, the team chooses an available time and saves the reschedule. Without persistent RSVP, public copy must say so even if the message uses “confirm” as an invitation.

Rescheduling cancels old jobs and calculates new ones.
Cancellation and no-show are different operational states.
A WhatsApp reply still requires a team action.

7. Check what happened in the schedule

Automatic confirmation is useful only when the team can explain what happened afterward. In the schedule, inspect the appointment, related reminders and current state before changing anything. The interface labels each configured lead time and distinguishes pending, sent, failed, suppressed and cancelled. This trail is better than trusting an outbox without context.

At the end of the day, separate completed appointments, cancellations, reschedules and no-shows. A no-show can be marked only after the start and when a confirmed appointment was not completed; the action cancels pending jobs and records an audit. A client who replied “yes” on WhatsApp still appears as confirmed because the system has no separate field to persist that answer.

Choose a reproducible measure: confirmed appointments, sent notices, cancellations reported and recorded no-shows. Declare the denominator, interval and time zone. Do not compare a week with a policy of up to five lead times to a week in which the team disabled the cadence. History helps the clinic learn, but a small sample is not proof of an outcome.

Use job state and appointment state together.
Separate completion, cancellation, rescheduling and no-show.
Declare the rule, period and time zone for each metric.

8. Finish with human review and honest limits

A simple routine has three moments. At the start of the day, the receptionist reviews times, conflicts, blocks and confirmed appointments. Before sending windows, she checks settings and exceptions. After appointments, she classifies completed, cancelled, rescheduled or missed. Automation removes repetition; the team keeps the decision that code cannot infer.

If the clinic needs to know who replied, accept a “yes” with one click, offer self-scheduling or calculate a confirmation rate, record that need as product work. Do not change the meaning of `status`, promise the feature in sales copy or collect a clinical reply in an improvised field. A well-described opportunity is safer than selling a capability that does not exist.

Bia provides configurable reminders, idempotent jobs, eligibility controls, cancellation, rescheduling and visible states. It does not guarantee that a client read, replied or will attend. The owner can test with real clinic times and compare real data, but should keep human review until a separate RSVP contract exists with migration, tenant isolation and its own proofs.

Automation organizes signals; it does not guarantee attendance.
The RSVP gap is recorded, never hidden.
Human review closes each appointment cycle.

What this guide does — and does not promise

It explains reminders and states that already exist in Bia. It does not invent persistent RSVP, a confirmation percentage, self-scheduling, testimonials or an attendance guarantee.

Bia schedules up to five clinic-selected lead times, but it does not currently store a client's confirmation response.
`status = confirmed` means an active appointment used by legacy reports and constraints; it is not RSVP.
Delivery depends on settings, time zone, quiet hours, opt-out, blocking, phone data and a connected provider.
Cancellation and rescheduling stop old jobs, but a WhatsApp reply does not move the appointment by itself.
No metric in this guide guarantees financial, clinical or attendance results.

Frequently asked questions

Questions about confirmations and reminders

Does Bia confirm an appointment on its own?

It schedules up to five lead times chosen by the clinic and checks eligibility before delivery. The product does not currently persist an RSVP to know whether the client replied or accepted.

Can I use only one lead time?

Yes. Settings allow any combination of up to five lead times from 72, 48, 24, 3, 2 and 1 hours, or all of them off. Compare results only across periods with the same policy and time zone.

What happens when a client asks to reschedule?

The team chooses an available time and uses the rescheduling flow. Pending jobs for the old time are cancelled and the new appointment calculates reminders again.

Why was a reminder not sent?

Check job state, time, quiet hours, settings, opt-out, blocking, phone data and the provider connection. A skipped or suppressed job is not necessarily a failure.

How can I measure whether reminders help?

Define the period, time zone, denominator and included states. Separate no-shows, cancellations, reschedules and completions; a sent message should not count as attendance.

Test the routine with your own appointment times

Create an account, configure reminders and observe the difference between a notice, a reply and the schedule's real state.

Create my account