> Kontinuierliche Prozessoptimierung > `Incident Management` > Zendesk Support > Datenvorlage

Ihr `Incident Management Data Template`

Zendesk Support

`Incident Management`-`Attribute` (24) `Incident Management`-Aktivitäten (13) Extraktionsleitfäden (4)

Ihr `Incident Management Data Template`

Dieses Template bietet eine strukturierte Übersicht über die essenziellen Daten, die zur effektiven Analyse Ihres Incident Management Prozesses erforderlich sind. Es skizziert wichtige Attribute, zu verfolgende kritische Aktivitäten und enthält praktische Anleitungen zur Extraktion dieser Daten aus Zendesk Support. Nutzen Sie es, um sicherzustellen, dass Ihr Process Mining Projekt mit einem leistungsstarken und vollständigen Datensatz beginnt.

Empfohlene Attribute zur Erfassung
Wichtige Aktivitäten zur Verfolgung für die Prozesskartierung
Praktische Anleitung zur Datenextraktion

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

Vorlage herunterladen

`Incident Management`-`Attribute`

Dies sind die empfohlenen Datenfelder, die in Ihrem Event Log enthalten sein sollten, um eine gründliche Analyse Ihres Incident Management Prozesses zu gewährleisten.

5 Erforderlich 7 Empfohlen 12 Optional

	Name	Beschreibung
	`Incident`-ID TicketId	Die eindeutige, systemgenerierte Kennung für jedes Incident-Ticket.
Beschreibung Die Incident ID ist der Primärschlüssel, der jeden Incident-Case innerhalb von Zendesk Support eindeutig identifiziert. Sie dient als CaseId für Process Mining und verknüpft alle zugehörigen Aktivitäten, Statusänderungen und Mitteilungen vom Moment der Incident-Erstellung bis zu dessen Abschluss. In der Analyse ist diese ID entscheidend für die Rekonstruktion des End-to-End-Weges jedes Incidents. Sie ermöglicht die Aggregation von Event-Daten, um Metriken wie die gesamte Lösungszeit, die Anzahl der Übergaben und die Einhaltung von Service Level Agreements für einzelne Cases zu verfolgen. Durch das Gruppieren von Events nach dieser ID können Analysten Prozessflüsse visualisieren, gängige Pfade identifizieren und Abweichungen vom Standardverfahren erkennen. Bedeutung Dies ist der essenzielle Identifikator, der alle Events mit einem einzelnen Incident verbindet, wodurch es möglich wird, den gesamten Lebenszyklus zu verfolgen und die Prozessleistung präzise zu analysieren. Datenquelle Zendesk Tickets API (/api/v2/tickets/{id}), Feld id. Beispiele 19428230113521941055
	Ereignis-Timestamp EventTimestamp	Das genaue Datum und die Uhrzeit, zu der die Aktivität stattgefunden hat.
Beschreibung Dieser Timestamp erfasst den genauen Moment, in dem ein Event im Incident-Lebenszyklus stattfand, z.B. wann ein Kommentar hinzugefügt oder der Status geändert wurde. Er liefert die chronologische Reihenfolge für alle Aktivitäten innerhalb eines Cases. Dieses Attribut ist fundamental für jede zeitbasierte Process Mining Analyse. Es wird verwendet, um Zykluszeiten zwischen Aktivitäten zu berechnen, Wartezeiten zu identifizieren, die gesamte Case Duration zu messen und die Prozessleistung über verschiedene Zeiträume zu analysieren. Genaue Timestamps sind unerlässlich, um eine animierte Prozesslandkarte zu erstellen, die den Fluss von Cases über die Zeit zeigt, und um Performance Dashboards zu erstellen, die KPIs wie die durchschnittliche Lösungszeit verfolgen. Bedeutung Timestamps liefern den chronologischen Kontext für alle Aktivitäten, ermöglichen die Berechnung von Dauern, die Identifizierung von Bottlenecks und die Analyse der Prozessleistung über die Zeit. Datenquelle Zendesk Ticket Audits API (/api/v2/tickets/{ticket_id}/audits), Feld created_at für jedes Audit-Event. Beispiele 2023-04-15T10:00:00Z2023-04-15T10:05:12Z2023-04-16T14:30:00Z
	Aktivität ActivityName	Der Name der Geschäftsaktivität oder des Events, das zu einem bestimmten Zeitpunkt im Incident-Lebenszyklus aufgetreten ist.
Beschreibung Dieses Attribut beschreibt einen spezifischen Schritt oder eine Aktion innerhalb des Incident Management Prozesses, z.B. 'Incident Created', 'Ticket Assigned to Agent' oder 'Incident Resolved'. Diese Aktivitäten werden aus dem Event Log oder den Audit-Trail-Daten von Zendesk abgeleitet, wo Systemänderungen aufgezeichnet werden. Im Process Mining bildet die Abfolge dieser Aktivitäten die Prozesslandkarte, die die Grundlage für alle Analysen ist. Durch die Analyse des Aktivitätsflusses können Organisationen die tatsächlichen Wege erkennen, die Incidents nehmen, Bottlenecks zwischen Schritten identifizieren, Nacharbeitszyklen messen (z.B. das erneute Öffnen eines gelösten Tickets) und die Konformität mit einem definierten Standardprozess überprüfen. Bedeutung Die Abfolge der Aktivitäten definiert den Prozessfluss, der den Kern der Process Mining Analyse bildet, um Ineffizienzen, Abweichungen und Verbesserungsmöglichkeiten zu identifizieren. Datenquelle Abgeleitet von Events in der Zendesk Ticket Audits API. Zum Beispiel könnte ein Change-Event im Statusfeld auf „Status geändert“ abgebildet werden. Beispiele `Incident` erstelltTicket einem Agenten zugewiesenStatus auf 'Ausstehend' geändert`Incident` gelöstIncident geschlossen
	Letzte Datenaktualisierung LastDataUpdate	Der Timestamp, der angibt, wann die Daten für diesen Prozess zuletzt aktualisiert wurden.
Beschreibung Dieses Attribut erfasst Datum und Uhrzeit der letzten Datenextraktion oder Aktualisierung aus dem Quellsystem. Es ist typischerweise ein Einzelwert, der auf den gesamten Datensatz eines gegebenen Aktualisierungszyklus angewendet wird. Diese Information ist entscheidend für die Data Governance und für die Nutzer der Process Mining Analyse. Sie bietet Kontext zur Datenaktualität und hilft Analysten zu verstehen, ob sie die aktuellsten verfügbaren Informationen betrachten. Dies ist besonders wichtig für die Überwachung der operativen Leistung und die Entscheidungsfindung auf Basis der Analyse. Bedeutung Bietet entscheidenden Kontext zur Datenaktualität, um sicherzustellen, dass Nutzer verstehen, wie aktuell die Analyse ist und wann die Daten zuletzt bezogen wurden. Datenquelle Timestamp, generiert durch den ETL/Datenpipeline-Prozess nach Abschluss der Datenaktualisierung. Beispiele 2023-10-27T08:00:00Z2023-10-28T08:00:00Z
	Quellsystem SourceSystem	Das `System`, aus dem die `Vorfalldaten` extrahiert wurden.
Beschreibung Dieses Attribut identifiziert den Ursprung der Prozessdaten. Für diese Ansicht wäre der Wert statisch, zum Beispiel 'Zendesk Support', was darauf hinweist, dass alle Events und Attribute aus diesem System stammen. In Umgebungen, in denen Daten aus mehreren Systemen kombiniert werden, ist dieses Feld entscheidend, um zwischen verschiedenen Datenquellen zu unterscheiden. Es hilft, die Datenintegrität sicherzustellen und ermöglicht eine quellspezifische Analyse, wie z.B. den Vergleich des Incident Management Prozesses in Zendesk mit einem anderen ITSM-Tool. Bedeutung Identifiziert den Ursprung der Daten, was für die Data Governance und für Analysen, die Daten aus mehreren Quellsystemen kombinieren, entscheidend ist. Datenquelle Statischer Wert, der während der Datentransformation festgelegt wird, um den Datenursprung zu identifizieren. Beispiele Zendesk SupportZendesk
	Endzeit des Events EventEndTime	Der Zeitstempel, der angibt, wann eine Aktivität abgeschlossen wurde.
Beschreibung Die Event End Time markiert den Abschluss einer Aktivität. In Event Log Daten wird die Endzeit einer Aktivität oft als Startzeit der nächsten Aktivität in der Sequenz für diesen Case interpretiert. Für die allerletzte Aktivität in einem Case kann die Endzeit dieselbe sein wie ihre Startzeit. Dieses Attribut ist essenziell für die Berechnung der Dauer einzelner Aktivitäten (ProcessingTime) und der Wartezeit zwischen Aktivitäten. Diese Information bildet die Grundlage für die Bottleneck-Analyse und ermöglicht es Analysten, nicht nur zu sehen, wie lange ein Schritt dauert, sondern auch, wie lange der Case untätig war, bevor dieser Schritt begann. Bedeutung Ermöglicht die Berechnung von Aktivitätsdauern und Wartezeiten, was grundlegend für die Durchführung detaillierter Engpassanalysen und die Identifizierung von Prozessverzögerungen ist. Datenquelle Berechnet als Startzeit des nachfolgenden Events innerhalb desselben Case. Die Endzeit des letzten Events kann mit seiner Startzeit oder der Case-Abschlusszeit identisch sein. Beispiele 2023-04-15T10:05:12Z2023-04-16T14:30:00Z2023-04-16T18:00:00Z
	Meldekanal Channel	Der Kanal, über den der Incident ursprünglich gemeldet wurde, z.B. 'E-Mail', 'Web' oder 'API'.
Beschreibung Dieses Attribut erfasst die Methode, die vom Endnutzer oder System verwendet wurde, um das Incident-Ticket zu erstellen. Das Verständnis des Kanals ist wichtig für die Analyse von Incident-Quellen und die entsprechende Anpassung des Support-Prozesses. Die Analyse von Incidents nach Kanal kann verschiedene Muster aufdecken. Zum Beispiel könnten über Telefon gemeldete Incidents kürzere Lösungszeiten haben als solche per E-Mail. Diese Information unterstützt das 'Incident Throughput Volume' Dashboard und hilft bei der Ressourcenplanung und den Bemühungen zur Kanaloptimierung. Bedeutung Hilft bei der Analyse von Incident-Volumen und Prozessleistung nach Quelle, ermöglicht kanalspezifische Prozessverbesserungen und Ressourcenzuweisung. Datenquelle Zendesk Tickets API, Feld via.channel. Beispiele webE-Mailapiphone
	Priorität TicketPriority	Die dem Incident zugewiesene Prioritätsstufe, z.B. 'Niedrig', 'Normal', 'Hoch' oder 'Dringend'.
