Eskalationsmanagement im Kundenservice bewerten

Qualität im Eskalationsmanagement im Kundenservice beschreibt, wie gut eine Konversation geführt wird, nachdem sie ihren ersten Verantwortlichen verlassen hat. Bewerten Sie sie mit einem eigenen Bewertungsschema, und ordnen Sie jeden Fehler der Stelle zu, an der er entstanden ist.

Kurz gesagt

• Bearbeitungszeit, Skripttreue und der reine CSAT führen bei einer Eskalation alle in die Irre.
• Die Übergabe ist ein eigenständig prüfbares Ereignis mit zwei Verantwortlichen.
• Die eigentliche Einsparung entsteht durch die Frage, ob die Eskalation überhaupt hätte entstehen müssen.
• Eskalationen sind zu selten, als dass eine kleine Stichprobe das Muster zeigen könnte.

Eskalationsmanagement im Kundenservice: was als Eskalation zählt, und warum Ihre Definition Ihre Daten bestimmt

Bevor Sie Eskalationen bewerten können, müssen Sie sich einigen, was eine Eskalation ist, und die meisten Supportteams arbeiten stillschweigend mit drei unvereinbaren Definitionen gleichzeitig. Der Kunde verlangt einen Vorgesetzten. Ein Agent weist ein Ticket einer Spezialisten-Queue zu. Eine Regel greift, weil ein Service Level kurz vor der Verletzung stand. Alle drei heißen Eskalation, operativ haben sie nichts gemeinsam, und ihr Durchschnitt ergibt eine Zahl, mit der niemand etwas anfangen kann.

Legen Sie eine Definition fest, schreiben Sie sie auf, und sorgen Sie dafür, dass sie am Ticket erfasst wird, statt später aus einem Tag abgeleitet zu werden, den jemand aus dem Gedächtnis gesetzt hat. Der brauchbare Test ist die Zuständigkeit: Eine Eskalation ist jede Konversation, deren Zuständigkeit wechselt, weil der aktuelle Verantwortliche sie mit seinen Befugnissen, seinen Informationen oder seinen Fähigkeiten nicht lösen kann. Das schließt eine routinemäßige Umverteilung aus Kapazitätsgründen aus und den Fall ein, in dem niemand das Ticket verschoben hat, aber eine Teamleitung das Ergebnis freigeben musste.

Der Typ ist wichtig, weil er entscheidet, wem die Qualitätsfrage gehört.

Warum Ihre normale Scorecard bei einem eskalierten Ticket falsch liegt

Die meisten Teams bewerten Eskalationen mit der Scorecard, die sie schon haben, eben weil sie sie schon haben. Sie liefert Zahlen, also fällt niemandem auf, dass mehrere Kriterien nichts mehr messen.

Das Problem ist nicht, dass Eskalationen schwieriger sind. Es ist, dass die Standardkriterien auf Annahmen gebaut wurden, die eine Eskalation bricht: dass der Agent dem Kunden zum ersten Mal begegnet, dass der Kunde neutral gestimmt ist, dass die schnellste Lösung die beste ist und dass es im Standard-Playbook eine gute Antwort gibt. Bei einem eskalierten Ticket trifft nichts davon zu. Bevor Sie etwas ändern, lohnt es sich, klar zu haben, was Ihre QA-Scorecard eigentlich zu messen behauptet.

Kriterium für Kriterium sehen Sie hier, was nicht mehr funktioniert.

Was Sie bei einer eskalierten Konversation stattdessen bewerten

Sechs Kriterien tragen fast das gesamte Signal bei einem eskalierten Ticket. Jedes braucht Belege, auf die ein zweiter Reviewer im Transkript zeigen könnte, sonst haben Sie Adjektive geschrieben statt ein Bewertungsschema.

