Eskalationsmanagement im technischen Support: So richten Sie einen Prozess ein, der tatsächlich funktioniert

Das Eskalationsmanagement ist der betrieblich bedeutendste – und am häufigsten unzureichend konzipierte – Prozess im technischen Support. Wenn es funktioniert, werden die Probleme der Nutzer effizient gelöst, erhalten die L2-Techniker vollständige und genaue Übergaben, und der Supportbetrieb läuft in dem Umfang und mit der Komplexität, für die er ausgelegt ist. Wenn es nicht funktioniert, verbringen die L2-Teams einen unverhältnismäßig großen Teil ihrer Zeit mit Problemen, die bereits auf der L1-Ebene hätten gelöst werden müssen; Techniker kontaktieren die Nutzer erneut, um Informationen einzuholen, die bereits beim ersten Mal hätten erfasst werden müssen; und Nutzer mit einem einfachen Problem warten am Ende tagelang auf eine Lösung, die eigentlich nur wenige Stunden hätte dauern sollen.

Dieser Leitfaden erläutert, wie ein effektives Eskalationsmanagement in der Praxis aussieht – wie Anfragen klassifiziert werden, welche Informationen eine Eskalation enthalten sollte, wie die Übergabe von L1 an L2 definiert wird und wie der Prozess im Laufe der Zeit überwacht und verbessert werden kann. Er wurde aus der Perspektive eines Teams verfasst, das den technischen First-Line-Support für Hardware- und Maschinenhersteller und Softwareanbieter verwaltet und täglich die Schnittstelle zwischen L1 und L2 im Eskalationsprozess betreut.

Was Eskalationsmanagement ist – und was es nicht ist

Das Eskalationsmanagement ist der strukturierte Prozess, durch den eine Supportanfrage von einer Ebene zur nächsten weitergeleitet wird – von L1 zu L2 oder von L2 zu L3 –, wobei der Kontext gewahrt bleibt, die Verantwortlichkeiten klar geregelt sind und der Nutzer durchgehend auf dem Laufenden gehalten wird.

Dies ist nicht dasselbe wie der Umgang mit schwierigen Kunden, die Bearbeitung von Beschwerden oder die Bewältigung von Notfällen – auch wenn all dies mit Eskalationen einhergehen kann. Dabei handelt es sich um Herausforderungen im Kundenmanagement. Das Eskalationsmanagement ist hingegen eine Herausforderung im Bereich der betrieblichen Gestaltung: Wie stellen Sie sicher, dass die richtigen Ansprechpartner zur richtigen Zeit mit den richtigen Informationen an die richtigen Personen weitergeleitet werden?

Eine schlecht gehandhabte Eskalation führt nicht nur zu Frustration beim Nutzer. Sie verschwendet Zeit der zweiten Support-Ebene, verursacht Nacharbeit und untergräbt das Vertrauen zwischen Ihren Support-Ebenen. Der Schaden ist operativer Natur und beschränkt sich nicht nur auf die Nutzererfahrung.

Die häufigsten Fehler beim Eskalationsmanagement

Bevor man einen besseren Eskalationsprozess entwirft, ist es hilfreich, genau zu verstehen, was bei einem schlecht konzipierten Prozess schiefläuft. Die Probleme treten unabhängig von der Organisation und der Art des Produkts immer wieder auf.

Zu früh – oder zu oft – eskalieren

Das offensichtlichste Versagen beim Eskalationsmanagement ist die übermäßige Eskalation: Anfragen, die die L2-Ebene erreichen, obwohl sie auf der L1-Ebene hätten gelöst werden können und sollen. Dies geschieht, wenn den L1-Mitarbeitern das Wissen, die Befugnis oder das Selbstvertrauen fehlt, um Anfragen eigenständig zu lösen. Eine übermäßige Eskalation überlastet die L2-Teams mit einem Arbeitsvolumen, für dessen Bewältigung sie nicht ausgelegt sind, verzögert die Lösung für Nutzer, deren Probleme eigentlich unkompliziert waren, und verschleiert die tatsächlichen Kompetenzlücken auf L1, die durch Schulungen und die Verbesserung der Wissensdatenbank behoben werden müssen.

