Qualitätssicherung im Callcenter: wie QA-Scorecards funktionieren

Was Qualitätssicherung im Callcenter eigentlich bedeutet

Jedes Supportteam stellt sich irgendwann eine Version der Frage "machen wir wirklich gute Arbeit, oder fühlt es sich nur so an?". Qualitätssicherung ist die Antwort auf diese Frage, in einen Prozess gegossen. Es ist die systematische Überprüfung von Support-Interaktionen - Anrufe, Chats, E-Mails, Tickets - anhand eines definierten Standards, damit "guter Service" aufhört, ein Gefühl zu sein, und stattdessen zu einer Zahl wird, auf die ein Manager verweisen kann.

Der Mechanismus, der fast jedem QA-Programm zugrunde liegt, ist die Scorecard: ein strukturiertes Bewertungsformular mit gewichteten Bewertungskategorien, das ein Prüfer - menschlich oder zunehmend KI - nach dem Lesen oder Anhören eines Gesprächs ausfüllt. Wie Zendesk es formuliert, existieren Scorecards, um "die Leistung von Agenten zu bewerten, Verbesserungspotenziale zu identifizieren und sicherzustellen, dass dein Team die Unternehmensziele erreicht". QA sitzt neben Personaleinsatzplanung und -prognose unter dem Oberbegriff Workforce Engagement Management (WEM) - die meisten Anbieter, Zendesk eingeschlossen, verkaufen es als eines von zwei oder drei Modulen dieser Suite.

Es ist aus Gründen wichtig, die sich verstärken, je größer ein Team wird. Ein Team aus drei Agenten kann von einem Manager geprüft werden, der einfach... alles liest. Ein Team aus dreißig kann das nicht. Scorecards und Sampling sind das, was es einer QA-Funktion erlaubt, über hunderte Agenten hinweg vergleichbare Bewertungen zu erzeugen, ohne dass ein Manager jedes einzelne Ticket persönlich lesen muss. Sie sind auch das Rohmaterial für Coaching - man kann darauf hinweisen, dass ein bestimmter Agent konsequent den Abschlusssatz auslässt, statt einer vagen "sei gründlicher"-Notiz in einem 1:1. Und in regulierten Branchen (Finanzdienstleistungen, Gesundheitswesen, Inkasso) haben QA-Scorecards oft rechtliches Gewicht: eine ausgelassene Offenlegung ist keine Stilfrage, sondern ein Compliance-Verstoß.

Auch der Business Case ist nicht abstrakt. Auf Zendesks eigener QA-Produktseite berichtet das Radiosendernetzwerk Audacy von 19% mehr Agentenproduktivität und 15% mehr Lösungen beim ersten Kontakt nach Einführung von strukturiertem QA; bei Kahoot! stieg der CSAT um 5 Prozentpunkte, begleitet von einem Sprung um 150% bei der Zahl tatsächlich geprüfter Tickets; Liberty berichtete von +2,3% CSAT und +4% beim eigenen Internal Quality Score. Keine dieser Zahlen ist QA um seiner selbst willen - sie zeigen, was passiert, wenn ein Team endlich seine eigenen blinden Flecken sehen kann.

Wie eine QA-Scorecard tatsächlich funktioniert

Entfernt man die Anbieter-Dashboards, ist eine Scorecard schlicht ein gewichteter Durchschnitt. Jede Kategorie - Genauigkeit, Tonfall, Empathie, Grammatik, Lösung, Compliance - erhält eine Bewertungsskala und eine Gewichtung von 0 bis 100. Zendesks Dokumentation ist unmissverständlich, was die Mathematik angeht: "Um die Bewertungspunktzahl einer Interaktion zu berechnen, multiplizierst du die Punktzahl jeder Kategorie mit ihrer Gewichtung und teilst die Summe dann durch die Summe der Gewichtungen." Ein Team, dem Ursachenverständnis wichtiger ist als Dokumentationsstil, gewichtet Ursachenanalyse einfach höher - die Formel erledigt den Rest.

Die gewählte Skala tauscht Geschwindigkeit gegen Nuancen. Zendesk QA bietet vier davon:

