> Kontinuierliche Prozessoptimierung > Kundenservice > Zendesk Support > Datenvorlage

Ihr Kundenservice-Daten-Template

Zendesk Support

Kundenservice-Attribute (18) Kundenservice-Aktivitäten (14) Extraktionsanleitungen (4)

Ihr Kundenservice-Daten-Template

Diese Vorlage hilft Sie, die richtigen Daten für die Analyse Ihres Kundenserviceprozesses zu sammeln. Sie skizziert wesentliche Datenattribute zum Sammeln, Schlüsselaktivitäten zur Verfolgung und bietet praktische Anleitungen zur Extraktion dieser Informationen. Mithilfe dieses Leitfadens können Sie einen leistungsstarken Event-Log aufbauen, um Erkenntnisse zu gewinnen und Ihre Serviceoperationen zu verbessern.

Empfohlene Attribute zur Erfassung
Schlüsselaktivitäten zur Verfolgung Ihres Kundenserviceprozesses
Extraktionsanleitung für Zendesk Support

Neu bei Event-Logs? Erfahren Sie wie Sie ein Process-Mining-Event-Log erstellen.

Vorlage herunterladen

Kundenservice-Attribute

Dies sind die empfohlenen Datenfelder, die Sie in Ihr Event Log für eine vollständige Kundenservice-Analyse aufnehmen sollten.

5 Erforderlich 6 Empfohlen 7 Optional

	Name	Beschreibung
	Service-Requestn ServiceRequest	Der eindeutige Identifikator für jede Kundenservice-Anfrage, auch bekannt als Ticket oder Case.
Beschreibung Die Service-Requestn ist der primäre Case-Identifikator, der alle Aktivitäten im Zusammenhang mit einer einzelnen Kundenanfrage oder einem Problem von ihrer Erstellung bis zur endgültigen Lösung verbindet. Jede Interaktion, Aktualisierung oder interne Aktion ist an diese eindeutige ID gebunden. Im Process Mining ermöglicht die Analyse von Ereignisse, die nach der Service-Requestn gruppiert sind, eine vollständige End-to-End-Sicht auf die Kundenservice-Journey. Sie ist die Grundlage für die Berechnung von Schlüsselkennzahlen wie der gesamten Lösungszeit, der Identifizierung von Prozessabweichungen und dem Verständnis des Lebenszyklus jedes Kundenproblems. Bedeutung Dies ist die zentrale Case-ID, die alle Prozessschritte verbindet und die Rekonstruktion und Analyse jeder einzelnen Kundenservice-Journey ermöglicht. Datenquelle Zendesk Tickets API, Feld `id`. Beispiele 102451287415332
	Startzeit StartTime	Der `Zeitstempel`, der anzeigt, wann eine `Aktivität` oder ein `Event` begann.
Beschreibung Die Startzeit, oder Event-Zeitstempel, erfasst das genaue Datum und die Uhrzeit, zu der eine spezifische Aktivität stattfand. Sie erfasst beispielsweise, wann ein Kundenkommentar hinzugefügt, ein Agent zugewiesen oder den Antrag bearbeitet.er Ticketstatus auf 'Gelöst' geändert wurde. Dieser Zeitstempel ist wesentlich für das Process Mining, da er die chronologische Reihenfolge der Ereignisse festlegt. Er wird verwendet, um Zeitspannen zwischen Aktivitäten zu berechnen, Durchlaufzeiten zu messen, die Leistungsfähigkeit im Vergleich zu SLAs zu analysierenn und die zeitlichen Dynamiken des Serviceprozesses zu verstehen. Bedeutung Dieser Zeitstempel ist unerlässlich für die Reihenfolge der Ereignisse, die Berechnung von Dauern und die Analyse der Zeitachse des Service-Requestnnprozesses. Datenquelle Zendesk Ticket Audits API, Feld `created_at` für jedes Event im Audit-Trail. Beispiele 2023-04-15T10:00:00Z2023-04-15T10:05:14Z2023-04-16T14:30:00Z
	Aktivitätsname ActivityName	Der Name des spezifischen Ereignisse oder den Antrag bearbeitet.er Aufgabe, das/die innerhalb des Lebenszyklus der Service-Requestn aufgetreten ist.
Beschreibung Der Aktivitätsname beschreibt einen einzelnen Schritt oder Meilenstein im Kundenserviceprozess, wie 'Service-Requestn erstellt', 'Anfrage Agent zugewiesen' oder 'Service-Requestn gelöst'. Diese Ereignisse sind mit einem Zeitstempel versehen und bilden die Abfolge der Aktionen für jede Service-Requestn. Dieses Attribut ist maßgeblich für die Visualisierung des Prozessflusses, die Entdeckung von Prozessvarianten und die Analyse der Häufigkeit und Reihenfolge von Ereignisse. Es ermöglicht Analysten zu verstehen, welche Aktionen ausgeführt werden, und gängige Pfade, Engpässe und Abweichungen vom Standardverfahren zu identifizieren. Bedeutung Dieses Attribut definiert die Schritte im Prozess und ermöglicht die Visualisierung der Prozessablauf sowie die Analyse von Prozessabläufen und -variationen. Datenquelle Abgeleitet aus Zendesk Ticket Audit-Logs oder Event Streams, die Änderungen und Aktionen aufzeichnen. Beispiele Service-Requestn erstelltAnfrage Agent zugewiesenErste öffentliche Antwort des Agenten gesendetService-Requestn gelöst
	Letzte Datenaktualisierung LastDataUpdate	Der Zeitstempel der jüngsten Datenaktualisierung bzw. der letzten Extraktion aus dem Quellsystem.
Beschreibung Dieses Attribut gibt den Zeitpunkt der letzten Aktualisierung des Datensatzes aus Zendesk Support an. Es liefert Kontext zur Aktualität der analysierten Daten. Die Kenntnis des letzten Aktualisierungszeitpunkts ist für Analysten und Geschäftsanwender wichtig, um zu verstehen, ob sie die aktuellsten ProzessHinweisrmationen sehen. Es hilft, Erwartungen hinsichtlich der Aktualität der Daten zu managen und ist wichtig für Berichts- und Überwachungszwecke. Bedeutung Schafft Klarheit über die Aktualität der Daten und stellt sicher, dass Benutzer verstehen, wie neu die Prozessanalyse ist. Datenquelle Dies ist ein MetaDatenfeld, das während des Datenextraktionsprozesses generiert und gespeichert wird und den Zeitstempel des Extraktionsjobs aufzeichnet. Beispiele 2023-10-27T02:00:00Z
	Quellsystem SourceSystem	Das System, aus dem die Daten extrahiert wurden.
Beschreibung Dieses Attribut spezifiziert das Ursprungssystem für die Service-Requestn-Daten, das in diesem Fall Zendesk Support ist. Es hilft bei der Daten Governance und Herkunft, insbesondere beim Kombinieren von Daten aus mehreren Systemen. In der Analyse stellt es sicher, dass Daten ihrer Quelle korrekt zugeordnet werden, was wichtig für die Wahrung der Datenintegrität und das Verständnis des Prozesskontextes ist, insbesondere in Multi-System-Umgebungen. Bedeutung Identifiziert die Herkunft der Daten, was für die Daten-Governance und zur Unterscheidung von ProzessDaten in integrierten Umgebungen wichtig ist. Datenquelle Dies ist ein statischer Wert, der während des Datenextraktionsprozesses hinzugefügt wird, um die Herkunft der Daten zu kennzeichnen. Beispiele Zendesk Support
	Kommunikationskanal CommunicationChannel	Der Kanal, über den die Service-Requestn eingereicht oder den Antrag bearbeitet.ie Kommunikation erfolgte.
Beschreibung Dieses Attribut identifiziert die verwendete Kommunikationsmethode, wie E-Mail, Webformular, Chat oder Telefon. Es spiegelt wider, wie Kunden mit dem Service Desk interagieren. Das Verständnis der Kanalnutzung ist wichtig für die Ressourcenplanung und die Verbesserung der Kundenerfahrung. Das Dashboard 'Übersicht der Kommunikationskanäle' analysiert diese Daten, um zu sehen, welche Kanäle am beliebtesten sind und ob bestimmte Kanäle mit längeren Lösungszeiten oder unterschiedlichen Prozesspfaden verbunden sind. Es kann bei der Entscheidung helfen, wo in Serviceverbesserungen oder Automatisierung investiert werden soll. Bedeutung Zeigt, wie Kunden und Agenten interagieren, und ermöglicht die Analyse der Kanaleffizienz sowie deren Auswirkungen auf den Prozess und die Kundenerfahrung. Datenquelle Zendesk Tickets API, Feld `via.channel`. Beispiele webemailAPIchat
	Priorität Priority	Die der Service-Requestn zugewiesene Prioritätsstufe, wie 'Niedrig', 'Standard', 'Hoch' oder 'Dringend'.
Beschreibung Die Priorität gibt die Dringlichkeit einer Service-Requestn an und beeinflusst oft ihre Position in der Warteschlange sowie die angestrebte Lösungszeit. Sie hilft Agenten, sich zuerst auf die kritischsten Probleme zu konzentrieren. Dieses Attribut ist maßgeblich für die Leistungs- und SLA-Analyse. Das Dashboard 'Service Request Resolution Time Analysis' verwendet die Priorität zur Datensegmentierung und zeigt auf, ob Anfragen mit hoher Priorität schneller bearbeitet werden als solche mit niedriger Priorität und ob die Ressourcen effektiv entsprechend den Geschäftsanforderungen zugewiesen sind. Bedeutung Gibt die Dringlichkeit einer Anfrage an, was wichtig ist für die Analyse der SLA-Compliance und die Sicherstellung, dass kritische Probleme umgehend behoben werden. Datenquelle Zendesk Tickets API, Feld `priority`. Beispiele NiedrigStandardHochDringend
	Service-Requestntyp ServiceRequestType	Die Klassifizierung der Service-Requestn, wie 'Frage', 'Vorfall', 'Problem' oder 'Aufgabe'.
Beschreibung Dieses Attribut kategorisiert die Service-Requestn basierend auf ihrer Art. Diese Klassifizierung wird in der Regel bei der Erstellung oder Triage der Anfrage vorgenommen und hilft, den geeigneten Workflow und die Priorität zu bestimmen. In der Analyse ist die Segmentierung nach Service-Requestntyp wesentlich. Sie ermöglicht den Vergleich von Lösungszeiten, Eskalationsraten und Prozessabläufen für verschiedene Problemtypen, wie in Dashboards wie 'Service Request Resolution Time Analysis' und 'Interne Eskalationsrate & Ursachen' gezeigt. Dies hilft zu identifizieren, ob bestimmte Anfragetypen problematischer oder ineffizienter zu bearbeiten sind. Bedeutung Kategorisiert Anfragen, um Leistungsvergleiche und Analysen über verschiedene Problemtypen hinweg zu ermöglichen, was für gezielte Prozessoptimierungen wichtig ist. Datenquelle Zendesk Tickets API, Feld `type`. Beispiele FrageVorfallProblemAufgabe
	SLA verletzt? IsSlaBreached	Eine boolesche Markierung, die angibt, ob die Lösungszeit der Service-Requestn das SLA-Ziel überschritten hat.