Wenn Ihr L2-Team mehr als 20 % seiner Zeit mit Anfragen verbringt, die bereits auf L1-Ebene hätten gelöst werden können, liegt das Problem auf L1 – nicht auf L2. Beheben Sie zunächst die Mängel in der Wissensdatenbank und den Eskalationskriterien, bevor Sie die Kapazitäten auf L2-Ebene aufstocken.

Zu spät eskalieren – oder gar nicht

Ein weniger offensichtlicher, aber ebenso schädlicher Fehler ist die unzureichende Eskalation: Fälle, die auf Ebene L1 verbleiben, obwohl sie längst hätten weitergeleitet werden müssen. Ein L1-Mitarbeiter, der weiterhin versucht, ein Problem zu lösen, das seine Fähigkeiten übersteigt – sei es aus Unsicherheit darüber, wann eine Eskalation erforderlich ist, oder aus dem Unwillen, zuzugeben, dass er es nicht lösen kann –, verzögert die Lösung, frustriert den Nutzer und erschwert mitunter die Diagnose des Problems auf L2, indem er zusätzliche Schritte einführt, die den ursprünglichen Fehler verschleiern. Klare Eskalationskriterien beseitigen diesen Fehlermodus.

Unvollständige Übergaben

Der betrieblich kostspieligste Fehler bei der Eskalation ist die unvollständige Übergabe – eine Eskalation, die bei L2 eintrifft, ohne dass dem Techniker ausreichende Informationen zum Handeln vorliegen. Der L2-Techniker kontaktiert den Nutzer, um Informationen einzuholen, die der L1-Mitarbeiter eigentlich hätte erfassen müssen. Der Nutzer muss sein Problem erneut schildern. Die Lösung verzögert sich. Die Zeit des L2-Technikers wird durch die Informationsbeschaffung in Anspruch genommen, anstatt zur Problemlösung beizutragen. Hierbei handelt es sich um einen Fehler in der Prozessgestaltung, nicht um einen Qualitätsmangel des Mitarbeiters. Die Lösung ist eine strukturierte Eskalationsvorlage, die genau festlegt, welche Informationen vorliegen müssen, bevor eine Eskalation eingereicht wird.

Keine Kommunikation mit dem Benutzer während der Eskalation

Nutzer, deren Anfragen eskaliert wurden und die anschließend nicht mehr reagieren – keine Bestätigung, kein Zeitplan, keine Statusaktualisierung –, führen zu Folgeanfragen, die sowohl L1- als auch L2-Zeit in Anspruch nehmen. Ein Nutzer, der weiß, dass sein Anliegen eskaliert wurde, warum dies geschehen ist und wann er mit einer Antwort rechnen kann, ruft nicht erneut an. Ein Nutzer, der nichts gehört hat, tut dies hingegen. Kommunikationsprotokolle für die Eskalation sind ebenso wichtig wie die Eskalationskriterien – und sie sind oft das Erste, was vernachlässigt wird, wenn der Betrieb unter Druck steht.

So klassifizieren Sie Kontakte – die Grundlage für eine effektive Eskalation

Ein effektives Eskalationsmanagement beginnt mit einer einheitlichen Klassifizierung der Anfragen. Bevor eine Entscheidung über die Eskalation getroffen werden kann, muss die Anfrage nach Schweregrad eingestuft werden – denn der Schweregrad bestimmt den Eskalationspfad, den Zeitrahmen und das Kommunikationsprotokoll.

Ein einfaches vierstufiges Schweregradsmodell eignet sich für die meisten technischen Supportvorgänge:

