Automatisierungsprojekte scheitern selten an der Technologie. Sie scheitern daran, dass niemand festgelegt hat, was bei falschen Eingaben, API-Ausfällen oder echten Unklarheiten passieren soll. Ein Workflow, der an guten Tagen funktioniert und an schlechten stillschweigend abbricht, kostet mehr als der manuelle Prozess, den er ersetzen sollte – weil nun niemand mehr mitverfolgt, was passiert.
Ein brauchbares Briefing ist kurz. Es benennt fünf Punkte und tut dies, bevor jemand eine Plattform öffnet und beginnt, Module zu verbinden.
1. Der Auslöser
Was startet diesen Workflow genau? „Wenn ein Lead eingeht“ ist kein Trigger. „Wenn eine Fluent-Forms-Einreichung mit dem Tag ‚Enquiry‘ erstellt wird“ schon. Wenn Sie den Trigger nicht in einem Satz formulieren können, den ein Entwickler ohne Rückfragen umsetzen kann, wurde der Prozess noch nicht ausreichend verstanden, um ihn zu automatisieren.
2. Der Verantwortliche
One named person, not a team. The owner is who gets alerted when the workflow fails and who decides whether the output was correct. Automation without an owner does not become autonomous; it becomes unmonitored. The distinction shows up about six weeks in, when something breaks quietly.
3. Die Entscheidungsschwelle
Dieser Abschnitt wird in fast jedem Briefing ausgelassen. Was darf die Automatisierung autonom entscheiden, und was erfordert zwingend menschliche Freigabe? Listen Sie es auf. Seien Sie konkret bei Budgets, Kundenkommunikation und allen unumkehrbaren Aktionen.
- Entscheidungen, die das System allein trifft: Klassifizierung, Routing, Formatierung, Zusammenfassung, Anreicherung.
- Entscheidungen zur Bestätigung durch eine Person: Versand an Kunden, Ausgaben, Rückerstattungen, Löschungen, Veröffentlichungen.
- Entscheidungen, die das System eskalieren muss: alles außerhalb der von Ihnen genannten Fälle.
Der dritte Ansatz ist der, der Sie schützt. Ein System, das unbekannte Fälle automatisch eskaliert, ist sicher. Ein System, das auf Vermutung basiert, ist es nicht.
4. Der Fehlerpfad
Jeder Schritt kann fehlschlagen. Das Briefing muss festlegen, was im Fehlerfall passiert: wie oft retryt wird, wen man alarmiert und wo das hängengebliebene Element wartet. Die Standardeinstellung „es bleibt einfach stehen“ verwandelt ein kleines Problem in eine Woche verlorener Leads.
- Wiederholungsrichtlinie für temporäre Fehler mit einem Limit.
- Eine sichtbare Warteschlange für nicht verarbeitete Elemente.
- Eine Benachrichtigung an die zuständige Person, nicht an einen gemeinsamen Posteingang, den niemand liest.
- Ein manueller Pfad, damit die Arbeit auch bei automatisierten Ausfällen fortgeführt werden kann.
5. Der geschäftliche Nutzen
Ein messbares Ergebnis, vor der Implementierung gewählt. Schnellere Erstantwort. Weniger verpasste Follow-ups. Weniger manuelle Dateneingabe. Ohne dieses Ziel lässt sich nicht feststellen, ob die Automatisierung funktioniert oder nur läuft – und jede zukünftige Entscheidung wird zur Meinungsfrage.
Wie das in der Praxis aussieht
Ein gutes Briefing passt auf eine Seite und erfordert einen Nachmittag Gesprächszeit für die Erstellung. Es ist zudem das Artefakt, das die Umsetzung kostengünstig macht: Sobald Auslöser, Verantwortlicher, Grenzen, Fehlerpfad und Ergebnis feststehen, läuft die Implementierung weitgehend mechanisch ab. So arbeitet DigLab bei KI-Workflow-Automatisierung, und das ist der Grund, warum die Analysephase nicht optional ist.
Die Plattformwahl steht am Ende und ist weitaus weniger entscheidend, als oft angenommen wird. Die meisten Anforderungen lassen sich auf verschiedenen Tech-Stacks umsetzen. Was sich nachträglich nicht korrigieren lässt, ist ein Workflow ohne klare Verantwortung.
Nächster Schritt
Besitzen Sie einen Prozess, der ohne manuelle Datenübertragung zwischen zwei Systemen laufen sollte, formulieren Sie die fünf Zeilen oben und Sagen Sie uns, was effizienter laufen soll. We will tell you which part of it is ready to automate and which part needs simplifying first — see KI-Workflow-Automatisierung zeigt, wie das fertige System üblicherweise strukturiert ist.