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

Der Test-Knopf: Was ein Regel-Lauf mit einem Testkunden wirklich tut

Wer eine Automatisierungsregel baut, zögert vor dem Einschalten. Die Regel wird E-Mails an Kunden schicken, Deals verschieben und einen Webhook aufrufen — und ein Fehler wiederholt sich bei jedem passenden Datensatz. Firmspace setzt neben jede Regel einen Test-Knopf. Er ist nützlich, aber er ist keine Sandbox, und der Unterschied lohnt zwei Minuten.

Was der Knopf tut. Er schickt eine Anfrage mit der Id der Regel, und die Automatisierungs-Engine des CRM führt die Aktion dieser Regel sofort und einmalig mit einem festen Beispieldatensatz aus. Das Beispiel ist immer dasselbe: ein Deal namens Test deal, in der Phase Test stage, mit einem Kontakt Test Client, leerer Id und leerer E-Mail-Adresse, dazu eine Beispielaufgabe, eine Nachricht und ein Absender. Der Test sucht sich keinen Ihrer Datensätze aus. Was danach passiert, entscheidet die Aktion.

Drei Aktionen scheitern absichtlich, und die Meldung erklärt, warum. Deal verschieben scheitert, weil das Beispiel keinen echten Deal hat — die Engine antwortet, dieses Ereignis habe keinen Deal zum Verschieben. Notiz hinzufügen scheitert aus demselben Grund: Es gibt nichts, woran sie hängen könnte. Eine E-Mail an den Kunden scheitert, weil der Testkunde keine Adresse hat. Ist der Empfänger dagegen der Inhaber, geht die Nachricht wirklich an den Inhaber. Das ist kein kaputter Test, sondern ein Test, der ehrlich sagt, dass die Regel echte Daten braucht.

Drei Aktionen laufen wirklich. Eine Benachrichtigung erscheint für die ganze Firma, weil der Test dieselbe Benachrichtigung auslöst wie die Regel. Eine Aufgabe entsteht — eine echte Aufgabe in der Aufgabenliste, mit dem Text der Regel und dem Inhaber als Verantwortlichem. Ein Webhook wird tatsächlich aufgerufen: Die Anfrage verlässt das CRM und geht an die Adresse aus der Regel, die mit https beginnen und auf einen öffentlichen Host zeigen muss. Und die KI-Aktion ruft das Modell auf und kann einen echten Schreibvorgang ausführen.

Die ausgeschaltete Regel ist ein Sonderfall — im guten Sinn. Der Testpfad führt die Regel direkt aus, ohne zu fragen, ob sie eingeschaltet ist, und ohne Phasenfilter. Man kann eine Regel also testen, während sie noch aus ist — genau dann will man es. Der echte Ereignisfluss ist strenger: Eine ausgeschaltete Regel wird übersprungen, und eine an eine Phase gebundene Regel feuert nur in dieser Phase.

Wohin das Ergebnis geht. Jeder Lauf, ob Test oder echt, schreibt eine Zeile ins Regel-Log: Name der Regel, Datum, Erfolg oder Fehler und die Meldung der Aktion. Die Meldung wird nach 300 Zeichen abgeschnitten, und das Log behält die letzten 200 Einträge — es ist ein Journal, kein Archiv. Der Bereich dafür heißt Test Logs, zeichnet aber auch echte Läufe auf; nur der Regelname unterscheidet sie.

Fehler bleiben drinnen. Die Engine fängt den Fehler einer Aktion ab, schreibt ihn mit Status error ins Log und gibt eine kurze Meldung zurück, die die Oberfläche als Toast zeigt. Ein fehlgeschlagener Test bricht die Regel nicht, berührt keine anderen Regeln und stoppt die Seite nicht. Er bedeutet aber, dass dieselbe Aktion im echten Lauf wahrscheinlich auch scheitern würde — warum, steht in der Log-Zeile.

