How a no-show gets handled

The deposit only matters on the day

Everything so far — the hold, the link, the confirmation, the release — exists to get a real, committed booking onto the calendar. But the deposit itself only does its final job on the day of the appointment, and it does one of two things. If the customer turns up, the deposit is theirs: it comes off the final bill, exactly as the message promised, so it never feels like a charge, just money paid early. If the customer doesn’t turn up, the deposit is forfeit — that’s the whole point of taking it, and it’s what makes the no-show cost the customer something instead of costing the business the slot. Settlement is the step that carries out whichever of those two the day actually delivers.

The important design choice here is that attendance is a recorded fact, not an inference. The system does not try to work out whether someone came — it has no way to, and guessing about money is exactly the wrong instinct. Instead, front-of-house tells it: a tap on the booking (“seated”, “arrived”, “started”) posted back through the intake surface marks the booking attended. A booking that reaches the end of its appointment window with no such mark is, by definition, a no-show. Making attendance an explicit signal keeps the settlement honest and auditable: there is always a clear reason on the record for why a deposit was applied or forfeited.

A rule, not a judgement

How a deposit settles is set once, in the policy, and applied the same way every time. The settings doc holds the business’s no-show terms — the ones the customer agreed to when they paid: apply the deposit to the bill on attendance, forfeit it in full on a no-show, or a softer variant like a grace window or a partial forfeit for a late cancellation. Whatever the rule, it’s deterministic Python. The settlement step reads the booking’s outcome (attended or not, cancelled or not, and when), looks up the matching policy branch, and does exactly what it says. This is the sharpest example of the whole system’s division of labour: Bedrock phrases the messages around all of this, but it is nowhere near the decision to keep or return someone’s money. A model must never decide a forfeit, because a forfeit is a financial action a business has to be able to defend, and “the AI decided” is not a defence.

A settlement sweep — the same EventBridge Scheduler pattern as Part 4 — runs after appointment windows close and settles each confirmed booking once. For an arrival, it marks the booking APPLIED: the deposit is credited against the bill (or simply noted as already taken, depending on how the till works) and a short thank-you can go out. For a no-show, it marks the booking FORFEITED, records the amount and the reason, and — because a forfeited deposit is the one message most likely to prompt a reply — sends the customer the plain, policy-worded note they agreed to, and drops a line into the handover inbox so the business has a record and a chance to soften it for a good regular. The state field makes this exactly-once, just like every other transition: a booking settles a single time and can’t be both applied and forfeited.

The human side of a forfeit

A forfeited deposit is the one outcome most likely to end in a conversation, so the system is built to hand that conversation to a person rather than have the last word itself. When a deposit is forfeited, the customer gets the plain note they agreed to — no arguing, no automated back-and-forth — and the business gets a line in the handover inbox with the whole history: when they booked, that the deposit was paid and confirmed, that the slot went unused, and the exact policy applied. If the customer replies “I was in hospital” or “I cancelled hours ago, check your messages”, that reply goes straight to a human, who can waive or refund the forfeit with a click. The system enforces the policy consistently; a person retains the discretion to be kind. That balance — firm by default, human by exception — is what lets a small business take deposits without feeling like it’s treating its regulars as suspects.

The same discretion covers the genuinely awkward cases. A double-booking that somehow slipped through (it shouldn’t, given Part 2, but belt and braces), a customer who paid but whose slot was cancelled by the business itself, a partial-refund request — none of these are settled by rule, because none of them should be. They’re recorded and escalated, with the full booking and payment history attached, for someone to resolve and, where needed, issue a refund through the payment provider by hand. The system’s job ends at making the routine outcomes automatic, correct, and defensible; the exceptions are exactly where a human belongs.

All posts