Kurz gesagt. Ein europäisches B2B-Unternehmen wickelte seine Abläufe von Hand ab. Jeder Auftrag, jede Vertriebsfrage und jeder neue Partner brauchte einen Menschen. Wir haben die Systeme des Unternehmens nicht ersetzt, sondern mit n8n eine Operations-Schicht darübergelegt und Slack zur einzigen Oberfläche gemacht. Zehn Prozesse laufen heute produktiv. Vier Regeln prägen alle: dort arbeiten, wo die Menschen schon sind; wo Geld im Spiel ist, klickt ein Mensch den Button; jede Aktion nach der Ausführung prüfen; jeden Fehler sichtbar machen.
Das ist ein echtes Kundenprojekt. Der Kunde bleibt anonym, daher sind die Zahlen aus Vertraulichkeitsgründen angepasst. Die Verhältnisse stimmen.
Was war das Problem?
Das Unternehmen verkauft an Geschäftskunden in ganz Europa. Seine Kunden wählen den Lieferanten, der pünktlich und vollständig liefert. Ein Kunde sammelt den ganzen Tag Aufträge und erwartet eine Lieferung zu einer festen Uhrzeit. Jede Verzögerung auf Seiten unseres Kunden bricht daher das Versprechen, das dieser Kunde seinen eigenen Abnehmern gegeben hat.
Hinter diesem Versprechen steckte Handarbeit:
- Jemand informierte das Lager über jeden Auftrag und ermittelte den Versandtag.
- Jemand änderte Auftragsstatus von Hand.
- Vor jeder festgelegten Kommissionierzeit prüfte jemand jeden offenen Auftrag Position für Position.
- Vertriebsfragen landeten immer wieder bei denselben Mitgliedern des Entwicklungsteams. Jede Antwort hieß, mehrere Systeme von Hand zu prüfen: wiederkehrende Arbeit, die sie von der Produktentwicklung abhielt.
Das Wachstum hing daran, wie viel einige wenige Menschen schaffen konnten. Fiel eine von ihnen aus, blieb die Arbeit liegen.
Warum auf den bestehenden Systemen aufbauen?
Die Kernsysteme funktionierten. Sie zu ersetzen hätte lange gedauert, und in der Zwischenzeit wäre nichts davon besser gelaufen. Außerdem waren ihre Release-Zyklen langsam, auf neue Funktionen darin zu warten kam nicht infrage.
Also haben wir verbunden, was da war: Auftrags- und Lagersysteme, Kundendaten, die Werkzeuge von Finanzen und Compliance sowie das Projekttracking. n8n führt die Workflows aus. In Slack sehen die Menschen die Ergebnisse und drücken die Buttons.
Welche Prozesse haben wir automatisiert?
Die zehn Prozesse lassen sich in drei Gruppen einteilen.
Aufträge: vom Auftrag ins Lager
- Sofortmeldung ans Lager. Ein neuer Auftrag erreicht das Lager in Slack, sobald er angelegt wird, mit gesetzter Priorität und festgelegtem Versandtag. Jeder Auftrag hat eine festgelegte Kommissionierzeit, und diese Zeit bestimmt zusammen mit der Auftragsgröße den Versandtag.
- Expressaufträge. Expressaufträge benachrichtigen die Teams, die handeln müssen. Reguläre Aufträge laufen ohne zusätzliche Nachrichten den normalen Weg.
- Vertrauenswürdige Kunden. Jede Stunde gehen Aufträge freigegebener Kunden mit Zahlung auf Rechnung ohne Wartezeit auf einen Menschen in die Bearbeitung.
- Bereinigung von Testaufträgen. Jeden Abend werden Aufträge von Testkonten storniert, damit sie aus der Lagerwarteschlange und den Vertriebsberichten verschwinden.
- Fehlende Auftragspositionen. Offene Aufträge werden stündlich vor der Kommissionierung mit dem abgeglichen, was der Kunde tatsächlich geschickt hat (siehe unten).
Vertriebsfragen und Statusprüfungen
- Ein Vertriebsbot in Slack. Er versteht eine Frage in normalen Worten und prüft den Status über die Abteilungen hinweg selbst: Compliance, Finanzen (zum Beispiel die USt-Prüfung), Aufträge und Bestand. Aktionen mit Folgen laufen über einen Button und werden danach geprüft.
- Eine wöchentliche Statusliste. Jede Woche erhält der Vertrieb die Kunden, die noch auf die Entscheidung einer anderen Abteilung warten, damit niemand im Stillen wartet.
Partner und Reporting
- Partner-Onboarding in einem Thread. Eine zuständige Person postet eine Kunden-ID und wählt die Anbindungsart. Das System legt den Partner in allen beteiligten Systemen an, beantragt die nötigen Zugänge und meldet sich im Thread zurück.
- Tägliche Partnerprüfungen. Offene Einrichtungsschritte werden nachverfolgt, bis der Partner vollständig angebunden ist.
- Reporting. Wöchentliche Auftragszahlen je Partner, Berichtserinnerungen und Roadmap-Status, die automatisch aus der Arbeit in anderen Projekten und Systemen zusammengeführt werden.
Wie funktioniert ein Prozess von Anfang bis Ende?
Die Prüfung auf fehlende Auftragspositionen zeigt das Muster am besten.
Schlüsselkunden fügen den ganzen Tag über eine API Positionen zu einem offenen Auftrag hinzu. Zur festgelegten Kommissionierzeit wird der Auftrag geschlossen und geht in die Kommissionierung. Manchmal kam eine Position nie im Auftrag an, und der Kunde erfuhr davon durch eine Reklamation.
Heute läuft es so:
- Stündliche Prüfung. In den Stunden vor der Kommissionierung wird jede Position, die der Kunde über die API hinzugefügt hat, mit den Positionen verglichen, die tatsächlich im Auftrag stehen.
- Erneut lesen, bevor alarmiert wird. Eine Lücke wird nach kurzer Wartezeit erneut aus der Primärquelle gelesen. Eine Datenquelle hinkte einmal hinterher, und ein verfrühter Alarm hätte Positionen verdoppelt.
- Zuständige Person alarmiert. Slack zeigt „In diesem Auftrag fehlen 4 Positionen“ mit zwei Buttons: „4 Positionen hinzufügen“ und „Manuell behoben“.
- Ein Klick. Die zuständige Person klickt auf „4 Positionen hinzufügen“. Das System fügt sie hinzu, liest den Auftrag erneut und bestätigt. Der Button wird durch „Alle Positionen hinzugefügt“ ersetzt.
- Gesperrter Artikel, falls vorhanden. Ist ein Artikel gesperrt und lässt sich nicht hinzufügen, werden die Personen, die ihn freigeben können, sofort in den Thread geholt.
Die Regel aus Schritt 2 stammt aus einem echten Fehlalarm. Sie gilt inzwischen in jedem Workflow, den wir bauen: erst erneut prüfen, dann alarmieren.
Wie haben wir den Vertriebsbot getestet?
Wir haben den Bot nicht nach Bauchgefühl gestartet. Wir haben Tausende echter Anfragen aus dem Verlauf des Vertriebskanals genommen und von Hand mit der richtigen Antwort klassifiziert. Jede Änderung an den Regeln des Bots läuft gegen den vollständigen Datensatz, bevor sie live geht.
Der Anteil der Fragen, die der Bot übergangen hat, sank von 36 % auf 5 %. Beim ersten Lauf hat die Roadmap-Zusammenführung 12 Vorgänge mit 0 Fehlern und 4 Warnungen verschoben.
Was leistet es nicht?
- Alles, was Geld betrifft, braucht den Klick eines Menschen: Auftragspositionen hinzufügen, Express-Etiketten, Zugangsanfragen.
- Der Bot ordnet Fragen nach Schlüsselwortregeln zu und verfehlt noch manche Themen. Jeder Fehler fließt in die nächste Regelrunde ein.
- Zahlungserinnerungen und das Einsammeln der Rechnungen zum Monatsende sind gebaut und warten darauf, wieder eingeschaltet zu werden.
Was hat sich für das Team geändert?
Das Vertriebsteam fragt den Bot und bekommt in Sekunden eine Antwort. Die Entwickler, bei denen diese Fragen früher landeten, bekommen nur noch die ungewöhnlichen Fälle und bleiben bei ihrer eigentlichen Arbeit. Ihr Wissen steckt im System, sodass ein Wechsel der Zuständigkeit es nicht mehr auf null setzt.
Kundenverantwortliche reagieren auf eine Slack-Nachricht mit Button, statt jeden Auftrag vor der Kommissionierung zu prüfen. Das Lager kommissioniert nach Aufgaben, die mit festgelegter Priorität und festgelegtem Versandtag ankommen. Das Partnermanagement bindet einen neuen Partner in einem einzigen Slack-Thread an, und niemand verschiebt Roadmap-Status mehr von Hand.
Was können Sie für Ihre eigenen Abläufe mitnehmen?
- Listen Sie die Übergaben auf, nicht die Systeme. Der Aufwand steckte zwischen Vertrieb, Lager und Partnern, nicht in einem einzelnen Tool.
- Legen Sie die Oberfläche dorthin, wo die Menschen ohnehin arbeiten. Für dieses Team war das Slack.
- Lassen Sie bei jeder Entscheidung über Geld einen Menschen entscheiden. Ein Button kostet Sekunden und erhält das Vertrauen.
- Prüfen Sie Ergebnisse, nicht nur Fehler. Der gefährlichste Fehler ist ein Schritt, der stillschweigend nie gelaufen ist.
- Geben Sie jedem Alarm genau eine benannte zuständige Person.
Wenn Sie das auf Ihre eigenen Prozesse übertragen möchten, stellt der Automatisierungs-Blueprint dieselben Fragen und liefert einen Plan. Unsere Prozessautomatisierung beginnt meist mit einem Prozess wie der Auftragsprüfung oben.
FAQ
Warum Slack und nicht ein neues Dashboard?
Das Team arbeitete ohnehin den ganzen Tag in Slack. Ein neues Dashboard ist ein weiterer Tab, den niemand öffnet. Eine Slack-Nachricht mit Button erreicht die richtige Person dort, wo sie schon ist, und der Thread hält fest, was passiert ist.
Warum n8n und nicht individuell programmierter Code?
Mit n8n konnten wir die bestehenden Systeme des Kunden schnell verbinden und jeden Workflow den Menschen zeigen, die dafür zuständig sind. Die Regeln sind wichtiger als das Werkzeug. Jede Regel ist aufgeschrieben, getestet und hat eine namentlich benannte verantwortliche Person. Dieselbe Logik ließe sich später in eigenen Code überführen, falls ein Prozess dem Workflow-Tool entwächst.
Wie verhindern Sie, dass eine Automatisierung Schaden anrichtet?
Vier Gewohnheiten. Alles, was Geld betrifft, wartet auf den Klick eines Menschen. Jede Aktion wird nach der Ausführung geprüft. Ein auffälliges Ergebnis wird erneut aus der Primärquelle gelesen, bevor jemand alarmiert wird. Jeder Fehler geht an eine benannte zuständige Person, nie in einen Kanal, in dem alle annehmen, dass sich jemand anderes kümmert.
Echtes Kundenprojekt, Kunde anonymisiert. Zahlen aus Vertraulichkeitsgründen angepasst, Verhältnisse beibehalten.