Beschreibung Dieses berechnete Attribut ist ein einfaches True/False-Flag, das anzeigt, ob eine Service-Requestn ihr definiertes Service Level Agreement für die Lösungszeit nicht erfüllt hat. Es wird abgeleitet, indem die tatsächliche Lösungsdauer mit dem geplanten SLA-Ziel verglichen wird. Dieses Flag vereinfacht die SLA-Compliance-Analyse. Es ist der KernDatenpunkt für das Dashboard 'SLA Compliance Leistungsfähigkeit' und den KPI 'SLA Compliance Rate', was eine schnelle Aggregation und Visualisierung ermöglicht, wie viele Anfragen die Serviceziele erfüllen und wie viele nicht. Bedeutung Bietet ein klares, binäres Ergebnis für die SLA-Leistungsfähigkeit jedes Falls und vereinfacht so die Compliance-Überwachung und Berichterstattung. Datenquelle Berechnet während der Datenumwandlung durch Vergleich der gesamten Lösungszeit mit der SlaTargetResolutionTime. Beispiele JaNein
	SLA-Ziel-Lösungszeit SlaTargetResolutionTime	Die Zieldauer, innerhalb derer eine Service-Requestn gemäß ihrer SLA-Richtlinie gelöst werden soll.
Beschreibung Dieses Attribut definiert das Service Level Agreement (SLA)-Ziel für die Lösung eines Tickets. Dieses Ziel ist oft dynamisch und hängt von Faktoren wie der Priorität, dem Typ der Anfrage oder den Antrag bearbeitet.em Serviceplan des Kunden ab. Dies ist ein grundlegendes Attribut für das Dashboard 'SLA Compliance Leistungsfähigkeit'. Es dient als Benchmark, an dem die tatsächliche Lösungszeit gemessen wird. Die Analyse der Leistung im Vergleich zu diesem Ziel hilft, die Qualität der Serviceerbringung zu quantifizieren und sicherzustellen, dass vertragliche Verpflichtungen gegenüber Kunden erfüllt werden. Bedeutung Definiert das Serviceversprechen an den Kunden und dient als Benchmark für die Messung der Pünktlichkeit und SLA-Compliance. Datenquelle Abgeleitet aus den auf ein Ticket angewendeten SLA-Richtlinien. Diese Informationen sind über die Zendesk Ticket Metrics API verfügbar. Beispiele 144002880086400
	Zugewiesener Agent AssignedAgent	Der Name oder den Antrag bearbeitet.ie ID des Kundenservice-Agenten, der für die Bearbeitung der Service-Requestn zuständig ist.
Beschreibung Dieses Attribut identifiziert den spezifischen Agenten, der zu einem bestimmten Zeitpunkt für eine Aktivität oder den Antrag bearbeitet.ie Service-Requestn verantwortlich ist. Es kann sich während des Lebenszyklus ändern, wenn die Anfrage neu zugewiesen wird. Die Analyse nach zugewiesenem Agenten ist maßgeblich, um die Arbeitslast, Leistung und Effizienz der Agenten zu verstehen. Sie unterstützt das Dashboard 'Agenten-Arbeitslast und Effizienz', indem sie Vergleiche der Bearbeitungszeiten und Fallvolumen über verschiedene Agenten hinweg ermöglicht, was hilft, Coaching-Möglichkeiten zu identifizieren und eine ausgewogene Arbeitslast sicherzustellen. Bedeutung Verfolgt, welcher Agent eine Aktion ausgeführt hat, und ermöglicht die Analyse der individuellen Leistung, Arbeitslastverteilung und Ressourcenzuweisung. Datenquelle Zendesk Tickets API, Feld `assignee_id`. Benutzerdetails können über die Nutzer API abgerufen werden. Beispiele John SmithJane DoeSupportBot
	Agentengruppe AgentGroup	Die Supportgruppe oder den Antrag bearbeitet.as Team, dem die Service-Requestn zugewiesen ist.
Beschreibung Dieses Attribut repräsentiert das Team von Agenten, das für die Service-Requestn verantwortlich ist. Anfragen werden oft basierend auf Fähigkeiten, Produktbereich oder Sprache an bestimmte Gruppen weitergeleitet. Die Analyse nach Agentengruppe hilft, die Teamleistung, Arbeitslastverteilung und Eskalationsmuster zwischen Teams zu verstehen. Sie bietet eine übergeordnete Sichtweise im Vergleich zur Analyse einzelner Agenten und kann helfen, systemische Probleme innerhalb spezifischer Abteilungen oder Funktionen zu identifizieren. Bedeutung Verfolgt die Teamverantwortung und ermöglicht die Analyse der Gruppenleistung, der Übergaben zwischen Teams und der Ressourcenzuweisung über verschiedene Support-Stufen oder Spezialgebiete hinweg. Datenquelle Zendesk Tickets API, Feld `group_id`. Gruppendetails können über die Groups API abgerufen werden. Beispiele Tier 1 SupportTechnischer SupportAbrechnung
	Anzahl der Informationsanfragen InformationRequestCount	Die Gesamtzahl der Male, die Informationen vom Kunden für eine einzelne Service-Requestn angefordert wurden.
Beschreibung Diese berechnete Metrik zählt das Auftreten der Aktivität 'Informationen vom Kunden angefordert' für jede Service-Requestn. Eine hohe Anzahl deutet darauf hin, dass Agenten nicht alle notwendigen Informationen im Voraus sammeln. Dieses Attribut wird im Dashboard 'Analyse wiederholter Informationsanfragen' verwendet. Die Verfolgung dieser Anzahl hilft, Prozesseffizienzdefizite und Bereiche für die Agentenschulung zu identifizieren. Die Reduzierung der Anzahl der Informationsanfragen kann die Lösungszeiten erheblich verkürzen und die Kundenerfahrung verbessern. Bedeutung Quantifiziert die Hin- und Her-Kommunikation mit dem Kunden und zeigt Ineffizienzen auf, die Lösungszeiten verlängern und die Kundenerfahrung beeinträchtigen. Datenquelle Berechnet durch Zählen der Ereignisse, bei denen der ActivityName 'Information vom Kunden angefordert' für jede Service-Requestn ist. Beispiele 013
	Behebungscode ResolutionCode	Ein Code oder eine Kategorie, die den Grund für die endgültige Lösung oder Schließung der Anfrage angibt.
Beschreibung Der Lösungscode liefert strukturierte Informationen über das Ergebnis einer Service-Requestn. Beispiele sind 'Gelöst durch Agent', 'Duplikat', 'Keine Aktion erforderlich' oder 'Bekanntes Problem'. Er bietet mehr Kontext als ein einfacher 'Geschlossen'-Status. Dieses Attribut ist besonders wertvoll für die Ursachenanalyse. Für das Dashboard 'Trends wiedereröffneter Service-Requestnn' kann die Analyse der Wiedereröffnungsraten nach Lösungscode aufzeigen, ob bestimmte Lösungsarten weniger effektiv sind, was dazu führt, dass Kunden erneut den Support kontaktieren müssen. Bedeutung Bietet Einblick in das Ergebnis einer Service-Requestn, was für die Ursachenanalyse und das Verständnis, warum Anfragen wiedereröffnet werden, wichtig ist. Datenquelle Dies ist in der Regel ein benutzerdefiniertes Ticketfeld in Zendesk. Der genaue Feldname hängt von der spezifischen Zendesk-Konfiguration ab. Beispiele ErstkontaktlösungEskaliert an Tier 2Wartet auf KundeProduktfehler
	Endzeit EndTime	Der Zeitstempel, der anzeigt, wann eine Aktivität oder ein Event abgeschlossen wurde.
Beschreibung Die Endzeit repräsentiert die Abschlusszeit einer Aktivität. In vielen Event-Log-Strukturen kann die Startzeit der nächsten Aktivität als Endzeit der aktuellen dienen. Für zustandsbasierte Aktivitäten wie 'Agent untersucht Problem' markiert sie den Abschluss dieses Zustands. Dieses Attribut ist unerlässlich für die Berechnung der präzisen Dauer von Aktivitäten, was ein Kernbestandteil der Leistungsfähigkeit-Analyse ist. Es hilft zu identifizieren, welche Schritte am zeitaufwendigsten sind, und bildet die Grundlage für detaillierte Engpassanalysen und Berechnungen der Ressourceneffizienz. Bedeutung Ermöglicht die Berechnung von Aktivitätsdauern, was wichtig ist für die Identifizierung von Engpässen und die Leistungsmessung. Datenquelle Dies wird oft abgeleitet, indem die StartTime des nachfolgenden Ereignisse in der Sequenz für eine gegebene Service-Requestn genommen wird. Beispiele 2023-04-15T10:05:14Z2023-04-15T11:20:30Z2023-04-16T15:00:00Z
	Produkt-Service-Kategorie ProductServiceCategory	Das spezifische Produkt, der Service oder den Antrag bearbeitet.ie Funktion, auf die sich die Kundenanfrage bezieht.
Beschreibung Dieses Attribut bietet detaillierten Kontext, indem es die Service-Requestn nach einem Produkt- oder Servicebereich kategorisiert. Es wird oft manuell von einem Agenten oder automatisch basierend auf dem Anfrageinhalt gesetzt. Diese Kategorisierung ist maßgeblich für die Dashboards 'Genauigkeit der Anfragenkategorisierung' und 'Aufschlüsselung der Untersuchungszykluszeit'. Sie ermöglicht eine detaillierte Analyse, welche Produkte die meisten Supportanfragen generieren, welche am komplexesten zu lösen sind und ob die anfängliche Kategorisierung mit der endgültigen Lösung übereinstimmt, was zur Verbesserung der Weiterleitung und Agentenschulung beiträgt. Bedeutung Verknüpft Anfragen mit spezifischen Geschäftsbereichen, Produkten oder Dienstleistungen und ermöglicht eine fokussierte Analyse von Problembereichen und deren Auswirkungen auf den Prozess. Datenquelle Dies ist in der Regel ein benutzerdefiniertes Ticketfeld in Zendesk. Der genaue Feldname hängt von der spezifischen Zendesk-Konfiguration ab. Beispiele Mobile AppAbonnementnnementverwaltungAPI-Integration`Hardware`
	Wiedereröffnet IsReopened	Eine boolesche Markierung, die angibt, ob eine Service-Requestn nach der Markierung als gelöst wiedereröffnet wurde.