Die in diesem Modell genannten konkreten Zeitrahmen dienen lediglich der Veranschaulichung – sie sollten mit jedem Kunden individuell auf der Grundlage seines Produkts, seiner Nutzer und seiner SLA-Verpflichtungen vereinbart werden. Entscheidend ist, dass die Klassifizierung dokumentiert ist, einheitlich angewendet wird und sowohl von den L1-Mitarbeitern als auch von den L2-Technikern verstanden wird. Ein Klassifizierungssystem, das nur im Kopf einer einzelnen Person existiert, ist kein Klassifizierungssystem.

Was jede Eskalation enthalten sollte

Die Qualität einer Eskalationsübergabe entscheidet darüber, ob L2 sofort handeln kann oder weitere Informationen einholen muss. Eine vollständige Eskalation sollte sieben Elemente enthalten – nicht mehr und nicht weniger.

1. 1. Kontaktübersicht

   Eine ein- oder zweisatzige Beschreibung dessen, was der Nutzer erlebt – in einfacher Sprache, ohne Fachjargon. Verfasst für einen Ingenieur, der diesen Kontakt zum ersten Mal sieht und die Situation innerhalb von dreißig Sekunden verstehen muss.

2. 2. Schweregradklassifizierung

   Die von L1 zugewiesene Schweregradstufe mit einer kurzen Begründung. Falls der L1-Mitarbeiter den Kontakt als „kritisch“ eingestuft hat, muss der Techniker verstehen, warum – was genau ihn kritisch macht –, damit er die Einstufung überprüfen und entsprechend priorisieren kann.

3. 3. Angaben zur Umgebung

   Produktversion, Betriebssystem, Gerätetyp, gegebenenfalls Browserversion, Integrationsumgebung. Die genauen Angaben hängen vom jeweiligen Produkt ab – sie sollten jedoch in der Eskalationsvorlage dokumentiert sein, damit die L1-Mitarbeiter genau wissen, welche Informationen sie vor einer Eskalation erfassen müssen.

4. 4. Schritte zur Reproduktion

   Bei Fehlern und technischen Störungen – die genauen Schritte, die der Benutzer vor dem Auftreten des Problems durchgeführt hat, sofern bekannt. „Es hat einfach nicht mehr funktioniert“ ist kein Reproduktionsablauf. „Der Benutzer exportierte in Version 4.2.1 einen Bericht im CSV-Format, als sich die Anwendung unerwartet schloss“ hingegen schon.

5. 5. Was L1 bereits versucht hat

   Die vom L1-Mitarbeiter durchgeführten Schritte zur Fehlerbehebung und deren Ergebnisse. Dadurch wird verhindert, dass der L2-Mitarbeiter dieselben Schritte wiederholt, was Zeit kostet und bei den Benutzern, die diese Schritte bereits durchlaufen haben, Frustration hervorruft.

6. 6. Benutzerkontext

   Seit wann der Benutzer von dem Problem betroffen ist, wie geschäftskritisch die betroffene Funktion für ihn ist und alle relevanten Hintergrundinformationen – frühere Kontaktaufnahmen wegen desselben Problems, frühere Lösungen, die nicht von Dauer waren, sowie bekannte Umgehungslösungen, die der Benutzer bereits ausprobiert hat.

7. 7. Die Nachricht wurde bereits gesendet

   Was dem Nutzer mitgeteilt wurde – welche Informationen der L1-Mitarbeiter bezüglich der nächsten Schritte, der voraussichtlichen Zeitrahmen und der Person, von der er als Nächstes hören wird, übermittelt hat. Der L2-Techniker muss wissen, welche Zusagen bereits gemacht wurden, damit er diesen nicht widerspricht.

Die Bearbeitung einer Eskalation mit sieben Schritten dauert bei L1-Mitarbeitern drei bis fünf Minuten. Dadurch sparen L2-Techniker dreißig Minuten an Nacharbeit. Die Rechnung ist ganz einfach.

Entwurf des Übergangs von L1 zu L2

Die Übergabe ist der Moment, in dem das operative Risiko bei einem technischen Supportvorgang am größten ist. Hier geht der Kontext verloren, die Verantwortlichkeiten verschwimmen und die Benutzererfahrung verschlechtert sich. Eine gut konzipierte Übergabe beseitigt Unklarheiten auf beiden Seiten des Vorgangs.