Zwei Mechanismen leisten den Großteil der Arbeit in einem ausgereiften QA-Programm. Der erste ist die kritische Kategorie - markiere "Stornogebühr offengelegt" als kritisch, und eine schlechte Bewertung dort setzt die gesamte Prüfung auf 0%, egal wie warm und fehlerfrei der Rest der Antwort war. Das ist der Hebel, den regulierte Teams ziehen, um sicherzustellen, dass ein Compliance-Fehler nicht durch einen guten Tonfall wegdurchschnittet werden kann. Der zweite ist das Root-Cause-Tagging: statt einfach "Empathie: schlecht" zu bewerten, wählt der Prüfer einen vordefinierten Grund aus einer Liste - genau das macht QA-Daten für Coaching nützlich, statt nur eine Zahl zu sein, über die sich der Agent ärgert.

Das hauseigene AutoQA-System von Zendesk QA kommt mit acht Standardkategorien, die automatisch bewertet werden, sobald ein Ticket geschlossen wird:

(Zendesk Help Center)

Hier die Mathematik im Kleinen: Angenommen, Genauigkeit ist mit 40 gewichtet, Tonfall mit 20 und Compliance mit 40. Ein Agent erzielt 90% bei Genauigkeit, 100% bei Tonfall und 80% bei Compliance. Gewichtet ergibt das (90×40 + 100×20 + 80×40) ÷ 100 = 88%. Ändere die Gewichtungen, und dieselbe zugrunde liegende Leistung ergibt eine andere Kopfzahl - genau deshalb ist Kalibrierung (unten) so wichtig.

Sampling: die Mathematik, die still und leise aufgehört hat zu funktionieren

Für den größten Teil der QA-Geschichte konnte ein menschlicher Prüfer nicht jede Interaktion anhören oder lesen, also bauten Teams die gesamte Disziplin um das Zufalls-Sampling herum auf - eine Handvoll Tickets pro Agent und Woche herausgreifen, diese bewerten, hochrechnen.

Das Problem ist, dass die Mathematik auf Teamebene gut aussieht und auf Agentenebene zusammenbricht. Leo Gasperin hat das in einem LinkedIn-Beitrag über sein früheres Team unverblümt dargelegt: Sie verbrachten 200 Stunden im Monat damit, Tickets nach strengen Kriterien zu prüfen, und deckten trotzdem nur etwa 5% des Gesamtvolumens ab. Wöchentlich 5-10 Tickets von den etwa 500 monatlichen Tickets eines Agenten zu prüfen, ergibt keine statistisch belastbare Aussage über diesen Agenten, selbst wenn die gesamte Sampling-Quote auf einem QA-Dashboard akzeptabel aussieht. Seine Lösung, wörtlich: "100% mit KI-Agenten als konfigurierte Bewerter auditieren, und dann nur die Probleme überprüfen." Eine Kommentatorin desselben Beitrags, Shubhashree S., brachte den Fehlerfall in einem Satz auf den Punkt: "Sampling schafft Vertrauen, aber keine Klarheit."

Das ist keine Randbeschwerde. Auf G2 beschrieb eine MaestroQA-Rezensentin, die als Executive Director arbeitet, den vorherigen Zustand direkt: "wir haben QA anhand einer Zufallsstichprobe von Tickets gemacht", bevor sie zu einem Tool wechselte, das ihrem Team stattdessen "gezielte QA" ermöglichte. Aus einem anderen Blickwinkel ist es dieselbe Geschichte bei evaluagent, wo ein Senior Advisor im Luftfahrt-Support genau das Problem benennt, das KI-AutoQA lösen soll: es "löst das Problem der eingeschränkten Sichtbarkeit durch QA-Sampling und reduziert Zeit und Aufwand für manuelle Prüfungen."

Kalibrierung: Prüfer tatsächlich zur Übereinstimmung bringen

Scorecards funktionieren nur, wenn zwei Prüfer, die dasselbe Ticket bewerten, zum gleichen Ergebnis kommen. Diese Abstimmungsübung heißt Kalibrierung, und Zendesks eigene Definition trifft genau das, wonach es klingt: "die Praxis, alle Prüfer dieselbe Charge von Gesprächen bewerten zu lassen und ihre Punktzahlen und Kommentare zu vergleichen ... sorgt dafür, dass deine Prüfer in ihren Bewertungen aufeinander abgestimmt sind und Agenten konsistentes Feedback erhalten, unabhängig davon, wer die Prüfung durchführt."