Beschreibung Die Priorität eines Incidents bestimmt die erforderliche Dringlichkeit für eine Reaktion und Lösung. Sie ist ein Schlüsselfaktor bei der Arbeitspriorisierung und Ressourcenallokation innerhalb des Support-Teams. In der Prozessanalyse wird die Priorität verwendet, um Incidents zu segmentieren und deren Prozessflüsse sowie Leistung zu vergleichen. Zum Beispiel können Analysten überprüfen, ob 'Dringende' Incidents tatsächlich schneller gelöst werden als solche mit 'Niedriger' Priorität. Sie wird auch zur Überwachung der SLA-Compliance eingesetzt, da SLAs oft auf Prioritätsstufen basieren. Der KPI 'Priority Change Rate' basiert auf der Verfolgung von Änderungen in diesem Feld. Bedeutung Dieses Attribut ist entscheidend für die Segmentierung der Analyse, die Bewertung der Priorisierungseffektivität und die Überwachung der SLA-Compliance für verschiedene Dringlichkeitsstufen. Datenquelle Zendesk Tickets API, Feld priority. Änderungen werden in der Ticket Audits API protokolliert. Beispiele niedrignormalhochurgent
	SLA-Status SlaStatus	Der aktuelle Status des Service Level Agreements (SLA) für den Incident.
Beschreibung Dieses Attribut gibt an, ob ein Incident auf Kurs ist, seine definierten SLA-Ziele zu erreichen, diese bereits verletzt hat oder ob die SLA-Timer pausiert sind. Zendesk verfolgt SLA-Metriken automatisch basierend auf konfigurierten Richtlinien. Dies ist ein kritisches Attribut für das Dashboard 'SLA Compliance Monitoring'. Es bietet ein direktes Maß für die Leistung im Verhältnis zu den Servicezusagen. Durch die Analyse, wann und warum SLAs verletzt werden, können Organisationen Prozessschwächen identifizieren und die Servicezuverlässigkeit verbessern. Es unterstützt direkt den KPI 'Incident SLA Adherence Rate'. Bedeutung Misst direkt die Leistung im Vergleich zu Service-Verpflichtungen und ermöglicht die Analyse von SLA-Verletzungen sowie proaktives Monitoring zur Verbesserung der Compliance. Datenquelle Zendesk Ticket Metrics API (/api/v2/ticket_metrics.json), abgeleitet aus Feldern wie sla_policy, breached_at, etc. Beispiele AktivPausiertVerletztErfüllt.
	Ticketstatus TicketStatus	Der Status des Incident-Tickets zum Zeitpunkt des Events, z.B. 'Open', 'Pending' oder 'Solved'.
Beschreibung Dieses Attribut spiegelt den Status des Incident-Tickets zu verschiedenen Zeitpunkten in seinem Lebenszyklus wider. Standard-Zendesk-Status umfassen new, open, pending, on-hold, solved und closed. Das Verfolgen von Änderungen in diesem Feld ist eine primäre Methode, um Aktivitäten für Process Mining zu generieren. Die Analyse des Ticket-Status ist grundlegend für das Verständnis des Prozesses. Sie hilft zu identifizieren, wie viel Zeit Incidents in bestimmten Zuständen verbringen, wie z.B. 'Pending', was oft auf das Warten auf eine Kundenantwort hindeutet. Sie ist auch entscheidend für die Definition des Case-Abschlusses und die Berechnung der Lösungszeiten. Bedeutung Das Verfolgen von Statusänderungen ist entscheidend, um den Prozessfortschritt zu verstehen, Wartezeiten zu identifizieren und die Start- und Endpunkte des Incident-Lebenszyklus zu definieren. Datenquelle Zendesk Tickets API, Feld status. Änderungen werden in der Ticket Audits API protokolliert. Beispiele neuopenpendingsolvedgeschlossen
	Zugewiesene Gruppe AssignedGroup	Das Support-Team oder die Gruppe, die dem Incident aktuell zugewiesen ist.
Beschreibung Dieses Attribut gibt an, welches Team für den Incident verantwortlich ist. Incidents wechseln oft zwischen verschiedenen Support-Ebenen oder spezialisierten Gruppen, z.B. vom 'L1 Support' zum 'Network Team'. Dies ist eine kritische Dimension für die Analyse von Prozess-Übergaben und die Identifizierung von Bottlenecks. Durch die Überwachung, wie Incidents zwischen Gruppen fließen, können Analysten teamübergreifende Abhängigkeiten messen, Wartezeiten für spezifische Teams berechnen und Routing-Regeln optimieren. Es unterstützt direkt das Dashboard 'Handoffs and Rework Analysis'. Bedeutung Verfolgt die Teamverantwortung, was essenziell ist für die Analyse von teamübergreifenden Übergaben, die Identifizierung teamspezifischer Bottlenecks und die Messung von Wartezeiten in Queues. Datenquelle Zendesk Tickets API, Feld group_id. Änderungen werden in der Ticket Audits API protokolliert. Beispiele L1 SupportL2 Network TeamL3 InfrastructureAbrechnung
	Zugewiesener Agent Assignee	Der individuelle Support-Agent, der aktuell für die Bearbeitung des Incidents zuständig ist.
Beschreibung Dieses Attribut identifiziert den spezifischen Agenten, der zu einem bestimmten Zeitpunkt für den Incident verantwortlich ist. Änderungen in der Zuweisung sind kritische Events, die eine Übergabe der Arbeit von einer Person zur anderen signalisieren. Die Analyse des zugewiesenen Agenten hilft beim Verständnis der Arbeitslastverteilung, der individuellen Leistung und der Kollaborationsmuster. Die Verfolgung von Änderungen in diesem Feld ist unerlässlich für die Berechnung des KPIs 'Average Handoffs per Incident' und die Identifizierung von Situationen, in denen Incidents häufig weitergegeben werden, was auf Wissenslücken oder ineffizientes Routing hindeuten kann. Bedeutung Identifiziert den verantwortlichen Agenten, ermöglicht die Arbeitslastanalyse und die Nachverfolgung von Übergaben (Handoffs), was entscheidend für die Identifizierung von Prozessineffizienzen ist. Datenquelle Zendesk Tickets API, Feld assignee_id. Änderungen werden in der Ticket Audits API protokolliert. Beispiele John SmithJane DoeService Desk Automation
	`Handoff`-Anzahl HandoffCount	Die Gesamtzahl, wie oft ein Incident einem anderen Agenten oder einer anderen Gruppe neu zugewiesen wurde.
Beschreibung Diese berechnete Metrik quantifiziert, wie oft die Verantwortung für einen Incident übertragen wurde. Jede Änderung im Feld Assignee oder AssignedGroup erhöht diesen Zähler für den Case. Übergaben sind eine häufige Ursache für Ineffizienz und Verzögerungen im Incident Management. Eine hohe Anzahl von Übergaben kann auf unklare Routing-Regeln, Wissenslücken in Support-Teams oder übermäßig komplexe Prozesse hindeuten. Diese Metrik ist die Grundlage für den KPI 'Average Handoffs per Incident' und entscheidend für das Dashboard 'Handoffs and Rework Analysis'. Bedeutung Quantifiziert Prozessreibung, die durch Weiterleitungen entsteht, und hilft dabei, Ineffizienzen im Routing sowie Wissenslücken zu identifizieren, die die Lösungszeiten verlängern. Datenquelle Berechnet durch Zählung der Häufigkeit, mit der sich das Feld „AssignedGroup“ oder „Assignee“ für einen Incident geändert hat. Beispiele 0135
	Bearbeitungszeit ProcessingTime	Die Dauer einer einzelnen Aktivität, die die aktiv für eine Aufgabe aufgewendete Zeit darstellt.
Beschreibung Diese Metrik misst die verstrichene Zeit vom Beginn einer Aktivität bis zu deren Ende. Sie wird berechnet als die Differenz zwischen der EventEndTime und dem EventTimestamp für jede Zeile im Event Log. Die Verarbeitungszeit, auch bekannt als Aktivitätsdauer, hilft, zwischen aktiver Arbeitszeit und Leerlauf- oder Wartezeit zu unterscheiden. Im Dashboard 'Bottleneck Activities Overview' können hohe durchschnittliche Verarbeitungszeiten für bestimmte Aktivitäten auf komplexe, zeitaufwendige Aufgaben hinweisen. Dies unterscheidet sich von der Wartezeit, die Verzögerungen zwischen Aufgaben darstellt. Bedeutung Misst die aktive Arbeitszeit für spezifische Aktivitäten und hilft, Aufgaben zu identifizieren, die von Natur aus zeitaufwendig sind und Kandidaten für Vereinfachung oder Automatisierung sind. Datenquelle Berechnet als Differenz zwischen EventEndTime und EventTimestamp für jede Aktivität. Beispiele 30018003600
	Einreicher Submitter	Der Endnutzer oder das System, das den Incident ursprünglich gemeldet hat.
Beschreibung Dieses Attribut identifiziert die Person oder Entität, die das Ticket erstellt hat. Dies unterscheidet sich vom Anfragenden, da ein Agent ein Ticket im Namen einer anderen Person erstellen könnte. In der Analyse kann der Einreicher verwendet werden, um zu verstehen, wer Probleme meldet. In Kombination mit Organisationsdaten kann es helfen, zu identifizieren, ob bestimmte Kunden oder Benutzergruppen ein hohes Incident-Volumen erleben. Dies kann proaktive Support-Initiativen oder Schulungsbemühungen leiten. Bedeutung Identifiziert die Quelle des Incident-Berichts, die analysiert werden kann, um Muster in Bezug auf spezifische Benutzer, Abteilungen oder automatisierte Systeme zu finden. Datenquelle Zendesk Tickets API, Feld submitter_id. Beispiele alice.jones@example.combob.williams@example.comSystem Monitor
	Falldauer CaseDuration	Die gesamte verstrichene Zeit von der Erstellung des Incidents bis zu dessen endgültigem Abschluss.
Beschreibung Diese berechnete Metrik stellt die End-to-End-Zykluszeit für einen einzelnen Incident dar. Sie wird berechnet, indem die Differenz zwischen dem Timestamp des allerersten Events (z.B. 'Incident Created') und dem allerletzten Events (z.B. 'Incident Closed') ermittelt wird. Die Case Duration ist ein primärer Key Performance Indicator (KPI) für die gesamte Prozesseffizienz. Sie wird intensiv in Dashboards verwendet, um durchschnittliche Zykluszeiten anzuzeigen, langlaufende Cases zu identifizieren und Trends über die Zeit zu analysieren. Sie bietet ein hohes Maß dafür, wie schnell der Prozess Incidents bearbeiten und lösen kann. Bedeutung Dies ist ein kritischer KPI zur Messung der Gesamtprozessgeschwindigkeit und zur Identifizierung von Faktoren, die zu langen Lösungszeiten beitragen. Datenquelle Berechnet durch Ermittlung der Differenz zwischen dem Timestamp des letzten Events und dem ersten Event für jede Incident ID. Beispiele 25920060480086400
	Ist automatisiert IsAutomated	Ein boolesches Flag, das anzeigt, ob eine Aktivität von einem automatisierten System oder einem menschlichen Agenten durchgeführt wurde.
