> Kontinuierliche Prozessverbesserung > Incident Management > Zendesk Support > Daten Template

Ihr Daten-Template für das Incident Management

Zendesk Support

Attribute des Incident Managements (23) Aktivitäten des Incident Managements (13) Anleitungen zur Datenextraktion (4)

Ihr Daten-Template für das Incident Management

Dieses Template bietet einen strukturierten Überblick über die wesentlichen Daten, die Sie für eine effektive Analyse Ihres Incident-Management-Prozesses benötigen. Es beschreibt die wichtigsten zu erfassenden Attribute und relevanten Aktivitäten und enthält praktische Hinweise zur Extraktion dieser Daten aus Zendesk Support. Verwenden Sie es, damit Ihr Process-Mining-Projekt mit einem vollständigen und aussagekräftigen Datensatz startet.

Empfohlene Attribute für die Erfassung
Wichtige Aktivitäten für die Prozessmodellierung
Praktische Hinweise zur Datenextraktion

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

Template herunterladen

Attribute des Incident Managements

Dies sind die empfohlenen Datenfelder, die Sie für eine gründliche Analyse Ihres Incident-Management-Prozesses in Ihr Event Log aufnehmen sollten.

5 Erforderlich 7 Empfohlen 11 Optional

	Name	Beschreibung
	Ereignis-Timestamp EventTimestamp	Das genaue Datum und die genaue Uhrzeit, zu denen die Aktivität stattgefunden hat.
Beschreibung Dieser Timestamp erfasst den genauen Zeitpunkt eines Ereignisses im Incident-Lebenszyklus, beispielsweise das Hinzufügen eines Kommentars oder eine Statusänderung. Er legt die chronologische Reihenfolge aller Aktivitäten innerhalb eines Cases fest. Dieses Attribut ist grundlegend für jede zeitbasierte Process-Mining-Analyse. Es dient zur Berechnung der Durchlaufzeiten zwischen Aktivitäten, zur Erkennung von Wartezeiten, zur Messung der gesamten Case-Dauer und zur Analyse der Prozessleistung über verschiedene Zeiträume. Präzise Timestamps sind erforderlich, um eine animierte Prozesslandkarte zu erstellen, die den zeitlichen Verlauf von Cases zeigt, sowie Performance-Dashboards mit KPIs wie der durchschnittlichen Lösungszeit aufzubauen. Warum das wichtig ist Timestamps liefern den zeitlichen Kontext für alle Aktivitäten. Dadurch lassen sich Dauern berechnen, Engpässe erkennen und Prozessleistungen im Zeitverlauf analysieren. Bezugsquelle Zendesk Ticket Audits API (/api/v2/tickets/{ticket_id}/audits), Feld created_at für jedes Audit-Ereignis. Beispiele 2023-04-15T10:00:00Z2023-04-15T10:05:12Z2023-04-16T14:30:00Z
	Incident-ID TicketId	Die vom System erzeugte eindeutige Kennung für jedes Incident-Ticket.
Beschreibung Die Incident ID ist der Primärschlüssel, der jeden Incident-Case in 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 Zeitpunkt der Incident-Erstellung bis zum Abschluss. In der Analyse ist diese ID entscheidend, um den End-to-End-Verlauf jedes Incidents zu rekonstruieren. Sie ermöglicht die Aggregation von Event-Daten, um Kennzahlen wie die gesamte Lösungszeit, die Anzahl der Übergaben und die Einhaltung von Service Level Agreements für einzelne Cases zu verfolgen. Durch die Gruppierung der Ereignisse nach dieser ID können Analysten Prozessabläufe visualisieren, häufige Pfade erkennen und Abweichungen vom Standardprozess feststellen. Warum das wichtig ist Dies ist die zentrale Kennung, die alle Ereignisse mit einem einzelnen Incident verknüpft. Dadurch lässt sich der gesamte Lebenszyklus nachvollziehen und die Prozessleistung präzise analysieren. Bezugsquelle Zendesk Tickets API (/api/v2/tickets/{id}), Feld id. Beispiele 19428230113521941055
	Aktivität ActivityName	Der Name der geschäftlichen Aktivität oder des Ereignisses, das zu einem bestimmten Zeitpunkt im Incident-Lebenszyklus stattgefunden hat.
Beschreibung Dieses Attribut beschreibt einen konkreten Schritt oder eine Aktion im Incident-Management-Prozess, beispielsweise „Incident erstellt“, „Ticket einem Agent zugewiesen“ oder „Incident gelöst“. Die Aktivitäten werden aus dem Event Log oder den Audit-Trail-Daten von Zendesk abgeleitet, in denen Systemänderungen protokolliert werden. Im Process Mining bildet die Abfolge dieser Aktivitäten die Prozesslandkarte und damit die Grundlage für alle Analysen. Durch die Analyse des Aktivitätsflusses können Unternehmen die tatsächlichen Pfade von Incidents ermitteln, Engpässe zwischen Schritten erkennen, Schleifen wiederholter Bearbeitung messen, beispielsweise beim erneuten Öffnen eines gelösten Tickets, und die Konformität mit einem definierten Standardprozess prüfen. Warum das wichtig ist Die Abfolge der Aktivitäten definiert den Prozessfluss. Dieser bildet den Kern der Process-Mining-Analyse zur Erkennung von Ineffizienzen, Abweichungen und Verbesserungspotenzialen. Bezugsquelle Abgeleitet aus Ereignissen der Zendesk Ticket Audits API. Ein „Change“-Ereignis für das Statusfeld kann beispielsweise auf „Status geändert“ abgebildet werden. Beispiele Incident erstelltTicket einem Agent zugewiesenStatus auf Pending geändertIncident 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. In der Regel handelt es sich um einen einzelnen Wert, der dem gesamten Datensatz eines Aktualisierungszyklus zugewiesen wird. Diese Information ist für Data Governance und für die Nutzer der Process-Mining-Analyse wichtig. Sie zeigt, wie aktuell die Daten sind, und hilft Analysten zu verstehen, ob sie die derzeit verfügbaren Informationen betrachten. Das ist besonders relevant für die Überwachung der operativen Leistung und für zeitnahe Entscheidungen auf Grundlage der Analyse. Warum das wichtig ist Liefert wichtigen Kontext zur Aktualität der Daten. So erkennen Nutzer, wie aktuell die Analyse ist und wann die Daten zuletzt aus der Quelle übernommen wurden. Bezugsquelle Timestamp, der vom ETL-/Datenpipeline-Prozess nach Abschluss der Datenaktualisierung erzeugt wird. Beispiele 2023-10-27T08:00:00Z2023-10-28T08:00:00Z
	Quellsystem SourceSystem	Das System, aus dem die Incident-Daten extrahiert wurden.
Beschreibung Dieses Attribut identifiziert die Herkunft der Prozessdaten. In dieser Ansicht wäre der Wert statisch, beispielsweise „Zendesk Support“, und würde anzeigen, dass alle Ereignisse und Attribute aus diesem System stammen. Wenn Daten aus mehreren Systemen kombiniert werden, ist dieses Feld entscheidend, um die verschiedenen Datenquellen zu unterscheiden. Es unterstützt die Datenintegrität und ermöglicht quellsystemspezifische Analysen, etwa einen Vergleich des Incident-Management-Prozesses in Zendesk mit einem anderen ITSM-Tool. Warum das wichtig ist Identifiziert die Herkunft der Daten. Das ist für Data Governance und Analysen mit Daten aus mehreren Quellsystemen entscheidend. Bezugsquelle Statischer Wert, der während der Datentransformation zur Identifizierung der Datenherkunft gesetzt wird. Beispiele Zendesk SupportZendesk
	Endzeit des Ereignisses EventEndTime	Der Timestamp, der angibt, wann eine Aktivität abgeschlossen wurde.
Beschreibung Die Endzeit des Ereignisses markiert den Abschluss einer Aktivität. In Event-Log-Daten wird die Endzeit einer Aktivität häufig als Startzeit der nächsten Aktivität in der Sequenz für den jeweiligen Case abgeleitet. Bei der letzten Aktivität eines Cases kann die Endzeit der Startzeit entsprechen. Dieses Attribut ist entscheidend für die Berechnung der Dauer einzelner Aktivitäten (ProcessingTime) und der Wartezeit zwischen Aktivitäten. Diese Informationen bilden die Grundlage für die Bottleneck-Analyse. So lässt sich nicht nur erkennen, wie lange ein Schritt dauert, sondern auch, wie lange der Case vor Beginn dieses Schritts inaktiv war. Warum das wichtig ist Ermöglicht die Berechnung von Aktivitätsdauern und Wartezeiten. Das ist eine wesentliche Grundlage für detaillierte Bottleneck-Analysen und die Identifikation von Prozessverzögerungen. Bezugsquelle Wird als Startzeit des nachfolgenden Ereignisses innerhalb desselben Cases berechnet. Die Endzeit des letzten Ereignisses kann seiner Startzeit oder der Abschlusszeit des Cases entsprechen. 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, beispielsweise „Email“, „Web“ oder „API“.
Beschreibung Dieses Attribut erfasst die Methode, mit der der Endbenutzer oder ein System das Incident-Ticket erstellt hat. Das Verständnis des Kanals ist wichtig, um die Quellen von Incidents zu analysieren und den Supportprozess entsprechend auszurichten. Die Analyse von Incidents nach Kanal kann unterschiedliche Muster sichtbar machen. Über das Telefon gemeldete Incidents können beispielsweise kürzere Lösungszeiten aufweisen als Incidents aus E-Mails. Diese Information unterstützt das Dashboard „Incident Throughput Volume“ und hilft bei der Ressourcenplanung sowie bei der Optimierung der Kanäle. Warum das wichtig ist Unterstützt die Analyse von Incident-Volumen und Prozessleistung nach Quelle. Dadurch werden kanalspezifische Prozessverbesserungen und eine passende Ressourcenverteilung möglich. Bezugsquelle Zendesk Tickets API, Feld via.channel. Beispiele WebE-MailAPITelefon
	Priorität TicketPriority	Die dem Incident zugewiesene Prioritätsstufe, beispielsweise „Low“, „Normal“, „High“ oder „Urgent“.
Beschreibung Die Priorität eines Incidents bestimmt die erforderliche Dringlichkeit für Reaktion und Lösung. Sie ist ein wichtiger Faktor für die Arbeitspriorisierung und Ressourcenverteilung im Supportteam. In der Prozessanalyse dient die Priorität dazu, Incidents zu segmentieren und ihre Prozessabläufe sowie ihre Leistung zu vergleichen. Analysten können beispielsweise prüfen, ob Incidents mit der Priorität „Urgent“ tatsächlich schneller gelöst werden als Incidents mit der Priorität „Low“. Außerdem wird sie zur Überwachung der SLA-Konformität verwendet, da SLAs häufig anhand von Prioritätsstufen definiert werden. Die KPI „Priority Change Rate“ basiert auf der Nachverfolgung von Änderungen dieses Felds. Warum das wichtig ist Dieses Attribut ist entscheidend für die Segmentierung der Analyse, die Bewertung der Priorisierung und die Überwachung der SLA-Konformität bei unterschiedlichen Dringlichkeitsstufen. Bezugsquelle Zendesk Tickets API, Feld priority. Änderungen werden in der Ticket Audits API protokolliert. Beispiele NiedrigNormalHochDringend
	SLA-Status SlaStatus	Der aktuelle Status des Service Level Agreement (SLA) für den Incident.
