Vom Entwurf zum aktiven Vertrag: Was die Unterschrift im CRM wirklich auslöst

Die meisten kleinen Firmen verlieren keine Verträge. Sie verlieren den Moment, in dem ein Vertrag unterschrieben wurde. Das PDF liegt irgendwo, der Kunde ist zufrieden, und trotzdem kann am Donnerstag niemand sagen, ob die Arbeit beginnen darf, wer das Material bestellen sollte oder bis wann geliefert werden sollte. Das Papier existiert, der Zustand des Geschäfts nicht.

Firmspace CRM behandelt einen Vertrag als lebenden Datensatz im Finanzbereich und nicht als Anhang in einem Ordner. Der Datensatz durchläuft eine feste Folge von Zuständen, und jeder Übergang hinterlässt eine Spur. Die Vertragsliste liegt unter /crm/finance?tab=contracts, neben Angeboten, Bestellungen und Rechnungen.

Der Assistent kann den Vertrag selbst anlegen. Sein Werkzeug create_contract nimmt einen Kundennamen, optional einen Ansprechpartner, einen Gesamtbetrag, eine Währung sowie optional Start- und Enddatum entgegen und verknüpft einen passenden Kontakt oder legt ihn an. Eine vorherige Suche im CRM ist nicht nötig. Das Werkzeug erzeugt einen Entwurf. Einen aktiven Vertrag erzeugt es nicht, denn unterschrieben hat noch niemand.

Diesen Zustand ändert ein eigenes Werkzeug, contract_action, mit genau drei Werten: sign, complete und cancel. Sign führt einen Entwurf in den aktiven Zustand, complete schließt einen aktiven Vertrag ab, cancel beendet einen Entwurf oder einen aktiven Vertrag. In der Beschreibung des Werkzeugs steht die Bedingung, auf die es ankommt: es braucht die Bestätigung eines Menschen, solange der Auto-Modus nicht eingeschaltet ist. Einen vierten Wert gibt es nicht, und keinen Zustand lässt sich überspringen.

Hinter dem Assistenten steht für denselben Schritt eine gewöhnliche Route, und sie ist strenger, als der Knopf vermuten lässt. Der Endpunkt für die Unterschrift arbeitet nur mit Entwürfen: ist der Vertrag bereits aktiv, wird die Anfrage mit einem klaren Satz abgelehnt, statt sie stillschweigend ein zweites Mal anzunehmen. Zwei Unterschriften auf einem Vertrag sind genau die Art von Doppelung, die ein CRM verhindern sollte.

Eine erfolgreiche Unterschrift schreibt drei Dinge, die drei verschiedene Fragen beantworten. Das Erste ist der Zustand selbst: der Vertrag wird aktiv und das Datum der Unterschrift wird gespeichert. Damit hat die Frage „darf die Arbeit beginnen?“ eine Antwort statt fünf Meinungen.

Das Zweite ist das Signal an die Automatisierung. Die Unterschrift sendet ein Ereignis vom Typ contract_signed, das Vertragsnummer, Kundenname, den zugehörigen Deal, den Wert und die Währung mitführt. Für sich genommen bewirkt dieses Ereignis nichts. Es ist eine Feststellung, auf die andere Maschinerie reagieren darf.

Das Dritte ist die Nachvollziehbarkeit. Ein Audit-Eintrag hält die Aktion, den Vertrag, die Nummer, wer unterschrieben hat und den Betrag fest, sodass die Änderung auch Monate später zurechenbar ist. Daneben schreibt die Dokumentenkette ein Ereignis in den Verlauf des Deals, des Kontakts und der Firma, mit denen der Vertrag verknüpft ist. Ein Vorgang, und die ganze Beziehungskette weiß davon.

Wirklich nützlich wird die Unterschrift durch das, was danach kommt, und vor allem dadurch, dass von selbst nichts passiert. Es gibt keinen versteckten Ablauf, der in dem Moment, in dem ein Kunde unterschreibt, Material bestellt. Es gibt eine Liste von Ereignissen, die das CRM auslösen kann, und eine Liste von Aktionen, die eine Regel ausführen kann: jemanden benachrichtigen, eine Aufgabe anlegen, eine Notiz hinzufügen, einen Deal in eine andere Phase verschieben, eine E-Mail senden, einen Webhook aufrufen oder einen KI-Schritt ausführen. Keine davon ist an eine Vertragsunterschrift fest verdrahtet.

Die richtige Frage lautet deshalb nicht, was das CRM nach einer Unterschrift tut, sondern was Ihre Firma tun möchte. Soll nach der Unterschrift „Material bestellen“ bei einem Menschen liegen, dann ist das eine Regel, die jemand geschrieben haben muss. Soll der Deal nicht länger in der falschen Phase stehen, ist auch das eine Regel. Das Ereignis ist vollständig und verlässlich; die Absicht dahinter muss von einem Menschen kommen.

Es gibt einen zweiten, leiseren Weg in denselben Datensatz, und er sollte vom ersten getrennt betrachtet werden. Liest der Assistent ein hochgeladenes PDF eines Vertrags, liefert sein Werkzeug read_document den Text, und das Werkzeug save_employee_contract schlägt vor, ausgelesene Felder in ein Mitarbeiterprofil zu schreiben: Vertragsart, Startdatum und eine kurze Notiz. Das ist die Personalkarte, nicht der Vertrag im Finanzbereich. Die beiden sind Nachbarn, nicht dasselbe.

Beide Wege treffen an derselben Leitplanke zusammen. Nichts, was der Assistent zu einem Vertrag vorschlägt, geschieht von allein: er legt die Aktion vor, und ein Mensch bestätigt sie. Selbst bei eingeschaltetem Auto-Modus gilt die Regel, dass das Lesen von Text aus dem eigenen Umfeld — ein Dokument, ein Postfach, eine Karte, eine Webseite — das Recht nimmt, Datensätze ohne Nachfrage zu ändern. Text in einem Vertrag sind Daten, niemals eine Anweisung.

Das ist eine bewusste Entscheidung und für ein Dokument mit Geld daran die richtige. Ein Vertrag liegt genau an der Grenze, an der ein falscher Klick teuer wird und ein präpariertes PDF realistisch ist. Der Assistent darf ihn lesen, zusammenfassen, einen neuen entwerfen und die Unterschrift anbieten; die Zustimmung zur Unterschrift bleibt beim Menschen, und der Audit-Eintrag nennt diesen Menschen anschließend.

Praktisch heißt das: die Unterschrift ist keine Formalität am Ende eines Ablaufs, sondern dessen Angelpunkt. Davor ist der Vertrag ein Entwurf, änderbar und harmlos. Danach ist der Zustand fest, der Nachweis geschrieben, und die weitere Arbeit der Firma darf sich darauf verlassen. Das System ist so gebaut, dass dieser Angelpunkt sichtbar ist und dass bekannt ist, wer ihn umgelegt hat.