1. Kontext aufnehmen. Hat die bearbeitende Person den Verlauf gelesen, bevor sie antwortete? Der Beleg ist konkret: Sie hat sich auf etwas bezogen, das der Kunde früher gesagt hat, ohne dass er es wiederholen musste. Der Beleg für das Scheitern ist noch leichter zu finden, und er ist der nächste Punkt.
2. Die erneute Nachfrage. Hat die bearbeitende Person nach Informationen gefragt, die schon im Verlauf stehen? Bestellnummer, E-Mail-Adresse des Kontos, was schiefgelaufen ist. Das ist binär, ein Reviewer braucht dafür zehn Sekunden, und Agents bestreiten es nie, weil das Transkript es klärt.
3. Anerkennung ohne Schuldzuweisung. Der Kunde muss hören, dass der Fehler benannt wird. Was dieses Kriterium verfehlt, ist keine fehlende Entschuldigung, sondern Ablenkung: dem vorherigen Agent, dem System, der Richtlinie oder dem Kunden die Schuld zu geben. Eine Kollegin oder einen Kollegen vor dem Kunden als Ursache zu nennen, sollte ein K.o.-Kriterium sein.
4. Genauigkeit der Zusagen. Hat die bearbeitende Person etwas versprochen, das das Unternehmen tatsächlich tun wird, zu einem Termin, an dem es tatsächlich passiert? Dieses Kriterium erzeugt die nächste Eskalation, wenn es verfehlt wird, also verdient es ein hohes Gewicht.
5. Nutzung der Befugnis, für die eskaliert wurde. Eine Eskalation, die mit derselben Antwort endet, nur von jemand Ranghöherem überbracht, hat Sie zwei Agents gekostet und dem Kunden nichts gebracht. Entweder hat die bearbeitende Person einen Ermessensspielraum genutzt, den der erste Agent nicht hatte, oder der Eskalationsweg ist Dekoration.
6. Den Kreis schließen. Wurde dem Kunden das Ergebnis mitgeteilt, und wurde dem ursprünglichen Agent mitgeteilt, wie die Lösung aussah? Die zweite Hälfte wird fast überall übersprungen, und wer sie überspringt, garantiert, dass derselbe Agent nächste Woche dieselbe Eskalation erzeugt.

Kalibrieren Sie, bevor Sie das einführen

Eskalationen sind genau die Konversationen, bei denen Reviewer uneins sind, weil sie emotional sind und weil die richtige Antwort oft von Kontext abhängt, den das Transkript nur halb enthält. Führen Sie eine Kalibrierungssitzung mit drei eskalierten Tickets durch, bevor das Bewertungsschema live geht. Wenn Ihre Reviewer sich nicht einigen können, ob die bearbeitende Person echten Ermessensspielraum genutzt hat, werden die Agents den Score erst recht nicht akzeptieren. Das Format ist dasselbe wie bei jeder anderen Kalibrierungssitzung, die Sie durchführen (auf Englisch), nur mit Eskalationen als einziger Stichprobe.

Bewerten Sie die Übergabe, nicht nur die Lösung

Fragen Sie ein Supportteam, wo Eskalationen schiefgehen, und es beschreibt die Lösung. Lesen Sie hundert eskalierte Verläufe, und Sie stellen fest, dass der Schaden meist in den neunzig Sekunden der Übergabe entstanden ist. Das Plädoyer der Harvard Business Review, den Aufwand für Kunden zu senken, statt sie begeistern zu wollen, gilt hier mit besonderer Wucht, denn eine Eskalation ist bereits ein zweiter Anlauf, und eine schlampige Übergabe macht daraus einen dritten.

Die Übergabe ist ein eigenständig prüfbares Ereignis, und sie hat zwei Verantwortliche. Bewerten Sie sie als eigenen Block, wobei die sendende Seite dem ursprünglichen Agent und die empfangende Seite der bearbeitenden Person zugeordnet wird. Beide getrennt zu halten, ist der ganze Sinn, denn nur so landet der Score bei der richtigen Person.

