Stell dir einen gewöhnlichen Montag vor. In der E-Mail liegt eine Nachricht eines Kunden: Er bittet darum, einen Termin zu verschieben und noch eine Person hinzuzufügen. Im CRM - dem Programm, in dem das Team Kunden und Verkäufe führt - steht noch die alte Uhrzeit. In der Tabelle hat der Manager bereits “abgestimmt” geschrieben. Du zeigst einem KI-Assistenten alle drei Quellen, und er schlägt selbstbewusst eine vierte Variante vor: eine Bestätigung für einen freien Termin zu senden.
Es sieht so aus, als hätte die KI einen Fehler gemacht. Tatsächlich hat sie widersprüchliche Anweisungen erhalten und weiß nicht, welche davon das letzte Wort hat. Wenn du ihr das Recht zu handeln gibst, kann sie nicht nur einen unglücklichen Text formulieren, sondern auch den Status eines Geschäfts ändern, eine Aufgabe für die falsche Person erstellen oder das Team mit zwei unterschiedlichen Vereinbarungen zurücklassen.
Deshalb lohnt sich vor der Entwicklung ein Process Audit - eine kurze Analyse, wie Arbeit tatsächlich von einer Person und einem System zur nächsten übergeht. Das ist keine Prüfung, ob dein CRM “modern genug” ist. Es ist ein Weg, einem neuen Werkzeug keinen Prozess zu übergeben, dessen Regeln noch immer in den Köpfen des Teams leben.
1. Das Modell sieht Daten, aber nicht immer ihr Gewicht
KI kann E-Mails gut lesen, darin die Anfrage finden, den Inhalt kurz erklären und eine nächste Aktion vorschlagen. Zwischen “lesen” und “einen Arbeitsdatensatz ändern” liegt jedoch eine wichtige Grenze.
Schnittstelle ist das deutsche Wort für Integration, also den Ort, an dem zwei Systeme Daten austauschen. Genau hier geht der Kontext am häufigsten verloren. Ein Dienst übermittelt den Namen des Kunden ohne Geschäftsnummer. Ein anderer teilt nicht mit, dass der Datensatz bereits geschlossen ist. Ein dritter akzeptiert jede Aktualisierung, obwohl sie nur der verantwortliche Manager vornehmen sollte. KI kann eine Regel, die niemand aufgeschrieben hat, nicht ehrlich erraten.
Das Problem liegt oft nicht im Datenaustausch selbst, sondern in seiner Bedeutung. Zum Beispiel kann das Feld “Phase” im CRM bedeuten, dass ein Manager ein Angebot vorbereitet hat. Dasselbe Wort kann in einer Tabelle bedeuten, dass der Kunde es bereits angenommen hat. Technisch lassen sich beide Datensätze zwischen den Systemen übertragen. Aber die Automatisierung unterscheidet eine Arbeitsnotiz nicht von einer Entscheidung, wenn du das nicht festlegst.
Ein altes System ist kein Urteil
Das ist nicht nur ein Problem alter Programme. Eine Zapier-Umfrage unter großen Unternehmen nennt komplexe Integrationen mit Altsystemen, Kosten, Abhängigkeit von Anbietern und fehlende notwendige Fähigkeiten als Hindernisse für die Einführung von KI. Die Schlussfolgerung für ein kleines B2B-Unternehmen ist einfacher: Du musst das vorhandene System nicht für ungeeignet erklären. Du musst einen konkreten Übergang prüfen - was hineingeht, was sich ändert, wer es bestätigt und was herauskommt.
Zum Beispiel kann bei einem Unternehmen für Gebäudereinigung - professionelle Reinigung von Gebäuden - eine Anfrage über ein Website-Formular, eine E-Mail oder einen Anruf eingehen. Wenn alle drei Kanäle letztlich im CRM landen, kann die KI nur neue Anfragen lesen, Adresse und Objektart extrahieren und einen Entwurf für eine Karte vorbereiten. Wenn der Manager den Einsatzbereich jedoch noch in einer eigenen Tabelle abgleicht, darf der Agent dem Kunden nicht selbstständig etwas versprechen. Er kann die Abweichung zeigen und um eine Entscheidung bitten.
Ein weiteres Beispiel: Wenn ein Kunde dem Preis in einer E-Mail zugestimmt hat, im CRM aber noch ein anderer Betrag steht, ist das automatische Versenden eines Vertrags ein schlechter erster Schritt. Ein nützlicher erster Lauf kann solche Abweichungen stattdessen in einer Liste für den Manager sammeln. Du verlierst nicht die Kontrolle, siehst aber genau, wo der Prozess auseinanderläuft: in der Korrespondenz, bei der Dateneingabe oder in der Regel, nach der das Team einen Betrag als endgültig betrachtet.
2. Sechs Fragen, die du vor jeder Entwicklung durchgehen solltest
Ein Process Audit braucht keinen technischen Vortrag. Nimm einen wiederkehrenden Prozess: die Bearbeitung einer neuen Anfrage, die Abstimmung eines kommerziellen Angebots, die Sortierung von E-Mails oder die Übergabe eines Projekts in die Umsetzung.
Es ist sinnvoll, nicht einen vorgestellten Idealprozess zu analysieren, sondern einen aktuellen Fall. Öffne die E-Mail, die Karte im CRM und das Dokument, in dem das Team etwas geklärt hat. Dann werden nicht nur der offizielle Weg, sondern auch die Umwege schnell sichtbar: eine Nachricht im Messenger, das manuelle Kopieren einer Nummer, die Vereinbarung “ich aktualisiere es später”. Versuche nicht, sofort das ganze Unternehmen zu beschreiben oder eine lange Präsentation vorzubereiten. Wähle den Moment, an dem das Team regelmäßig kopiert, nachfragt oder nach der letzten Version sucht.
Gehe danach sechs Fragen in der Reihenfolge der tatsächlichen Arbeit durch.
- Wo beginnt die Anfrage? Schreibe nicht “bei einem Lead”, sondern konkret: bei einem Formular, einer E-Mail, einem Anruf, einem Messenger oder einer manuell erstellten Karte. Das hilft dir, den Kanal nicht zu vergessen, der nur existiert, weil “es so bequemer ist”.
- Welche Quelle ist die Quelle der Wahrheit - der Datensatz, dem man vertraut, wenn Daten einander widersprechen? Für den Preis kann das das freigegebene Angebot sein, für den Geschäftsstatus das CRM, für das Einsatzdatum der Kalender. Wenn es darauf keine Antwort gibt, lass die KI diesen Status nicht ändern.
- Welche Statusübergänge gibt es? Benenne sie einfach: “neue Anfrage”, “Klärung nötig”, “Angebot gesendet”, “zugestimmt”, “geschlossen”. Schreibe neben jeden Übergang, was geschehen muss, um weiterzugehen. Nicht “wenn alles fertig ist”, sondern “der Kunde hat dem Betrag schriftlich zugestimmt”.
- Wem gehört jeder Übergang? Der Verantwortliche ist nicht die Person, die manchmal hilft, sondern diejenige, die sagen darf: “Ja, der Status hat sich jetzt geändert.” Gibt es keinen Verantwortlichen, muss die KI die zuständige Person erraten oder sich an der letzten zufälligen Aktion orientieren.
- Wo darf die KI lesen und wo darf sie schreiben? Leserecht bedeutet das Recht, Daten nur anzusehen; Schreibrecht bedeutet das Recht, sie zu ändern. Zu Beginn ist es sinnvoller, der KI breiteres Leserecht zu geben und Schreibrecht eng zu begrenzen oder gar nicht zu geben. So prüfst du die Regel an echten Ausnahmen, ohne wichtige Datensätze zu gefährden.
- Welche Fälle passen nicht in den normalen Weg, und wodurch ist die Arbeit abgeschlossen? Notiere zumindest die Ausnahmen, die das Team nennt: doppelte Anfrage, der Kunde hat Bedingungen geändert, Daten fehlen, ein Vertrag besteht bereits, Zugriff ist untersagt. Benenne zusätzlich den Nachweis des Abschlusses: Die E-Mail wurde versendet und gespeichert, eine Aufgabe hat einen Bearbeiter, der Datensatz wurde in der Quelle der Wahrheit aktualisiert, eine Person hat die Entscheidung bestätigt.
Du musst keine komplexe Grafik zeichnen. Ein Blatt oder gemeinsames Dokument reicht, wenn bei jedem Schritt sichtbar sind: Eingang, Quelle der Wahrheit, Verantwortlicher, erlaubte Aktion, Ausnahme und Nachweis des Abschlusses. Eine solche Karte ist wertvoller als eine schöne Demo, weil sie zeigt, was gebaut werden muss und was zuerst ohne jede Entwicklung abgestimmt werden sollte. Wenn zwei Personen die Frage “Wer darf den Status ändern?” unterschiedlich beantworten, ist das bereits ein Ergebnis. Streite nicht mit der KI über die Genauigkeit ihrer Antwort. Vereinbart zuerst die Regel manuell, tragt sie in die Arbeitsbeschreibung ein und gebt sie erst danach an die Automatisierung weiter.
3. Der erste Lauf sollte eine sichere Prüfung sein, kein Ersatz für das Team
Ein Canary ist ein kleiner kontrollierter Start, der eine Idee in einem engen Bereich prüft, ohne ihm den gesamten Prozess zu überlassen. Für KI ist er besonders nützlich, wenn sich das Ergebnis lesen, prüfen und rückgängig machen lässt.
Ein guter Canary hat drei Merkmale. Er nimmt eine Art von Eingangsdaten, ändert keinen kritischen Datensatz ohne einen Menschen und hinterlässt eine Spur, mit der nachvollziehbar ist, warum das Ergebnis entstanden ist. Zum Beispiel liest KI E-Mails mit dem Betreff “Anfrage”, extrahiert Fakten nur aus der E-Mail selbst und bereitet einen Antwortentwurf zusammen mit einem Link zur Quelle vor. Ein Manager bestätigt oder verwirft ihn manuell. So funktioniert das Beispiel der Klar-E-Mail-Triage: Wichtig sind dort nicht nur die Hinweise der KI, sondern auch die Verbindung zu Belegen und die menschliche Kontrolle.
Vereinbare vor einem solchen Start, was ihr als Fehler betrachtet. Nicht abstrakt “schlecht geschrieben”, sondern verständliche Fälle: Ein notwendiges Detail in der E-Mail wurde nicht gefunden, der Kunde wurde verwechselt, eine Aktion ohne Quelle vorgeschlagen oder etwas in eine Warteschlange geschickt, das nicht zu deren Thema gehört. Dann korrigiert die Person, die die Ergebnisse prüft, nicht einfach alles stillschweigend, sondern führt den Prozess auf eine konkrete Regel zurück.
Die Grenze eines sicheren Starts
Ein schlechter Canary sieht anders aus: “Der Agent soll alle Leads selbst führen.” Darin stecken zu viele unterschiedliche Regeln, Kanäle und Folgen. Wenn etwas schiefgeht, weißt du nicht, ob die E-Mail-Erkennung, die Integration, eine Routing-Regel oder das Schreibrecht versagt hat. Ein solcher Start ist wie die Reparatur der Verkabelung in einem ganzen Gebäude mit einem Schalter: Das Licht kann angehen, aber die Ursache später zu finden, wird nicht vergnüglich sein.
Wenn du dennoch eine Aktion im System brauchst, wähle eine umkehrbare. Zum Beispiel ändert die KI nicht das Budget eines Geschäfts, sondern setzt ein Tag “Prüfung nötig”; sie versendet keine Rechnung, sondern erstellt einen Entwurf; sie schließt keine Aufgabe, sondern fügt sie einer Warteschlange zur Bestätigung hinzu. Lege vor dem Start fest, wer diese Warteschlange prüft und wie eine falsche Aktion rückgängig gemacht wird. Ohne das bedeutet “automatisch” manchmal nur, dass der Fehler Zeit hatte, vor dir loszulaufen.
Auch die Trennung von Rollen ist wichtig. In einem guten Arbeitsprozess lässt du Entscheidung und Verantwortung bei einem Menschen, überträgst die Vorbereitung einem Assistenten und gibst einem Agenten eine begrenzte Aktion nach einer vorgegebenen Regel. Genau eine solche Trennung zwischen menschlicher Führung, Unterstützung durch Assistenten und Automatisierung durch Agenten wird in Ansätzen zur Gestaltung von Arbeitsprozessen und ihren Steuerungsregeln vorgeschlagen.
4. Was nach der Prozessanalyse bleiben sollte
Das Ergebnis sollte kein Bericht sein, den man bequem in einen Ordner legen und vergessen kann. Es sollte zu einer kurzen Arbeitsbeschreibung werden, mit der du und das Team Entscheidungen treffen könnt.
Behalte eine Karte eines Prozesses mit sechs Feldern: Quelle der Anfrage, Quelle der Wahrheit, Status, Verantwortlicher, Rechte der KI, Ausnahmen und Nachweis des Abschlusses. Ergänze die Grenze des ersten Starts: Was genau die KI liest, was sie vorschlägt, was sie nicht ändert und wer das Ergebnis prüft. Markiere getrennt, wo eine menschliche Entscheidung nötig ist und wo eine vorher vereinbarte Regel ausreicht.
Diese Beschreibung ist nicht nur für Entwickler nützlich. Ein neuer Manager versteht damit, wo er nach dem aktuellen Preis schauen muss. Der Prozessverantwortliche sieht, welche Entscheidungen zwischen Rollen hängen bleiben. Die Person, die für Zugriffe verantwortlich ist, kann dem Werkzeug genau die Rechte geben, die für die erste Aufgabe nötig sind. Und du kannst Angebote von Dienstleistern nicht nach dem Versprechen “wir integrieren alles”, sondern danach vergleichen, ob sie die echten Grenzen des Prozesses sehen.
Danach kann sich herausstellen, dass die Automatisierung noch nicht gebaut werden sollte. Wenn zum Beispiel kommerzielle Bedingungen im Chat ohne einen einheitlichen Datensatz abgestimmt werden und Manager den Status “fertig” unterschiedlich benennen, vereinbart zuerst eine manuelle Regel. Das ist weder eine Niederlage noch eine Absage an KI. Es ist ein Weg, eine kaputte Übergabe zu entfernen, bevor du ihr noch einen weiteren Dienst hinzufügst. Ein kaputter Prozess ist auch ohne KI einfallsreich genug: Er kann den Verantwortlichen sogar in drei Tabs verlieren.
Ein kontrollierter Workflow kann bereits ein Beweis dafür sein, dass das Team einen Prozess mit Prüfungen bauen kann. Er beweist jedoch nicht, dass jede nächste Aufgabe sicher an einen Agenten übergeben werden kann. Deshalb solltest du kontrollierte KI-Systeme nicht nach der Wirkung des ersten Bildschirms bewerten, sondern danach, ob klar ist, wo der Agent stoppt, wer seine Aktion sieht und was das Ergebnis bestätigt.
5. Beginne mit einem Ort, an dem das Team nach Wahrheit sucht
Beginne nicht mit der Frage “Welche KI sollen wir kaufen?” Öffne einen echten Prozess, bei dem Menschen häufig E-Mail, CRM und Tabelle abgleichen. Nimm das letzte Beispiel, bei dem jemand fragte “Welcher Status ist richtig?”, und schreibe daneben auf, wo es eine Wahrheit hätte geben müssen, wer sie ändern durfte und was für den Abschluss fehlte.
Du musst nicht sofort entscheiden, welches System ersetzt werden soll oder wie alles miteinander verbunden wird. Deine erste Aufgabe ist, die Grenze des Problems so zu benennen, dass das Team sie erkennt. Wenn es für einen Fall eine Quelle der Wahrheit, einen Verantwortlichen und einen Nachweis des Abschlusses gibt, entsteht ein sicherer Ort für einen kleinen Start.
Das ist der erste Schritt. Wenn er getan ist, ist KI kein Rater mehr zwischen drei Versionen der Realität und kann zu einem hilfreichen Assistenten in klar umrissener Arbeit werden.