Wenn ein Kriterium von einem ausgefallenen System, einem Kunden, der gegangen ist, oder einem Team abhängt, das nie geantwortet hat, verlieren Agents Punkte, die sie nicht beeinflussen konnten. Korrigieren Sie die Scorecard, indem Sie das Kriterium streichen, es als nicht anwendbar markieren oder den Befund an seinen Verantwortlichen weiterleiten.
Kurz gesagt
- Agents erkennen ein Kriterium, das sie nicht beeinflussen können, innerhalb von etwa einem Monat.
- „Nicht anwendbar“ muss es bei jedem Kriterium geben, und es muss den Nenner verkleinern.
- Fehler, die sich in einer Queue, einer Uhrzeit oder nach einem Release häufen, deuten auf ein Systemproblem.
- Ein kaputter Prozess sollte den Prozess ändern, nicht den Score des Agents.
Warum ein einziges unkontrollierbares Kriterium den ganzen Score entwertet
Vier Situationen tauchen immer wieder auf, wenn Support-Agents einen Score beschreiben, den sie für unfair halten, und keine davon ist wirklich ein Streit über das Urteil.
- Durch einen Systemfehler wurde ein Schritt, den der Agent erledigt hatte, nie protokolliert, sodass der Reviewer ihn nicht sehen konnte und als fehlend bewertete.
- Der Kunde hat die Verbindung vor dem Gesprächsabschluss beendet, und jedes Abschlusskriterium ergab eine automatische Null.
- Eine Eskalation ging an eine Teamleitung, die nie antwortete, und der Agent verlor die Punkte für Lösung und Nachverfolgung.
- Ein Anrufer war schwer zu verstehen, eine E-Mail-Adresse kam mit Tippfehler zurück, und ein Kriterium zur Datenrichtigkeit verbuchte das als Datenschutzverstoß.
Nehmen Sie die Rechnung beim zweiten Fall ernst, denn sie ist am klarsten. Enthält Ihr Abschlussteil vier Kriterien und setzt ein Verbindungsabbruch drei davon auf null, dann entscheidet das Verhalten des Kunden, nicht das des Agents, in welchem Leistungsband dieser Agent landet. Bei den Agents, die die wütendsten Anrufer abbekommen, wird am häufigsten aufgelegt, also schneiden die Menschen, die Ihre schwierigste Arbeit erledigen, am schlechtesten ab.
Daraus folgen zwei Dinge, in dieser Reihenfolge. Erstens trägt der Score keine Information mehr. Wenn ein Reviewer Ihnen nicht sagen kann, ob eine 72 schlechte Arbeit oder einen schlechten Nachmittag mit den Tools bedeutet, kann niemand weiter unten die Zahl für eine Entscheidung nutzen. Zweitens, und das ist teurer, verliert der Score seine Autorität bei den Menschen, denen er helfen soll. Sobald ein Agent glaubt, dass die Zahl teilweise willkürlich ist, kommt jedes Coaching, das daran hängt, bereits mit Abschlag an. Sie coachen nicht mehr, Sie verhandeln, und Sie haben die Voraussetzungen dafür verloren, ein QA-Programm zu führen, dem Agents vertrauen. Deming hat den allgemeinen Fall deutlicher formuliert als jeder QA-Leitfaden: Ein schlechtes System schlägt jedes Mal einen guten Menschen, und den Menschen strenger zu messen ändert nichts daran, wer von beiden verliert.
Das ist kein Versagen des QA-Teams. Reviewer arbeiten im selben Formular wie alle anderen, und die meisten Formulare lassen ihnen bei einem Kriterium, das unmöglich zu erfüllen war, zwei Möglichkeiten: es durchfallen lassen oder es stillschweigend bestehen lassen und hoffen, dass niemand nachprüft. Beides ist falsch, und eine dritte Möglichkeit gibt es nicht. Das ist ein Designproblem, das sich im Bewertungsraster lösen lässt statt im Streit darüber.
So finden Sie die kontrollabhängigen Kriterien auf Ihrer Scorecard
Nehmen Sie Ihre aktuelle QA-Scorecard und gehen Sie sie Zeile für Zeile durch. Stellen Sie zu jedem Kriterium drei Fragen in dieser Reihenfolge.
- Hätte der Agent dieses Kriterium mit den Tools, Berechtigungen und Informationen bestehen können, die er in diesem Moment hatte? Nicht mit den Tools, die er hätte haben sollen. Mit denen, die er tatsächlich vor sich hatte.
- Muss für ein Bestehen zuerst jemand anderes handeln? Ein anderes Team, ein Kunde, ein Batch-Job, eine Freigabe.
- Könnte ein starker Agent das Kriterium jedes einzelne Mal bestehen, wenn er es will? Lautet die ehrliche Antwort nein, misst das Kriterium neben dem Können auch die Umstände.
Ordnen Sie dabei jedes Kriterium einer von drei Gruppen zu. Voll kontrollierbar: Hier sollten die meisten Ihrer Kriterien zu Soft Skills und Prozessen liegen. Bedingt kontrollierbar: Der Agent hat es nur in der Hand, wenn eine Vorbedingung erfüllt ist. Nicht kontrollierbar: Ein Bestehen hängt von etwas ab, auf das der Agent überhaupt keinen Einfluss hat.
Die zweite Gruppe ist die eigentliche Arbeit. Schreiben Sie für jedes bedingt kontrollierbare Kriterium die Vorbedingung in einem schlichten Satz auf: Der Kunde blieb in der Leitung, das Erstattungstool lief, das Second-Level-Team antwortete innerhalb seines Service Levels, die Aufnahme hat das ganze Gespräch erfasst. Diese Sätze werden später Ihre Auslöser für „nicht anwendbar“, und erst das Aufschreiben macht aus einem vagen Gefühl von Ungerechtigkeit eine Regel, die ein Reviewer zweimal gleich anwenden kann.
Machen Sie es mit Agents im Raum
Gehen Sie die Scorecard mit zwei Reviewern und zwei erfahrenen Agents gemeinsam durch, nicht als reine QA-Übung. Die Agents finden die kontrollabhängigen Kriterien in einem Bruchteil der Zeit, weil sie seit Monaten Punkte daran verlieren und das genaue Ticket nennen können. Es verändert auch, was die Übung signalisiert: Sie bitten die Teams, das Formular mit zu reparieren, statt eine Korrektur zu verkünden. Planen Sie zwei Stunden für eine Scorecard mit fünfzehn Kriterien ein und rechnen Sie mit zwei bis fünf problematischen Zeilen.
Die drei Kategorien unkontrollierbarer Fehler
Fast alles, was Sie finden, fällt in eine von drei Kategorien, und die Kategorie sagt Ihnen, was zu tun ist. Entscheidend ist, wer den Fehler hätte verhindern können, denn genau diese Stelle sollte auch den Befund bekommen.
| Kategorie | Wie es aussieht | Meist betroffene Kriterien | Standardbehandlung |
|---|---|---|---|
| System und Tools | Ein Ausfall oder ein langsames Tool, ein erledigter Schritt, der nie im Datensatz landete, eine Aufnahme oder ein Transkript mit Lücken, ein Feld, das nicht gespeichert wurde | Prozesstreue, Dokumentation, Verifizierungsschritte, Halte- und Bearbeitungszeit | Nicht anwendbar für diese Konversation, plus ein Fehlerticket gegen das System |
| Verhalten des Kunden | Der Kunde beendet die Verbindung vor dem Abschluss, verweigert die Verifizierung, bleibt nicht für die Zusammenfassung, redet dem Agent ständig ins Wort, ist schon wütend, bevor es losgeht | Gesprächsabschluss, Identitätsprüfung, an Zufriedenheit gekoppelte Kriterien, Kriterien zu Ton und Unterbrechungen | Kriterium streichen oder davon abhängig machen, dass der Kunde geblieben ist und mitgewirkt hat |
| Vorgelagerte und benachbarte Teams | Eine Eskalation, die niemand beantwortet, ein Rückstau im Second Level, eine Richtlinie, die die Lösung verbietet, die der Kunde braucht, ein Wissensartikel, der falsch ist oder fehlt, ein Makro mit veralteter Formulierung | Lösung, Erstlösungsquote, Richtigkeit, zugesagte Nachverfolgung | Den Agent nur danach bewerten, was er mit den vorhandenen Mitteln getan hat, und den Befund an das verantwortliche Team weiterleiten |
Streichen, als nicht anwendbar markieren oder weiterleiten
Drei Korrekturen, und die falsche zu wählen ist der Grund, warum solche Korrekturen scheitern. Der Maßstab ist nicht, wie schwer der Fehler war, sondern wie oft das Kriterium unmöglich ist und wem die Ursache gehört.
Streichen Sie das Kriterium, wenn es den Kontrolltest meistens nicht besteht. Hängt ein Kriterium von einem unzuverlässigen Tool ab oder davon, dass sich der Kunde auf eine bestimmte Weise verhält, ist es kein Standard, sondern ein Münzwurf mit Punktwert. Eine nützliche Faustregel: Wenn Sie jemanden nie dazu coachen würden, bewerten Sie ihn auch nicht danach.
Markieren Sie es als nicht anwendbar, wenn das Kriterium normalerweise kontrollierbar ist, in dieser einen Konversation aber wirklich unmöglich war. Das ist der häufige Fall, und er braucht zwei Dinge: einen benannten Auslöser aus den Vorbedingungen, die Sie vorher aufgeschrieben haben, und einen Beleg im Datensatz, dass der Auslöser eingetreten ist. Ein Zeitstempel des Verbindungsabbruchs vor dem Gesprächsabschluss ist ein Beleg. Der Eindruck eines Reviewers ist keiner.
Leiten Sie den Befund weiter, wenn der Fehler echt ist, für den Kunden zählt und jemandem gehört. Der Kunde hat seine Erstattung nicht bekommen, ein echter Qualitätsmangel, den man kennen sollte, aber die Ursache war eine Richtlinie, über die sich der Agent nicht hinwegsetzen darf. Der Befund verlässt die QA als Prozessfehler mit einem Verantwortlichen und einem Datum. Der Score des Agents bewegt sich nicht.
Es gibt eine vierte Option, zu der Teams greifen und die Sie ablehnen sollten: das Kriterium durchfallen lassen und einen Kommentar ergänzen, dass es nicht die Schuld des Agents war. Der Kommentar ändert die Zahl nicht, und die Zahl ist es, die im Monatsreview, im Ranking und im Leistungsgespräch ankommt. Mitgefühl in einem Freitextfeld ist keine Kontrolle, und es lässt dem Agent nichts anderes übrig, als den Score anzufechten.
Geben Sie Reviewern die Befugnis und prüfen Sie sie danach
Reviewer sollten „nicht anwendbar“ ohne Rückfrage vergeben können. Teams, die daraus eine Eskalation machen, nehmen die Option faktisch weg, denn ein Reviewer mit vierzig offenen Prüfungen eröffnet kein Ticket, um eine Zeile auszulassen. Steuern Sie es stattdessen im Nachgang: Werten Sie die Nutzung von „nicht anwendbar“ nach Reviewer und nach Kriterium aus und setzen Sie die Ausreißer auf die Agenda Ihrer nächsten Kalibrierungssitzung. Das ist ein weit besseres Gespräch als das, das Sie bekommen, wenn Sie falsche Fehlbewertungen erzwingen.
Warum „nicht anwendbar“ bei jedem Kriterium eine vollwertige Option sein muss
„Nicht anwendbar“ funktioniert nur, wenn die Rechnung stimmt. Der Score muss erreichte Punkte geteilt durch anwendbare Punkte sein, nicht geteilt durch das ganze Formular. Waren elf von fünfzehn Kriterien anwendbar und hat der Agent acht bestanden, lautet der Score acht von elf. Bleiben in Ihrem Formular alle fünfzehn im Nenner, kostet „nicht anwendbar“ genau so viel wie ein Durchfallen, die Reviewer merken das innerhalb einer Woche, und die Option wird nicht mehr genutzt. Viele Teams bewerten bereits nur über die anwendbaren Fragen. Andere haben ein Kontrollkästchen „nicht anwendbar“, das nichts bewirkt, und das ist schlimmer als keines, weil es wie eine Lösung aussieht.
Überlegen Sie, was in einem Formular ohne funktionierendes „nicht anwendbar“ passiert. Die strengen Reviewer lassen das unmögliche Kriterium durchfallen, die großzügigen lassen es bestehen, und beide raten an einer Regel herum, die nie aufgeschrieben wurde. Sie haben Abweichungen zwischen Reviewern erzeugt, die keine Kalibrierung auflösen wird, weil sie strukturell sind und nicht in der Wahrnehmung liegen: Zwei Reviewer können sich vollkommen einig sein, was passiert ist, und trotzdem unterschiedliche Scores vergeben. Agents erleben ihren Score dann als Funktion davon, wer sie geprüft hat, und das ist der schnellste Weg, wie ein QA-Programm seine Glaubwürdigkeit verliert.
Der Schaden an den Daten hält länger an. Ein Kriterium, das als bestanden gilt, obwohl es nie geprüft wurde, bläht Ihre Bestehensquote auf. Ein Kriterium, das durchfällt, obwohl es unmöglich war, erzeugt einen Mangel, den es nie gab. So oder so werden die Statistiken dieses Kriteriums unbrauchbar, und genau diese Statistiken brauchen Sie, um die Scorecard sinnvoll zu gewichten und die Systemprobleme aus dem nächsten Abschnitt zu erkennen.
Vier Anforderungen, und alle sind günstig:
- Bei jedem Kriterium verfügbar, nicht nur bei ausgewählten. Das eine, bei dem Sie es nicht aktiviert haben, ist das, das bricht.
- Ein Grundcode aus einer kurzen Liste, fünf oder sechs Optionen, damit die Nutzung zählbar ist. Freitext lässt sich nicht zählen.
- Für den Agent in der Prüfung sichtbar, damit er sieht, dass der Reviewer es bemerkt hat. Die Hälfte des Unmuts in diesem ganzen Thema kommt daher, dass Agents annehmen, niemand habe es bemerkt.
- Monatlich ausgewertet nach Kriterium und nach Grund.
Ein Schwellenwert, der sich lohnt: Ist ein Kriterium in mehr als ungefähr einem Drittel der Konversationen nicht anwendbar, gehört es nicht auf diese Scorecard. Es gehört auf eine kanal- oder queuespezifische, denn Sie verlangen von einem einzigen Formular, zwei verschiedene Arten von Arbeit zu bewerten.
So erkennen Sie das Problem in Ihren Daten, bevor ein Agent es Ihnen sagt
Beschwerden sind ein nachlaufender Indikator, und sie kommen von Ihren selbstbewusstesten Agents statt von den am stärksten betroffenen. Die Daten sind früher da, und die Methode läuft in einer Tabellenkalkulation.
Nehmen Sie für jedes Kriterium die Fehlerquote des letzten Quartals und schlüsseln Sie sie nach Tageszeit, Queue oder Skill, Kanal, Betriebszugehörigkeit der Agents und den Daten von Releases und Richtlinienänderungen auf. Das Können der Agents verteilt sich ziemlich gleichmäßig über diese Gruppen. Systemprobleme nicht, und diese Asymmetrie ist die ganze Diagnose. Ein Kriterium, das insgesamt in 6 % der Fälle durchfällt, in einer Queue zwischen zwei und fünf Uhr nachmittags aber in 35 %, sagt Ihnen nichts über Coaching.
Vier Muster und was sie meist bedeuten:
- Konzentriert in einem Zeitfenster. Unterbesetzung, Druck in der Queue oder ein Batch-Job, der jeden Nachmittag ein System sperrt. Prüfen Sie, was sonst zu dieser Uhrzeit passiert, bevor Sie eine Coaching-Notiz schreiben.
- Konzentriert in einer Queue, einem Skill oder einem Kanal. Ein Tool, das nur diese Gruppe nutzt, eine Routing-Regel oder eine Scorecard, die nicht zur Arbeit dieser Gruppe passt.
- Ein Sprung ab einem Datum. Ein Release, eine Richtlinienänderung oder eine Änderung an der Scorecard selbst. Ein Kriterium, das im März in Ordnung war und ab April ständig durchfällt, ist nicht schwerer geworden, weil Ihre Agents schlechter wurden.
- Gleichmäßig über alle verteilt, auch über Ihre stärksten Agents. Das Kriterium ist mehrdeutig oder unmöglich. Wenn Ihr oberstes Zehntel es etwa so oft verfehlt wie Ihr unterstes, misst es kein Können.
In dieser Methode steckt ein Stichprobenproblem, und es lohnt sich, es zu benennen. Bei der Stichprobe von 3 %, mit der die meisten Programme arbeiten, ist sie gar nicht durchführbar. Schlüsseln Sie ein Kriterium nach Queue und Uhrzeit auf, und die meisten Zellen sind leer, sodass das Muster, das den Agent entlastet hätte, unsichtbar bleibt und stattdessen die Anekdote den Streit gewinnt. Das ist das praktische Argument dafür, alles zu bewerten: 100 % Abdeckung zeigt Trends, die eine 3-%-Stichprobe nie zeigen könnte. Es geht nicht darum, dass mehr gesehen wird, sondern darum, dass die Auswahlverzerrung verschwindet, sodass ein konzentrierter Fehler als konzentriert erkannt werden kann.
Auto QA von Kaizo bewertet jede Konversation nach Ihrer eigenen Scorecard und hält die Belege Kriterium für Kriterium fest, sodass Sie die Fehler eines Kriteriums nach Queue und Uhrzeit filtern und sehen können, ob sie sich häufen, bevor irgendjemand dazu gecoacht wird. Diese Nachvollziehbarkeit zählt mehr als die Abdeckung: Die nützliche Frage ist nicht, wie viele Konversationen bewertet wurden, sondern ob Sie zeigen können, warum ein bestimmtes Kriterium in einer bestimmten Konversation durchgefallen ist. Mehr zur Abdeckung unter was 100 % QA-Abdeckung wirklich bedeutet.
Sehen Sie es an Ihren eigenen Konversationen. Kaizo bewertet 100 % Ihrer Supportkonversationen und macht aus den Ergebnissen Coaching. Demo buchen.
Leiten Sie den Befund an den Verantwortlichen, nicht in den Score des Agents
Alles oben läuft auf ein Prinzip hinaus. Ein Befund, der auf einen kaputten Prozess zurückgeht, sollte den Prozess ändern, nicht den Score der Person. QA liest mehr von dem, was Kunden tatsächlich erleben, als jede andere Funktion, und ist damit das beste Fehlererkennungssystem, das die meisten Supportorganisationen besitzen. Dieses Signal für einzelne Punktabzüge zu verbrauchen, verschwendet es.
Die Mechanik ist gewöhnlich, und genau darum geht es:
- Markieren Sie den Verantwortlichen schon bei der Prüfung. Produkt, Workforce Management, Second Level, Wissensmanagement, Richtlinien. Während der Prüfung dauert das Sekunden. In einer monatlichen Retro nachträglich rekonstruiert, dauert es einen Nachmittag und fällt aus.
- Geben Sie dem Befund die Felder eines Fehlertickets. Was ist fehlgeschlagen, wie oft, in welchen Queues, was kostet es an erneut geöffneten Tickets oder Bearbeitungszeit. Ein Prozessbefund mit einer Zahl wird behoben. Eine Beschwerde nicht. Das ist klassische Ursachenanalyse, angewendet auf die Scorecard selbst statt auf das Ticket.
- Setzen Sie das Kriterium aus, solange der Fehler offen ist, und sagen Sie das den Teams laut. Das ist der Schritt, der Glaubwürdigkeit zurückkauft, weil er beweist, dass die Scorecard auf Belege reagiert.
- Berichten Sie die Korrekturen neben den Scores. Ausgesetzte Kriterien, gemeldete Fehler, behobene Fehler. Das verändert, wofür QA gehalten wird, und es gibt Ihrem Team eine zweite Reihe von Zahlen, die nicht der Durchschnittsscore ist.
Was nach dieser Arbeit übrig bleibt, ist der Teil, den der Agent tatsächlich steuert, und nur dieser Teil ist ein Einzelgespräch wert. Coaching beginnt nicht mehr mit einem Streit darüber, ob der Score fair war, und aus QA-Daten Coaching zu machen wird einfacher, weil alle Befunde Dinge sind, die ein Mensch ändern kann. Das KI-Coaching von Kaizo baut seine Coaching-Karten aus bewerteten Kriterien, sodass die Kriterien, die Sie streichen oder an Bedingungen knüpfen, nicht nur keine Punktabzüge mehr erzeugen, sondern auch kein Coaching-Rauschen.
Zwei Ordnungsregeln zum Schluss. Versionieren Sie die Scorecard jedes Mal, wenn Sie ein Kriterium entfernen oder an eine Bedingung knüpfen, und berechnen Sie alte Scores nie nach neuen Regeln neu, denn ein Score aus dem März ist unter dem Formular vom März entstanden. Und kündigen Sie jede Änderung an, bevor sie gilt, mit Begründung. Eine Scorecard, die sich sichtbar selbst korrigiert, wird ganz anders behandelt als eine, die jedes Quartal stillschweigend in einer neuen Version auftaucht.
Häufig gestellte Fragen
Sollten Agents nach Dingen bewertet werden, die sie nicht beeinflussen können?
Nein. Ein Kriterium, das ein Agent nicht beeinflussen kann, misst Umstände statt Leistung und macht den Gesamtscore für Coaching oder Ranking unbrauchbar. Der Fehler kann trotzdem festgehalten werden, aber gegen das System, die Situation beim Kunden oder das Team, das ihn verursacht hat. Ordnen Sie jedes Kriterium als voll kontrollierbar, bedingt kontrollierbar oder nicht kontrollierbar ein und streichen Sie es dann, markieren Sie es als nicht anwendbar oder leiten Sie es weiter.
Was tun Sie, wenn ein Agent in der QA aus einem Grund durchfällt, für den er nichts kann?
Korrigieren Sie es nicht mit einer Notiz im Kommentarfeld, denn der Kommentar ändert nicht die Zahl, die in seinem Review ankommt. War das Kriterium in dieser konkreten Konversation unmöglich, markieren Sie es als nicht anwendbar, damit es aus dem Nenner fällt. Ist das Kriterium regelmäßig unmöglich, entfernen Sie es von der Scorecard. War der Fehler echt, aber von einem anderen Team verursacht, behalten Sie den Befund, geben Sie ihm einen Verantwortlichen und lassen Sie den Score des Agents unberührt.
Wie gehen Sie mit einem Anruf um, bei dem der Kunde vor dem Abschluss aufgelegt hat?
Setzen Sie jedes Abschlusskriterium auf „nicht anwendbar“, belegt durch den Zeitstempel des Verbindungsabbruchs, statt automatische Nullen zuzulassen. Bewerten Sie die Teile der Konversation, die stattgefunden haben. Ein Abbruch, der drei oder vier Abschlusskriterien auf null setzt, kann einen Agent allein durch das Verhalten des Kunden ein ganzes Leistungsband verschieben, und er trifft die Agents mit den schwierigsten Anrufern am härtesten.
Sollte eine QA-Scorecard eine Option „nicht anwendbar“ haben?
Ja, bei jedem Kriterium, und sie muss das Kriterium aus dem Nenner nehmen, sodass der Score erreichte Punkte von anwendbaren Punkten ist. Eine Option „nicht anwendbar“, die die Gesamtsumme unverändert lässt, ist rechnerisch identisch mit einem Durchfallen, und Reviewer hören auf, sie zu nutzen. Verlangen Sie einen Grundcode aus einer kurzen Liste, zeigen Sie den Status dem Agent in der Prüfung und werten Sie die Nutzung nach Reviewer und Kriterium aus, damit die Kalibrierung sie prüfen kann.
Wie unterscheiden Sie in QA-Daten ein Systemproblem von einem Agent-Problem?
Schlüsseln Sie die Fehlerquote jedes Kriteriums nach Tageszeit, Queue, Kanal, Betriebszugehörigkeit und Release-Datum auf. Können verteilt sich ziemlich gleichmäßig über diese Gruppen, also ist ein Kriterium, das in einer Queue, in einem Zeitfenster oder ab einem Release-Datum deutlich häufiger durchfällt, fast immer ein System- oder Prozessproblem. Ein Kriterium, das Ihre stärksten und schwächsten Agents ähnlich oft verfehlen, ist entweder mehrdeutig oder unmöglich.
Wie nutzen Sie Ursachenanalyse in der Qualitätssicherung?
Fragen Sie, was hätte zutreffen müssen, damit der Agent besteht, und folgen Sie dieser Kette, bis Sie bei etwas ankommen, das jemandem gehört. Endet die Kette bei einem Tool, das ein Feld nicht gespeichert hat, einem falschen Wissensartikel oder einer Eskalation, die niemand beantwortet hat, gehört der Befund diesem Verantwortlichen als Fehler mit Häufigkeit und Kosten, und das Kriterium auf der Scorecard sollte ausgesetzt werden, bis er behoben ist. Ein Befund, der auf einen kaputten Prozess zurückgeht, sollte den Prozess ändern, nicht den Score der Person.
Verwandte Themen
- Was ein QA-Bewertungsraster ist und wie Sie eines aufbauen
- How to run a QA program agents trust
- Ursachenanalyse im Kundenservice
- Was QA-Kalibrierung ist und warum sie zählt
- How to turn QA data into coaching
Finden Sie heraus, welche Kriterien Ihre Agents gar nicht bestehen können
Bringen Sie die Scorecard mit, die Sie heute nutzen, und ein Quartal bewerteter Konversationen. Wir zeigen Ihnen, welche Kriterien in Mustern durchfallen, die Ihren Queues und Release-Daten folgen statt Ihren Agents.