Eskalation im Kundensupport: Ablaufdiagramm (Entscheidungsbaum) — Excel

Kurz gesagt

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

Die Quelldaten: Eskalation im Kundensupport: Ablaufdiagramm (Entscheidungsbaum)

Erfassen Sie in Excel einen Schritt pro Zeile mit eindeutiger Kennung, Beschreibung, Folgeschritt und verantwortlicher Rolle. 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.

Ordnen Sie die Beschreibung Box text, das Ziel Line to, den Zweigtext Line text und die Zuständigkeit Vertical lane zu. 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. Prüfen Sie alle Zweige und Zuständigkeiten im Diagramm anhand der Tabelle. Siehe auch /de/guides/excel-daten-fur-ein-flussdiagramm-strukturieren.

So funktioniert es

1. Benennen Sie die vier Entscheider

   Erfassen Sie in Excel einen Schritt pro Zeile mit eindeutiger Kennung, Beschreibung, Folgeschritt und verantwortlicher Rolle. 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

   Ordnen Sie die Beschreibung Box text, das Ziel Line to, den Zweigtext Line text und die Zuständigkeit Vertical lane zu. „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

   Verfolgen Sie den Normalweg, Ablehnungen und Rücksprünge im Diagramm, bevor Sie es weitergeben. 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.

Häufige Fehler

• Fehlende Verbindungen

  Eine Aufgabenliste ist erst dann ein Prozessdiagramm, wenn jeder Schritt ein klares Ziel und jede Entscheidung benannte Ergebnisse hat. Die Eskalation in Ihrem Team hängt vom Temperament der einzelnen Person ab, und zwei Agenten behandeln denselben Fall unterschiedlich.

Häufig gestellte Fragen

Kann ich meine Excel-Datei verwenden?

Ja. Ordnen Sie die Spalten dem QueryChart-Tabelleneditor zu und prüfen Sie die Ziele nach Änderungen der Zeilen. 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.