Verwenden Sie eine strukturierte Eskalationsvorlage

Die oben genannten sieben Elemente sollten in einer strukturierten Vorlage – einem Formular oder einem Ticket-Feldsatz – erfasst werden und nicht in Form einer Freitextnotiz. Freitext-Eskalationsnotizen sind in ihrer Vollständigkeit uneinheitlich, schwer zu überblicken und hängen von der Qualität des jeweiligen Mitarbeiters ab. Eine strukturierte Vorlage gewährleistet einheitliche und vollständige Übergaben, unabhängig davon, welcher L1-Mitarbeiter den Kontakt bearbeitet. Außerdem wird sofort ersichtlich, wenn Informationen fehlen – ein leeres Feld ist sichtbar; ein fehlender Absatz in einer Freitextnotiz hingegen nicht.

Legen Sie die Eskalationskriterien ausdrücklich fest

Die Bedingungen, die eine Eskalation von L1 auf L2 auslösen, sollten dokumentiert und zwischen den L1- und L2-Teams vereinbart werden. „Eskalieren Sie, wenn Sie das Problem nicht lösen können“ ist kein Kriterium – es handelt sich um eine Ermessensentscheidung, die zu uneinheitlichen Ergebnissen führt. „Eskalieren Sie, wenn das Problem nicht innerhalb von zwei Kontaktversuchen gelöst wird, wenn das Problem einen Systemzugriff erfordert, der über die L1-Berechtigungen hinausgeht, oder wenn der Kontakt der Definition der Schweregrade ‚Kritisch‘ oder ‚Hoch‘ entspricht“ – das ist ein Kriterium. Dokumentieren Sie es. Schulen Sie die L1-Mitarbeiter entsprechend. Überprüfen Sie es regelmäßig im Zuge der Weiterentwicklung des Produkts. Weitere Informationen dazu, wo L1 endet und L2 beginnt, finden Sie in unserem Leitfaden zu dem technischen First-Line-Support .

Legen Sie das Kommunikationsprotokoll fest

Zum Zeitpunkt der Eskalation sollten drei Dinge automatisch geschehen: Der Nutzer erhält eine Bestätigung, dass sein Anliegen eskaliert wurde, einschließlich eines realistischen Zeitrahmens für die Antwort durch die L2-Ebene; der L2-Techniker erhält die strukturierte Eskalation mit allen sieben Elementen; und die Beteiligung des L1-Mitarbeiters wird offiziell beendet – er wartet nicht mehr auf das Ticket in der Hoffnung, helfen zu können, sondern wird zum nächsten Kontakt weitergeleitet. Die Verantwortlichkeiten sind eindeutig. Der Nutzer weiß, an wen er sich wenden muss, falls er keine Rückmeldung erhalten hat. L2 weiß, dass die Verantwortung für den Kontakt nun bei ihm liegt.

Überwachen Sie die Eskalationsraten nach Kontaktart

Die Eskalationsrate – der Prozentsatz der L1-Anfragen, die an L2 eskaliert werden – ist eine der nützlichsten betrieblichen Kennzahlen im technischen Support. Erfassen Sie diese nach Kontaktart und nicht nur als Gesamtwert. Eine hohe Eskalationsrate bei einer bestimmten Kontaktart ist ein Hinweis darauf, dass entweder die Wissensdatenbank für dieses Problem unvollständig ist, die Eskalationskriterien zu weit gefasst sind oder das Produkt ein wiederkehrendes Problem aufweist, das an der Quelle behoben werden muss. Eine aggregierte Eskalationsrate verschleiert diese Hinweise. Dies steht in direktem Zusammenhang mit der Erstlösungsquote – die Verbesserung der L1-Kompetenz reduziert das Eskalationsvolumen und verbessert die Ergebnisse für die Nutzer.

Häufig gestellte Fragen zum Eskalationsmanagement