Die Regel, die um neun feuert: Was Firmspace prüft, bevor eine verzögerte Automatisierung handelt
Eine Regel im CRM sieht aus wie ein Reflex: Das Geschäft entsteht, die Regel antwortet. Interessant wird es dort, wo die Regel nicht sofort antwortet. Ein Geschäft erscheint um neun Uhr morgens, die Nachfassaktion ist auf zehn gesetzt. In dieser Stunde zahlt der Kunde, ein Kollege verschiebt das Geschäft in eine andere Phase, jemand schließt die Aufgabe. Eine Regel, die um zehn feuert, ohne erneut in die Welt zu schauen, ist keine Automatisierung, sondern eine Quelle von Nachrichten über Dinge, die nicht mehr stimmen.
Firmspace speichert einen verzögerten Schritt als Datensatz und nicht als Timer in einem offenen Browser-Tab. Trifft ein Ereignis auf eine Regel mit Verzögerung, schreibt die Engine einen Automatisierungsjob: die Firma, die Regel, eine Kopie der Ereignisdaten und den Zeitpunkt, zu dem die Aktion fällig ist. Der Job überlebt einen geschlossenen Laptop, einen neu gestarteten Server und eine Woche Urlaub, weil er in der Datenbank lebt. Ein täglicher Hintergrundlauf holt ab, was fällig ist; derselbe Lauf überführt überfällige Rechnungen in ihren Status, erzeugt Rechnungen aus wiederkehrenden Vorlagen, verschickt Zahlungserinnerungen und aktualisiert Postfächer, und jeder dieser Schritte läuft getrennt, damit ein fehlgeschlagener Schritt die anderen nicht abbricht.
Das Erste, was eine verzögerte Aktion vertrauenswürdig macht, ist, dass sie nicht zweimal passieren kann. Jeder fällige Job wird mit einem bedingten Update übernommen: Der Datensatz wird in einer Anweisung von nicht erledigt auf erledigt gesetzt, und nur der Abruf, der die Zeile geändert hat, macht weiter. Fragen ein Cron-Server, eine zweite Anwendungsinstanz und eine offene Seite im selben Moment, erhält einer die Zeile und die übrigen erhalten nichts. Die Drosselung im Arbeitsspeicher, die begrenzt, wie oft die Jobs einer Firma geprüft werden, spart nur Abfragen; die Korrektheit hängt nicht von ihr ab. Ein Lauf nimmt bis zu fünfundzwanzig fällige Jobs, damit sich ein Rückstand allmählich abbaut, statt eine Anfrage zu sprengen.
Das Zweite ist, dass die Regel im Moment der Aktion erneut gelesen wird und nicht aus dem Moment des Ereignisses erinnert wird. Wurde die Regel gelöscht oder abgeschaltet, während der Job wartete, wird der Job ohne Meldung verworfen. Hat jemand den Text geändert oder die Phase gewechselt, nutzt der Job die aktuelle Fassung für seinen Text, behält aber die Ereignisdaten, mit denen er entstanden ist. Das ist eine bewusste Trennung: Die Fakten des Ereignisses ändern sich nicht nachträglich, die Absicht der Firma schon.
Das Dritte ist die Phasenprüfung. Eine Regel kann an eine Phase gebunden sein, und bei Geschäftsereignissen vergleicht die Engine die in der Regel gespeicherte Phase mit der Phase des Geschäfts im Augenblick. Ein Geschäft, das weitergezogen ist, wird nicht erinnert, und das Journal notiert einen übersprungenen Lauf mit dem schlichten Satz, dass das Geschäft diese Phase verlassen hat. Diese eine Prüfung beseitigt den größten Teil des Unsinns, der das Vertrauen in Automatisierung ruiniert: Nachfassaktionen für gewonnene Geschäfte, Erinnerungen für Kunden, die längst gezahlt haben, Aufgaben für gelöschte Datensätze.
Verzögerungen haben vier Stufen — sofort, nach einer Stunde, nach einem Tag und nach drei Tagen — und sie gehören zur Regel, nicht zur Nachricht. Die Aktionen selbst sind bewusst gewöhnlich: eine Benachrichtigung, eine Aufgabe, eine Notiz am Geschäft oder am Kontakt, ein Phasenwechsel, eine E-Mail, ein Webhook und der Schritt KI-Aktion. Jede Aktion liefert eine kurze Zeile darüber, was sie getan hat, und genau diese Zeile liest die Person später im Journal.
Text in einer Regel kann das Ereignis und die eigenen Konstanten der Firma ansprechen: den Kundennamen, den Phasennamen, die Belegnummer, einen Wert aus dem Abschnitt Konstanten, eine Variable, die sich mit der Zeit ändert. Eine Belegnummer wird für Rechnung, Auftrag, Angebot und Vertrag gleich gefüllt, daher braucht eine einzige Regel über Nummern keine vier Varianten. Fehlt ein Wert, setzt die Vorlage eine leere Zeichenkette ein statt eines übrig gebliebenen Platzhalters, und wenn die Nachricht selbst leer ist, dient der Name der Regel als Rückfall.
Fehler werden absichtlich eingegrenzt. Eine Aktion, die nicht ausgeführt werden kann, landet mit Fehlerstatus und kurzer Begründung im Journal, und der Vorgang, der das Ereignis ausgelöst hat, gelingt trotzdem — ein Geschäftsabschluss, eine Rechnungsmail oder eine eingehende Nachricht darf nicht daran scheitern, dass kein Postfach verbunden ist. Die Gründe sind konkret und lesbar: kein verbundenes Postfach, ein Kunde ohne E-Mail-Adresse, eine Zielphase, die es nicht mehr gibt, ein gelöschtes Geschäft, eine Webhook-Adresse ohne https oder mit einem Ziel im privaten Netz, ein KI-Schritt, den der Tarif der Firma nicht mehr enthält, oder ein Tageskontingent, das bereits aufgebraucht ist.
Die KI-Aktion verdient einen eigenen Satz, denn sie ist der einzige Schritt, in dem ein Modell entscheidet, was zu tun ist. Sie läuft mit den Rechten des Firmeninhabers, wie die übrigen Aktionen, und darf pro Auslösung höchstens eine schreibende Operation ausführen. Sie darf zuerst lesen — einige Abfragen, um die richtige Person oder den richtigen Datensatz zu finden —, aber in dem Moment, in dem sie schreibt, endet der Lauf. Die Anweisung sagt ihr, dass Text in CRM-Datensätzen Daten sind und keine Befehle, und dass sie bei Unsicherheit nichts tun und in einem Satz begründen soll. Der Schritt verbraucht außerdem das Tageskontingent der Firma, dasselbe, das der Chat nutzt, damit eine den ganzen Tag feuernde Automatisierung den Assistenten nicht aushungert.
Eine berechtigte Frage ist, ob eine Regel sich selbst erneut auslösen kann. Die gewöhnlichen Aktionen ändern Datensätze direkt und melden dasselbe Ereignis nicht an die Engine zurück, und die Engine markiert ihren eigenen Lauf, damit sie innerhalb dieser Auslösung nicht erneut in den Abgleich eintritt. Eine Kette entsteht also nicht aus Reflexen. Die KI-Aktion ist die Ausnahme, die man beobachten sollte: Wenn sie tatsächlich eine Rechnung über die Werkzeuge der Firma versendet, ist das ein echtes neues Ereignis, und andere Regeln hören es, genau als hätte eine Person den Knopf gedrückt. Daraus folgt die praktische Regel: Verzögerte Schritte um einen Fakt herum schreiben, der einmal wahr wird — eine Aufgabe existiert, eine Notiz ist angehängt, die Phase hat sich geändert — und nicht um die Hoffnung, dass das Modell sich erinnert.
Das Journal behält die zweihundert jüngsten Einträge pro Firma, jeweils mit Datum, Name der Regel, Status und einer auf dreihundert Zeichen gekürzten Meldung. Es beantwortet die Frage, die man am Morgen danach tatsächlich stellt: Was haben die Regeln um neun getan, und was haben sie abgelehnt zu tun. Es ist kein Buchhaltungsregister und nicht als Beweis für eine Steuerprüfung gedacht; es ist das Notizbuch der Automatisierung und wird bewusst gekürzt.
Nichts davon ersetzt Urteilsvermögen. Eine verzögerte Regel braucht weiterhin einen Phasenfilter, wenn die Phase zählt, eine klare Aktion statt fünf und einen Blick ins Journal nach der ersten Auslösung. Die nützlichsten verzögerten Automatisierungen in einer kleinen Firma sind die langweiligen: eine Aufgabe einen Tag vor einer Frist, eine Notiz nach der Unterschrift unter einem Vertrag, ein Phasenwechsel eine Stunde nach dem Versand eines Angebots. Es sind Versprechen, die die Firma sich selbst gibt, und das CRM hält sie ein, indem es die Welt prüft, bevor es handelt, statt zu hoffen, dass die Welt stillgestanden hat.