Beschreibung Dieses Attribut zeigt an, ob ein Incident seine definierten SLA-Ziele voraussichtlich erreicht, bereits gegen sie verstoßen hat oder ob die SLA-Timer pausiert sind. Zendesk erfasst SLA-Kennzahlen automatisch auf Grundlage der konfigurierten Richtlinien. Dieses Attribut ist für das Dashboard „SLA-Compliance-Monitoring“ besonders wichtig. Es misst direkt, wie die Leistung im Verhältnis zu den vereinbarten Serviceleistungen ausfällt. Durch die Analyse, wann und warum SLAs verletzt werden, können Unternehmen Schwachstellen im Prozess erkennen und die Zuverlässigkeit ihrer Services verbessern. Das Attribut unterstützt unmittelbar die KPI „Einhaltungsquote der Incident-SLAs“. Warum das wichtig ist Misst die Leistung im Verhältnis zu vereinbarten Serviceleistungen und ermöglicht die Analyse von SLA-Verletzungen sowie eine proaktive Überwachung zur Verbesserung der Compliance. Bezugsquelle Zendesk Ticket Metrics API (/api/v2/ticket_metrics.json), abgeleitet aus Feldern wie sla_policy, breached_at usw. Beispiele AktivPausiertVerletztErfüllt
	Ticketstatus TicketStatus	Der Status des Incident-Tickets zum Zeitpunkt des Ereignisses, beispielsweise „Open“, „Pending“ oder „Solved“.
Beschreibung Dieses Attribut zeigt den Zustand des Incident-Tickets an verschiedenen Punkten seines Lebenszyklus. Zu den Standardstatus in Zendesk gehören new, open, pending, on-hold, solved und closed. Die Nachverfolgung von Änderungen dieses Felds ist eine zentrale Methode, um Aktivitäten für Process Mining zu erzeugen. Die Analyse des Ticketstatus ist grundlegend für das Verständnis des Prozesses. Sie zeigt, wie viel Zeit Incidents in bestimmten Zuständen verbringen, beispielsweise in „Pending“, was häufig auf eine ausstehende Antwort des Kunden hinweist. Außerdem ist sie entscheidend für die Definition des Case-Abschlusses und die Berechnung der Lösungszeiten. Warum das wichtig ist Die Nachverfolgung von Statusänderungen ist entscheidend, um den Prozessfortschritt und Wartezeiten zu verstehen sowie Anfang und Ende des Incident-Lebenszyklus festzulegen. Bezugsquelle Zendesk Tickets API, Feld status. Änderungen werden in der Ticket Audits API protokolliert. Beispiele NeuOffenAusstehendGelöstGeschlossen
	Zugewiesene Gruppe AssignedGroup	Das Supportteam oder die Supportgruppe, das beziehungsweise die aktuell für den Incident zuständig ist.
Beschreibung Dieses Attribut zeigt, welches Team für den Incident verantwortlich ist. Incidents wechseln häufig zwischen verschiedenen Supportstufen oder spezialisierten Gruppen, beispielsweise von „L1 Support“ zum „Network Team“. Dies ist eine wichtige Dimension für die Analyse von Prozessübergaben und die Erkennung von Engpässen. Durch die Überwachung des Incident-Flusses zwischen Gruppen können Analysten Abhängigkeiten zwischen Teams messen, Wartezeiten in den Warteschlangen einzelner Teams berechnen und Routing-Regeln optimieren. Das unterstützt direkt das Dashboard „Handoffs and Rework Analysis“. Warum das wichtig ist Verfolgt die Teamverantwortung. Das ist entscheidend für die Analyse von Übergaben zwischen Teams, die Erkennung teamspezifischer Engpässe und die Messung von Wartezeiten in Warteschlangen. Bezugsquelle Zendesk Tickets API, Feld group_id. Änderungen werden in der Ticket Audits API protokolliert. Beispiele Support Stufe 1Netzwerkteam Stufe 2Infrastruktur Stufe 3Abrechnung
	Zugewiesener Agent Assignee	Der einzelne Supportagent, der aktuell für die Bearbeitung des Incidents zuständig ist.
Beschreibung Dieses Attribut identifiziert den Agent, der zu einem bestimmten Zeitpunkt für den Incident verantwortlich ist. Änderungen des zuständigen Agents sind wichtige Ereignisse, da sie eine Übergabe der Arbeit von einer Person an eine andere anzeigen. Die Analyse des zugewiesenen Agents hilft, die Verteilung der Arbeitslast, die individuelle Leistung und Muster der Zusammenarbeit zu verstehen. Die Nachverfolgung dieses Felds ist erforderlich, um die KPI „Average Handoffs per Incident“ zu berechnen und Situationen zu erkennen, in denen Incidents häufig weitergereicht werden. Dies kann auf Wissenslücken oder ineffizientes Routing hinweisen. Warum das wichtig ist Identifiziert den verantwortlichen Agent und ermöglicht die Analyse der Arbeitslast sowie die Nachverfolgung von Übergaben. Das ist entscheidend, um Ineffizienzen im Prozess zu erkennen. Bezugsquelle Zendesk Tickets API, Feld assignee_id. Änderungen werden in der Ticket Audits API protokolliert. Beispiele John SmithJane DoeService-Desk-Automatisierung
	Anzahl der Übergaben HandoffCount	Die Gesamtzahl der Fälle, in denen ein Incident einem anderen Agent oder einer anderen Gruppe neu zugewiesen wurde.
Beschreibung Diese berechnete Kennzahl 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 hinweisen. Diese Kennzahl bildet die Grundlage für die KPI „Durchschnittliche Übergaben pro Incident“ und ist für das Dashboard „Analyse von Übergaben und Nacharbeit“ entscheidend. Warum das wichtig ist Quantifiziert die durch Übergaben verursachte Reibung im Prozess und hilft, ineffizientes Routing sowie Wissenslücken zu erkennen, die Lösungszeiten verlängern. Bezugsquelle Berechnet durch Zählen der Änderungen im Feld AssignedGroup oder Assignee für einen Incident. Beispiele 0135
	Case-Dauer CaseDuration	Die gesamte Zeit vom Erstellen des Incidents bis zu seinem endgültigen Abschluss.
Beschreibung Diese berechnete Kennzahl beschreibt die End-to-End-Durchlaufzeit eines einzelnen Incidents. Sie wird als Differenz zwischen dem Timestamp des allerersten Ereignisses, zum Beispiel „Incident erstellt“, und dem des letzten Ereignisses, zum Beispiel „Incident geschlossen“, berechnet. Die Case-Dauer ist eine zentrale KPI für die Bewertung der gesamten Prozesseffizienz. Sie wird in Dashboards häufig verwendet, um durchschnittliche Durchlaufzeiten darzustellen, lang laufende Cases zu erkennen und Trends im Zeitverlauf zu analysieren. Damit lässt sich auf übergeordneter Ebene messen, wie schnell der Prozess Incidents bearbeitet und löst. Warum das wichtig ist Dies ist eine wichtige KPI zur Messung der gesamten Prozessgeschwindigkeit und zur Identifikation von Faktoren, die zu langen Lösungszeiten beitragen. Bezugsquelle Berechnet als Differenz zwischen dem Timestamp des letzten und des ersten Ereignisses für jede Incident-ID. Beispiele 25920060480086400
	Ist automatisiert IsAutomated	Ein boolesches Kennzeichen, das angibt, ob eine Aktivität von einem automatisierten System oder einem menschlichen Agent ausgeführt wurde.
Beschreibung Dieses abgeleitete Attribut unterscheidet zwischen Ereignissen, die von menschlichen Benutzern ausgeführt wurden, und solchen, die durch Systemautomatisierungen, Trigger oder API-Integrationen entstanden sind. Üblicherweise wird dafür geprüft, ob der Autor eines Ereignisses einem bekannten Systembenutzer entspricht. Das Verständnis des Automatisierungsgrads ist für moderne Prozessanalysen entscheidend. Es hilft, die Wirksamkeit von Automatisierungsregeln zu bewerten, manuelle Aufgaben mit Automatisierungspotenzial zu erkennen und den Einfluss der Automatisierung auf Effizienz und Lösungszeiten zu messen. Mit diesem Attribut können automatisierte und manuelle Aktivitäten anhand ihrer Prozessabläufe verglichen werden. Warum das wichtig ist Unterscheidet zwischen menschlichen und systemseitigen Aktionen. Das ist entscheidend, um den Einfluss der Automatisierung auf die Prozesseffizienz zu analysieren und neue Automatisierungsmöglichkeiten zu erkennen. Bezugsquelle Abgeleitet durch die Prüfung, ob der Ereignisautor (author_id in der Ticket Audits API) einem bekannten System- oder Automatisierungsbenutzer entspricht. Beispiele truefalse
	Kategorie der Grundursache RootCauseCategory	Die übergeordnete Kategorie der zugrunde liegenden Grundursache des Incidents.
Beschreibung Dieses Attribut klassifiziert den grundlegenden Grund für das Auftreten eines Incidents. Es wird üblicherweise gegen Ende des Incident-Lebenszyklus erfasst, häufig im Rahmen einer Nachbesprechung oder eines Problem-Management-Prozesses, und in einem benutzerdefinierten Feld gespeichert. Diese Daten sind für das Dashboard „Genauigkeit der Grundursachenidentifikation“ und die KPI „RCA-Abdeckung“ unverzichtbar. Die Analyse von Incidents nach Grundursache hilft, wiederkehrende Probleme zu erkennen. So können Unternehmen dauerhafte Lösungen umsetzen und das künftige Incident-Volumen reduzieren. Der Fokus verschiebt sich dadurch von der reaktiven Störungsbehebung zur proaktiven Problemvermeidung. Warum das wichtig ist Unterstützt ein proaktives Problem-Management, indem Incident-Ursachen kategorisiert werden. Dadurch lassen sich Trends erkennen und künftige Vorkommnisse vermeiden. Bezugsquelle Dies ist üblicherweise ein benutzerdefiniertes Ticketfeld. Prüfen Sie die Konfiguration der Ticketfelder im Zendesk Admin Center. Beispiele SoftwarefehlerHardwareausfallBenutzerfehlerNetzwerkausfall
	Kundenorganisation Organization	Die Organisation oder das Unternehmen, dem der Anfragende des Incidents angehört.
Beschreibung Dieses Attribut verknüpft einen Incident mit der Organisation des Kunden. Es ist für B2B-Supportumgebungen wichtig, in denen Service Level und Supportprozesse je nach Kunde unterschiedlich sein können. Durch die Analyse von Incidents nach Organisation können Supportteams die Kundensituation überwachen, wiederkehrende Probleme bei bestimmten Kunden erkennen und die Einhaltung vertraglicher Verpflichtungen sicherstellen. Das Attribut ist eine wichtige Dimension zum Filtern von Dashboards und Berichten und ermöglicht eine kundenorientierte Sicht auf die Leistung. Warum das wichtig ist Ermöglicht kundenspezifische Analysen, unterstützt die Überwachung von Service Leveln, die Erkennung von Trends bei wichtigen Kunden und ein wirksames Kundenbeziehungsmanagement. Bezugsquelle Zendesk Tickets API, Feld organization_id. Beispiele Global Tech Inc.Innovate SolutionsData Corp
	Meldende Person Submitter	Der Endbenutzer oder das System, von dem der Incident ursprünglich gemeldet wurde.