Beschreibung Dieses Attribut ist ein Flag, das auf 'Ja' gesetzt wird, wenn eine Service-Requestn nach einer zuvor als gelöst oder geschlossen markierten Phase in den Status 'Offen' zurückkehrt. Es signalisiert, dass die ursprüngliche Lösung nicht ausreichend war. Dieses Flag ist maßgeblich für die Verfolgung von Nacharbeit und fehlgeschlagenen Erstkontaktlösungen. Es unterstützt direkt das Dashboard 'Trends wiedereröffneter Service-Requestnn' und den KPI 'Service-Requestn Wiedereröffnungsrate', indem es das Zählen und Analysieren von Fällen, die zusätzliche Aufmerksamkeit erfordern und oft tiefere zugrunde liegende Probleme anzeigen, vereinfacht. Bedeutung Identifiziert Nacharbeiten und fehlgeschlagene Lösungen und hilft, die Qualität und Effektivität der bereitgestellten Lösungen zu messen. Datenquelle Berechnet während der Datenumwandlung durch Überprüfung, ob sich der Status eines Tickets von 'gelöst' oder 'geschlossen' zurück zu 'offen' ändert. Beispiele JaNein
	Zufriedenheitsbewertung SatisfactionRating	Der Zufriedenheitswert, den der Kunde nach der Lösung der Service-Requestn gegeben hat.
Beschreibung Dieses Attribut erfasst das Kundenfeedback zu ihrer Serviceerfahrung, in der Regel durch eine Umfrage nach der Lösung des Tickets. Gängige Bewertungen umfassen 'Gut', 'Schlecht' oder einen numerischen Wert. Dies ist ein direktes Maß für die Kundenstimmung und eine wichtige Ergebniskennzahl. Es wird zur Berechnung des KPI 'Kundenstimmungs-Wert' verwendet. Die Analyse von Zufriedenheitsbewertungen in Verbindung mit ProzessDaten, wie Lösungszeit oder Anzahl der Agentenkontakte, kann aufzeigen, welche Prozessverhaltensweisen zu besseren Kundenergebnissen führen. Bedeutung Misst direkt das Kundenfeedback zum erbrachten Service und verknüpft die Prozessleistung mit den Kundenergebnissen. Datenquelle Zendesk Tickets API, Feld `satisfaction_rating.score`. Beispiele gutschlechtangeboten

Erforderlich Empfohlen Optional

Kundenservice-Aktivitäten

Dies sind die wichtigsten Prozessschritte und Meilensteine, die Sie in Ihrem Event-Log für eine präzise Kundenservice-Prozessanalyse erfassen sollten.

6 Empfohlen 8 Optional

	Aktivität	Beschreibung
	Anfrage Agent zugewiesen	Dieses Event signalisiert, dass die Service-Requestn einem bestimmten Agenten zur Bearbeitung zugewiesen wurde. Dies kann automatisch basierend auf Routing-Regeln oder manuell durch einen Teamleiter oder Agenten geschehen.
Bedeutung Die Zuweisung ist ein wichtiger Meilenstein für die Verantwortlichkeit und das Workload-Management. Die Analyse der Zuweisungszeit und der Neuzuweisungsmuster offenbart Engpässe im Triage- und Verteilungsprozess. Datenquelle Dies ist ein explizites 'Change'-Event in der Zendesk Ticket Audits API, das protokolliert wird, wann immer das Feld 'assignee_id' befüllt oder geändert wird. Erfassen Verfolgen Sie Änderungen am Feld 'assignee_id' im Ticket Audits Log. Ereignistyp explicit
	Informationen vom Kunden angefordert	Tritt auf, wenn ein Agent weitere Informationen von einem Kunden benötigt, um fortzufahren, und den Ticketstatus auf 'ausstehende Zahlungen identifizieren.end' ändert. Diese Statusänderung zeigt explizit an, dass der Prozess nun auf eine externe Partei wartet.
Bedeutung Diese Aktivität verdeutlicht Abhängigkeiten vom Kunden und pausiert interne SLA-Zähler. Häufige oder wiederholte Vorkommen bei einem einzelnen Ticket können auf unvollständige initiale Informationssammlung hindeuten und zu längeren Lösungszeiten führen. Datenquelle Dies ist ein explizites Statusänderungs-Event, das in der Zendesk Ticket Audits API protokolliert wird. Es wird erfasst, wenn das Feld 'status' zu 'pending' wechselt. Erfassen Identifizieren Sie 'Change'-Ereignisse in den Ticket Audits, bei denen der Ticketstatus auf 'ausstehende Zahlungen identifizieren.end' gesetzt wird. Ereignistyp explicit
	Service-Requestn erstellt	Diese Aktivität markiert den Beginn des Kundenserviceprozesses, wenn ein neues Ticket in Zendesk über einen beliebigen Kanal wie E-Mail, Webformular oder Chat generiert wird. Dieses Event wird vom System bei der Erstellung explizit mit einer eindeutigen Ticket-ID und einem Zeitstempel protokolliert.
Bedeutung Als primäres Start-Ereignis ist es essenziell für die Berechnung der gesamten Falldauer und die Analyse des Volumens eingehender Anfragen über die Zeit. Es dient als Grundlage für die Messung wichtiger Leistungskennzahlen wie der Zeit bis zur ersten Antwort und der gesamten Lösungszeit. Datenquelle Dies ist ein explizites Event, das in der Zendesk Ticket Audits API erfasst wird. Es entspricht dem 'Create'-Event für ein Ticket und liefert den initialen Erstellungs-Zeitstempel. Erfassen Erfasst aus dem Ticket-Erstellungsereignis im Ticket Audits Log. Ereignistyp explicit
	Service-Requestn gelöst	Ein Agent markiert die Service-Requestn als 'gelöst', nachdem er dem Kunden eine Lösung bereitgestellt hat. Dies ist ein temporärer Zustand, da das Ticket durch eine Kundenantwort wiedereröffnet werden kann, bevor es dauerhaft geschlossen wird.
Bedeutung Dies ist der primäre Meilenstein zur Messung der Lösungszeit und Agenteneffizienz. Er markiert den Punkt, an dem der Agent die Arbeit als abgeschlossen betrachtet, und bietet eine Grundlage für die Analyse von Nacharbeit, falls das Ticket wiedereröffnet wird. Datenquelle Dies ist eine explizite Statusänderung, die in der Zendesk Ticket Audits API protokolliert wird, wenn das Feld 'status' auf 'solved' gesetzt wird. Erfassen Identifizieren Sie 'Change'-Ereignisse in den Ticket Audits, bei denen der Ticketstatus auf 'gelöst' gesetzt wird. Ereignistyp explicit
	Service-Requestn geschlossen	Dies ist die finale Aktivität, die den permanenten Abschluss der Service-Requestn markiert. Dies geschieht in der Regel automatisch, nachdem eine bestimmte Zeitspanne seit der Markierung des Tickets als 'gelöst' vergangen ist, ohne neue Antworten vom Kunden.
Bedeutung Als definitives Endereignis schließt es den Ticket-Lebenszyklus ab. Die Zeit von 'gelöst' bis 'geschlossen' stellt das Zeitfenster für mögliche Wiedereröffnungen dar, und das Ereignis 'geschlossen' bestätigt, dass die Lösung akzeptiert wurde. Datenquelle Dies ist eine explizite Statusänderung, die in der Zendesk Ticket Audits API protokolliert wird, wenn das Feld 'status' auf 'closed' gesetzt wird. Erfassen Identifizieren Sie 'Change'-Ereignisse in den Ticket Audits, bei denen der Ticketstatus auf 'geschlossen' gesetzt wird. Ereignistyp explicit
	Service-Requestn wiedereröffnet	Diese Aktivität tritt auf, wenn ein Kunde auf ein Ticket antwortet, das den Status 'Gelöst' hat. Zendesk ändert den Status automatisch zurück auf 'Offen', was darauf hindeutet, dass das Problem nicht vollständig gelöst wurde.
Bedeutung Wiedereröffnungen sind ein kritischer Indikator für das Scheitern der Erstkontaktlösung und eine mangelhafte Lösungsqualität. Die Analyse der Häufigkeit und Gründe für wiedereröffnete Tickets hilft dabei, Bereiche für die Verbesserung der Agentenschulung und der Lösungsverfahren zu identifizieren. Datenquelle Dies ist eine explizite Statusänderung in der Ticket Audits API, erfasst, wenn der 'status' von 'solved' zurück zu 'open' wechselt. Erfassen Verfolgen Sie Status 'Change'-Ereignisse von 'solved' zu 'open'. Ereignistyp explicit
	Anfrage kategorisiert und priorisiert	Diese Aktivität tritt auf, wenn ein Agent oder eine Automatisierung Ticketfelder wie Typ, Kategorie und Priorität setzt oder aktualisiert. Dieser Schritt wird als Änderungs-Event in der Ticket-Historie protokolliert.
Bedeutung Eine korrekte Kategorisierung und Priorisierung sind wichtig für eine effiziente Weiterleitung und Ressourcenzuweisung. Die Analyse dieser Aktivität hilft, die Genauigkeit der initialen Triage und deren Auswirkungen auf die Lösungszeiten zu bestimmen. Datenquelle Erfasst aus der Zendesk Ticket Audits API als 'Change'-Ereignisse. Es kann durch die erste Aktualisierung von Feldern wie 'priority', 'type' oder benutzerdefinierten Feldern, die mit der Kategorisierung zusammenhängen, identifiziert werden. Erfassen Filtern Sie Ticket Audit-Logs nach dem ersten 'Change'-Ereignis an wichtigen Kategorisierungsfeldern nach der Erstellung. Ereignistyp explicit
	Erste Bestätigung gesendet	Stellt die automatisierte erste Antwort an den Kunden dar, die bestätigt, dass seine Anfrage eingegangen ist. Dies wird in der Regel durch einen Zendesk-Trigger gehandhabt, der unmittelbar nach Ticketerstellung eine Vorlagen-E-Mail-Benachrichtigung sendet.
Bedeutung Die Verfolgung dieser Aktivität ist maßgeblich für die Messung der anfänglichen Reaktionsfähigkeit und das Management von Kundenerwartungen. Die Zeit zwischen der Erstellung der Anfrage und dieser Bestätigung ist eine Schlüsselmetrik für die Kundenzufriedenheit. Datenquelle Abgeleitet vom ersten öffentlichen Kommentar zum Ticket, wenn dessen Autor ein automatischer Benutzer ist oder wenn er innerhalb von Sekunden nach Ticketerstellung erfolgt. Dies kann durch Analyse des Ticket Comments Streams identifiziert werden. Erfassen Identifizieren Sie den ersten öffentlichen Kommentar, der unmittelbar nach der Ticket-Erstellung durch eine Automatisierung oder einen Trigger erstellt wurde. Ereignistyp inferred
	Erste öffentliche Antwort des Agenten gesendet	Diese Aktivität markiert das erste Mal, dass ein Agent einen öffentlichen Kommentar an den Kunden sendet, im Gegensatz zu einer automatisierten Bestätigung. Dieses Event ist ein wichtiger Indikator für das anfängliche Einbindung des Agenten bei dem Kundenanliegen.