Mechanisch läuft es meist nach dem Muster "erst prüfen, dann diskutieren": Prüfer bewerten unabhängig voneinander, ein Manager markiert eine Prüfung als Baseline, und die Gruppe trifft sich, um Lücken zu klären - oft mit einem QA-Lead, der bei Streitfragen die endgültige Entscheidung trifft. Was tatsächlich abgestimmt werden muss, sind selten die großen Dinge; es sind die Grenzfälle. Wie bewertet man eine Kategorie, die in diesem konkreten Gespräch nie vorkam? Wie lang sollte schriftliches Feedback sein? Kalibrierungswerte werden bewusst aus dem laufenden Internal Quality Score eines Agenten herausgehalten und leben in ihrem eigenen Dashboard, genau damit die Übung darauf ausgerichtet bleibt, Prüfer zu trainieren, statt zu einem zweiten, versteckten Bewertungskanal zu werden. Die meisten Teams machen das monatlich.

Der Wandel hin zu KI, die 100% der Gespräche prüft

Jeder wichtige QA-Anbieter, den ich mir angesehen habe, konvergiert auf dasselbe Verkaufsversprechen, und es lohnt sich, es klar zu benennen: KI prüft jede Interaktion und ersetzt manuelles Sampling vollständig, während die Scorecard-und-Kalibrierung-Struktur als Rückgrat darunter erhalten bleibt.

Zendesk QA (früher Klaus) führt mit AutoQA an - es bewertet 100% der Gespräche über Sprache, Chat, E-Mail und KI-Agenten-Transkripte hinweg, wobei Admins benutzerdefinierte, promptbasierte Kategorien in einfacher Sprache statt in Code schreiben können. Die Spotlight-Funktion markiert automatisch Abwanderungsrisiko und Wissenslücken, ohne dass ein Mensch jeden markierten Thread lesen muss, und Real-time QA bringt Probleme ans Licht, während ein Gespräch noch läuft, statt erst danach.

Am aufschlussreichsten finde ich AI Agent QA - dieselben Bewertungsstandards, die bei menschlichen Agenten verwendet werden, angewendet auf Bots. Zendesk vergleicht ausdrücklich die Werte von menschlichen und KI-Agenten nebeneinander, um zu sehen, wo der Bot nachbessern muss - was still und leise etwas bestätigt, das man sich bewusst machen sollte: Sobald ein KI-Agent echte Tickets bearbeitet, braucht er auch einen QA-Prozess, keinen Freifahrtschein nur weil er Software ist.

MaestroQA hat sich weiter von der Marke "QA-Tool" entfernt und nennt sich mittlerweile eine Conversation-Data-Plattform - die eigene Homepage rahmt diesen Wandel direkt so: "Wir haben als Contact-Center-QA-Unternehmen angefangen ... Seit ChatGPT 2023 aufkam, ist die Analyse von Gesprächsdaten zur C-Level-Priorität geworden." Die DraftKings-Case-Study ist als vollständiger Ersatz manueller QA-Prüfungen gerahmt, und Brex berichtet von 20-mal mehr erkannten gefährdeten Kunden, nachdem der eigene QA-Prozess rund um die Plattform neu aufgebaut wurde - ein Sprung, der laut Case Study so groß war, dass die COO von Brex dem Team angeblich nach einer einzigen Vorschau sagte: "kein manuelles QA mehr."

Playvox, inzwischen Teil von NICE, spielt eine ähnliche Rolle innerhalb einer breiteren Workforce-Engagement-Suite - flexible Scorecards, Kalibrierung und native Zendesk-/Salesforce-Integrationen -, wobei die eigenen Marketing-Seiten Scraping aktiv blockieren, weshalb konkrete Angaben zu Playvox eher als Orientierung denn als verifiziert zu behandeln sind.

Praktiker vor Ort bestätigen eher den Coaching- als den Benotungsgedanken. Eine MaestroQA-Rezensentin, die als unabhängige Auftragnehmerin arbeitet, brachte es gut auf den Punkt: "es hört auf, Qualitätsprüfungen wie einen simplen 'Bestanden/Nicht bestanden'-Test zu behandeln, und macht sie zu einer echten Möglichkeit, Menschen zu coachen." Und eine echte QA-Analystin - keine Managerin, sondern die Person, die die Bewertung tatsächlich Tag für Tag vornimmt - beschrieb zweieinhalb Jahre mit MaestroQA "zuerst als Agentin, die ihre eigenen Qualitätswerte überwachte, und jetzt als Quality Analyst, die die gesamte Bewertung durchführt", und bezeichnete den Prozess als "extrem unkompliziert."

