Restaurant-No-Shows sind kein Verhaltensproblem von Gästen. Sie sind ein Friktionsproblem. Ein Gast bucht am Dienstag für Samstag, bekommt vier Erinnerungen, die niemand liest, Pläne ändern sich, der Tisch bleibt leer. Das Restaurant trägt die Kosten. In einem typischen 50-Plätze-Haus machen No-Shows 5–8 Prozent der Wochenend-Buchungen aus — 40.000–60.000 € entgangener Umsatz pro Jahr.
Der erste Reflex: Vorkasse. Lass den Gast vorab zahlen, Problem gelöst. Nur ist das Problem damit nicht gelöst. Vorkasse drückt deine Konversionsrate in die falsche Richtung. Ein Gast, der bereit ist, 120 € am Tisch auszugeben, ist oft nicht bereit, 120 € vier Tage im Voraus an ein Restaurant zu überweisen, das er nie besucht hat. Du konvertierst weniger Buchungen, dein Funnel verengt sich, und das No-Show-Problem kommt als „gar nicht erst gebucht"-Problem zurück, das du nicht mehr siehst.
Es gibt einen ruhigeren Mittelweg: Karte hinterlegen, nur bei Bedarf abbuchen. Stripe nennt das einen SetupIntent — eine 0-€-Autorisierung, die das Zahlungsmittel erfasst, ohne Geld einzuziehen. Der Gast stimmt bei der Buchung einer Stornierungsrichtlinie zu. Wenn er kommt, passiert nichts. Wenn er innerhalb der Frist storniert oder nicht erscheint, wird der vereinbarte Betrag eingezogen. Du bleibst auf der friktionsfreien Spur — bis zu dem Moment, in dem ein Gast dich tatsächlich Geld kostet.
Das macht Tablarios Booking-Policy-Plugin.
Drei Modi, pro Schicht wählbar
Booking Policy gibt dir drei Modi, die du pro Schicht, pro Personenzahl, pro Kanal mischen kannst:
- Keine. Standard. Keine Karte, keine Richtlinie, keine Friktion. Mittagessen am Dienstag, Walk-ins, Stammgäste — aus lassen.
- Kartenautorisierung. Stripe SetupIntent speichert die Karte. 0 €-Authorization. Stornierungsrichtlinie wird bei der Buchung offengelegt. Abbuchung nur bei No-Show oder verspäteter Stornierung. Verwende das für Freitag/Samstag-Primetime, große Gruppen, Feiertage.
- Deposit. SetupIntent + echte Autorisierung über einen vereinbarten Betrag (typisch 10–20 € pro Person). Eingesetzt für Tasting-Menüs, Silvester, Muttertag — Events, bei denen du tatsächlich Küchenkapazität im Voraus festlegst.
Der entscheidende Punkt ist die schichtweise Konfiguration. Eine No-Show-Richtlinie, die auf jede Buchung läuft, nervt Stammgäste. Eine, die nur Freitag 19:00, nur ab 6 Personen läuft, holt 80 Prozent des Werts mit 10 Prozent der Friktion.
Wie der Gast es erlebt
Wenn eine Kartenautorisierung aktiv ist, bekommt der Buchungsablauf einen zusätzlichen Schritt. Nach Zeit und Personenzahl sieht der Gast:
Wir hinterlegen Ihre Karte für Stornierungen nach Freitag 17:00 oder bei No-Show. Wir buchen 25 € pro Person ab, falls Sie nicht erscheinen. Sonst wird Ihre Karte nicht belastet.
Er gibt seine Karte ein, Stripe führt den SetupIntent aus, die Buchung bestätigt sich. Die Karte wird zur Buchung bei Stripe gespeichert — niemals bei Tablario. Du siehst „Karte hinterlegt: ✓" im Dashboard.
Wenn der Gast drei Tage vorher storniert, passiert nichts. Wenn er zwei Stunden vorher storniert, fragt das Dashboard mit einem Klick: „50 € einziehen (2 Personen × 25 €)?" Du entscheidest — das System bucht nicht automatisch ab. Wir halten bewusst einen Menschen in der Schleife, weil Sonderfälle (echter Notfall, du willst lieber Goodwill aufbauen, die Küche war ohnehin überbucht) häufiger auftreten, als Marketing es nahelegt.
Warum wir bewusst kein Auto-Charge bauen
Auto-Charge bei No-Show ist technisch eine einzeilige Änderung. Wir haben es nicht gebaut, weil die Datenlage dazu schlecht ist. Restaurants, die automatisch abbuchen, sehen ihre Bewertungen über 6–12 Monate einbrechen. Die finanzielle Erholung ist real. Der Markenschaden ist real und länger anhaltend. Die meisten erfolgreichen Restaurants, mit denen wir gesprochen haben, buchen No-Shows manuell ab — und erst nach einer 24-Stunden-Bedenkzeit. Auf diesen Workflow haben wir gebaut.
Auto-Charge kannst du später konfigurieren, wenn du es willst. Heute ist „Klick-zur-Bestätigung" der Standard, mit Absicht.
Wie es No-Shows tatsächlich reduziert
Der Mechanismus ist nicht die Abbuchung. Der Mechanismus ist der Moment der Friktion im Buchungsablauf selbst. Ein Gast, der eine Karte eingibt, hat sich psychologisch festgelegt — auf eine Weise, die eine reine E-Mail-Buchung nicht tut. Branchendaten und unsere eigenen Beta-Restaurants konvergieren auf dieselbe Zahl: Eine Kartenautorisierung auf Primetime-Schichten reduziert No-Shows um 30–60 Prozent, ohne messbaren Rückgang des Buchungsvolumens auf diesen Schichten.
Die Karte ist der Glaubwürdigkeitscheck. Die tatsächliche Abbuchung ist selten. Restaurants, die die Richtlinie einsetzen, buchen typischerweise weniger als 2 Prozent der Buchungen ab — und selbst dieser kleine Umsatz ist relevant, wenn er einen Teil der vergeudeten Küchenvorbereitung deckt.
Wo Tablario was speichert
Die Karte selbst wird bei Stripe gespeichert, am Stripe-Customer-Objekt. Tablario speichert nur die Stripe-SetupIntent-ID an der Buchungszeile. Wir loggen keine Kartennummern, Ablaufdaten, CVCs oder BINs. Das Stripe-Kundenportal ist deinen Gästen verfügbar, falls sie ihre Karte nachträglich von der Buchung entfernen wollen (wir blenden einen „Karte verwalten"-Link in der Bestätigungsmail ein). Alle Abläufe sind PCI-DSS-konform über Stripe, auf EU-Infrastruktur.
Was es nicht ist
- Kein Zahlungs-Plugin. Das ist ein No-Show-Plugin. Es gibt heute kein „Bezahl deine Rechnung über Tablario". (Siehe: KassenSichV, TSE, Phase 2.)
- Keine Mitgliedschaft. Wir speichern Karten nicht über die Buchung hinaus. Jede Buchung ist eine frische Einwilligung. Für wiederkehrende Mitgliedschaften brauchst du ein anderes Feature, das es noch nicht gibt.
- Kein Ersatz für die Doppelbestätigung. Erinnerungs-Mails am Vortag laufen weiter. Die Karte ist Zusatzversicherung, kein Ersatz für Gastfreundschaft.
Konfiguration
Im Tablario-Admin, Einstellungen → Buchungsrichtlinie:
- Schicht wählen (oder alle).
- Modus wählen (Keine / Karten-Auth / Deposit).
- Stornierungsfenster setzen (Standard: 4 Stunden vor der Reservierung).
- Betrag pro Person festlegen.
- Optional auf Mindestpersonenzahl beschränken.
Speichern. Sofort aktiv. Du kannst es schicht-für-schicht anpassen, wie sich das Muster deines Hauses entwickelt.
Wenn du nicht aktivierst, bleibt der Standard „Keine" — Tablario drängt dich nicht in ein Friktionsregime. Du entscheidest.
Das Booking-Policy-Plugin ist Teil des Phase-1-Releases von Tablario. Stripe-SetupIntent-Integration über die Stripe-Connect-Plattform; PCI-DSS bei Stripe. Preise auf /preise. Stornierungstexte sind pro Restaurant in DE/EN konfigurierbar.