Bedeutung Dies ist ein wichtiger Meilenstein zur Messung der SLA 'First Reply Time', ein kritischer Indikator für die Service-Reaktionsfähigkeit. Er trennt die automatisierte Kommunikation vom Beginn der aktiven, von Menschen geführten Untersuchung und des Supports. Datenquelle Identifiziert durch den ersten öffentlichen Kommentar im Ticket-Kommentarstrom, dessen Autor ein menschlicher Agent (kein automatisierter Systembenutzer) ist. Erfassen Scannen Sie Ticket-Kommentare, filtern Sie nach öffentlichen Kommentaren von Agenten und wählen Sie den mit dem frühesten Zeitstempel aus. Ereignistyp inferred
	Interne Eskalation ausgelöst	Stellt die Weiterleitung einer Service-Requestn an ein anderes internes Team oder eine höhere Supportstufe dar. Dies wird in der Regel abgeleitet, wenn die zugewiesene Gruppe des Tickets geändert wird.
Bedeutung Die Verfolgung von Eskalationen ist maßgeblich, um Prozessschwächen, Wissenslücken im Erstlinien-Support und komplexe Anfragetypen zu identifizieren. Hohe Eskalationsraten können auf die Notwendigkeit besserer Schulungen oder Prozessdokumentationen hinweisen. Datenquelle Abgeleitet von einem 'Change'-Ereignis in der Ticket Audits API, bei dem das Feld 'group_id' geändert wird. Eine Gruppenänderung bedeutet eine Übergabe zwischen Teams. Erfassen Überwachen Sie Änderungen am Feld 'group_id' im Ticket Audits Log. Ereignistyp inferred
	Kunde hat geantwortet	Dieses Event wird ausgelöst, wenn ein Kunde auf ein Ticket antwortet, in der Regel eines, das sich im Status 'Ausstehend' befand. Zendesk wechselt den Ticketstatus automatisch von 'Ausstehend' zurück zu 'Offen', was signalisiert, dass der Agent die Arbeit wieder aufnehmen kann.
Bedeutung Diese Aktivität markiert das Ende einer Wartezeit und ist ein Trigger für die Fortsetzung des Prozesses. Die Analyse der Reaktionszeit von Kunden kann Einblicke in die Klarheit der Agentenanfragen geben. Datenquelle Dieses Event entspricht einem neuen öffentlichen Kommentar des Endbenutzers, der eine explizite Statusänderung von 'Ausstehend' zu 'Offen' in der Ticket Audits API auslöst. Erfassen Verfolgen Sie Status 'Change'-Ereignisse von 'pending' zu 'open' oder identifizieren Sie neue öffentliche Kommentare eines Endbenutzers. Ereignistyp explicit
	SLA-Verstoß aufgetreten	Diese Aktivität markiert den Zeitpunkt, zu dem eine Service-Requestn ein vordefiniertes Service Level Agreement, wie die erste Antwortzeit oder den Antrag bearbeitet.ie Lösungszeit, nicht erfüllt. Dieses Event wird basierend auf Ticketaktivitäts-Zeitstempels im Vergleich zu SLA-Richtlinien berechnet.
Bedeutung SLA-Verstöße wirken sich direkt auf die Kundenzufriedenheit und die Vertragskonformität aus. Die Analyse, wann und warum sie auftreten, ist maßgeblich, um systemische Verzögerungen, Ressourcenengpässe oder unrealistische Leistungsziele zu identifizieren. Datenquelle Dies kann aus der Zendesk Ticket Metrics API bezogen werden, welche SLA-Verletzungs-Zeitstempels ('breached_at') speichert. Alternativ kann es durch den Vergleich von Ticket-Event-Zeitstempels mit den definierten SLA-Regeln berechnet werden. Erfassen Verwenden Sie den 'breached_at' Zeitstempel aus der Ticket Metrics API oder berechnen Sie ihn, indem Sie die Lösungszeit mit der SLA-Richtlinienzeit vergleichen. Ereignistyp calculated
	Zufriedenheitsbewertung erhalten	Dieses Event tritt auf, wenn der Kunde seine Antwort auf die Zufriedenheitsumfrage einreicht und eine Bewertung wie 'Gut' oder 'Schlecht' abgibt. Die Bewertung und alle zugehörigen Kommentare werden dem Ticket zugeordnet.
Bedeutung Direktes Kundenfeedback ist von besonders wertvoll für die Messung der Servicequalität und der Kundenstimmung. Die Analyse dieser Bewertungen im Kontext des Prozessflusses hilft, spezifische Aktivitäten oder Agenten mit Resultaten zu korrelieren. Datenquelle Erfasst als 'Change'-Ereignis in der Ticket Audits API, wenn das Feld 'satisfaction_rating' mit der Bewertung und dem Kommentar des Kunden gefüllt wird. Erfassen Filtern Sie Ticket Audit-Logs nach Änderungen am Feld 'satisfaction_rating'. Ereignistyp explicit
	Zufriedenheitsumfrage gesendet	Stellt den Zeitpunkt dar, zu dem eine Kundenzufriedenheitsumfrage (CSAT) automatisch an den Kunden gesendet wird. Dies geschieht in der Regel kurze Zeit, nachdem das Ticket als gelöst markiert wurde.
Bedeutung Diese Aktivität initiiert den Kundenfeedback-Loop. Zu verstehen, wann und ob Umfragen gesendet werden, ist wichtig, um Zufriedenheitswerte zu kontextualisieren und die Effektivität des Feedback-Programms zu messen. Datenquelle Dies kann aus einem Automatisierungsprotokoll oder den Antrag bearbeitet.urch das Hinzufügen eines spezifischen Tags zum Ticket abgeleitet werden. Der Abschnitt 'satisfaction_rating' in der Ticket Audits API erfasst ebenfalls, wann die Umfrage angeboten wurde. Erfassen Suchen Sie nach Tags wie 'csat_sent' oder verwenden Sie den Zeitstempel, wann die Zufriedenheitsbewertung angeboten wurde. Ereignistyp inferred

Extraktionsanleitungen

So erhalten Sie Ihre Daten von Zendesk Support

Schritte

Navigieren Sie zu Zendesk Explore: Melden Sie sich bei Ihrer Zendesk-Instanz an und öffnen Sie das Explore-Produkt, indem Sie auf das Produktsymbol in der oberen Leiste klicken und Explore auswählen.
Neue Abfrage erstellen: Klicken Sie in Explore in der linken Seitenleiste auf das Abfrage-Symbol und dann oben rechts auf die Schaltfläche „Neue Abfrage“.
Datensatz auswählen: Wählen Sie im Fenster „Datensatz auswählen“ den Datensatz Support: Tickets aus. Dieser Datensatz enthält die primären Ticket-Attribute und wichtige Event-Zeitstempel.
Metriken hinzufügen: Gehen Sie im Abfrage-Builder zum Panel „Metriken“ und klicken Sie auf „Hinzufügen“. Wählen Sie COUNT(Tickets). Dies hilft bei der Validierung des Datenvolumens.
Attribute zu Zeilen hinzufügen: Gehen Sie zum Panel „Zeilen“ und klicken Sie auf „Hinzufügen“. Fügen Sie die folgenden Attribute hinzu. Diese bilden die Basisspalten Ihres Exports im Wide-Format.
- Ticket ID (Dies ist Ihr Case-ID, ServiceRequest)
- Assignee name (AssignedAgent)
- Ticket type (ServiceRequestTyp)
- Ticket priority (Priority)
- Ticket channel (CommunicationChannel)
- SLA resolution time (SlaTargetResolutionTime)
- SLA breach status (IsSlaBreached)
- Full resolution time (min) (ServiceRequestResolutionTime)
Aktivitäts-Zeitstempel zu Zeilen hinzufügen: Fügen Sie die folgenden Zeitstempel-Attribute zum Panel „Zeilen“ hinzu. Jedes davon stellt eine potenzielle Aktivität dar. Einige Aktivitäten erfordern die Erstellung eines benutzerdefinierten berechneten Attributs.
- Ticket created – Zeitstempel: Für Service Request Created und Initial Acknowledgment Sent.
- Ticket assigned – Zeitstempel: Für Request Assigned To Agent.
- First reply time – Zeitstempel: Für First Agent Public Reply Sent.
- Ticket solved – Zeitstempel: Für Service Request Resolved und Satisfaction Survey Sent.
- Ticket reopened – Zeitstempel: Für Service Request Reopened.
- Satisfaction rating received – Zeitstempel: Für Satisfaction Rating Received.
- Ticket closed – Zeitstempel: Für Service Request Closed.
Benutzerdefinierte berechnete Attribute für andere Aktivitäten erstellen: Einige Aktivitäten basieren auf spezifischen Feldänderungen und erfordern die Erstellung benutzerdefinierter Attribute, um deren Zeitstempel zu erfassen. Gehen Sie zum Menü „Berechnungen“ (Taschenrechner-Symbol) und wählen Sie „Standard berechnetes Attribut“. Erstellen Sie für jede der folgenden Aktivitäten ein Attribut. Sie müssen die genauen Namen für Felder und Werte in Ihrer Zendesk-Instanz finden.
- Name: Zeitstempel – Categorized and Prioritized. Formel: IF ([Changes – Field name] = "priority" OR [Changes – Field name] = "type") THEN [Update – Zeitstempel] ENDIF. Nach der Erstellung fügen Sie dieses neue Attribut zum Panel „Zeilen“ hinzu und ändern Sie dessen Aggregator auf MIN.
- Name: Zeitstempel – Info Requested. Formel: IF ([Changes – Field name] = "status" AND [Changes – New value] = "pending") THEN [Update – Zeitstempel] ENDIF. Fügen Sie es zu „Zeilen“ hinzu und setzen Sie den Aggregator auf MIN.
- Name: Zeitstempel – Customer Responded. Formel: IF ([Changes – Field name] = "status" AND [Changes – Previous value] = "pending" AND [Changes – New value] = "open") THEN [Update – Zeitstempel] ENDIF. Fügen Sie es zu „Zeilen“ hinzu und setzen Sie den Aggregator auf MIN.
- Name: Zeitstempel – Escalated. Formel: IF ([Changes – Field name] = "group") THEN [Update – Zeitstempel] ENDIF. Fügen Sie es zu „Zeilen“ hinzu und setzen Sie den Aggregator auf MIN.
- Name: Zeitstempel – SLA Breach. Formel: IF ([SLA breach status]=TRUE) THEN [SLA update – Zeitstempel] ENDIF. Fügen Sie es zu „Zeilen“ hinzu und setzen Sie den Aggregator auf MIN.n8. Daten filtern: Gehen Sie zum Panel „Filter“ und klicken Sie auf „Hinzufügen“. Fügen Sie einen Filter für Ticket created – Date hinzu und wählen Sie einen geeigneten Datumsbereich, z. B. die letzten 3 bis 6 Monate, um den Datensatz überschaubar zu halten.
Bericht ausführen und exportieren: Klicken Sie auf „Speichern“, um die Abfrage auszuführen. Sobald die Tabelle die Daten anzeigt, klicken Sie auf die Schaltfläche „Exportieren“ und wählen Sie Ihr bevorzugtes Format, z. B. CSV oder Excel.
Daten in Event Log-Format modernisieren: Die exportierte Datei liegt im „Wide“-Format vor, wobei jede Zeile ein Ticket und jede Spalte ein Event-Zeitstempel ist. Sie müssen diese für Process Mining in ein „Long“-Format modernisieren. Verwenden Sie ein Tool wie Microsoft Excel (mit der Power Query „Unpivot“-Funktion), Python oder ein anderes Datenvorbereitungstool.
- Erstellen Sie für jede Zeile (Ticket) mehrere neue Zeilen, eine für jede nicht leere Zeitstempelspalte.
- Die endgültige Tabelle sollte Spalten wie ServiceRequest, ActivityName, StartTime und die anderen Attribute enthalten, die für jede Aktivität einer bestimmten Service-Requestn dupliziert werden.