Beschreibung Dieses Attribut identifiziert die Person oder Einheit, die das Ticket erstellt hat. Es unterscheidet sich vom Anfragenden, da ein Agent ein Ticket im Namen einer anderen Person erstellen kann. In der Analyse zeigt die meldende Person, wer Probleme meldet. In Verbindung mit Organisationsdaten lässt sich erkennen, ob bestimmte Kunden oder Benutzergruppen besonders viele Incidents melden. Diese Erkenntnisse können proaktive Supportmaßnahmen oder Schulungen unterstützen. Warum das wichtig ist Identifiziert die Quelle der Incident-Meldung. So lassen sich Muster im Zusammenhang mit bestimmten Benutzern, Abteilungen oder automatisierten Systemen analysieren. Bezugsquelle Zendesk Tickets API, Feld submitter_id. Beispiele alice.jones@example.combob.williams@example.comSystemüberwachung
	Schweregrad Severity	Das Ausmaß der Auswirkungen des Incidents auf das Geschäft.
Beschreibung Der Schweregrad beschreibt die geschäftlichen Auswirkungen eines Incidents und wird häufig zusammen mit der Priorität verwendet, um die Gesamtdringlichkeit zu bestimmen. In Zendesk wird er üblicherweise als benutzerdefiniertes Feld konfiguriert. Die Analyse des Schweregrads hilft dabei, die Kritikalität der bearbeiteten Incidents zu verstehen. Er ist eine wichtige Dimension für die Segmentierung von Daten in Dashboards wie „SLA-Compliance-Monitoring“ und „Kennzahlen zur Priorisierungseffektivität“. Der Vergleich von Prozessabläufen für unterschiedliche Schweregrade kann zeigen, ob Incidents mit hohem Schweregrad mit der erforderlichen Geschwindigkeit und den passenden Ressourcen bearbeitet werden. Warum das wichtig ist Zeigt die geschäftlichen Auswirkungen eines Incidents an. Dadurch lassen sich besonders kritische Probleme gezielt analysieren und effizient lösen. Bezugsquelle Dies ist üblicherweise ein benutzerdefiniertes Feld. Prüfen Sie die Konfiguration der Ticketfelder im Zendesk Admin Center. Beispiele 1 - Kritisch2 - Hoch3 - Mittel4 - Niedrig
	Tags Tags	Eine Liste der Tags, die dem Incident zur Kategorisierung und Kontextualisierung zugewiesen wurden.
Beschreibung Tags sind flexible Bezeichnungen, die Tickets zusätzlichen Kontext geben oder bei Kategorisierung und Routing unterstützen. Agents können sie manuell hinzufügen, oder sie werden automatisch durch Trigger und Automatisierungen vergeben. Tags sind eine umfangreiche Datenquelle für Process-Mining-Analysen. Sie ermöglichen eine detaillierte Segmentierung, etwa durch Filterung nach Incidents im Zusammenhang mit einem bestimmten Produktlaunch („launch_q4“) oder einem bekannten Ausfall („outage_20231027“). Diese Flexibilität erlaubt eingehende Untersuchungen, die über Standard-Ticketfelder hinausgehen. Warum das wichtig ist Bietet eine flexible Möglichkeit, Incidents zu kategorisieren und zu filtern. Dadurch werden detaillierte, kontextspezifische Analysen möglich, die mit Standardfeldern allein möglicherweise nicht durchführbar wären. Bezugsquelle Zendesk Tickets API, Feld tags. Beispiele VIP-BenutzerNetzwerkproblemAusfall_20231027Abrechnungsbezogen
	Ticket-Typ TicketType	Die Klassifizierung des Tickets, zum Beispiel „Incident“, „Problem“, „Frage“ oder „Task“.
Beschreibung Dieses Feld kategorisiert das Ticket anhand der Art der Anfrage. Der Incident-Management-Prozess konzentriert sich speziell auf Tickets mit dem Typ „Incident“. Dabei handelt es sich um eine ungeplante Unterbrechung oder Beeinträchtigung der Qualität eines IT-Services. In der Analyse wird dieses Attribut hauptsächlich als Filter verwendet, damit in der Prozessansicht nur Incidents berücksichtigt werden. Es eignet sich außerdem für umfassendere ITSM-Analysen, etwa zum Vergleich der Prozesse für die Bearbeitung von Incidents, Problemen und Serviceanfragen. Warum das wichtig ist Ermöglicht die Filterung der Daten auf Incidents und stellt sicher, dass die Prozessanalyse den Lebenszyklus des Incident-Managements abbildet. Bezugsquelle Zendesk Tickets API, Feldtyp. Beispiele IncidentProblemFrageAufgabe
	Wird beim Erstkontakt gelöst IsFirstContactResolution	Ein boolesches Kennzeichen, das wahr ist, wenn der Incident ohne Übergaben durch den zuerst zugewiesenen Agent oder die zuerst zugewiesene Gruppe gelöst wurde.
Beschreibung First Contact Resolution (FCR) ist eine wichtige Kennzahl für die Effizienz von Support-Centern und die Kundenzufriedenheit. Dieses berechnete Attribut kennzeichnet Incidents, die gelöst wurden, ohne einem anderen Agent oder Team neu zugewiesen zu werden. Die Logik prüft üblicherweise, ob das Ticket den Status „Gelöst“ erreicht hat und weiterhin dem ursprünglichen Agent und der ursprünglichen Gruppe zugewiesen war. Im Process Mining ermöglicht dies die direkte Berechnung der FCR-Quote sowie den Vergleich der Prozesspfade von FCR-Incidents mit Fällen, die eine Eskalation erforderten. So lassen sich Möglichkeiten erkennen, Lösungen früher im Prozess herbeizuführen. Warum das wichtig ist Misst direkt die Effizienz des ersten Support-Kontakts und hilft, Möglichkeiten für eine frühere Lösung im Prozess zu erkennen. Bezugsquelle Berechnetes boolesches Kennzeichen. Wahr, wenn der Ticketstatus „gelöst“ oder „geschlossen“ lautet und dem Incident während seines gesamten Lebenszyklus nur ein eindeutiger Bearbeiter oder eine eindeutige zugewiesene Gruppe zugeordnet war. Beispiele truefalse
	Zufriedenheitsbewertung SatisfactionRating	Die Zufriedenheitsbewertung, die der Endnutzer nach der Lösung des Incidents abgibt.
Beschreibung Dieses Attribut erfasst das Feedback des Kunden zu seiner Support-Erfahrung. Die Erhebung erfolgt üblicherweise über eine Umfrage, nachdem das Ticket gelöst wurde. In Zendesk sind „Gut“ und „Schlecht“ gängige Bewertungen. Zufriedenheitsbewertungen messen die Prozesseffizienz zwar nicht direkt, liefern aber eine wichtige Ergebniskennzahl. Im Process Mining können sie mit Prozessvarianten korreliert werden, um zu verstehen, welche Lösungswege zu einer höheren Kundenzufriedenheit führen. Erhalten Incidents mit mehr Übergaben beispielsweise schlechtere Bewertungen? Warum das wichtig ist Liefert eine wichtige Ergebniskennzahl, die mit Prozesseigenschaften korreliert werden kann, um den Einfluss der Prozessleistung auf die Nutzerzufriedenheit zu verstehen. Bezugsquelle Zendesk Ticket Metrics API (/api/v2/ticket_metrics.json), Feld satisfaction_rating.score. Beispiele GutSchlechtAngebotenNicht angeboten

Erforderlich Empfohlen Optional

Aktivitäten des Incident Managements

Dies sind die kritischen Prozessschritte und Meilensteine, die Sie für eine präzise Erkennung und Analyse in Ihrem Event Log erfassen sollten.

6 Empfohlen 7 Optional

	Aktivität	Beschreibung
	Incident erstellt	Markiert den Beginn des Incident-Lebenszyklus, sobald ein neues Ticket in Zendesk erstellt wird. Dieses Ereignis wird ausdrücklich im Audit Log zur Ticketerstellung von Zendesk erfasst und bildet den Ausgangspunkt für jeden Case.
Warum das wichtig ist Dies ist die zentrale Startaktivität. Die Zeit von diesem Ereignis bis zu anderen Aktivitäten ist entscheidend, um die Gesamtdauer des Ticket-Lebenszyklus und die anfängliche Reaktionszeit zu messen. Bezugsquelle Dieses Ereignis wird ausdrücklich in den Audit Logs des Zendesk-Tickets erfasst. Für jedes neue Ticket wird ein „Create“-Ereignis mit dem zugehörigen Timestamp erzeugt. Erfassen Direkt aus dem Ereignis zur Ticketerstellung im Audit Log. Ereignistyp explicit
	Incident gelöst	Dieser wichtige Meilenstein tritt ein, wenn ein Agent eine Lösung umgesetzt und das Ticket als „solved“ markiert hat. Die ausdrückliche Aktion wird als Statusänderung im Audit Log des Tickets erfasst.
Warum das wichtig ist Dies ist die zentrale Lösungsaktivität und ein wichtiger Zeitpunkt für die Messung der Lösungszeit. Die Zeit zwischen diesem Ereignis und „Incident geschlossen“ entspricht der Wartezeit auf die Bestätigung durch den Benutzer oder bis zum automatischen Abschluss. Bezugsquelle Wird aus dem Audit Log des Tickets über ein „Change“-Ereignis erfasst, bei dem der neue Wert des Felds „status“ „solved“ ist. Erfassen Erkannt durch ein „Change“-Ereignis für das Feld „status“ mit dem Wert „solved“. Ereignistyp explicit
	Incident geschlossen	Markiert das endgültige Ende des Incident-Lebenszyklus, sobald das Ticket dauerhaft geschlossen wird. In Zendesk geschieht dies häufig automatisch nach einem festgelegten Zeitraum ab der Lösung und wird als abschließende Statusänderung erfasst.
Warum das wichtig ist Dies ist die definitive Endaktivität des Prozesses. Die Gesamtdauer wird von „Incident erstellt“ bis zu diesem Ereignis berechnet und bietet eine End-to-End-Sicht auf die Durchlaufzeit. Bezugsquelle Wird aus dem Audit Log des Tickets über ein „Change“-Ereignis erfasst, bei dem der neue Wert des Felds „status“ „closed“ ist. Erfassen Erkannt durch ein „Change“-Ereignis für das Feld „status“ mit dem Wert „closed“. Ereignistyp explicit
	Status auf Open geändert	Zeigt an, dass ein Agent mit der aktiven Bearbeitung des Incidents begonnen hat. Diese Aktivität wird in der Regel aus einer Änderung des Ticketfelds „status“ von „new“ zu „open“ abgeleitet und markiert den Beginn der Untersuchung und Diagnose.
Warum das wichtig ist Dieses Ereignis markiert den Übergang von der Warteschlange zur aktiven Bearbeitung. Die Zeit, die Tickets im Status „new“ verbringen, bevor sie zu „open“ wechseln, ist eine wichtige Kennzahl für die anfängliche Reaktionszeit. Bezugsquelle Aus dem Audit Log des Tickets abgeleitet, indem ein „Change“-Ereignis erkannt wird, bei dem der neue Wert des Felds „status“ „open“ und der vorherige Wert „new“ ist. Erfassen Abgeleitet aus einer Änderung des Statusfelds von „new“ zu „open“. Ereignistyp inferred
	Ticket einem Agent zugewiesen	Diese Aktivität tritt auf, wenn ein Ticket einem bestimmten Agent zur Bearbeitung zugewiesen wird. Das ausdrückliche Ereignis wird in der Audit-Historie des Tickets protokolliert und zeigt, dass eine Person die Verantwortung übernommen hat.
