Drei Workflows, die ich heute nicht mehr bauen würde
Was ich aus drei meiner eigenen Fehler gelernt habe: warum gut gemeinte Automatisierungen Schaden anrichten, wohin sie Kosten verschieben, und welche drei Fragen ich heute vor jedem Workflow stelle.
Drei Workflows, die ich heute nicht mehr bauen würde
In den vergangenen vier Jahren habe ich für Kunden hunderte Workflows gebaut. Manche laufen heute noch und produzieren Wert. Andere wurden nach sechs Monaten still abgeschaltet, weil sie mehr Schaden als Nutzen anrichteten.
Ich schreibe nicht oft über meine Fehler. In Beratung verkauft das schlecht. Aber wer Automatisierung betreibt, lernt aus Fehlern mehr als aus Erfolgen. Hier sind drei Workflows aus meiner eigenen Vergangenheit, die ich heute nicht mehr so bauen würde. Nicht weil sie technisch falsch waren. Sondern weil sie ein Problem lösten, das es nicht gab, oder ein neues schufen, das größer war als das gelöste.
Workflow eins: Die Slack-Benachrichtigung für jeden erfolgreichen Run
Ein Kunde aus 2023, knapp dreißig Mitarbeitende, klassisches B2B-Geschäft. Wir bauten einen Workflow, der eingehende Anfragen aus dem Kontaktformular qualifizierte und in HubSpot einlas. Auf Kundenwunsch hängten wir am Ende eine Slack-Benachrichtigung an, die das Vertriebsteam über jede neue Anfrage informierte.
Drei Monate später bat mich der Vertriebsleiter, die Benachrichtigung wieder abzustellen. Was war passiert?
Im ersten Monat liefen sieben Anfragen pro Woche durch. Sieben Slack-Nachrichten, die das Team las und auf die reagiert wurde. Schön.
Im dritten Monat liefen vierzig Anfragen pro Woche durch, weil unsere Lead-Generation parallel angezogen hatte. Vierzig Nachrichten in einem Channel mit zwölf Personen. Die ersten zehn wurden gelesen, die nächsten zwanzig überflogen, die letzten zehn ignoriert. Wenn dann eine relevante Anfrage dabei war, ging sie im Lärm unter.
Was ich daraus gelernt habe. Benachrichtigungen über "es ist etwas passiert" sind kein Feature, sondern Lärm. Was man benachrichtigen sollte, sind Ausnahmen. Fehler. Anfragen über einer bestimmten Größenordnung. Anfragen von Bestandskunden mit offenen Vertragsverlängerungen. Aber nicht jede einzelne neue Lead-Anfrage in einem aktiven Vertriebsteam.
Heute baue ich Benachrichtigungen mit demselben Maßstab wie ein Pager: was muss jemand sofort wissen, weil sonst Schaden entsteht? Alles andere gehört in einen Bericht, der einmal am Tag oder einmal in der Woche kommt.
Workflow zwei: Die automatische CRM-Aktualisierung aus E-Mail-Signaturen
Ein anderer Kunde, 2024, IT-Dienstleister mit hundert Mitarbeitenden. Wir bauten einen Workflow, der eingehende E-Mails scannte, die Signaturen extrahierte und die Kontaktdaten im CRM automatisch aktualisierte. Klang elegant. War aber falsch.
Was nicht bedacht war: E-Mail-Signaturen sind keine zuverlässige Wahrheitsquelle. Mitarbeiter wechseln Jobs, schreiben aber von ihrer alten Adresse, weil sie noch nicht weitergeleitet haben. Auto-Reply-Antworten enthalten Vertretungen, deren Daten in den Hauptkontakt überschrieben wurden. Mitarbeiter aus Subunternehmen mit eigenen Firmen-Suffixen wurden zu Kontakten der falschen Organisation zugeordnet.
Nach vier Monaten hatten wir 380 stille Datenfehler im CRM. Vertriebsleute riefen die falschen Personen an. Eine wichtige Mahnung ging an die alte Adresse eines ausgeschiedenen CFOs, weil die Signatur eines anderen Empfängers sie überschrieben hatte. Der Aufräumaufwand betrug zwei Wochen. Der Vertrauensschaden gegenüber dem CRM dauerte länger.
Heute baue ich keine Workflows mehr, die produktive Datenbanken ohne menschliche Bestätigung verändern. Wenn der Workflow eine Datenänderung vorschlägt, landet sie in einer Reviewing-Queue. Ein Mensch bestätigt oder verwirft. Erst dann wird sie übernommen.
Dieser Ansatz ist langsamer. Er ist auch der einzige, der das CRM nicht zu einer Vermutungsbank macht.
Workflow drei: Der dreistufige Approval-Workflow für Reisekosten unter fünfzig Euro
Drittes Beispiel, ein Kunde im professionellen Dienstleistungssektor, fünfzehn Mitarbeitende. Sie hatten einen unsauberen Approval-Prozess für Reisekosten. Wir bauten einen sauberen: Mitarbeiter reicht ein, Teamleitung prüft, Buchhaltung verbucht. Drei Stufen, jede mit Slack-Benachrichtigung und Reminder.
Nach drei Monaten Auswertung. Mitarbeiter reichten weniger Reisekosten ein als vorher. Nicht weil sie weniger reisten. Sondern weil sich für eine 14-Euro-Taxifahrt der Aufwand nicht mehr lohnte. Sie zahlten selbst.
Wir hatten einen Workflow gebaut, der das Problem "Kosten werden zu lange nicht erstattet" gelöst hatte und ein neues geschaffen: "Mitarbeiter erstatten dem Unternehmen kleine Beträge auf eigene Rechnung". Das ist aus mehreren Gründen schlecht: arbeitsrechtlich problematisch, steuerlich problematisch, und ein Signal, dass der Prozess zu schwer ist für den eigentlichen Anlass.
Heute schaue ich vor jedem Approval-Workflow auf die Beträge, die durchlaufen sollen. Wenn die durchschnittliche Position unter hundert Euro liegt, baue ich keinen mehrstufigen Genehmigungsprozess. Ich baue eine Pauschalierung mit Stichprobenkontrolle. Genehmigung kostet Zeit. Zeit ist teurer als das, was geprüft wird, wenn das Prüfobjekt zu klein ist.
Was die drei Beispiele gemeinsam haben
Drei Fehler, drei Lehren. Wenn ich sie zusammenfasse, kommt ein Muster heraus, das ich heute öfter erkenne als früher.
Erstens. Automatisierung sollte ein Problem lösen, das die Beteiligten als Problem empfinden. Nicht eines, das von außen erfunden wird. In keinem der drei Fälle hatte sich jemand beschwert: weder über fehlende Lead-Updates, noch über CRM-Lücken, noch über zu lasche Reisekostenprüfung.
Zweitens. Jede Automatisierung verschiebt Kosten. Selten verschwinden sie. Im ersten Fall verschob sie kognitive Last vom Bauenden zum Vertriebsteam. Beim zweiten landeten Fehlerquellen vom manuellen Erfassen im automatischen, wo sie schwerer zu finden sind. Im dritten zahlten Mitarbeitende den Preis aus eigener Tasche.
Wer Automatisierung verspricht, sollte angeben können, wohin die Kosten verschoben werden. Wer das nicht kann, hat die Auswirkung nicht zu Ende gedacht.
Drittens. Reversibilität ist unterschätzt. Alle drei Workflows liefen monatelang, bevor jemand ihre Wirkung verstand. Wenn man sie früher hätte stoppen können, hätten wir weniger Schaden gehabt. Heute baue ich produktive Workflows so, dass sie nach einem Knopfdruck wieder gestoppt werden können, ohne dass jemand verloren geht. Eine Pause-Funktion gehört zu jedem produktiven Setup, von Anfang an.
Was ich heute anders mache
Vor jeder neuen Automatisierung stelle ich drei Fragen. Was würde passieren, wenn dieser Workflow nicht existiert? Wer trägt die Kosten, die ich verschiebe? Wie schalte ich ihn wieder ab, wenn er den falschen Effekt hat?
Wer die ersten beiden Fragen nicht klar beantworten kann, sollte den Workflow nicht bauen. Wer die dritte nicht beantworten kann, sollte ihn nicht produktiv schalten.
Diese drei Fragen sind nicht originell. Sie sind nur ungewöhnlich, weil im Automatisierungsalltag selten gefragt wird, ob etwas gebaut werden sollte. Es wird gefragt, ob es gebaut werden kann.
Wer wissen möchte, welche Workflows im eigenen Unternehmen heute mehr Schaden als Nutzen anrichten, kann das im kostenlosen Automations-Check in etwa 30 Minuten herausfinden.