RXed AI News

The cancellation fill engine: put someone in the slot that just opened

A waiting list that offers the freed slot by itself, with no ring-around and no double-booking

Reminders stop the no-show. They do nothing for the client who cancels honestly at 08:40 for a 09:00. That slot is a separate problem with a separate fix, and every booking platform sells the fix as a paid extra.

The problem

Start with the number, not the tool. Count your short-notice cancellations for one month. Six a week at a €55 average ticket is roughly €1,430 a month of empty chair. Fill half of them and you have recovered around €715 a month for an afternoon of setup. If your count is one a fortnight, stop reading and go build something else. That is the whole business case, and it is your number, not mine.

The manual version of this is the ring-around: your receptionist works down a list of people who once said "call me if anything opens up", makes six calls, gets two voicemails, and the slot is 40 minutes closer by the time anyone answers. Everyone selling salon and clinic software knows this, which is why waitlist automation sits behind the mid or top tier on every platform. Their marketing pages claim 60–70 % of cancellations get recovered. Treat that as marketing, because none of it is independently measured. Measure your own fill rate after four weeks and believe that number instead.

This blueprint is the other half of the no-show reminder engine. That one prevents the loss. This one recovers it. They run on the same box and share the same booking tool.

The architecture

Two containers you probably already run, plus one table. The design decision worth defending: the waiting list lives outside the booking tool. A waiting-list entry is intent, not a booking. It has its own lifecycle, it sits there for weeks, and you need to be able to delete it without touching anyone's calendar. Bolt it into the booking tool as a fake appointment and you will spend a year explaining ghost entries to your staff.

The one real decision: how you offer the slot

There are two mechanics and people argue about them as if it were taste. It is not, it is arithmetic on the clock.

Broadcast. Message everyone who matches, first to claim wins. Fastest fill. The cost is that everyone else gets "sorry, gone", and after the third one they stop opening your messages. Your list dies quietly.

Ladder. Offer to the single best match, give them a window, then move to the next. Nobody is disappointed, but it needs time you may not have.

The rule: let the time-to-slot decide. More than 12 hours out, run the ladder with a 60–90 minute window. Between 3 and 12 hours, ladder with a 20-minute window. Under 3 hours, broadcast, because no ladder finishes in time. Either way the claim link is single-use and exactly one workflow writes the booking. Two people tapping in the same second is not a freak event when you broadcast to thirty people.

Tool choices — and why

Easy!Appointments (GPL-3.0, 4,197 stars, last push 27/05/2026) is the booking tool this is written against, because it has the two things the engine needs and documents both: webhooks you configure from the admin UI with a secret header, and a REST API with a published OpenAPI file. Cal.diy works too if that is what you already run — the trade-offs between the two are in the no-show blueprint and have not changed.

The catch nobody mentions. Easy!Appointments fires webhooks on two events: Save (create or update) and Delete. There is no "cancelled" event. A cancellation reaches you as a Delete if the record was removed, or as a Save if someone flipped a status field. So your first n8n node cannot trust an event name — it has to hold the last known state of that appointment and compare. Second catch, reported in 2017 and still true: creating an appointment over the API needs a customerId, so the workflow looks the customer up by email first and creates them only if they are new. Build both of these on day one, not after the first double-booking.

n8n (Sustainable Use License — free for internal business use, 188,877 stars, last push 20/05/2026) is the engine. The work here is almost entirely waiting: a timer, a branch per outcome, a webhook that catches the claim. That is what n8n is good at, and a cron script is not. If you already run the reminder engine, this is a second workflow on the same instance, not a second server.

NocoDB (Sustainable Use License, 63k stars, release 2026.05.0 on 08/05/2026) holds the list. It gives you three things out of the box that matter here: a public form view for sign-ups, a grid your front desk can read and edit like a spreadsheet, and a REST API for n8n. Baserow does the same job if you prefer it. Do not use a spreadsheet file — two people editing it at once is exactly the failure this blueprint is meant to remove.

Monthly cost. Software €0 for all three. If the box already runs your booking tool or your invoice chasing, the marginal cost of this blueprint is €0. From scratch, one small VPS at roughly €5–12/month carries the lot. Email costs nothing on the mailbox you already pay for. SMS is the only real variable: optional, pay-per-message, roughly €0.01–0.10 depending on country — check current rates with your provider rather than trusting a number in a blog post. At 25 offers a month that is small change either way, and email-only is €0.

Setup outline

1. Build the table first. Columns: name, contact, service, preferred provider, days available, hours available, "how far can you travel at short notice", added-on date, last-offered date, status. Working when: your receptionist can add someone in under 20 seconds.
2. Publish the NocoDB form view as your public sign-up, and link it from the booking page for the case "no slots available". Working when: a test submission lands as a row.
3. Point the booking tool's webhook at an n8n webhook URL, with the secret header set. Working when: booking a test appointment produces a run in n8n.
4. Write the freed-slot detector: store the last known state per appointment, compare, and only continue when a slot actually opened. Working when: a normal edit produces no offer and a cancellation produces one.
5. Write the matcher: service, provider, day and hour window, minus anyone offered a slot in the last seven days. Rank oldest-on-the-list first. Working when: a cancelled Tuesday 09:00 colour returns only people who said Tuesday mornings and colour.
6. Build the offer step with a single-use token per offer, an expiry timestamp, and a claim webhook that checks-and-sets that one row before it books anything. Working when: tapping the same link twice books once and shows "already taken" the second time.
7. Wire the ladder timers per the rule above, and the broadcast branch for slots under three hours away. Working when: nobody claiming inside the window rolls to the next person by itself.
8. Run it on your own diary for a week before you point it at real clients. Then measure the fill rate for four weeks and write the number down.

Pitfalls — the real ones

The event name lies. Save and Delete are not "booked" and "cancelled". Compare state, always. A workflow that treats every Save as a cancellation will offer the same slot to your list every time a receptionist fixes a typo.
Double-booking is a race, not a bug you will notice. It shows up as one angry client, weeks apart, and it is nearly impossible to reproduce. Single-use token plus a conditional write on one row, on day one.
List fatigue kills this faster than any technical fault. Cap it: one offer per person per week, and never offer a slot that does not fit the window they gave you. A list that is messaged too often is not a list, it is a spam folder.
A waiting list is personal data with a purpose. Say what you will use it for at sign-up, keep it while the person still wants a slot, and delete after a defensible period of silence — 90 days is easy to justify. A slot offer is not a marketing channel; if you staple a promotion to it in the EU you have changed its legal nature. US senders using application SMS still need A2P 10DLC registration.
Match the provider, not just the hour. A cancellation frees a person and a room, and those are not always the same constraint. Offer a slot you cannot actually staff and you have converted a lost hour into a lost client.
Measure before you tune. If the fill rate is under 20 % after four weeks, the fault is almost always the data: people ticked "any time" at sign-up, so the matcher cannot rank anyone. Fix the form, not the workflow.

Verified repos

Easy!Appointments — GPL-3.0, 4,197 stars, last push 27/05/2026
n8n — Sustainable Use License (free self-hosted internal use), 188,877 stars, last push 20/05/2026
NocoDB — Sustainable Use License, 63k stars, release 2026.05.0 on 08/05/2026