Was Ihr KI-Agent nicht bewältigen kann, ist das Geschäft, das Sie noch nicht aufgebaut haben

7 min read

IKEAs Chatbot hat Arbeitsplätze geschaffen.

Nicht durch mehr Leistung, sondern indem er aufzeigte, was er nicht konnte.

Billie, IKEAs Kundenservice-Agent, löst seit 2021 47% aller eingehenden Anfragen ohne menschliche Hilfe. 3,2 Millionen Interaktionen, 13 Millionen Euro Einsparungen, und mittlerweile hat jede Business-Transformation-Präsentation in Europa eine Folie darüber. Die 47%-Zahl wurde so oft in Pitch-Decks kopiert, dass sie praktisch das "läuft auf meinem Rechner" der AI-Business-Cases geworden ist: jeder zitiert sie, niemand prüft, was darunter läuft.

Niemand hat die andere Spalte beleuchtet.

Die 53%, die Billie nicht bewältigen konnte, speisten ein Umschulungsprogramm: 8.500 Call-Center-Mitarbeiter wurden zu Remote-Inneneinrichtungsberatern umgeschult. Der Kanal generierte 1,3 Milliarden Euro im Geschäftsjahr 2022. Um präzise zu sein: Diese Zahl umfasst Ingkas gesamten Remote-Verkaufsbetrieb, und ein Teil dieses Umsatzes existierte bereits vor dem Umschulungsprogramm. Der kausale Zusammenhang ist nicht perfekt sauber. Aber die Größenordnung stimmt, und die strategische Erkenntnis braucht keine perfekte Kausalität. Das ist keine HR-Geschichte. Es ist ein Produktsignal, das alle falsch gelesen haben.

Geteilte Büro-Illustration: links zeigt ängstlichen Büroangestellten, der KI-Metriken auf Dashboards feiert; rechts zeigt selbstbewussten Profi, der Fehlerprotokolle und Geschäftsmuster mit Lupe analysiert
Die Erfolgsmetriken Ihrer KI sind die Geschäftsgoldmine von jemand anderem.

Das Verhältnis, über das niemand berichtete

Die Wirtschaftspresse berichtete über den IKEA-Fall und rahmte ihn sofort als Geschichte der Belegschaftstransformation. "KI schafft Arbeitsplätze, zerstört sie nicht." Schöne Schlagzeile. Sogar wahr. Aber sie begrub die eigentliche Erkenntnis unter einer beruhigenden Erzählung, die hauptsächlich dazu gedacht war, der Geschäftsführung gleichzeitig ein besseres Gefühl bezüglich des KI-Budgets und der Belegschaftsoptik zu geben.

IKEA fand keine 1,3 Milliarden Euro, indem sie einen besseren Chatbot bauten. Sie fanden sie, indem sie fragten, was der Chatbot nicht konnte, und diese Antwort als Geschäftschance behandelten. Die 53% waren keine Fehlermetrik. Sie waren eine Nachfragekarte, die niemand zu lesen gedacht hatte.

Jedes Mal, wenn Billie ein Gespräch weiterleitete, signalisierte er einen Kundenbedarf, den das Produkt noch nicht bedienen konnte. 53% der Kundeninteraktionen waren unbefriedigte Nachfrage, die in der Log-Datei saß. Unbefriedigte Nachfrage ist kein Problem, das man umgeht, sondern eine Produktlücke mit Preisschild. Und je länger man die 47% optimiert, desto unsichtbarer werden die 53%, weil das Dashboard suggeriert, dass das System einwandfrei funktioniert.

Du liest das falsche Dashboard

Jedes KI-Agent-Team, das ich kenne, überwacht die Deflection Rate. Das ist die naheliegende Metrik: Wie viele Anfragen löst der Agent, ohne zu eskalieren? Höher ist besser. Man optimiert sie, berichtet darüber, packt sie in die monatliche Review-Präsentation. Die Kurve steigt, alle fühlen sich gut bezüglich des Quartals.

Das Problem ist nicht, dass die Deflection Rate nutzlos wäre. Sie ist strukturell blind dafür, was die Nutzer tatsächlich in den Gesprächen wollten, die der Agent abgebrochen hat. Die Metrik misst, was erfolgreich war. Sie sagt dir nichts über die Form dessen, was gescheitert ist.