Konfiguration

Datensatz: Der primäre Datensatz ist Support: Tickets. Dies ermöglicht den Zugriff auf die meisten Ticket-Eigenschaften und wichtige Zeitstempel in einer einzigen Abfrage.
Berechtigungen: Sie benötigen mindestens eine Editor- oder Admin-Rolle in Zendesk Explore, um Abfragen zu erstellen und zu speichern.
Datumsbereich: Es ist maßgeblich, einen Datumsbereichsfilter auf Ticket erstellt – Datum zu setzen. Ein Bereich von 3 bis 6 Monaten Daten wird empfohlen, um Erkenntnisse und Leistung auszugleichen. Der Export von Millionen von Tickets kann langsam sein oder fehlschlagen.
Abfragefilter: Erwägen Sie das Hinzufügen von Filtern für spezifische Ticket-Eigenschaften wie Ticket-Marke, Ticket-Formular oder Ticket-Gruppe, um die Analyse auf einen bestimmten Service oder ein Team zu konzentrieren.
Berechnete Attribute: Diese Methode basiert stark auf der Erstellung von Standard-berechneten Attributen, um Zeitstempel für Ereignisse zu erfassen, die keine Standard-Attribute sind, wie Statusänderungen oder Eskalationen. Stellen Sie sicher, dass Sie die Berechtigungen zum Erstellen dieser Attribute haben.

a Beispielabfrage config

This extraction is configured through the Zendesk Explore graphical user interface. There is no single script to execute. The configuration below outlines the components to add in the query builder.

**Dataset**: `Support: Tickets`

**Metrics**:
1.  `COUNT(Tickets)`

**Rows (Attributes)**:
1.  `Ticket ID`
2.  `Assignee name`
3.  `Ticket type`
4.  `Ticket priority`
5.  `Ticket channel`
6.  `SLA resolution time`
7.  `SLA breach status`
8.  `Full resolution time (min)`
9.  `MIN(Ticket created - Timestamp)`
10. `MIN(Ticket assigned - Timestamp)`
11. `MIN(First reply time - Timestamp)`
12. `MIN(Ticket solved - Timestamp)`
13. `MIN(Ticket reopened - Timestamp)`
14. `MIN(Satisfaction rating received - Timestamp)`
15. `MIN(Ticket closed - Timestamp)`
16. `MIN(Timestamp - Categorized and Prioritized)` (Custom calculated attribute)
17. `MIN(Timestamp - Info Requested)` (Custom calculated attribute)
18. `MIN(Timestamp - Customer Responded)` (Custom calculated attribute)
19. `MIN(Timestamp - Escalated)` (Custom calculated attribute)
20. `MIN(Timestamp - SLA Breach)` (Custom calculated attribute)

**Filters**:
1.  `Ticket created - Date`: Select a date range (e.g., last 180 days)

**Standard Calculated Attribute Formulas**:
*   `Timestamp - Categorized and Prioritized`: `IF ([Changes - Field name] = "priority" OR [Changes - Field name] = "type") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Info Requested`: `IF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Customer Responded`: `IF ([Changes - Field name] = "status" AND [Changes - Previous value] = "pending" AND [Changes - New value] = "open") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Escalated`: `IF ([Changes - Field name] = "group") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - SLA Breach`: `IF ([SLA breach status]=TRUE) THEN [SLA update - Timestamp] ENDIF`

Schritte

Zendesk API-Zugang vorbereiten: Melden Sie sich als Administrator bei Zendesk an. Navigieren Sie zum Admin Center, dann zu Apps und Integrationen > APIs > Zendesk API. Stellen Sie unter dem Tab „Einstellungen“ sicher, dass der Token-Zugriff aktiviert ist. Klicken Sie auf „API-Token hinzufügen“, um einen neuen Token zu erstellen. Kopieren Sie den generierten Token sicher, da er nicht erneut angezeigt wird.
Python-Umgebung einrichten: Stellen Sie sicher, dass Python 3.6 oder neuer installiert ist. Installieren Sie die requests-Bibliothek, die für HTTP-Anfragen an die Zendesk-API erforderlich ist. Sie können sie über die Befehlszeile installieren: pip install requests.
Python-Skript konfigurieren: Speichern Sie das bereitgestellte Python-Skript in einer Datei, z. B. extract_zendesk_log.py. Öffnen Sie die Datei in einem Texteditor und aktualisieren Sie die Platzhaltervariablen oben: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL und API_TOKEN mit Ihren spezifischen Zendesk-Instanzdetails und ZugangsDaten.
Extraktionsperiode definieren: Suchen Sie die Variable START_TIMESTAMP im Skript. Dieser Wert bestimmt das historische Startdatum für die Datenextraktion. Es muss ein Unix-Epoch-Zeitstempel sein. Für eine erste Analyse wird ein Wert empfohlen, der den Antrag bearbeitet.en letzten 3 bis 6 Monaten entspricht.
Skript ausführen: Öffnen Sie ein Terminal oder eine Eingabeaufforderung, bewältigen Sie zu dem Verzeichnis, in dem Sie das Skript gespeichert haben, und führen Sie es mit dem Befehl aus: python extract_zendesk_log.py.
Ausführung überwachen: Das Skript gibt Fortschrittsaktualisierungen auf der Konsole aus, die die Anzahl der verarbeiteten Tickets anzeigen. Die gesamte Ausführungszeit hängt vom Volumen der zu extrahierenden Daten und den von Zendesk auferlegten API-Ratenbegrenzungen ab. Das Skript enthält grundlegende Logik zur Behandlung von Ratenbegrenzungsantworten.
Event Log abrufen: Nach erfolgreichem Abschluss erstellt das Skript eine Datei namens zendesk_Event_log.csv im selben Verzeichnis. Diese Datei enthält den strukturierten Event Log, der zur Analyse bereit ist.
Für den Upload vorbereiten: Öffnen Sie die Datei zendesk_Event_log.csv, um sicherzustellen, dass sie korrekt generiert wurde. Überprüfen Sie, ob die Spalten den erforderlichen Attributen entsprechen: ServiceRequest, ActivityName, StartTime, (SourceSystem) und LastDatenUpdate. Die Datei ist nun bereit für den Upload in das Process-Mining-Tool.

Konfiguration

API-ZugangsDaten: Das Skript erfordert eine gültige Zendesk-Subdomain, die E-Mail-Adresse eines Agenten oder Administrators und einen aktiven API-Token. Der Benutzer, der mit den ZugangsDaten verknüpft ist, muss über Berechtigungen zum Lesen von Tickets, Ticket-Audits, Benutzern und Ticket-Metriken verfügen.
Datumsbereich: Das Startdatum der Extraktion wird durch die Variable START_TIMESTAMP im Skript gesteuert, die ein Unix-Epoch-Zeitstempel sein muss. Es ist ratsam, mit einem kürzeren Zeitraum, z. B. 3 Monaten, zu beginnen, um die Ausgabe und Leistung des Skripts zu validieren, bevor ein größerer historischer Datenabruf versucht wird.
Inkrementelle Export-API: Diese Lösung verwendet die inkrementelle Export-API von Zendesk. Dies ist die effizienteste und empfohlene Methode zum Abrufen einer großen Anzahl von Tickets, da sie für den MassenDatenexport konzipiert ist und häufige Paginierungsfallen vermeidet.
Leistung und Ratenbegrenzung: Zendesk erzwingt API-Ratenbegrenzungen, die je nach Abonnementnnementplan variieren. Das Skript verfügt über eine integrierte Logik, um die Ausführung zu pausieren, wenn eine Ratenbegrenzung erreicht wird, basierend auf dem vom API zurückgegebenen Retry-After-Header. Bei sehr großen Instanzen kann die Extraktion mehrere Stunden dauern.
Voraussetzungen: Diese Extraktionsmethode erfordert eine funktionierende Python 3.6+ Umgebung und die externe Bibliothek requests. Administratorzugriff auf die Ziel-Zendesk-Instanz ist erforderlich, um den benötigten API-Token zu generieren.

a Beispielabfrage python

import requests
import json
import time
import datetime
import csv

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Zendesk details
ZENDESK_SUBDOMAIN = class="hl-string">'[your_zendesk_subdomain]'
ZENDESK_EMAIL = class="hl-string">'[your_zendesk_login_email]'
API_TOKEN = class="hl-string">'[your_zendesk_api_token]'

class=class="hl-string">"hl-comment"># Set the start time for the export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1672531200 is Jan 1, 2023 00:00:00 GMT
START_TIMESTAMP = 1672531200

class=class="hl-string">"hl-comment"># --- Script --- 

BASE_URL = fclass="hl-string">'https://{ZENDESK_SUBDOMAIN}.zendesk.com/api/v2'
AUTH = (fclass="hl-string">'{ZENDESK_EMAIL}/token', API_TOKEN)
SOURCE_SYSTEM = class="hl-string">'Zendesk Support'
LAST_DATA_UPDATE = datetime.datetime.utcnow().isoformat() + class="hl-string">'Z'

CSV_FILENAME = class="hl-string">'zendesk_event_log.csv'
CSV_HEADERS = [
    class="hl-string">'ServiceRequest', class="hl-string">'ActivityName', class="hl-string">'StartTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
    class="hl-string">'AssignedAgent', class="hl-string">'ServiceRequestType', class="hl-string">'Priority', class="hl-string">'CommunicationChannel',
    class="hl-string">'SlaTargetResolutionTime', class="hl-string">'IsSlaBreached', class="hl-string">'ServiceRequestResolutionTime'
]

def get_user_name(user_id, users_cache, session):
    if user_id in users_cache:
        return users_cache[user_id]
    if user_id is None:
        return None
    try:
        response = session.get(fclass="hl-string">'{BASE_URL}/users/{user_id}.json')
        response.raise_for_status()
        user_name = response.json().get(class="hl-string">'user', {}).get(class="hl-string">'name')
        users_cache[user_id] = user_name
        return user_name
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">'Warning: Could not fetch user {user_id}. Error: {e}')
        users_cache[user_id] = str(user_id)
        return str(user_id)

def format_duration(seconds):
    if seconds is None:
        return None
    return str(datetime.timedelta(seconds=seconds))

