Der Support-Call-to-Ticket-Workflow sollte nicht davon abhängen, woran sich der Agent erinnert, nachdem der Kunde aufgelegt hat.
Beim Anruf kommt das eigentliche Problem zum Vorschein.
Der Kunde erklärt, was kaputt gegangen ist. Sie erwähnen den Browser, das Konto, die Fehlermeldung, den von ihnen versuchten Workaround und die Frist, die das Problem dringend macht. Der Agent stellt Fragen, prüft Annahmen und verspricht einen nächsten Schritt.
Dann endet das Gespräch.
Wenn das Ticket aus dem Speicher startet, werden die nützlichen Details sofort durchsickern.
Das Ergebnis ist ein Ticket mit der Aufschrift:
„Kunde hat angerufen. Login-Problem. Untersuchung wird durchgeführt.“
Für eine Unterstützung reicht das nicht.
Das ist ein Brotkrümel.
Wenn telefonischer Support zu nutzbaren Tickets werden soll
Verwandeln Sie Support-Anrufe in Ticket-fähige Ausgaben
Superscribe Phone erfasst Anrufe und hilft dabei, sie in überprüfte Tickets, Notizen, Nachverfolgungen, Aufgaben und abrechenbaren Kontext umzuwandeln, anstatt ein weiteres Transkript zur späteren Bereinigung.
Die Kurzversion
Ein Support-Call-to-Ticket-Workflow sollte sieben Dinge erfassen:
- das genaue Problem des Kunden
- der betroffene Benutzer, das Konto, das Gerät, das System oder die Umgebung
- Die Schritte wurden bereits ausprobiert
- was der Agent während des Anrufs getestet hat
- die aktuellen Auswirkungen und die Dringlichkeit
- der nächste Besitzer und die nächste Aktion
- Was sollte dem Kunden gesagt werden?
Die Anrufaufzeichnung oder das Transkript ist Ausgangsmaterial.
Das Ticket ist ein Arbeitskontext.
Dieser Unterschied ist wichtig, da der nächste Supportschritt Stunden später von einer anderen Person in einem anderen System erfolgen kann. Wenn das Ticket keinen nützlichen Anrufkontext enthält, muss das Team dem Kunden dieselben Fragen erneut stellen.
Deshalb fühlt sich die Unterstützung langsamer an, als sie tatsächlich ist.
Warum Tickets für den Telefonsupport selten werden
Supportanrufe sind im Gegensatz zu Chat und E-Mail chaotisch.
Der Kunde beschreibt das Problem nicht immer in der richtigen Reihenfolge. Sie erinnern sich an eine Fehlermeldung mitten im Gespräch. Gegen Ende erwähnen sie einen zweiten betroffenen Benutzer. Sie sagen: „Es passiert jeden Morgen“, stellen aber erst später klar, dass es nach einem Zurücksetzen des Passworts begann.
Mittlerweile erledigt der Agent drei Aufgaben:
- dem Kunden zuhören
- Fehlerbehebung live
- Ich versuche, eine nützliche Spur für später zu hinterlassen
Der dritte Job ist derjenige, der normalerweise verliert.
Nicht, weil Agenten nachlässig sind.
Weil der Anruf bereits die Aufmerksamkeit auf sich zog.
Nach dem Anruf kann es zu einem weiteren Warteschlangenelement, einem anderen Kunden, einer weiteren Eskalation oder einem versprochenen Update kommen. Die Ticketnotiz wird zu einer komprimierten Version des Speichers:
- „Benutzer kann sich nicht anmelden.“
- „Druckerproblem.“
- „VPN ausgefallen.“
- „Der Kunde sagt, die App sei langsam.“
- „Entwickler muss das überprüfen.“
Diese Notizen sind technisch gesehen Tickets.
Es sind keine guten Übergaben.
Ein Ticket hat eine andere Aufgabe als ein Transkript
Eine Niederschrift bewahrt das Gesagte.
Ein Ticket erklärt, was als nächstes passieren soll.
Tools wie Zendesk und Jira Service Management bieten Teams Orte zum Speichern von Feldern, Kommentaren, Status, Anfragetypen und internem Kontext (Zendesk-Entwicklerdokumente, Atlassian-Support).
Die Lagerung ist nicht der Engpass.
Der Engpass besteht darin, den Anruf in den richtigen Ticketinhalt umzuwandeln, bevor die Details verschwimmen.
Ein nützliches Support-Ticket sollte antworten:
- Was ist kaputt?
- Wer ist betroffen?
- Wie schlimm ist es?
- Wie kann jemand es reproduzieren oder untersuchen?
- Was wurde bereits versucht?
- Was ist die nächste Aktion?
- Was erwartet der Kunde als nächstes?
Deshalb Gesprächsnotizen sind keine Transkripte. Das Transkript darf vollständig sein, das Ticket muss jedoch verwendbar sein.
Der Workflow: Anruf, Struktur, Überprüfung, Weiterleitung
Der sauberste Support-Call-to-Ticket-Workflow besteht aus vier Schritten.
1. Erfassen Sie den Anruf
Der Anruf sollte die Quelle der Wahrheit sein.
Keine halbgeschriebene Notiz.
Nicht die Erinnerung des Agenten nach dem nächsten Anruf.
Die Erfassung ist wichtig, denn kleine Details verändern das Ticket. Ein „Anmeldeproblem“ wird ganz anders, wenn der Kunde sagt, dass es nur auf einem verwalteten Laptop, nur nach SSO, nur bei Verbindung mit Hotel-WLAN oder nur für Benutzer in einer Rolle auftritt.
Diese Details entscheiden darüber, ob es sich bei dem Ticket um eine Passwortzurücksetzung, ein Problem mit dem Identitätsanbieter, ein Netzwerkproblem, einen Berechtigungsfehler oder eine Kundenschulung handelt.
Wenn die Quelle schwach ist, beginnt das Ticket schwach.
2. Strukturieren Sie den Supportkontext
Roher Anruftext ist zu viel für ein Ticket.
Das Ticket benötigt eine geformte Version des Anrufs:
- Zusammenfassung des Problems: die kürzeste genaue Version des Problems
- Auswirkungen auf den Kunden: Wer blockiert ist und warum es wichtig ist
- Umfeld: Konto, Gerät, Browser, Version, Standort, Integration oder System
- Symptome: genaues Verhalten, Fehler, Timing oder Muster
- Versuchte Schritte: was der Kunde und Agent bereits getestet haben
- Hinweise zur Reproduktion: was bewirkt, dass es wieder passiert
- Nächste Aktion: Besitzer, Aktion und erwartetes Update
- Hinweis für Kunden: was der Kunde als nächstes hören soll
Dies ist die Ebene, die einen Supportanruf in ein Ticket verwandelt, auf das jemand reagieren kann.
3. Überprüfen Sie es, bevor das Ticket in die Teamerinnerung übergeht
Schieben Sie roh generierte Notizen nicht direkt in eine Ticketwarteschlange.
Bei Supportanrufen geht es häufig um Vermutungen, vertrauliche Kontodaten, Frustration, Teildiagnosen und private interne Notizen. Das Ticket sollte einen nützlichen Kontext bewahren, ohne jeden Satz in eine offizielle Geschichte umzuwandeln.
Die Rezension erkennt den Unterschied zwischen:
- „SSO ist kaputt.“
- „Der Kunde meldet, dass die SSO-Anmeldung für zwei Benutzer fehlgeschlagen ist. Die Protokolle des Identitätsanbieters müssen überprüft werden.“
Eine davon ist eine unbewiesene Schlussfolgerung.
Das andere ist ein Support-Ticket.
4. Leiten Sie die Ausgabe dorthin, wo die Arbeit stattfindet
Das Ticket sollte im System landen, wo das Team tatsächlich arbeiten wird.
Wenn es sich um ein Supportproblem handelt, erstellen oder aktualisieren Sie das Ticket. Wenn Technik erforderlich ist, schließen Sie Reproduktionsschritte und Auswirkungen ein. Wenn es um Kundenerfolg geht, bewahren Sie die Erwartungen und versprochenen Updates. Wenn dadurch abrechenbare Supportzeit entsteht, bewahren Sie den Grund auf, solange er noch aktuell ist.
Dies ist das gleiche Muster hinter einem starken Workflow für Follow-up-Anrufe. Der Anruf ist nicht beendet, wenn der Kunde auflegt. Der Vorgang ist abgeschlossen, wenn die nützliche Ausgabe den nächsten Workflow erreicht.
Eine praktische Support-Ticket-Vorlage
Nutzen Sie dies, wenn Sie Tickets nach Anrufen immer noch manuell schreiben.
Zusammenfassung des Problems:
Auswirkungen auf den Kunden:
Betroffener Benutzer, Konto oder System:
Umgebung:
Symptome:
Bereits ausprobierte Schritte:
Hinweise zur Reproduktion:
Nächste Aktion:
- Besitzer:
- Fälligkeits- oder Aktualisierungszeit:
Kundenspezifisches Update:
Interner Kontext:
Hier ist eine ausgefüllte Version.
Zusammenfassung des Problems:
Der Benutzer kann die SSO-Anmeldung vom verwalteten Laptop aus nicht abschließen.
Auswirkungen auf den Kunden:
Der Finanzleiter ist daran gehindert, Rechnungen vor dem heutigen Abschluss zu genehmigen.
Betroffener Benutzer, Konto oder System:
Acme-Konto. Benutzer: Finanzleiter. Gerät: Firmen-MacBook.
Umgebung:
Chrom. Sowohl Büro-WLAN als auch mobiler Hotspot getestet.
Symptome:
Die Anmeldung wird zu SSO weitergeleitet und kehrt dann mit einer leeren Seite zur App zurück. Es wird kein Passwortfehler angezeigt.
Bereits ausprobierte Schritte:
Browser-Cache geleert. Inkognito versucht. Bestätigt, dass sich ein anderer Benutzer mit demselben Konto anmelden kann.
Hinweise zur Reproduktion:
Begonnen, nachdem die Kunden-IT gestern die Regeln für Identitätsanbieter geändert hatte.
Nächste Aktion:
– Eigentümer: Der Support eskaliert zur Überprüfung der Identitätsprotokolle.
- Fälligkeit oder Aktualisierungszeit: Der Kunde erwartet eine Aktualisierung innerhalb von zwei Stunden.
Kundenspezifisches Update:
Wir prüfen die SSO-Übergabe und werden Sie vor 15:00 Uhr informieren.
Interner Kontext:
Zeitkritisch, da die Rechnungsfreigabe blockiert wird. Noch nicht als bestätigter App-Ausfall einordnen.
Dieses Ticket gibt der nächsten Person einen Ausgangspunkt.
Außerdem wird verhindert, dass der Kunde den gesamten Anruf wiederholt.
Was nicht ins Ticket darf
Ein gutes Support-Ticket ist keine Mülldeponie.
Lassen Sie weg:
- lange Transkriptabschnitte, die keinen Einfluss auf die nächste Aktion haben
- Vermutungen, die als Fakten geschrieben wurden
- emotionaler Füller aus dem Anruf
- private Kundendaten, die nicht benötigt werden
- innere Schuld
- unbestätigte Grundursache
Das Ticket sollte spezifisch, aber nicht laut sein.
Wenn das vollständige Gesprächsprotokoll später benötigt wird, bewahren Sie es als Ausgangsmaterial auf. Das Hauptticket sollte die betriebsbereite Version enthalten.
Wo Superscribe passt
Superscribe Phone ist für Anrufe gemacht, die Arbeit erzeugen.
Für Support-Teams und kleine Servicebetreiber bedeutet das, dass der Anruf zu einer überprüften Ticketnotiz, Aufgabe, Nachverfolgung, CRM-Aktualisierung, Eskalationskontext oder abrechenbarem Support-Trail werden kann.
Es geht nicht darum, ein schöneres Transkript zu erstellen.
Es geht darum, den Weg vom Telefonanruf zum nützlichen Ticket zu verkürzen.
Wenn der Anruf Arbeit außerhalb des Telefonsystems verursacht, deckt Superscribe Desktop die nächste Ebene ab. Sie können die technische Übergabe, Kundenaktualisierung, interne Notiz oder Rechnungserklärung direkt in das Feld diktieren, wo sie hingehören.
Anrufe schaffen den Kontext. Das Desktop-Diktieren erfasst die Nachverfolgung.
Diese Brücke ist aus demselben Grund wichtig automatischen Vorfallberichten aus Support-Anrufen Gegenstand. Support-Arbeit ist nur so gut wie die Übergabe, die sie hinterlässt.
Bevor der nächste Support-Anruf diesen überschreibt
Erfassen Sie den Ticketkontext, solange er aktuell ist
Verwende Superscribe Phone wenn Supportanrufe in überprüfte Tickets, Notizen, Nachverfolgungen und abrechenbaren Kontext umgewandelt werden müssen.
FAQ
Was ist ein Support-Call-to-Ticket-Workflow?
Ein Supportanruf-zu-Ticket-Workflow erfasst ein telefonisches Supportgespräch, extrahiert den nützlichen Problemkontext, überprüft ihn und leitet ihn mit Eigentümern und nächsten Schritten an das Ticketsystem weiter.
Reicht ein Anrufprotokoll für ein Support-Ticket?
Normalerweise nicht. Ein Transkript bewahrt das Gespräch auf, aber ein Ticket benötigt eine prägnante Zusammenfassung des Problems, die Auswirkungen, die Umgebung, den Fehlerbehebungsverlauf, Reproduktionshinweise und eine nächste Aktion.
Was sollte ein Support-Ticket aus einem Telefonanruf enthalten?
Es sollte das Problem, den betroffenen Benutzer oder das betroffene System, die Auswirkungen auf den Kunden, Symptome, bereits ausprobierte Schritte, Reproduktionshinweise, den Besitzer, die nächste Aktion und ein kundenorientiertes Update umfassen.
Sollten Support-Tickets automatisch aus Anrufen erstellt werden?
Sie können automatisch erstellt werden, wichtige Tickets sollten jedoch noch überprüft werden, bevor sie in das Teamgedächtnis übernommen werden. Bei der Überprüfung fallen Ihnen unbestätigte Diagnosen, sensible Details und unklare Versprechen auf.