Zum Inhalt springen
Pilotphase – noch kein kommerzielles Angebot. Die ersten 500 Nutzer arbeiten kostenlos mit und geben uns Feedback zur Verbesserung. Die erste Tarifrunde startet im Mai 2027
Firmspace
Zurück zum Blog

Die Regel, die drei Tage wartet — und den Status erneut prüft

Die meisten Automatisierungsregeln in einem CRM sollen sofort greifen: Ein Deal wechselt die Spalte und eine Aufgabe erscheint, eine Rechnung wird bezahlt und die Buchung entsteht. Manche Schritte sind aber erst nach einer Pause sinnvoll. Firmspace erlaubt deshalb eine Aktion sofort, nach einer Stunde, nach einem Tag oder nach drei Tagen. Interessant ist nicht das Warten, sondern das, was das System am Ende der Wartezeit tut.

Der Auslöser bleibt ein Ereignis. Deal-Status sind ein Fall, in dem das zählt. Wechselt ein Deal die Spalte, hält das CRM fest, um welchen Deal es geht und welche Spalte erreicht wurde, dazu Kontakt und verantwortliche Person. Die Regel passt auf den Ereignistyp und optional auf genau eine Spalte. Deshalb lässt sich eine Regel an 'Angebot gesendet' binden, ohne jede andere Bewegung auf dem Board mitzunehmen.

Ist die Verzögerung länger als null, liegt die verzögerte Aktion nicht in einem Browser-Tab. Das CRM schreibt einen Auftrag: die Regel, eine Kopie des Ereignisses und den Zeitpunkt der Fälligkeit. Der Tab darf geschlossen werden, das Notebook darf schlafen, die Person, die die Karte bewegt hat, darf in Urlaub gehen. Der Auftrag bleibt in der Datenbank.

Die Warteschlange wird vom täglichen Server-Cron geleert und zusätzlich, wenn die Anwendung Benachrichtigungen prüft; die Benachrichtigungsprüfung ist auf einen Durchlauf alle zwanzig Sekunden pro Firma begrenzt und nimmt bis zu fünfundzwanzig fällige Aufträge mit. In der Praxis greift eine Drei-Tage-Regel beim nächsten Durchlauf nach der Frist, nicht auf die Minute genau. Für ein Vertriebs-Follow-up ist das in Ordnung. Für eine Zahlungsfrist nicht — dafür gibt es die Zahlungserinnerungen.

Vor der Ausführung wird die Regel erneut gelesen. Wurde sie in der Wartezeit gelöscht oder abgeschaltet, passiert nichts. Eine Regel, die es nicht mehr gibt, darf keine E-Mail verschicken, die niemand erwartet.

Bei Deal-Ereignissen kommt eine zweite Prüfung dazu. Der Deal wird geladen und mit der Spalte verglichen, für die die Regel geschrieben wurde. Hat er sich weiterbewegt, wird der Auftrag mit einer kurzen Zeile im Protokoll geschlossen: übersprungen, der Deal hat die Spalte verlassen. Das ist der Unterschied zwischen einer Erinnerung und einer Warteschlange veralteter Nachrichten. Wer längst unterschrieben hat, braucht keine Nachfrage zum Angebot.

Der Auftrag wird mit einem bedingten Update beansprucht: Nur ein Arbeiter kann 'nicht erledigt' in 'erledigt' ändern. Fragen zwei Tabs, zwei Mitarbeitende oder zwei Serverinstanzen im selben Moment, gewinnt eine und die anderen ziehen weiter. Ohne das könnte eine verzögerte E-Mail doppelt rausgehen — ein Fehler, der in der Datenbank billig zu verhindern und beim Kunden teuer zu erklären ist.

Eine verzögerte Regel kann auch eine KI-Aktion tragen. Der Assistent erhält die Ereignisdaten und die Anweisung der Firma, darf Datensätze lesen, um die richtige Person oder den richtigen Deal zu finden, und darf höchstens ein schreibendes Werkzeug ausführen. Vier Schritte sind die Obergrenze. Er arbeitet mit den Rechten des Inhabers, weil nachts niemand bestätigen kann — genau deshalb sollte die Anweisung eng sein: Deal prüfen und eine Nachfassnotiz vorbereiten, nicht den Kunden bearbeiten.

Daraus folgen zwei Grenzen. Die KI-Aktion verbraucht dasselbe Tageskontingent wie der Chat, und der Tarif der Firma muss den autonomen Automatisierungsschritt enthalten; ohne ihn stoppt die Regel mit einer klaren Meldung, statt zu improvisieren. Lesende Werkzeuge hinterlassen keine Spuren in den Daten; nur der eine Schreibvorgang kann einen Datensatz ändern.

Jeder Lauf hinterlässt eine Zeile im Automatisierungsprotokoll von Firmspace CRM: Regelname, Datum, Erfolg oder Fehler und eine kurze Meldung — was gesendet, welche Aufgabe erstellt, warum die Regel übersprungen wurde. Das Protokoll behält die letzten zweihundert Einträge. So beantwortet eine Firma die Frage 'hat das System es wirklich getan?' ohne Server-Logs.

Das Muster, das funktioniert, ist einfach: Verzögern Sie dort, wo ein Mensch ohnehin warten würde. Einen Tag nach dem Angebot eine Follow-up-Aufgabe für die verantwortliche Person. Drei Tage vor Vertragsbeginn die Prüfung, ob die unterschriebene Fassung vorliegt. Die Verzögerung macht die CRM-Automatisierung nicht klüger. Sie lässt sie wie eine Kollegin wirken, die sich erinnert, zurückzukommen.

Automatisieren wir Ihren nächsten Prozess gemeinsam.

Beschreiben Sie uns einen wiederkehrenden Arbeitsablauf. Wir prüfen gemeinsam, ob und wie sich dieser sinnvoll automatisieren lässt.