def main():
    session = requests.Session()
    session.auth = AUTH
    users_cache = {}
    event_log = []

    class=class="hl-string">"hl-comment"># Fetch tickets using the incremental export API
    url = fclass="hl-string">'{BASE_URL}/incremental/tickets/cursor.json?start_time={START_TIMESTAMP}'
    ticket_count = 0

    while url:
        print(fclass="hl-string">'Fetching tickets from: {url}')
        try:
            response = session.get(url)

            if response.status_code == 429:
                retry_after = int(response.headers.get(class="hl-string">'Retry-After', 60))
                print(fclass="hl-string">'Rate limit hit. Retrying after {retry_after} seconds.')
                time.sleep(retry_after)
                continue

            response.raise_for_status()
            data = response.json()
            tickets = data.get(class="hl-string">'tickets', [])

            for ticket in tickets:
                ticket_count += 1
                ticket_id = ticket[class="hl-string">'id']
                print(fclass="hl-string">'Processing ticket {ticket_id} ({ticket_count} total)...')

                class=class="hl-string">"hl-comment"># Fetch ticket metrics for SLA and resolution time
                metrics_response = session.get(fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/metrics.json')
                ticket_metrics = metrics_response.json().get(class="hl-string">'ticket_metric', {}) if metrics_response.ok else {}

                resolution_time_seconds = ticket_metrics.get(class="hl-string">'full_resolution_time_in_minutes', {}).get(class="hl-string">'business')
                if resolution_time_seconds:
                    resolution_time_seconds *= 60

                class=class="hl-string">"hl-comment"># Fetch ticket audits for events
                audits_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/audits.json'
                audits_response = session.get(audits_url)
                audits = audits_response.json().get(class="hl-string">'audits', []) if audits_response.ok else []

                first_agent_reply_sent = False

                for audit in audits:
                    audit_created_at = audit[class="hl-string">'created_at']
                    base_event = {
                        class="hl-string">'ServiceRequest': ticket_id,
                        class="hl-string">'StartTime': audit_created_at,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'AssignedAgent': get_user_name(ticket.get(class="hl-string">'assignee_id'), users_cache, session),
                        class="hl-string">'ServiceRequestType': ticket.get(class="hl-string">'type'),
                        class="hl-string">'Priority': ticket.get(class="hl-string">'priority'),
                        class="hl-string">'CommunicationChannel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
                        class="hl-string">'SlaTargetResolutionTime': None, class=class="hl-string">"hl-comment"># Requires parsing SLA policies, complex
                        class="hl-string">'IsSlaBreached': ticket_metrics.get(class="hl-string">'sla_breach_at') is not None,
                        class="hl-string">'ServiceRequestResolutionTime': format_duration(resolution_time_seconds)
                    }

                    for event in audit.get(class="hl-string">'events', []):
                        event_type = event.get(class="hl-string">'type')
                        class=class="hl-string">"hl-comment"># Service Request Created
                        if event_type == class="hl-string">'Create' and event.get(class="hl-string">'field_name') == class="hl-string">'id':
                            new_event = base_event.copy()
                            new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Created'
                            event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># Initial Acknowledgment Sent (Proxy by Notification event)
                        if event_type == class="hl-string">'Notification':
                            new_event = base_event.copy()
                            new_event[class="hl-string">'ActivityName'] = class="hl-string">'Initial Acknowledgment Sent'
                            event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># Request Categorized And Prioritized, Assigned, Status Changes
                        if event_type == class="hl-string">'Change':
                            field = event.get(class="hl-string">'field_name')
                            if field in [class="hl-string">'type', class="hl-string">'priority', class="hl-string">'custom_field_[your_category_field_id]']:
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Request Categorized And Prioritized'
                                event_log.append(new_event)
                            
                            if field == class="hl-string">'assignee_id':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Request Assigned To Agent'
                                new_event[class="hl-string">'AssignedAgent'] = get_user_name(event.get(class="hl-string">'value'), users_cache, session)
                                event_log.append(new_event)

                            if field == class="hl-string">'group_id':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Internal Escalation Triggered'
                                event_log.append(new_event)

                            if field == class="hl-string">'status':
                                new_status = event.get(class="hl-string">'value')
                                if new_status == class="hl-string">'pending':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Information Requested From Customer'
                                    event_log.append(new_event)
                                elif new_status == class="hl-string">'solved':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Resolved'
                                    event_log.append(new_event)
                                    class=class="hl-string">"hl-comment"># Satisfaction Survey Sent (Proxy: occurs after solve)
                                    solve_time = datetime.datetime.fromisoformat(audit_created_at.replace(class="hl-string">'Z', class="hl-string">'+00:00'))
                                    survey_time = solve_time + datetime.timedelta(hours=1)
                                    survey_event = new_event.copy()
                                    survey_event[class="hl-string">'ActivityName'] = class="hl-string">'Satisfaction Survey Sent'
                                    survey_event[class="hl-string">'StartTime'] = survey_time.isoformat().replace(class="hl-string">'+00:00', class="hl-string">'Z')
                                    event_log.append(survey_event)
                                elif new_status == class="hl-string">'closed':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Closed'
                                    event_log.append(new_event)
                                elif new_status == class="hl-string">'open' and event.get(class="hl-string">'previous_value') in [class="hl-string">'solved', class="hl-string">'pending']:
                                    activity = class="hl-string">'Service Request Reopened' if event.get(class="hl-string">'previous_value') == class="hl-string">'solved' else class="hl-string">'Customer Responded'
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = activity
                                    event_log.append(new_event)
                            
                            if field == class="hl-string">'satisfaction_score':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Satisfaction Rating Received'
                                event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># First Agent Public Reply Sent & Customer Responded
                        if event_type == class="hl-string">'Comment':
                            author_id = event.get(class="hl-string">'author_id')
                            author_details_response = session.get(fclass="hl-string">'{BASE_URL}/users/{author_id}.json')
                            author_role = author_details_response.json().get(class="hl-string">'user',{}).get(class="hl-string">'role', class="hl-string">'end-user') if author_details_response.ok else class="hl-string">'end-user'

                            if author_role in [class="hl-string">'agent', class="hl-string">'admin'] and event.get(class="hl-string">'public') and not first_agent_reply_sent:
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'First Agent Public Reply Sent'
                                event_log.append(new_event)
                                first_agent_reply_sent = True

                class=class="hl-string">"hl-comment"># SLA Breach Occurred
                if ticket_metrics.get(class="hl-string">'sla_breach_at'):
                    sla_breach_time = ticket_metrics.get(class="hl-string">'sla_breach_at')
                    new_event = base_event.copy()
                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'SLA Breach Occurred'
                    new_event[class="hl-string">'StartTime'] = sla_breach_time
                    event_log.append(new_event)

            url = data.get(class="hl-string">'after_url')
            if not data.get(class="hl-string">'end_of_stream', False):
                time.sleep(1) class=class="hl-string">"hl-comment"># Be a good API citizen
            else:
                url = None

        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">'An error occurred: {e}')
            break

    class=class="hl-string">"hl-comment"># Write to CSV
    print(fclass="hl-string">'Writing {len(event_log)} events to {CSV_FILENAME}...')
    with open(CSV_FILENAME, class="hl-string">'w', newline=class="hl-string">'', encoding=class="hl-string">'utf-8') as csvfile:
        writer = csv.DictWriter(csvfile, fieldnames=CSV_HEADERS)
        writer.writeheader()
        class=class="hl-string">"hl-comment"># Sort events by ticket and then by time for chronological order
        sorted_log = sorted(event_log, key=lambda x: (x[class="hl-string">'ServiceRequest'], x[class="hl-string">'StartTime']))
        for row in sorted_log:
            writer.writerow(row)
    print(class="hl-string">'Extraction complete.')

if __name__ == class="hl-string">'__main__':
    main()

Schritte

Zendesk API-Zugang vorbereiten: Melden Sie sich als Administrator bei Zendesk an. Navigieren Sie zum Admin Center, dann zu Apps und Integrationen > APIs > Zendesk API. Stellen Sie unter dem Tab „Einstellungen“ sicher, dass der Token-Zugriff aktiviert ist. Klicken Sie auf „API-Token hinzufügen“, um einen neuen Token zu erstellen. Kopieren Sie den generierten Token sicher, da er nicht erneut angezeigt wird.
Python-Umgebung einrichten: Stellen Sie sicher, dass Python 3.6 oder neuer installiert ist. Installieren Sie die requests-Bibliothek, die für HTTP-Anfragen an die Zendesk-API erforderlich ist. Sie können sie über die Befehlszeile installieren: pip install requests.
Python-Skript konfigurieren: Speichern Sie das bereitgestellte Python-Skript in einer Datei, z. B. extract_zendesk_log.py. Öffnen Sie die Datei in einem Texteditor und aktualisieren Sie die Platzhaltervariablen oben: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL und API_TOKEN mit Ihren spezifischen Zendesk-Instanzdetails und ZugangsDaten.
Extraktionsperiode definieren: Suchen Sie die Variable START_TIMESTAMP im Skript. Dieser Wert bestimmt das historische Startdatum für die Datenextraktion. Es muss ein Unix-Epoch-Zeitstempel sein. Für eine erste Analyse wird ein Wert empfohlen, der den Antrag bearbeitet.en letzten 3 bis 6 Monaten entspricht.
Skript ausführen: Öffnen Sie ein Terminal oder eine Eingabeaufforderung, bewältigen Sie zu dem Verzeichnis, in dem Sie das Skript gespeichert haben, und führen Sie es mit dem Befehl aus: python extract_zendesk_log.py.
Ausführung überwachen: Das Skript gibt Fortschrittsaktualisierungen auf der Konsole aus, die die Anzahl der verarbeiteten Tickets anzeigen. Die gesamte Ausführungszeit hängt vom Volumen der zu extrahierenden Daten und den von Zendesk auferlegten API-Ratenbegrenzungen ab. Das Skript enthält grundlegende Logik zur Behandlung von Ratenbegrenzungsantworten.
Event Log abrufen: Nach erfolgreichem Abschluss erstellt das Skript eine Datei namens zendesk_Event_log.csv im selben Verzeichnis. Diese Datei enthält den strukturierten Event Log, der zur Analyse bereit ist.
Für den Upload vorbereiten: Öffnen Sie die Datei zendesk_Event_log.csv, um sicherzustellen, dass sie korrekt generiert wurde. Überprüfen Sie, ob die Spalten den erforderlichen Attributen entsprechen: ServiceRequest, ActivityName, StartTime, (SourceSystem) und LastDatenUpdate. Die Datei ist nun bereit für den Upload in das Process-Mining-Tool.

Konfiguration

API-ZugangsDaten: Das Skript erfordert eine gültige Zendesk-Subdomain, die E-Mail-Adresse eines Agenten oder Administrators und einen aktiven API-Token. Der Benutzer, der mit den ZugangsDaten verknüpft ist, muss über Berechtigungen zum Lesen von Tickets, Ticket-Audits, Benutzern und Ticket-Metriken verfügen.
Datumsbereich: Das Startdatum der Extraktion wird durch die Variable START_TIMESTAMP im Skript gesteuert, die ein Unix-Epoch-Zeitstempel sein muss. Es ist ratsam, mit einem kürzeren Zeitraum, z. B. 3 Monaten, zu beginnen, um die Ausgabe und Leistung des Skripts zu validieren, bevor ein größerer historischer Datenabruf versucht wird.
Inkrementelle Export-API: Diese Lösung verwendet die inkrementelle Export-API von Zendesk. Dies ist die effizienteste und empfohlene Methode zum Abrufen einer großen Anzahl von Tickets, da sie für den MassenDatenexport konzipiert ist und häufige Paginierungsfallen vermeidet.
Leistung und Ratenbegrenzung: Zendesk erzwingt API-Ratenbegrenzungen, die je nach Abonnementnnementplan variieren. Das Skript verfügt über eine integrierte Logik, um die Ausführung zu pausieren, wenn eine Ratenbegrenzung erreicht wird, basierend auf dem vom API zurückgegebenen Retry-After-Header. Bei sehr großen Instanzen kann die Extraktion mehrere Stunden dauern.
Voraussetzungen: Diese Extraktionsmethode erfordert eine funktionierende Python 3.6+ Umgebung und die externe Bibliothek requests. Administratorzugriff auf die Ziel-Zendesk-Instanz ist erforderlich, um den benötigten API-Token zu generieren.

a Beispielabfrage python

import requests
import json
import time
import datetime
import csv

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Zendesk details
ZENDESK_SUBDOMAIN = class="hl-string">'[your_zendesk_subdomain]'
ZENDESK_EMAIL = class="hl-string">'[your_zendesk_login_email]'
API_TOKEN = class="hl-string">'[your_zendesk_api_token]'

class=class="hl-string">"hl-comment"># Set the start time for the export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1672531200 is Jan 1, 2023 00:00:00 GMT
START_TIMESTAMP = 1672531200

class=class="hl-string">"hl-comment"># --- Script --- 

BASE_URL = fclass="hl-string">'https://{ZENDESK_SUBDOMAIN}.zendesk.com/api/v2'
AUTH = (fclass="hl-string">'{ZENDESK_EMAIL}/token', API_TOKEN)
SOURCE_SYSTEM = class="hl-string">'Zendesk Support'
LAST_DATA_UPDATE = datetime.datetime.utcnow().isoformat() + class="hl-string">'Z'

CSV_FILENAME = class="hl-string">'zendesk_event_log.csv'
CSV_HEADERS = [
    class="hl-string">'ServiceRequest', class="hl-string">'ActivityName', class="hl-string">'StartTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
    class="hl-string">'AssignedAgent', class="hl-string">'ServiceRequestType', class="hl-string">'Priority', class="hl-string">'CommunicationChannel',
    class="hl-string">'SlaTargetResolutionTime', class="hl-string">'IsSlaBreached', class="hl-string">'ServiceRequestResolutionTime'
]

def get_user_name(user_id, users_cache, session):
    if user_id in users_cache:
        return users_cache[user_id]
    if user_id is None:
        return None
    try:
        response = session.get(fclass="hl-string">'{BASE_URL}/users/{user_id}.json')
        response.raise_for_status()
        user_name = response.json().get(class="hl-string">'user', {}).get(class="hl-string">'name')
        users_cache[user_id] = user_name
        return user_name
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">'Warning: Could not fetch user {user_id}. Error: {e}')
        users_cache[user_id] = str(user_id)
        return str(user_id)

def format_duration(seconds):
    if seconds is None:
        return None
    return str(datetime.timedelta(seconds=seconds))

def main():
    session = requests.Session()
    session.auth = AUTH
    users_cache = {}
    event_log = []

    class=class="hl-string">"hl-comment"># Fetch tickets using the incremental export API
    url = fclass="hl-string">'{BASE_URL}/incremental/tickets/cursor.json?start_time={START_TIMESTAMP}'
    ticket_count = 0

    while url:
        print(fclass="hl-string">'Fetching tickets from: {url}')
        try:
            response = session.get(url)

            if response.status_code == 429:
                retry_after = int(response.headers.get(class="hl-string">'Retry-After', 60))
                print(fclass="hl-string">'Rate limit hit. Retrying after {retry_after} seconds.')
                time.sleep(retry_after)
                continue

            response.raise_for_status()
            data = response.json()
            tickets = data.get(class="hl-string">'tickets', [])

            for ticket in tickets:
                ticket_count += 1
                ticket_id = ticket[class="hl-string">'id']
                print(fclass="hl-string">'Processing ticket {ticket_id} ({ticket_count} total)...')

                class=class="hl-string">"hl-comment"># Fetch ticket metrics for SLA and resolution time
                metrics_response = session.get(fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/metrics.json')
                ticket_metrics = metrics_response.json().get(class="hl-string">'ticket_metric', {}) if metrics_response.ok else {}

                resolution_time_seconds = ticket_metrics.get(class="hl-string">'full_resolution_time_in_minutes', {}).get(class="hl-string">'business')
                if resolution_time_seconds:
                    resolution_time_seconds *= 60

                class=class="hl-string">"hl-comment"># Fetch ticket audits for events
                audits_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/audits.json'
                audits_response = session.get(audits_url)
                audits = audits_response.json().get(class="hl-string">'audits', []) if audits_response.ok else []

                first_agent_reply_sent = False

                for audit in audits:
                    audit_created_at = audit[class="hl-string">'created_at']
                    base_event = {
                        class="hl-string">'ServiceRequest': ticket_id,
                        class="hl-string">'StartTime': audit_created_at,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'AssignedAgent': get_user_name(ticket.get(class="hl-string">'assignee_id'), users_cache, session),
                        class="hl-string">'ServiceRequestType': ticket.get(class="hl-string">'type'),
                        class="hl-string">'Priority': ticket.get(class="hl-string">'priority'),
                        class="hl-string">'CommunicationChannel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
                        class="hl-string">'SlaTargetResolutionTime': None, class=class="hl-string">"hl-comment"># Requires parsing SLA policies, complex
                        class="hl-string">'IsSlaBreached': ticket_metrics.get(class="hl-string">'sla_breach_at') is not None,
                        class="hl-string">'ServiceRequestResolutionTime': format_duration(resolution_time_seconds)
                    }

                    for event in audit.get(class="hl-string">'events', []):
                        event_type = event.get(class="hl-string">'type')
                        class=class="hl-string">"hl-comment"># Service Request Created
                        if event_type == class="hl-string">'Create' and event.get(class="hl-string">'field_name') == class="hl-string">'id':
                            new_event = base_event.copy()
                            new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Created'
                            event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># Initial Acknowledgment Sent (Proxy by Notification event)
                        if event_type == class="hl-string">'Notification':
                            new_event = base_event.copy()
                            new_event[class="hl-string">'ActivityName'] = class="hl-string">'Initial Acknowledgment Sent'
                            event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># Request Categorized And Prioritized, Assigned, Status Changes
                        if event_type == class="hl-string">'Change':
                            field = event.get(class="hl-string">'field_name')
                            if field in [class="hl-string">'type', class="hl-string">'priority', class="hl-string">'custom_field_[your_category_field_id]']:
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Request Categorized And Prioritized'
                                event_log.append(new_event)
                            
                            if field == class="hl-string">'assignee_id':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Request Assigned To Agent'
                                new_event[class="hl-string">'AssignedAgent'] = get_user_name(event.get(class="hl-string">'value'), users_cache, session)
                                event_log.append(new_event)

                            if field == class="hl-string">'group_id':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Internal Escalation Triggered'
                                event_log.append(new_event)

                            if field == class="hl-string">'status':
                                new_status = event.get(class="hl-string">'value')
                                if new_status == class="hl-string">'pending':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Information Requested From Customer'
                                    event_log.append(new_event)
                                elif new_status == class="hl-string">'solved':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Resolved'
                                    event_log.append(new_event)
                                    class=class="hl-string">"hl-comment"># Satisfaction Survey Sent (Proxy: occurs after solve)
                                    solve_time = datetime.datetime.fromisoformat(audit_created_at.replace(class="hl-string">'Z', class="hl-string">'+00:00'))
                                    survey_time = solve_time + datetime.timedelta(hours=1)
                                    survey_event = new_event.copy()
                                    survey_event[class="hl-string">'ActivityName'] = class="hl-string">'Satisfaction Survey Sent'
                                    survey_event[class="hl-string">'StartTime'] = survey_time.isoformat().replace(class="hl-string">'+00:00', class="hl-string">'Z')
                                    event_log.append(survey_event)
                                elif new_status == class="hl-string">'closed':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Closed'
                                    event_log.append(new_event)
                                elif new_status == class="hl-string">'open' and event.get(class="hl-string">'previous_value') in [class="hl-string">'solved', class="hl-string">'pending']:
                                    activity = class="hl-string">'Service Request Reopened' if event.get(class="hl-string">'previous_value') == class="hl-string">'solved' else class="hl-string">'Customer Responded'
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = activity
                                    event_log.append(new_event)
                            
                            if field == class="hl-string">'satisfaction_score':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Satisfaction Rating Received'
                                event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># First Agent Public Reply Sent & Customer Responded
                        if event_type == class="hl-string">'Comment':
                            author_id = event.get(class="hl-string">'author_id')
                            author_details_response = session.get(fclass="hl-string">'{BASE_URL}/users/{author_id}.json')
                            author_role = author_details_response.json().get(class="hl-string">'user',{}).get(class="hl-string">'role', class="hl-string">'end-user') if author_details_response.ok else class="hl-string">'end-user'

                            if author_role in [class="hl-string">'agent', class="hl-string">'admin'] and event.get(class="hl-string">'public') and not first_agent_reply_sent:
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'First Agent Public Reply Sent'
                                event_log.append(new_event)
                                first_agent_reply_sent = True

                class=class="hl-string">"hl-comment"># SLA Breach Occurred
                if ticket_metrics.get(class="hl-string">'sla_breach_at'):
                    sla_breach_time = ticket_metrics.get(class="hl-string">'sla_breach_at')
                    new_event = base_event.copy()
                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'SLA Breach Occurred'
                    new_event[class="hl-string">'StartTime'] = sla_breach_time
                    event_log.append(new_event)

            url = data.get(class="hl-string">'after_url')
            if not data.get(class="hl-string">'end_of_stream', False):
                time.sleep(1) class=class="hl-string">"hl-comment"># Be a good API citizen
            else:
                url = None

        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">'An error occurred: {e}')
            break

    class=class="hl-string">"hl-comment"># Write to CSV
    print(fclass="hl-string">'Writing {len(event_log)} events to {CSV_FILENAME}...')
    with open(CSV_FILENAME, class="hl-string">'w', newline=class="hl-string">'', encoding=class="hl-string">'utf-8') as csvfile:
        writer = csv.DictWriter(csvfile, fieldnames=CSV_HEADERS)
        writer.writeheader()
        class=class="hl-string">"hl-comment"># Sort events by ticket and then by time for chronological order
        sorted_log = sorted(event_log, key=lambda x: (x[class="hl-string">'ServiceRequest'], x[class="hl-string">'StartTime']))
        for row in sorted_log:
            writer.writerow(row)
    print(class="hl-string">'Extraction complete.')

if __name__ == class="hl-string">'__main__':
    main()

Schritte

Navigieren Sie zu Zendesk Explore: Melden Sie sich bei Ihrer Zendesk-Instanz an und öffnen Sie das Explore-Produkt, indem Sie auf das Produktsymbol in der oberen Leiste klicken und Explore auswählen.
Neue Abfrage erstellen: Klicken Sie in Explore in der linken Seitenleiste auf das Abfrage-Symbol und dann oben rechts auf die Schaltfläche „Neue Abfrage“.
Datensatz auswählen: Wählen Sie im Fenster „Datensatz auswählen“ den Datensatz Support: Tickets aus. Dieser Datensatz enthält die primären Ticket-Attribute und wichtige Event-Zeitstempel.
Metriken hinzufügen: Gehen Sie im Abfrage-Builder zum Panel „Metriken“ und klicken Sie auf „Hinzufügen“. Wählen Sie COUNT(Tickets). Dies hilft bei der Validierung des Datenvolumens.
Attribute zu Zeilen hinzufügen: Gehen Sie zum Panel „Zeilen“ und klicken Sie auf „Hinzufügen“. Fügen Sie die folgenden Attribute hinzu. Diese bilden die Basisspalten Ihres Exports im Wide-Format.
- Ticket ID (Dies ist Ihr Case-ID, ServiceRequest)
- Assignee name (AssignedAgent)
- Ticket type (ServiceRequestTyp)
- Ticket priority (Priority)
- Ticket channel (CommunicationChannel)
- SLA resolution time (SlaTargetResolutionTime)
- SLA breach status (IsSlaBreached)
- Full resolution time (min) (ServiceRequestResolutionTime)
Aktivitäts-Zeitstempel zu Zeilen hinzufügen: Fügen Sie die folgenden Zeitstempel-Attribute zum Panel „Zeilen“ hinzu. Jedes davon stellt eine potenzielle Aktivität dar. Einige Aktivitäten erfordern die Erstellung eines benutzerdefinierten berechneten Attributs.
- Ticket created – Zeitstempel: Für Service Request Created und Initial Acknowledgment Sent.
- Ticket assigned – Zeitstempel: Für Request Assigned To Agent.
- First reply time – Zeitstempel: Für First Agent Public Reply Sent.
- Ticket solved – Zeitstempel: Für Service Request Resolved und Satisfaction Survey Sent.
- Ticket reopened – Zeitstempel: Für Service Request Reopened.
- Satisfaction rating received – Zeitstempel: Für Satisfaction Rating Received.
- Ticket closed – Zeitstempel: Für Service Request Closed.
Benutzerdefinierte berechnete Attribute für andere Aktivitäten erstellen: Einige Aktivitäten basieren auf spezifischen Feldänderungen und erfordern die Erstellung benutzerdefinierter Attribute, um deren Zeitstempel zu erfassen. Gehen Sie zum Menü „Berechnungen“ (Taschenrechner-Symbol) und wählen Sie „Standard berechnetes Attribut“. Erstellen Sie für jede der folgenden Aktivitäten ein Attribut. Sie müssen die genauen Namen für Felder und Werte in Ihrer Zendesk-Instanz finden.
- Name: Zeitstempel – Categorized and Prioritized. Formel: IF ([Changes – Field name] = "priority" OR [Changes – Field name] = "type") THEN [Update – Zeitstempel] ENDIF. Nach der Erstellung fügen Sie dieses neue Attribut zum Panel „Zeilen“ hinzu und ändern Sie dessen Aggregator auf MIN.
- Name: Zeitstempel – Info Requested. Formel: IF ([Changes – Field name] = "status" AND [Changes – New value] = "pending") THEN [Update – Zeitstempel] ENDIF. Fügen Sie es zu „Zeilen“ hinzu und setzen Sie den Aggregator auf MIN.
- Name: Zeitstempel – Customer Responded. Formel: IF ([Changes – Field name] = "status" AND [Changes – Previous value] = "pending" AND [Changes – New value] = "open") THEN [Update – Zeitstempel] ENDIF. Fügen Sie es zu „Zeilen“ hinzu und setzen Sie den Aggregator auf MIN.
- Name: Zeitstempel – Escalated. Formel: IF ([Changes – Field name] = "group") THEN [Update – Zeitstempel] ENDIF. Fügen Sie es zu „Zeilen“ hinzu und setzen Sie den Aggregator auf MIN.
- Name: Zeitstempel – SLA Breach. Formel: IF ([SLA breach status]=TRUE) THEN [SLA update – Zeitstempel] ENDIF. Fügen Sie es zu „Zeilen“ hinzu und setzen Sie den Aggregator auf MIN.n8. Daten filtern: Gehen Sie zum Panel „Filter“ und klicken Sie auf „Hinzufügen“. Fügen Sie einen Filter für Ticket created – Date hinzu und wählen Sie einen geeigneten Datumsbereich, z. B. die letzten 3 bis 6 Monate, um den Datensatz überschaubar zu halten.
Bericht ausführen und exportieren: Klicken Sie auf „Speichern“, um die Abfrage auszuführen. Sobald die Tabelle die Daten anzeigt, klicken Sie auf die Schaltfläche „Exportieren“ und wählen Sie Ihr bevorzugtes Format, z. B. CSV oder Excel.
Daten in Event Log-Format modernisieren: Die exportierte Datei liegt im „Wide“-Format vor, wobei jede Zeile ein Ticket und jede Spalte ein Event-Zeitstempel ist. Sie müssen diese für Process Mining in ein „Long“-Format modernisieren. Verwenden Sie ein Tool wie Microsoft Excel (mit der Power Query „Unpivot“-Funktion), Python oder ein anderes Datenvorbereitungstool.
- Erstellen Sie für jede Zeile (Ticket) mehrere neue Zeilen, eine für jede nicht leere Zeitstempelspalte.
- Die endgültige Tabelle sollte Spalten wie ServiceRequest, ActivityName, StartTime und die anderen Attribute enthalten, die für jede Aktivität einer bestimmten Service-Requestn dupliziert werden.

Konfiguration

Datensatz: Der primäre Datensatz ist Support: Tickets. Dies ermöglicht den Zugriff auf die meisten Ticket-Eigenschaften und wichtige Zeitstempel in einer einzigen Abfrage.
Berechtigungen: Sie benötigen mindestens eine Editor- oder Admin-Rolle in Zendesk Explore, um Abfragen zu erstellen und zu speichern.
Datumsbereich: Es ist maßgeblich, einen Datumsbereichsfilter auf Ticket erstellt – Datum zu setzen. Ein Bereich von 3 bis 6 Monaten Daten wird empfohlen, um Erkenntnisse und Leistung auszugleichen. Der Export von Millionen von Tickets kann langsam sein oder fehlschlagen.
Abfragefilter: Erwägen Sie das Hinzufügen von Filtern für spezifische Ticket-Eigenschaften wie Ticket-Marke, Ticket-Formular oder Ticket-Gruppe, um die Analyse auf einen bestimmten Service oder ein Team zu konzentrieren.
Berechnete Attribute: Diese Methode basiert stark auf der Erstellung von Standard-berechneten Attributen, um Zeitstempel für Ereignisse zu erfassen, die keine Standard-Attribute sind, wie Statusänderungen oder Eskalationen. Stellen Sie sicher, dass Sie die Berechtigungen zum Erstellen dieser Attribute haben.

a Beispielabfrage config

This extraction is configured through the Zendesk Explore graphical user interface. There is no single script to execute. The configuration below outlines the components to add in the query builder.

**Dataset**: `Support: Tickets`

**Metrics**:
1.  `COUNT(Tickets)`

**Rows (Attributes)**:
1.  `Ticket ID`
2.  `Assignee name`
3.  `Ticket type`
4.  `Ticket priority`
5.  `Ticket channel`
6.  `SLA resolution time`
7.  `SLA breach status`
8.  `Full resolution time (min)`
9.  `MIN(Ticket created - Timestamp)`
10. `MIN(Ticket assigned - Timestamp)`
11. `MIN(First reply time - Timestamp)`
12. `MIN(Ticket solved - Timestamp)`
13. `MIN(Ticket reopened - Timestamp)`
14. `MIN(Satisfaction rating received - Timestamp)`
15. `MIN(Ticket closed - Timestamp)`
16. `MIN(Timestamp - Categorized and Prioritized)` (Custom calculated attribute)
17. `MIN(Timestamp - Info Requested)` (Custom calculated attribute)
18. `MIN(Timestamp - Customer Responded)` (Custom calculated attribute)
19. `MIN(Timestamp - Escalated)` (Custom calculated attribute)
20. `MIN(Timestamp - SLA Breach)` (Custom calculated attribute)

**Filters**:
1.  `Ticket created - Date`: Select a date range (e.g., last 180 days)

**Standard Calculated Attribute Formulas**:
*   `Timestamp - Categorized and Prioritized`: `IF ([Changes - Field name] = "priority" OR [Changes - Field name] = "type") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Info Requested`: `IF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Customer Responded`: `IF ([Changes - Field name] = "status" AND [Changes - Previous value] = "pending" AND [Changes - New value] = "open") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Escalated`: `IF ([Changes - Field name] = "group") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - SLA Breach`: `IF ([SLA breach status]=TRUE) THEN [SLA update - Timestamp] ENDIF`

Ihr Kundenservice-Daten-Template

Ihr Kundenservice-Daten-Template

Kundenservice-Attribute

Kundenservice-Aktivitäten

Extraktionsanleitungen

Zendesk Explore UI für Berichts- und Datenexport

Schritte

Konfiguration

a Beispielabfrage config

Python-Skript mit der Zendesk Support REST API

Schritte

Konfiguration

a Beispielabfrage python

Zendesk Incremental Exports API für MassenDaten

Schritte

Konfiguration

a Beispielabfrage python

Drittanbieter ETL-Tool-Konnektor für Zendesk

Schritte

Konfiguration

a Beispielabfrage config

Bereit, um loszulegen?

Kundenservice-Engpässe beenden, CSAT jetzt steigern

Ihr Kundenservice-Daten-Template

Ihr Kundenservice-Daten-Template

Kundenservice-Attribute

Kundenservice-Aktivitäten

Extraktionsanleitungen

Zendesk Explore UI für Berichts- und Datenexport

Schritte

Konfiguration

a Beispielabfrage config

Python-Skript mit der Zendesk Support REST API

Schritte

Konfiguration

a Beispielabfrage python

Zendesk Incremental Exports API für MassenDaten

Schritte

Konfiguration

a Beispielabfrage python

Drittanbieter ETL-Tool-Konnektor für Zendesk

Schritte

Konfiguration

a Beispielabfrage config

Ihre Privatsphäre ist uns wichtig

Bereit, um loszulegen?

Kundenservice-Engpässe beenden, CSAT jetzt steigern