What Actually Happens When a Cancellation Comes In

Most waitlist software is described in terms of outcomes: "fill more cancellations," "recover lost revenue," "automate your waitlist." That's all fine. But if you're considering adopting a system, it's worth understanding what's actually happening under the hood — because the architecture determines the speed, and speed is what fills slots.

Here's the complete sequence, from the moment a client cancels to the moment the slot is confirmed with a new client.

Step 1: Detection (0–5 seconds)

The starting gun is the cancellation itself. When a client cancels through your scheduling software — Calendly, Acuity, Square, Google Calendar, Outlook — that platform fires a webhook: a real-time HTTP notification to any system listening.

FullSlot listens for that webhook. The moment it arrives, we parse it: what's the appointment type, who was the provider, what time was it, how long was it. That event triggers the rest of the flow.

Webhook-based detection is important because it's instantaneous. The alternative — polling your calendar every few minutes — introduces lag. At 2pm on a Thursday, a slot that's open at 4pm has a narrow recovery window. Every minute of lag is a minute of recovery window gone.

We also run a backup check. Webhooks occasionally fail — the scheduling platform has a hiccup, the payload is malformed, something times out. A periodic check catches anything the webhook missed. Nothing slips through.

Step 2: Classification (5–15 seconds)

Knowing that a cancellation happened is step one. Knowing what kind of cancellation it is — specifically, which waitlist it should route to — is step two.

This is harder than it sounds. Event titles in real calendars are not clean. They look like:

"Botox w/ Dr. Kim"
"Ashley 2pm facial"
"bx — 30 min"
"follow-up"

FullSlot reads the event title, duration, provider name, and any metadata from the webhook payload, then runs it through a matching pipeline:

1. Cache lookup. Has this exact pattern been seen before? If so, use the cached result — it's been confirmed by an operator or seen enough times to be reliable. 2. Keyword matching. Does the title contain a known keyword ("botox," "bx," "filler") that maps to a schedule? 3. Provider rules. Has the operator defined that Dr. Kim handles Injectables? If the provider name matches, use that. 4. Duration rules. A 30-minute slot is more likely to be a Botox appointment than a 60-minute facial. 5. Classification rules. Custom shorthand rules the operator has defined ("anything titled 'bx' that's 30 min = Botox").

If the match is high-confidence, the slot routes automatically. If the match is uncertain, the slot goes to the Review Queue for operator confirmation — it waits rather than going out wrong.

This is the intelligence layer that makes routing feel automatic. Every correction an operator makes gets remembered. Over time, the system needs less help.

Step 3: Waitlist Lookup (15–30 seconds)

Once we know which schedule the slot belongs to, we pull the waitlist for that schedule.

Waitlist entries are ordered. Clients who've been waiting longer rank higher by default. If the operator uses Priority Queue, VIP clients or high-priority entries get first access. The dispatch mode (broadcast to all vs. sequential priority) is determined by the schedule's settings.

We also check eligibility. A client who's already booked for that time slot shouldn't receive a notification. A client who's opted out of SMS shouldn't get a text. A client outside the operator's quiet hours window gets held until the window opens.

Step 4: Dispatch (30 seconds–2 minutes)

This is the part clients see.

Eligible waitlist clients receive a text message and/or email — depending on the operator's settings and the client's preferences. The message is short: a slot opened up, here's what it is, here's a link to claim it.

The claim link is unique per client per slot. Tapping it opens a lightweight confirmation page — no login required, no form to fill out. Tap, confirm, done.

The first client to claim locks the slot. Everyone else who taps the link afterward sees a "slot is no longer available" message and stays on the waitlist for next time. No awkward conversations. No two clients claiming the same slot.

If nobody claims within the claim window, the operator can re-notify remaining clients with one click — or extend the window — without starting the process over.

Step 5: Confirmation (immediate on claim)

The moment a client claims the slot, two things happen simultaneously:

1. The operator receives a notification — app, email, or both — that the slot was filled and by whom. 2. The slot status updates to "claimed."

Depending on the integration and plan, FullSlot can write the booking back to the scheduling software directly — creating the appointment in Calendly, Acuity, or Square without the operator having to do it manually. For integrations where direct write-back isn't available, the notification includes everything needed to complete the booking in under 30 seconds.

The Full Timeline

In practice, this entire sequence — detection through client claim — typically completes in under 5 minutes. Often faster.

The client who cancels doesn't need to do anything differently. They cancel through your normal booking page.

The client who claims doesn't need to call in, log in, or know anything about how the system works. They get a text, tap a link, and have an appointment.

You get a notification that your 4pm slot is filled, without having made a single call.

Why the Architecture Matters

The speed of this sequence is not incidental. A slot that opens at 2pm for a 4pm appointment has maybe a 90-minute viable fill window. After that, it's functionally unsellable — clients can't rearrange their afternoon on 30 minutes' notice.

A system that polls for cancellations every 5 minutes, takes 2 minutes to classify, and sends notifications in batches has already consumed a significant portion of that window before the first client hears about the opening.

FullSlot is designed around the constraint that cancellation recovery is a race with a hard deadline. The detection is instant. The classification is seconds. The dispatch is immediate. Every design decision in the pipeline reflects the same priority: reach the right clients as fast as possible, because fast is what fills slots.

What This Looks Like From Your Side

From the operator's perspective, the experience is: you get a notification that a slot was filled. Most of the time, you didn't do anything. The cancellation came in, the system handled it, and a client you already knew claimed the slot.

When the system needs help — an unusual event title, an ambiguous appointment type — it surfaces that to you in the Review Queue. You make a call, the system learns, and it handles that pattern automatically going forward.

That's the model: automation handles the routine, humans handle the exceptions, and the system gets more automated over time as exceptions become patterns.