Beschreibung Dieses abgeleitete Attribut hilft, zwischen Events, die von menschlichen Nutzern ausgeführt werden, und solchen, die von Systemautomatisierungen, Triggern oder API-Integrationen durchgeführt werden, zu unterscheiden. Es wird typischerweise durch Überprüfung ermittelt, ob der Autor eines Events ein bekannter Systemnutzer ist. Das Verständnis des Automatisierungsgrades ist entscheidend für die moderne Prozessanalyse. Es hilft bei der Bewertung der Effektivität von Automatisierungsregeln, der Identifizierung manueller Aufgaben, die automatisiert werden könnten, und der Messung der Auswirkungen der Automatisierung auf Effizienz und Lösungszeiten. Dieses Attribut kann verwendet werden, um die Prozessflüsse von automatisierten im Vergleich zu manuellen Aktivitäten zu vergleichen. Bedeutung Unterscheidet zwischen menschlichen und Systemaktionen, was für die Analyse der Auswirkungen der Automatisierung auf die Prozesseffizienz und die Identifizierung neuer Automatisierungsmöglichkeiten unerlässlich ist. Datenquelle Abgeleitet durch Überprüfung, ob der Event-Autor (author_id in der Ticket Audits API) einem bekannten System- oder Automatisierungsbenutzer entspricht. Beispiele truefalsch
	Ist Erstkontaktlösung IsFirstContactResolution	Ein boolesches Flag, das wahr ist, wenn der Incident vom ersten zugewiesenen Agenten oder der ersten Gruppe ohne Übergaben (Handoffs) gelöst wurde.
Beschreibung Die Erstkontaktlösung (First Contact Resolution, FCR) ist eine entscheidende Metrik für die Effizienz von Support-Centern und die Kundenzufriedenheit. Dieses berechnete Attribut kennzeichnet Incidents, die gelöst wurden, ohne einem anderen Agenten oder Team neu zugewiesen zu werden. Die Logik prüft typischerweise, ob das Ticket den Status „Gelöst“ erreicht hat, während es noch dem initialen Agenten und der initialen Gruppe zugewiesen war. Im Process Mining ermöglicht dies die direkte Berechnung der FCR-Rate und den Vergleich der Prozesspfade von FCR-Incidents mit denen, die eine Eskalation erforderten, was hilft, Möglichkeiten zur Stärkung des Front-Line-Supports zu identifizieren. Bedeutung Misst direkt die Effizienz des initialen Support-Kontaktpunkts und hilft, Möglichkeiten zu identifizieren, die Lösung früher im Prozess zu verschieben. Datenquelle Berechnetes boolesches Flag. Wahr, wenn der Ticketstatus „gelöst“ oder „geschlossen“ ist und es während des gesamten Incident-Lebenszyklus nur einen einzigen Bearbeiter oder eine einzige zugewiesene Gruppe gab. Beispiele truefalsch
	Kundenorganisation Organization	Die Organisation oder das Unternehmen, zu dem der Incident-Anfragende gehört.
Beschreibung Dieses Attribut verknüpft einen Incident mit der Organisation des Kunden. Es ist essenziell für B2B-Support-Umgebungen, in denen Service Levels und Support-Prozesse je nach Kunde variieren können. Die Analyse von Incidents nach Organisation ermöglicht es Support-Teams, die Kundenzufriedenheit zu überwachen, wiederkehrende Probleme bei spezifischen Kunden zu identifizieren und sicherzustellen, dass vertragliche Verpflichtungen eingehalten werden. Es ist eine Schlüsseldimension für das Filtern von Dashboards und Berichten, um eine kundenorientierte Sicht auf die Leistung zu bieten. Bedeutung Ermöglicht kundenspezifische Analysen, hilft bei der Überwachung von Service Levels, identifiziert Trends für Schlüsselkunden und verwaltet Kundenbeziehungen effektiv. Datenquelle Zendesk Tickets API, Feld organization_id. Beispiele Global Tech Inc.Lösungen innovierenData Corp
	Schweregrad Severity	Das Ausmaß des Einflusses, den der Incident auf das Geschäft hat.
Beschreibung Die Schwere definiert den geschäftlichen Einfluss eines Incidents, oft in Verbindung mit der Priorität, um die Gesamtdringlichkeit zu bestimmen. Sie wird typischerweise als benutzerdefiniertes Feld in Zendesk konfiguriert. Die Analyse der Schwere hilft, die Kritikalität der bearbeiteten Incidents zu verstehen. Sie ist eine Schlüsseldimension zur Datensegmentierung in Dashboards wie 'SLA Compliance Monitoring' und 'Prioritization Effectiveness Metrics'. Der Vergleich von Prozessflüssen für verschiedene Schweregrade kann aufzeigen, ob Incidents mit hoher Schwere mit der entsprechenden Geschwindigkeit und den nötigen Ressourcen bearbeitet werden. Bedeutung Zeigt den geschäftlichen Einfluss eines Incidents an, ermöglicht eine Analyse, die sich auf die kritischsten Probleme konzentriert, und stellt sicher, dass diese effizient gelöst werden. Datenquelle Dies ist typischerweise ein benutzerdefiniertes Feld. Überprüfen Sie die Konfiguration der Ticketfelder im Zendesk Admin Center. Beispiele 1 - Kritisch2 - Hoch3 - Mittel4 - Niedrig
	Tags Tags	Eine Liste von Tags, die für die Kategorisierung und den Kontext auf den Incident angewendet wurden.
Beschreibung Tags sind flexible Labels, die Tickets hinzugefügt werden können, um zusätzlichen Kontext zu liefern oder die Kategorisierung und das Routing zu unterstützen. Sie können manuell von Agenten oder automatisch über Trigger und Automatisierungen hinzugefügt werden. Tags sind eine reiche Datenquelle für die Process Mining Analyse. Sie können verwendet werden, um feingranulare Segmente für die Analyse zu erstellen, wie z.B. das Filtern nach Incidents, die sich auf eine bestimmte Produkteinführung ('launch_q4') oder einen bekannten Ausfall ('outage_20231027') beziehen. Diese Flexibilität ermöglicht detaillierte Untersuchungen, die über Standard-Ticketfelder hinausgehen. Bedeutung Bietet eine flexible Möglichkeit zur Kategorisierung und Filterung von Incidents, was eine detaillierte, kontextspezifische Analyse ermöglicht, die mit Standardfeldern allein möglicherweise nicht umsetzbar wäre. Datenquelle Zendesk Tickets API, Feld tags. Beispiele vip_usernetwork_issueoutage_20231027billing_related
	Ticket-Typ TicketType	Die Klassifizierung des Tickets, z.B. 'Incident', 'Problem', 'Question' oder 'Task'.
Beschreibung Dieses Feld kategorisiert das Ticket basierend auf der Art der Anfrage. Der Incident Management Prozess konzentriert sich spezifisch auf Tickets, bei denen der Typ 'Incident' ist, was eine ungeplante Unterbrechung oder Qualitätsminderung eines IT-Dienstes darstellt. In der Analyse wird dieses Attribut primär als Filter verwendet, um sicherzustellen, dass nur Incidents in der Prozessansicht enthalten sind. Es kann auch für eine breitere ITSM-Analyse verwendet werden, um die Prozesse zur Bearbeitung von Incidents im Vergleich zu Problemen oder Serviceanfragen zu vergleichen. Bedeutung Ermöglicht die Filterung von Daten, um sich gezielt auf Incidents zu konzentrieren, wodurch sichergestellt wird, dass die Prozessanalyse für den Incident-Management-Lebenszyklus relevant ist. Datenquelle Zendesk Tickets API, Feld type. Beispiele incidentproblemquestiontask
	Ursachenkategorie RootCauseCategory	Die übergeordnete Kategorie der zugrundeliegenden Ursache des Incidents.
Beschreibung Dieses Attribut wird verwendet, um den grundlegenden Grund für das Auftreten eines Incidents zu klassifizieren. Es wird typischerweise gegen Ende des Incident-Lebenszyklus erfasst, oft als Teil eines Post-Mortem- oder Problem-Management-Prozesses, und in einem benutzerdefinierten Feld gespeichert. Diese Daten sind essenziell für das Dashboard 'Root Cause Identification Accuracy' und den KPI 'RCA Coverage'. Die Analyse von Incidents nach Ursache hilft, wiederkehrende Probleme zu identifizieren, was Bemühungen zur Implementierung dauerhafter Lösungen und zur Reduzierung des zukünftigen Incident-Volumens leitet. Es verlagert den Fokus vom reaktiven "Feuerlöschen" auf proaktive Problemprävention. Bedeutung Ermöglicht proaktives Problemmanagement durch Kategorisierung von Incident-Ursachen, was hilft, Trends zu identifizieren und zukünftige Vorkommnisse zu verhindern. Datenquelle Dies ist typischerweise ein benutzerdefiniertes Ticketfeld. Überprüfen Sie die Konfiguration der Ticketfelder im Zendesk Admin Center. Beispiele Software-Bug`Hardware`-AusfallAnwenderfehlerNetzwerkausfall
	Zufriedenheitsbewertung SatisfactionRating	Die Zufriedenheitsbewertung, die der Endnutzer nach der Lösung des Incidents abgegeben hat.
Beschreibung Dieses Attribut erfasst das Kundenfeedback zu deren Support-Erfahrung, typischerweise gesammelt über eine Umfrage, nachdem das Ticket gelöst wurde. Gängige Bewertungen in Zendesk sind 'Gut' oder 'Schlecht'. Obwohl keine direkte Messgröße für die Prozesseffizienz, liefern Zufriedenheitsbewertungen eine kritische Ergebnis-Metrik. Im Process Mining kann dies mit Prozessvarianten korreliert werden, um zu verstehen, welche Lösungswege zu höherer Kundenzufriedenheit führen. Erhalten beispielsweise Incidents mit mehr Übergaben niedrigere Bewertungen? Bedeutung Liefert eine entscheidende Ergebnis-Metrik, die mit Prozessmerkmalen korreliert werden kann, um zu verstehen, wie die Prozessleistung die Benutzerzufriedenheit beeinflusst. Datenquelle Zendesk Ticket Metrics API (/api/v2/ticket_metrics.json), Feld satisfaction_rating.score. Beispiele gutschlechtangebotenunoffered

Erforderlich Empfohlen Optional

`Incident Management`-Aktivitäten

Dies sind die kritischen Prozessschritte und Meilensteine, die in Ihrem Event Log erfasst werden sollten, um eine präzise Entdeckung und Analyse zu ermöglichen.

6 Empfohlen 7 Optional

	Aktivität	Beschreibung
	`Incident` erstellt	Markiert den Beginn des Incident-Lebenszyklus, wenn ein neues Ticket in Zendesk erstellt wird. Dieses Event wird explizit durch Zendesk's Ticket-Erstellungs-Audit-Log erfasst und dient als Ausgangspunkt für jeden Case.
Bedeutung Dies ist die primäre Startaktivität. Die Analyse der Zeit von diesem Event zu anderen ist entscheidend für die Messung der gesamten Ticket-Lebenszyklusdauer und der initialen Antwortzeiten. Datenquelle Dies ist ein explizites Event, das in den Zendesk Ticket Audit Logs erfasst wird. Jedes neue Ticket generiert ein 'Create'-Event mit einem entsprechenden Timestamp. Erfassen Direkt aus dem Ticket-Erstellungsereignis im Audit Log. Ereignistyp explicit
	`Incident` gelöst	Dieser Schlüsselmeilenstein tritt ein, wenn ein Agent eine Lösung implementiert und das Ticket als 'solved' markiert. Dies ist eine explizite Aktion, die als Statusänderung im Ticket-Audit-Log erfasst wird.