Denk an Google Analytics. Seitenaufrufe zeigen dir, was funktioniert. Ausstiegsseiten zeigen dir, wo dein Produkt kaputt ist. Ausstiegsseiten sind fast immer wertvoller für die Entscheidung, was als nächstes gebaut werden soll. (Ist mir mal in GA4 passiert. 6 Monate Features gebaut basierend auf dem, was Leute am längsten angeschaut haben, was sich als Preisseite herausstellte, weil sie verwirrt waren, nicht interessiert. Lehrbuch-Seitenquest. Ich habe den völlig falschen Mob gefarmt. Das tat weh.) Man behebt keine 38% Ausstiegsrate auf der Checkout-Seite, indem man sich zu den 62% gratuliert, die es geschafft haben. Man schaut, wo Leute gegangen sind, und fragt warum.

Agent-Logs funktionieren genauso. Du optimierst die 47%. Du liest nicht die 53%.

Noch ein Grund anzufangen: Wenn deine Agents auf einer CLI-nativen Architektur laufen, kommen diese Logs strukturiert heraus. Nicht als Suppe aus Gesprächstext, sondern als tatsächlich maschinenlesbare Ausgabe, die du in einen Audit-Prompt pipen kannst, ohne einen Nachmittag mit Datenbereinigung zu verbringen. Ich bin ausführlich auf das Argument eingegangen, warum CLI-native Agents auswertbarere Logs produzieren, lesenswert, bevor du dieses Audit auf chaotischen Logs versuchst und dich wunderst, warum das Clustering nutzlos zurückkommt.

Dein Fehler-Log ist eine Nachfragekarte

Nicht alles, was dein Agent verweigert, ist eine Chance. Das vorweg. Bewusste Blockaden, Third-Party-Auth-Walls, destruktive Operationen, Dinge, die per Policy außerhalb des Bereichs liegen: die funktionieren korrekt. Das sind keine Produktlücken. Der Filter ist einfach: Häufigkeit kombiniert mit Umformulierung ergibt ein echtes Signal. Ein einzelnes Vorkommen ist wahrscheinlich Rauschen.

4 Signale, die es wert sind, in dem gelesen zu werden, was dein Agent aufgibt, vom stärksten zum subtilsten.

Signal 1: Wiederkehrende verweigte Fragen. Wenn verschiedene Nutzer innerhalb eines 30-Tage-Fensters an derselben Wand mit demselben Fragentyp scheitern, ist diese Wand eine Feature-Anfrage mit angehängter Stichprobengröße. Du schaust nicht auf 1 verwirrten Nutzer. Du schaust auf Nachfrage, die du noch nicht bedient hast.

Signal 2: Wiederholte In-Session-Umformulierungen. Ein Nutzer, der dieselbe Anfrage 3 oder 4 Mal umformuliert, ohne eine brauchbare Antwort zu bekommen, ist nicht verwirrt darüber, wie das Produkt funktioniert. Er ist hartnäckig, weil der Bedarf real ist und er ihn nirgendwo anders finden kann. Loop-Anzahl ist ein Maß dafür, wie sehr sie es wollen.

Signal 3: Systematische Fallback-Muster. Schau dir an, welche Kategorie von Anfragen konsistent auf Fallback trifft, nicht einzelne Anfragen, Kategorien. "Nutzer wollen 2 Optionen direkt vergleichen." "Nutzer wollen eine geplante Nachfassung." Das sind keine zufälligen Fehler. Das ist der Umriss dessen, was deine Nutzer tatsächlich wollen versus was du gebaut hast.

Signal 4: Aufwändige Wiederholungsversuche. Wenn ein Nutzer dieselbe Anfrage 5 Mal in einer einzigen Session mit zunehmender Spezifität stellt, ist das kein verwirrter Nutzer. Das ist jemand, der nicht finden kann, was er braucht, und zwar nirgendwo anders. Wiederholungsanzahl ist ein Proxy für Zahlungsbereitschaft. Je höher der Aufwand, desto wahrscheinlicher schaust du auf einen Premium-Tier-Bedarf, der in deinem aktuellen Produkt keinen Platz hat.

