Welchen Geschäftsprozess zuerst automatisieren? Bewerten Sie Ihre Kandidaten mit sechs Fragen und sehen Sie, was der Betrieb kostet und was im Livebetrieb kaputtgeht.
Bewertungsschema mit sechs Fragen: welchen Geschäftsprozess zuerst automatisieren
Automatisieren Sie zuerst den Prozess, der oft vorkommt, dessen Eingaben in vorhersehbarer Form ankommen, der Regeln folgt, die jemand aufschreiben kann, und bei dem ein falsches Ergebnis wenig kostet. Bei vielen Teams, mit denen wir sprechen, ist das nicht der Prozess, der am meisten nervt. Es ist der langweilige mit hohem Volumen und einer klar zuständigen Person.
Die sechs Fragen unten machen daraus eine Punktzahl. Gehen Sie damit Ihre Kandidatenliste durch, bevor Sie mit einem Anbieter sprechen, auch mit uns. Dafür reicht ein kurzer Termin mit der Person, die die Arbeit heute erledigt.
Das Bewertungsschema
Bewerten Sie jede Frage mit 1 bis 3 Punkten. Das Maximum sind 18 Punkte.
15 bis 18: ein guter erster Kandidat.
12 bis 14: ein zweites Projekt, mit Prüfschritt.
Unter 12: zurückstellen.
Eine Regel sticht die Gesamtpunktzahl aus. Eine 1 bei Frage 4 oder Frage 6 schließt einen Prozess als erstes Projekt aus, egal wie gut er sonst abschneidet.
Volumen. Wie oft kommt der Vorgang vor? 1: ein paar Mal im Monat. 2: ein paar Mal pro Woche. 3: jeden Tag, viele Male.
Form der Eingaben. Was kommt herein? 1: Freitext, Telefonate, handschriftliche Notizen. 2: PDFs und E-Mails mit bekanntem Aufbau. 3: Formulare, CSV-Exporte oder eine API.
Klarheit der Regeln. Kann die Person, die das heute macht, die Entscheidung auf einer Seite aufschreiben? 1: „Kommt drauf an, das weiß ich einfach.“ 2: klare Regeln mit ein paar bekannten Ausnahmen. 3: klare Regeln, Ausnahmen sind selten.
Kosten eines falschen Ergebnisses (höhere Punktzahl = sicherer). Was passiert, wenn die Automatisierung einen Fall falsch bearbeitet? 1: Geld verlässt das Unternehmen oder ein Kunde bekommt es zu sehen. 2: ein interner Datensatz ist falsch, bis ihn jemand korrigiert. 3: im nächsten Schritt fällt es ohnehin jemandem auf.
Systemzugang. Kann das Zielsystem das Ergebnis übernehmen? 1: keine API, kein Import, nur Eingabe von Hand über die Oberfläche. 2: ein Dateiimport oder eine eingeschränkte API. 3: eine dokumentierte API.
Verwandte Dienstleistungen
Schicken Sie uns Ihr Projekt. Wir sagen Ihnen ehrlich, was wir zuerst ändern würden.
Die Entwickler, die es bauen würden, antworten schriftlich, so schnell wie möglich, meist innerhalb weniger Tage.
Was wir gebaut haben, was schiefging und was wir heute anders machen würden. Keine Linksammlungen.
Eine zuständige Person. Gibt es jemanden, der den Prozess kennt und in den ersten Wochen die Ergebnisse prüft? 1: nein. 2: ja, nebenbei. 3: ja, und diese Person will das.
Frage 4 ist die, die Teams gern überspringen. Ein Prozess kann überall sonst hoch punkten und trotzdem ein schlechtes erstes Projekt sein, wenn ein einziges falsches Ergebnis beim Kunden ankommt.
Ein Rechenbeispiel
So könnten vier typische Kandidaten bei einem Großhändler mit 50 Mitarbeitenden abschneiden. Das veranschaulicht die Methode. Es sind keine Daten eines Kunden, und Ihre Punktzahlen werden anders aussehen.
Posteingang sortieren (eingehende E-Mails an die richtige Person oder Warteschlange verteilen): Volumen 3, Eingaben 2, Regeln 2, Fehlerkosten 3, Zugang 3, Zuständigkeit 2. Summe 15. Eine falsch zugeordnete E-Mail wird weitergeleitet. Geringes Risiko, schnelle Rückmeldung.
Lieferantenrechnungen erfassen (PDF auslesen, Buchungssatz in der Buchhaltung anlegen): Volumen 3, Eingaben 2, Regeln 3, Fehlerkosten 2, Zugang 2, Zuständigkeit 3. Summe 15. Gut, solange eine Person freigibt, bevor etwas bezahlt wird.
Auftragserfassung aus per E-Mail eingehenden Bestellungen: Volumen 3, Eingaben 2, Regeln 2, Fehlerkosten 1, Zugang 2, Zuständigkeit 2. Summe 12. Eine falsche Menge wird ausgeliefert, deshalb fällt der Prozess als erstes Projekt durch die Ausschlussregel. Machen Sie ihn als zweites, mit Prüfschritt.
Angebote erstellen: Volumen 2, Eingaben 1, Regeln 1, Fehlerkosten 1, Zugang 2, Zuständigkeit 2. Summe 9. Die Preislogik steckt im Kopf einer Person. Schreiben Sie zuerst die Regeln auf und automatisieren Sie später.
Zwei Dinge fallen auf. Der Prozess, der am meisten schmerzt (Angebote), hat die niedrigste Punktzahl. Und die beiden Gewinner haben beide eine günstige Möglichkeit, Fehler abzufangen.
Was der Betrieb kostet
Der Aufbau ist einmalig. Die laufenden Kosten entscheiden, ob sich das Projekt im zweiten Jahr noch lohnt. Sie bestehen aus vier Teilen.
Hosting. Die Workflow-Engine braucht einen Server. Betreiben Sie n8n selbst in der EU oder auf Ihren eigenen Servern, damit die Daten dort bleiben, wo Ihr Datenschutzbeauftragter sie erwartet.
KI-Aufrufe pro Lauf. Wenn ein Schritt ein Dokument mit einem Sprachmodell ausliest, wird jeder Lauf nach der Textmenge abgerechnet, die das Modell liest und schreibt. Die Kosten sind also grob Seiten pro Dokument mal Dokumente pro Monat. Setzen Sie vor den Modellaufruf ein Limit, etwa eine maximale Seitenzahl oder eine Token-Obergrenze pro Lauf, damit ein einzelnes ungewöhnliches PDF mit 80 Seiten nicht das Budget eines ganzen Monats auffrisst.
Zeit für die manuelle Prüfung. Fälle, die die Automatisierung als unsicher markiert, gehen an eine Person. Planen Sie diese Zeit ein. Sie ist der Preis dafür, dass unsichere Fälle nicht einfach durchrutschen.
Wartung. APIs ändern sich, Lieferanten ändern das Layout ihrer Rechnungen, Modellanbieter bringen neue Versionen heraus. Jemand muss das bemerken und nachjustieren. Diese Kosten werden in einem Angebot am leichtesten weggelassen.
Machen Sie den Workflow nicht von einem einzigen KI-Anbieter abhängig. Wenn ein Anbieter die Preise erhöht oder ein Modell ändert, sollte der Wechsel eine Konfigurationsänderung sein, kein Neubau.
Was im Livebetrieb kaputtgeht
Ein fehlgeschlagener Lauf ist der einfache Fall. In n8n verweisen Sie in der Einstellung Error Workflow jedes Workflows auf einen Workflow, der mit einem Error Trigger-Node beginnt, und jemand bekommt eine Nachricht. Schwierig sind die Läufe, die erfolgreich aussehen.
Das haben wir an unseren eigenen Systemen gelernt. Im September 2026 haben wir festgestellt, dass einer unserer internen Lead-Workflows einen Fehler im Daten-Mapping hatte, der sieben Tage lang falsche Ergebnisse erzeugt hatte. Jeder Lauf war grün. Niemand wurde benachrichtigt, weil technisch nichts fehlgeschlagen war. Heute leiten wir die Fehler aller Workflows an einen gemeinsamen Alarm, und wir prüfen die Ergebnisse, nicht nur die Fehler.
Im selben Monat haben wir bemerkt, dass ein älteres Alarm-Relay von uns verstummt war. Der empfangende Endpunkt lieferte HTTP 404 zurück, und der JavaScript-Aufruf fetch(), der den Alarm verschickte, behandelt einen 404 nicht von sich aus als Fehler. Jeder Alarm verschwand spurlos, bis wir es bei der Arbeit an etwas anderem entdeckt haben.
Ein drittes Risiko sind doppelte Läufe. In einem n8n-Issue auf GitHub, das im November 2026 noch offen ist (#31837, github.com/n8n-io/n8n/issues/31837), hat eine einzige Anfrage an einen Webhook-Trigger mehrere Ausführungen mit derselben Event-ID ausgelöst. Beim Sortieren des Posteingangs bedeutet das ein doppeltes Ticket. Bei der Rechnungserfassung bedeutet es eine doppelte Buchung. Jeder Schritt, der geldrelevante Datensätze anlegt, sollte jede Event-ID in einer Datenbanktabelle mit Unique-Constraint speichern und den Lauf überspringen, wenn die ID schon vorhanden ist.
Die Prüfung „Läuft es noch?“ hat also drei Punkte, nicht einen:
Ist es fehlgeschlagen? Das beantwortet der Fehleralarm.
Ist es überhaupt gelaufen? Das beantwortet eine tägliche Prüfung, zum Beispiel ein Alarm, wenn die Zahl der Läufe heute unter die Hälfte des üblichen Tageswerts fällt.
Stimmt das Ergebnis? Das beantwortet eine wöchentliche Stichprobe, zum Beispiel fünf Ergebnisse, die Sie mit Antworten vergleichen, die Sie bereits kennen.
Woran Sie erkennen, dass die KI richtig lag
Nicht am Ausführungsprotokoll. Eine grüne Ausführung sagt Ihnen nur, dass die Aufrufe eine Antwort zurückgegeben haben.
Stellen Sie vor dem Start ein Testset aus Ihren eigenen echten Fällen zusammen, bei denen Sie jeweils die richtige Antwort kennen. Bewerten Sie das Ergebnis Feld für Feld und verlangen Sie bei den wichtigen Feldern eine exakte Übereinstimmung, etwa bei Betrag, Datum und IBAN. Lassen Sie dasselbe Set nach jedem Modell-Update erneut laufen. Lassen Sie jede KI-Antwort ihre Quelle angeben: von welcher Seite und aus welcher Zeile der Rechnung der Betrag stammt. Und lassen Sie den riskanten Schritt, etwa eine Zahlung oder eine Nachricht an Kunden, weiter von einer Person freigeben, bis die Testergebnisse Ihnen einen Grund geben, das zu lockern.
Diesen Test haben wir ausführlich in unserem früheren Beitrag beschrieben: „KI-Workflow prüfen: Hat er die Rechnung richtig gelesen?“.
Wo Sie anfangen
Nehmen Sie die zwei Prozesse mit der höchsten Punktzahl von Ihrer Liste. Setzen Sie zuerst den um, bei dem Fehler weniger kosten. Lassen Sie ihn einen Monat lang mit aktivierter Prüfung und den drei Kontrollen oben laufen. Entscheiden Sie dann über den zweiten anhand echter Zahlen statt Schätzungen.
Wenn Sie eine zweite Meinung möchten, schicken Sie uns eine kurze Beschreibung des Prozesses, und wir bewerten ihn gemeinsam mit Ihnen anhand dieser sechs Fragen. Auf unserer Seite zur erklären wir, wie wir einen ersten Workflow zuschneiden, einschließlich Testset und Freigabeschritt.