Bedeutung Dies ist die primäre Lösungsaktivität und ein kritischer Punkt zur Messung der Time-to-Resolution. Die Zeit zwischen diesem Event und 'Incident Closed' stellt die Benutzerbestätigungs- oder Auto-Closure-Periode dar. Datenquelle Erfasst aus dem Ticket-Audit-Log über ein „Änderungs“-Event, bei dem der neue Wert des Feldes „Status“ zu „gelöst“ wird. Erfassen Identifiziert durch ein „Änderungs“-Event für das Feld „status“ zu „gelöst“. Ereignistyp explicit
	Incident geschlossen	Markiert das endgültige Ende des Incident-Lebenszyklus, wenn das Ticket dauerhaft geschlossen wird. In Zendesk geschieht dies oft automatisch nach einer festgelegten Zeitspanne nach der Lösung und wird als letzte Statusänderung erfasst.
Bedeutung Dies ist die definitive Endaktivität für den Prozess. Die gesamte Prozessdauer wird von 'Incident Created' bis zu diesem Event berechnet, was eine End-to-End-Ansicht der Zykluszeit bietet. Datenquelle Erfasst aus dem Ticket-Audit-Log über ein „Änderungs“-Event, bei dem der neue Wert des Feldes „Status“ zu „geschlossen“ wird. Erfassen Identifiziert durch ein „Änderungs“-Event für das Feld „status“ zu „geschlossen“. Ereignistyp explicit
	Status auf „Open“ geändert	Zeigt an, dass ein Agent aktiv mit der Arbeit am Incident begonnen hat. Diese Aktivität wird typischerweise aus der Änderung des Ticket-Statusfeldes von „neu“ zu „offen“ abgeleitet, was den Beginn der Untersuchungs- und Diagnosephase signalisiert.
Bedeutung Dieses Event markiert den Übergang vom Queuing zur aktiven Arbeit. Die Zeit, die Tickets im Status 'new' verbringen, bevor sie zu 'open' wechseln, ist eine Schlüsselmetrik für die initiale Antwortzeit. Datenquelle Abgeleitet aus dem Ticket-Audit-Log durch Identifizierung eines „Änderungs“-Events, bei dem der neue Wert des Feldes „status“ „offen“ und der vorherige Wert „neu“ war. Erfassen Abgeleitet aus einer Statusfeldänderung von „neu“ zu „offen“. Ereignistyp inferred
	Ticket einem Agenten zugewiesen	Diese Aktivität tritt auf, wenn ein Ticket einem spezifischen Agenten zur Bearbeitung zugewiesen wird. Dies ist ein explizites Event, das in der Audit-Historie des Tickets protokolliert wird und signalisiert, dass eine Person die Verantwortung übernommen hat.
Bedeutung Dieser Meilenstein ist essenziell für die Messung der Zeit bis zur ersten Zuweisung und bildet die Grundlage für die Analyse von Übergaben, Nacharbeiten und First Contact Resolution Raten. Datenquelle Erfasst aus dem Ticket-Audit-Log, wenn das Feld „assignee_id“ ausgefüllt oder geändert wird. Die erste Zuweisung ist ein wichtiger Meilenstein für die KPI-Berechnung. Erfassen Identifiziert durch ein „Änderungs“-Event für das Feld „assignee_id“ im Ticket-Audit-Log. Ereignistyp explicit
	Ticket neu zugewiesen	Tritt auf, wenn die Ticket-Zuständigkeit nach der initialen Zuweisung von einem Agenten oder einer Gruppe an eine andere übertragen wird. Dies ist ein explizites Event, das in der Audit-Historie des Tickets verfolgt wird.
Bedeutung Neu-Zuweisungen sind entscheidend für die Analyse von Übergaben und Nacharbeiten. Eine hohe Häufigkeit von Neu-Zuweisungen deutet oft auf ein falsches Initial-Routing, komplexe Probleme oder Prozess-Bottlenecks hin. Datenquelle Erfasst aus dem Ticket-Audit-Log durch Identifizierung eines „Änderungs“-Events im Feld „assignee_id“ oder „group_id“, nachdem es erstmals ausgefüllt wurde. Erfassen Identifiziert durch ein nachfolgendes „Änderungs“-Event für das Feld „assignee_id“ oder „group_id“. Ereignistyp explicit
	Benutzerzufriedenheit bewertet	Repräsentiert den Zeitpunkt, an dem der Endnutzer eine Zufriedenheitsbewertung für den erhaltenen Support abgibt. Dies ist ein explizites Event, das in Zendesk erfasst wird, nachdem ein Ticket gelöst wurde.
Bedeutung Die Analyse von Zufriedenheitsbewertungen liefert entscheidendes Feedback zur Agentenleistung und Prozesseffektivität, indem Prozessmetriken mit Kundenergebnissen verknüpft werden. Datenquelle Erfasst aus den Zufriedenheitsbewertungsdaten, die mit dem Ticket verknüpft sind. Dies umfasst typischerweise eine Bewertung („gut“ oder „schlecht“) und einen optionalen Kommentar. Erfassen Event protokolliert, wenn eine Zufriedenheitsbewertung für das Ticket eingereicht wird. Ereignistyp explicit
	Interne Notiz hinzugefügt	Diese Aktivität kennzeichnet eine interne Zusammenarbeit, bei der ein Agent eine private Notiz zum Ticket für andere Teammitglieder hinzufügt. Dies wird explizit erfasst, wenn ein Kommentar als nicht öffentlich markiert wird.
Bedeutung Die Analyse interner Notizen kann Einblicke in komplexe Probleme geben, die eine Zusammenarbeit erfordern, aber eine übermäßige Anzahl kann auf Wissenslücken oder Prozessineffizienzen hindeuten. Datenquelle Erfasst aus den Ticket-Kommentardaten. Ein Kommentar wird als interne Notiz identifiziert, wenn sein Attribut „public“ falsch ist. Erfassen Event protokolliert, wenn ein neuer Kommentar mit „public: false“ zum Ticket hinzugefügt wird. Ereignistyp explicit
	Öffentliche Antwort gesendet	Stellt eine Kommunikation dar, die von einem Support-Agenten an den Endnutzer gesendet wird. Dies ist ein explizites Event in Zendesk, das erfasst wird, sobald ein öffentlicher Kommentar zum Ticket hinzugefügt wird.
Bedeutung Das Verfolgen öffentlicher Antworten ist wichtig, um die Kommunikationshäufigkeit zu verstehen und kann ein Schlüsselbestandteil der Zeitachse sein, wenn Verzögerungen bei der Benutzerbestätigung analysiert werden. Datenquelle Erfasst aus den Ticket-Kommentardaten. Ein Kommentar wird als öffentlich identifiziert, wenn sein Attribut „public“ wahr ist. Erfassen Event protokolliert, wenn ein neuer Kommentar mit „public: true“ zum Ticket hinzugefügt wird. Ereignistyp explicit
	Priorität festgelegt	Das Prioritätslevel eines Incidents (z. B. Niedrig, Normal, Hoch, Dringend) wird definiert. Dies wird als explizites Änderungsereignis erfasst und bestimmt die Dringlichkeit und die erforderliche Reaktionszeit für das Ticket.
Bedeutung Das Verfolgen, wann und wie die Priorität festgelegt wird, ist entscheidend für das Dashboard 'Prioritization Effectiveness Metrics', um sicherzustellen, dass kritische Probleme zeitnah angegangen werden. Datenquelle Erfasst aus einem „Änderungs“-Event im Feld „Priorität“ innerhalb des Ticket-Audit-Logs. Nachfolgende Änderungen können ebenfalls verfolgt werden, um den KPI „Prioritätsänderungsrate“ zu messen. Erfassen Identifiziert durch ein „Änderungs“-Event für das Feld „priority“ im Ticket-Audit-Log. Ereignistyp explicit
	SLA-Ziel verletzt	Markiert den Moment, an dem ein Ticket ein definiertes Service Level Agreement nicht erfüllt hat, wie z. B. die erste Antwortzeit oder die Lösungszeit. Dieses Event wird basierend auf SLA-Richtliniendefinitionen und Ticket-Update-Timestamps berechnet.
Bedeutung Dieses Event unterstützt direkt das SLA-Compliance-Monitoring. Das Identifizieren, wann und warum Verstöße auftreten, ist grundlegend für die Verbesserung der Servicezuverlässigkeit und des Kundenvertrauens. Datenquelle Dies ist ein berechnetes Event. Es kann durch Analyse der 'sla_policy_metrics' Daten, die einem Ticket zugeordnet sind, abgeleitet werden, unter Verwendung des 'breached_at' Timestamps für jedes SLA-Ziel. Erfassen Abgeleitet vom Timestamp „breached_at“ innerhalb der SLA-Metrikdaten des Tickets. Ereignistyp calculated
	Status auf 'Ausstehend' geändert	Zeigt an, dass der Prozess pausiert ist, während auf eine Antwort des Anfragenden gewartet wird. Dieses Event wird aus der Änderung des Ticket-Statusfeldes zu „ausstehend“ abgeleitet.
Bedeutung Diese Aktivität ist entscheidend für die Berechnung der Wartezeit auf Benutzerbestätigung. Lange Verweildauern in diesem Zustand können die gesamte Lösungszeit erheblich verlängern und Kommunikationsverzögerungen aufzeigen. Datenquelle Abgeleitet aus dem Ticket-Audit-Log durch Identifizierung eines „Änderungs“-Events, bei dem der neue Wert des Feldes „status“ „ausstehend“ ist. Erfassen Abgeleitet aus einer Statusfeldänderung zu „ausstehend“. Ereignistyp inferred
	Ticket einer Gruppe zugewiesen	Repräsentiert das initiale Routing oder die Triage eines Incidents an eine spezifische Supportgruppe. Dies ist typischerweise der erste Schritt bei der Zuweisung von Verantwortung und wird als explizites Change-Event in der Audit-Historie des Tickets erfasst.
Bedeutung Das Verfolgen von Gruppenzuweisungen hilft, die Effizienz des initialen Triage-Prozesses zu analysieren und Verzögerungen zu identifizieren, bevor ein Ticket an das richtige Team geroutet wird. Datenquelle Erfasst aus dem Ticket-Audit-Log, wann immer das Feld „group_id“ gesetzt oder geändert wird. Die erste Instanz dieser Änderung nach der Erstellung ist die initiale Zuweisung. Erfassen Identifiziert durch ein „Änderungs“-Event für das Feld „group_id“ im Ticket-Audit-Log. Ereignistyp explicit

Extraktionsleitfäden

So erhalten Sie Ihre Daten von Zendesk Support

Schritte