Sendende Seite

• Der Grund für die Eskalation ist im Ticket festgehalten, in Worten, nicht nur als Tag.
• Was bereits versucht wurde, ist zusammengefasst, damit die empfangende Seite es nicht wiederholt.
• Dem Kunden wurde gesagt, dass die Übergabe stattfindet, warum, und ungefähr wann er eine Antwort erwarten kann. Eine stille Übergabe ist ein Fehler, auch wenn die Lösung perfekt ist.
• Im Namen des empfangenden Teams wurde nichts versprochen, dem das empfangende Team nicht zugestimmt hat.

Empfangende Seite

• Der Verlauf wurde gelesen, bevor die erste Antwort rausging. Der Test der erneuten Nachfrage klärt das.
• Die Wartezeit wurde anerkannt. Der Kunde hat jetzt schon zweimal in einer Queue gewartet.
• Der Kunde wurde nicht gebeten, das Problem als Gesprächseinstieg noch einmal zu schildern.
• Wenn das Ticket zurück- oder weitergeschickt wurde, wurde der Grund mit derselben Sorgfalt festgehalten wie bei der ersten Übergabe.

Zwei Kennzahlen ergeben sich direkt daraus, die Übergabe so zu bewerten, und beide sind nützlicher als die Eskalationsrate allein. Die Nachfragequote ist der Anteil eskalierter Konversationen, in denen die empfangende Person nach Informationen gefragt hat, die schon im Verlauf standen. Die Bounce-Rate ist der Anteil der Eskalationen, die vor der Lösung erneut zurück- oder weitergeschickt werden, was meist ein Routing-Fehler ist und kein persönliches Versagen. Keine von beiden braucht eine Umfrage, und beide lassen sich aus den Konversationsdaten zählen, die Sie ohnehin haben. Wenn Sie ein breiteres Kennzahlenset aufbauen, gehört das neben die anderen Wege, Konversationsqualität zu messen (auf Englisch).

Das Zuordnungsproblem: Wer hat diese Eskalation eigentlich verursacht?

Das ist die Fairnessfrage, die entscheidet, ob Sie ein QA-Programm aufbauen können, dem Agents vertrauen (auf Englisch), und kaum ein Leitfaden zu Eskalationen geht darauf ein.

Die meisten Eskalationen entstehen weiter vorne. Wenn eine Konversation bei einem Spezialisten oder einer Teamleitung ankommt, ist die Entscheidung, die sie verursacht hat, längst gefallen: durch einen Erstkontakt, der etwas übersehen hat, durch eine Richtlinie, die niemand im First Level biegen darf, durch einen Produkt- oder Systemfehler oder durch eine Erwartung, die jemand anderes geweckt hat. Die bearbeitende Person dafür zu bewerten, dass es die Eskalation überhaupt gibt, ist die häufigste Ungerechtigkeit in der Support-QA, und Agents bemerken sie sofort.

Die Lösung ist eine Regel und eine Gewohnheit.

Die Regel. Die bearbeitende Person wird nur für die Eskalation selbst bewertet. Ob die Eskalation hätte passieren dürfen, ist ein separater Befund, der einem separaten Verantwortlichen zugeordnet und in einem separaten Datensatz festgehalten wird. Lassen Sie nie einen Score beide Urteile tragen, denn sobald er das tut, schneiden die Menschen, die Ihre schwierigste Arbeit machen, am schlechtesten ab.

Die Gewohnheit. Jede Prüfung einer Eskalation sind zwei Prüfungen. Öffnen Sie die eskalierte Konversation, und öffnen Sie den Kontakt, der sie ausgelöst hat. Ordnen Sie dann den Ursprung einer von vier Kategorien zu:

