Angebote nachfassen: eine Follow-up-Maschine, die sich meldet, wenn sie ausfällt

Ein Angebot geht raus. Der Kunde bedankt sich, sagt, er schaue es sich in Ruhe an. Dann passiert nichts.

Mein CRM weiß das alles längst. Die Phase steht auf Angebot, der letzte protokollierte Kontakt liegt elf Tage zurück, beides liegt in der Datenbank. Nur unterbricht die Datenbank niemals meine Woche, um es zu erwähnen. Nachfassen ist in dem Moment, in dem es fällig wäre, niemandes Aufgabe. Am Tag, an dem man anrufen sollte, gibt es drei dringendere Dinge. Eine Woche später fühlt sich der Anruf schon unangenehm an. Nach drei Wochen ist das Angebot kalt.

Die übliche Antwort darauf ist eine Wiedervorlage im Kalender. Die funktioniert, bis man sie einmal wegklickt.

Manche CRMs schließen diese Lücke von Haus aus. Pipedrive erkennt liegengebliebene Deals, HubSpot kann Ähnliches über Workflows in den höheren Tarifen. Wer dort schon ist, braucht diese Maschine vermutlich nicht.

Ich betreibe ein selbst gehostetes CRM, EspoCRM, ohne das kostenpflichtige Advanced Pack. Damit gibt es keine eingebaute Workflow-Automatisierung. Also habe ich mir eine gebaut, für meinen eigenen Vertrieb. Das Folgende beschreibt, was sie tut, und vor allem, was beim Bau schiefgegangen ist.

Die Regeln

Sobald ein Deal in meinem CRM in die Phase Angebot oder Verhandlung wechselt, legt die Maschine drei Termine an: nach 5, 12 und 21 Werktagen. Werktage heißt wirklich Werktage: Die gesetzlichen Feiertage stehen in einer Tabelle, bei mir die österreichischen, erzeugt für die Region Tirol. Ohne diese Tabelle landet ein Termin auf dem 26. Oktober, und vier Tage lang passiert nichts.

Jede Stunde zwischen 7 und 19 Uhr, Montag bis Freitag, prüft sie jeden offenen Deal und sieht nach, welcher der folgenden vier Fälle zutrifft:

1. Der Deal ist gewonnen oder verloren. Die Beobachtung endet, alle offenen Termine entfallen.
2. Es gab seit dem letzten Mal Kontakt. Eine gesendete E-Mail, ein geführtes Telefonat, ein Treffen. Dann beginnt die Uhr von vorne, gerechnet ab diesem Kontakt.
3. Der Deal existiert nicht mehr. Die Beobachtung endet ohne Alarm.
4. Nichts davon, und ein Termin ist fällig. Dann entsteht eine Aufgabe in ClickUp, mit dem Link zum Deal.

„Kontakt“ ist dabei streng gemeint. Ein für nächste Woche geplanter Anruf ist kein Kontakt, und ein aufgeräumtes Feld am Deal auch nicht. Nur was tatsächlich stattgefunden hat, setzt die Uhr zurück.

Dazu kommen zwei E-Mails an mich. Dienstag bis Freitag um 8:45 eine kurze Liste, was heute fällig ist, aber nur, wenn etwas fällig ist. Und jeden Freitag um 15:45 eine Übersicht: was sich bewegt hat, was feststeckt, was geschlossen wurde.

Wo die KI hilft, und wo nicht

Der schwierigste Teil beim Nachfassen ist nicht das Erinnern. Es ist die Frage, womit man anfängt. Worum ging es zuletzt? Was war offen?

Deshalb liest ein zweiter Ablauf die letzten drei E-Mails zu jedem Deal und fasst sie in zwei Zeilen zusammen: worum es gerade geht, und welcher Aufhänger für das nächste Nachfassen sinnvoll wäre. Diese zwei Zeilen stehen in der Aufgabe und in der Morgenliste. Das Modell ist Mistral Small, und es antwortet in der Sprache der Korrespondenz.

Was die KI nicht tut: Sie schreibt keine E-Mails, und sie verschickt nichts. Die Maschine erinnert, ein Mensch schreibt. Eine automatisch formulierte Nachfrage erkennt man beim Lesen, und die Gegenseite erkennt sie auch.

Warum sie nichts in mein CRM schreibt

Die Maschine liest aus dem CRM, aber sie schreibt nie hinein. Ihren eigenen Zustand, also welche Deals beobachtet werden und welche Erinnerungen bereits ausgelöst wurden, hält sie in einer eigenen kleinen Datenbank.

Das war eine bewusste Entscheidung. Das CRM bleibt die maßgebliche Datenquelle. Wenn die Maschine kaputtgeht, geht dort nichts kaputt. Und wenn ihre Datenbank verloren geht, bleiben die Geschäftsdaten im CRM erhalten: Jede Stunde gleicht die Maschine ihre Liste mit dem CRM ab und legt fehlende Beobachtungen neu an. Was dabei nicht zurückkommt, ist ihr eigener Verlauf, also welche Erinnerung wann schon gelaufen ist.

Die wichtigste Regel: nicht still ausfallen

Eine Automatisierung, die leise stehen bleibt, ist schlimmer als keine. Man verlässt sich weiter auf sie, obwohl sie nichts mehr tut.