Warum das wichtig ist Dieser Meilenstein ist entscheidend, um die Zeit bis zur ersten Zuweisung zu messen. Er bildet außerdem die Grundlage für die Analyse von Übergaben, wiederholter Bearbeitung und der Lösungsquote beim Erstkontakt. Bezugsquelle Wird aus dem Audit Log des Tickets erfasst, wenn das Feld „assignee_id“ befüllt oder geändert wird. Die erste Zuweisung ist ein wichtiger Meilenstein für die KPI-Berechnung. Erfassen Erkannt durch ein „Change“-Ereignis für das Feld „assignee_id“ im Audit Log des Tickets. Ereignistyp explicit
	Ticket neu zugewiesen	Tritt auf, wenn die Verantwortung für ein Ticket nach der ersten Zuweisung von einem Agent oder einer Gruppe auf einen anderen Agent oder eine andere Gruppe übertragen wird. Dieses ausdrückliche Ereignis wird in der Audit-Historie des Tickets erfasst.
Warum das wichtig ist Neuzuweisungen sind für die Analyse von Übergaben und wiederholter Bearbeitung entscheidend. Eine hohe Häufigkeit weist häufig auf ein fehlerhaftes erstes Routing, komplexe Probleme oder Engpässe im Prozess hin. Bezugsquelle Wird aus dem Audit Log des Tickets abgeleitet, indem ein „Change“-Ereignis für das Feld „assignee_id“ oder „group_id“ erkannt wird, nachdem das Feld erstmals befüllt wurde. Erfassen Erkannt durch ein nachfolgendes „Change“-Ereignis für das Feld „assignee_id“ oder „group_id“. Ereignistyp explicit
	Benutzerzufriedenheit bewertet	Bezeichnet den Zeitpunkt, an dem der Endbenutzer eine Bewertung für den erhaltenen Support abgibt. Dies ist ein ausdrückliches Ereignis, das Zendesk nach der Lösung eines Tickets erfasst.
Warum das wichtig ist Die Analyse von Zufriedenheitsbewertungen liefert wichtige Rückmeldungen zur Leistung von Agents und zur Wirksamkeit des Prozesses. Sie verknüpft Prozesskennzahlen mit Ergebnissen für Kunden. Bezugsquelle Wird aus den mit dem Ticket verknüpften Zufriedenheitsdaten erfasst. Diese enthalten in der Regel eine Bewertung, „good“ oder „bad“, sowie einen optionalen Kommentar. Erfassen Protokolliertes Ereignis, sobald eine Zufriedenheitsbewertung für das Ticket abgegeben wird. Ereignistyp explicit
	Interne Notiz hinzugefügt	Diese Aktivität steht für die interne Zusammenarbeit. Ein Agent fügt dem Ticket eine private Notiz für andere Teammitglieder hinzu. Das Ereignis wird ausdrücklich erfasst, wenn ein Kommentar als nicht öffentlich gekennzeichnet ist.
Warum das wichtig ist Die Analyse interner Notizen kann Erkenntnisse zu komplexen Problemen liefern, die Zusammenarbeit erfordern. Eine übermäßig hohe Anzahl kann jedoch auf Wissenslücken oder Ineffizienzen im Prozess hinweisen. Bezugsquelle Wird aus den Kommentardaten des Tickets erfasst. Ein Kommentar gilt als interne Notiz, wenn sein Attribut „public“ den Wert false hat. Erfassen Protokolliertes Ereignis, sobald dem Ticket ein neuer Kommentar mit „public: false“ hinzugefügt wird. Ereignistyp explicit
	Öffentliche Antwort gesendet	Bezeichnet eine Mitteilung, die ein Supportagent an den Endbenutzer sendet. Dies ist ein ausdrückliches Ereignis in Zendesk und wird erfasst, sobald ein öffentlicher Kommentar zum Ticket hinzugefügt wird.
Warum das wichtig ist Die Nachverfolgung öffentlicher Antworten ist wichtig, um die Kommunikationshäufigkeit zu verstehen. Sie kann außerdem ein zentraler Bestandteil der Zeitleiste sein, wenn Verzögerungen bei der Bestätigung durch Benutzer analysiert werden. Bezugsquelle Wird aus den Kommentardaten des Tickets erfasst. Ein Kommentar gilt als öffentlich, wenn sein Attribut „public“ den Wert true hat. Erfassen Protokolliertes Ereignis, sobald dem Ticket ein neuer Kommentar mit „public: true“ hinzugefügt wird. Ereignistyp explicit
	Priorität festgelegt	Die Prioritätsstufe eines Incidents, beispielsweise Low, Normal, High oder Urgent, wird festgelegt. Dies wird als ausdrückliches Änderungsereignis erfasst und bestimmt die Dringlichkeit sowie die erforderliche Reaktionszeit für das Ticket.
Warum das wichtig ist Die Nachverfolgung, wann und wie eine Priorität festgelegt wird, ist für das Dashboard „Prioritization Effectiveness Metrics“ entscheidend. So stellen Sie sicher, dass kritische Probleme zeitnah bearbeitet werden. Bezugsquelle Wird aus einem „Change“-Ereignis für das Feld „priority“ im Audit Log des Tickets erfasst. Nachfolgende Änderungen können ebenfalls verfolgt werden, um die KPI „Priority Change Rate“ zu messen. Erfassen Erkannt durch ein „Change“-Ereignis für das Feld „priority“ im Audit Log des Tickets. Ereignistyp explicit
	SLA-Ziel verfehlt	Markiert den Zeitpunkt, an dem ein Ticket ein definiertes Service Level Agreement nicht erfüllt, beispielsweise bei der Zeit bis zur ersten Antwort oder bis zur Lösung. Das Ereignis wird anhand der SLA-Richtliniendefinitionen und der Timestamps von Ticketaktualisierungen berechnet.
Warum das wichtig ist Dieses Ereignis unterstützt direkt die Überwachung der SLA-Konformität. Zu erkennen, wann und warum Verletzungen auftreten, ist grundlegend für eine zuverlässigere Servicequalität und das Vertrauen der Kunden. Bezugsquelle Dies ist ein berechnetes Ereignis. Es kann aus den mit einem Ticket verknüpften Daten „sla_policy_metrics“ abgeleitet werden, wobei für jedes SLA-Ziel der Timestamp „breached_at“ verwendet wird. Erfassen Abgeleitet aus dem Timestamp „breached_at“ in den SLA-Messdaten des Tickets. Ereignistyp calculated
	Status auf Pending geändert	Zeigt an, dass der Prozess pausiert, während auf eine Antwort des Anfragenden gewartet wird. Das Ereignis wird aus einer Änderung des Ticketfelds „status“ zu „pending“ abgeleitet.
Warum das wichtig ist Diese Aktivität ist entscheidend für die Berechnung der Wartezeit auf die Bestätigung durch den Benutzer. Lange Zeiträume in diesem Status können die gesamte Lösungszeit deutlich verlängern und auf Verzögerungen in der Kommunikation hinweisen. Bezugsquelle Aus dem Audit Log des Tickets abgeleitet, indem ein „Change“-Ereignis erkannt wird, bei dem der neue Wert des Felds „status“ „pending“ ist. Erfassen Abgeleitet aus einer Änderung des Statusfelds zu „pending“. Ereignistyp inferred
	Ticket einer Gruppe zugewiesen	Bezeichnet das erste Routing oder die Triage eines Incidents an eine bestimmte Supportgruppe. Dies ist in der Regel der erste Schritt zur Übernahme der Verantwortung und wird als ausdrückliches Änderungsereignis in der Audit-Historie des Tickets erfasst.
Warum das wichtig ist Die Nachverfolgung von Gruppenzuweisungen hilft, die Effizienz der ersten Triage zu analysieren und Verzögerungen zu erkennen, bevor ein Ticket an das zuständige Team weitergeleitet wird. Bezugsquelle Wird aus dem Audit Log des Tickets erfasst, sobald das Feld „group_id“ gesetzt oder geändert wird. Das erste derartige Änderungsereignis nach der Erstellung gilt als erste Zuweisung. Erfassen Erkannt durch ein „Change“-Ereignis für das Feld „group_id“ im Audit Log des Tickets. Ereignistyp explicit

Anleitungen zur Datenextraktion

So beziehen Sie Ihre Daten aus Zendesk Support

Schritte

Zendesk Explore öffnen: Melden Sie sich mit einem Benutzerkonto bei Ihrer Zendesk-Support-Instanz an, das über die erforderlichen Berechtigungen zum Erstellen und Verwalten von Berichten in Zendesk Explore verfügt.
Neuen Bericht erstellen: Öffnen Sie das Explore-Modul. Klicken Sie in der linken Navigationsleiste auf das Symbol „Reports“ und anschließend auf die Schaltfläche „New report“.
Datensatz auswählen: Wählen Sie im Fenster „Choose a dataset“ den Datensatz „Support: Ticket updates [default]“ aus. Dieser Datensatz enthält den Prüfpfad für jede Ticketänderung und ist daher für die Erstellung eines Event Logs erforderlich.
Erste Attribute (Spalten) hinzufügen: Öffnen Sie im Berichtseditor den Bereich „Rows“. Klicken Sie auf „Add“ und wählen Sie die folgenden Attribute aus. Sie bilden die Spalten Ihres Event Logs: Ticket ID, Update - Timestamp, Ticket status, Assignee name, Ticket group, Ticket priority, Ticket channel, Changes - Field name, Changes - Previous value, Changes - New value, Comment public.
Berechnete Attribute erstellen: Dies ist der wichtigste Schritt. Öffnen Sie das Menü „Calculations“ (Symbol mit dem Becherglas) und wählen Sie „Standard calculated attribute“. Erstellen Sie die drei im Abschnitt „Query“ definierten Attribute: ActivityName, SourceSystem und LastDataUpdate. Kopieren Sie die bereitgestellten Formeln exakt.
Berichtsspalten verfeinern: Fügen Sie die neu erstellten berechneten Attribute (ActivityName, SourceSystem, LastDataUpdate) zum Bereich „Rows“ hinzu. Anschließend können Sie die Rohfelder entfernen, die zur Erstellung von ActivityName verwendet wurden (Changes - Field name, Changes - Previous value, Changes - New value, Comment public), um die Ansicht zu bereinigen.
Berichtsfilter hinzufügen: Öffnen Sie den Bereich „Filters“ und klicken Sie auf „Add“. Fügen Sie einen Filter für Update - Date hinzu und wählen Sie einen passenden Zeitraum aus, zum Beispiel die letzten drei Monate. Fügen Sie außerdem einen Filter für das berechnete Attribut ActivityName hinzu und schließen Sie Nullwerte aus. Dadurch entfernen Sie Ticketaktualisierungen, die keiner gewünschten Aktivität entsprechen.
Bericht ausführen und prüfen: Zendesk Explore aktualisiert den Bericht automatisch, sobald Sie Attribute und Filter hinzufügen. Prüfen Sie die Datentabelle, um sicherzustellen, dass Zeilen und Spalten wie erwartet angezeigt werden. Der Bericht sollte eine Zeile pro Event enthalten.
Daten als CSV exportieren: Klicken Sie nach Abschluss des Berichts oben rechts auf „Export“ und wählen Sie „CSV“. Zendesk erstellt die CSV-Datei und lädt sie herunter.
Upload vorbereiten: Öffnen Sie die exportierte CSV-Datei. Benennen Sie die Spaltenüberschriften so um, dass sie den erforderlichen Attributnamen Ihres Process-Mining-Tools entsprechen, zum Beispiel „Ticket ID“ in TicketId und „Update - Timestamp“ in EventTimestamp. Stellen Sie sicher, dass das Datumsformat der Timestamps ISO-8601-konform ist. Die Datei ist nun für den Upload bereit.