• Bearbeitung. Der erste Agent hatte die Informationen und die Befugnis und hat sie nicht genutzt. Das gehört zu einer Person, und es lässt sich coachen.
• Richtlinie. Der Agent hat genau das getan, was die Richtlinie vorgibt, und die Richtlinie hat einen verärgerten Kunden erzeugt. Das gehört dem, der die Richtlinie verantwortet, und den Agent dafür zu coachen, ist schlimmer als nutzlos.
• System oder Produkt. Etwas war defekt, langsam oder falsch. Das gehört in ein Engineering- oder Operations-Backlog, nicht in ein Einzelgespräch.
• Erwartung. Ein Versprechen, das an anderer Stelle gegeben wurde, durch Preise, Marketing, ein früheres Ticket oder eine Störungsmeldung, hat den Kontakt mit der Realität nicht überstanden.

Zwei Leitplanken halten die Zuordnung ehrlich. Die Ursprungskategorie darf nicht von der bearbeitenden Person gesetzt werden, die ein offensichtliches Interesse daran hat, und auch nicht vom ursprünglichen Agent. Sie ist die Entscheidung eines Reviewers. Und wenn die Ursprungskategorie Richtlinie, System oder Erwartung ist, ändert sich kein einziger Score auf Agent-Ebene, und genau das sollten Sie beim Start laut sagen. Sobald sich die Zuordnungen sammeln, sind sie der Input für eine echte Ursachenanalyse statt einer monatlichen Vermutung.

Hätte diese Eskalation überhaupt passieren dürfen?

Die Qualität der Bearbeitung zu verbessern, lohnt sich. Das Eskalationsvolumen zu senken, lohnt sich mehr, denn eine verhinderte Eskalation muss gar nicht erst gut bearbeitet werden, und jede vermeidbare ist ein Stück Kundenunzufriedenheit, das Sie selbst produziert haben.

Hängen Sie deshalb an jede Prüfung einer Eskalation ein Urteil, getrennt vom Score. Drei Optionen, und die Formulierung ist wichtig, denn der ganze Sinn ist, die mittlere Kategorie sichtbar zu machen.

• Vermeidbar. Der erste Agent hatte die Befugnis, die Informationen und die Werkzeuge, um es zu lösen. Nichts Strukturelles hat ihn gehindert. Das ist ein Coaching-Befund, und in einem gesunden Programm sollte er nur einen kleinen Anteil der Gesamtzahl ausmachen.
• Strukturell. Niemand im First Level hätte es lösen können, wegen einer Berechtigung, die er nicht hat, eines Systems, auf das er keinen Zugriff hat, oder einer Richtlinie, die er nicht biegen darf. Das ist die wichtige Kategorie. Es ist kein Agent-Problem, es ist ein Designproblem, und jedes Ticket darin ist ein Kandidat dafür, Befugnisse eine Ebene nach unten zu verlagern.
• Berechtigt. Die Eskalation ist der Prozess, der funktioniert. Spezialwissen war wirklich nötig. Nichts zu beheben, und sie sollte in niemandes Zahlen als Mangel zählen.

In der strukturellen Kategorie liegt das Geld, und sie ist für jedes Eskalationsprogramm unsichtbar, das nur die Eskalation selbst bewertet. Wenn vierzig Eskalationen des letzten Quartals alle dieselbe Erstattungsfreigabe brauchten, die eine Ebene über dem First Level liegt, sehen Sie keine Schulungslücke. Sie sehen eine Freigabeschwelle, die an der falschen Stelle liegt, und Sie können den Preis der Lösung beziffern, indem Sie die Tickets zählen.

