How scheduling agents handle no-shows

Most scheduling automation handles the happy path reasonably well. A client requests a slot. The system checks availability. It confirms and sends reminders. For a large portion of bookings this is all that's needed, and there's clear value in not doing this manually.

The no-show is where things get more interesting.

It's not just one thing

When a client doesn't show up to a scheduled appointment, that single event actually contains several different situations that might call for different responses.

There's the first-time no-show from a long-term client who probably had a legitimate reason and will reschedule without prompting. There's the second no-show from a client who rescheduled three weeks ago after the last one. There's the no-show where the client contacted you that morning through a different channel and the scheduling system hasn't been updated. There's the no-show where the cancellation policy says a fee should be charged. There's the no-show from a client who is in the middle of an onboarding process that has already been delayed twice.

A scheduling agent that treats all of these the same — send one standard message, rebook the slot, mark as complete — will handle the common case fine and create friction in the edge cases.

What needs to be explicit

Before building a no-show handler, the questions that need answers are:

• At what point after the appointment start time is a client considered a no-show, versus just late?
• Does the no-show history of a particular client change how the response is handled?
• Is there a fee, and if so, under what conditions is it automatically charged versus manually reviewed?
• What does the agent do if the client contacts through another channel between the no-show and the automated follow-up?
• Who gets notified when a no-show occurs — just the client, or someone on your team as well?

These questions usually reveal that people handling this manually have developed rules they've never written down, because they evolved over time through experience.

The slot availability question

One thing that comes up often: what does the agent do with the now-empty slot? Marking it as available again is usually right, but it depends. If the appointment required preparation that another booking would duplicate, the slot shouldn't be offered immediately. If there's a waitlist, the agent might trigger a notification to the next person in it. If the slot is in a part of the day where rescheduling the same client is realistic, an immediate rebook offer makes more sense than releasing to the general pool.

None of this is technically complicated. All of it requires someone to make decisions about what the right behaviour is and then encode those decisions explicitly.

Where automation runs into limits

The cases where a no-show handler reliably creates problems are the ones involving client relationships that have context outside the scheduling system. A client who is going through something difficult, a long-standing relationship where the usual rules feel wrong to apply automatically, a client whose account is under internal review. The agent doesn't know about any of this unless the information is somewhere it can access.

The most practical approach is usually to automate the straightforward cases and surface everything else to a human with enough context to make a call. The agent flags the edge case, describes what it knows, and waits. A person handles it once. The outcome might teach you something that refines the edge case logic for next time.