Konfiguration

Zendesk-Datensatz: Der Bericht muss auf dem Datensatz „Support: Ticket updates [default]“ basieren. Nur dieser Standarddatensatz stellt den detaillierten Prüfpfad bereit, der für die Rekonstruktion des Prozesses Event für Event erforderlich ist.
Filter für den Zeitraum: Begrenzen Sie das Datenvolumen unbedingt mit einem Datumsfilter. Verwenden Sie das Attribut Update - Date als primären Filter. Für eine erste Analyse empfiehlt sich in der Regel ein Zeitraum von drei bis sechs Monaten.
Aktivitätsfilter: Nachdem Sie das berechnete Attribut ActivityName erstellt haben, müssen Sie den Bericht so filtern, dass Zeilen mit einem Nullwert ausgeschlossen werden. Dadurch entfernen Sie irrelevante Ticketänderungen, etwa Systemaktualisierungen oder Tag-Änderungen, aus Ihrem Event Log.
Berechnete Attribute: Die Extraktion stützt sich maßgeblich auf ein berechnetes Standardattribut, das rohe Ticketfeldänderungen in verständliche Aktivitätsnamen überführt. Die Formel muss exakt sein.
Voraussetzungen: Der Benutzer, der den Bericht ausführt, benötigt mindestens die Rolle „Viewer“ in Zendesk Explore. Zum Erstellen und Speichern des Berichts sind Berechtigungen als „Editor“ oder „Admin“ 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

Voraussetzungen: Stellen Sie sicher, dass Python 3.6 oder höher sowie die Bibliotheken requests und pandas auf Ihrem System installiert sind. Installieren Sie sie bei Bedarf mit pip: pip install requests pandas.
Zendesk-API-Token erstellen: Melden Sie sich als Administrator bei Ihrer Zendesk-Support-Instanz an. Öffnen Sie Admin Center > Apps and integrations > APIs > Zendesk APIs. Fügen Sie im Bereich „API Tokens“ ein neues aktives API-Token hinzu und speichern Sie die generierte Token-Zeichenfolge sicher.
Python-Skript konfigurieren: Erstellen Sie eine neue Python-Datei, zum Beispiel 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 Zugangsdaten. Legen Sie mit START_TIMESTAMP den Beginn des gewünschten Extraktionszeitraums fest, und zwar als Unix-Epoch-Timestamp.
API-Endpunkte verstehen: Das Skript verwendet hauptsächlich zwei Zendesk-API-Endpunkte. Der Endpunkt incremental/tickets/cursor.json ruft effizient alle Tickets ab, die seit START_TIMESTAMP aktualisiert wurden. Für jedes Ticket ruft das Skript anschließend den Endpunkt tickets/{ticket_id}/audits.json auf, um eine detaillierte Historie aller Änderungen und Events abzurufen.
Skript ausführen: Starten Sie das Skript in Ihrem Terminal mit dem Befehl: python extract_zendesk_logs.py. Das Skript beginnt daraufhin mit dem Abruf der Daten aus der Zendesk-API.
Skriptfortschritt überwachen: Das Skript gibt die Anzahl der verarbeiteten Tickets in der Konsole aus. So können Sie den Fortschritt verfolgen. Je nach Zeitraum und Ticketvolumen kann der Vorgang längere Zeit dauern.
Datenabruf und Seitennavigation: Das Skript verarbeitet die API-Seitennavigation automatisch. Es beginnt mit der URL für den ersten Ticket-Export und folgt der in jeder API-Antwort bereitgestellten after_url, bis alle Tickets des Zeitraums abgerufen wurden.
Events umwandeln: Für jedes Ticket durchläuft das Skript die Audit-Historie. Es analysiert jedes Audit-Event und ordnet die internen Zendesk-Eventtypen wie Create, Change und Comment den erforderlichen Geschäftsaktivitäten zu, etwa Incident Created, Status Changed to Open und Public Reply Sent.
SLA-Daten verarbeiten: Das Skript enthält die spezielle Funktion get_sla_breach_events, um SLA-Kennzahlen für jedes gelöste Ticket abzurufen. Dies ist erforderlich, weil SLA-Verletzungen keine Standard-Events im Audit Log sind. Die Funktion führt einen zusätzlichen API-Aufruf aus, um Details zur Anwendung der SLA-Richtlinie abzurufen.
Event Log erstellen: Sobald alle Tickets verarbeitet wurden, fasst das Skript die extrahierten Events in einem pandas DataFrame zusammen und speichert das fertige Event Log als CSV-Datei mit dem Namen zendesk_incident_event_log.csv im Verzeichnis, in dem das Skript ausgeführt wurde.
Upload vorbereiten: Prüfen Sie die erzeugte CSV-Datei auf Vollständigkeit und Richtigkeit. Die Datei liegt nun im erforderlichen Format vor und kann direkt zur Analyse in ProcessMind hochgeladen werden.

Konfiguration

Zendesk-API-Zugangsdaten: Sie müssen Ihre Zendesk-Subdomain, die E-Mail-Adresse eines Administrator- oder Agentenkontos sowie ein gültiges API-Token angeben. Speichern Sie diese Zugangsdaten sicher und hinterlegen Sie sie in Produktionsskripten, die versioniert werden, nicht fest im Quelltext.
Start-Timestamp (START_TIMESTAMP): Dieser ganzzahlige Wert bestimmt den Beginn der Datenextraktion. Er muss als Unix-Epoch-Timestamp angegeben werden. Als Startpunkt empfiehlt sich ein Zeitpunkt drei bis sechs Monate in der Vergangenheit, damit Sie eine aussagekräftige Datenmenge erfassen, ohne das System zu überlasten. Für ein bestimmtes Datum können Sie einen Online-Konverter verwenden.
API-Ratenbegrenzung: Das Skript führt zahlreiche API-Aufrufe aus. Zendesk setzt Ratenbegrenzungen fest, die je nach Tarif variieren. Für moderate Datenmengen ist das Skript geeignet. Bei sehr großen Instanzen müssen Sie möglicherweise innerhalb der Schleifen time.sleep()-Aufrufe ergänzen, um die Ratenbegrenzung und einen 429-Fehler zu vermeiden.
Erforderliche Python-Bibliotheken: Das Skript verwendet die Bibliothek requests für API-Aufrufe sowie pandas für die Datenverarbeitung und den CSV-Export. Stellen Sie sicher, dass beide Bibliotheken in Ihrer Python-Umgebung installiert sind.
Benutzerberechtigungen: Das mit dem API-Token verknüpfte Benutzerkonto muss über ausreichende Berechtigungen zum Lesen von Ticketdaten verfügen, einschließlich Audits und Ticketkennzahlen.

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

Erstellen Sie einen Zendesk-API-Client mit Berechtigungen zum Lesen von Tickets, Ticket-Audits, Benutzern, Gruppen, Zufriedenheitsbewertungen und inkrementellen Exporten. Verwenden Sie ein API-Token oder eine für Ihre Zendesk-Support-Instanz konfigurierte OAuth-Anmeldedaten. Speichern Sie Subdomain, Zugangsdaten und Extraktions-Watermark als sichere Konfigurationswerte.
Verwenden Sie die Zendesk Incremental Ticket Export API, um Tickets abzurufen, die nach dem letzten erfolgreichen Watermark aktualisiert wurden. Das folgende Skript verwendet das dokumentierte Endpunktmuster https://[Your Zendesk subdomain].zendesk.com/api/v2/incremental/tickets/cursor.json und folgt der Cursor-Seitennavigation, bis die API meldet, dass die Ergebnismenge vollständig ist.
Rufen Sie für jedes zurückgegebene Ticket die Audit-Historie über den Ticket-Audit-Endpunkt ab. Audit-Datensätze sind erforderlich, weil ProcessMind das Event Log unverändert einliest und Aktivitäten nicht aus dem finalen Ticketstatus ableitet. Bewahren Sie Audit-Timestamp, Akteur, Ticketkennung und Audit-Events auf.
Wandeln Sie Audit-Events in explizite Event-Zeilen um. Extrahieren Sie Ticketerstellung, Gruppenzuweisung, Agentenzuweisung, Prioritätsänderungen, Statusänderungen zu open, öffentliche Antworten, interne Notizen, Neuzuweisungen, Statusänderungen zu pending, den Status solved und den Status closed. Erfassen Sie Zufriedenheitsbewertungen als separate Zeilen, wenn eine Bewertung vorliegt. Berechnen Sie SLA-Verletzungen nur, wenn das erforderliche SLA-Ziel und die benötigten Event-Timestamps verfügbar sind, und dokumentieren Sie die Eingabewerte der Berechnung.
Speichern Sie den zuletzt erfolgreich verarbeiteten Update-Timestamp oder Cursor. Aktualisieren Sie das Watermark erst, wenn alle Seiten, Ticket-Audits und optionalen Zufriedenheitsdatensätze erfolgreich geschrieben wurden. Verwenden Sie beim ersten Lauf einen begrenzten Startzeitpunkt wie [Start date in ISO 8601 format], der normalerweise drei bis sechs Monate abdeckt.
Befüllen Sie die erforderlichen Spalten TicketId, ActivityName, EventTimestamp, SourceSystem und LastDataUpdate. Ergänzen Sie die empfohlenen Spalten TicketStatus, Assignee, AssignedGroup, TicketPriority, Channel, SlaStatus und EventEndTime, sofern die Quelldaten dies ermöglichen. Verwenden Sie leere Werte nur, wenn Zendesk das Attribut für das jeweilige Event nicht bereitstellt.
Entfernen Sie Duplikate anhand von TicketId, ActivityName, EventTimestamp und, sofern vorhanden, einer stabilen Quell-Eventkennung. Bewahren Sie mehrere legitime Vorkommen derselben Aktivität auf, etwa mehrere öffentliche Antworten, interne Notizen, Zuweisungen oder Statusänderungen.
Schreiben Sie die resultierenden Zeilen in eine CSV-Datei oder ein anderes von ProcessMind unterstütztes Event-Log-Format. Stellen Sie sicher, dass Timestamps ISO 8601 mit explizitem UTC-Offset entsprechen, TicketId einheitlich typisiert ist, ActivityName exakt den dokumentierten Aktivitätsnamen entspricht und LastDataUpdate für alle Zeilen desselben Extraktionslaufs identisch ist.
Laden Sie das Event Log in ProcessMind hoch und konfigurieren Sie Incident ID als Case-ID, Activity als Aktivitätsspalte und Event Timestamp als Spalte für die Event-Zeit. Prüfen Sie, ob jede erforderliche Aktivität durch explizite Zeilen vertreten ist, statt erst bei der Visualisierung abgeleitet zu werden.

Konfiguration