1 Vorbehalt, den ich ernst meine: Die Signale sind real. Deine Interpretation davon ist es vielleicht nicht. Führe das Audit durch, aber baue nicht direkt aus der Ausgabe, ohne zumindest etwas informelle Validierung vorher. Ein 30-minütiges Gespräch mit 2 Nutzern schlägt jedes Mal ein hochsicheres KI-Clustering.

Das Fehler-Log ist die einzige Produktspezifikation, die deine Nutzer tatsächlich geschrieben haben.

Was 3,5 GB Logs mir erzählten

Ich führte das Audit auf 3,5 GB Claude Code-Transkripten durch: 2.801 Dateien, 30 Tage, 101 Projekte.

Das zählbarste Muster war genau das, was das Dashboard mir die ganze Zeit gesagt hatte: 112 Auth-Fallbacks auf Third-Party-Panels. Sichtbar, erwartet und völlig nicht umsetzbar, weil die Lösung von Anbietern abhängt, die keinen Grund haben, sich um meinen Use Case zu kümmern. Davon wusste ich seit Monaten.

Das waren meine 47%.

Was sich in der anderen Spalte versteckte, sah so aus. Etwa 20 rohe Vorkommen einer Umformulierungs-Schleife, was nach Rauschen klingt, bis man in diese Sessions hineinschaut und realisiert, dass "dasselbe" oder "immer noch kaputt" 2 bis 5 Mal pro Session zurückkam, jedes Mal dieselbe Sequenz: Der Agent lieferte ein UI-Feature und erklärte es für erledigt, ich testete manuell auf Mobile, etwas ging kaputt, der Agent startete im nächsten Zug aus einem etwas anderen Winkel neu, immer noch unfähig zu registrieren, dass "erledigt" bedeutete, auf allen Oberflächen zu funktionieren und nicht nur in der Sandbox, zu der er während der Session Zugang hatte, und bei der 4. Schleife verbrannte ich Zeit, die ich nicht eingeplant hatte, für ein Problem, das ich technisch schon zweimal "gelöst" hatte. Bei Schleife 4 fühlte es sich an wie ein Dark Souls-Run, bei dem jemand das Lagerfeuer weggepatcht hatte und ich immer noch dasselbe Ausweichmuster beim selben Boss probierte. (Dark Souls sagt wenigstens "YOU DIED", damit man weiß, wann man aufhören soll.)

Das Fehler-Log kodierte etwas Spezifisches: Ich brauchte einen blockierenden Hook, der sich weigert, einen Turn zu schließen ohne echten End-to-End-Beweis, einen Test und keine Erklärung, Desktop und Mobile. 1 Tag Arbeit zum Bauen, und es war in 20 Zeilen Log versteckt, die niemand las.

Dann 7 Vorkommen von etwas qualitativ anderem: Content, der nach KI roch, die Art generischer Taglines und Off-Persona-Copy, die auf einer Lifestyle-Site landet und sofort signalisiert, dass kein Mensch sie geschrieben hat. (Ich kann es immer erkennen, wenn es passiert. Es hat eine spezifische Flachheit, als hätte das Modell nach der ersten akzeptablen Formulierung gegriffen und dort aufgehört.) Das war keine externe Nutzernachfrage. Es war eine interne Spec-Lücke: kein Content-Quality-Gate mit expliziten Anti-Patterns und Persona-Constraints pro Site. Das Fehler-Log brachte keine Nutzer-Feature-Anfrage an die Oberfläche. Es brachte eine Abwesenheit an die Oberfläche, die ich nie formalisiert hatte. Anderer Mechanismus als das Schleifenmuster, dieselbe Quelle.

Das Dashboard zählte 112 Auth-Fallbacks. Die tatsächlichen Kosten lagen in den Schleifen und den 7 Off-Tone-Lieferungen. Und falls 7 von 2.800 Dateien zu klein klingt, um sich darum zu kümmern: Jede kostete mich eine komplette manuelle Umschreibungssession.

Führe das 53%-Audit auf deinen Logs durch

3 Prompts. Kopiere sie in Claude mit deinen Agent-Logs. Führe sie der Reihe nach aus, oder beginne einfach mit Prompt 1, wenn du wenig Zeit hast.

Prompt 1: Clustere verweigte Anfragen und erkenne Umformulierungsschleifen (Signale 1+2)

Analysiere diese Agent-Logs und tue folgendes:

1. Extrahiere alle Anfragen, die der Agent verweigert, nicht bewältigen konnte oder an Fallback weitergeleitet hat.
2. Clustere sie nach Thema. Benenne jeden Cluster in verständlicher Sprache.
3. Für jeden Cluster: zähle Häufigkeit, markiere jede Session, in der dieselbe Anfrage
   2+ Mal ohne Erfolg umformuliert wurde.
4. Klassifiziere jeden Cluster: Feature-Lücke | Bug | absichtlich außerhalb des Bereichs | unklar.
5. Schätze potentiellen Wert: niedrig | mittel | hoch (basierend auf Häufigkeit und Wiederholungsaufwand).

Für jeden Cluster gib aus: Name, Häufigkeit, Umformulierungssessions, Kategorie, potentieller Wert.

Schließe mit 1 Satz: "Wenn du 1 Sache aus dieser Ausgabe bauen müsstest, wäre es ___."

Prompt 2: Isoliere Umformulierungsschleifen (Signal 2 Tiefenanalyse)

Finde aus diesen Agent-Logs alle Sessions, in denen der Nutzer dieselbe 
Anfrage 2 oder mehr Mal umformuliert hat, ohne eine erfolgreiche Antwort.

Für jede Session:
- Was war die ursprüngliche Anfrage?
- Wie oft hat der Nutzer umformuliert?
- Was war das finale Ergebnis (Fallback / teilweise / abgebrochen)?
- Wiederholt sich dieses Muster über mehrere Sessions, oder ist es einmalig?

Gruppiere Sessions nach zugrundeliegendem Bedarf, nicht nach exakter Formulierung. Trenne echte 
wiederkehrende Nachfrage von einmaliger Reibung.

Prompt 3: Bewerte nach Häufigkeit x Aufwand (Signale 3+4)

Bewerte aus diesen Agent-Logs jedes Fehlermuster:
Häufigkeit x Nutzeraufwand = Prioritätsscore

Nutzeraufwand = Anzahl Wiederholungen + Umformulierungsanzahl pro Session.

Rangiere alle Muster nach Prioritätsscore, höchste zuerst.
Für die Top 5: Was würde es brauchen, um diese Anfrage erfolgreich zu bewältigen? 
1 Satz pro Muster.

Markiere jedes Muster, bei dem Nutzeraufwand hoch, aber Häufigkeit niedrig ist.
Das sind deine wertvollen Ausreißer.

Prompt 2 bringt spezifisch etwas an die Oberfläche, das es wert ist, mit einem breiteren Rahmen gelesen zu werden: Wiederholte Session-Schleifen bedeuten nicht nur "der Agent ist wiederholt gescheitert", sie signalisieren, was dein Agent werden soll. Ich habe ausgepackt, was wiederholte Session-Schleifen über deinen Agent signalisieren im Detail, die Rahmung gilt hier direkt.

2 Lesarten, dieselben Logs

IKEA baute keinen besseren Chatbot. Sie lasen die Abandonment-Queue und fragten, was sie ihnen über das Geschäft erzählte, das sie noch nicht gebaut hatten.

Du hast dieselben Logs. Du liest sie wahrscheinlich nicht (vielleicht liege ich falsch, vielleicht führt dein Team bereits jedes Sprint dieses Audit durch und die Fehler-Queue ist leer und ihr baut präzise das, was Nutzer nirgendwo anders finden können). In 3 Jahren des Betriebs von Agents über verschiedene Produkte und Pipelines habe ich dieses Setup nie gesehen. Was ich sehe, ist eine Deflection Rate auf einem Dashboard und einen Log-Ordner, den niemand öffnet.

Füge deine Logs in Prompt 1 ein. Lies die Spalte "potentieller Wert". Prüfe, ob das, was an die Oberfläche kommt, etwas ist, wovon du seit Monaten weißt, aber nie gebaut hast.

Wenn die Antwort ja ist, das sind deine 1,3 Milliarden Euro, die sich in Sichtweite verstecken.

Quellen

Dieser Beitrag kann Affiliate-Links enthalten. Wenn du sie anklickst, verdiene ich möglicherweise eine kleine Provision (kostet dich nichts und hilft mir dabei, weiterhin täglich qualitativ hochwertige Artikel für dein Lesevergnügen zu liefern).