Ablaufdiagramm für die Übergabe im Live-Chat
Ablaufdiagramm für Live-Chat-Übergaben mit Verifizierung, Diagnose, Warm- oder Async-Transfer, Transkript, Dringlichkeitsprüfung, Annahme und Kundenbestätigung.
Was ist ablaufdiagramm für die übergabe im live-chat?
Eine Live-Chat-Übergabe scheitert, wenn der Kunde von vorn beginnen muss. Diese Vorlage erfasst Kunde, Problem und gewünschtes Ergebnis und verlangt eine Identitätsprüfung nur, wenn Kontodaten oder Aktionen sie erfordern. Die Frontline-Kraft prüft frühere Kontakte und entscheidet, ob das Problem im aktuellen Chat lösbar ist. Andernfalls wählt der Prozess zwischen einem Warm Transfer zu einem verfügbaren Spezialisten und einem asynchronen Fall mit Transkript, knapper Zusammenfassung und bereits gesammelten Belegen.
Das Diagramm behandelt Kommunikation als Teil der Übergabe. Dringliche Auswirkungen erhalten einen priorisierten Verantwortlichen und eine Frist; auf jedem Weg erfährt der Kunde, wer übernimmt, welcher Kanal gilt und wann Kontakt folgt. Der Kunde kann einen ungeeigneten Plan zurückweisen, bevor die ursprüngliche Servicekraft geht, und der Empfänger muss den Fall bestätigen. Lösung oder zugesagtes erstes Update erreicht anschließend den Kunden, dessen Bestätigung entweder eine durchgehende Historie schließt oder das Problem in einen dokumentierten Fall zurückführt.
Was dieses Flussdiagramm abdeckt
In dieser Vorlage
- Bedingte Identitätsprüfung, die Kontodaten schützt, ohne jedes Gespräch unnötig zu belasten
- Die Wahl zwischen Warm Transfer und asynchroner Übergabe mit vorbereitetem Kontext vor Besitzer- oder Kanalwechsel
- Transkript, Zusammenfassung, Belege, Dringlichkeit, Priorität, Antwortfrist und Bestätigung durch den Empfänger
- Zustimmung des Kunden zum Übergabeplan und eine Abschlussprüfung, die Chat und Fall in einer Historie hält
Wann Sie diese Vorlage verwenden sollten
- Kunden wiederholen Kontodaten und Fehlerdiagnose nach Übergaben im Live-Chat
- Servicekräfte beenden Gespräche mit einem vagen Versprechen eines anderen Teams ohne sichtbaren Verantwortlichen oder Termin
- Warm Transfers und Folgetickets folgen verschiedenen Praktiken und dringende Chats verlieren beim Kanalwechsel ihre Priorität
- Sie gestalten Übergänge von Bot zu Mensch, Agent zu Spezialist oder Chat zu E-Mail und brauchen einen gemeinsamen Standard
So funktioniert es
Stellen mit Identitätsprüfung markieren
Bestimmen Sie Themen, die Kontodaten offenlegen oder Änderungen erlauben, und verwenden Sie dort nur das freigegebene Verfahren. Legen Sie zugleich fest, welche sicheren Informationen bei gescheiterter Prüfung erlaubt bleiben.
Das Übergabepaket definieren
Verlangen Sie Problembeschreibung, Ziel, bereits ausgeführte Schritte, Belege, Kundenauswirkung und Transkript-Link. Ein Transkript ist keine Zusammenfassung; eine Zusammenfassung ohne Belege zwingt den nächsten Bearbeiter zum Neustart.
Regeln für Warm und Async festlegen
Bestimmen Sie Wartezeit auf einen Spezialisten, live übertragbare Themen und den Punkt, an dem ein Fall angelegt wird. Ergänzen Sie eine Dringlichkeitsregel, die den Wechsel vom Chat in eine andere Queue übersteht.
Kontinuitätsfehler messen
Prüfen Sie Transfers mit wiederholten Angaben, abgelehnter Verantwortung oder verpasstem Update. Nutzen Sie diese Fälle zur Verbesserung von Routing, Besetzung und Übergabevorlage statt nur zur Schulung des Senders.
Häufig gestellte Fragen
Was sollte eine Live-Chat-Übergabe enthalten?
Sie sollte zulässigen verifizierten Kundenkontext, eine knappe Problembeschreibung, Ziel, erledigte Fehlersuche, Belege und den Transkript-Link enthalten. Außerdem gehören nächster Verantwortlicher, Kanal, Priorität und erwartete Antwortzeit dazu. Der Empfänger muss den Fall bestätigen, damit Verantwortung und nicht nur Daten übertragen werden.
Was unterscheidet Warm Transfer und asynchrone Übergabe?
Beim Warm Transfer informiert die ursprüngliche Servicekraft einen verfügbaren Spezialisten, bevor dieser in den laufenden Chat eintritt. Bei der asynchronen Übergabe wird ein Fall zur späteren Bearbeitung angelegt und der Kunde erfährt, wie und wann der neue Verantwortliche antwortet. Kontext und klare Verantwortung sind gleich; nur Zeitpunkt und Kanal unterscheiden sich.
Wann sollte der ursprüngliche Chat geschlossen werden?
Nach Lösung im Chat oder nachdem der Kunde einem klaren Übergabeplan zugestimmt und der Empfänger den verknüpften Fall bestätigt hat. Ein gespeichertes Transkript oder eine neue Queue reicht nicht. Meldet der Kunde später ein fortbestehendes Problem, wird der verknüpfte Fall wieder geöffnet oder mit derselben Historie fortgeführt.