API-Methode: Zendesk Incremental Ticket Export API mit Cursor-Seitennavigation. Verwenden Sie den Ticket-Audit-Endpunkt für die Extraktion auf Event-Ebene und den Zufriedenheits-Endpunkt, wenn Zufriedenheitsbewertungen aktiviert und zugänglich sind.
Erforderliche Konfiguration: Zendesk-Subdomain, API-Authentifizierung, initiales Startdatum, Extraktions-Watermark, Request-Timeout, Wiederholungsrichtlinie und Ausgabeort. Ersetzen Sie [Your Zendesk subdomain], [Your API email] und [Your API token] durch sichere Bereitstellungswerte.
Zeitraum: Verwenden Sie für einen ersten Ladevorgang drei bis sechs Monate, sofern keine längere Historie erforderlich ist. Fordern Sie bei wiederkehrenden Ladevorgängen Datensätze nach dem letzten erfolgreichen Watermark an und berücksichtigen Sie ein kleines Überlappungsfenster, um verspätet eintreffende Aktualisierungen abzudecken. Entfernen Sie anschließend Duplikate.
Filter: Wenden Sie Filter für Unternehmen, Marke, Gruppe, Organisation, Ticketformular, Kanal oder benutzerdefinierte Felder nur an, wenn sie für den Prozessumfang ausdrücklich erforderlich sind. Zendesk Support verwendet keine SAP-typischen Filter wie Company Code oder Document Type, sofern diese Konzepte nicht durch konfigurierte Zendesk-Felder abgebildet werden.
Event-Semantik: Behandeln Sie Audit-Events als maßgebliche Quelle für explizite Änderungen. Erstellen Sie kein Statusänderungs-Event allein deshalb, weil der aktuelle Ticketstatus einen Wert enthält. Ein Status-Event muss aus einem Audit-Event oder einer anderen dokumentierten Quell-Event stammen.
SLA-Konfiguration: Für SLA Target Breached benötigen Sie Zugriff auf die geltende SLA-Richtlinie, die Zieldauer, den Kalender der Geschäftszeiten und die für die Bewertung erforderlichen Timestamps. Wenn Zendesk ein Verletzungs-Event oder eine entsprechende Kennzahl bereitstellt, verwenden Sie diese Quelle. Andernfalls berechnen Sie die Verletzung nur anhand dokumentierter Richtliniendaten und halten Sie die Berechnungsgrundlage fest.
Konfiguration der Zufriedenheitsbewertung: User Satisfaction Rated setzt voraus, dass Zufriedenheitsbewertungen aktiviert und die Bewertungsdatensätze über die API zugänglich sind. Ein gelöstes Ticket ohne Bewertung darf kein künstliches Bewertungs-Event erhalten.
Leistung: Verwenden Sie Cursor-Seitennavigation, eine begrenzte Parallelisierung für Ticket-Audit-Anfragen, wiederverwendete Verbindungen, exponentielles Backoff bei Ratenbegrenzungen und Checkpoints nach erfolgreichen Batches. Vermeiden Sie es, bei jedem Lauf alle Ticket-Audits erneut abzurufen.
Vollständigkeit: Inkrementelle Exporte können Tickets enthalten, die nach dem angeforderten Zeitpunkt aktualisiert wurden. Der Abruf von Audits und verspätete Aktualisierungen müssen jedoch separat behandelt werden. Verwenden Sie ein Überlappungsfenster und stabile Schlüssel zur Duplikaterkennung.
Voraussetzungen: API-Zugriff, Berechtigungen zum Lesen von Tickets und Audits, Zugriff auf Benutzer und Gruppen zur Namensauflösung, Zugriff auf Zufriedenheitsdaten bei Bedarf sowie Zugriff auf SLA-Daten, wenn eine Verletzungsberechnung erforderlich ist. Welche Audit-Eventtypen verfügbar sind, kann je nach Zendesk-Konfiguration und Abonnement variieren.

a Beispielabfrage python

import csv
import json
import os
import time
from datetime import datetime, timezone, timedelta
from typing import Any, Dict, Iterable, List, Optional, Tuple

import requests

ZENDESK_SUBDOMAIN = os.getenv(class="hl-string">"ZENDESK_SUBDOMAIN", class="hl-string">"[Your Zendesk subdomain]")
API_EMAIL = os.getenv(class="hl-string">"ZENDESK_API_EMAIL", class="hl-string">"[Your API email]")
API_TOKEN = os.getenv(class="hl-string">"ZENDESK_API_TOKEN", class="hl-string">"[Your API token]")
START_DATE = os.getenv(class="hl-string">"START_DATE", class="hl-string">"[Start date in ISO 8601 format]")
OUTPUT_FILE = os.getenv(class="hl-string">"OUTPUT_FILE", class="hl-string">"incident_event_log.csv")
SOURCE_SYSTEM = class="hl-string">"Zendesk Support"
LAST_DATA_UPDATE = datetime.now(timezone.utc).isoformat()

if class="hl-string">"[" in ZENDESK_SUBDOMAIN or class="hl-string">"[" in API_EMAIL or class="hl-string">"[" in API_TOKEN or class="hl-string">"[" in START_DATE:
    raise ValueError(class="hl-string">"Set ZENDESK_SUBDOMAIN, ZENDESK_API_EMAIL, ZENDESK_API_TOKEN, and START_DATE before running")

BASE_URL = fclass="hl-string">"https://{ZENDESK_SUBDOMAIN}.zendesk.com/api/v2"
SESSION = requests.Session()
SESSION.auth = (fclass="hl-string">"{API_EMAIL}/token", API_TOKEN)
SESSION.headers.update({class="hl-string">"Accept": class="hl-string">"application/json"})

FIELDS = [
    class="hl-string">"TicketId", class="hl-string">"ActivityName", class="hl-string">"EventTimestamp", 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", class="hl-string">"EventEndTime"
]


def parse_time(value: Optional[str]) -> Optional[datetime]:
    if not value:
        return None
    return datetime.fromisoformat(value.replace(class="hl-string">"Z", class="hl-string">"+00:00"))


def iso(value: Any) -> str:
    if isinstance(value, datetime):
        return value.astimezone(timezone.utc).isoformat()
    if value is None:
        return class="hl-string">""
    return str(value)


def get_json(url: str, params: Optional[Dict[str, Any]] = None) -> Dict[str, Any]:
    for attempt in range(6):
        response = SESSION.get(url, params=params, timeout=60)
        if response.status_code == 429:
            retry_after = int(response.headers.get(class="hl-string">"Retry-After", class="hl-string">"5"))
            time.sleep(max(retry_after, 2 ** attempt))
            continue
        response.raise_for_status()
        return response.json()
    raise RuntimeError(fclass="hl-string">"Request failed after retries: {url}")


def incremental_tickets(start_time: str) -> Iterable[Dict[str, Any]]:
    url = fclass="hl-string">"{BASE_URL}/incremental/tickets/cursor.json"
    params: Optional[Dict[str, Any]] = {class="hl-string">"start_time": int(parse_time(start_time).timestamp())}
    while url:
        payload = get_json(url, params)
        for ticket in payload.get(class="hl-string">"tickets", []):
            yield ticket
        if payload.get(class="hl-string">"end_of_stream"):
            break
        url = payload.get(class="hl-string">"after_url")
        params = None


def ticket_audits(ticket_id: int) -> Iterable[Dict[str, Any]]:
    url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/audits.json"
    while url:
        payload = get_json(url)
        for audit in payload.get(class="hl-string">"audits", []):
            yield audit
        url = payload.get(class="hl-string">"next_page")


def satisfaction_for_ticket(ticket_id: int) -> Iterable[Dict[str, Any]]:
    url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/satisfaction_ratings.json"
    try:
        payload = get_json(url)
    except requests.HTTPError as error:
        if error.response is not None and error.response.status_code in (403, 404):
            return
        raise
    for rating in payload.get(class="hl-string">"satisfaction_ratings", []):
        yield rating


def user_name(user_id: Any, cache: Dict[str, str]) -> str:
    if not user_id:
        return class="hl-string">""
    key = str(user_id)
    if key not in cache:
        payload = get_json(fclass="hl-string">"{BASE_URL}/users/{user_id}.json")
        user = payload.get(class="hl-string">"user", {})
        cache[key] = user.get(class="hl-string">"name") or user.get(class="hl-string">"email") or key
    return cache[key]


def group_name(group_id: Any, cache: Dict[str, str]) -> str:
    if not group_id:
        return class="hl-string">""
    key = str(group_id)
    if key not in cache:
        payload = get_json(fclass="hl-string">"{BASE_URL}/groups/{group_id}.json")
        cache[key] = payload.get(class="hl-string">"group", {}).get(class="hl-string">"name") or key
    return cache[key]


def ticket_context(ticket: Dict[str, Any], users: Dict[str, str], groups: Dict[str, str]) -> Dict[str, str]:
    assignee = user_name(ticket.get(class="hl-string">"assignee_id"), users)
    group = group_name(ticket.get(class="hl-string">"group_id"), groups)
    return {
        class="hl-string">"TicketStatus": str(ticket.get(class="hl-string">"status") or class="hl-string">""),
        class="hl-string">"Assignee": assignee,
        class="hl-string">"AssignedGroup": group,
        class="hl-string">"TicketPriority": str(ticket.get(class="hl-string">"priority") or class="hl-string">""),
        class="hl-string">"Channel": str((ticket.get(class="hl-string">"via") or {}).get(class="hl-string">"channel") or class="hl-string">""),
        class="hl-string">"SlaStatus": class="hl-string">"",
    }


def make_row(ticket_id: Any, activity: str, event_time: Any, context: Dict[str, str], end_time: Any = class="hl-string">"") -> Dict[str, str]:
    row = {
        class="hl-string">"TicketId": str(ticket_id),
        class="hl-string">"ActivityName": activity,
        class="hl-string">"EventTimestamp": iso(event_time),
        class="hl-string">"SourceSystem": SOURCE_SYSTEM,
        class="hl-string">"LastDataUpdate": LAST_DATA_UPDATE,
        class="hl-string">"TicketStatus": context.get(class="hl-string">"TicketStatus", class="hl-string">""),
        class="hl-string">"Assignee": context.get(class="hl-string">"Assignee", class="hl-string">""),
        class="hl-string">"AssignedGroup": context.get(class="hl-string">"AssignedGroup", class="hl-string">""),
        class="hl-string">"TicketPriority": context.get(class="hl-string">"TicketPriority", class="hl-string">""),
        class="hl-string">"Channel": context.get(class="hl-string">"Channel", class="hl-string">""),
        class="hl-string">"SlaStatus": context.get(class="hl-string">"SlaStatus", class="hl-string">""),
        class="hl-string">"EventEndTime": iso(end_time),
    }
    return row


def audit_value(audit_event: Dict[str, Any], field: str) -> Any:
    for change in audit_event.get(class="hl-string">"changes", []):
        if change.get(class="hl-string">"field") == field:
            return change
    return None


