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.
Häufige Fragen
Was ist ein Idempotenzschlüssel und warum braucht ihn eine Regel?
Er ist die stabile Identität einer Ausführung, berechnet aus Regel, Trigger-Typ, Entität und dem Datum des Ereignisses. Geplante Trigger werden laufend neu ausgewertet – eine heute überfällige Rechnung ist es in fünf Minuten noch – ohne festgehaltenen Schlüssel geht dieselbe Erinnerung bei jedem Durchlauf erneut raus.
Wann ein geplanter Trigger statt eines Ereignis-Triggers?
Ein Ereignis-Trigger feuert, weil gerade in einem präzisen Moment etwas passiert ist: eine Buchung entstand, eine Zahlung kam an. Ein geplanter Trigger feuert, weil eine Bedingung mit der Zeit wahr wurde: ein Aufenthalt beginnt morgen, eine Mitgliedschaft läuft aus. Wer den Moment nicht benennen kann, braucht einen geplanten Trigger.
Kann eine Bedingung als Trigger dienen?
Nein. Bedingungen filtern die Kandidaten, die der Trigger bereits erzeugt hat; von allein bemerken sie nichts. Eine Regel mit dem Trigger „Mitgliedschaft läuft aus“ und einer Bedingung für einen bestimmten Tarif funktioniert. Eine Regel, die darauf hofft, von der Bedingung gestartet zu werden, läuft nie.