Warum euer Contact Center das teuerste Symptom eurer Prozessprobleme ist

Es gibt eine Zahl, die in den meisten Service-Organisationen niemand kennt. Nicht weil sie schwer zu ermitteln wäre, sondern weil niemand danach fragt. Die Zahl beschreibt den Anteil des Kontaktvolumens, der nicht durch Kundenbedürfnisse entsteht, sondern durch vorgelagerte Fehler anderer Abteilungen.

Diese Zahl heißt Failure-Demand-Anteil. Und sie liegt in den meisten Organisationen, die ich von innen gesehen habe, zwischen 40 und 60 Prozent.

Der Begriff geht auf John Seddon zurück und beschreibt Nachfrage, die durch das Versagen der Organisation selbst erzeugt wird. Der Kunde kontaktiert den Service nicht, weil er eine Frage hat oder Hilfe braucht. Er kontaktiert ihn, weil jemand oder etwas vorher versagt hat.

Konkret: Die Rechnung ist falsch. Die Lieferung ist nicht nachvollziehbar. Der Vertrag enthält Klauseln, die kein Mensch versteht. Die Website bricht mitten im Bestellprozess ab. Der Chatbot gibt eine falsche Auskunft. Das Produkt tut nicht, was die Werbung versprochen hat.

Das sind keine Service-Anliegen. Das sind Prozessbrüche aus Billing, Logistik, Produktmanagement, IT, Marketing oder dem KI-Team. Das Contact Center repariert sie nur.

Failure Demand ist dabei klar von Value Demand zu unterscheiden. Value Demand ist der Kontakt, den die Organisation erzeugen will: Beratung, Bestellung, echte Hilfe. Failure Demand ist der Kontakt, den die Organisation erzeugt, ohne es zu wollen - und oft ohne es zu wissen.

In den meisten Contact Centern wird Failure Demand in denselben Queues verarbeitet wie echte Servicenachfrage. Es gibt kein Dropdown, das zwischen „Kunde braucht Hilfe" und „Jemand anderes hat Mist gebaut" unterscheidet. Die ACD-Anlage sieht nur einen Anruf. Das Ticketsystem sieht nur ein Ticket. Das Dashboard sieht nur ein Volumen.

Und so wächst das Contact Center Quartal für Quartal. Mehr Agents für mehr Kontakte. Der CFO fragt, warum Service so teuer ist. Die Antwort lautet immer: „Weil das Volumen gestiegen ist." Die richtige Frage wäre: „Warum ist das Volumen gestiegen?" Aber die stellt niemand, weil die Daten fehlen, um sie zu beantworten.

Das Paradoxe: Die meisten Operations-Teams können die Top-3-Ursachen für vermeidbare Kontakte sofort benennen. Sie wissen, dass die Rechnung verwirrend ist. Sie wissen, dass der Self-Service-Prozess nicht funktioniert. Sie wissen, dass der Bot Unsinn erzählt. Was fehlt, ist kein Wissen. Was fehlt, ist ein Prozess, der dieses Wissen verbindlich dorthin zurückspielt, wo die Ursache liegt.

Die Frage klingt polemisch, aber sie ist ernst gemeint. In jeder Organisation, die ich beraten oder operativ geführt habe, war es kurzfristig einfacher, drei neue Agents einzustellen, als ein Billing-Problem zu lösen. Und dafür gibt es strukturelle Gründe:

Das Budgetproblem. Das Contact Center hat ein eigenes Budget. Wenn das Volumen steigt, bekommt es mehr Geld für mehr Agents. Das Billing-Team, das die fehlerhaften Rechnungen erzeugt, hat ein anderes Budget. Dort taucht das Problem nie auf. Die Kosten, die der Fehler verursacht, werden im Service verbucht, nicht bei der Ursache.

