Ablaufdiagramm Eskalationsprozess im Kundenservice
Swimlane-Ablaufdiagramm für die Eskalation im Kundenservice: Lösungsversuch im 1st Level, dokumentierte Übergabe an den 2nd Level, Schweregrad- und SLA-Bewertung, Eskalation an die Entwicklung.
So funktioniert es
Benennen Sie die Bahnen nach Ihren echten Rollen
Ersetzen Sie Kunde, 1st-Level-Support, 2nd Level / Spezialist, Supportleitung und Entwicklung durch die Funktionen, die es bei Ihnen gibt. Kleine Teams führen den 2nd Level meist mit der Entwicklung zusammen; Teams mit festen Kundenbetreuern teilen die Bahn Supportleitung häufig in eine Dienstleitung und einen Kundenbetreuer. Behalten Sie die Kundenbahn, auch wenn sie nur zwei Knoten enthält — das sind die Punkte, an denen der Kunde und nicht Sie den Ablauf steuert.
Legen Sie fest, was der 1st Level tun darf
„Im 1st Level gelöst?“ braucht einen Umfang und ein Zeitfenster: auf welche Systeme eine Servicekraft zugreifen darf, welche Eingriffe erlaubt sind und wie lange ein Lösungsversuch läuft, bevor der Fall weitergeht. Ohne beides schwankt das Eskalationsvolumen mit der Schicht. Halten Sie ausdrücklich fest, dass eine Eskalation innerhalb des Zeitfensters das richtige Ergebnis ist und kein Versagen — sonst halten Ihre Leute Fälle fest, um ihre Kennzahlen zu schützen.
Legen Sie den Inhalt des Übergabeprotokolls fest
Entscheiden Sie, was „Übergabeprotokoll erfassen“ enthalten muss, und machen Sie daraus eine Vorlage in Ihrem Helpdesk: betroffener Kunde und Umgebung, Schritte zur Reproduktion, was bereits versucht und ausgeschlossen wurde, die Auswirkung beim Kunden und was dem Kunden bisher gesagt wurde. Eine aus einem Chatverlauf kopierte Übergabe ist der mit Abstand häufigste Grund dafür, dass ein Spezialist die erste Arbeitsstunde wiederholt.
Formulieren Sie objektive Auslöser für den kritischen Zweig
„Kritisch oder Schlüsselkunde?“ darf nicht davon abhängen, wie laut der Kunde geschrieben hat. Nutzen Sie prüfbare Bedingungen: ein blockierter geschäftskritischer Ablauf, ein namentlich benannter strategischer Kunde, ein gefährdetes vertragliches Reaktionsziel oder ein bereits einmal wiedereröffneter Fall. Benennen Sie je Auslöser, wer informiert wird, und halten Sie fest, dass die Benachrichtigung allein die Warteschlange nicht neu priorisiert — sonst wird jeder Fall kritisch.
Entscheiden Sie, was passiert, wenn die Entwicklung noch nicht liefern kann
Sobald ein Produktfehler angenommen ist, läuft er auf der Release-Uhr der Entwicklung, und die tickt langsamer als die Support-Uhr. Einigen Sie sich darauf, wer in dieser Zeit die Kundenbeziehung verantwortet, in welchem Takt Updates hinausgehen — auch wenn es nichts Neues gibt — und ob Sie sich auf ein Zielrelease statt auf ein Datum festlegen. Der Zweig „Noch nicht“ existiert, damit der Workaround eine ausdrückliche Absprache mit dem Kunden ist und kein Schweigen.
Vereinbaren Sie die Wiedereröffnungsregel und veröffentlichen Sie eine versionierte Fassung
Diese Vorlage leitet eine gescheiterte Bestätigung zurück über den Übergabeschritt, sodass ein wiedereröffneter Fall erneut dokumentiert und neu bewertet wird, statt in einer Warteschlange zu landen. Ändern Sie das, wenn Wiedereröffnungen bei Ihnen direkt an den letzten Bearbeiter zurückgehen sollen. Gehen Sie das Diagramm anschließend je Bahn durch, korrigieren Sie die Schritte, die Ihre Leute tatsächlich ausführen, und veröffentlichen Sie es mit einer Freigabe als gültige Fassung, damit später nachvollziehbar bleibt, welche Revision galt.
Häufig gestellte Fragen
Was ist ein Eskalationsprozess im Kundenservice?
Es ist der dokumentierte Weg, den ein Servicefall nimmt, sobald der 1st Level ihn nicht lösen kann. Er umfasst nicht den gesamten Ticket-Lebenszyklus, sondern genau den Teil, der an der Grenze der First-Level-Fähigkeit beginnt: die Entscheidung zu eskalieren, die Übergabe an einen Spezialisten, die erneute Bewertung von Schweregrad und SLA-Auswirkung — der Fall wird ja nun länger dauern —, die Untersuchung selbst sowie Bestätigung und Nachbereitung, die ihn schließen. Der Wert liegt nicht in den einzelnen Schritten, die die meisten Teams ohnehin ausführen, sondern in der Einigung darüber, wer den Fall an welcher Stelle verantwortet und was aufgeschrieben sein muss, bevor er den Besitzer wechselt.
Wann sollte ein Fall vom 1st Level an den 2nd Level eskaliert werden?
Nutzen Sie Bedingungen, die eine Servicekraft prüfen kann, kein Ermessen. Drei decken die meisten Fälle ab: Der Person fehlen die Berechtigungen oder Werkzeuge, die die Diagnose verlangt; das Symptom liegt außerhalb des dokumentierten First-Level-Umfangs; oder das Zeitfenster für den Lösungsversuch ist ohne Behebung abgelaufen. Ein vierter Auslöser ist bewusst getrennt: Der Fall braucht eine Entscheidung, die nur jemand anderes treffen kann, etwa eine Gutschrift oder ein vertragliches Entgegenkommen. Kein Auslöser für sich genommen ist die Bitte des Kunden zu eskalieren — sonst wird die Level-Zuordnung zur Verhandlungssache. Bearbeiten Sie diese Bitte stattdessen über den Benachrichtigungszweig.
Was ist der Unterschied zwischen funktionaler und hierarchischer Eskalation?
Funktionale Eskalation verschiebt einen Fall seitwärts zu jemandem mit mehr Fachwissen, etwa vom 1st Level an einen Spezialisten. Hierarchische Eskalation verschiebt ihn nach oben zu jemandem mit mehr Befugnis oder Überblick, etwa an Supportleitung und Kundenbetreuer. Sie lösen unterschiedliche Probleme und stehen in diesem Diagramm als getrennte Zweige: Der Eskalationszweig von „Im 1st Level gelöst?“ ist funktional, der kritische Zweig von „Kritisch oder Schlüsselkunde?“ ist hierarchisch. Der typische Fehler besteht darin, das eine zu tun und anzunehmen, es decke das andere mit ab — dann arbeitet ein Spezialist still an einem Fall, von dem der Kundenbetreuer zuerst vom Kunden erfährt.
Worin unterscheidet sich das vom Incident Management?
Eskalation bringt den Fall eines einzelnen Kunden zu jemandem, der ihn besser lösen kann. Incident Management stellt einen Service für alle wieder her, die von einer einzelnen Störung betroffen sind. Auslöser, Uhr und Erfolgsmaßstab sind jeweils andere: Ein eskalierter Fall wird daran gemessen, ob dieser Kunde eine bestätigte Lösung hat, ein Incident daran, wie schnell der Service wieder läuft. Zeigen mehrere eskalierte Fälle auf dieselbe Störung, übernimmt der Incident-Prozess, die Fälle werden damit verknüpft und schließen, wenn der Service wiederhergestellt ist und jeder Kunde bestätigt hat. Genau diese Trennung verhindert, dass ein Service Desk einen Ausfall als fünfzig parallele Untersuchungen führt.
Wer verantwortet den Fall nach der Eskalation, und was gehört in die Übergabe?
Die Verantwortung für die Untersuchung geht an den Spezialisten, die Verantwortung für die Kundenbeziehung bleibt in der Regel bei der ursprünglichen Servicekraft — deshalb kehrt das Diagramm für „Lösung mit dem Kunden bestätigen“ in die Bahn 1st-Level-Support zurück. Legen Sie diese Teilung ausdrücklich fest, denn ein Fall, in dem beide Seiten annehmen, die andere informiere den Kunden, ist die häufigste Ursache für Funkstille. Das Übergabeprotokoll sollte betroffenen Kunden und Umgebung, Schritte zur Reproduktion, was versucht und ausgeschlossen wurde, die Auswirkung beim Kunden und den bisherigen Informationsstand des Kunden tragen. Halten Sie es als einen Datensatz statt als Verlauf, damit ein wiedereröffneter Fall beim erneuten Durchlauf zu einer einzigen Historie beiträgt.