Eine Anmerkung zu den Kosten, bewusst ohne Zahl. Es ist verlockend, die Eskalationen mit durchschnittlichen Bearbeitungskosten zu multiplizieren und eine Schlagzeile zu produzieren. Tun Sie es nicht, es sei denn, Sie können die Eingangswerte verteidigen: Eine echte Eskalation kostet mindestens die Zeit von zwei Personen, meist die Aufmerksamkeit einer Teamleitung, die Wartezeit, die der Kunde erlebt, und die höhere Abwanderungswahrscheinlichkeit nach einer misslungenen Wiedergutmachung, und nichts davon ist über verschiedene Anliegen hinweg konstant. Zählen Sie die Tickets in der strukturellen Kategorie, und beschreiben Sie die konkrete Lösung, die jedes Cluster braucht. Dieses Argument hält einer Prüfung stand. Erfundene Kosten pro Eskalation tun es nicht.

Was Eskalationsmuster in der Summe zeigen

Eine Eskalation ist ein Coaching-Gespräch. Hundert Eskalationen, zusammen gelesen, sind eine Landkarte der Stellen, an denen Ihr Service-Design versagt, und sie zeigen Dinge, die keine einzelne Prüfung zeigen kann.

Fünf Auswertungen, die sich monatlich lohnen

• Konzentration nach Thema. Gruppieren Sie Eskalationen nach dem, was der Kunde wollte, nicht nach dem Tag, den der Agent gesetzt hat. Eine Handvoll Themen erzeugt fast immer den Großteil des Volumens, und meist sind es Grenzfälle von Richtlinien statt komplexer Probleme.
• Ursprungsmix im Zeitverlauf. Verfolgen Sie die vier Zuordnungskategorien als Anteile. Wenn der Anteil der Bearbeitung sinkt, während der strukturelle Anteil gleich bleibt, wirkt Ihr Coaching, Ihr Prozess aber nicht.
• Wiederholte Eskalationen. Derselbe Kunde, dasselbe zugrunde liegende Anliegen, zweimal eskaliert. Das ist der stärkste einzelne Hinweis darauf, dass die erste Lösung nur kosmetisch war, und jeder einzelne Fall lohnt eine Prüfung von Hand.
• Bounce- und Nachfragequote nach empfangendem Team. Sie zeigen die Teams, die Arbeit bekommen, für die sie nicht aufgestellt sind, und das ist eine Routing-Diskussion, keine Qualitätsdiskussion.
• Tageszeit und Personalbesetzung. Eskalationen, die sich an Schichtwechseln oder Besetzungslücken häufen, sind ein Befund für die Dienstplanung, und kein Coaching wird sie bewegen.

Das Nennerproblem

Eskalationsraten zwischen Agents zu vergleichen, ist der schnellste Weg, das Team zu verlieren, denn der Agent in der schwierigsten Queue eskaliert am meisten. Die Eskalationsrate gehört zu Ihren übrigen KPIs im Kundenservice, und sie ist nur innerhalb derselben Queue, desselben Kanals und bei ungefähr gleichem Mix an Anliegen vergleichbar, und selbst dann gehört sie in ein Gespräch statt auf eine Rangliste. Eine hohe Eskalationsrate bei komplexer Arbeit kann richtiges Verhalten sein. Eine niedrige kann bedeuten, dass ein Agent sich weigert, Dinge zu eskalieren, die er eskalieren sollte, und das ist das teurere Versagen, das sich stattdessen in wiederholten Kontakten zeigt.

Warum Stichproben hier an Grenzen stoßen

Eskalationen sind von Natur aus selten, und genau das macht sie schwer gut zu prüfen. Eine kleine zufällige Stichprobe aus den Konversationen eines Monats, gezogen so, wie die meisten QA-Stichproben funktionieren, enthält fast keine Eskalationen, und die wenigen, die sie enthält, sind für die Themen, die sie verursachen, nicht repräsentativ. Die meisten Teams reagieren darauf, indem sie Eskalationen für die Prüfung von Hand auswählen, was eine andere Verzerrung einführt: Sie finden, wonach Sie gesucht haben. Jede Eskalation zu prüfen statt einer Stichprobe ist das, was aus Anekdoten ein Muster macht, und es ist dasselbe Argument wie bei 100 % Abdeckung, die Trends zeigt, die eine 3-%-Stichprobe nie zeigen könnte (auf Englisch).

