Ein Anruf geht beim Service Desk ein und der Vorfall wird sofort gelöst. Ist dies immer ein Zeichen für Erfolg? Die Erstlösungsquote (First Call Resolution, auch „First Contact Resolution“ oder „FCR“) ist seit langem eine entscheidende Kennzahl zur Beurteilung der Leistungsfähigkeit eines Service Desks oder Call Centers. Es wird allgemein angenommen, dass eine hohe Erstlösungsquote (FCR) gut ist – je höher, desto besser!
FCR hat wohl einen signifikanteren Einfluss auf die Kundenzufriedenheit als jede andere Call Center-Metrik. Zahlreiche Studien haben immer wieder gezeigt, dass eine hohe Korrelation zwischen FCR und Kundenzufriedenheit besteht (d. h. weniger Verzögerungen, Rückrufe und Weiterleitungen = weniger Kundenbeschwerden). Mitarbeiter der Stufe 1 werden tendenziell schlechter bezahlt als qualifiziertere Support-Teams der 2ten und 3ten Stufe, sodass eine Verbesserung der FCR auch dazu neigt, die Betriebskosten zu senken (d. h. weniger Eskalationen = weniger Kosten).
Aus all diesen Gründen ist es wichtig, die FCR-Metriken korrekt zu erfassen. Es gibt jedoch drei (3) Hauptgründe, warum Ihre FCR-Daten Ihnen ein falsches Bild von Ihrer Leistung vermitteln könnten.
Grund Nr. 1: Viele Organisationen definieren und dokumentieren die FCR-Kriterien nicht klar. Selbst eine klar definierte FCR-Metrik kann immer noch auf eine Weise berechnet werden, die für die Organisation nicht sinnvoll ist.
Bei einer so wichtigen Metrik würde man meinen, es gäbe eine klare Definition, wie FCR zu berechnen ist. Sie werden jedoch überrascht sein, dass es keinen Industriestandard für FCR gibt. Nicht einmal die ITIL-Bücher liefern eine definitive Definition für FCR.
Daher definieren verschiedene Organisationen diesen Key Performance Indicator (KPI) auf unterschiedliche Weise. Verschiedene FCR-Metrik-Überlegungen umfassen:
- Umfasst FCR sowohl Incidents als auch Service Requests? Oder werden diese separat berechnet?
- Was ist, wenn das Problem ohne Rückruf gelöst wird, aber eine Eskalation oder Weiterleitung an einen anderen Agenten erforderlich war?
- Beinhaltet die FCR-Berechnung „Call Abandonment“ (d. h. der Kunde legt auf, nachdem er zu lange gewartet hat, bevor er mit einem Agenten sprechen konnte)?
Viele andere Faktoren könnten berücksichtigt werden, bevor Sie entscheiden, wie Ihre Organisation die FCR misst. Sie müssen wissen, was Sie messen und warum Sie es messen. Wie können Sie gute Managemententscheidungen treffen, wenn Sie nicht wirklich verstehen, was Ihre Daten Ihnen sagen?
Bevor wir uns ins Detail stürzen, lassen Sie uns zunächst unsere Begriffe definieren. Die Erstlösungsquote wird typischerweise so beschrieben: „Der Prozentsatz der eingehenden Anrufe, die Vorfälle sind und beim ersten Kontakt gelöst werden können, während der Kunde noch am Telefon ist, ohne dass der Anruf an jemand anderen weitergeleitet werden muss (d. h. ohne die Notwendigkeit einer Eskalation, Anrufweiterleitung oder eines Rückrufs).“
Grund Nr. 2: Selbst wenn Sie die FCR-Kriterien gut definieren und Ihre Daten verstehen, kann FCR eine irreführende KPI-Metrik sein. FCR ist im Allgemeinen hoch, wenn ein Service Desk viele wiederholte Anrufe für Probleme bearbeitet, bei denen der Vorfall bekannt ist und eine bekannte Umgehungslösung existiert. Eine hohe FCR-Rate aus diesem Grund kann jedoch ein Symptom für ein schlechtes proaktives Problem Management sein. Eine hohe FCR-Rate kann darauf hindeuten, dass die wahre „Grundursache“ für wiederkehrende Probleme nicht ausreichend ermittelt und bekannte Fehler nicht angemessen behandelt werden.
Der wahre Wert jeder IT-Abteilung sollte an ihrer Fähigkeit gemessen werden, wiederholte Anrufe zu eliminieren, indem die Grundursache in der IT-Umgebung identifiziert und beseitigt wird (d. h. bekannte Fehler behoben werden). Eine niedrigere FCR-Rate kann tatsächlich ein Hinweis darauf sein, dass das Problem Management-Team seine Arbeit erfolgreich erledigt, da nur neue Probleme mit unbekannten Ursachen an den Service Desk gemeldet werden.
Grund Nr. 3: Es stimmt, dass ein effektives reaktives Problem Management Ihre FCR verbessern wird. Aber das ist nur dann gut, wenn Sie nach temporären „Pflaster“-Lösungen für Ihre Probleme suchen (d. h. Umgehungslösungen). Auf diese Weise erkennt der Service Desk den Anruf als einen weiteren wiederholten Vorfall, sucht die akzeptierte Umgehungslösung und wendet dann das entsprechende Verfahren für den Kunden an – ein Punkt für die FCR-Metriken! Das eigentliche Ziel sollte jedoch sein, die Grundursache zu finden und zu beheben, um wiederkehrende Fehler/Vorfälle und alle zukünftigen damit verbundenen Anrufe zu eliminieren.
Der konsequente Einsatz einer effektiven Ursachenanalyse (RCA) im Problem Management hat das Potenzial, einen echten Geschäftswert zu liefern. Die Beseitigung kleiner, lästiger Probleme, die regelmäßige Service Desk-Anrufe auslösen, kann einen großen kumulativen Einfluss auf die Produktivität haben.
Zusammenfassend lässt sich sagen, dass FCR eine sehr irreführende Metrik sein kann, wenn Sie nicht verstehen, was hinter den Daten steckt. Erstlösungsquoten sollten analytisch betrachtet werden. Eine hohe FCR kann ein Zeichen dafür sein, dass Ihre Organisation über exzellente Incident- und/oder Problem Management-Prozesse mit qualifizierten und sachkundigen IT-Mitarbeitern verfügt, die fortschrittliche Automatisierungs- und Wissensmanagement-Tools einsetzen. Eine hohe FCR könnte jedoch auch ein Hinweis darauf sein, dass Ihr proaktiver Problem Management-Prozess verbessert werden muss. Umgekehrt muss auch eine niedrige FCR genauer betrachtet werden. Eine niedrige FCR-Prozentsatz ist nicht unbedingt ein Indikator für einen ineffektiven Service Desk. Eine niedrige FCR kann auf ein gutes proaktives Problem Management hindeuten.
Das wichtigste Maß für die Erstlösungsquote ist die Wahrnehmung des Kunden, ob sein Problem beim ersten Versuch gelöst wurde oder nicht. Eine der besten Möglichkeiten, dies herauszufinden, ist, ihn direkt mit einer automatisierten E-Mail und/oder Telefonumfrage zu befragen. Oder noch besser: Rufen Sie höflich persönlich an und hören Sie dann, was Ihre Kunden Ihnen sagen.
