Vom Angebot zur bezahlten Rechnung: wie die Belegkette im CRM funktioniert
Angebot, Auftrag, Rechnung und Zahlung sind vier Ansichten ein und desselben Geschäfts. In vielen kleinen Unternehmen liegen sie an vier verschiedenen Orten: ein Dokument im Ordner, eine Zeile in der Tabelle, ein PDF per E-Mail, eine Notiz im Buchhaltungsprogramm. Jede Übergabe dazwischen ist eine Gelegenheit, einen Betrag zu vertippen, eine Position zu vergessen oder den Faden zu verlieren, wer was schuldet.
Die Kette beginnt auf dem Deal-Board, nicht in einem Texteditor. Die Karte enthält bereits den Kunden, die Kontaktperson, die zuständige Kollegin oder den Kollegen und den erwarteten Betrag. Jedes folgende Dokument entsteht aus dieser Karte, sodass Kundenname und Bezug zum Geschäft nie erneut getippt werden.
Das Angebot wird als Entwurf vorbereitet und dann an den Kunden gesendet. Der Moment des Versands wird als Ereignis festgehalten, und der Status ändert sich mit ihm. Das ist wichtiger, als es klingt: Nur ein tatsächlich versendetes Angebot kann später als angenommen oder abgelehnt markiert werden, ein Entwurf wird also nicht stillschweigend zur Zusage.
Der Kunde muss nicht zurückrufen, um zuzusagen. Für das Angebot lässt sich ein öffentlicher Link ausgeben, über den der Kunde selbst annimmt. Der Link öffnet genau ein Dokument und sonst nichts, das Token ist lang und zufällig, es lässt sich jederzeit widerrufen, und die Laufzeit ist standardmässig auf neunzig Tage begrenzt. Will der Kunde nur einen Teil des Angebots, markiert er die Positionen, denen er zustimmt, und nur diese bleiben im Angebot.
Nur ein angenommenes Angebot kann zu einem Auftrag werden, und das nur einmal. Der Auftrag erbt Kunde, Kontaktperson, Geschäft, Währung und jede Position aus dem Angebot. Nichts wird von Hand kopiert, die Beträge im Auftrag sind also die Beträge, denen der Kunde zugestimmt hat.
Ein Auftrag durchläuft eine feste Menge von Status: Entwurf, bestätigt, ausgeliefert, in Rechnung gestellt, bezahlt, abgeschlossen, storniert. Nicht jeder Status darf auf jeden folgen — das System folgt einer ausdrücklichen Übergangstabelle, ein bereits ausgelieferter Auftrag kann also nicht stillschweigend in den Entwurf zurückrutschen. Statuswechsel und Lagerbewegungen geschehen in einer einzigen Transaktion: Ausliefern bucht Ware aus, Stornieren gibt genau das zurück, was das Lager verlassen hat, und das Bewegungsjournal ist die Quelle der Wahrheit, sodass eine wiederholte Auslieferung nichts doppelt abbucht.
Eine Rechnung lässt sich nur aus einem Auftrag erzeugen, der noch keine Rechnung und dafür Positionen hat. Die Rechnung übernimmt Kunde, Kontakt, Geschäft und Vertrag aus dem Auftrag, wendet die Steuereinstellungen der Firma an und zählt die Zahlungsfrist ab dem vereinbarten Zahlungsziel — standardmässig vierzehn Tage. Der Auftrag selbst wechselt in den Status in Rechnung gestellt.
Die Zahlung schliesst den Kreis. Eine Rechnung lässt sich vollständig oder teilweise als bezahlt markieren, und das Datum, an dem das Geld eingegangen ist, entscheidet, in welchem Monat es in den Auswertungen erscheint — nicht das Datum, an dem jemand dazu kam, es einzutragen. Bankbewegungen lassen sich Rechnungen zuordnen, sodass der Abgleich am Monatsende nicht von Hand wiederholt werden muss.
Ein Vertrag folgt seinen eigenen kurzen Weg: Entwurf, dann aktiv nach der Unterschrift, dann abgeschlossen. Nur ein Entwurf kann unterschrieben werden, und die Unterschrift wird mit Datum festgehalten und als Ereignis gemeldet, sodass der Rest des Unternehmens davon erfährt, ohne dass jemand eine Nachricht herumschickt.
Jeder dieser Momente ist ein Ereignis, auf das das CRM reagieren kann: ein Angebot wurde versendet, ein Angebot wurde angenommen, ein Auftrag wurde erstellt, ein Auftrag wechselte den Status, eine Rechnung wurde versendet, bezahlt oder wurde überfällig, ein Vertrag wurde unterschrieben, eine Bankbewegung wurde zugeordnet. Eine Automatisierungsregel kann sofort reagieren oder nach einer Verzögerung von einer Stunde, einem Tag oder drei Tagen, und ihre Aktion kann eine Benachrichtigung, eine Aufgabe, eine Notiz, ein Spaltenwechsel, eine E-Mail, ein Webhook-Aufruf oder ein von der Assistentin ausgeführter Schritt sein.
Der von der Assistentin ausgeführte Schritt verdient einen warnenden Hinweis, denn er arbeitet anders als der Chat. Er läuft ohne Person daneben und kann deshalb nicht um Bestätigung bitten. Er darf zunächst mit Lesewerkzeugen nachsehen, führt dann aber höchstens eine schreibende Aktion pro Durchlauf aus — keine Kette davon. Er handelt mit den Rechten des Firmeninhabers und verbraucht dasselbe Tageskontingent an KI wie der Chat. Ist die Anweisung unklar oder ist er nicht sicher, führt er gar keine Aktion aus und erklärt in einem Satz, warum. Das ist beabsichtigt: In einem Prozess ohne Aufsicht ist Nichtstun oft das bessere Ergebnis.
Jeder Schritt hinterlässt eine Spur. Belegereignisse werden in die Aktivitätshistorie von Geschäft, Kontakt und Firma geschrieben, und jeder Eintrag ist mit einem Schlüssel versehen, damit dasselbe Ereignis nicht zweimal erfasst wird. Wochen später lässt sich noch rekonstruieren, wann das Angebot hinausging, wann es angenommen wurde, wann die Ware ausgeliefert wurde und wann das Geld kam — ohne jemanden fragen zu müssen.
Der Wert dieser Kette liegt nicht darin, dass Belege ordentlich aussehen. Er liegt darin, dass derselbe Datensatz vom ersten Angebot bis zur letzten Zahlung wandert, sodass ein Betrag unterwegs nicht abdriften kann, Lager und Papiere sich nicht widersprechen und das System den überfälligen Schritt selbst bemerkt, statt darauf zu warten, dass sich jemand daran erinnert.