Hier verdient sich automatisierte Bewertung ihren Platz, sobald das oben beschriebene Bewertungsschema existiert und die Reviewer sich darauf geeinigt haben. Kaizos Auto QA wendet Ihr eigenes Eskalations-Bewertungsschema auf jede eskalierte Konversation an statt auf die Handvoll, die in der Stichprobe landet, sodass Themenkonzentration und Ursprungsmix gezählt statt geschätzt werden. Wichtiger als die Abdeckung ist, dass jeder Abzug an dem Moment in der Konversation hängen bleibt, der ihn verursacht hat. Wenn ein Agent also einen Score für ein Ticket anficht, das er geerbt hat, kann der Reviewer sich den Austausch ansehen, statt aus dem Gedächtnis zu argumentieren. Was aus der Gesamtsicht hervorgeht, speist dann die Coaching-Gespräche (auf Englisch), die sich lohnen, und lässt die, die sich nicht lohnen, leise verschwinden.

Häufig gestellte Fragen

Was ist Eskalationsmanagement?

Eskalationsmanagement ist die Arbeit, eine Konversation zu lösen, nachdem die Zuständigkeit von der Person gewechselt ist, die sie zuerst erhalten hat, meist weil das Anliegen mehr Befugnisse, mehr Spezialwissen oder eine Entscheidung brauchte, die der erste Agent nicht treffen konnte. Es umfasst die Übergabe selbst, die Rückgewinnung eines Kunden, der bereits frustriert ist, die Genauigkeit dessen, was zugesagt wird, und das Schließen des Kreises mit dem Kunden und mit dem ursprünglichen Agent. In der Qualitätssicherung wird es als eigene Arbeitskategorie behandelt, weil die Kriterien, nach denen ein Routineticket beurteilt wird, auf ein geerbtes Ticket nicht sauber passen.

Wie bearbeitet man eine Eskalation gut?

Lesen Sie den gesamten Verlauf, bevor Sie antworten, damit der Kunde sich nie wiederholen muss. Benennen Sie, was schiefgelaufen ist, ohne einer Kollegin, einem Kollegen, einer Richtlinie oder dem Kunden die Schuld zu geben. Nutzen Sie den Ermessensspielraum, für den eskaliert wurde, denn eine Eskalation, die dieselbe Antwort von jemand Ranghöherem liefert, hat niemandem geholfen. Sagen Sie nur zu, was tatsächlich passieren wird, zu Terminen, die real sind. Schließen Sie dann den Kreis zweimal: Teilen Sie dem Kunden das Ergebnis mit, und teilen Sie dem Agent, der eskaliert hat, die Lösung mit, damit dieselbe Eskalation nächste Woche nicht wieder passiert.

Was ist ein Beispiel für eine Kundeneskalation?

Ein Agent, der der Richtlinie folgt, verweigert einem Kunden eine Erstattung, der Kunde antwortet, das sei inakzeptabel, und verlangt einen Vorgesetzten. Das Ticket geht an eine Teamleitung, die befugt ist, eine Ausnahme zu machen. Das ist eine hierarchische, vom Kunden verlangte Eskalation, und sie ist die häufigste Form. Ein anderes Beispiel: Eine Abweichung in der Abrechnung, die der First Level in seinen Tools nicht sehen kann, wird an einen Spezialisten in der Buchhaltung weitergeleitet. Das ist eine fachliche Eskalation, niemand hat etwas falsch gemacht, und sie sollte nicht gegen den ersten Agent zählen.

Sollten eskalierte Tickets mit derselben QA-Scorecard bewertet werden?