Deshalb hat die Maschine zwei Sicherungen. Erstens ist die Freitagsübersicht so gebaut, dass sie auch dann verschickt wird, wenn nichts zu berichten ist, und in ihrer Fußzeile steht, wann die stündliche Prüfung zuletzt erfolgreich durchgelaufen ist. Ein Lauf, der scheitert, zählt dabei nicht als Erfolg, auch wenn der Ablauf selbst noch aktiv ist. Liegt der letzte erfolgreiche Lauf mehr als 24 Stunden zurück, steht das in der ersten Zeile statt in der letzten. Zweitens schickt jeder Fehler eine Warnung, aber höchstens eine alle sechs Stunden pro Ablauf. Sonst erzeugt ein abgelaufenes Passwort über Nacht zwei Dutzend E-Mails, man richtet einen Filter ein, und der nächste echte Fehler landet ungelesen im Ordner.

Beides hat eine Grenze, die ich erst beim Schreiben von Teil 6 gefunden habe: Fällt die Datenbank aus, an der beide Sicherungen hängen, kommt weder die Warnung noch die Freitagsmail. Übrig bleibt dann nur die ausbleibende Mail als Signal.

Jeder Ablauf ist außerdem so gebaut, dass zweimal ausführen dasselbe ergibt wie einmal. Webhooks werden wiederholt, Zeitpläne überlappen, Netzwerke fallen aus. Ohne diese Eigenschaft entstehen doppelte Aufgaben, und nach der dritten doppelten Aufgabe glaubt man keiner mehr.

Was beim Bau schiefging

Geplant war ein halber Tag. Der erste Commit entstand am 28. Juli, die letzte Korrektur am 6. August. Einen Tag davon hat die KI-Zusammenfassung gekostet, die ich unterwegs dazugenommen habe. Der Rest ging größtenteils in Dinge, die auf dem Papier niemand vorhersieht: Sie zeigen sich erst, wenn echte Daten durch die Maschine laufen.

Die Maschine hat fünf Tage lang genau das ignoriert, wofür sie gebaut war. Mein Filter suchte nach der Phase „Proposal/Price Quote“. So heißt sie in SugarCRM, aber nicht in einer Standardinstallation von EspoCRM, wo sie schlicht „Proposal“ heißt. Jeder Deal in der Angebotsphase wurde also stillschweigend übergangen. Aufgefallen ist es fünf Tage lang nicht, weil mein Testdeal zufällig in der Phase Verhandlung stand, und die funktionierte.

E-Mails und Anrufe haben ihr Datum in verschiedenen Feldern. Bei Anrufen und Treffen heißt es Startzeit, bei E-Mails Sendezeit. Die Maschine las zunächst nur die Startzeit. Weil der meiste Kontakt per E-Mail läuft, war das kein Randfall, sondern der Normalfall.

Ein Komma in einem deutschen Satz hat einen Schreibvorgang zerstört. Die erste echte Zusammenfassung der KI enthielt zwei Kommas. n8n trennt bestimmte Datenbankparameter an Kommas, auch innerhalb des Textes. Die Datenbank bekam einen halben Satz, wo sie eine Zahl erwartete.

Der Error Workflow hat nicht ausgelöst. Laut Dokumentation von n8n muss ein Workflow mit Error Trigger nicht aktiviert sein. In der Version, die ich einsetze, hat ein inaktiver keine Warnung erzeugt, als ein geplanter Lauf scheiterte. Er muss eingeschaltet sein.

Keiner dieser Fehler war schwer zu beheben. Aufschlussreich ist, wie sie sichtbar wurden. Nur das Komma hat einen Fehler ausgelöst und damit eine Warnung. Der falsche Phasenname und das falsche Datumsfeld haben nichts ausgelöst: Die Maschine lief fehlerfrei und tat einfach weniger, als sie sollte. Der inaktive Error Workflow war der schlimmste der drei, denn er hat den Melder selbst abgeschaltet. Gefunden habe ich diese drei nur, weil ich mit echten Deals getestet habe, Fall für Fall.

Das ist die eigentliche Lehre.

Fehlermeldungen machen Abstürze sichtbar. Gegen eine Maschine, die fehlerfrei das Falsche tut, hilft nur ein Test mit echten Daten.

Selbst bauen oder kaufen

Wenn Ihr CRM liegengebliebene Deals schon selbst erkennt, nehmen Sie das. Es ist weniger zu warten.

Sonst passt diese Maschine zu Betrieben mit einem selbst gehosteten CRM, oder mit einem Einstiegstarif, der keine Automatisierung enthält. Nur ein kleiner Teil muss an das jeweilige CRM angepasst werden: sechs API-Abfragen in drei Abläufen und eine Liste mit Phasennamen. Die Regeln, die Werktage, die Berichte und der Schutz vor doppelten Aufgaben sind vom jeweiligen CRM unabhängig. Jedes CRM, das eine Liste seiner Deals über eine API ausgeben kann, lässt sich anschließen. Webhooks braucht es nicht, sie machen die Maschine nur schneller.

Der meiste Aufwand steckt ohnehin nicht darin, dass die Maschine läuft, sondern darin, dass man ihr trauen kann.

Was noch fehlt

Zahlen. Die Maschine läuft seit Anfang August, das ist zu kurz für eine ehrliche Aussage darüber, wie viele Angebote sie gerettet hat. Ich schreibe darüber, sobald es etwas zu berichten gibt.

Dieser Beitrag ist Teil 1 einer Serie. Die technischen Details, also die einzelnen n8n-Abläufe, die Datenbank und die Fehler im Einzelnen, finden Sie in den Teilen 2 bis 6.

Wenn Sie einen Ablauf in Ihrem Betrieb haben, der auf diese Weise liegen bleibt, erzählen Sie mir davon. Nachfassen ist selten der einzige.