Buchungsregeln, Anzahlungen & Quellen
Pro Restaurant lassen sich Anzahlungs- und Garantieregeln definieren, Reservierungstypen separat einstellen und jede Buchung einer Quelle zuordnen.
Restaurants vergeben Tische unter unterschiedlichen Bedingungen — eine Hochzeitsfeier braucht eine Anzahlung, ein Werktags-Lunch nicht. Onboard kennt drei Regeltypen, die du pro Restaurant und pro Reservierungstyp (Innen, Terrasse, Lounge …) frei kombinierst.
Drei Regeltypen
| Name | Type | Required | Default | Description |
|---|---|---|---|---|
| Frei | free | — | — | Keine Zahlungsangaben nötig. Standard für die meisten Tische. Stornierung jederzeit kostenfrei bis kurz vor der Reservierung. |
| Anzahlung | deposit | — | — | Gast zahlt einen festen Betrag oder einen Prozentsatz des erwarteten Umsatzes über Stripe. Bei No-Show wird die Anzahlung verrechnet. |
| Garantie | guarantee | — | — | Kreditkarte wird zur Garantie hinterlegt, aber nicht belastet, solange der Gast erscheint. Belastung erst bei No-Show in Höhe einer festgelegten Pauschale. |
Anzahlungs-Flow
Bei einer Buchung mit Anzahlung wird der Gast nach der Standard-Reservierungsmaske auf eine Stripe-Checkout-Seite weitergeleitet. Erst nach erfolgreicher Zahlung gilt die Reservierung als bestätigt — sonst läuft sie nach 15 Minuten automatisch ab. Die Bestätigungs-Mail enthält Betrag und Beleg.
Stornierungsfenster
Pro Regel definierst du, wie lange vor der Reservierung der Gast kostenfrei stornieren kann. Bei Anzahlungen liegt der Standard bei 48 Stunden — danach behält das Restaurant den Betrag. Spätere Stornierungen können trotzdem erstattet werden; der Admin entscheidet pro Fall.
Reservierungstypen
Ein benannter Slot-Typ (z.B. „Innen", „Terrasse", „Lounge"), der eine Untergruppe der Tische bündelt und eigene Öffnungszeiten, Kapazitäten und Regeln tragen kann.
Reservierungstypen sind in den Widget-Einstellungen aktivierbar. Wenn aktiv, sieht der Gast bei der Buchung eine Auswahl — und nur die Slots, die für diesen Typ verfügbar sind. Die KI-Buchungs-Schnittstelle liest dasselbe Schema und gibt dem agentischen Client die verfügbaren Typen zurück.
Quellen-Attribution
Jede Reservierung trägt eine source_id-Spalte, die auf einen Eintrag in reservation_sources verweist. Die Tabelle wird pro Restaurant geführt und enthält den Namen, einen Slug, eine Art (Direkt, Widget, KI-Agent, Telefon, Google …) und optional UTM-Parameter.
| Name | Type | Required | Default | Description |
|---|---|---|---|---|
| kind | 'direct' | 'widget' | 'ai-agent' | 'phone' | 'google' | 'other' | — | — | Grobe Quellklasse für Reports und Filter. |
| integration_name | string | — | — | Klarname des Konnektors, z.B. „ChatGPT", „Claude.ai Connector", „Concierge XY". |
| utm_source / medium / campaign | string | — | — | Optional. Wird vom Widget-Embed mitgelesen, falls vorhanden, und in Berichte gespiegelt. |
kind='ai-agent'-Eintrag pro Restaurant angelegt. Die alte source-Freitextspalte bleibt aus Kompatibilitätsgründen bestehen, neue Reports lesen aber source_id.