Access Zendesk Explore: Loggen Sie sich in Ihre Zendesk Support-Instanz mit einem Benutzerkonto ein, das über Berechtigungen zum Erstellen und Verwalten von Berichten in Zendesk Explore verfügt.
Create a New Report: Navigieren Sie zum Explore-Modul. Klicken Sie in der linken Navigationsleiste auf das Symbol „Berichte“ und dann auf die Schaltfläche „Neuen Bericht erstellen“.
Select the Dataset: Wählen Sie im Fenster „Dataset auswählen“ das Dataset „Support: Ticket-Updates [Standard]“ aus. Dieses Dataset enthält den Audit-Trail für jede Ticketänderung, der für die Erstellung eines Event Logs unerlässlich ist.
Add Initial Attributes (Columns): Gehen Sie im Berichts-Builder zum Abschnitt „Zeilen“. Klicken Sie auf „Hinzufügen“ und wählen Sie die folgenden Attribute aus. Diese bilden die Spalten Ihres Event Logs: Ticket ID, Update - Timestamp, Ticketstatus, Name des Bearbeiters, Ticketgruppe, Ticketpriorität, Ticketkanal, Änderungen - Feldname, Änderungen - Vorheriger Wert, Änderungen - Neuer Wert, Öffentlicher Kommentar.
Create Calculated Attributes: Dies ist der wichtigste Schritt. Gehen Sie zum Menü „Berechnungen“ (das Becher-Symbol) und wählen Sie „Standard berechnetes Attribut“ aus. Erstellen Sie die drei Attribute, die im Abschnitt „Abfrage“ unten definiert sind: ActivityName, SourceSystem und LastDataUpdate. Sie müssen die bereitgestellten Formeln exakt kopieren.
Refine Report Columns: Fügen Sie Ihre neu erstellten berechneten Attribute (ActivityName, SourceSystem, LastDataUpdate) zum Abschnitt „Zeilen“ hinzu. Sie können nun die Rohfelder, die zur Erstellung von ActivityName verwendet wurden (Änderungen - Feldname, Änderungen - Vorheriger Wert, Änderungen - Neuer Wert, Öffentlicher Kommentar), entfernen, um die Ansicht zu bereinigen.
Add Report Filters: Gehen Sie zum Abschnitt „Filter“ und klicken Sie auf „Hinzufügen“. Fügen Sie einen Filter für „Update - Date“ hinzu und wählen Sie einen geeigneten Datumsbereich aus (z. B. die letzten 3 Monate). Fügen Sie einen weiteren Filter für Ihr berechnetes Attribut ActivityName hinzu und schließen Sie Nullwerte aus, um Ticket-Updates zu entfernen, die keiner gewünschten Aktivität entsprechen.
Run and Review the Report: Zendesk Explore aktualisiert den Bericht automatisch, wenn Sie Attribute und Filter hinzufügen. Überprüfen Sie die Datentabelle, um sicherzustellen, dass die Zeilen und Spalten wie erwartet angezeigt werden. Der Bericht sollte eine Zeile pro Event anzeigen.
Export the Data to CSV: Sobald der Bericht fertiggestellt ist, klicken Sie oben rechts auf die Schaltfläche „Exportieren“ und wählen Sie „CSV“ aus. Zendesk generiert und lädt die CSV-Datei herunter.
Prepare for Upload: Öffnen Sie die exportierte CSV-Datei. Benennen Sie die Spaltenüberschriften um, um sie an die erforderlichen Attributnamen für Ihr Process Mining-Tool anzupassen (z. B. benennen Sie „Ticket ID“ in TicketId, „Update - Timestamp“ in EventTimestamp um). Stellen Sie sicher, dass das Datumsformat für Zeitstempel ISO 8601-konform ist. Die Datei ist nun zum Hochladen bereit.

Konfiguration

Zendesk Dataset: Der Bericht muss auf dem Dataset „Support: Ticket-Updates [Standard]“ basieren. Dies ist das einzige Standard-Dataset, das den detaillierten Audit-Trail bereitstellt, der zur ereignisweisen Rekonstruktion des Prozesses erforderlich ist.
Datumsbereichsfilterung: Es ist entscheidend, einen Datumsfilter anzuwenden, um das Datenvolumen zu begrenzen. Verwenden Sie das Attribut „Update - Date“ als primären Filter. Ein Datenbereich von 3-6 Monaten wird typischerweise für eine erste Analyse empfohlen.
Aktivitätenfilter: Nachdem Sie das berechnete Attribut „ActivityName“ erstellt haben, müssen Sie den Bericht so filtern, dass Zeilen ausgeschlossen werden, bei denen dieser Wert null ist. Dadurch werden irrelevante Ticketänderungen (z. B. Systemaktualisierungen, Tag-Änderungen) aus Ihrem Event Log entfernt.
Berechnete Attribute: Die Logik dieser Extraktion basiert stark auf einem Standard-Berechneten-Attribut, um Rohdatenänderungen in lesbare Aktivitätsnamen zu übersetzen. Präzision in der Formel ist entscheidend.
Voraussetzungen: Der Benutzer, der den Bericht ausführt, benötigt mindestens die Rolle „Viewer“ in Zendesk Explore. Zum Erstellen und Speichern des Berichts sind „Editor“- oder „Admin“-Berechtigungen erforderlich.

a Beispielabfrage config

This extraction is configured using the Zendesk Explore UI. The core logic is contained within a standard calculated attribute. 

**1. Dataset Selection:**
* `Support: Ticket updates [default]`

**2. Report Columns (Add to 'Rows' panel):**
* `Ticket ID`
* `ActivityName` (Calculated Attribute)
* `EventTimestamp` (Use the `Update - Timestamp` attribute)
* `SourceSystem` (Calculated Attribute)
* `LastDataUpdate` (Calculated Attribute)
* `Ticket status`
* `Assignee name`
* `Ticket group`
* `Ticket priority`
* `Ticket channel`
* `SLA metric status`
* `EventEndTime` (Use the `Update - Timestamp` attribute again)

**3. Standard Calculated Attribute Formulas:**

**Attribute Name:** `ActivityName`
**Formula:**
```
IF ([Changes - Field name] = "status" AND [Changes - Previous value] = NULL AND [Changes - New value] = "new") THEN "Incident Created"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "open") THEN "Status Changed to Open"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN "Status Changed to Pending"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "solved") THEN "Incident Resolved"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "closed") THEN "Incident Closed"
ELIF ([Changes - Field name] = "group_id") THEN "Ticket Assigned to Group"
ELIF ([Changes - Field name] = "assignee_id") THEN "Ticket Assigned to Agent"
ELIF ([Changes - Field name] = "priority") THEN "Priority Set"
ELIF ([Changes - Field name] = "satisfaction_score") THEN "User Satisfaction Rated"
ELIF ([Changes - Field name] = "SLA metric breach") THEN "SLA Target Breached"
ELIF ([Comment public] = TRUE) THEN "Public Reply Sent"
ELIF ([Comment public] = FALSE) THEN "Internal Note Added"
ELSE NULL
ENDIF
```

**Attribute Name:** `SourceSystem`
**Formula:**
```
"Zendesk Support"
```

**Attribute Name:** `LastDataUpdate`
**Formula:**
```
NOW()
```

Schritte

Prerequisites: Stellen Sie sicher, dass Python 3.6+ auf Ihrem System installiert ist, zusammen mit den Bibliotheken requests und pandas. Sie können diese mit pip installieren: pip install requests pandas.
Generate Zendesk API Token: Melden Sie sich als Administrator bei Ihrer Zendesk Support-Instanz an. Navigieren Sie zu „Admin Center“ > „Apps und Integrationen“ > „APIs“ > „Zendesk APIs“. Fügen Sie unter dem Abschnitt „API-Token“ einen neuen aktiven API-Token hinzu und speichern Sie die generierte Token-Zeichenfolge sicher ab.
Configure the Python Script: Erstellen Sie eine neue Python-Datei (z. B. extract_zendesk_logs.py) und kopieren Sie das bereitgestellte Skript hinein. Aktualisieren Sie die Platzhaltervariablen am Anfang des Skripts: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL und ZENDESK_API_TOKEN mit Ihren spezifischen Anmeldeinformationen. Legen Sie den START_TIMESTAMP fest, um den Beginn Ihres gewünschten Datenextraktionszeitraums zu definieren (ein Unix-Epoch-Timestamp).
Understand API Endpoints: Das Skript verwendet hauptsächlich zwei Zendesk API-Endpunkte. Der incremental/tickets/cursor.json-Endpunkt wird verwendet, um alle seit dem START_TIMESTAMP aktualisierten Tickets effizient abzurufen. Für jedes Ticket ruft das Skript dann den tickets/{ticket_id}/audits.json-Endpunkt auf, um eine detaillierte Historie jeder Änderung und jedes Events zu erhalten.
Execute the Script: Führen Sie das Skript von Ihrem Terminal aus mit dem Befehl: python extract_zendesk_logs.py aus. Das Skript beginnt dann mit dem Abrufen von Daten von der Zendesk API.
Monitor Script Progress: Das Skript gibt die Anzahl der verarbeiteten Tickets in der Konsole aus, sodass Sie den Fortschritt überwachen können. Je nach Datumsbereich und Ticketvolumen kann dies eine erhebliche Zeit in Anspruch nehmen.
Data Retrieval and Pagination: Das Skript behandelt die API-Paginierung automatisch. Es beginnt mit der anfänglichen Ticket-Export-URL und folgt der in jeder API-Antwort bereitgestellten after_url, bis alle Tickets für den Zeitraum abgerufen wurden.
Event Transformation: Für jedes Ticket durchläuft das Skript dessen Audit-Historie. Es parst jedes Audit-Event und ordnet die internen Event-Typen von Zendesk (wie Create, Change, Comment) den erforderlichen Geschäftsaktivitäten (wie Incident Created, Status Changed to Open, Public Reply Sent) zu.
Handling SLA Data: Das Skript enthält eine dedizierte Funktion, get_sla_breach_events, um SLA-Metriken für jedes gelöste Ticket abzurufen. Dies ist notwendig, da SLA-Verletzungen keine Standard-Events im Audit Log sind. Diese Funktion führt einen zusätzlichen API-Aufruf durch, um Details zur Anwendung der SLA-Richtlinien zu erhalten.
Generate the Event Log: Sobald alle Tickets verarbeitet sind, kompiliert das Skript die extrahierten Events in ein pandas DataFrame und speichert das endgültige Event Log als CSV-Datei mit dem Namen zendesk_incident_event_log.csv im selben Verzeichnis, in dem das Skript ausgeführt wurde.
Prepare for Upload: Überprüfen Sie die generierte CSV-Datei auf Korrektheit. Diese Datei ist nun im erforderlichen Format, um direkt in ProcessMind zur Analyse hochgeladen zu werden.

Konfiguration

Zendesk API-Zugangsdaten: Geben Sie Ihre Zendesk-Subdomain, die zugehörige E-Mail-Adresse eines Admin- oder Agent-Kontos sowie einen gültigen API-Token an. Bewahren Sie diese Zugangsdaten sicher auf und vermeiden Sie Hardcoding in versionsverwalteten Skripten für den Produktiveinsatz.
Start-Timestamp (START_TIMESTAMP): Dieser Integer-Wert definiert den Startpunkt für die Data-Extraktion. Es muss ein Unix-Epoch-Timestamp sein. Empfohlen wird ein Startzeitraum von 3-6 Monaten in der Vergangenheit, um eine aussagekräftige Menge an Data zu sammeln, ohne das System zu überlasten. Mit einem Online-Konverter lässt sich der korrekte Timestamp für ein bestimmtes Datum ermitteln.
API-Rate-Limiting: Das Skript führt zahlreiche API-Aufrufe durch. Zendesk setzt Rate-Limits ein, die je nach Tarif variieren. Während das Skript für moderate Data-Volumen gut funktioniert, müssen Sie bei sehr großen Instanzen eventuell time.sleep()-Aufrufe in die Schleifen einbauen, um das Limit nicht zu überschreiten und 429-Fehler zu vermeiden.
Erforderliche Python-Libraries: Das Skript benötigt die requests-Library für API-Aufrufe und die pandas-Library für die Data-Manipulation und den CSV-Export. Stellen Sie sicher, dass diese in Ihrer Python-Umgebung installiert sind.
Benutzerberechtigungen: Das mit dem API-Token verknüpfte Benutzerkonto muss über ausreichende Berechtigungen verfügen, um Ticket-Data zu lesen, einschließlich Audits und Ticket-Metriken.

