Coworking-Buchungen automatisieren, ohne Aktionen doppelt auszuführen
Eine zuverlässige Automation ist mehr als „Wenn X passiert, tue Y“. Sie muss wissen, wann sie läuft, welche Bedingungen noch gelten und wie dieselbe Aktion sicher nur einmal ausgeführt wird.
Zwei Arten von Triggern, die nicht austauschbar sind
Ein Ereignis-Trigger reagiert auf etwas, das gerade passiert ist: Eine Buchung wurde bestätigt, ein Zahlungsstatus geändert oder ein Check-in abgeschlossen. Das Ereignis kennt bereits die betroffene Buchung und kann unmittelbar verarbeitet werden.
Ein zeitgesteuerter Trigger reagiert auf einen zeitlichen Bezug: 24 Stunden vor Anreise, jeden Morgen oder nach einer Frist. Er muss zum Ausführungszeitpunkt nach passenden Buchungen suchen. Ein beim Erstellen gestarteter Timer scheitert, wenn sich das Datum ändert oder ein Prozess neu startet.
Der Idempotenzschlüssel ist das eigentliche Design
Jobs werden wiederholt. Ein Worker kann eine E-Mail versenden und vor der Erfolgsmeldung abstürzen; beim nächsten Versuch ist der Versand unbekannt. Deshalb braucht jede Ausführung einen stabilen Schlüssel, zum Beispiel:
automation:{rule_id}:booking:{booking_id}:event:{event_key}Vor der Aktion wird dieser Schlüssel eindeutig registriert. Existiert er bereits, wurde dieselbe Absicht schon verarbeitet. Eine Suche nach „ähnlichen E-Mails“ reicht nicht, denn mehrere gültige Regeln können verschiedene Nachrichten zur gleichen Buchung senden.
Bedingungen sind Filter, keine Trigger
„Buchung bestätigt“ kann ein Trigger sein. „Zahlung offen“, „direkter Kanal“ und „Kunde hat eine E-Mail-Adresse“ sind Bedingungen, die unmittelbar vor der Aktion geprüft werden. So entstehen keine Dutzenden beinahe identischer Ereignisse, und übersprungene Ausführungen bleiben erklärbar.
Regeln sollen Dienste aufrufen, nicht nachbauen
Die Aktion „Check-in-Einladung senden“ muss denselben Dienst verwenden wie der manuelle Button. Dort sind Sprache, Vorlage, Linkablauf und Historie bereits definiert. Eine Kopie dieser Logik in der Automation entwickelt zwangsläufig ein abweichendes Verhalten.
Sinnvolle erste Regeln
- Bestätigung senden, wenn eine Buchung bestätigt wird.
- An offene Zahlungen vor Fälligkeit erinnern.
- Den Check-in-Link innerhalb eines konfigurierbaren Fensters senden.
- Das Team bei einer fehlgeschlagenen Pflichtaktion benachrichtigen.
- Nach einer abgeschlossenen Buchung Feedback anfragen.
Vor dem Aktivieren einer Regel
- Definiere einen Idempotenzschlüssel für genau eine Absicht.
- Speichere Trigger, Bedingungen, Ergebnis und Fehler in der Historie.
- Lege Einschränkungen als Bedingungen statt als neue Triggerarten an.
- Lass Aktionen den echten Produktdienst verwenden.
- Fehler müssen an einer Stelle erscheinen, die tatsächlich geprüft wird.