Das Zuständigkeitsproblem. Wer ist verantwortlich dafür, dass 20.000 Kund:innen pro Monat anrufen, weil sie ihre Rechnung nicht verstehen? Nicht der Service - der beantwortet den Anruf nur. Aber auch nicht das Billing-Team - denn die Rechnung entspricht den Vorgaben. Es fehlt ein Owner, der für die Existenz des Kontaktgrunds verantwortlich ist, nicht nur für den Inhalt des Dokuments.

Das Messproblem. Die meisten Organisationen messen Kontaktgründe in IT-Sprache statt in Kundensprache. „Rechnungsreklamation" sagt nichts darüber, ob die Rechnung falsch war, unverständlich oder zu spät kam. Und wenn Amazon mit seinen ursprünglich 360 Contact Codes eines gelernt hat, dann dass mehr Codes nicht mehr Erkenntnis bedeuten, sondern mehr Rauschen.

Ein Rückspielprozess ist die Mechanik, die Failure Demand sichtbar macht und an die Ursache zurückführt. Er besteht aus fünf Teilen, die zusammenhängen:

1. Kontaktgründe in Kundensprache. 25 bis 50 Codes, MECE (mutually exclusive, collectively exhaustive), in der Sprache des Kunden formuliert, nicht in der Sprache des CRM-Systems. Nicht „Rechnungsreklamation", sondern „Rechnung stimmt nicht" oder „Rechnung unverständlich". Jeder Code hat genau einen Owner außerhalb des Service. Die Codes ändern sich idealerweise nie - das ermöglicht Trendanalysen über Jahre.

2. Markierung im Tagesgeschäft. Jeder Kontakt wird als Value Demand oder Failure Demand klassifiziert. Minimalinvasiv: Ein Dropdown pro Kontakt, das nach dem Gespräch ausgefüllt wird. Die Markierung muss so einfach sein, dass sie in unter zwei Sekunden passiert. Alles andere wird nicht gelebt.

3. Monatlicher Rückspielprozess. Einmal im Monat legt der Service-Bereich die Top-Failure-Demand-Kategorien auf den Tisch - mit Volumen, Trend, Kostenimpact und 1-3 konkreten Maßnahmenvorschlägen. Die Owner aus den verursachenden Abteilungen berichten selbst über den Status ihrer Maßnahmen. Das ist kein Fingerpointing-Format. Der Fokus liegt auf Ursachenbeseitigung, nicht auf Schuldzuweisung.

4. Sponsorschutz. Der Rückspielprozess braucht einen Sponsor auf Geschäftsführungsebene, der den Prozess schützt. Ohne diesen Schutz wird der Rückspielprozess in dem Moment sterben, in dem er zum ersten Mal unbequeme Wahrheiten über das Produkt oder die Website auf den Tisch legt. Das ist kein theoretisches Risiko - es passiert regelmäßig.

5. Wirksamkeitsmessung. Nicht nur „weniger Kontakte", sondern Kontaktrate normalisiert auf Kundenbasis (Contacts per Customer, aufgeschlüsselt nach Neukund:innen und Bestand) und Repeat Contacts getrennt nach service- vs. systemverursacht. Denn wenn das Kontaktvolumen sinkt, könnte das auch an weniger Kund:innen liegen. Und wenn die Repeat-Contact-Rate sinkt, war es vielleicht nicht der Rückspielprozess, sondern eine Prozessänderung.

Die meisten Organisationen rechnen Servicekosten über Kosten pro Kontakt. Das ist legitim als Basismetrik. Aber es ist die halbe Wahrheit, weil es die Downstream-Kosten ignoriert.

Ein Beispiel: Ein Kunde ruft an, weil ein Produkt defekt geliefert wurde. Der Kontakt kostet im Schnitt 6-8 Euro (Handling-Kosten). Aber danach kommt ein Techniker-Einsatz (80-150 Euro), eventuell eine Gutschrift (variabler Wert), ein Ersatzprodukt (Logistikkosten) und ein zweiter Anruf, weil der Kunde den Status wissen will. Die tatsächlichen Kosten eines einzelnen Failure-Demand-Kontakts liegen oft beim 5- bis 15-fachen der reinen Handling-Kosten.