a Beispielabfrage python

import requests
import pandas as pd
import time
import os
from datetime import datetime

class=class="hl-string">"hl-comment"># --- CONFIGURATION --- 
class=class="hl-string">"hl-comment"># Replace with your Zendesk details
ZENDESK_SUBDOMAIN = class="hl-string">"[your_subdomain]"
ZENDESK_EMAIL = class="hl-string">"[your_login_email@example.com]"
ZENDESK_API_TOKEN = class="hl-string">"[your_zendesk_api_token]"

class=class="hl-string">"hl-comment"># Set the start time for the incremental export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1672531200 is for January 1, 2023 00:00:00 UTC
class=class="hl-string">"hl-comment"># It's recommended to extract the last 3-6 months of data.
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", ZENDESK_API_TOKEN)
SOURCE_SYSTEM = class="hl-string">"Zendesk Support"
LAST_DATA_UPDATE = datetime.utcnow().isoformat() + class="hl-string">'Z'

def get_sla_breach_events(ticket_id, session):
    class="hl-string">"""Fetches SLA metrics for a ticket and creates breach events."""
    sla_events = []
    try:
        metrics_url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/metrics.json"
        response = session.get(metrics_url)
        response.raise_for_status()
        metrics = response.json().get(class="hl-string">'ticket_metric', {})
        
        if metrics and metrics.get(class="hl-string">'sla_policy'):
            for sla in metrics.get(class="hl-string">'sla_policy').get(class="hl-string">'policy_metrics', []):
                if sla.get(class="hl-string">'breach_at'):
                    breach_timestamp = sla[class="hl-string">'breach_at']
                    sla_events.append({
                        class="hl-string">'TicketId': ticket_id,
                        class="hl-string">'ActivityName': class="hl-string">'SLA Target Breached',
                        class="hl-string">'EventTimestamp': breach_timestamp,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'TicketStatus': class="hl-string">'breached',
                        class="hl-string">'Assignee': metrics.get(class="hl-string">'assignee_updated_at'), 
                        class="hl-string">'AssignedGroup': metrics.get(class="hl-string">'group_stations'),
                        class="hl-string">'TicketPriority': None, class=class="hl-string">"hl-comment"># Not directly available in metrics
                        class="hl-string">'Channel': None, class=class="hl-string">"hl-comment"># Not directly available in metrics
                        class="hl-string">'SlaStatus': fclass="hl-string">"{sla.get('metric')} Breached",
                        class="hl-string">'EventEndTime': breach_timestamp
                    })
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Could not fetch SLA metrics for ticket {ticket_id}: {e}")
    return sla_events

def process_ticket(ticket, session):
    class="hl-string">"""Processes a single ticket's audits to extract all relevant events."""
    all_events = []
    ticket_id = ticket[class="hl-string">'id']
    ticket_created_at = ticket[class="hl-string">'created_at']
    
    class=class="hl-string">"hl-comment"># 1. Incident Created event
    all_events.append({
        class="hl-string">'TicketId': ticket_id,
        class="hl-string">'ActivityName': class="hl-string">'Incident Created',
        class="hl-string">'EventTimestamp': ticket_created_at,
        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
        class="hl-string">'TicketStatus': class="hl-string">'new',
        class="hl-string">'Assignee': ticket.get(class="hl-string">'assignee_id'),
        class="hl-string">'AssignedGroup': ticket.get(class="hl-string">'group_id'),
        class="hl-string">'TicketPriority': ticket.get(class="hl-string">'priority'),
        class="hl-string">'Channel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
        class="hl-string">'SlaStatus': None,
        class="hl-string">'EventEndTime': ticket_created_at
    })
    
    class=class="hl-string">"hl-comment"># Process audits for other events
    audits_url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/audits.json"
    try:
        response = session.get(audits_url)
        response.raise_for_status()
        audits = response.json().get(class="hl-string">'audits', [])
        
        is_first_group_assignment = True
        is_first_agent_assignment = True

        for audit in audits:
            event_timestamp = audit[class="hl-string">'created_at']
            for event in audit.get(class="hl-string">'events', []):
                activity = {}
                event_type = event.get(class="hl-string">'type')

                if event_type == class="hl-string">'Change':
                    field_name = event.get(class="hl-string">'field_name')
                    value = event.get(class="hl-string">'value')
                    
                    if field_name == class="hl-string">'group_id' and value is not None:
                        activity_name = class="hl-string">'Ticket Assigned to Group' if is_first_group_assignment else class="hl-string">'Ticket Reassigned'
                        is_first_group_assignment = False
                        activity = {class="hl-string">'ActivityName': activity_name, class="hl-string">'AssignedGroup': value}

                    elif field_name == class="hl-string">'assignee_id' and value is not None:
                        activity_name = class="hl-string">'Ticket Assigned to Agent' if is_first_agent_assignment else class="hl-string">'Ticket Reassigned'
                        is_first_agent_assignment = False
                        activity = {class="hl-string">'ActivityName': activity_name, class="hl-string">'Assignee': value}
                        
                    elif field_name == class="hl-string">'priority':
                        activity = {class="hl-string">'ActivityName': class="hl-string">'Priority Set', class="hl-string">'TicketPriority': value}
                        
                    elif field_name == class="hl-string">'status':
                        if value == class="hl-string">'open': activity = {class="hl-string">'ActivityName': class="hl-string">'Status Changed to Open', class="hl-string">'TicketStatus': class="hl-string">'open'}
                        elif value == class="hl-string">'pending': activity = {class="hl-string">'ActivityName': class="hl-string">'Status Changed to Pending', class="hl-string">'TicketStatus': class="hl-string">'pending'}
                        elif value == class="hl-string">'solved': activity = {class="hl-string">'ActivityName': class="hl-string">'Incident Resolved', class="hl-string">'TicketStatus': class="hl-string">'solved'}
                        elif value == class="hl-string">'closed': activity = {class="hl-string">'ActivityName': class="hl-string">'Incident Closed', class="hl-string">'TicketStatus': class="hl-string">'closed'}
                        
                elif event_type == class="hl-string">'Comment':
                    is_public = event.get(class="hl-string">'public', False)
                    activity_name = class="hl-string">'Public Reply Sent' if is_public else class="hl-string">'Internal Note Added'
                    activity = {class="hl-string">'ActivityName': activity_name}

                elif event_type == class="hl-string">'SatisfactionRating':
                    activity = {class="hl-string">'ActivityName': class="hl-string">'User Satisfaction Rated'}

                if activity:
                    base_event = {
                        class="hl-string">'TicketId': ticket_id,
                        class="hl-string">'EventTimestamp': event_timestamp,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'TicketStatus': ticket.get(class="hl-string">'status'),
                        class="hl-string">'Assignee': ticket.get(class="hl-string">'assignee_id'),
                        class="hl-string">'AssignedGroup': ticket.get(class="hl-string">'group_id'),
                        class="hl-string">'TicketPriority': ticket.get(class="hl-string">'priority'),
                        class="hl-string">'Channel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
                        class="hl-string">'SlaStatus': None,
                        class="hl-string">'EventEndTime': event_timestamp
                    }
                    base_event.update(activity)
                    all_events.append(base_event)
    
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Could not process audits for ticket {ticket_id}: {e}")

    class=class="hl-string">"hl-comment"># Get SLA Breach events if ticket is solved
    if ticket.get(class="hl-string">'status') in [class="hl-string">'solved', class="hl-string">'closed']:
        all_events.extend(get_sla_breach_events(ticket_id, session))

    return all_events

def main():
    class="hl-string">"""Main function to fetch tickets and generate the event log."""
    all_ticket_events = []
    url = fclass="hl-string">"{BASE_URL}/incremental/tickets/cursor.json?start_time={START_TIMESTAMP}"
    
    with requests.Session() as session:
        session.auth = AUTH
        
        ticket_count = 0
        while url:
            try:
                response = session.get(url)
                response.raise_for_status()
                data = response.json()
                tickets = data.get(class="hl-string">'tickets', [])
                
                for ticket in tickets:
                    ticket_count += 1
                    all_ticket_events.extend(process_ticket(ticket, session))
                    if ticket_count % 100 == 0:
                        print(fclass="hl-string">"Processed {ticket_count} tickets...")

                if data.get(class="hl-string">'end_of_stream', True):
                    print(class="hl-string">"Reached the end of the ticket stream.")
                    break
                
                url = data.get(class="hl-string">'after_url')
                class=class="hl-string">"hl-comment"># Respect rate limits
                time.sleep(1) 

            except requests.exceptions.RequestException as e:
                print(fclass="hl-string">"An API error occurred: {e}")
                if hasattr(e, class="hl-string">'response') and e.response.status_code == 429:
                    retry_after = int(e.response.headers.get(class="hl-string">'Retry-After', 60))
                    print(fclass="hl-string">"Rate limit exceeded. Retrying after {retry_after} seconds...")
                    time.sleep(retry_after)
                else:
                    break

    if not all_ticket_events:
        print(class="hl-string">"No events were extracted. Check configuration and API access.")
        return

    print(fclass="hl-string">"\nTotal events extracted: {len(all_ticket_events)}")
    df = pd.DataFrame(all_ticket_events)
    
    class=class="hl-string">"hl-comment"># Reorder columns for clarity
    cols = [
        class="hl-string">'TicketId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'EventEndTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'TicketStatus', class="hl-string">'Assignee', class="hl-string">'AssignedGroup', class="hl-string">'TicketPriority', class="hl-string">'Channel', class="hl-string">'SlaStatus'
    ]
    df = df[cols]
    
    class=class="hl-string">"hl-comment"># Save to CSV
    output_file = class="hl-string">'zendesk_incident_event_log.csv'
    df.to_csv(output_file, index=False)
    print(fclass="hl-string">"Event log successfully saved to {output_file}")

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

Schritte