def append_audit_rows(ticket: Dict[str, Any], audit: Dict[str, Any], rows: List[Dict[str, str]], users: Dict[str, str], groups: Dict[str, str]) -> None:
    ticket_id = ticket.get(class="hl-string">"id")
    event_time = audit.get(class="hl-string">"created_at")
    context = ticket_context(ticket, users, groups)
    author = user_name(audit.get(class="hl-string">"author_id"), users)
    for change in audit.get(class="hl-string">"events", []):
        event_type = change.get(class="hl-string">"type")
        field = change.get(class="hl-string">"field")
        value = change.get(class="hl-string">"value")
        previous = change.get(class="hl-string">"previous_value")
        if event_type == class="hl-string">"Create" or field == class="hl-string">"created_at":
            rows.append(make_row(ticket_id, class="hl-string">"Incident Created", event_time, context))
        if field == class="hl-string">"group_id" and value is not None:
            context[class="hl-string">"AssignedGroup"] = group_name(value, groups)
            if previous not in (None, class="hl-string">"", value):
                rows.append(make_row(ticket_id, class="hl-string">"Ticket Reassigned", event_time, context))
            else:
                rows.append(make_row(ticket_id, class="hl-string">"Ticket Assigned to Group", event_time, context))
        if field == class="hl-string">"assignee_id" and value is not None:
            context[class="hl-string">"Assignee"] = user_name(value, users)
            if previous not in (None, class="hl-string">"", value):
                rows.append(make_row(ticket_id, class="hl-string">"Ticket Reassigned", event_time, context))
            else:
                rows.append(make_row(ticket_id, class="hl-string">"Ticket Assigned to Agent", event_time, context))
        if field == class="hl-string">"priority" and value is not None:
            context[class="hl-string">"TicketPriority"] = str(value)
            rows.append(make_row(ticket_id, class="hl-string">"Priority Set", event_time, context))
        if field == class="hl-string">"status":
            context[class="hl-string">"TicketStatus"] = str(value or class="hl-string">"")
            if value == class="hl-string">"open":
                rows.append(make_row(ticket_id, class="hl-string">"Status Changed to Open", event_time, context))
            if value == class="hl-string">"pending":
                rows.append(make_row(ticket_id, class="hl-string">"Status Changed to Pending", event_time, context))
            if value == class="hl-string">"solved":
                rows.append(make_row(ticket_id, class="hl-string">"Incident Resolved", event_time, context))
            if value == class="hl-string">"closed":
                rows.append(make_row(ticket_id, class="hl-string">"Incident Closed", event_time, context))
        if event_type == class="hl-string">"Comment":
            if bool(change.get(class="hl-string">"public")):
                rows.append(make_row(ticket_id, class="hl-string">"Public Reply Sent", event_time, context))
            else:
                rows.append(make_row(ticket_id, class="hl-string">"Internal Note Added", event_time, context))


def append_satisfaction_rows(ticket: Dict[str, Any], rows: List[Dict[str, str]], users: Dict[str, str], groups: Dict[str, str]) -> None:
    context = ticket_context(ticket, users, groups)
    for rating in satisfaction_for_ticket(ticket.get(class="hl-string">"id")):
        rated_at = rating.get(class="hl-string">"created_at") or rating.get(class="hl-string">"updated_at")
        if rated_at:
            rows.append(make_row(ticket.get(class="hl-string">"id"), class="hl-string">"User Satisfaction Rated", rated_at, context))


def append_sla_breach_rows(ticket: Dict[str, Any], rows: List[Dict[str, str]], users: Dict[str, str], groups: Dict[str, str]) -> None:
    context = ticket_context(ticket, users, groups)
    sla_breach_time = ticket.get(class="hl-string">"sla_breach_at")
    if sla_breach_time:
        context[class="hl-string">"SlaStatus"] = class="hl-string">"Breached"
        rows.append(make_row(ticket.get(class="hl-string">"id"), class="hl-string">"SLA Target Breached", sla_breach_time, context))


def extract() -> List[Dict[str, str]]:
    rows: List[Dict[str, str]] = []
    users: Dict[str, str] = {}
    groups: Dict[str, str] = {}
    seen = set()
    for ticket in incremental_tickets(START_DATE):
        for audit in ticket_audits(ticket.get(class="hl-string">"id")):
            append_audit_rows(ticket, audit, rows, users, groups)
        append_satisfaction_rows(ticket, rows, users, groups)
        append_sla_breach_rows(ticket, rows, users, groups)
    unique_rows: List[Dict[str, str]] = []
    for row in rows:
        key = (row[class="hl-string">"TicketId"], row[class="hl-string">"ActivityName"], row[class="hl-string">"EventTimestamp"], row[class="hl-string">"Assignee"], row[class="hl-string">"AssignedGroup"])
        if key not in seen:
            seen.add(key)
            unique_rows.append(row)
    unique_rows.sort(key=lambda item: (item[class="hl-string">"TicketId"], item[class="hl-string">"EventTimestamp"], item[class="hl-string">"ActivityName"]))
    return unique_rows


if __name__ == class="hl-string">"__main__":
    event_rows = extract()
    with open(OUTPUT_FILE, class="hl-string">"w", newline=class="hl-string">"", encoding=class="hl-string">"utf-8") as output:
        writer = csv.DictWriter(output, fieldnames=FIELDS)
        writer.writeheader()
        writer.writerows(event_rows)
    print(json.dumps({class="hl-string">"output_file": OUTPUT_FILE, class="hl-string">"rows": len(event_rows), class="hl-string">"last_data_update": LAST_DATA_UPDATE}))

Schritte

Wählen Sie ein kommerzielles ETL- oder Datenintegrationstool mit einem verifizierten Zendesk-Support-Konnektor, der die Ticket-Audit-Historie und Kommentare extrahieren und Daten in Ihr Ziel-Data-Warehouse oder Dateisystem schreiben kann. Prüfen Sie, ob der Konnektor inkrementelle Extraktionen, Seitennavigation, die Verarbeitung von Ratenbegrenzungen und die Übernahme von Quell-Timestamps unterstützt.
Erstellen Sie die Zendesk-Verbindung im ausgewählten Tool. Geben Sie über die Konfigurationsoberfläche die Zendesk-Subdomain, die Authentifizierungsmethode, Zugangsdaten oder Token sowie alle erforderlichen Verbindungseinstellungen ein. Gewähren Sie Zugriff auf Tickets, Ticket-Audits, Kommentare, Benutzer, Gruppen, Zufriedenheitsbewertungen und SLA-Daten, sofern diese Objekte in Ihrem Zendesk-Tarif und im Konnektor verfügbar sind.
Konfigurieren Sie das Extraktionsfenster. Verwenden Sie für den ersten Ladevorgang einen rollierenden Zeitraum von drei bis sechs Monaten. Konfigurieren Sie anschließend inkrementelle Ladevorgänge anhand des vom Konnektor unterstützten Update- oder Audit-Timestamps. Speichern Sie das Watermark der letzten erfolgreichen Extraktion außerhalb des Event Logs, damit spätere Läufe keine Events duplizieren oder auslassen.
Extrahieren Sie die Ticketdaten, die für den Case-Kontext erforderlich sind, einschließlich Ticketkennung, aktuellem oder Event-bezogenem Status, Assignee, Gruppe, Priorität, Reporting-Kanal, SLA-Status und relevanten Update-Timestamps. Extrahieren Sie Ticket-Audit-Datensätze, da Zuweisungen, Prioritätsänderungen, Statusänderungen und andere Feldänderungen als explizite Event-Zeilen dargestellt werden müssen.
Extrahieren Sie Ticketkommentare und unterscheiden Sie öffentliche Kommentare anhand des öffentlichen Sichtbarkeitsindikators von internen Notizen. Erfassen Sie Kommentar-Timestamps, Ticketkennungen, Autorenkennungen sowie verfügbare End- oder Abschluss-Timestamps. Erstellen Sie für öffentliche Kommentare Zeilen mit Public Reply Sent und für private Kommentare Zeilen mit Internal Note Added.
Extrahieren Sie Zufriedenheitsbewertungen und SLA-Verletzungsdatensätze, sofern der Konnektor diese bereitstellt. Wenn der Konnektor SLA-Verletzungs-Events nicht direkt liefert, konfigurieren Sie im ETL-Tool eine Berechnung anhand des verfügbaren SLA-Ziels, der Richtlinie, der Geschäftszeiten und der Ticket-Event-Timestamps. Erstellen Sie keine Verletzungszeile, sofern die Quelldaten oder eine konfigurierte Berechnung keine Überschreitung des Ziels belegen.
Überführen Sie die extrahierten Quelldatensätze in ein normalisiertes Event Log. Erstellen Sie eine Zeile pro explizitem Auftreten einer Aktivität. Ordnen Sie die Ticketerstellung Incident Created zu, Änderungen der Gruppenzuweisung Ticket Assigned to Group oder Ticket Reassigned, Änderungen der Agentenzuweisung Ticket Assigned to Agent oder Ticket Reassigned, Prioritätsänderungen Priority Set, Statusübergänge der jeweils passenden Statusaktivität, Kommentare Public Reply Sent oder Internal Note Added, den Status solved Incident Resolved, Zufriedenheitsdatensätze User Satisfaction Rated und den Status closed Incident Closed.
Wenden Sie die Regeln zur Aktivitätsklassifizierung in einer festgelegten Reihenfolge an. Verwenden Sie, sofern verfügbar, die vorherigen und neuen Werte aus der Audit-Historie. Klassifizieren Sie die erste Zuweisung zu einer Gruppe als Ticket Assigned to Group, die erste Zuweisung zu einem Agenten als Ticket Assigned to Agent und spätere Änderungen der Zuständigkeit als Ticket Reassigned. Erstellen Sie für jede relevante Änderung eine Zeile, nicht nur für den zuletzt bekannten Ticketstatus.
Befüllen Sie die erforderlichen Spalten TicketId, ActivityName, EventTimestamp, SourceSystem und LastDataUpdate. Ergänzen Sie die empfohlenen Spalten TicketStatus, Assignee, AssignedGroup, TicketPriority, Channel, SlaStatus und EventEndTime aus dem Event-Kontext oder dem nächstgelegenen gültigen Quelldatensatz. Bewahren Sie Quell-Timestamps in einer einheitlichen Zeitzone, vorzugsweise UTC, auf und erhalten Sie die vom Konnektor unterstützte ursprüngliche Genauigkeit.
Validieren Sie die transformierte Ausgabe. Prüfen Sie, ob jede TicketId eine Zeile mit Incident Created enthält, ob die Event-Timestamps, soweit zutreffend, innerhalb des Extraktionsfensters liegen, ob alle 13 erforderlichen Aktivitätsnamen vertreten sind, wenn Quelldaten vorhanden sind, und ob doppelte Event-Schlüssel anhand der Quell-Auditkennung oder eines dokumentierten zusammengesetzten Schlüssels behandelt werden.
Schreiben Sie das Event Log als ProcessMind-kompatible Tabelle oder Datei in die Zieltabelle oder das Zieldateisystem, zum Beispiel als CSV oder im Format des unterstützten Warehouse-Konnektors. Verwenden Sie eine Kopfzeile, stabile Spaltennamen, UTF-8-Kodierung, ISO-8601-Timestamps und keine verschachtelten JSON-Daten in den finalen Event-Spalten. Laden Sie das resultierende Event Log in ProcessMind hoch oder verbinden Sie es mit ProcessMind. Verlassen Sie sich dabei nicht auf abgeleitete Aktivitäten, da ProcessMind die extrahierten Zeilen unverändert einliest.

Konfiguration

