Qualitätssicherung in Salesforce Service Cloud heißt: Sie bewerten die Antworten, die ein Agent geschrieben hat, den Kanal und den Zustand, in dem der Fall hinterlassen wurde. Legen Sie zuerst fest, was als Konversation zählt, denn ein Fall umfasst viele verknüpfte Datensätze.
Kurz gesagt
- Der Fallinhaber hat die Antwort oft nicht selbst geschrieben.
- Ordnen Sie jedes Kriterium einem Feld zu, das es in Ihrer Org gibt.
- Definieren Sie die Grundgesamtheit der Stichprobe mit einem Bericht.
- Entscheiden Sie vor dem Rollout, wie Sie Fälle mit mehreren Kanälen bewerten.
Was Qualitätssicherung in Salesforce Service Cloud tatsächlich bedeutet
Die meisten QA-Leitfäden gehen von einem Ticket aus: ein Kunde, ein Thread, ein Bearbeiter, von oben nach unten gelesen. Service Cloud funktioniert so nicht, und genau dieser eine strukturelle Unterschied ist der Grund, warum allgemeine QA-Ratschläge meist schon in der ersten Woche auseinanderfallen.
Ein Fall ist ein Datensatz. Er trägt Felder wie Status, Herkunft, Grund, Priorität und Inhaber, wobei die Werte in diesen Auswahllisten von Ihrem eigenen Admin konfiguriert und nicht von der Plattform vorgegeben werden. Um diesen Datensatz herum liegt das, was Kunde und Agent tatsächlich getan haben: E-Mails, Chat- oder Messaging-Transkripte, interne Beiträge, Aufgaben und, wo die Org Voice bereitgestellt hat, Anrufdatensätze. Der Fall-Feed zeigt eine Chronologie dieser Aktivität, aber eine Chronologie ist nicht dasselbe wie eine Konversation. Sie mischt Antworten von Agents mit Systemeinträgen, Feldänderungen und Beiträgen von Personen, die nie mit dem Kunden gesprochen haben.
Die erste Frage der QA in Service Cloud lautet also nicht „Was sollen wir bewerten?“. Sie lautet: Was nennen wir die Konversation? Es gibt drei vertretbare Antworten, und Sie müssen sich bewusst für eine entscheiden:
- Nur der kundenseitige Austausch. Jede Nachricht, die der Kunde sehen konnte, in der richtigen Reihenfolge, ohne interne Beiträge und Feldverlauf. Das kommt einem Ticket-Thread am nächsten und lässt sich einem Agent am leichtesten erklären.
- Der Austausch plus der Zustand des Datensatzes. Dieselben Nachrichten, bewertet zusammen damit, wie der Fall kategorisiert und geschlossen wurde. Richtig für Teams, deren Datenqualität ins Reporting einfließt.
- Der ganze Fall einschließlich interner Arbeit. Nachrichten, interne Notizen, Übergaben und Aufgaben. Die vollständigste Sicht und die am schwersten konsistent zu bewertende, weil Reviewer sich uneinig sind, wie viel interne Arbeit genug ist.
Halten Sie die Antwort schriftlich fest, bevor Sie Kriterien schreiben. Sonst wählt jeder Reviewer still seine eigene, und Sie bekommen das Muster an Uneinigkeit, das alle QA-Verantwortlichen kennen: Zwei Personen bewerten denselben Fall mit 60 und 85, und keiner kann sagen, warum. Die Scorecard-Mechanik, die darauf aufsetzt, ist dieselbe wie in jedem QA-Programm im Support. Wenn Sie noch keine haben, beginnen Sie mit wie Sie eine QA-Scorecard aufbauen und kommen Sie dann zurück.
Was sich an einem Fall bewerten lässt und was nicht
Bevor Sie Kriterien schreiben, nehmen Sie einen kürzlich geschlossenen Fall und erfassen, was tatsächlich daran hängt. Tun Sie das in Ihrer eigenen Org statt anhand einer Vorlage, denn was vorhanden ist, hängt stark davon ab, wie die Org konfiguriert wurde.
In der Regel vorhanden
- Von Agents verfasste Nachrichten. Die E-Mail-Antworten, die Chat- oder Messaging-Beiträge und alle öffentlichen Beiträge. Das ist der zentrale Beleg für alles, was die Kommunikation betrifft.
- Zeitstempel. Wann der Kunde schrieb, wann der Agent antwortete, wann der Inhaber wechselte, wann der Fall geschlossen wurde. Genug, um die Reaktionsgeschwindigkeit zu beurteilen, mit den Einschränkungen weiter unten.
- Feldwerte beim Schließen. Status, Grund, Produkt- oder Kategoriefelder und alle benutzerdefinierten Felder, die Ihre Org verlangt. Sie machen einen Fall auswertbar und gehören daher zu Recht zur Qualität.
- Interne Notizen und Beiträge. Die Qualität der Übergabe, die Recherche, die Begründung einer Eskalation.
- Inhaberverlauf. Wer den Fall hatte und wann er weiterging.
Häufig fehlend, und vor dem Zusagen eines Kriteriums zu prüfen
- Voice. Ob überhaupt ein Anruf angehängt ist und ob es ein Transkript statt nur einer Aufzeichnung oder einer Notiz gibt, hängt davon ab, wie Voice in Ihrer Org bereitgestellt ist. Prüfen Sie das, bevor Sie ein Kriterium schreiben, das vom Inhalt des Anrufs abhängt.
- Was der Agent sehen konnte. Sicherheit auf Feldebene und Freigaberegeln bedeuten, dass die Sicht des Reviewers auf einen Fall nicht unbedingt die des Agents ist. Wenn ein Kriterium voraussetzt, dass der Agent eine Information hatte, prüfen Sie, ob er sie hatte.
- Der Stand des Wissens zum damaligen Zeitpunkt. Wenn sich ein Artikel nach dem Schließen des Falls geändert hat, lag der Agent mit der Version, die er hatte, vielleicht richtig.
- Alles, was außerhalb des Datensatzes passiert ist. Ein telefonischer Rückruf, der als einzeilige Notiz erfasst wurde, eine Unterhaltung in einem Chat-Tool, eine persönliche Übergabe an ein anderes Team. Das ist echte Arbeit, und für die QA ist sie unsichtbar.
Die Regel, die daraus folgt, ist kurz. Wenn sich ein Kriterium nicht mit etwas am Fall belegen lässt, ist es kein QA-Kriterium, sondern eine Meinung. Finden Sie entweder das Feld oder die Nachricht, die es belegt, oder nehmen Sie es aus der Scorecard heraus und verschieben es ins Coaching. Eine allgemeine QA-Checkliste für den Kundenservice ist eine nützliche erste Bestandsaufnahme, aber jede Zeile davon muss diesen Test an Ihrem eigenen Fall-Layout bestehen.
Wie Falldaten auf Scorecard-Kriterien passen
An dieser Zuordnung entscheidet sich das Programm. Benennen Sie für jedes Kriterium den Beleg, die Prüfung und die Fehlerquelle, die Sie erwarten. Die letzte Spalte lassen Teams gern weg, und gerade sie sagt jede Diskussion voraus, die Sie führen werden.
| Art des Kriteriums | Beleg am Fall | Wie ein Reviewer es prüft | Wo es schiefgeht |
|---|---|---|---|
| Richtigkeit der Lösung | Die letzte Nachricht des Agents, gelesen gegen die Felder, mit denen der Fall geschlossen wurde | Passt die gegebene Antwort zum erfassten Ergebnis, und war sie zu dem Zeitpunkt richtig | Der Status wird von einer Automatisierung oder einem Makro gesetzt, sodass der Datensatz „gelöst“ sagt, ohne dass es dafür einen Beleg gibt |
| Einhaltung von Prozessen | Pflichtfelder, interne Notizen und alle Berechtigungs- oder Service-Level-Datensätze, die die Org konfiguriert hat | Vergleichen, was der Fall erfasst, mit Ihrem dokumentierten Prozess für diesen Falltyp | Die Anforderung steht in einem Wiki statt in einem Feld, sodass zwei Reviewer zwei verschiedene Versionen davon anwenden |
| Kommunikationsqualität | Nur von Agents verfasste Nachrichten, nie der ganze Feed | Den Text bewerten, den der Kunde tatsächlich lesen konnte | Reviewer übernehmen den Ton aus internen Beiträgen und Systemeinträgen und rechnen ihn dem Agent zu |
| Reaktionszeit und Aufwand | Zeitstempel an Nachrichten und Inhaberwechseln | Die Lücken zwischen einer Kundennachricht und der nächsten Antwort eines Agents messen | Wartezeit in der Queue, Geschäftszeiten und das Warten auf ein anderes Team werden alle dem angelastet, der den Fall gerade hat |
| Kategorisierung und Datenqualität | Herkunft, Grund, Datensatztyp und Ihre eigenen Reporting-Felder | Beschreiben die Werte, was in der Konversation tatsächlich passiert ist | Agents wählen den Wert, der am schnellsten durch die Validierungsregel kommt, und bisher hat das niemand bewertet |
| Routing | Inhaberverlauf, Queue-Zugehörigkeit, Datensatztyp | Hat der Fall zuerst das richtige Team erreicht, und wenn nicht, warum nicht | Eine Fehlleitung durch eine Routing-Regel wird als Fehler des Agents bewertet |
Wie sich die Bewertung eines Falls von der eines Zendesk-Tickets unterscheidet
Viele Support-Ops-Verantwortliche haben QA in Zendesk betrieben und sollen sie jetzt in Service Cloud betreiben, oder in beiden gleichzeitig. Die Philosophie der Scorecard lässt sich übertragen. Die Mechanik nicht, und diese sechs Unterschiede kosten am meisten Zeit. Wenn Sie auch die Zendesk-Seite betreiben, finden Sie die plattformspezifische Mechanik dafür gesondert unter Qualitätssicherung für Zendesk.
| Dimension | Zendesk-Ticket | Fall in Salesforce Service Cloud |
|---|---|---|
| Die Einheit der Prüfung | Ein Ticket ist ein Thread. Anfragender, Bearbeiter und Kommentare lesen sich als eine lineare Konversation | Ein Fall ist ein Datensatz. Die Konversation wird aus verknüpften Nachrichten, Transkripten und Feed-Einträgen zusammengesetzt |
| Wer die Arbeit gemacht hat | Bearbeiter plus die sichtbaren Kommentarautoren | Das Inhaberfeld sagt, wer den Fall jetzt hat. Die Autorschaft muss an jeder einzelnen Nachricht abgelesen werden |
| Kanal | Meist eine Eigenschaft des Tickets selbst | Kanäle kommen als verschiedene verknüpfte Datensätze, und ein Fall kann mehr als einen davon enthalten |
| Die Grundgesamtheit der Stichprobe definieren | Ansichten und Suchfilter | Ein Bericht oder eine Listenansicht auf Basis der eigenen Fallfelder Ihrer Org |
| Wie viel Standard ist | Die Feldstruktur ist zwischen Accounts weitgehend gleich | Datensatztypen, benutzerdefinierte Felder und Auswahllistenwerte werden pro Org konfiguriert, daher lässt sich keine Scorecard unverändert übertragen |
| Abschlusszustand | Wenige, vertraute Statuswerte | Statuswerte und was jeder davon operativ bedeutet, legt Ihr Admin fest |
Wie Sie eine Stichprobe ziehen, die Sie verteidigen können
Der häufigste Vorwurf an ein QA-Programm lautet, der Reviewer habe die schlechtesten Fälle ausgesucht. In Service Cloud ist dieser Vorwurf leicht zu erheben, denn es gibt keine natürliche Prüf-Queue, und es ist wirklich verlockend, mit der Listenansicht zu arbeiten, die gerade offen ist.
Definieren Sie zuerst die Grundgesamtheit, in einem Bericht, und speichern Sie den Bericht. Ein brauchbarer Filter ist: Schließdatum im Prüfzeitraum, Datensatztyp oder Queue, der die zu bewertende Arbeit kennzeichnet, Kanal, falls Sie Kanäle getrennt bewerten, und ein Ausschluss für Fälle ganz ohne von einem Agent verfasste Nachricht. Duplikate, automatisch geschlossene Fälle und Fälle, die nie einen Menschen erreicht haben, sind Rauschen. Bleiben sie in der Grundgesamtheit, verzerren sie still jeden Durchschnitt, den Sie danach veröffentlichen, nach oben oder unten.
Ziehen Sie die Stichprobe dann aus dieser Grundgesamtheit statt aus der Liste. Zwei Regeln sind wichtiger als der Stichprobenumfang:
- Randomisieren Sie innerhalb von Schichten, nicht über die ganze Menge. Schichten Sie nach Agent und Falltyp und ziehen Sie dann zufällig innerhalb jeder Schicht. Eine rein zufällige Stichprobe über einen ganzen Monat gibt Ihren meistbeschäftigten Agents zwanzig Fälle und Ihrem neuesten Agent einen, und damit sind die Einzelscores nicht vergleichbar.
- Legen Sie die Stichprobe fest, bevor jemand einen Fall liest. Ziehen Sie die Liste, speichern Sie sie und prüfen Sie, was Sie gezogen haben. Eine Stichprobe, die ausgewählt wird, nachdem der Reviewer die Grundgesamtheit überflogen hat, ist keine Stichprobe.
Machen Sie sich ehrlich klar, was Ihnen eine manuelle Stichprobe bringt. Dreißig Fälle pro Agent und Monat zu prüfen ist ein erheblicher Aufwand und sagt trotzdem sehr wenig über die bestimmten Falltypen, die selten vorkommen und am meisten schaden. Diese Grenze ist Arithmetik, nicht Fleiß, und es ist dieselbe Einschränkung, die das Engineering-Handbuch des NIST beschreibt, wenn es fragt, ob ein in einer Stichprobe ermittelter Anteil fehlerhafter Einheiten eine Anforderung erfüllt: Die Stichprobe muss groß genug sein, damit der Test gültig ist, bevor die Antwort etwas bedeutet. Deshalb müssen ein Stichproben-Score und ein an die Leitung berichteter Internal Quality Score ihr Konfidenzintervall neben der Zahl tragen, und deshalb lohnt es sich zu wissen, wo QA-Stichproben die Frage nicht mehr beantworten können.
Wer hat die Antwort geschrieben: Zuordnung bei einem Fall, der den Inhaber gewechselt hat
Hier ist das Problem, auf das keine Vorlage Sie vorbereitet, und das, das dem Vertrauen der Agents in ein QA-Programm in Service Cloud am meisten schadet.
Fälle wandern. Sie werden geroutet, eskaliert, neu zugewiesen, aus einer Queue genommen, an ein Spezialistenteam übergeben und zurückgegeben. Das Inhaberfeld erfasst, wer den Fall in dem Moment hat, in dem Sie hinsehen. Es erfasst nicht, wer die Antwort geschrieben hat, die den Kunden verärgert hat, oder wer die Recherche gemacht hat, die das Problem gelöst hat. Wenn Ihr QA-Prozess einen Fall bewertet und das Ergebnis dem Inhaber zuschreibt, haben Sie bei jedem weitergegebenen Fall die Arbeit einer Person einer anderen zugeschrieben.
Die praktische Folge ist vorhersehbar und konkret. Die Agents, die Eskalationen bearbeiten, übernehmen Fälle, die bereits schlecht laufen, und sammeln die daraus folgenden Scores ein. Das sind meist Ihre fähigsten Leute. Innerhalb eines Quartals lernen sie, dass es sie etwas kostet, einen schwierigen Fall zu übernehmen, und genau das Verhalten, das Sie am meisten fördern wollten, wird zu dem Verhalten, das Ihre Rangliste bestraft.
Vier Regeln, die das beheben
- Bewerten Sie die Nachricht, nicht den Datensatz. Jeder Abzug sollte an einer bestimmten, von einem Agent verfassten Nachricht mit Zeitstempel und Autor hängen, nicht am Fall als Ganzem.
- Ordnen Sie nach Autor zu. Lesen Sie die Autorschaft an jeder Nachricht ab statt am Inhaberfeld. Wenn Ihr Reporting das nicht kann, ist das das Erste, was Sie beheben, noch bevor Sie eine einzige Gewichtung anpassen.
- Behandeln Sie Fälle mit mehreren Agents ausdrücklich. Bewerten Sie entweder den eigenen Beitrag jedes Agents getrennt, oder nehmen Sie den Fall aus der Einzelbewertung heraus und nutzen Sie ihn für die Prozessprüfung. Beides ist vertretbar. Still den letzten Inhaber zu bewerten, ist es nicht.
- Halten Sie den Inhaberverlauf neben dem Score bereit. Wenn ein Score angefochten wird, lautet die erste Frage immer, wer was getan hat. Wenn die Antwort zwanzig Minuten Rekonstruktion braucht, ist die Diskussion bereits verloren.
Weitergegebene Fälle sind außerdem Ihre ergiebigste Quelle für Prozessarbeit statt für individuelles Coaching. Ein Fall, der viermal den Inhaber gewechselt hat, bevor er gelöst wurde, sagt Ihnen etwas über Routing, Berechtigungen oder Teamgrenzen, und das gehört in die Ursachenanalyse statt auf die Scorecard von irgendjemandem.
Jeden Fall bewerten statt einer Stichprobe
Sobald die manuelle Methode steht, liegt die Frage nahe, ob Sie mit den Stichproben aufhören können. Sie können es, und das Argument dafür ist in Service Cloud stärker als bei einem einfacheren Ticketmodell, weil die wichtigsten Falltypen häufig die seltenen sind, die eine Stichprobe nie erreicht. Es ist ein echter Unterschied, ob 100 % Abdeckung Trends sichtbar macht, die eine 3-%-Stichprobe nie zeigen könnte, oder ob Sie monatlich dreißig Fälle pro Agent prüfen.
Abdeckung allein ist allerdings nicht der interessante Teil, und sie ist auch kein Unterscheidungsmerkmal mehr. Jeder Anbieter in dieser Kategorie bewertet inzwischen alles. Ob ein automatisierter Score den Kontakt mit Ihrem Team übersteht, entscheidet die Frage, ob Sie zeigen können, dass die Bewertung richtig war. In Service Cloud heißt das konkret vier Dinge:
- Nachvollziehbarkeit bis in den Fall. Ein Abzug muss das Kriterium nennen und auf die genaue Nachricht im Fall zeigen, die ihn ausgelöst hat. „Kommunikation: minus zehn“ bei einem Fall mit vierzig Feed-Einträgen ist unbrauchbar.
- Dieselben Belege, die die Bewertung genutzt hat. Ein Reviewer, der einen Score prüft, sollte die Nachrichten sehen, aus denen der Score berechnet wurde, nicht eine Zusammenfassung davon.
- Ein Weg zum Widerspruch. Ein Agent muss einen Score anfechten können, und jemand muss sich die Begründung ansehen. Wenn das nicht geht, ist der Score ein Urteil.
- Gemessene Übereinstimmung, bevor er zählt. Lassen Sie den automatisierten Score einige Wochen lang parallel zu Ihren eigenen Reviewern auf denselben Fällen laufen und validieren Sie die Bewertung, bevor die Zahl an irgendetwas mit Konsequenzen geknüpft wird.
Kaizos Auto QA wendet Ihre eigenen Scorecard-Kriterien auf Fälle an und hält die Begründung an der Konversation fest, sodass sich ein angefochtener Abzug bis zu dem Austausch zurückverfolgen lässt, der ihn verursacht hat, statt aus dem Gedächtnis darüber zu streiten. Es läuft auf Service Cloud über die Salesforce-Integration, ausführlicher beschrieben unter Kaizo auf Salesforce, neben derselben Integration für Zendesk. Das ist wichtig, wenn Sie während einer laufenden Migration QA auf beiden Plattformen betreiben. Demo buchen.
Ein Rollout, der die erste Anfechtung übersteht
QA-Programme in Service Cloud scheitern an derselben Stelle: beim ersten Mal, wenn ein Agent einen Score ernsthaft anficht und das Programm keine Antwort hat. Planen Sie den Rollout so, dass die Antwort existiert, bevor die Anfechtung kommt.
| Phase | Was Sie tun | Erledigt, wenn |
|---|---|---|
| 1. Die Einheit definieren | Eine der drei Definitionen der Konversation wählen und schriftlich festhalten. Erfassen, was an einem geschlossenen Fall in Ihrer Org tatsächlich vorhanden ist | Ein Reviewer ohne Ausflüchte sagen kann, welche Datensätze dazugehören |
| 2. Kriterien Feldern zuordnen | Für jedes Kriterium den Beleg, die Prüfung und die erwartete Fehlerquelle benennen. Alles streichen, was sich nicht belegen lässt | Jedes Kriterium auf ein Feld oder einen Nachrichtentyp zeigt, den es gibt |
| 3. Den Bericht für die Grundgesamtheit bauen | Ein gespeicherter Bericht, der die prüfbare Menge definiert, mit Ausschlüssen für automatisch geschlossene Fälle und Fälle ohne Agent | Zwei Personen, die den Bericht ausführen, dieselbe Fallzahl erhalten |
| 4. Schattenbewertung und Kalibrierung | Drei Reviewer bewerten unabhängig dieselben fünfzehn Fälle, darunter mindestens drei mit Inhaberwechsel. Vergleichen und diskutieren | Sie die Uneinigkeitsrate Ihrer Reviewer kennen und sie sinkt |
| 5. Mit Widerspruchsweg veröffentlichen | Scorecard, Stichprobenmethode und Widerspruchsverfahren gemeinsam ankündigen. Ein Widerspruch ohne Weg ist eine Beschwerde | Agents das Verfahren nennen können, ohne nachzuschlagen |
| 6. Berichten, dann die Zuordnung erneut prüfen | Scores neben operativen Ergebnissen wie erneut geöffneten Fällen und Eskalationen berichten. Die Zuordnung jedes Quartal überprüfen | Die Bewegung des Scores etwas erklärt, das eine Führungskraft schon vermutet hat |
Einen Fall-Score so berichten, dass jemand handelt
Ein QA-Score, der nur in einem QA-Tool lebt, wird vom QA-Team gelesen. Damit sich der Aufwand lohnt, muss der Score neben den operativen Zahlen stehen, auf die die Supportleitung ohnehin schaut, und er muss so aufgeschlüsselt sein, dass er eine Maßnahme benennt.
Drei Schnitte leisten bei Service-Cloud-Daten den Großteil der Arbeit:
- Nach Falltyp oder Datensatztyp, nicht nur nach Agent. Qualität schwankt weit mehr mit der Art der Arbeit als mit der Person, die sie macht. Ein niedriger Durchschnitt bei einem Datensatztyp ist ein Prozess-, Wissens- oder Routingproblem und lässt sich zentral beheben.
- Nach Kriterium, über das ganze Team. Ein Kriterium, das breit verfehlt wird, ist fast nie ein Coaching-Problem. Es ist eine unklare Richtlinie, ein fehlender Wissensartikel oder ein schlecht formuliertes Kriterium.
- Score gegen die Quote erneut geöffneter und eskalierter Fälle. Das ist die Kontrolle der Scorecard selbst. Wenn Fälle mit hohem Score genauso oft wieder geöffnet werden wie Fälle mit niedrigem, misst die Scorecard etwas anderes als Qualität und muss neu gewichtet werden.
Diesen dritten Schnitt sollten Sie schützen. Er verhindert, dass ein QA-Programm zu einem Compliance-Ritual wird, das alle durchführen und niemand nutzt. Qualitätsscores mit dem operativen Bild zu verbinden, ist genau die Aufgabe einer Analyseansicht für den Support, und es ist zugleich der schnellste Weg, einer skeptischen Leitung zu zeigen, dass das QA-Programm etwas Reales misst.
Häufig gestellte Fragen
Enthält Salesforce Service Cloud eine QA-Bewertung ab Werk?
Service Cloud liefert Ihnen das Rohmaterial: den Falldatensatz, die damit verknüpften Nachrichten und Transkripte, den Feldverlauf und eine Reporting-Ebene über all dem. Eine gewichtete Scorecard, eine Prüf-Queue für Reviewer, Kalibrierung zwischen Reviewern und ein nachprüfbarer Widerspruchsverlauf gehören nicht zum Standard-Fallobjekt. Teams bauen entweder eine schlanke Version mit benutzerdefinierten Feldern und Berichten, die funktioniert, bis die Uneinigkeit der Reviewer zum Engpass wird, oder sie ergänzen ein QA-Tool, das Fälle liest. Prüfen Sie, was Ihre eigene Org bereits konfiguriert hat, bevor Sie das eine oder andere annehmen, denn die Anpassungen unterscheiden sich enorm.
Was sollten Sie an einem Salesforce-Fall bewerten?
Nur das, was der Fall belegt. In der Praxis sind das die von Agents verfassten Nachrichten, die Zeitstempel dieser Nachrichten und der Inhaberwechsel, die Feldwerte, mit denen der Fall geschlossen wurde, und die internen Notizen, wenn Ihre Definition der Konversation sie einschließt. Alles, worauf Sie im Datensatz nicht zeigen können, etwa was der Agent damals wusste oder ein als einzeilige Notiz erfasster Rückruf, gehört ins Coaching statt in einen Score.
Worin unterscheidet sich QA in Service Cloud von QA in Zendesk?
Die Philosophie der Scorecard ist dieselbe, die Mechanik nicht. Ein Zendesk-Ticket ist ein linearer Thread mit einem klaren Bearbeiter, die Einheit der Prüfung ist also offensichtlich. Ein Salesforce-Fall ist ein Datensatz mit verknüpften Nachrichten, Transkripten und Feed-Einträgen, die Einheit müssen Sie also selbst definieren. Die Autorschaft muss außerdem an einzelnen Nachrichten abgelesen werden statt am Inhaberfeld, und weil Datensatztypen und benutzerdefinierte Felder pro Org konfiguriert werden, lässt sich keine Scorecard unverändert zwischen zwei Salesforce-Orgs übertragen.
Wie ziehen Sie eine Stichprobe von Salesforce-Fällen für die QA-Prüfung?
Bauen Sie einen gespeicherten Bericht, der die Grundgesamtheit definiert: Filter auf Schließdatum, Datensatztyp oder Queue, Kanal, wo relevant, und Ausschluss von Fällen ohne von einem Agent verfasste Nachricht. Ziehen Sie dann zufällig innerhalb von Schichten, nach Agent und nach Falltyp, statt zufällig über den ganzen Monat, damit jeder Agent eine vergleichbare Zahl an Fällen beisteuert. Legen Sie die Stichprobe fest, bevor jemand einen Fall öffnet. Eine Liste zu prüfen, die Sie schon überflogen haben, ist keine Stichprobe.
Wer bekommt den QA-Score, wenn ein Fall den Inhaber wechselt?
Nicht automatisch der aktuelle Inhaber. Das ist die Voreinstellung, in die die meisten Programme verfallen, und die, die den größten Schaden anrichtet. Ordnen Sie jede bewertete Nachricht dem zu, der sie geschrieben hat. Bei einem Fall, den mehrere Personen bearbeitet haben, bewerten Sie entweder den eigenen Beitrag jedes Agents getrennt oder nehmen den Fall aus der Einzelbewertung heraus und nutzen ihn für die Prozessprüfung. Den letzten Inhaber für geerbte Arbeit zu bewerten, bringt Ihren stärksten Agents bei, Eskalationen zu meiden.
Können Sie E-Mail, Chat und Voice im selben Fall bewerten?
Ja, aber entscheiden Sie das Vorgehen vor dem Rollout, nicht während der ersten Anfechtung. Ein einziger gemischter Score über einen Fall mit einem E-Mail-Thread und einem Chat-Transkript ist schwer zu coachen, weil die Standards für beides wirklich verschieden sind. Jeden Kanalabschnitt getrennt zu bewerten und getrennt zu berichten, ist meist klarer. Wenn Voice beteiligt ist, prüfen Sie zuerst, ob in Ihrer Org tatsächlich Transkripte angehängt sind statt nur Aufzeichnungen, denn ein Kriterium, das vom Inhalt eines Anrufs abhängt, lässt sich ohne sie nicht durchsetzen.
