Eskalation im Kundensupport: Ablaufdiagramm (Entscheidungsbaum)

Was ist eskalation im kundensupport: ablaufdiagramm (entscheidungsbaum)?

Diese Seite ist ein Entscheidungsbaum, keine Prozesslandkarte. Eine Prozesslandkarte beantwortet, was als Nächstes passiert und wer es tut: vom erfassten Ticket bis zum Abschluss. Ein Entscheidungsbaum beantwortet eine engere und weit umstrittenere Frage, die darin steckt: Bleibt der Fall, der gerade vorliegt, im First Level, und wenn nicht, wer übernimmt ihn? Für den durchgängigen Ablauf mit Erfassung, Priorisierung, Behandlung von Großstörungen und Abschluss nutzen Sie das Ablaufdiagramm zum Incident-Management-Prozess. Geht es um Unzufriedenheit mit der Leistung statt um einen Fehler darin, nutzen Sie das Ablaufdiagramm zum Reklamationsprozess. Dieses Diagramm nutzen Sie, wenn die Diskussion um die Zuweisung selbst geht.

Eskalation läuft in zwei entgegengesetzte Richtungen schief, und beide sind teuer. Wer zu bereitwillig eskaliert, macht aus dem 2nd Level eine zweite Warteschlange für Fälle, die der First Level hätte schließen können. Das treibt die Kosten je Ticket und verlängert die Wartezeit für die Fälle, die wirklich Spezialwissen brauchen. Wer zu selten eskaliert, lässt einen vertraglich geschützten Kunden von seinen eigenen Anwendern erfahren, dass eine Zusage gerissen wurde. Keines der beiden Muster löst sich durch mehr Kontrolle. Es löst sich durch schriftliche Prüfungen (hier acht), von denen jede aus dem Ticket und dem Kundendatensatz heraus beantwortbar ist und nicht aus dem Gefühl im Gespräch.

Die Bahnen benennen Entscheidungsbefugnisse, keine Abteilungen. Der First-Level-Agent entscheidet über den Umfang und darüber, ob eine dokumentierte Lösung tatsächlich greift. Die Support-Teamleitung verantwortet die Prüfungen zu Risiko, SLA und Produktfehler. Der Account Manager beantwortet, ob ein Kunde strategisch oder vertraglich geschützt ist. Die Bereitschaftsleitung beantwortet eine einzige Frage (ob ein kritischer Kunde betroffen ist) und das erst, wenn das Risiko bereits festgestellt wurde. Diese Reihenfolge sorgt dafür, dass die höchste Befugnis gewinnt: Ein Fall mit rechtlichem Risiko kann sich nicht still auf einen Entwicklungs-Backlog abmelden.

Was dieses Flussdiagramm abdeckt

In dieser Vorlage

• Ein First-Level-Tor vor jeder Eskalationsüberlegung: „Im Umfang des First Level?“ und „Dokumentierte Lösung behebt es?“ müssen beide mit Ja beantwortet werden, um das Ergebnis „Im First Level gelöst“ zu erreichen. Jedes Nein führt zu „Eskalationsprüfung durch die Teamleitung“.
• Das Risiko wird zuerst geprüft, nicht zuletzt. Ein Ja bei „Reputations- oder Rechtsrisiko?“ geht direkt zu „Kritischer Kunde betroffen?“ in der Bahn der Bereitschaftsleitung, deren Ja bei „Bereitschaftsleitung übernimmt die Führung“ endet und deren Nein bei „Account Manager übernimmt den Fall“.
• „SLA-Ziel gefährdet?“ trennt Gefährdet von Im Ziel: Gefährdet läuft über die Kundenprüfung, bevor irgendeine technische Zuweisung erfolgt, Im Ziel geht direkt zur Produktfehlerfrage.
• „Strategischer oder geschützter Kunde?“ liegt in der Bahn des Account Managers. Ja endet bei „Account Manager übernimmt den Fall“; Nein führt zurück in die technische Zuweisung, statt eine zweite parallele Warteschlange zu eröffnen.
• Technische Zuweisung über „Bestätigter Produktfehler?“: Nein endet bei „An den 2nd-Level-Support eskaliert“, Ja führt weiter zu „Workaround verfügbar?“, wo ein Nein bei „Als Fehler an die Entwicklung eskaliert“ endet.
• Ein bewusstes Nicht-Eskalations-Ergebnis: Existiert ein Workaround, gibt der Agent ihn an den Kunden, und der Fall endet bei „Als Fehler erfasst, nicht eskaliert“: Der Bug reiht sich damit in den normalen Entwicklungs-Backlog ein, statt eine Eskalation zu verbrauchen.

Wann Sie diese Vorlage verwenden sollten

• Die Eskalation in Ihrem Team hängt vom Temperament der einzelnen Person ab, und zwei Agenten behandeln denselben Fall unterschiedlich.
• Der 2nd Level oder die Entwicklung beschwert sich über die Qualität der Eskalationen, und Sie brauchen abgestimmte Annahmekriterien statt eines schärferen Tons.
• Account Manager erfahren von ernsten Fällen regelmäßig zuerst vom Kunden und nicht intern.
• Sie schreiben oder überarbeiten eine Eskalationsrichtlinie und wollen Prüfungen und Entscheidungsbefugnisse geklärt haben, bevor jemand den Text formuliert.
• Sie schulen neue Supportmitarbeitende und brauchen eine Seite, die zeigt, wann und an wen eskaliert wird, ergänzend zur durchgängigen Prozesslandkarte.

So funktioniert es

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

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

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

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

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

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