Reibungslos ist es nicht. Ein Founder aus der Telekommunikationsbranche wies auf G2 auf einen echten Kosten-Stolperstein hin: "KI-Funktionen erfordern einen zusätzlichen Kauf, der die Kosten erheblich in die Höhe treibt" - budgetiere KI-Bewertung als zusätzlichen Posten über dem Basis-QA-Produkt, nicht als kostenloses Upgrade. Und eine Operations-Führungskraft bei evaluagent brachte eine kleinere, aber echte UX-Beschwerde aus Sicht des Agenten vor: Benachrichtigungs-E-Mails zu Bewertungen, die nur sagen, dass eine Prüfung stattgefunden hat, ohne das eigentliche Ergebnis - was er als "beunruhigend" beschrieb und als etwas, das ihn "ängstlich macht und dazu bringt, sofort Evaluagent zu öffnen." Ein technisch rigoroses QA-Programm kann trotzdem schlecht ankommen, wenn sich die agentenseitige Seite davon anfühlt wie ins Rektorenzimmer zitiert zu werden.

Wenn der bewertete Agent KI ist, kein Mensch

Hier kommen meine eigenen, echten Zahlen ins Spiel, denn genau das ist die Frage, die ein QA-Programm beantworten muss, sobald ein KI-Agent in die Warteschlange aufgenommen wird: nicht "klingt die KI richtig", sondern "hält sie derselben Scorecard stand, die man auch bei einem Menschen anlegen würde".

In einem kreuzvalidierten Test, den wir gegen echten Zendesk-Traffic für ein E-Commerce-Team durchgeführt haben, erreichte die KI von eesel 93% Triage-Genauigkeit und 100% Spam-Erkennung ohne falsch-positive Treffer, bei einem Posteingang, in dem Spam 22% des Gesamtvolumens ausmachte. Die direktionale Genauigkeit der Entwürfe lag bei 88%, was bedeutet, dass die inhaltliche Substanz der Antwort fast neun von zehn Mal auf dem richtigen Weg war. Aber nur 12% der Entwürfe wurden von Agenten so versendet, wie sie waren, und die Rate an sachlichen Fehlern lag bei 7%. Die Leistung nach Kategorie schwankte stark: Entwürfe zu Rückgaben und Rückerstattungen wurden in 93,8% der Fälle als nützlich bewertet, Garantieansprüche in 96,4%, und sowohl Produktanfragen als auch Nachfragen zum Rückerstattungsstatus erreichten jeweils 100%.

Die Lücke zwischen 88% direktionaler Genauigkeit und 12% unveränderter Übernahme ist der Teil, über den es sich nachzudenken lohnt. Es lag nicht daran, dass die Agenten dem Urteil der KI nicht vertrauten - das dominante Muster war "kurz drüberschauen und umschreiben": Agenten nahmen einen Entwurf aus 8-15 Sätzen und kürzten ihn vor dem Versenden auf 1-3 Sätze. Schlüsselt man dieses Umschreib-Muster auf, waren rund 65% davon reine Länge- und Tonfall-Bearbeitung, behebbar, indem man den Agenten anhand der tatsächlich vom Team in der Vergangenheit versendeten Antworten trainiert. Weitere 20% benötigten Daten, mit denen die KI schlicht noch nicht verbunden war, etwa Live-ERP- oder Logistikstatus. Nur etwa 5% der Umschreibungen erfolgten, weil der Entwurf schlichtweg sachlich falsch war. Ein Training mit einer Stichprobe von 200 aktuellen Agentenantworten brachte die unveränderte Übernahmerate von 12% in Folgetests in den Bereich von 30-40%.

Ich erwähne das, weil es genau das Muster ist, das eine echte QA-Scorecard aufdecken soll - und genau das Muster, das unsichtbar bleibt, wenn man nur 5% der Tickets stichprobenartig prüft. Wenn dein QA-Programm dir nicht sagen kann, ob die Entwürfe deines KI-Agenten falsch sind oder sich nur stilistisch von der Schreibweise deines Teams unterscheiden, misst du in Wirklichkeit gar keine Qualität - du misst ein Bauchgefühl mit ein paar Extraschritten.

