Wie man einen Support-Ticket-Bericht erstellt: Schritt für Schritt
Ein Support-Ticket-Bericht ist meistens ein Definitionsproblem. Erstellte Tickets, gelöste Tickets, die erste Antwortzeit und die Lösungszeit klingen alle selbsterklärend. Doch jede dieser Kennzahlen hat innerhalb desselben Helpdesks mehr als eine offizielle Bedeutung.
Sobald die Zählregeln feststehen, schreibt sich der Bericht fast von selbst. Überspringt man diesen Schritt, ziehen zwei ehrliche Personen denselben Export und weichen um Stunden voneinander ab.
Dieser Leitfaden zeigt, was in den Bericht gehört, an welchen vier Stellen sich die Definitionen gabeln und wie Sie ihn aus einem Ticket-Export erstellen.
Was in einen Support-Ticket-Bericht gehört
Das reine Volumen sagt fast nichts aus. Erst die Anordnung sorgt dafür, dass die Zahlen verlässlich interpretiert werden können.
| Element | Warum es enthalten ist |
|---|---|
| Im Zeitraum erstellte Tickets | Die Nachfrageseite |
| Im Zeitraum gelöste Tickets | Die Angebotsseite, basierend auf einer festgelegten Statusregel |
| Backlog am Ende des Zeitraums | Alles, was nicht gelöst oder geschlossen ist |
| Erste Antwortzeit | Nach einer festgelegten Zeitzählung und Definition |
| Lösungszeit | Erste oder vollständige Lösung, explizit benannt |
| Wiedereröffnete Tickets | Das Qualitätssignal, das die anderen Zahlen verbergen |
| Unbeantwortete Tickets | Wo der Prozess komplett versagt hat |
| Eine festgelegte Datumsbasis und ein definierter Umfang | Welche Kanäle, Marken und Warteschlangen enthalten sind |
Zwei Zeilen haben mehr Gewicht, als ihre Größe vermuten lässt. Bei wiedereröffneten und unbeantworteten Tickets hört ein Bericht auf, eine bloße Anzeigetafel zu sein, und wird wirklich nützlich.
Zendesk veröffentlicht die zugrundeliegenden Formeln, wodurch die Definitionen überprüfbar werden, statt reine Ansichtssache zu sein. Die Referenz für Metriken und Attribute führt jede einzelne auf.
Beginnen wir mit dem Einfachsten. Gelöste Tickets ist „die Anzahl der gelösten oder geschlossenen Tickets“, sodass die Metrik zwei Status umfasst und nicht nur einen.
Die „erste Antwortzeit“ hat zwei offizielle Definitionen
Dies ist die Abzweigung, die für die meisten Unstimmigkeiten sorgt, und der Anbieter warnt direkt davor.
Die SLA-Dokumentation von Zendesk bringt es in einer Zeile auf den Punkt: „Verwechseln Sie die SLA-Antwortzeit nicht mit der nativen Zendesk-Antwortzeitmetrik.“
Die native Metrik ist streng darin, wer antwortet. Zendesk gibt an, dass „die erste Antwortzeit ausschließlich auf der Grundlage von Agentenantworten berechnet wird“. Automatisierte und Bot-bezogene Aktionen „werden bei der Berechnung der ersten Antwortzeit nicht berücksichtigt“.
Bei der SLA-Metrik ist das anders. Hier ist die erste Antwortzeit „die Zeit zwischen der Ticketerstellung und dem ersten öffentlichen Kommentar eines Agenten (oder einer automatischen Antwort)“. Zendesk fügt hinzu, dass „Antwortzeitmetriken erfüllt sind, wenn Sie einen Auslöser für eine automatische Antwort mit einem öffentlichen Kommentar einrichten“.
Wenn man diese beiden Punkte zusammen betrachtet, ist die Konsequenz drastisch. Ein Autoresponder kann Ihr SLA-Ziel erfüllen, während die native erste Antwortzeit im Hintergrund weiterläuft.
Ein Bericht, der eine SLA-Erfüllung von 98% und eine mediane erste Antwortzeit von vier Stunden ausweist, widerspricht sich also nicht. Er meldet zwei verschiedene Dinge, beide korrekt.
Es gibt zwei kleinere Ausnahmen, die man kennen sollte. Nehmen wir den Fall, dass ein Agent das Ticket erstellt und der erste Kommentar öffentlich ist. Die Referenz für Zeitdauermetriken besagt, dass sich der zweite Zeitstempel „auf den zweiten öffentlichen Agentenkommentar verschiebt“.
Zudem zählen geteilte Tickets nicht. Zendesk weist darauf hin, dass ein öffentlicher Kommentar eines Agenten aus einem anderen Konto über die Ticketfreigabe „nicht für die erste Antwortzeit Ihres Kontos zählt“.
Auch für die „Lösungszeit“ gibt es zwei Definitionen
Dieselbe Spaltung zieht sich durch die Lösungsmetriken, und hier werden standardmäßig beide Versionen mitgeliefert.
Die erste Lösungszeit ist die „Dauer zwischen der Ticketerstellung und der ersten Lösung“, die endet, „wenn der Ticketstatus zum ersten Mal auf gelöst gesetzt wird“.
Die vollständige Lösungszeit ist die „Dauer zwischen der Ticketerstellung und der jüngsten Lösung“. Sie endet, „wenn der Ticketstatus zum letzten Mal auf gelöst gesetzt wurde“.
Bei einem Ticket, das nur einmal gelöst wurde, sind beide identisch. Bei einem Ticket, das gelöst, wiedereröffnet und erneut gelöst wurde, weichen sie um die Dauer der zweiten Runde voneinander ab.
Genau deshalb gehören wiedereröffnete Tickets in den Bericht. Zendesk definiert sie als Tickets, die „nach dem Lösen wiedereröffnet wurden“, und stellt fest, dass die Metrik „keine Tickets enthält, die während desselben Updates gelöst und wiedereröffnet wurden“.
Es gibt einen Nebeneffekt zweiter Ordnung, den viele übersehen. Der tägliche Durchschnitt der gelösten Tickets zählt diese „nur, wenn sie aktuell gelöst oder geschlossen sind“. Ein heute wiedereröffnetes Ticket verschwindet also stillschweigend aus der Anzahl der gelösten Tickets des Vormonats.
Ein Bericht, den Sie im Juni erstellt haben, lässt sich daher im August nicht eins zu eins reproduzieren. Es ist nichts kaputtgegangen; der zugrundeliegende Status hat sich einfach geändert.
Zwei weitere Metriken trennen das Warten von der Bearbeitung. Die Wartezeit des Anfragenden ist die kumulierte Zeit in den Status „Neu“, „Offen“ und „Angehalten“, während die Wartezeit des Agenten die kumulierte Zeit im Status „Wartend“ ist.
Dieses Paar beantwortet die Frage, die ein Lösungsdurchschnitt nicht beantworten kann. Lange Lösungszeiten, die durch das Warten auf den Kunden entstehen, sind ein ganz anderes Problem als lange Lösungszeiten, die durch die Warteschlangentiefe verursacht werden.
Kalenderstunden oder Geschäftszeiten
Jeder Antwort- und Lösungswert existiert auf zwei verschiedenen Uhren, und die Wahl einer davon ist unumgänglich.
Zendesk speichert beide. Nach der ersten öffentlichen Antwort „berechnet das System die erste Antwortzeit in Kalenderstunden und Geschäftszeiten“. Beide Metriken „werden mit den Ticketdaten gespeichert“.
Der Standardwert, den Sie sehen, ist nicht neutral. Zendesk weist darauf hin, dass vorkonfigurierte Explore-Berichte „Informationen in Kalenderstunden anzeigen“. Metriken für Geschäftszeiten „sind verfügbar und können in Ihren eigenen Berichten verwendet werden“.
Ein Team, das von neun bis siebzehn Uhr arbeitet, sieht im Standardbericht also langsam aus. Ein Ticket, das am Freitag um 18:00 Uhr eingeht, sammelt bis Montagmorgen etwa 63 Kalenderstunden an, aber fast null Geschäftsstunden.
Live-Kommunikationskanäle bringen eine weitere Besonderheit mit sich. Die Metrik für die erste Antwortzeit (Sek.) für Messaging und Chat „ignoriert Ihre Einstellungen für Messaging-Geschäftszeiten und Live-Chat-Betriebszeiten“.
Zudem muss man sich für SLAs für Chat-Antwortzeiten aktiv entscheiden. Zendesk gibt an, dass Antwortzeit-SLAs für Live-Chats „standardmäßig deaktiviert sind“. Ihr Fehlen ist also eine Frage der Konfiguration und kein Beleg für perfekte Leistung.
Wie man es manuell macht
Option 1: Ein Tab pro Metrikfamilie
Exportieren Sie die Ticketliste mit den Metrikfeldern und teilen Sie dann Volumen, Antwortzeit und Lösungszeit auf separate Tabs auf, bevor Sie irgendetwas zusammenfassen.
Halten Sie die Spalten für Kalender- und Geschäftsstunden nebeneinander, anstatt sich schon beim Export für eine zu entscheiden. Sie werden garantiert nach der anderen gefragt werden.
Berechnen Sie für die Zeitmetriken Mediane statt Mittelwerte. Eine Handvoll Tickets, die über die Feiertage offen geblieben sind, zieht einen Durchschnitt in Bereiche, die kein echtes Ticket widerspiegeln.
Die Grenze dabei ist, dass eine Tabellenkalkulation den Statusverlauf nicht einsehen kann. Sie erhalten den aktuellen Zustand jedes Tickets, sodass das Wiedereröffnungsverhalten aus der Anzahl der Wiedereröffnungen abgelesen werden muss, statt es rekonstruieren zu können.
Option 2: Ein vorab erstellter Definitions-Tab
Halten Sie die Definition der Antwortzeit, die Zeitzählung, die Lösungsmetrik, die Statusregel für gelöste Tickets, die betroffenen Kanäle und die Datumsbasis fest.
Halten Sie dann fest, was der Bericht nicht aussagt. Wenn Sie schriftlich fixieren, dass die SLA-Erfüllung und die native erste Antwortzeit unterschiedliche Dinge messen, hindert das gutmeinende Kollegen daran, sie als eine einzige Zahl zu zitieren.
Die Einschränkung ist die übliche: Das Dokumentieren einer Regel wendet sie noch nicht an, und im nächsten Quartal baut jemand die Pivot-Tabelle aus dem Gedächtnis nach.
Option 3: Segmentieren vor der Durchschnittsberechnung
Teilen Sie die Daten nach Kanälen auf, bevor Sie eine Zeitmetrik berechnen. E-Mail-, Chat- und Telefon-Tickets folgen einer völlig unterschiedlichen Dynamik, und ein gemischter Median beschreibt keinen davon zutreffend.
Schließen Sie dann verzerrende Tickets aus oder markieren Sie diese. Tickets, die seit Wochen auf eine Antwort des Kunden warten, gehören in eine eigene Zeile und nicht in den Lösungsdurchschnitt.
Zeigen Sie, was Sie ausgeschlossen haben und wie viele es waren. Ein Leser, der den Filter nicht sieht, wird davon ausgehen, dass es keinen gab.
Die Einschränkung hierbei ist, dass die Segmentierung die Arbeit vervielfacht. Drei Kanäle mal zwei Zeitzählungen mal zwei Lösungsmetriken ergibt zwölf Zahlen, die man im Auge behalten muss.
Die gemeinsame Grenze. Alle drei Optionen setzen voraus, dass der Export einen einzigen Datumsbereich auf einer einheitlichen Datumsbasis für jede Warteschlange abdeckt. Gemischte Zeiträume über verschiedene Tabs hinweg sind der häufigste unbemerkte Fehler in diesem Bericht.
Wo der manuelle Weg an seine Grenzen stößt
Der erste Support-Ticket-Bericht dauert einen Nachmittag. Der vierte dauert länger, weil sich der Helpdesk im Hintergrund verändert hat.
Ein neuer kanal wird freigeschaltet, sodass sich der gemischte Median aus Gründen verschiebt, die nichts mit der Leistung zu tun haben. Die Geschäftszeiten werden für eine neue Region angepasst, und jeder historische Geschäftszeiten-Wert verschiebt sich mit ihnen.
Dann setzt der Wiedereröffnungseffekt ein. Die Zahlen des letzten Quartals lassen sich nicht mehr reproduzieren, und die Erklärung dafür dauert länger als die Neuerstellung des Berichts.
Es gibt noch einen vierten Nachteil, der sich erst unter Druck zeigt. Jemand fragt, ob der Support in diesem Quartal schneller geworden ist. Eine ehrliche Antwort erfordert, dass zuerst die Zeitzählung, die Definition und der Kanalmix offengelegt werden.
Für die Zufriedenheitsseite desselben Bildes lesen Sie unseren Leitfaden zur Erstellung eines NPS-Berichts. Wenn das Volumen selbst das Problem ist, zeigt unsere Anleitung zum Aufbau eines AI-Agenten für den Pre-Sales-Kundensupport, wie Sie Anfragen abfangen können.
Wie Sie ihn mit Powerdrill Bloom erstellen
Schritt 1: Laden Sie Ihren Ticket-Export hoch
Laden Sie den Ticket-Export oder den Ticket- und SLA-Export zusammen hoch. Powerdrill Bloom analysiert die Spalten direkt beim Import, sodass leere Zeitstempel, gemischte Datumsformate und Tickets ohne erste Antwort auffallen, noch bevor ein Median berechnet wird.
Schritt 2: Beschreiben Sie den Bericht in natürlicher Sprache
Geben Sie die Definitionen einfach an, statt sie mühsam nachzubauen. Nennen Sie die Definition der Antwortzeit, die Zeitzählung, die gewünschte Lösungsmetrik, die Statusregel für gelöste Tickets und die betroffenen Kanäle.
Stellen Sie dann die Fragen, die Fehler aufdecken. Fragen Sie, wie viele Tickets überhaupt keine Agentenantwort haben. Fragen Sie, welche Tickets wiedereröffnet wurden. Fragen Sie nach Medianen pro Kanal statt nach einem einzigen Gesamtwert.
Schritt 3: Exportieren Sie das Diagramm, den Bericht oder die Präsentation
Exportieren Sie die Metriktabelle pro Kanal oder ein Diagramm der erstellten gegenüber den gelösten Tickets mit dem Backlog im Hintergrund. Folien, die die Definitionen direkt neben den Zahlen zeigen, werden im selben Durchlauf erstellt.
Häufige Fehler
Die SLA-Erfüllung als erste Antwortzeit anzugeben. Die eine akzeptiert eine automatische Antwort, während die andere automatisierte Aktionen komplett ausschließt.
Der Vergleich von Kalenderstunden mit Geschäftszeiten. Der Standardbericht liefert Ihnen Ersteres, während Ihr Ziel wahrscheinlich auf Letzterem basierte.
Die Verwendung des Mittelwerts für Antwort- und Lösungszeiten. Einige wenige liegengelassene Tickets verschieben den Durchschnitt in einen Bereich, den kein echtes Ticket widerspiegelt.
Die Vermischung von Kanälen. Die Mediane von Chat und E-Mail unterscheiden sich von Natur aus, und eine Vermischung verschleiert beide.
Die Angabe der Lösungszeit, ohne zu sagen, welche gemeint ist. Erste und vollständige Lösungszeit sind separat gespeicherte Metriken, keine Rundungsvarianten.
Die Anzahl der gelösten Tickets als endgültig zu betrachten. Gelöste Tickets umfassen nur Tickets, die aktuell gelöst oder geschlossen sind, sodass Wiedereröffnungen die Vergangenheit verändern.
Das Weglassen von unbeantworteten Tickets. Sie sind definiert als Tickets mit weniger als einer Agentenantwort und stellen das deutlichste Versagen dar, das der Bericht aufzeigen kann.
Fazit
Nennen Sie die Antwortdefinition, nennen Sie die Zeitzählung, wählen Sie die erste oder vollständige Lösung, legen Sie die Statusregel fest, segmentieren Sie nach Kanälen und zeigen Sie wiedereröffnete sowie unbeantwortete Tickets. So entsteht ein Support-Ticket-Bericht, mit dem man tatsächlich arbeiten kann.
Was der Bericht unter Umständen nicht leistet, ist ein sauberer Vergleich mit den Zahlen eines anderen Unternehmens. Die Definitionen sind konfigurierbar, sodass ein Benchmark, den Sie irgendwo gelesen haben, fast sicher anders gemessen wurde.
Vergleichen Sie die Zahlen stattdessen anhand fester Regeln mit Ihrer eigenen Historie. Das ist die einzige Variante, die Ihnen verrät, ob sich wirklich etwas verbessert hat.
Wenn das monatliche Neuerstellen einen ganzen Tag verschlingt, probieren Sie Powerdrill Bloom für Ihren Ticket-Export. Siehe auch die Seite zum AI-Berichtsgenerator und den Voice-of-Customer-Zusammenfasser.
Häufig gestellte Fragen
Warum stimmt meine SLA-Erfüllung nicht mit meiner ersten Antwortzeit überein?
Sie messen unterschiedliche Ereignisse. Die SLA-Erste-Antwortzeit von Zendesk kann durch eine automatische Antwort erfüllt werden, während die native Metrik für die erste Antwortzeit automatisierte Aktionen und Bots komplett ausschließt.
Sollte ich die erste Lösungszeit oder die vollständige Lösungszeit angeben?
Geben Sie diejenige an, die Sie benennen. Die erste Lösungszeit endet, wenn ein Ticket zum ersten Mal auf gelöst gesetzt wird. Die vollständige Lösungszeit endet beim letzten Mal, sodass wiedereröffnete Tickets die beiden voneinander trennen.
Werden Support-Metriken in Kalenderstunden oder Geschäftszeiten gemessen?
Beide werden gespeichert. Die vorkonfigurierten Explore-Berichte von Zendesk zeigen Kalenderstunden an, und Metriken für Geschäftszeiten sind für Berichte verfügbar, die Sie selbst erstellen.
Warum hat sich die Anzahl der gelösten Tickets des letzten Quartals geändert?
Die Anzahl der gelösten Tickets umfasst nur Tickets, die aktuell gelöst oder geschlossen sind. Ein Ticket, das nach dem Ende des Zeitraums wiedereröffnet wird, fällt aus der Zählung dieses Zeitraums heraus.
Kann ich meine Lösungszeit mit einem Branchen-Benchmark vergleichen?
Nur vage. Die Definitionen, die Zeitzählung und der Kanalmix sind alle konfigurierbar, sodass ein veröffentlichter Wert wahrscheinlich nach anderen Regeln gemessen wurde als Ihre eigenen.