Ablaufdiagramm Eskalationsprozess im Kundenservice

Was ist ablaufdiagramm eskalationsprozess im kundenservice?

Eskalation ist der Teil des Kundenservice, den die meisten Teams aus dem Bauch heraus fahren. Eine Servicekraft stößt an die Grenze dessen, was sie tun darf, und der Fall wandert entweder seitwärts zu jemandem mit mehr Fachwissen oder nach oben zu jemandem mit mehr Befugnis. ITIL nennt diese beiden Bewegungen funktionale und hierarchische Eskalation, und sie sind nicht austauschbar: Einen Fall an einen Spezialisten zu geben, sagt dem Kundenbetreuer nichts, und die Supportleitung zu informieren, diagnostiziert keinen Fehler. Dieses Diagramm zeichnet beide Wege als getrennte Zweige, damit ein Team festlegen kann, wer wann was erfährt.

Ebenso wichtig ist, was dieser Prozess nicht ist. Er ist nicht der gesamte Ticket-Lebenszyklus: Fälle, die beim Erstkontakt gelöst werden, laufen gar nicht erst hinein, sondern gehen im Diagramm direkt zur Bestätigung durch den Kunden. Er ist kein Incident Management. Das übernimmt, sobald eine einzelne Störung viele Kunden gleichzeitig trifft und das Ziel nicht mehr der Abschluss eines Falls, sondern die Wiederherstellung eines Service ist. Er ist keine Fehler-Triage: Sobald die Entwicklung einen reproduzierbaren Produktfehler annimmt, läuft dieser Fehler im Release-Prozess auf seiner eigenen Uhr weiter, während der Servicefall gegenüber dem Kunden offen bleibt. Und er ist kein Beschwerdeverfahren. Dorthin gehört ein Kunde, der mit der Behandlung unzufrieden ist und nicht mit einem technischen Fehler.

Die hier abgebildete Fassung läuft über fünf Bahnen: Kunde, 1st-Level-Support, 2nd Level / Spezialist, Supportleitung und Entwicklung. Zwei Verzweigungen tragen den größten Teil der Last. „Im 1st Level gelöst?“ entscheidet überhaupt erst darüber, ob eskaliert wird, und dieser Schritt bleibt am häufigsten dem persönlichen Ermessen überlassen. Genau deshalb wird derselbe Fall von der einen Person nach zehn Minuten weitergegeben und von der nächsten drei Tage lang gehalten. „Kritisch oder Schlüsselkunde?“ entscheidet, ob Supportleitung und Kundenbetreuer von einem Fall erfahren, solange er noch offen ist, oder erst, nachdem der Kunde sich bei ihnen gemeldet hat. Alles, was den 1st Level verlässt, passiert ein einziges dokumentiertes Übergabeprotokoll (auch wiedereröffnete Fälle), damit der aufnehmende Spezialist sieht, was bereits versucht und ausgeschlossen wurde.

Was dieses Flussdiagramm abdeckt

In dieser Vorlage

• Fünf Swimlanes mit benannter Verantwortung für jeden Schritt (Kunde, 1st-Level-Support, 2nd Level / Spezialist, Supportleitung und Entwicklung) über fünf Phasen von Erfassung und Triage bis zu Lösung und Nachbereitung.
• Die Arbeit im 1st Level, bevor überhaupt über eine Eskalation nachgedacht wird: „Fall erfassen, Auswirkung festhalten“, „Gegen bekannte Fehler prüfen“ und „Lösung im 1st Level versuchen“. So fällt die Eskalationsentscheidung gegen einen dokumentierten Versuch und nicht gegen ein Gefühl.
• Das Eskalationstor selbst: „Im 1st Level gelöst?“ schickt den Fall entweder weiter zur Bestätigung durch den Kunden oder in „Übergabeprotokoll erfassen“, den einen Übergabedatensatz, den jeder eskalierte und jeder wiedereröffnete Fall durchläuft.
• Die Neubewertung bei der Übergabe: Der 2nd Level führt „Schweregrad und SLA bewerten“ aus, danach informiert der Zweig „Kritisch oder Schlüsselkunde?“ Supportleitung und Kundenbetreuer, während die Untersuchung weiterläuft, und nicht erst, nachdem der Kunde selbst eskaliert hat.
• Der Weg in die Entwicklung: „Produktfehler bestätigt?“ trennt Konfigurationsprobleme von echten Fehlern, gibt Fehler zum Reproduzieren und Erfassen an die Entwicklung und teilt „Fix in diesem Release verfügbar?“ in einen angewendeten Fix oder einen mit dem Kunden abgestimmten Workaround auf.
• Bestätigung und Nachbereitung: „Kunde bestätigt die Lösung?“ schickt einen weiterhin gestörten Fall zurück zum Übergabeschritt, statt ihn zu schließen, und einen bestätigten Fall über „Eskalation nachbereiten“ und den Known-Error-Artikel in den Abschluss.

Wann Sie diese Vorlage verwenden sollten

• Eskalationen laufen per Direktnachricht oder über den kurzen Weg zum Schreibtisch nebenan, und niemand kann sagen, wer einen Fall verantwortet, sobald er den 1st Level verlassen hat.
• Sie legen die Level-Definitionen neu fest und möchten die Grenze zwischen 1st und 2nd Level als Entscheidung mit Kriterien formuliert haben statt als zwei Stellenbeschreibungen.
• Kunden erfahren von schwerwiegenden Fällen früher als Ihre Supportleitung oder der zuständige Kundenbetreuer.
• Sie konfigurieren Eskalationsregeln, Warteschlangen, Schweregradfelder und SLA-Timer in einem Helpdesk-Werkzeug und wollen den Prozess abgestimmt haben, bevor das Werkzeug versehentlich einen eigenen festlegt.
• Eskalierte Fälle dauern deutlich länger als vergleichbare Fälle im 1st Level, und Sie müssen sehen, in welcher Übergabe die zusätzliche Zeit tatsächlich liegt.

So funktioniert es

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.