Dieser Unterschied zeigt sich sogar schon, bevor ein Kunde überhaupt eine Live-Antwort sieht. Ein Interessent, der eesel evaluierte - ein Support-Leiter bei einem belgischen Unternehmen - baute sich eine eigene 67-Test-Bewertung auf, bevor er dem Tool echte Tickets anvertraute, und bewertete die Wissensantworten insgesamt als "solide" (er entschied sich letztlich aus einem unabhängigen Grund dagegen: Geschwindigkeit des Chat-Widgets, nicht Antwortqualität). Das ist ein QA-Prozess im Kleinen, durchgeführt von einem Käufer statt von einem Anbieter - und genau der Instinkt, den ich mir bei jedem Team wünsche, das einen KI-Agenten evaluiert: nimm nicht "es macht in der Demo einen guten Eindruck" als deine Scorecard.

Eine praktische QA-Scorecard, die du diese Woche aufbauen kannst

Man braucht keine WEM-Plattform, um anzufangen. Eine funktionierende erste Scorecard braucht vier Dinge:

1. Wähle 4-6 Kategorien, die tatsächlich das abbilden, was für dein Geschäft wichtig ist - Genauigkeit, Tonfall, Lösung und, im regulierten Umfeld, eine compliance-kritische Kategorie. Wenige gut gewählte Kategorien schlagen ein aufgeblähtes 15-Punkte-Formular, das niemand konsistent ausfüllt.
2. Wähle zu Beginn binäre oder 3-stufige Skalen. Nuancierte 5-stufige Skalen klingen rigoros, verlangsamen aber Prüfungen und führen zu mehr Uneinigkeit zwischen Prüfern - genau das, wofür Kalibrierung existiert. Fang einfach an, füge Nuancen hinzu, sobald das Programm läuft.
3. Gewichte, was tatsächlich Ergebnisse beeinflusst, nicht das, was am leichtesten zu bewerten ist. Wenn Ursachendiagnose für deine Verlängerungsquote wichtiger ist als eine perfekt interpunktierte Antwort, gewichte es entsprechend - die Formel kümmert sich nicht darum, was bequem zu bewerten ist.
4. Kalibriere, bevor du coachst. Führe eine Kalibrierungssitzung mit deinen Prüfern anhand derselben 10 Tickets durch, bevor die erste echte Bewertung jemandes rausgeht. Uneinigkeit ist hier normal und erwartet - das ist der ganze Sinn, es zuerst zu tun.

Sobald diese Scorecard für deine menschlichen Agenten existiert, wende sie auch auf deinen KI-Agenten an - einschließlich jedes Teils deines Stacks, der Eskalationen oder Callcenter-Automatisierung übernimmt. Dieselben gewichteten Kategorien, dieselbe kritische Compliance-Regel, dieselbe Kalibrierungsdisziplin. Ein KI-Agent, der nie an deiner echten Scorecard gemessen wurde, läuft nach Gefühl, genau wie es ein untrainierter Neuzugang tun würde.

eesel und Qualitätssicherung

Ich arbeite in der Support-Warteschlange von eesel, und die ehrliche Antwort auf "sollte ich den Antworten eines KI-Agenten vertrauen, ohne sie zu prüfen" lautet nein - man sollte niemandes Antworten ungeprüft vertrauen, weder Mensch noch KI. Deshalb baut eesel QA direkt in den Rollout ein, statt es als separates, nachträglich angeflanschtes Programm zu behandeln. Bevor ein Agent überhaupt ein Live-Ticket beantwortet, lässt der Simulationsmodus ihn gegen die eigenen historischen Tickets laufen, sodass man Abdeckung nach Thema sehen und Lücken erkennen kann, bevor ein Kunde sie je zu sehen bekommt - das Nächste, was einer vor dem Launch statt danach durchgeführten QA-Scorecard kommt. Sobald es live ist, fungiert vertrauensbasiertes Routing als laufendes QA-Gate für jede einzelne Antwort: Antworten mit niedrigem Konfidenzwert werden als Entwurf zurückgehalten, damit ein Mensch sie prüft, statt sie blind zu versenden - dieselbe Logik, die Zendesks AI Agent QA nachträglich anwendet, nur früher im Ablauf verschoben.

Wenn du bereits ein QA-Programm für dein menschliches Team betreibst und überlegst, ob ein KI-Agent derselben Messlatte standhalten könnte, ist genau das ein Gespräch, das sich lohnt: eesel lässt sich kostenlos testen, und die Preisgestaltung ist nutzungsbasiert pro Ticket statt einer festen Sitzplatzgebühr - Testen gegen deine eigene Scorecard erfordert also keinen vorgeschalteten Beschaffungsprozess.