Restaurant no-shows are not a guest behavior problem. They are a friction problem. A guest books on Tuesday for Saturday, gets four reminders nobody reads, plans change, the table sits empty. The restaurant absorbs the cost. In a typical 50-cover venue, no-shows account for 5–8 percent of weekend bookings — €40,000–€60,000 of foregone revenue per year.
The first instinct is pre-payment: charge the guest upfront, problem solved. Except it isn't. Pre-payment moves your conversion rate the wrong direction. A guest who is willing to spend €120 at your table is often not willing to wire €120 four days in advance to a restaurant they have never visited. You convert fewer bookings, your top of funnel shrinks, and the no-show problem comes back as a "didn't book at all" problem you can't see.
There is a calmer middle path: store the card, charge only if needed. Stripe calls it a SetupIntent — a €0 authorization that captures the payment method without taking any money. The guest agrees to a cancellation policy at booking time. If they show up, nothing happens. If they cancel inside the window, or no-show, you charge the agreed amount. You stay in the no-friction lane until the moment a guest actually costs you money.
This is what Tablario's Booking Policy plugin does.
Three modes, picked per shift
Booking Policy gives you three modes you can mix per shift, per party size, per channel:
- None. Default. No card, no policy, no friction. Lunch on a Tuesday, walk-ins, regulars — leave it off.
- Card Authorization. Stripe SetupIntent stores the card. €0 hold. Cancellation policy disclosed at booking. Charge issued only if the guest no-shows or cancels late. Use this for Friday/Saturday primetime, large parties, holidays.
- Deposit. SetupIntent + a real authorization for an agreed amount (typically €10–€20 per cover). Used for tasting menus, NYE, Mother's Day — events where you genuinely commit kitchen capacity in advance.
The crucial part is per-shift configuration. A no-show policy that runs on every booking annoys regulars. A no-show policy that runs only on Friday 19:00, only for parties of 6+, captures 80 percent of the value with 10 percent of the friction.
How the guest experiences it
When a Card Authorization policy is active, the booking flow gets one extra step. After the time and party size, the guest sees:
We hold your card for cancellations after Friday 17:00 or no-shows. We charge €25 per seat if you don't show. Your card is not charged otherwise.
They enter their card, Stripe runs the SetupIntent, the booking confirms. The card is stored against the booking on Stripe's side — never on Tablario's. You see "Card on file: ✓" in the dashboard.
If the guest cancels three days out, nothing happens. If they cancel two hours before, the dashboard prompts you with one click: "Charge €50 (2 covers × €25)?" You decide — the system does not auto-charge. We deliberately keep a human in the loop, because edge cases (guest had a real emergency, you'd rather build goodwill, the kitchen was overbooked anyway) come up more often than the marketing suggests.
Why we are deliberately not building auto-charge
Auto-charging on no-show is technically a one-line change. We have not done it because the data on it is bad. Restaurants that auto-charge see guest reviews collapse over a 6–12 month window. The financial recovery is real. The brand damage is real and longer-lasting. Most successful restaurants we talked to charge no-shows manually, and only after a 24-hour cooling-off window. That is the workflow we built for.
You can configure auto-charge later if you want it. Today, the prompt-with-one-click design is the default, on purpose.
How it actually reduces no-shows
The mechanism is not the charge. The mechanism is the moment of friction in the booking flow itself. A guest who enters a card has psychologically committed in a way that an email-only booking has not. Industry data and our own beta restaurants converge on the same number: introducing a card-on-file policy on primetime shifts reduces no-shows by 30–60 percent, with no measurable drop in booking volume on those shifts.
The card is a credibility check. The actual charge is rare. Restaurants that adopt the policy typically charge fewer than 2 percent of bookings — and even that small revenue stream is meaningful when it covers a portion of the kitchen's wasted preparation cost.
Where Tablario stores what
The card itself is stored at Stripe, against your Stripe Customer object. Tablario stores only the Stripe SetupIntent ID on the booking row. We do not log card numbers, expiration dates, CVCs, or BINs. The Stripe Customer Portal is available to your guests if they want to remove their card from their booking after the fact (we surface a "Manage your card" link in the confirmation email). All flows are PCI-DSS-compliant via Stripe, on EU infrastructure.
What this is not
- Not a payment plugin. This is a no-show plugin. There is no "pay your bill via Tablario" today. (See: KassenSichV, TSE, Phase 2.)
- Not membership. We do not store cards beyond the booking. Each booking is a fresh consent. If you want recurring memberships, that's a different feature you don't have yet.
- Not a substitute for double-confirmation. Reminder emails the day before still go out. The card is added insurance, not a replacement for hospitality.
Configuring it
In Tablario admin, Settings → Booking Policy:
- Pick a shift (or all shifts).
- Pick a mode (None / Card Auth / Deposit).
- Set the cancellation window (default: 4 hours before the reservation).
- Set the charge amount per cover.
- Optionally, restrict to a minimum party size.
Save. Active immediately. You can change it shift-by-shift as your restaurant's pattern evolves.
If you have not opted in, the default stays None — Tablario does not aggressively push you into a friction regime. You decide.
The Booking Policy plugin is part of Tablario's Phase 1 release. Stripe SetupIntent integration via the Stripe Connect platform; PCI-DSS handled at Stripe. Pricing on /preise. Cancellation policy text is per-restaurant configurable in DE/EN.