Wer seinen Failure-Demand-Anteil von 50% auf 30% senkt, spart nicht nur 20% Kontaktvolumen. Er spart Techniker, Gutschriften, Rework, Eskalationen, Beschwerden und die Fluktuation, die entsteht, wenn Agents tagein, tagaus Probleme lösen müssen, die sie nicht verursacht haben.

Seit der breiten Einführung von Chatbots und Voicebots gibt es eine neue Kategorie, die besonders heimtückisch ist: AI Failure Demand. Das ist Kontaktvolumen, das durch schlecht konfigurierte oder halluzinierende KI-Systeme entsteht.

Der Mechanismus: Der Kunde versucht, sein Anliegen über den Bot zu lösen. Der Bot versteht das Anliegen nicht, gibt eine falsche Auskunft oder dreht sich im Kreis. Der Kunde eskaliert zum menschlichen Service - und ist bei Ankunft bereits frustriert, oft wütend. Die Recovery-AHT (die Zeit, die der Agent braucht, um den Bot-Fehler zu reparieren und den Kunden wieder einzufangen) liegt erfahrungsgemäß beim 2- bis 3-fachen eines normalen Kontakts.

Organisationen, die KI einsetzen, brauchen deshalb eine eigene Metrik: AI Failure Demand. Wie viel Volumen erzeugt die KI, das beim menschlichen Service aufschlägt? Und wie hat sich dieses Volumen seit dem letzten Release des Bot-Modells verändert?

Wer nur die Autonomous Handle Rate (den Anteil der Anfragen, die der Bot allein löst) misst, sieht die halbe Wahrheit. Die andere Hälfte steckt in der Frage, was mit den Anfragen passiert, die der Bot nicht löst - und ob er sie verschlimmert hat.

Wer noch keinen Rückspielprozess hat, braucht keinen Change-Management-Workshop und kein Transformationsprogramm. Es reicht mit drei Dingen zu beginnen:

Woche 1-2: Kontaktgründe neu schneiden. Eine Handvoll Leute aus dem Serviceteam, idealerweise ergänzt um jemanden aus Produkt und Billing, setzt sich zusammen und formuliert 25-40 Kontaktgründe in Kundensprache. MECE. Jeder Grund bekommt einen Owner außerhalb des Service.

Woche 3-4: Markierung starten. Dropdown im CRM oder Ticketsystem. Jeder Kontakt wird markiert: Value oder Failure Demand, plus Kontaktgrund. Die ersten zwei Wochen sind Kalibrierung - die Codes werden geschärft, Definitionen angepasst, Edge Cases geklärt.

Ab Woche 5: Erster Rückspielprozess. Die Daten werden zum ersten Mal aufbereitet. Top-5-Failure-Demand-Kategorien mit Volumen und Trend. Vorgelegt an die Owner. Kein Blame Game, sondern eine gemeinsame Frage: Was können wir tun, damit dieser Kontaktgrund in drei Monaten kleiner ist?

Die Erfahrung zeigt: Schon nach den ersten 4-8 Wochen gibt es Kontaktgründe, die sich durch einfache Maßnahmen (klarerer Text auf der Rechnung, geänderter Self-Service-Prozess, korrigiertes Bot-Training) substanziell reduzieren lassen. Oft sind die ersten Wins überraschend einfach - sie waren nur nie sichtbar.

Ein häufiger Fehler: Organisationen springen direkt in Six-Sigma- oder Lean-Methoden, ohne vorher die Kontaktgrund-Architektur sauber aufzusetzen. Das ist, als würde man eine Datenanalyse auf einer Datenbank machen, die keine konsistenten Felder hat.

Root-Cause-Analyse ergibt erst Sinn, wenn die Reason Codes sauber sind. Erst zählen, dann verstehen, dann beseitigen. Nicht umgekehrt.

