Eskalation im Kundensupport: Ablaufdiagramm (Entscheidungsbaum)
Ablaufdiagramm zur Eskalation im Kundensupport: ein Entscheidungsbaum aus acht Prüfungen, der einen Fall an First Level, 2nd Level, Entwicklung, Account Manager oder Bereitschaftsleitung leitet.
So funktioniert es
Benennen Sie die vier Entscheider
Ersetzen Sie First-Level-Agent, Support-Teamleitung, Account Manager und Bereitschaftsleitung durch die Rollen, die es bei Ihnen gibt. Kleine Teams führen den Account Manager häufig mit der Teamleitung zusammen; Organisationen mit Rufbereitschaft halten die Bereitschaftsleitung getrennt, weil diese Rolle über einen Dienstplan wechselt. Jede Bahn muss eine erreichbare Person sein, die zur Entscheidung befugt ist, und kein Abteilungsname.
Schreiben Sie auf, was First-Level-Umfang bedeutet
„Im Umfang des First Level?“ entscheidet darüber, wie viel Ihres Volumens nie eskaliert, und verdient deshalb eine schriftliche Definition. Fassen Sie den Umfang nach Fähigkeit statt nach Aufwand: ein veröffentlichter Artikel, eine dokumentierte Konfigurationsänderung oder eine Standardaktion am Kundenkonto liegen im Umfang; alles, was Code, Zugriff auf Produktivdaten oder ein vertragliches Zugeständnis verlangt, liegt per Definition außerhalb — so willig der Agent auch sein mag.
Setzen Sie den SLA-Auslöser vor die Frist
Entscheiden Sie, welcher Anteil der verbleibenden Reaktions- oder Lösungszeit „SLA-Ziel gefährdet?“ auslöst, und vereinbaren Sie ihn vorab, damit das Werkzeug ihn automatisch feuern kann. Der ganze Wert des Zweigs liegt darin, dass er läuft, solange das Ziel noch erreichbar ist. Ein Auslöser genau auf der Frist teilt Ihnen nur mit, dass die Zusage bereits gerissen wurde.
Legen Sie die Liste geschützter Kunden vorab fest
„Strategischer oder geschützter Kunde?“ muss in Sekunden aus dem CRM beantwortbar sein. Pflegen Sie eine ausdrückliche Liste und halten Sie fest, was einen Kunden schützt: benannter strategischer Status oder vertraglich zugesagte Reaktions- und Lösungszeiten. Diese Frage von Fall zu Fall zu entscheiden ist genau das, was dem lautesten Kunden Vorrang verschafft statt dem wichtigsten.
Stimmen Sie die Risikoauslöser mit der Rechtsabteilung ab
„Reputations- oder Rechtsrisiko?“ ist der Zweig, der jede andere Prüfung aussticht, seine Kriterien sollten deshalb außerhalb des Supports freigegeben werden: offengelegte personenbezogene Daten, eine beteiligte Aufsichtsbehörde oder Revision, ein Sicherheitsrisiko, ein öffentlicher Beitrag oder eine Presseanfrage, oder eine drohende Vertragsstrafe. Halten Sie die Liste kurz genug, um sie unter Druck zu erinnern, und lassen Sie jeden einzelnen Auslöser genügen.
Klären Sie bestätigten Produktfehler und akzeptablen Workaround
Setzen Sie eine Nachweisschwelle für „Bestätigter Produktfehler?“, etwa reproduziert auf einer unterstützten Version mit Schritten, denen ein anderer Entwickler folgen kann — nicht reproduzierte Meldungen gehen dann zur Diagnose an den 2nd Level statt an die Entwicklung. Entscheiden Sie danach, wer den Workaround als akzeptabel beurteilt. Liegt dieses Urteil allein beim Support, wird das Ergebnis „Als Fehler erfasst, nicht eskaliert“ von Kunden bestritten, die ihm nie zugestimmt haben.
Häufig gestellte Fragen
Worin unterscheidet sich das von einem Prozessdiagramm für die Support-Eskalation?
Ein Prozessdiagramm ist eine Abfolge: Ticket erfassen, triagieren, bearbeiten, lösen, schließen — mit Bahnen, die zeigen, wer jeden Schritt ausführt. Dieses Diagramm ist ein Entscheidungsbaum, sein Rückgrat ist also eine Kette von Fragen statt einer Kette von Aufgaben, und seine Zweige enden in fünf verschiedenen benannten Ergebnissen, statt in einem gemeinsamen Abschlussschritt zusammenzulaufen. Nutzen Sie die Prozesslandkarte, um den gesamten Lebenszyklus eines Falls zu sehen, und diesen Baum an dem einen Punkt darin, an dem jemand einen Weg wählen muss. Beide ergänzen sich: Das Ablaufdiagramm zum Incident-Management zeigt, wo die Eskalationsentscheidung sitzt, und dieses Diagramm zeigt, wie man sie trifft.
Wann sollte ein Supportfall eskaliert werden?
Wenn eine von wenigen schriftlich festgelegten Prüfungen mit Ja beantwortet wird — nicht, wenn der Fall einfach lange offen ist. Fünf der acht Prüfungen in diesem Diagramm entscheiden, ob überhaupt eskaliert wird: Der Fall liegt außerhalb der First-Level-Fähigkeit, keine dokumentierte Lösung behebt ihn, das SLA-Ziel ist gefährdet, der Kunde ist strategisch oder vertraglich geschützt, oder es besteht ein Reputations- oder Rechtsrisiko. Die übrigen drei entscheiden, wohin er geht. Verstrichene Zeit ist ein nützlicher Auslöser, um einen Fall zu überprüfen, aber ein schlechter, um ihn allein deswegen zu eskalieren — sie verschiebt Arbeit, ohne dem Fall eine Fähigkeit hinzuzufügen, die er tatsächlich gebraucht hätte.
Was ist der Unterschied zwischen einer Eskalation an den 2nd Level und einer an eine Führungskraft?
Sie lösen verschiedene Probleme, und ITIL trennt sie als funktionale und hierarchische Eskalation. Funktionale Eskalation gibt einen Fall an Personen mit mehr Spezialwissen oder tieferem Systemzugriff — dafür stehen hier „An den 2nd-Level-Support eskaliert“ und „Als Fehler an die Entwicklung eskaliert“. Hierarchische Eskalation zieht jemanden mit mehr Befugnis hinzu, um Kundenerwartungen neu zu setzen, eine Ausnahme zu genehmigen oder Ressourcen zuzusagen — dafür stehen die Ergebnisse beim Account Manager und bei der Bereitschaftsleitung. Ein Fall kann beides brauchen. Ihn die Führungslinie hinaufzuschicken, wenn er eigentlich einen Spezialisten braucht, kostet Führungszeit und bewegt das Ticket nicht.
Muss jeder bestätigte Produktfehler an die Entwicklung eskaliert werden?
Nein — jeden Fehler als Eskalation zu behandeln ist genau der Weg, auf dem Eskalation ihre Bedeutung verliert. Dieses Diagramm verzweigt bei „Workaround verfügbar?“. Ohne akzeptablen Workaround ist der Kunde blockiert, der Fall endet also bei „Als Fehler an die Entwicklung eskaliert“ und trägt betriebsrelevante Priorität. Mit Workaround gibt der Agent ihn heraus, und der Fall endet bei „Als Fehler erfasst, nicht eskaliert“: Der Bug erreicht die Entwicklung weiterhin über die normale Fehleraufnahme und Priorisierung, er unterbricht nur niemanden. Dieses zweite Ergebnis ist absichtlich ein Abbruch-Endpunkt, denn die Entscheidung, nicht zu eskalieren, ist ein legitimes Ergebnis der Bewertung und sollte als solches dokumentiert werden.
Wer darf eine Eskalation ablehnen?
Wer die Prüfung verantwortet, die nicht bestanden wurde — deshalb sind die Bahnen in diesem Diagramm Entscheidungsbefugnisse und keine Abteilungen. Die Teamleitung kann einen Fall zurückweisen, der die Prüfungen zu Risiko, SLA und Produktfehler nicht auslöst, und ihn an den First Level zurückgeben. Der Account Manager und nicht der Support entscheidet, ob ein Kunde geschützt ist. Die Bereitschaftsleitung entscheidet, ob ein Kunde kritisch ist, und wird erst gefragt, wenn das Risiko bereits festgestellt wurde — so bleibt diese Rolle echten Führungslagen vorbehalten. Ohne dokumentierten Grund abgelehnte Eskalationen sind genau die, die zurückkommen; halten Sie also am Fall fest, welche Prüfung nicht bestanden wurde.