Warum ein KI-Stabschef zuerst Vorfälle lösen sollte, nicht Dashboards bauen

Wenn Operatoren zum ersten Mal einen KI-Stabschef einrichten, wollen sie fast immer dasselbe: eine tägliche Zusammenfassung. Was ist in der Inbox passiert, was steht im Kalender, was hat sich in Pipedrive bewegt. Klingt vernünftig. Ist es aber nicht als erster Schritt.

Das Problem ist nicht, dass Übersichten nutzlos wären. Das Problem ist, dass sie diffus sind. Ein System, das "jedem ein bisschen hilft", löst kein einziges Problem wirklich – und genau das macht es schwer, den Wert überhaupt zu belegen, geschweige denn ihn zu skalieren.

Die Analogie aus der IT-Betriebswelt ist hier lehrreich: Self-Healing-ITOps-Systeme, die tatsächlich funktionieren, setzen nicht auf breite Berichterstattung. Sie setzen auf Root-Cause-Analyse plus governte Automatisierung für einen konkreten, wiederkehrenden Vorfalltyp. Erst wenn das stabil läuft, wird ausgeweitet.

Vertikale Vorfälle sind eng definiert. Eine Eskalationskette, die immer wieder bei derselben Person hängen bleibt. Ein Übergabepunkt zwischen Sales und Onboarding, an dem regelmäßig Kontext verloren geht. Ein bestimmter Typ von Kundenanfrage, der immer zu spät beantwortet wird.

Der Vorteil dieser Enge ist praktisch, nicht theoretisch: Governance-Entscheidungen für einen vertikalen Vorfall lassen sich in einem einzigen Meeting treffen. Wer hat Zugriff auf welche Daten, wann wird eskaliert, wer entscheidet im Zweifel. Bei horizontalen Systemen, die über mehrere Funktionen hinweg operieren, wird genau das exponentiell komplexer – Berechtigungen, fragmentierte Systeme, unklare Verantwortlichkeit verzögern den Rollout.

Für einen COO heißt das konkret: Bevor der KI-Stabschef eine Wochenübersicht über alle Deals in HubSpot bauen soll, sollte er erst lernen, warum bestimmte Deals systematisch drei Tage in "Verhandlung" hängen bleiben, bevor jemand nachfasst. Das ist ein Vorfall mit klarer Ursache, klarer Metrik und klarem Besitzer.

Vertikale KI-Projekte liefern messbare Ergebnisse, weil sie repetitive, hochwertige Workflows automatisieren statt allgemein zu unterstützen. Die Zahlen aus internen Tool-Projekten sprechen dafür: ROI-Zeiträume von zwei bis vier Monaten für spezialisierte interne Tools, gegenüber zwölf bis achtzehn Monaten für breite Business-Intelligence-Systeme. Dazu kommen Berichte über bis zu 80 Prozent Kostenersparnis und fünf- bis zehnfach schnellere Entwicklung bei eng zugeschnittenen internen Lösungen.

Das deckt sich mit dem, was ich bei Operatoren sehe, die Moments AI produktiv nutzen: Der erste Aha-Moment kommt nie durch eine Zusammenfassung. Er kommt, wenn der Stabschef merkt, dass eine bestimmte Kundenanfrage aus dem Postfach immer denselben Umweg über drei Personen macht, bevor sie beantwortet wird – und diesen Umweg selbst schließt, statt ihn nur zu protokollieren.

Auch die Zahlen zu Reporting- und IT-Aufwand zeigen dasselbe Muster: Wo KI konkrete, wiederkehrende Aufgaben übernimmt, sinkt der Zeitaufwand für Reporting um bis zu 40 Prozent und die IT-Belastung um bis zu 60 Prozent. Das sind Effekte, die aus gelösten Einzelfällen entstehen, nicht aus einem generischen Dashboard.

Es gibt noch einen zweiten Grund, vertikal zu starten, und der wird oft übersehen: Risiko. Vorfälle, die in regulierten oder geschäftskritischen Bereichen liegen – eine falsche Freigabe in der Buchhaltung, eine übersehene Compliance-Anforderung, eine fehlerhafte Eskalation bei einem Großkunden – haben ein hohes Schadenspotenzial. Organisationen mit starken Governance-Rahmenwerken für solche Fälle verzeichnen bis zu 60 Prozent weniger Compliance-Verstöße.

Ein horizontales System, das breit über alle Funktionen läuft, verteilt Aufmerksamkeit gleichmäßig – auch auf Dinge, die keine Konsequenzen haben, wenn sie schiefgehen. Das fühlt sich produktiv an, ist es aber nicht, wenn währenddessen der eine Vorfall mit echtem Schadenspotenzial unbeaufsichtigt bleibt, weil er in der Masse der "Insights" untergeht.

Deshalb sollte die erste Frage an einen KI-Stabschef nicht lauten "Was ist diese Woche passiert?", sondern "Welcher wiederkehrende Fehler hat uns in den letzten drei Monaten am meisten Geld oder Vertrauen gekostet?". Das ist eine Frage mit einer Antwort, keine Frage, die eine Übersichtsseite verlangt.

In der Praxis bedeutet das: Statt den Stabschef zu bitten, jeden Morgen den Posteingang zusammenzufassen, gibt man ihm einen einzigen, klar umrissenen Vorfall zum Lösen. Etwa: Immer wenn ein Lead in Pipedrive länger als 48 Stunden ohne Follow-up bleibt, soll der Stabschef automatisch eine Erinnerung an den zuständigen Sales-Mitarbeiter schicken und, wenn nach weiteren 24 Stunden nichts passiert, eskalieren.

Oder in Linear: Ein Ticket, das den Status "blocked" seit mehr als drei Tagen trägt, ohne dass ein Kommentar hinzugefügt wurde, ist ein Vorfall, kein Trend. Der Stabschef kann prüfen, wer blockiert, warum, und eine konkrete Nachfrage auslösen – statt das nur in einem wöchentlichen Report zu erwähnen.

Oder bei Terminanfragen über Calendly: Wenn ein bestimmter Kundentyp regelmäßig Termine kurzfristig absagt und dadurch Slots blockiert, ist das ein vertikaler Vorfall mit klarer Ursache – nicht ein Datenpunkt für eine allgemeine Auslastungsstatistik.

Erst wenn solche engen Fälle stabil laufen – wenn Governance, Eskalationsregeln und Vertrauen etabliert sind – lohnt es sich, den Stabschef horizontal auszuweiten: über mehrere Teams hinweg, über mehrere Tools hinweg, mit echten Übersichten, die dann auch etwas bedeuten, weil die zugrunde liegenden Prozesse bereits verstanden und gehärtet sind.

Empfehlenswert ist eine klare Abfolge: zuerst die Vorfälle mit dem höchsten Risiko oder größten geschäftlichen Einfluss identifizieren, dann Anwendungsfälle mit klaren Kennzahlen und eindeutiger Verantwortlichkeit priorisieren, Governance für diese engen Fälle festlegen, frühe Erfolge sichtbar machen – und erst danach horizontal ausweiten.

Das ist keine Frage von Geschmack, sondern von Reihenfolge. Horizontale Systeme sind nicht per se schlecht, sie sind nur die falsche erste Investition. Sie werden erst wertvoll, wenn die vertikale Arbeit bereits Vertrauen und Struktur geschaffen hat.

Wer seinen KI-Stabschef also als Dashboard-Bauer einführt, bekommt am Ende ein hübsches Dashboard. Wer ihn als Vorfall-Löser einführt, bekommt einen Stabschef, der tatsächlich etwas übernimmt.