Ein Punkt, der in der Praxis selten berücksichtigt wird: Neukund:innen erzeugen 3- bis 5-mal mehr Kontakte als Bestandskund:innen. Das klingt intuitiv, hat aber massive Konsequenzen für die Messung.

Wenn euer Unternehmen gerade schnell wächst, steigt euer Kontaktvolumen - aber nicht, weil euer Service schlechter geworden ist, sondern weil ihr mehr Neukund:innen habt. Wer das nicht getrennt misst (Contacts per New Customer vs. Contacts per Existing Customer), steuert blind.

Dasselbe gilt für Failure Demand: Ein überproportionaler Anteil des Failure-Demand-Volumens kommt von Neukund:innen, die zum ersten Mal auf unklare Rechnungen, unverständliche Verträge oder kaputte Onboarding-Prozesse treffen. Bestandskund:innen haben sich entweder arrangiert oder sind längst weg.

Die Sprache, in der Failure Demand am wirkungsvollsten kommuniziert wird, ist nicht die Sprache der Customer Experience. Es ist die Sprache der Kosten.

Eine einfache Rechnung: 100.000 Kontakte pro Monat. Failure-Demand-Anteil: 50%. Durchschnittliche Vollkosten pro Kontakt (inklusive anteiliger Overhead): 12 Euro. Failure-Demand-Kosten: 600.000 Euro pro Monat. 7,2 Millionen Euro pro Jahr. Und das nur die direkten Handling-Kosten, ohne Downstream.

Wenn der Rückspielprozess den Failure-Demand-Anteil in 12 Monaten von 50% auf 35% senkt, sind das 1,8 Millionen Euro weniger Handling-Kosten pro Jahr. Plus die Downstream-Ersparnis. Plus die reduzierte Agent-Fluktuation, weil die Arbeit sinnvoller wird.

Das ist kein CX-Argument. Das ist ein Business Case.

Weil es unbequem ist. Weil der Rückspielprozess Wahrheiten produziert, die nicht jeder hören will. Weil die Billing-Abteilung nicht hören will, dass ihre Rechnung 15.000 Kontakte pro Monat erzeugt. Weil das Produktteam nicht hören will, dass die letzte Feature-Änderung 8.000 neue Anrufe ausgelöst hat. Weil das KI-Team nicht hören will, dass ihr Bot mehr Arbeit erzeugt als er löst.

Und weil das Contact Center oft nicht die organisatorische Stellung hat, andere Abteilungen in die Pflicht zu nehmen. Es ist eine Support-Funktion, ein Cost Center, das im Organigramm zwei Ebenen unter der Geschäftsführung hängt.

Genau deshalb braucht der Rückspielprozess Sponsorschutz. Nicht als Formalität, sondern als Überlebensbedingung.

Das Contact Center ist nicht das Problem. Es ist das Diagnoseinstrument. Es ist der Ort, an dem jeden Tag sichtbar wird, was in der Organisation nicht funktioniert. Die Frage ist, ob jemand zuhört.

Jede Organisation, die ihren Failure-Demand-Anteil ernsthaft senken will, muss bereit sein, das Contact Center nicht als Kostenstelle zu behandeln, sondern als Frühwarnsystem. Ein System, das Signale empfängt, die sonst nirgendwo sichtbar werden. Und das die Autorität hat, diese Signale verbindlich zurückzuspielen.

Das ist nicht nur eine Prozessfrage. Es ist eine Frage der Haltung.

_{Sie erhalten diesen Newsletter, weil Sie sich über newsletter.agrosz.de angemeldet haben.}

_{Verantwortlich für Angebot und Inhalt: Aleksander Grosz, Edmonton-Platz 16, 14513 Teltow, Deutschland | E-Mail: [email protected]}

_{Impressum: https://agrosz.de/impressum | Datenschutz: https://agrosz.de/datenschutz | Nutzungsbedingungen: https://agrosz.de/nutzungsbedingungen}