Konnektor und Lizenz: Verwenden Sie ein kommerzielles ETL- oder Datenintegrationstool mit einem Zendesk-Support-Konnektor, der Tickets, Ticket-Audits, Kommentare, Benutzer, Gruppen, Zufriedenheitsbewertungen und SLA-Informationen entsprechend dem Zendesk-Tarif und der Konnektorversion bereitstellt.
Authentifizierung und Autorisierung: Konfigurieren Sie die Zendesk-Subdomain und eine freigegebene Authentifizierungsmethode. Gewähren Sie nur die für die Extraktion von Tickets, Audits, Kommentaren, Benutzern, Gruppen, Zufriedenheits- und SLA-Daten erforderlichen Berechtigungen. Prüfen Sie, ob das Integrationskonto historische Datensätze lesen kann.
Zeitraum: Beginnen Sie zur Validierung und für den ersten Ladevorgang mit drei bis sechs Monaten. Erweitern Sie den Zeitraum erst, nachdem Zeilenanzahl, Seitennavigation und Verhalten bei Ratenbegrenzungen geprüft wurden. Verwenden Sie für geplante Läufe ein inkrementelles Watermark.
Erforderliche Filter: Wenden Sie nur unternehmensspezifische Filter an, die in der Quellkonfiguration bestätigt sind, etwa für eine bestimmte Zendesk-Subdomain, Marke, Organisation, Gruppe oder einen Ticketumfang. Verwenden Sie Company Code oder Document Type nur, wenn diese Felder im konfigurierten Zendesk-Datenmodell vorhanden sind.
Audit-Historie: Aktivieren Sie die Extraktion von Ticket-Audit-Events und bewahren Sie, sofern verfügbar, die Quell-Auditkennung auf, um doppelte Events bei inkrementellen Ladevorgängen zu verhindern.
Kommentare: Extrahieren Sie öffentliche und private Kommentare. Verwenden Sie den Sichtbarkeitsindikator der Quelle, um Public Reply Sent und Internal Note Added zu klassifizieren. Leiten Sie die Sichtbarkeit nicht aus dem Kommentartext ab.
Klassifizierung von Zuweisungen: Vergleichen Sie die vorherigen und neuen Werte für Gruppe oder Assignee. Klassifizieren Sie die erste relevante Zuweisung separat von späteren Änderungen und geben Sie für nachfolgende Änderungen der Zuständigkeit Ticket Reassigned aus.
Klassifizierung von Statusänderungen: Erstellen Sie Zeilen nur für explizite Statusübergänge. Ordnen Sie die Werte new, open, pending, solved und closed entsprechend dem konfigurierten Zendesk-Statusmodell zu. Wenn benutzerdefinierte Status verwendet werden, dokumentieren Sie die Zuordnung vor dem Ladevorgang.
SLA-Verarbeitung: Bevorzugen Sie Quell-Events zu SLA-Verletzungen. Wenn diese nicht verfügbar sind, konfigurieren Sie eine dokumentierte Berechnung anhand des verfügbaren SLA-Ziels, der Richtlinie, der Geschäftszeiten und der Event-Timestamps. Halten Sie die Berechnungsgrundlage in den ETL-Metadaten fest, statt Quellfelder zu erfinden.
Verarbeitung von Timestamps: Normalisieren Sie EventTimestamp und EventEndTime auf UTC oder eine andere dokumentierte Zeitzone. Bewahren Sie den Quell-Timestamp auf und ersetzen Sie die Event-Zeit nicht durch die Extraktionszeit.
LastDataUpdate: Setzen Sie LastDataUpdate auf den Timestamp der erfolgreichen ETL-Aktualisierung, einheitlich für alle Zeilen dieses Ladevorgangs.
Leistung: Verwenden Sie Seitennavigation, inkrementelle Extraktion, eine Partitionierung nach Ticket-Update- oder Audit-Timestamp, kontrollierte Parallelisierung, Wiederholungslogik und Backoff bei Ratenbegrenzungen. Vermeiden Sie es, bei jedem geplanten Lauf die vollständige Ticket-Historie erneut zu extrahieren.
Zielschema: Konfigurieren Sie eine flache Event-Tabelle oder Datei mit den erforderlichen Spalten TicketId, ActivityName, EventTimestamp, SourceSystem und LastDataUpdate sowie den empfohlenen Attributen, sofern verfügbar.
Verhalten von ProcessMind: Verlassen Sie sich nicht darauf, dass ProcessMind Statusänderungen, Zuweisungen, Antworten, Notizen, SLA-Verletzungen oder Lebenszyklus-Meilensteine ableitet. Jede Aktivität muss bereits vor dem Upload als Event-Zeile vorhanden sein.

a Beispielabfrage config

-- Configure this transformation in the selected ETL tool using its Zendesk connector.
-- Replace bracketed connection, credential, date, and company-specific values in the tool configuration.
-- The connector source objects and field mappings must be selected from the tool's verified Zendesk schema.

WITH
source_tickets AS (
    SELECT
        ticket_id,
        created_at,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        updated_at
    FROM [Your Zendesk tickets source]
    WHERE updated_at >= [Start date parameter]
      AND updated_at < [End date parameter]
),
source_audits AS (
    SELECT
        ticket_id,
        audit_id,
        event_timestamp,
        event_type,
        previous_value,
        new_value,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        event_end_time
    FROM [Your Zendesk ticket audits source]
    WHERE event_timestamp >= [Start date parameter]
      AND event_timestamp < [End date parameter]
),
source_comments AS (
    SELECT
        ticket_id,
        comment_id,
        event_timestamp,
        is_public,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        event_end_time
    FROM [Your Zendesk ticket comments source]
    WHERE event_timestamp >= [Start date parameter]
      AND event_timestamp < [End date parameter]
),
source_sla_breaches AS (
    SELECT
        ticket_id,
        breach_timestamp,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        event_end_time
    FROM [Your Zendesk SLA breach source]
    WHERE breach_timestamp >= [Start date parameter]
      AND breach_timestamp < [End date parameter]
),
source_satisfaction AS (
    SELECT
        ticket_id,
        rating_timestamp,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        event_end_time
    FROM [Your Zendesk satisfaction rating source]
    WHERE rating_timestamp >= [Start date parameter]
      AND rating_timestamp < [End date parameter]
),
classified_audits AS (
    SELECT
        a.*,
        ROW_NUMBER() OVER (
            PARTITION BY a.ticket_id, a.event_type
            ORDER BY a.event_timestamp, a.audit_id
        ) AS event_sequence
    FROM source_audits a
),
event_log AS (
    SELECT
        CAST(t.ticket_id AS VARCHAR(255)) AS TicketId,
        'Incident Created' AS ActivityName,
        t.created_at AS EventTimestamp,
        'Zendesk Support' AS SourceSystem,
        [ETL refresh timestamp] AS LastDataUpdate,
        t.status AS TicketStatus,
        t.assignee AS Assignee,
        t.assigned_group AS AssignedGroup,
        t.priority AS TicketPriority,
        t.channel AS Channel,
        t.sla_status AS SlaStatus,
        CAST(NULL AS TIMESTAMP) AS EventEndTime
    FROM source_tickets t

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Ticket Assigned to Group',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.status,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'group_assignment'
      AND a.event_sequence = 1
      AND a.new_value IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Ticket Assigned to Agent',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.status,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'assignee_assignment'
      AND a.event_sequence = 1
      AND a.new_value IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Priority Set',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.status,
        a.assignee,
        a.assigned_group,
        a.new_value,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'priority_change'
      AND a.new_value IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Status Changed to Open',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.new_value,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'status_change'
      AND a.previous_value = 'new'
      AND a.new_value = 'open'

    UNION ALL

    SELECT
        CAST(c.ticket_id AS VARCHAR(255)),
        'Public Reply Sent',
        c.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        c.status,
        c.assignee,
        c.assigned_group,
        c.priority,
        c.channel,
        c.sla_status,
        c.event_end_time
    FROM source_comments c
    WHERE c.is_public = TRUE

    UNION ALL

    SELECT
        CAST(c.ticket_id AS VARCHAR(255)),
        'Internal Note Added',
        c.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        c.status,
        c.assignee,
        c.assigned_group,
        c.priority,
        c.channel,
        c.sla_status,
        c.event_end_time
    FROM source_comments c
    WHERE c.is_public = FALSE

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Ticket Reassigned',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.status,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type IN ('group_assignment', 'assignee_assignment')
      AND a.event_sequence > 1
      AND COALESCE(a.previous_value, '') <> COALESCE(a.new_value, '')

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Status Changed to Pending',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.new_value,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'status_change'
      AND a.new_value = 'pending'

    UNION ALL

    SELECT
        CAST(s.ticket_id AS VARCHAR(255)),
        'SLA Target Breached',
        s.breach_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        s.status,
        s.assignee,
        s.assigned_group,
        s.priority,
        s.channel,
        s.sla_status,
        s.event_end_time
    FROM source_sla_breaches s
    WHERE s.breach_timestamp IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Incident Resolved',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.new_value,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'status_change'
      AND a.new_value = 'solved'

    UNION ALL

    SELECT
        CAST(s.ticket_id AS VARCHAR(255)),
        'User Satisfaction Rated',
        s.rating_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        s.status,
        s.assignee,
        s.assigned_group,
        s.priority,
        s.channel,
        s.sla_status,
        s.event_end_time
    FROM source_satisfaction s
    WHERE s.rating_timestamp IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Incident Closed',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.new_value,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'status_change'
      AND a.new_value = 'closed'
)
SELECT
    TicketId,
    ActivityName,
    EventTimestamp,
    SourceSystem,
    LastDataUpdate,
    TicketStatus,
    Assignee,
    AssignedGroup,
    TicketPriority,
    Channel,
    SlaStatus,
    EventEndTime
FROM event_log
WHERE TicketId IS NOT NULL
  AND ActivityName IS NOT NULL
  AND EventTimestamp IS NOT NULL
ORDER BY TicketId, EventTimestamp, ActivityName;

Möchten Sie jetzt starten?

Verwenden Sie dieses Template, um Ihre Datenvorbereitung zu vereinfachen und aussagekräftige Erkenntnisse über die Leistung Ihres Incident Managements zu gewinnen. Beginnen Sie noch heute mit der Optimierung Ihres Prozesses.

Zurück zum Leitfaden zur Verbesserung Template herunterladen

Optimieren Sie Ihr Incident Management und lösen Sie Incidents noch heute schneller

Senken Sie die MTTR um 35 %, vermeiden Sie wiederkehrende Incidents und steigern Sie die Zufriedenheit.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich, beginnen Sie in wenigen Minuten mit der Verbesserung

Ihr Daten-Template für das Incident Management

Ihr Daten-Template für das Incident Management

Attribute des Incident Managements

Aktivitäten des Incident Managements

Anleitungen zur Datenextraktion

Export von Zendesk-Explore-Berichten aus der Benutzeroberfläche in eine CSV-Datei

Schritte

Konfiguration

a Beispielabfrage config

Python-Skript mit der Zendesk-Support-REST-API

Schritte

Konfiguration

a Beispielabfrage python

Zendesk Incremental Export API für die Massensynchronisierung von Daten

Schritte

Konfiguration

a Beispielabfrage python

ETL-Tool eines Drittanbieters mit Zendesk-API-Konnektor

Schritte

Konfiguration

a Beispielabfrage config

Möchten Sie jetzt starten?

Optimieren Sie Ihr Incident Management und lösen Sie Incidents noch heute schneller

Ihr Daten-Template für das Incident Management

Ihr Daten-Template für das Incident Management

Attribute des Incident Managements

Aktivitäten des Incident Managements

Anleitungen zur Datenextraktion

Export von Zendesk-Explore-Berichten aus der Benutzeroberfläche in eine CSV-Datei

Schritte

Konfiguration

a Beispielabfrage config

Python-Skript mit der Zendesk-Support-REST-API

Schritte

Konfiguration

a Beispielabfrage python

Zendesk Incremental Export API für die Massensynchronisierung von Daten

Schritte

Konfiguration

a Beispielabfrage python

ETL-Tool eines Drittanbieters mit Zendesk-API-Konnektor

Schritte

Konfiguration

a Beispielabfrage config

Möchten Sie jetzt starten?

Optimieren Sie Ihr Incident Management und lösen Sie Incidents noch heute schneller

Ihre Privatsphäre ist uns wichtig