Die KI-Aktion verdient einen eigenen Absatz, denn ihr Test ist nicht kostenlos. Der Schritt bekommt die Beispieldaten, die Anweisung der Firma und den vollen Werkzeugsatz eines Inhabers und darf höchstens ein Schreibwerkzeug aufrufen — in einem automatisierten Lauf gibt es niemanden zum Bestätigen. Er hat vier Schritte zum Denken, jeder Zugriff und jeder Schreibvorgang landet im KI-Log, und er verbraucht das Tageskontingent der Firma genau wie eine Chat-Anfrage. Ist die Anweisung unklar, ist das richtige Verhalten, nichts zu tun und das zu sagen.

Ein Test der KI-Aktion kann also eine echte Aufgabe, Notiz oder einen E-Mail-Entwurf erzeugen, während man nur proben wollte. Nutzen Sie das bewusst: Solange getestet wird, soll die KI nachschauen und berichten, nicht handeln; die Schreibanweisung kommt erst, wenn die Regel fertig ist. Erlaubt der Tarif den autonomen KI-Schritt nicht mehr, sagt der Test das, statt vorzutäuschen, alles sei in Ordnung.

Die Verzögerung ignoriert der Test. Eine Regel, die eine Stunde, einen Tag oder drei Tage warten soll, läuft beim Klick sofort — die Verzögerung gehört zum Ereignisfluss, nicht zur Aktion. Im echten Lauf legt das Ereignis einen Job mit Laufzeit an, und ein späterer Durchlauf beansprucht ihn mit einem bedingten Update, damit zwei Tabs, zwei Mitarbeiter oder zwei Serverinstanzen ihn nicht doppelt ausführen. Wurde die Regel gelöscht oder ausgeschaltet, während der Job wartete, wird er übersprungen; hat der Deal die Phase verlassen, wird die Aktion übersprungen, und das Log sagt es.

Was ein Test nicht beweisen kann. Er beweist nicht, dass die Adresse des Kunden stimmt, dass das Postfach verbunden ist, dass die Variablen mit echten Daten richtig aussehen oder dass der Empfänger Deutsch liest. Er beweist nicht, dass die Regel genau einmal feuert — das erledigt die Beanspruchung des Jobs, nicht die Aktion. Er beweist, dass die Mechanik der Aktion funktioniert: Die Benachrichtigung kommt an, die Aufgabe entsteht, der Webhook antwortet mit einem Status, die KI erreicht ihre Werkzeuge.

Eine sichere Probe. Stellen Sie die Aktion auf eine Benachrichtigung an sich selbst oder auf einen Webhook zu einem Testendpunkt, führen Sie den Test aus, lesen Sie die Log-Zeile, und stellen Sie dann die echte Aktion zurück; testen Sie danach erneut, wenn die Aktion es erlaubt. Bei einer E-Mail-Regel zuerst den Empfänger auf den Inhaber setzen, den eingesetzten Text prüfen und erst dann den Kunden wählen. Lassen Sie die Regel aus, bis der Test das zeigt, was Sie erwarten.

Eine weitere ehrliche Grenze: Die Beispieldaten sind englisch. Ist die Nachricht Ihrer Regel eine deutsche Vorlage, werden die eingesetzten Werte die englischen Beispielwerte sein — Test Client, Test deal. Beurteilen Sie also die Mechanik, nicht den Wortlaut. Den Wortlaut prüft man an einem echten Datensatz oder in einer Vorschau der Vorlage.

Der Test-Knopf ist gerade deshalb sinnvoll, weil die meisten Automatisierungsfehler banal sind: ein falscher Empfänger, eine Aktion, die einen Datensatz braucht, den sie nie bekommt, ein Webhook, der mit 500 antwortet, eine KI-Anweisung, die etwas verlangt, das die Werkzeuge nicht können. Ein Testlauf findet das in Sekunden. Er verspricht nur nicht, dass der Kunde einen perfekten Brief erhält — dafür braucht es weiterhin einen Menschen, und Firmspace CRM führt das Regel-Log, damit der Mensch sieht, was wirklich gelaufen ist.

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.