Prerequisites: Stellen Sie sicher, dass Python 3.6+ auf Ihrem System installiert ist, zusammen mit den Bibliotheken requests und pandas. Sie können diese mit pip installieren: pip install requests pandas.
Generate Zendesk API Token: Melden Sie sich als Administrator bei Ihrer Zendesk Support-Instanz an. Navigieren Sie zu „Admin Center“ > „Apps und Integrationen“ > „APIs“ > „Zendesk APIs“. Fügen Sie unter dem Abschnitt „API-Token“ einen neuen aktiven API-Token hinzu und speichern Sie die generierte Token-Zeichenfolge sicher ab.
Configure the Python Script: Erstellen Sie eine neue Python-Datei (z. B. extract_zendesk_logs.py) und kopieren Sie das bereitgestellte Skript hinein. Aktualisieren Sie die Platzhaltervariablen am Anfang des Skripts: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL und ZENDESK_API_TOKEN mit Ihren spezifischen Anmeldeinformationen. Legen Sie den START_TIMESTAMP fest, um den Beginn Ihres gewünschten Datenextraktionszeitraums zu definieren (ein Unix-Epoch-Timestamp).
Understand API Endpoints: Das Skript verwendet hauptsächlich zwei Zendesk API-Endpunkte. Der incremental/tickets/cursor.json-Endpunkt wird verwendet, um alle seit dem START_TIMESTAMP aktualisierten Tickets effizient abzurufen. Für jedes Ticket ruft das Skript dann den tickets/{ticket_id}/audits.json-Endpunkt auf, um eine detaillierte Historie jeder Änderung und jedes Events zu erhalten.
Execute the Script: Führen Sie das Skript von Ihrem Terminal aus mit dem Befehl: python extract_zendesk_logs.py aus. Das Skript beginnt dann mit dem Abrufen von Daten von der Zendesk API.
Monitor Script Progress: Das Skript gibt die Anzahl der verarbeiteten Tickets in der Konsole aus, sodass Sie den Fortschritt überwachen können. Je nach Datumsbereich und Ticketvolumen kann dies eine erhebliche Zeit in Anspruch nehmen.
Data Retrieval and Pagination: Das Skript behandelt die API-Paginierung automatisch. Es beginnt mit der anfänglichen Ticket-Export-URL und folgt der in jeder API-Antwort bereitgestellten after_url, bis alle Tickets für den Zeitraum abgerufen wurden.
Event Transformation: Für jedes Ticket durchläuft das Skript dessen Audit-Historie. Es parst jedes Audit-Event und ordnet die internen Event-Typen von Zendesk (wie Create, Change, Comment) den erforderlichen Geschäftsaktivitäten (wie Incident Created, Status Changed to Open, Public Reply Sent) zu.
Handling SLA Data: Das Skript enthält eine dedizierte Funktion, get_sla_breach_events, um SLA-Metriken für jedes gelöste Ticket abzurufen. Dies ist notwendig, da SLA-Verletzungen keine Standard-Events im Audit Log sind. Diese Funktion führt einen zusätzlichen API-Aufruf durch, um Details zur Anwendung der SLA-Richtlinien zu erhalten.
Generate the Event Log: Sobald alle Tickets verarbeitet sind, kompiliert das Skript die extrahierten Events in ein pandas DataFrame und speichert das endgültige Event Log als CSV-Datei mit dem Namen zendesk_incident_event_log.csv im selben Verzeichnis, in dem das Skript ausgeführt wurde.
Prepare for Upload: Überprüfen Sie die generierte CSV-Datei auf Korrektheit. Diese Datei ist nun im erforderlichen Format, um direkt in ProcessMind zur Analyse hochgeladen zu werden.

Konfiguration

Zendesk API-Zugangsdaten: Geben Sie Ihre Zendesk-Subdomain, die zugehörige E-Mail-Adresse eines Admin- oder Agent-Kontos sowie einen gültigen API-Token an. Bewahren Sie diese Zugangsdaten sicher auf und vermeiden Sie Hardcoding in versionsverwalteten Skripten für den Produktiveinsatz.
Start-Timestamp (START_TIMESTAMP): Dieser Integer-Wert definiert den Startpunkt für die Data-Extraktion. Es muss ein Unix-Epoch-Timestamp sein. Empfohlen wird ein Startzeitraum von 3-6 Monaten in der Vergangenheit, um eine aussagekräftige Menge an Data zu sammeln, ohne das System zu überlasten. Mit einem Online-Konverter lässt sich der korrekte Timestamp für ein bestimmtes Datum ermitteln.
API-Rate-Limiting: Das Skript führt zahlreiche API-Aufrufe durch. Zendesk setzt Rate-Limits ein, die je nach Tarif variieren. Während das Skript für moderate Data-Volumen gut funktioniert, müssen Sie bei sehr großen Instanzen eventuell time.sleep()-Aufrufe in die Schleifen einbauen, um das Limit nicht zu überschreiten und 429-Fehler zu vermeiden.
Erforderliche Python-Libraries: Das Skript benötigt die requests-Library für API-Aufrufe und die pandas-Library für die Data-Manipulation und den CSV-Export. Stellen Sie sicher, dass diese in Ihrer Python-Umgebung installiert sind.
Benutzerberechtigungen: Das mit dem API-Token verknüpfte Benutzerkonto muss über ausreichende Berechtigungen verfügen, um Ticket-Data zu lesen, einschließlich Audits und Ticket-Metriken.

a Beispielabfrage python

import requests
import pandas as pd
import time
import os
from datetime import datetime

class=class="hl-string">"hl-comment"># --- CONFIGURATION --- 
class=class="hl-string">"hl-comment"># Replace with your Zendesk details
ZENDESK_SUBDOMAIN = class="hl-string">"[your_subdomain]"
ZENDESK_EMAIL = class="hl-string">"[your_login_email@example.com]"
ZENDESK_API_TOKEN = class="hl-string">"[your_zendesk_api_token]"

class=class="hl-string">"hl-comment"># Set the start time for the incremental export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1672531200 is for January 1, 2023 00:00:00 UTC
class=class="hl-string">"hl-comment"># It's recommended to extract the last 3-6 months of data.
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", ZENDESK_API_TOKEN)
SOURCE_SYSTEM = class="hl-string">"Zendesk Support"
LAST_DATA_UPDATE = datetime.utcnow().isoformat() + class="hl-string">'Z'

def get_sla_breach_events(ticket_id, session):
    class="hl-string">"""Fetches SLA metrics for a ticket and creates breach events."""
    sla_events = []
    try:
        metrics_url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/metrics.json"
        response = session.get(metrics_url)
        response.raise_for_status()
        metrics = response.json().get(class="hl-string">'ticket_metric', {})
        
        if metrics and metrics.get(class="hl-string">'sla_policy'):
            for sla in metrics.get(class="hl-string">'sla_policy').get(class="hl-string">'policy_metrics', []):
                if sla.get(class="hl-string">'breach_at'):
                    breach_timestamp = sla[class="hl-string">'breach_at']
                    sla_events.append({
                        class="hl-string">'TicketId': ticket_id,
                        class="hl-string">'ActivityName': class="hl-string">'SLA Target Breached',
                        class="hl-string">'EventTimestamp': breach_timestamp,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'TicketStatus': class="hl-string">'breached',
                        class="hl-string">'Assignee': metrics.get(class="hl-string">'assignee_updated_at'), 
                        class="hl-string">'AssignedGroup': metrics.get(class="hl-string">'group_stations'),
                        class="hl-string">'TicketPriority': None, class=class="hl-string">"hl-comment"># Not directly available in metrics
                        class="hl-string">'Channel': None, class=class="hl-string">"hl-comment"># Not directly available in metrics
                        class="hl-string">'SlaStatus': fclass="hl-string">"{sla.get('metric')} Breached",
                        class="hl-string">'EventEndTime': breach_timestamp
                    })
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Could not fetch SLA metrics for ticket {ticket_id}: {e}")
    return sla_events

def process_ticket(ticket, session):
    class="hl-string">"""Processes a single ticket's audits to extract all relevant events."""
    all_events = []
    ticket_id = ticket[class="hl-string">'id']
    ticket_created_at = ticket[class="hl-string">'created_at']
    
    class=class="hl-string">"hl-comment"># 1. Incident Created event
    all_events.append({
        class="hl-string">'TicketId': ticket_id,
        class="hl-string">'ActivityName': class="hl-string">'Incident Created',
        class="hl-string">'EventTimestamp': ticket_created_at,
        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
        class="hl-string">'TicketStatus': class="hl-string">'new',
        class="hl-string">'Assignee': ticket.get(class="hl-string">'assignee_id'),
        class="hl-string">'AssignedGroup': ticket.get(class="hl-string">'group_id'),
        class="hl-string">'TicketPriority': ticket.get(class="hl-string">'priority'),
        class="hl-string">'Channel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
        class="hl-string">'SlaStatus': None,
        class="hl-string">'EventEndTime': ticket_created_at
    })
    
    class=class="hl-string">"hl-comment"># Process audits for other events
    audits_url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/audits.json"
    try:
        response = session.get(audits_url)
        response.raise_for_status()
        audits = response.json().get(class="hl-string">'audits', [])
        
        is_first_group_assignment = True
        is_first_agent_assignment = True

        for audit in audits:
            event_timestamp = audit[class="hl-string">'created_at']
            for event in audit.get(class="hl-string">'events', []):
                activity = {}
                event_type = event.get(class="hl-string">'type')

                if event_type == class="hl-string">'Change':
                    field_name = event.get(class="hl-string">'field_name')
                    value = event.get(class="hl-string">'value')
                    
                    if field_name == class="hl-string">'group_id' and value is not None:
                        activity_name = class="hl-string">'Ticket Assigned to Group' if is_first_group_assignment else class="hl-string">'Ticket Reassigned'
                        is_first_group_assignment = False
                        activity = {class="hl-string">'ActivityName': activity_name, class="hl-string">'AssignedGroup': value}

                    elif field_name == class="hl-string">'assignee_id' and value is not None:
                        activity_name = class="hl-string">'Ticket Assigned to Agent' if is_first_agent_assignment else class="hl-string">'Ticket Reassigned'
                        is_first_agent_assignment = False
                        activity = {class="hl-string">'ActivityName': activity_name, class="hl-string">'Assignee': value}
                        
                    elif field_name == class="hl-string">'priority':
                        activity = {class="hl-string">'ActivityName': class="hl-string">'Priority Set', class="hl-string">'TicketPriority': value}
                        
                    elif field_name == class="hl-string">'status':
                        if value == class="hl-string">'open': activity = {class="hl-string">'ActivityName': class="hl-string">'Status Changed to Open', class="hl-string">'TicketStatus': class="hl-string">'open'}
                        elif value == class="hl-string">'pending': activity = {class="hl-string">'ActivityName': class="hl-string">'Status Changed to Pending', class="hl-string">'TicketStatus': class="hl-string">'pending'}
                        elif value == class="hl-string">'solved': activity = {class="hl-string">'ActivityName': class="hl-string">'Incident Resolved', class="hl-string">'TicketStatus': class="hl-string">'solved'}
                        elif value == class="hl-string">'closed': activity = {class="hl-string">'ActivityName': class="hl-string">'Incident Closed', class="hl-string">'TicketStatus': class="hl-string">'closed'}
                        
                elif event_type == class="hl-string">'Comment':
                    is_public = event.get(class="hl-string">'public', False)
                    activity_name = class="hl-string">'Public Reply Sent' if is_public else class="hl-string">'Internal Note Added'
                    activity = {class="hl-string">'ActivityName': activity_name}

                elif event_type == class="hl-string">'SatisfactionRating':
                    activity = {class="hl-string">'ActivityName': class="hl-string">'User Satisfaction Rated'}

                if activity:
                    base_event = {
                        class="hl-string">'TicketId': ticket_id,
                        class="hl-string">'EventTimestamp': event_timestamp,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'TicketStatus': ticket.get(class="hl-string">'status'),
                        class="hl-string">'Assignee': ticket.get(class="hl-string">'assignee_id'),
                        class="hl-string">'AssignedGroup': ticket.get(class="hl-string">'group_id'),
                        class="hl-string">'TicketPriority': ticket.get(class="hl-string">'priority'),
                        class="hl-string">'Channel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
                        class="hl-string">'SlaStatus': None,
                        class="hl-string">'EventEndTime': event_timestamp
                    }
                    base_event.update(activity)
                    all_events.append(base_event)
    
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Could not process audits for ticket {ticket_id}: {e}")

    class=class="hl-string">"hl-comment"># Get SLA Breach events if ticket is solved
    if ticket.get(class="hl-string">'status') in [class="hl-string">'solved', class="hl-string">'closed']:
        all_events.extend(get_sla_breach_events(ticket_id, session))

    return all_events

