| Suite | Professional, Enterprise oder Enterprise Plus |
| Support mit | Explore Professional oder Enterprise |
Sie können Dashboard-Berichte in Explore planen und als PDFs für Ihr Team bereitstellen. Vielleicht rufen Sie auch jeden Monat von Hand Zahlen ab und übertragen sie in eine Kalkulationstabelle oder erstellen Berichte für dieselben Zahlen in Explore. Wenn diese Methoden zu unterschiedlichen Ergebnissen führen, kann das verwirrend sein: warum stimmen die Zahlen nicht überein?
Denken Sie vor allem daran, dass PDFs und Kalkulationstabellen statisch sind, während Explore dynamisch ist.
In diesem Beitrag werden folgende Themen behandelt:
Warum sich Ergebnisse ändern
Angenommen, Sie exportieren am 1. August Daten für den gesamten Monat Juli und übernehmen sie in eine Kalkulationstabelle. Später, im September, führen Sie in Export einen Bericht zu denselben Daten aus und stellen fest, dass dieser für den Juli andere Zahlen aufweist.
| Spalte für Juli laut eines Exports vom August: | Spalte für Juli in einem Explore-Bericht vom September: |
 |
 |
In diesem Abschnitt werden folgende Fragen beantwortet:
Warum stimmen die Zahlen für erstellte Tickets nicht überein?
Die Gesamtzahl der erstellten Tickets kann sinken, wenn Sie Tickets gelöscht haben.
Gelöschte Tickets werden aus dem Dataset „Tickets“ entfernt. Wenn Sie also Tickets als Spam markieren oder auf andere Weise löschen, werden diese von der Gesamtzahl der Tickets abgezogen. Dies wirkt sich letztlich auch auf die Anzahl der erstellten Tickets aus.
Im oben stehenden Beispiel hat die Anzahl der erstellten Tickets von 705 auf 693 abgenommen. Das lässt darauf schließen dass zwischen dem Datenexport im August und dem Bericht im September 12 Tickets gelöscht wurden.
Andererseits kann die Anzahl der erstellten Tickets auch zunehmen, wenn Sie gelöschte Tickets wiederherstellen.
Die Anzahl der gelöschten und der wiederhergestellten Tickets lässt sich mithilfe der Metriken Löschungen und Wiederhergestellte Tickets im Dataset „Updates History“ feststellen.
Zu den Löschungen werden keine Details wie Ticket-IDs oder andere Attribute angezeigt (weil die Tickets gelöscht wurden), Sie können aber feststellen:
- wann die Tickets gelöscht wurden (mit dem Attribut Aktualisierung – Zeitstempel)
- wer die Tickets gelöscht hat (mit dem Attribut Aktualisierender – Name)
Zu wiederhergestellten Tickets können Sie ähnliche Informationen dazu abrufen, wer sie wann wiederhergestellt hat, aber auch andere Ticketattribute wie die Ticket-ID sehen (weil die Tickets wieder existieren).
Warum stimmen die Zahlen für gelöste Tickets nicht überein?
Typischerweise werden erstellte Tickets mit dem Attribut Ticket erstellt – Datum und gelöste Tickets mit dem Attribut Ticket gelöst – Datum angezeigt. Es gibt aber Fälle, in denen diese Zahlen aufgrund bestimmter Ereignisse schwanken.
Wenn Sie gelöste Tickets nach dem Lösungsdatum betrachten, werden die Zahlen durch die Metrik Erneut eröffnet (der Datasets „Tickets“ und „Updates History“) beeinflusst. Diese Zahl ändert sich, wenn Tickets zwischen dem Datenexport und der Ausführung des Berichts in Explore erneut geöffnet werden. Ein erneut geöffnetes Ticket kann entweder ganz aus der Metrik entfernt (weil es nicht mehr gelöst ist) oder in einen anderen Zeitraum verschoben werden (weil es beim letzten Mal in einem anderen Zeitraum gelöst wurde als beim ersten Mal).
Wenn Sie gelöste Tickets nach dem Erstellungsdatum betrachten, werden die Zahlen durch die Lösungen im Laufe der Zeit beeinflusst. Wenn 10 Tickets am Montag erstellt und 2 Tickets am selben Tag gelöst wurden, werden im Export für Montag 2 gelöste Tickets angezeigt. Werden am Dienstag weitere 3 Tickets gelöst, so zeigt der Bericht – und der nächste Export – für Montag 5 gelöste Tickets an.
Die Metrik Gelöste Tickets im Dataset „Updates History“ betrachtet nur die letzte Lösung des aktuell gelösten Tickets. Dies ist an der Formel der Metrik zu erkennen, insbesondere an den beiden fett gedruckten Bedingungen:
IF ([Changes - Field name]="status"
AND [Changes - Previous value]!="solved"
AND ([Changes - New value]="solved" OR [Changes - New value]="closed")
AND ([Ticket status - Unsorted] = "Solved" OR [Ticket status - Unsorted] = "Closed")
AND [Update - Timestamp]=[Ticket solved - Timestamp])
THEN [Update ID]
ENDIF
Wenn Sie alle Lösungen nachverfolgen möchten, können Sie eine berechnete Standardmetrik erstellen, die diese beiden Bedingungen für den aktuellen Status und das Datum ausschließt, sodass Sie die folgende Formel erhalten:
IF ([Changes - Field name]="status"
AND [Changes - Previous value]!="solved"
AND ([Changes - New value]="solved" OR [Changes - New value]="closed"))
THEN [Update ID]
ENDIF
Warum stimmen die Zahlen für Tickets einer bestimmten Kategorie nicht überein?
Das Dataset „Tickets“ betrachtet den aktuellen Zustand von Tickets – Status, Gruppe, Mitarbeiter, Priorität, angepasste Felder und so weiter. Deshalb führen Änderungen an einem Feld zwischen dem Export und der Berichtausführung in Explore in der Regel dazu, dass sich die Ergebnisse ändern.
Im oben stehenden Screenshot sehen Sie, dass der Export von August 10 Blips und 61 Bugs zeigt. Der Explore-Bericht vom September hingegen zeigt 2 Blips und 69 Bugs. Das lässt darauf schließen, dass zwischen dem Export und dem Bericht 8 Tickets vom „Blip“ zum „Bug“ hochgestuft wurden.
Diese Änderung kann sich auch auf die Filter Ihres Berichts auswirken. Angenommen, Sie haben einen Bericht so gefiltert, dass nur Tickets für Gruppe A angezeigt werden. Wenn ein Ticket zwischen dem Export und dem Bericht aus Gruppe A in eine andere Gruppe verschoben wird, erscheint dieses nicht mehr in Ihrem Bericht.
Umgekehrt werden aus Gruppe B in Gruppe A verschobene Tickets aufgrund des Filters zusätzlich in Ihrem Bericht angezeigt, sodass die Anzahl der Tickets in Ihrem Bericht steigt.
Die Größenordnung der Zahlen
Bei der Bewertung der Diskrepanzen zwischen Explore-Berichten und Exporten ist es hilfreich, die Größenordnung der tatsächlichen Zahlen im Blick zu behalten. Bedenken Sie Folgendes:
- Wenn ein Ergebnis von 20 auf 21 Tickets steigt, ist das ein Unterschied von 1 Ticket. Das hört sich nicht nach viel an, ist aber ein Anstieg von 5 %.
- Wenn ein anderes Ergebnis von 1.998 auf 2.100 Tickets steigt, ist das ein Unterschied von 102 Tickets. Das hört sich nach viel an, ist aber ebenfalls ein Anstieg von nur 5 %.
Betrachten Sie bei Abweichungen sowohl die Prozentwerte als auch die Zahlen selbst. Dadurch können Sie leichter erkennen, wie groß die Abweichungen tatsächlich sind.
Bedenken Sie, wie viele Agenten Sie haben. Wenn Sie 200 Agenten haben und sich ein Ergebnis um 102 Tickets ändert, haben zwischen dem Datenexport und der Berichtausführung im Durchschnitt etwa die Hälfte Ihrer Agenten das betreffende Feld in einem Ticket geändert.
Diese Ergebnisse können Sie wie gesagt im Dataset „Updates History“ untersuchen. Verwenden Sie das Attribut Aktualisierender – Name, um einen Bericht zu filtern, der das relevante Attribut [Änderungen – Feldname] und das vorherige oder neue Ergebnis zeigt, das Sie überprüfen möchten.
Häufig werden Sie eine breite Verteilung von Änderungen feststellen, weil beispielsweise 100 Agenten im betreffenden Zeitraum alle etwa ein Feld geändert haben.
Es kann aber vorkommen, dass ein oder zwei Agenten häufiger Ergebnisse in Feldern ändern. Diese sind dann vielleicht Manager, die hinter den Mitgliedern ihres Teams aufräumen, oder es handelt sich um neue Agenten, die noch nicht richtig verstanden haben, wie man ein bestimmtes Feld benutzt, und weitere Schulung benötigen.
Verwenden der richtigen Aggregatoren
Bei der Betrachtung der Dauer von Abläufen schließlich sollten Sie Quantität und Qualität gegeneinander abwägen.
Explore verwendet für Metriken wie die Zeit bis zur ersten Antwort und die Lösungszeit standardmäßig den Aggregator „Median“ (MED). Es kann aber sein, dass einige Ihrer Mitarbeiter oder Gruppen nur sehr wenige Tickets bearbeiten, und das in ganz anderer Weise, als Ihre anderen Agenden dies üblicherweise tun. Das könnten beispielsweise Mitarbeiter von Finanz- oder Sicherheitsteams sein, die nicht sehr häufig zu Tickets hinzugezogen werden und für die die Antwortzeit nur eine untergeordnete Rolle spielt.
Damit Ihre Ergebnisse nicht von solchen Ausreißern verzerrt werden, können Sie bei Metriken für die Dauer von Abläufen den Aggregator MED (Medianwert) verwenden. Bei Verwendung des Aggregators AVG (Mittelwert) können diese Verzerrungen deutlicher zutage treten. Angenommen, das Finanzteam sitzt seit sechs Monaten an einem Ticket eines bestimmten Kunden, während die übrigen Agenten ihre Tickets regelmäßig innerhalb einer Woche lösen. In diesem Fall wirkt sich der extreme Wert des Finanzteams erheblich auf das Alter der ungelösten Tickets aus, besonders, wenn Sie den Aggregator AVG verwenden.
Wenn das Finanzteam dieses Ticket schließlich löst, macht sich das in der Lösungszeit für den betreffenden Zeitraum ebenfalls deutlich bemerkbar – auch in diesem Fall besonders dann, wenn Sie AVG verwenden.
Zusammenfassung
Zahlen, die sich im Laufe der Zeit ändern, können Verwirrung stiften. Das wissen wir. Vor allem, wenn Ihr Chef Sie danach fragt. Aber es gibt viele logische Gründe für solche Veränderungen.
Wenn Sie Erklärungen für eine Abweichung suchen, überlegen Sie, ob eine der oben beschriebenen Ursachen zugrunde liegen könnte. Wenn Sie dann immer noch fragen haben, schlagen Sie in der Explore-Dokumentation nach, besuchen Sie die Community oder wenden Sie sich an den Zendesk-Kundensupport.
0 Kommentare
Melden Sie sich an, um einen Kommentar zu hinterlassen.