Nein. Mindestens vier Standardkriterien führen bei einer Eskalation in die Irre. Die Bearbeitungszeit bestraft die langsamere Arbeit, die die Eskalation gerade ermöglichen soll, die Einhaltung von Vorlagen belohnt die Wiederverwendung der Antwort, die der Kunde schon abgelehnt hat, Kriterien zu Begrüßung und Eröffnung übergehen, dass die Geschichte schon einmal erzählt wurde, und Zufriedenheitswerte bewerten zum Teil den vorherigen Kontakt statt des aktuellen. Behalten Sie Genauigkeit und Einhaltung der Richtlinien, streichen oder ersetzen Sie den Rest, und ergänzen Sie Kriterien für die Übergabe, die Genauigkeit der Zusagen und die Nutzung der Befugnis.

Wie misst man die Qualität im Eskalationsmanagement?

Nutzen Sie vier Kennzahlen zusammen und keine davon allein. Einen Score nach Bewertungsschema für die eskalierte Konversation, der Kontextaufnahme, Anerkennung, Genauigkeit der Zusagen, Nutzung der Befugnis und das Schließen des Kreises abdeckt. Die Nachfragequote, also den Anteil der Eskalationen, in denen die empfangende Person nach etwas gefragt hat, das schon im Verlauf stand. Die Bounce-Rate, also den Anteil, der vor der Lösung zurück- oder weitergeschickt wird. Und die Quote wiederholter Eskalationen, also den Anteil, bei dem derselbe Kunde dasselbe Anliegen zweimal eskaliert, das klarste Zeichen, dass die erste Lösung kosmetisch war.

Was ist eine gute Eskalationsrate?

Es gibt keinen Benchmark, der sich zu zitieren lohnt, denn die Zahl hängt ganz davon ab, wie Sie eine Eskalation definieren, was Ihr Produkt ist und wie viel Befugnis im First Level liegt. Ein Team, das jede Weiterleitung an Spezialisten als Eskalation zählt, meldet ein Vielfaches der Rate eines Teams, das nur die Beteiligung von Teamleitungen zählt. Vergleichen Sie Ihre Rate mit Ihrem eigenen Trend und mit vergleichbaren internen Queues, und achten Sie mehr auf den Mix als auf das Niveau. Eine stabile Rate mit einem sinkenden Anteil vermeidbarer Eskalationen ist ein Programm, das funktioniert.

Wer sollte bewertet werden, wenn ein Ticket eskaliert wird?

Beide Personen, für unterschiedliche Dinge. Der ursprüngliche Agent wird für die Übergabe bewertet, die er gesendet hat, und dafür, ob seine Bearbeitung die Eskalation verursacht hat. Die empfangende Person wird für die Eskalation selbst bewertet und nie dafür, dass es sie gibt. Ob die Eskalation hätte passieren dürfen, wird als separater Befund festgehalten, zugeordnet zu einem von vier Ursprüngen: Bearbeitung, Richtlinie, System oder eine an anderer Stelle geweckte Erwartung. Wenn der Ursprung Richtlinie, System oder Erwartung ist, sollte sich kein Score auf Agent-Ebene bewegen.

Verwandte Themen

• Was ein Bewertungsschema in der QA ist und wie Sie eines aufbauen
• Die QA-Scorecard: was darauf gehört
• Was Kalibrierung in der Qualitätssicherung ist und warum sie wichtig ist
• Ursachenanalyse für Supportteams
• Konversationsqualität messen (auf Englisch)
• Was 100 % QA-Abdeckung wirklich bedeutet (auf Englisch)

Finden Sie heraus, wie viele Ihrer Eskalationen vermeidbar waren

Bringen Sie einen Monat eskalierter Tickets mit und die Scorecard, mit der Sie sie heute bewerten. Wir zeigen Ihnen, wo diese Eskalationen entstanden sind, wie viele in der strukturellen Kategorie liegen, die Sie per Design beseitigen können, und was sich ändert, wenn das Bewertungsschema auf alle angewendet wird statt auf die wenigen, die in der Stichprobe landen.

Demo buchen Agentic Auto QA entdecken