def main():
    class="hl-string">"""Main function to fetch tickets and generate the event log."""
    all_ticket_events = []
    url = fclass="hl-string">"{BASE_URL}/incremental/tickets/cursor.json?start_time={START_TIMESTAMP}"
    
    with requests.Session() as session:
        session.auth = AUTH
        
        ticket_count = 0
        while url:
            try:
                response = session.get(url)
                response.raise_for_status()
                data = response.json()
                tickets = data.get(class="hl-string">'tickets', [])
                
                for ticket in tickets:
                    ticket_count += 1
                    all_ticket_events.extend(process_ticket(ticket, session))
                    if ticket_count % 100 == 0:
                        print(fclass="hl-string">"Processed {ticket_count} tickets...")

                if data.get(class="hl-string">'end_of_stream', True):
                    print(class="hl-string">"Reached the end of the ticket stream.")
                    break
                
                url = data.get(class="hl-string">'after_url')
                class=class="hl-string">"hl-comment"># Respect rate limits
                time.sleep(1) 

            except requests.exceptions.RequestException as e:
                print(fclass="hl-string">"An API error occurred: {e}")
                if hasattr(e, class="hl-string">'response') and e.response.status_code == 429:
                    retry_after = int(e.response.headers.get(class="hl-string">'Retry-After', 60))
                    print(fclass="hl-string">"Rate limit exceeded. Retrying after {retry_after} seconds...")
                    time.sleep(retry_after)
                else:
                    break

    if not all_ticket_events:
        print(class="hl-string">"No events were extracted. Check configuration and API access.")
        return

    print(fclass="hl-string">"\nTotal events extracted: {len(all_ticket_events)}")
    df = pd.DataFrame(all_ticket_events)
    
    class=class="hl-string">"hl-comment"># Reorder columns for clarity
    cols = [
        class="hl-string">'TicketId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'EventEndTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'TicketStatus', class="hl-string">'Assignee', class="hl-string">'AssignedGroup', class="hl-string">'TicketPriority', class="hl-string">'Channel', class="hl-string">'SlaStatus'
    ]
    df = df[cols]
    
    class=class="hl-string">"hl-comment"># Save to CSV
    output_file = class="hl-string">'zendesk_incident_event_log.csv'
    df.to_csv(output_file, index=False)
    print(fclass="hl-string">"Event log successfully saved to {output_file}")

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

Schritte

Access Zendesk Explore: Loggen Sie sich in Ihre Zendesk Support-Instanz mit einem Benutzerkonto ein, das über Berechtigungen zum Erstellen und Verwalten von Berichten in Zendesk Explore verfügt.
Create a New Report: Navigieren Sie zum Explore-Modul. Klicken Sie in der linken Navigationsleiste auf das Symbol „Berichte“ und dann auf die Schaltfläche „Neuen Bericht erstellen“.
Select the Dataset: Wählen Sie im Fenster „Dataset auswählen“ das Dataset „Support: Ticket-Updates [Standard]“ aus. Dieses Dataset enthält den Audit-Trail für jede Ticketänderung, der für die Erstellung eines Event Logs unerlässlich ist.
Add Initial Attributes (Columns): Gehen Sie im Berichts-Builder zum Abschnitt „Zeilen“. Klicken Sie auf „Hinzufügen“ und wählen Sie die folgenden Attribute aus. Diese bilden die Spalten Ihres Event Logs: Ticket ID, Update - Timestamp, Ticketstatus, Name des Bearbeiters, Ticketgruppe, Ticketpriorität, Ticketkanal, Änderungen - Feldname, Änderungen - Vorheriger Wert, Änderungen - Neuer Wert, Öffentlicher Kommentar.
Create Calculated Attributes: Dies ist der wichtigste Schritt. Gehen Sie zum Menü „Berechnungen“ (das Becher-Symbol) und wählen Sie „Standard berechnetes Attribut“ aus. Erstellen Sie die drei Attribute, die im Abschnitt „Abfrage“ unten definiert sind: ActivityName, SourceSystem und LastDataUpdate. Sie müssen die bereitgestellten Formeln exakt kopieren.
Refine Report Columns: Fügen Sie Ihre neu erstellten berechneten Attribute (ActivityName, SourceSystem, LastDataUpdate) zum Abschnitt „Zeilen“ hinzu. Sie können nun die Rohfelder, die zur Erstellung von ActivityName verwendet wurden (Änderungen - Feldname, Änderungen - Vorheriger Wert, Änderungen - Neuer Wert, Öffentlicher Kommentar), entfernen, um die Ansicht zu bereinigen.
Add Report Filters: Gehen Sie zum Abschnitt „Filter“ und klicken Sie auf „Hinzufügen“. Fügen Sie einen Filter für „Update - Date“ hinzu und wählen Sie einen geeigneten Datumsbereich aus (z. B. die letzten 3 Monate). Fügen Sie einen weiteren Filter für Ihr berechnetes Attribut ActivityName hinzu und schließen Sie Nullwerte aus, um Ticket-Updates zu entfernen, die keiner gewünschten Aktivität entsprechen.
Run and Review the Report: Zendesk Explore aktualisiert den Bericht automatisch, wenn Sie Attribute und Filter hinzufügen. Überprüfen Sie die Datentabelle, um sicherzustellen, dass die Zeilen und Spalten wie erwartet angezeigt werden. Der Bericht sollte eine Zeile pro Event anzeigen.
Export the Data to CSV: Sobald der Bericht fertiggestellt ist, klicken Sie oben rechts auf die Schaltfläche „Exportieren“ und wählen Sie „CSV“ aus. Zendesk generiert und lädt die CSV-Datei herunter.
Prepare for Upload: Öffnen Sie die exportierte CSV-Datei. Benennen Sie die Spaltenüberschriften um, um sie an die erforderlichen Attributnamen für Ihr Process Mining-Tool anzupassen (z. B. benennen Sie „Ticket ID“ in TicketId, „Update - Timestamp“ in EventTimestamp um). Stellen Sie sicher, dass das Datumsformat für Zeitstempel ISO 8601-konform ist. Die Datei ist nun zum Hochladen bereit.

Konfiguration

Zendesk Dataset: Der Bericht muss auf dem Dataset „Support: Ticket-Updates [Standard]“ basieren. Dies ist das einzige Standard-Dataset, das den detaillierten Audit-Trail bereitstellt, der zur ereignisweisen Rekonstruktion des Prozesses erforderlich ist.
Datumsbereichsfilterung: Es ist entscheidend, einen Datumsfilter anzuwenden, um das Datenvolumen zu begrenzen. Verwenden Sie das Attribut „Update - Date“ als primären Filter. Ein Datenbereich von 3-6 Monaten wird typischerweise für eine erste Analyse empfohlen.
Aktivitätenfilter: Nachdem Sie das berechnete Attribut „ActivityName“ erstellt haben, müssen Sie den Bericht so filtern, dass Zeilen ausgeschlossen werden, bei denen dieser Wert null ist. Dadurch werden irrelevante Ticketänderungen (z. B. Systemaktualisierungen, Tag-Änderungen) aus Ihrem Event Log entfernt.
Berechnete Attribute: Die Logik dieser Extraktion basiert stark auf einem Standard-Berechneten-Attribut, um Rohdatenänderungen in lesbare Aktivitätsnamen zu übersetzen. Präzision in der Formel ist entscheidend.
Voraussetzungen: Der Benutzer, der den Bericht ausführt, benötigt mindestens die Rolle „Viewer“ in Zendesk Explore. Zum Erstellen und Speichern des Berichts sind „Editor“- oder „Admin“-Berechtigungen erforderlich.

a Beispielabfrage config

This extraction is configured using the Zendesk Explore UI. The core logic is contained within a standard calculated attribute. 

**1. Dataset Selection:**
* `Support: Ticket updates [default]`

**2. Report Columns (Add to 'Rows' panel):**
* `Ticket ID`
* `ActivityName` (Calculated Attribute)
* `EventTimestamp` (Use the `Update - Timestamp` attribute)
* `SourceSystem` (Calculated Attribute)
* `LastDataUpdate` (Calculated Attribute)
* `Ticket status`
* `Assignee name`
* `Ticket group`
* `Ticket priority`
* `Ticket channel`
* `SLA metric status`
* `EventEndTime` (Use the `Update - Timestamp` attribute again)

**3. Standard Calculated Attribute Formulas:**

**Attribute Name:** `ActivityName`
**Formula:**
```
IF ([Changes - Field name] = "status" AND [Changes - Previous value] = NULL AND [Changes - New value] = "new") THEN "Incident Created"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "open") THEN "Status Changed to Open"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN "Status Changed to Pending"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "solved") THEN "Incident Resolved"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "closed") THEN "Incident Closed"
ELIF ([Changes - Field name] = "group_id") THEN "Ticket Assigned to Group"
ELIF ([Changes - Field name] = "assignee_id") THEN "Ticket Assigned to Agent"
ELIF ([Changes - Field name] = "priority") THEN "Priority Set"
ELIF ([Changes - Field name] = "satisfaction_score") THEN "User Satisfaction Rated"
ELIF ([Changes - Field name] = "SLA metric breach") THEN "SLA Target Breached"
ELIF ([Comment public] = TRUE) THEN "Public Reply Sent"
ELIF ([Comment public] = FALSE) THEN "Internal Note Added"
ELSE NULL
ENDIF
```

**Attribute Name:** `SourceSystem`
**Formula:**
```
"Zendesk Support"
```

**Attribute Name:** `LastDataUpdate`
**Formula:**
```
NOW()
```

Ihr `Incident Management Data Template`

Ihr `Incident Management Data Template`

`Incident Management`-`Attribute`

`Incident Management`-Aktivitäten

Extraktionsleitfäden

Zendesk Explore UI-Bericht als CSV-Datei-Export

Schritte

Konfiguration

a Beispielabfrage config

Python-Skript unter Verwendung der Zendesk Support REST API

Schritte

Konfiguration

a Beispielabfrage python

Zendesk Incremental Export API für Massendaten-Synchronisierung

Schritte

Konfiguration

a Beispielabfrage python

Drittanbieter-ETL-Tool mit Zendesk API Connector

Schritte

Konfiguration

a Beispielabfrage config

Bereit, um loszulegen?

Incident Management optimieren, heute noch schneller lösen

Ihr Incident Management Data Template

Ihr Incident Management Data Template

Incident Management-Attribute

Incident Management-Aktivitäten

Extraktionsleitfäden

Zendesk Explore UI-Bericht als CSV-Datei-Export

Schritte

Konfiguration

a Beispielabfrage config

Python-Skript unter Verwendung der Zendesk Support REST API

Schritte

Konfiguration

a Beispielabfrage python

Zendesk Incremental Export API für Massendaten-Synchronisierung

Schritte

Konfiguration

a Beispielabfrage python

Drittanbieter-ETL-Tool mit Zendesk API Connector

Schritte

Konfiguration

a Beispielabfrage config

Ihre Privatsphäre ist uns wichtig

Bereit, um loszulegen?

Incident Management optimieren, heute noch schneller lösen

Ihr `Incident Management Data Template`

Ihr `Incident Management Data Template`

`Incident Management`-`Attribute`

`Incident Management`-Aktivitäten