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

Ihr Daten-Template für das Vorfallmanagement

Zendesk Support

← Zurück zum Leitfaden zur Prozessverbesserung

Attribute des Vorfallmanagements(23) Aktivitäten im Vorfallmanagement(13) Anleitungen zur Datenextraktion(4)

Ihr Daten-Template für das Vorfallmanagement

Dieses Template bietet einen strukturierten Überblick über die wichtigsten Daten für eine fundierte Analyse Ihres Vorfallmanagements. Es zeigt, welche zentralen Attribute Sie erfassen und welche wichtigen Aktivitäten Sie nachverfolgen sollten. Außerdem enthält es praktische Hinweise zum Extrahieren der Daten aus Zendesk Support. So schaffen Sie eine geeignete und vollständige Datengrundlage für Ihr Process-Mining-Projekt.

Empfohlene Attribute für die Datenerfassung
Wichtige Aktivitäten für die Prozessabbildung
Praktische Hinweise zur Datenextraktion

Neu bei Event Logs? Erfahren Sie, wie Sie ein Event Log für Process Mining erstellen.

Template herunterladen

Attribute des Vorfallmanagements

Diese Datenfelder sollten Sie in Ihr Event Log aufnehmen, um Ihr Vorfallmanagement umfassend zu analysieren.

5 Erforderlich 7 Empfohlen 11 Optional

	Name	Beschreibung
	Ereignis-Timestamp EventTimestamp	Das genaue Datum und die genaue Uhrzeit, zu der die Aktivität stattgefunden hat.
Beschreibung Dieser Timestamp hält den genauen Zeitpunkt eines Ereignisses im Lebenszyklus eines Vorfalls fest, etwa wenn ein Kommentar hinzugefügt oder der Status geändert wurde. Er gibt die chronologische Reihenfolge aller Aktivitäten innerhalb eines Falls vor. Dieses Attribut ist grundlegend für jede zeitbasierte Process-Mining-Analyse. Es dient dazu, Zykluszeiten zwischen Aktivitäten zu berechnen, Wartezeiten zu erkennen, die Gesamtdauer eines Falls zu messen und die Prozessleistung über verschiedene Zeiträume hinweg zu analysieren. Präzise Zeitstempel sind unverzichtbar, um eine animierte Prozessübersicht zu erstellen, die den Ablauf von Fällen im Zeitverlauf zeigt, und Dashboards mit Kennzahlen wie der durchschnittlichen Lösungszeit aufzubauen. Warum das wichtig ist Zeitstempel ordnen alle Aktivitäten chronologisch ein. So lassen sich Dauern berechnen, Engpässe erkennen und die Prozessleistung im Zeitverlauf analysieren. Woher beziehen 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
	Vorfall-ID TicketId	Die eindeutige, vom System generierte Kennung für jedes Vorfallticket.
Beschreibung Die Incident ID ist der Primärschlüssel, der jeden Vorfallfall in Zendesk Support eindeutig identifiziert. Beim Process Mining dient sie als CaseId und verknüpft alle zugehörigen Aktivitäten, Statusänderungen und Mitteilungen vom Zeitpunkt der Erstellung bis zum Abschluss des Vorfalls. Für die Analyse ist diese ID entscheidend, um den vollständigen Verlauf jedes Vorfalls zu rekonstruieren. Sie ermöglicht es, Ereignisdaten zusammenzuführen und Kennzahlen wie die gesamte Lösungszeit, die Anzahl der Übergaben und die Einhaltung von Service-Level-Vereinbarungen für einzelne Fälle zu verfolgen. Wenn Analysten Ereignisse anhand dieser ID gruppieren, können sie Prozessabläufe visualisieren, häufige Pfade erkennen und Abweichungen vom Sollprozess aufdecken. Warum das wichtig ist Diese wichtige Kennung verknüpft alle Ereignisse mit einem einzelnen Vorfall. So lässt sich der gesamte Lebenszyklus nachvollziehen und die Prozessleistung präzise analysieren. Woher beziehen 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 Lebenszyklus eines Vorfalls stattgefunden hat.
Beschreibung Dieses Attribut beschreibt einen konkreten Schritt oder eine Aktion im Incident-Management-Prozess, zum Beispiel „Vorfall erstellt“, „Ticket einem Agent zugewiesen“ oder „Vorfall gelöst“. Die Aktivitäten werden aus dem Event Log oder den Audit-Trail-Daten von Zendesk abgeleitet, in denen Systemänderungen erfasst sind. Beim Process Mining bildet die Abfolge dieser Aktivitäten die Prozessübersicht und damit die Grundlage aller Analysen. Durch die Analyse des Aktivitätsflusses können Unternehmen die tatsächlichen Pfade von Vorfällen ermitteln, Engpässe zwischen Schritten erkennen, Schleifen mit Nacharbeit messen, etwa wenn ein gelöstes Ticket erneut geöffnet wird, und die Konformität mit einem festgelegten Sollprozess prüfen. Warum das wichtig ist Die Abfolge der Aktivitäten bestimmt den Prozessablauf. Sie bildet den Kern der Process-Mining-Analyse, mit der Ineffizienzen, Abweichungen und Verbesserungsmöglichkeiten erkannt werden. Woher beziehen Abgeleitet aus Ereignissen in der Zendesk Ticket Audits API. Ein Change-Ereignis für das Statusfeld kann beispielsweise „Status geändert“ zugeordnet werden. Beispiele Vorfall erstelltTicket einem Agent zugewiesenStatus auf „Pending“ geändertVorfall gelöstVorfall 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 wird ein einzelner Wert auf den gesamten Datensatz eines Aktualisierungszyklus angewendet. Diese Information ist wichtig für die Data Governance und für Benutzer der Process-Mining-Analyse. Sie zeigt, wie aktuell die Daten sind, und hilft Analysten einzuschätzen, ob sie die neuesten verfügbaren Informationen sehen. Das ist besonders wichtig, wenn die betriebliche Leistung überwacht und auf Grundlage der Analyse zeitnah entschieden werden soll. Warum das wichtig ist Gibt wichtigen Aufschluss über die Aktualität der Daten. So können Benutzer einschätzen, wie aktuell die Analyse ist und wann die Daten zuletzt aus der Quelle abgerufen wurden. Woher beziehen Timestamp, der nach Abschluss der Datenaktualisierung durch den ETL- oder Datenpipeline-Prozess erzeugt wird. Beispiele 2023-10-27T08:00:00Z2023-10-28T08:00:00Z
	Quellsystem SourceSystem	Das System, aus dem die Vorfalldaten extrahiert wurden.
Beschreibung Dieses Attribut gibt die Herkunft der Prozessdaten an. In dieser Ansicht wäre der Wert statisch, zum Beispiel „Zendesk Support“, und würde anzeigen, dass alle Ereignisse und Attribute aus diesem System stammen. Wenn Daten aus mehreren Systemen zusammengeführt werden, ist dieses Feld entscheidend, um die verschiedenen Datenquellen auseinanderzuhalten. Es unterstützt die Datenintegrität und ermöglicht Analysen nach Quelle, etwa einen Vergleich des Incident-Management-Prozesses in Zendesk mit dem in einem anderen ITSM-Tool. Warum das wichtig ist Gibt die Herkunft der Daten an. Das ist wichtig für die Data Governance und für Analysen, die Daten aus mehreren Quellsystemen zusammenführen. Woher beziehen Statischer Wert, der bei der Datentransformation zur Kennzeichnung der Datenherkunft festgelegt 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 aus der Startzeit der nächsten Aktivität desselben Cases abgeleitet. Bei der letzten Aktivität eines Cases kann die Endzeit mit der Startzeit übereinstimmen. Dieses Attribut ist erforderlich, um die Dauer einzelner Aktivitäten (ProcessingTime) und die Wartezeit zwischen Aktivitäten zu berechnen. Diese Informationen bilden die Grundlage für die Engpassanalyse. So sehen Analysten nicht nur, 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 die Grundlage für eine detaillierte Engpassanalyse und die Erkennung von Prozessverzögerungen. Woher beziehen Wird als Startzeit des nachfolgenden Ereignisses desselben Cases berechnet. Die Endzeit des letzten Ereignisses kann mit dessen Startzeit oder dem Zeitpunkt des Case-Abschlusses übereinstimmen. 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, zum Beispiel „E-Mail“, „Web“ oder „API“.
Beschreibung Dieses Attribut erfasst, über welchen Weg ein Endbenutzer oder ein System das Incident-Ticket erstellt hat. Der Kanal hilft dabei, die Herkunft von Incidents zu analysieren und den Supportprozess darauf abzustimmen. Die Analyse nach Kanal kann unterschiedliche Muster aufzeigen. Beispielsweise werden telefonisch gemeldete Incidents möglicherweise schneller gelöst als solche, die per E-Mail eingehen. Diese Informationen fließen in das Dashboard „Incident-Aufkommen“ ein und unterstützen die Ressourcenplanung sowie die Optimierung der Kanäle. Warum das wichtig ist Ermöglicht die Analyse des Incident-Aufkommens und der Prozessleistung nach Quelle. So lassen sich Prozesse gezielt für einzelne Kanäle verbessern und Ressourcen entsprechend zuweisen. Woher beziehen Zendesk Tickets API, Feld via.channel. Beispiele WebE-MailAPITelefon
	Priorität TicketPriority	Die dem Incident zugewiesene Priorität, zum Beispiel „Niedrig“, „Normal“, „Hoch“ oder „Dringend“.
Beschreibung Die Priorität eines Incidents bestimmt, wie dringend eine Reaktion und Lösung erforderlich sind. Sie ist ein wichtiger Faktor für die Priorisierung der Arbeit und die Zuweisung von Ressourcen im Support-Team. Bei der Prozessanalyse dient die Priorität dazu, Incidents zu segmentieren und ihre Abläufe und Leistung zu vergleichen. Analysten können beispielsweise prüfen, ob „Dringende“ Incidents tatsächlich schneller gelöst werden als Incidents mit niedriger Priorität. Die Priorität wird auch zur Überwachung der SLA-Einhaltung herangezogen, da SLAs häufig nach Prioritätsstufen festgelegt werden. Für die KPI „Änderungsrate der Priorität“ müssen Änderungen dieses Feldes erfasst werden. Warum das wichtig ist Dieses Attribut ist entscheidend, um Analysen zu segmentieren, die Wirksamkeit der Priorisierung zu bewerten und die SLA-Einhaltung für unterschiedliche Dringlichkeitsstufen zu überwachen. Woher beziehen 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 voraussichtlich die festgelegten SLA-Ziele erreicht, diese bereits verletzt hat oder die SLA-Zeitmessung pausiert ist. Zendesk erfasst SLA-Kennzahlen automatisch auf Grundlage der konfigurierten Richtlinien. Das Attribut ist entscheidend für das Dashboard „Überwachung der SLA-Einhaltung“. Es misst direkt, wie gut die vereinbarten Service-Level eingehalten werden. Durch die Analyse, wann und warum SLAs verletzt werden, können Unternehmen Schwachstellen im Prozess erkennen und die Zuverlässigkeit des Services verbessern. Das Attribut unterstützt direkt die KPI „Einhaltungsrate der Incident-SLAs“. Warum das wichtig ist Misst direkt die Leistung im Verhältnis zu den vereinbarten Service-Leveln. So lassen sich SLA-Verletzungen analysieren und die Einhaltung proaktiv überwachen. Woher beziehen 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 Vorfalltickets zum Zeitpunkt des Ereignisses, zum Beispiel „Open“, „Pending“ oder „Solved“.
Beschreibung Dieses Attribut zeigt den Status des Vorfalltickets zu verschiedenen Zeitpunkten seines Lebenszyklus. Zu den Standardstatus in Zendesk gehören new, open, pending, on-hold, solved und closed. Die Änderungen dieses Feldes nachzuverfolgen, ist eine wichtige Möglichkeit, Aktivitäten für Process Mining zu erzeugen. Die Analyse des Ticketstatus ist grundlegend, um den Prozess zu verstehen. Sie zeigt, wie lange Vorfälle in bestimmten Status verbleiben. Der Status „Pending“ weist beispielsweise häufig darauf hin, dass auf eine Antwort des Kunden gewartet wird. Der Ticketstatus ist außerdem wichtig, um den Abschluss eines Falls festzulegen und Lösungszeiten zu berechnen. Warum das wichtig ist Die Nachverfolgung von Statusänderungen ist entscheidend, um den Prozessverlauf zu verstehen, Wartezeiten zu erkennen und Anfang sowie Ende des Incident-Lebenszyklus festzulegen. Woher beziehen Zendesk Tickets API, Feld status. Änderungen werden in der Ticket Audits API protokolliert. Beispiele NeuOffenAusstehendGelöstGeschlossen
	Zugewiesene Gruppe AssignedGroup	Das Support-Team oder die Gruppe, die aktuell für den Incident zuständig ist.
Beschreibung Dieses Attribut zeigt, welches Team für den Incident verantwortlich ist. Incidents werden häufig zwischen verschiedenen Support-Ebenen oder spezialisierten Gruppen weitergegeben, zum Beispiel vom „L1 Support“ an das „Network Team“. Diese Dimension ist entscheidend, um Übergaben im Prozess zu analysieren und Engpässe zu erkennen. Wenn Analysten verfolgen, wie Incidents zwischen Gruppen weitergeleitet werden, können sie Abhängigkeiten zwischen Teams messen, Wartezeiten in den Warteschlangen einzelner Teams berechnen und Weiterleitungsregeln optimieren. Das Attribut unterstützt direkt das Dashboard „Analyse von Übergaben und Nacharbeit“. Warum das wichtig ist Erfasst die Zuständigkeit der Teams. Das ist wichtig, um teamübergreifende Übergaben zu analysieren, teambezogene Engpässe zu erkennen und Wartezeiten zu messen. Woher beziehen Zendesk Tickets API, Feld group_id. Änderungen werden in der Ticket Audits API protokolliert. Beispiele L1-SupportL2-NetzwerkteamL3-InfrastrukturAbrechnung
	Zugewiesener Agent Assignee	Der Support-Agent, der aktuell mit der Bearbeitung des Incidents betraut ist.
Beschreibung Dieses Attribut gibt an, welcher Agent zu einem bestimmten Zeitpunkt für den Incident verantwortlich ist. Änderungen der Zuständigkeit sind wichtige Ereignisse, denn sie zeigen, dass die Arbeit von einer Person an eine andere übergeben wurde. Die Analyse des zugewiesenen Agents hilft dabei, die Arbeitsverteilung, die individuelle Leistung und die Zusammenarbeit zu verstehen. Änderungen dieses Feldes müssen erfasst werden, um die KPI „Durchschnittliche Übergaben pro Incident“ zu berechnen und Fälle zu erkennen, die häufig weitergereicht werden. Das kann auf Wissenslücken oder eine ineffiziente Weiterleitung hindeuten. Warum das wichtig ist Gibt den zuständigen Agent an und ermöglicht so die Analyse der Arbeitsauslastung und die Nachverfolgung von Übergaben. Das ist entscheidend, um Ineffizienzen im Prozess zu erkennen. Woher beziehen 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 Neuzuweisungen eines Incidents an einen anderen Agent oder eine andere Gruppe.
Beschreibung Diese berechnete Kennzahl gibt an, wie oft die Verantwortung für einen Incident übertragen wurde. Jede Änderung im Feld Assignee oder AssignedGroup erhöht den Wert für den Case um eins. Übergaben sind eine häufige Ursache für Ineffizienz und Verzögerungen im Incident-Management. Eine hohe Anzahl kann auf unklare Weiterleitungsregeln, Wissenslücken in Support-Teams oder übermäßig komplexe Prozesse hindeuten. Die Kennzahl bildet die Grundlage für die KPI „Durchschnittliche Übergaben pro Incident“ und ist entscheidend für das Dashboard „Analyse von Übergaben und Nacharbeit“. Warum das wichtig ist Quantifiziert Reibungsverluste durch Übergaben und hilft, ineffiziente Weiterleitungen und Wissenslücken zu erkennen, die die Lösungszeit verlängern. Woher beziehen Wird berechnet, indem gezählt wird, wie oft sich das Feld AssignedGroup oder Assignee für einen Incident geändert hat. Beispiele 0135
	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 Ereignisse von menschlichen Benutzern von Aktionen durch Systemautomatisierungen, Trigger oder API-Integrationen. Üblicherweise wird dafür geprüft, ob der Autor eines Ereignisses ein bekanntes Systemkonto ist. Der Automatisierungsgrad ist für die moderne Prozessanalyse entscheidend. Er hilft dabei, die Wirksamkeit von Automatisierungsregeln zu bewerten, manuelle Aufgaben mit Automatisierungspotenzial zu erkennen und die Auswirkungen der Automatisierung auf Effizienz und Lösungszeiten zu messen. Mit diesem Attribut lassen sich die Abläufe automatisierter und manueller Aktivitäten vergleichen. Warum das wichtig ist Unterscheidet zwischen Aktionen von Menschen und Systemen. Das ist wichtig, um die Auswirkungen der Automatisierung auf die Prozesseffizienz zu analysieren und weitere Automatisierungsmöglichkeiten zu erkennen. Woher beziehen Wird abgeleitet, indem geprüft wird, ob der Autor des Ereignisses (author_id in der Ticket Audits API) einem bekannten System- oder Automatisierungsbenutzer entspricht. Beispiele truefalse
	Beim ersten Kontakt gelöst IsFirstContactResolution	Ein boolesches Kennzeichen, das angibt, ob der Incident vom zuerst zugewiesenen Agent oder der zuerst zugewiesenen Gruppe ohne Übergaben gelöst wurde.
Beschreibung Die Lösung beim ersten Kontakt (First Contact Resolution, FCR) ist eine wichtige Kennzahl für die Effizienz des Support-Centers und die Kundenzufriedenheit. Dieses berechnete Attribut kennzeichnet Incidents, die gelöst wurden, ohne einem anderen Agent oder Team zugewiesen zu werden. Die Logik prüft üblicherweise, ob das Ticket den Status „Gelöst“ erreicht hat und währenddessen dem ursprünglichen Agent und der ursprünglichen Gruppe zugewiesen blieb. Im Process Mining lässt sich damit die FCR-Rate direkt berechnen und der Ablauf von FCR-Incidents mit Fällen vergleichen, die eskaliert werden mussten. So erkennen Sie Möglichkeiten, Probleme früher im Supportprozess zu lösen. Warum das wichtig ist Misst direkt die Effizienz des ersten Supportkontakts und zeigt Möglichkeiten auf, Lösungen früher im Prozess zu erreichen. Woher beziehen Berechnetes boolesches Kennzeichen. Ist wahr, wenn der Ticketstatus „Gelöst“ oder „Geschlossen“ lautet und dem Incident während seines gesamten Lebenszyklus nur ein eindeutiger Agent oder eine eindeutige Gruppe zugewiesen war. Beispiele truefalse
	Case-Dauer CaseDuration	Die gesamte Zeit vom Anlegen des Incidents bis zu seinem endgültigen Abschluss.
Beschreibung Diese berechnete Kennzahl gibt die durchgängige Zykluszeit eines einzelnen Incidents an. Sie ergibt sich aus der Differenz zwischen dem Timestamp des ersten Ereignisses (z. B. „Incident erstellt“) und dem des letzten Ereignisses (z. B. „Incident geschlossen“). Die Case-Dauer ist eine zentrale KPI für die Effizienz des Gesamtprozesses. Dashboards verwenden sie häufig, um durchschnittliche Zykluszeiten darzustellen, lang laufende Cases zu erkennen und Entwicklungen im Zeitverlauf zu analysieren. Sie zeigt auf übergeordneter Ebene, wie schnell der Prozess Incidents bearbeitet und löst. Warum das wichtig ist Diese wichtige KPI misst die Geschwindigkeit des Gesamtprozesses und zeigt Faktoren auf, die zu langen Lösungszeiten beitragen. Woher beziehen Wird für jede Incident-ID berechnet, indem der Timestamp des ersten Ereignisses vom Timestamp des letzten Ereignisses abgezogen wird. Beispiele 25920060480086400
	Kategorie der Grundursache RootCauseCategory	Die übergeordnete Kategorie der zugrunde liegenden Ursache des Incidents.
Beschreibung Dieses Attribut klassifiziert die grundlegende Ursache eines Incidents. Es wird üblicherweise gegen Ende des Incident-Lebenszyklus erfasst, häufig im Rahmen einer Nachbesprechung oder des Problem-Managements, und in einem benutzerdefinierten Feld gespeichert. Diese Daten sind wichtig für das Dashboard „Genauigkeit der Ursachenanalyse“ und die KPI „Abdeckung der Ursachenanalyse“. Die Analyse der Incidents nach Ursache hilft, wiederkehrende Probleme zu erkennen und dauerhafte Lösungen zu entwickeln, um künftige Incidents zu vermeiden. So verlagert sich der Schwerpunkt von der reaktiven Störungsbehebung auf die proaktive Problemvermeidung. Warum das wichtig ist Unterstützt ein proaktives Problem-Management: Die Ursachen von Incidents werden kategorisiert, Trends sichtbar und künftige Vorfälle vermeidbar. Woher beziehen In der Regel handelt es sich um ein benutzerdefiniertes Ticketfeld. Prüfen Sie die Konfiguration der Ticketfelder im Zendesk Admin Center. Beispiele SoftwarefehlerHardwareausfallBenutzerfehlerNetzwerkausfall
	Kundenorganisation Organization	Die Organisation oder das Unternehmen, zu dem die anfragende Person des Incidents gehört.
Beschreibung Dieses Attribut ordnet einen Incident der Organisation des Kunden zu. Es ist für B2B-Support wichtig, da Service-Level und Supportprozesse je nach Kunde variieren können. Wenn Support-Teams Incidents nach Organisation analysieren, können sie die Kundenzufriedenheit im Blick behalten, wiederkehrende Probleme einzelner Kunden erkennen und die Einhaltung vertraglicher Verpflichtungen prüfen. Als wichtige Dimension ermöglicht das Attribut, Dashboards und Berichte zu filtern und die Leistung aus Kundensicht darzustellen. Warum das wichtig ist Ermöglicht Analysen für einzelne Kunden. So können Sie Service-Level überwachen, Trends bei wichtigen Kunden erkennen und Kundenbeziehungen gezielt betreuen. Woher beziehen 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 gibt an, welche Person oder Entität das Ticket erstellt hat. Es unterscheidet sich von der anfragenden Person, da ein Agent ein Ticket im Auftrag einer anderen Person erstellen kann. In der Analyse zeigt die meldende Person, wer Probleme meldet. In Verbindung mit Organisationsdaten lässt sich feststellen, ob bestimmte Kunden oder Benutzergruppen besonders viele Incidents melden. Daraus können sich Ansatzpunkte für proaktiven Support oder Schulungen ergeben. Warum das wichtig ist Gibt die Quelle der Incident-Meldung an. So lassen sich Muster bei bestimmten Benutzern, Abteilungen oder automatisierten Systemen erkennen. Woher beziehen Zendesk Tickets API, Feld submitter_id. Beispiele alice.jones@example.combob.williams@example.comSystemüberwachung
	Schweregrad Severity	Das Ausmaß der geschäftlichen Auswirkungen des Incidents.
Beschreibung Der Schweregrad beschreibt die geschäftlichen Auswirkungen eines Incidents. Zusammen mit der Priorität bestimmt er häufig die Dringlichkeit. In Zendesk wird er üblicherweise als benutzerdefiniertes Feld konfiguriert. Die Analyse des Schweregrads zeigt, wie kritisch die bearbeiteten Incidents sind. Als wichtige Dimension dient er zur Segmentierung von Daten in Dashboards wie „Überwachung der SLA-Einhaltung“ und „Kennzahlen zur Wirksamkeit der Priorisierung“. Der Vergleich von Prozessabläufen für unterschiedliche Schweregrade kann zeigen, ob Incidents mit schwerwiegenden Auswirkungen schnell genug und mit den passenden Ressourcen bearbeitet werden. Warum das wichtig ist Zeigt die geschäftlichen Auswirkungen eines Incidents an. So können Sie besonders kritische Probleme gezielt analysieren und sicherstellen, dass sie effizient gelöst werden. Woher beziehen In der Regel handelt es sich um ein benutzerdefiniertes Feld. Prüfen Sie die Konfiguration der Ticketfelder im Zendesk Admin Center. Beispiele 1 - Kritisch2 - Hoch3 - Mittel4 - Niedrig
	Tags Tags	Eine Liste von Tags, die dem Incident zur Kategorisierung und als Kontext hinzugefügt wurden.
Beschreibung Tags sind flexible Kennzeichnungen, die Tickets zusätzlichen Kontext geben oder bei der Kategorisierung und Weiterleitung helfen. Agents können sie manuell hinzufügen; ebenso können sie automatisch durch Trigger und Automatisierungen gesetzt werden. Tags liefern wertvolle Daten für Process-Mining-Analysen. Sie ermöglichen eine detaillierte Segmentierung, etwa nach Incidents zu einer bestimmten Produkteinführung („launch_q4“) oder einem bekannten Ausfall („outage_20231027“). Damit lassen sich Untersuchungen durchführen, die über die Standard-Ticketfelder hinausgehen. Warum das wichtig ist Ermöglicht eine flexible Kategorisierung und Filterung von Incidents. So werden detaillierte, kontextspezifische Analysen möglich, die Standardfelder allein nicht bieten. Woher beziehen Zendesk Tickets API, Feld tags. Beispiele vip_usernetwork_issueoutage_20231027billing_related
	Tickettyp TicketType	Die Klassifizierung des Tickets, zum Beispiel „Incident“, „Problem“, „Frage“ oder „Aufgabe“.
Beschreibung Dieses Feld kategorisiert das Ticket nach Art der Anfrage. Der Incident-Management-Prozess konzentriert sich auf Tickets des Typs „Incident“. Sie stehen für eine ungeplante Unterbrechung oder eine Beeinträchtigung der Qualität eines IT-Services. In der Analyse dient dieses Attribut vor allem als Filter, damit die Prozessansicht nur Incidents enthält. Für umfassendere ITSM-Analysen können Sie damit auch die Prozesse zur Bearbeitung von Incidents, Problemen und Serviceanfragen vergleichen. Warum das wichtig ist Ermöglicht es, die Daten gezielt auf Incidents zu beschränken, damit die Prozessanalyse den Lebenszyklus des Incident-Managements abbildet. Woher beziehen Zendesk Tickets API, Feld type. Beispiele IncidentProblemFrageAufgabe
	Zufriedenheitsbewertung SatisfactionRating	Die Zufriedenheitsbewertung, die der Endbenutzer nach der Lösung des Incidents abgibt.
Beschreibung Dieses Attribut erfasst die Rückmeldung des Kunden zu seiner Support-Erfahrung. Sie wird üblicherweise nach der Lösung des Tickets über eine Umfrage eingeholt. In Zendesk lauten gängige Bewertungen „Gut“ oder „Schlecht“. Die Zufriedenheitsbewertung misst die Prozesseffizienz nicht direkt, ist aber eine wichtige Ergebniskennzahl. Im Process Mining lässt sie sich mit Prozessvarianten vergleichen, 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 sich mit Prozessmerkmalen vergleichen lässt. So wird sichtbar, wie sich die Prozessleistung auf die Zufriedenheit der Benutzer auswirkt. Woher beziehen Zendesk Ticket Metrics API (/api/v2/ticket_metrics.json), Feld satisfaction_rating.score. Beispiele GutSchlechtAngebotenNicht angeboten

Erforderlich Empfohlen Optional

Aktivitäten im Vorfallmanagement

Diese wichtigen Prozessschritte und Meilensteine sollten Sie in Ihrem Event Log erfassen, damit sich der Prozess zuverlässig entdecken und analysieren lässt.

6 Empfohlen 7 Optional

	Aktivität	Beschreibung
	Status auf „Open“ geändert	Zeigt an, dass ein Agent mit der aktiven Bearbeitung des Vorfalls begonnen hat. Diese Aktivität wird üblicherweise daraus abgeleitet, dass sich das Feld 'status' des Tickets von 'new' zu 'open' ändert. Damit beginnt die 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. Woher beziehen Wird aus dem Ticket-Audit-Log abgeleitet, indem ein „Change“-Ereignis ermittelt wird, bei dem der neue Wert des Feldes 'status' 'open' und der vorherige Wert 'new' ist. Erfassung Abgeleitet aus einer Statusänderung von 'new' zu 'open'. Ereignistyp inferred
	Ticket einem Agent zugewiesen	Diese Aktivität tritt ein, wenn ein Ticket einem bestimmten Agent zur Bearbeitung zugewiesen wird. Sie wird ausdrücklich im Audit-Verlauf des Tickets protokolliert und zeigt an, dass eine Person die Verantwortung übernommen hat.
Warum das wichtig ist Dieser Meilenstein ist wichtig, um die Zeit bis zur ersten Zuweisung zu messen. Er bildet außerdem die Grundlage für die Analyse von Übergaben, Nacharbeit und Erstlösungsquoten. Woher beziehen Wird im Ticket-Audit-Log erfasst, wenn das Feld 'assignee_id' ausgefüllt oder geändert wird. Die erste Zuweisung ist ein wichtiger Meilenstein für die Berechnung von KPIs. Erfassung Erkennbar an einem „Change“-Ereignis für das Feld 'assignee_id' im Ticket-Audit-Log. Ereignistyp explicit
	Ticket neu zugewiesen	Tritt ein, wenn die Zuständigkeit für ein Ticket nach der Erstzuweisung von einem Agent oder einer Gruppe auf einen anderen Agent oder eine andere Gruppe übertragen wird. Dieses Ereignis wird ausdrücklich im Audit-Verlauf des Tickets erfasst.
Warum das wichtig ist Neuzuweisungen sind wichtig für die Analyse von Übergaben und Nacharbeit. Häufige Neuzuweisungen deuten oft auf eine falsche Erstzuweisung, komplexe Probleme oder Engpässe im Prozess hin. Woher beziehen Wird im Ticket-Audit-Log anhand eines „Change“-Ereignisses für das Feld 'assignee_id' oder 'group_id' ermittelt, nachdem das Feld erstmals ausgefüllt wurde. Erfassung Erkennbar an einem späteren „Change“-Ereignis für das Feld 'assignee_id' oder 'group_id'. Ereignistyp explicit
	Vorfall erstellt	Kennzeichnet den Beginn des Vorfalllebenszyklus, wenn in Zendesk ein neues Ticket erstellt wird. Dieses Ereignis wird ausdrücklich im Audit Log zur Ticketerstellung erfasst und bildet den Startpunkt jedes Falls.
Warum das wichtig ist Dies ist die zentrale Startaktivität. Die Zeitspanne von diesem Ereignis bis zu anderen Ereignissen ist wichtig, um die gesamte Ticketlaufzeit und die Reaktionszeit zu Beginn zu messen. Woher beziehen 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 angelegt. Erfassung Direkt aus dem Ereignis zur Ticketerstellung im Audit Log. Ereignistyp explicit
	Vorfall gelöst	Dieser wichtige Meilenstein tritt ein, wenn ein Agent eine Lösung umgesetzt und das Ticket als 'solved' markiert hat. Die Aktion wird ausdrücklich als Statusänderung im Ticket-Audit-Log erfasst.
Warum das wichtig ist Dies ist die zentrale Aktivität zur Lösung und ein wichtiger Messpunkt für die Lösungszeit. Die Zeit zwischen diesem Ereignis und „Vorfall geschlossen“ entspricht dem Zeitraum für die Benutzerbestätigung oder die automatische Schließung. Woher beziehen Wird im Ticket-Audit-Log über ein „Change“-Ereignis erfasst, bei dem der neue Wert des Feldes 'status' 'solved' ist. Erfassung Erkennbar an einem „Change“-Ereignis, bei dem das Feld 'status' auf 'solved' gesetzt wird. Ereignistyp explicit
	Vorfall geschlossen	Kennzeichnet das endgültige Ende des Vorfalllebenszyklus, wenn das Ticket dauerhaft geschlossen wird. In Zendesk geschieht dies häufig automatisch nach einer festgelegten Zeitspanne ab dem Status 'solved' und wird als abschließende Statusänderung erfasst.
Warum das wichtig ist Dies ist die abschließende Aktivität des Prozesses. Die Gesamtdauer wird vom Ereignis „Vorfall erstellt“ bis zu diesem Ereignis berechnet und zeigt die Zykluszeit von Anfang bis Ende. Woher beziehen Wird im Ticket-Audit-Log über ein „Change“-Ereignis erfasst, bei dem der neue Wert des Feldes 'status' 'closed' ist. Erfassung Erkennbar an einem „Change“-Ereignis, bei dem das Feld 'status' auf 'closed' gesetzt wird. Ereignistyp explicit
	Benutzerzufriedenheit bewertet	Beschreibt den Zeitpunkt, an dem der Endbenutzer die erhaltene Unterstützung bewertet. Dieses Ereignis wird in Zendesk ausdrücklich erfasst, nachdem ein Ticket gelöst wurde.
Warum das wichtig ist Die Analyse der Zufriedenheitsbewertungen liefert wichtiges Feedback zur Leistung der Agents und zur Wirksamkeit des Prozesses. So lassen sich Prozesskennzahlen mit den Ergebnissen für Kunden verknüpfen. Woher beziehen Wird aus den mit dem Ticket verknüpften Zufriedenheitsbewertungen ermittelt. Diese umfassen üblicherweise eine Bewertung ('good' oder 'bad') und einen optionalen Kommentar. Erfassung Wird protokolliert, wenn 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, bei denen Zusammenarbeit erforderlich ist. Eine übermäßig hohe Zahl kann jedoch auf Wissenslücken oder Ineffizienzen im Prozess hindeuten. Woher beziehen Wird aus den Ticket-Kommentardaten ermittelt. Ein Kommentar gilt als interne Notiz, wenn sein Attribut 'public' den Wert false hat. Erfassung Wird protokolliert, wenn dem Ticket ein neuer Kommentar mit 'public: false' hinzugefügt wird. Ereignistyp explicit
	Öffentliche Antwort gesendet	Beschreibt eine Mitteilung eines Support-Agents an den Endbenutzer. In Zendesk wird dieses Ereignis ausdrücklich erfasst, sobald ein öffentlicher Kommentar zum Ticket hinzugefügt wird.
Warum das wichtig ist Die Erfassung öffentlicher Antworten ist wichtig, um die Häufigkeit der Kommunikation zu verstehen. Sie kann außerdem ein wichtiger Bestandteil des zeitlichen Verlaufs sein, wenn Verzögerungen bei der Bestätigung durch Benutzer analysiert werden. Woher beziehen Wird aus den Ticket-Kommentardaten ermittelt. Ein Kommentar gilt als öffentlich, wenn sein Attribut 'public' den Wert true hat. Erfassung Wird protokolliert, wenn dem Ticket ein neuer Kommentar mit 'public: true' hinzugefügt wird. Ereignistyp explicit
	Priorität festgelegt	Die Prioritätsstufe eines Vorfalls, zum Beispiel Niedrig, Normal, Hoch oder Dringend, 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 Für das Dashboard „Kennzahlen zur Priorisierungseffektivität“ ist es wichtig nachzuverfolgen, wann und wie die Priorität festgelegt wird. So können kritische Probleme zeitnah bearbeitet werden. Woher beziehen Wird als „Change“-Ereignis für das Feld 'priority' im Ticket-Audit-Log erfasst. Auch spätere Änderungen lassen sich nachverfolgen, um die KPI zur Häufigkeit von Prioritätsänderungen zu messen. Erfassung Erkennbar an einem „Change“-Ereignis für das Feld 'priority' im Ticket-Audit-Log. Ereignistyp explicit
	SLA-Ziel verfehlt	Kennzeichnet den Zeitpunkt, an dem ein Ticket eine festgelegte Service-Level-Vereinbarung nicht erfüllt, etwa bei der Zeit bis zur ersten Antwort oder bis zur Lösung. Das Ereignis wird anhand der SLA-Richtliniendefinitionen und der Zeitstempel der Ticketaktualisierungen berechnet.
Warum das wichtig ist Dieses Ereignis unterstützt direkt die Überwachung der SLA-Einhaltung. Zu erkennen, wann und warum Verstöße auftreten, ist entscheidend, um die Zuverlässigkeit des Service und das Vertrauen der Kunden zu stärken. Woher beziehen Dieses Ereignis wird berechnet. Es lässt sich aus den mit einem Ticket verknüpften Daten zu 'sla_policy_metrics' ableiten, wobei für jedes SLA-Ziel der Timestamp 'breached_at' verwendet wird. Erfassung Abgeleitet aus dem Timestamp 'breached_at' in den SLA-Kennzahlendaten des Tickets. Ereignistyp calculated
	Status auf „Pending“ geändert	Zeigt an, dass der Prozess pausiert, während auf eine Antwort der anfragenden Person gewartet wird. Das Ereignis wird daraus abgeleitet, dass sich das Feld 'status' des Tickets zu 'pending' ändert.
Warum das wichtig ist Diese Aktivität ist entscheidend für die Berechnung der Wartezeit auf eine Benutzerbestätigung. Lange Verweildauern in diesem Status können die gesamte Lösungszeit deutlich erhöhen und auf Verzögerungen in der Kommunikation hinweisen. Woher beziehen Wird aus dem Ticket-Audit-Log abgeleitet, indem ein „Change“-Ereignis ermittelt wird, bei dem der neue Wert des Feldes 'status' 'pending' ist. Erfassung Abgeleitet aus einer Änderung des Statusfelds zu 'pending'. Ereignistyp inferred
	Ticket einer Gruppe zugewiesen	Beschreibt die erste Weiterleitung oder Triage eines Vorfalls an eine bestimmte Supportgruppe. Dies ist üblicherweise der erste Schritt bei der Zuweisung der Verantwortung und wird als ausdrückliches Änderungsereignis im Audit-Verlauf des Tickets erfasst.
Warum das wichtig ist Die Erfassung von Gruppenzuweisungen hilft dabei, die Effizienz der ersten Triage zu beurteilen und Verzögerungen zu erkennen, bevor ein Ticket beim zuständigen Team landet. Woher beziehen Wird im Ticket-Audit-Log erfasst, sobald das Feld 'group_id' gesetzt oder geändert wird. Die erste Änderung nach der Ticketerstellung gilt als Erstzuweisung. Erfassung Erkennbar an einem „Change“-Ereignis für das Feld 'group_id' im Ticket-Audit-Log. Ereignistyp explicit

Anleitungen zur Datenextraktion

So exportieren 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 Berechtigung verfügt, Berichte in Zendesk Explore zu erstellen und zu verwalten.
Neuen Bericht erstellen: Öffnen Sie das Explore-Modul. Klicken Sie in der linken Navigationsleiste auf das Symbol „Reports“ und anschließend auf „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 aller Ticketänderungen und ist daher für die Erstellung eines Event Logs unverzichtbar.
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 angegebenen Formeln exakt.
Berichtsspalten anpassen: Fügen Sie die neu erstellten berechneten Attribute (ActivityName, SourceSystem, LastDataUpdate) zum Bereich „Rows“ hinzu. Anschließend können Sie die Rohdatenfelder entfernen, die zur Erstellung von ActivityName verwendet wurden (Changes - Field name, Changes - Previous value, Changes - New value, Comment public), um die Ansicht übersichtlicher zu gestalten.
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 einen weiteren Filter für das berechnete Attribut ActivityName hinzu und schließen Sie Nullwerte aus. So entfernen Sie Ticketänderungen, die keiner gewünschten Aktivität entsprechen.
Bericht ausführen und prüfen: Zendesk Explore aktualisiert den Bericht automatisch, wenn 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 Ereignis enthalten.
Daten als CSV exportieren: Klicken Sie nach Fertigstellung 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. Achten Sie darauf, dass die Zeitstempel dem ISO-8601-Format entsprechen. Die Datei ist nun bereit für den Upload.

Konfiguration

Zendesk-Datensatz: Der Bericht muss auf dem Datensatz Support: Ticket updates [default] basieren. Nur dieser Standarddatensatz enthält den detaillierten Prüfpfad, der erforderlich ist, um den Prozess Ereignis für Ereignis zu rekonstruieren.
Filter für den Datumsbereich: Begrenzen Sie das Datenvolumen unbedingt mit einem Datumsfilter. Verwenden Sie dafür primär das Attribut Update - Date. 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 im Bericht Zeilen mit einem Nullwert für dieses Attribut ausschließen. Dadurch werden nicht relevante Ticketänderungen, etwa Systemaktualisierungen oder Tag-Änderungen, aus dem Event Log entfernt.
Berechnete Attribute: Für die Extraktion werden Rohdatenänderungen an Ticketfeldern mithilfe eines Standardattributs in verständliche Aktivitätsnamen übersetzt. Die Formel muss präzise sein.
Voraussetzungen: Der Benutzer, der den Bericht ausführt, benötigt in Zendesk Explore mindestens die Rolle „Viewer“. Zum Erstellen und Speichern des Berichts sind die Berechtigungen „Editor“ oder „Admin“ erforderlich.

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 diese 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 Abschnitt „API Tokens“ ein neues aktives API-Token hinzu und speichern Sie den generierten Token sicher.
Python-Skript konfigurieren: Erstellen Sie eine Python-Datei, zum Beispiel extract_zendesk_logs.py, und kopieren Sie das bereitgestellte Skript hinein. Ersetzen Sie die Platzhaltervariablen am Anfang des Skripts durch Ihre Zugangsdaten: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL und ZENDESK_API_TOKEN. Legen Sie mit START_TIMESTAMP den Beginn des gewünschten Extraktionszeitraums fest. Verwenden Sie dafür einen Unix-Epoch-Zeitstempel.
API-Endpunkte verstehen: Das Skript verwendet hauptsächlich zwei Zendesk-API-Endpunkte. Über incremental/tickets/cursor.json werden effizient alle Tickets abgerufen, die seit START_TIMESTAMP aktualisiert wurden. Für jedes Ticket ruft das Skript anschließend tickets/{ticket_id}/audits.json auf, um den detaillierten Verlauf aller Änderungen und Ereignisse abzurufen.
Skript ausführen: Starten Sie das Skript im Terminal mit dem Befehl python extract_zendesk_logs.py. Das Skript beginnt daraufhin, Daten über die Zendesk-API abzurufen.
Fortschritt überwachen: Das Skript gibt in der Konsole die Anzahl der verarbeiteten Tickets aus, sodass Sie den Fortschritt verfolgen können. Je nach Zeitraum und Ticketvolumen kann die Ausführung 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 enthaltenen after_url, bis alle Tickets des Zeitraums abgerufen wurden.
Ereignisse umwandeln: Für jedes Ticket durchläuft das Skript den Prüfverlauf. Es analysiert die einzelnen Prüfereignisse und ordnet interne Zendesk-Ereignistypen 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, die SLA-Kennzahlen für jedes gelöste Ticket abruft. Das ist erforderlich, weil SLA-Verletzungen keine Standardereignisse im Prüfprotokoll sind. Die Funktion führt einen zusätzlichen API-Aufruf aus, um Details zur Anwendung der SLA-Richtlinie abzurufen.
Event Log erstellen: Nachdem alle Tickets verarbeitet wurden, fasst das Skript die extrahierten Ereignisse in einem pandas DataFrame zusammen und speichert das fertige Event Log als CSV-Datei mit dem Namen zendesk_incident_event_log.csv im Verzeichnis, aus dem das Skript ausgeführt wurde.
Upload vorbereiten: Prüfen Sie die erstellte CSV-Datei auf Richtigkeit. Sie liegt nun im erforderlichen Format vor und kann direkt zur Analyse in ProcessMind hochgeladen werden.

Konfiguration

Zendesk-API-Zugangsdaten: Sie benötigen Ihre Zendesk-Subdomain, die E-Mail-Adresse eines Administrators oder Agenten sowie ein gültiges API-Token. Bewahren Sie diese Zugangsdaten sicher auf und hinterlegen Sie sie in produktiven Skripten nicht direkt im versionsverwalteten Code.
Startzeitstempel (START_TIMESTAMP): Dieser ganzzahlige Wert legt den Beginn der Datenextraktion fest und muss ein Unix-Epoch-Zeitstempel sein. Als Startpunkt empfiehlt sich ein Zeitpunkt drei bis sechs Monate in der Vergangenheit. So erhalten Sie eine aussagekräftige Datenmenge, ohne das System zu überlasten. Mit einem Online-Konverter können Sie den passenden Zeitstempel für ein bestimmtes Datum ermitteln.
API-Ratenbegrenzung: Das Skript führt zahlreiche API-Aufrufe aus. Zendesk setzt je nach Tarif unterschiedliche Ratenbegrenzungen durch. Für mittlere 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 nicht zu überschreiten und einen 429-Fehler zu vermeiden.
Erforderliche Python-Bibliotheken: Das Skript benötigt requests für API-Aufrufe und pandas für die Datenverarbeitung und den CSV-Export. Stellen Sie sicher, dass beide Bibliotheken in Ihrer Python-Umgebung installiert sind.
Benutzerberechtigungen: Das Benutzerkonto zum API-Token muss über ausreichende Berechtigungen verfügen, um Ticketdaten einschließlich Prüfverläufen und Ticketkennzahlen zu lesen.

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 Leseberechtigung für Tickets, Ticketprüfverläufe, Benutzer, Gruppen, Zufriedenheitsbewertungen und inkrementelle Exporte. Verwenden Sie ein API-Token oder OAuth-Zugangsdaten, die für Ihre Zendesk-Support-Instanz eingerichtet wurden. Speichern Sie die Subdomain, die Zugangsdaten und den Extraktions-Wasserstand als sichere Konfigurationswerte.
Rufen Sie mit der Zendesk Incremental Ticket Export API die Tickets ab, die nach dem letzten erfolgreichen Wasserstand aktualisiert wurden. Das folgende Skript verwendet das dokumentierte Endpunktmuster https://[Your Zendesk subdomain].zendesk.com/api/v2/incremental/tickets/cursor.json und durchläuft die Cursor-Seitennavigation, bis die API meldet, dass alle Ergebnisse abgerufen wurden.
Rufen Sie für jedes zurückgegebene Ticket den Prüfverlauf über den Ticket-Audits-Endpunkt ab. Diese Prüfdatensätze sind erforderlich, da ProcessMind das Event Log unverändert einliest und Aktivitäten nicht aus dem endgültigen Ticketstatus ableitet. Bewahren Sie den Zeitstempel der Prüfung, den Akteur, die Ticketkennung und die Prüfereignisse auf.
Wandeln Sie Prüfereignisse in einzelne Ereigniszeilen um. Erfassen Sie die 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, sofern sie verfügbar sind. Berechnen Sie SLA-Verletzungen nur, wenn das erforderliche SLA-Ziel und die Ereigniszeitstempel vorliegen, und dokumentieren Sie die Berechnungsgrundlage.
Speichern Sie den zuletzt erfolgreich verarbeiteten Aktualisierungszeitstempel oder Cursor. Aktualisieren Sie den Wasserstand erst, wenn alle Seiten, Ticketprüfverläufe und optionalen Zufriedenheitsdatensätze erfolgreich geschrieben wurden. Verwenden Sie beim ersten Durchlauf einen begrenzten Startzeitpunkt wie [Start date in ISO 8601 format], in der Regel für einen Zeitraum von drei bis sechs Monaten.
Befüllen Sie die erforderlichen Spalten TicketId, ActivityName, EventTimestamp, SourceSystem und LastDataUpdate. Befüllen Sie die empfohlenen Spalten TicketStatus, Assignee, AssignedGroup, TicketPriority, Channel, SlaStatus und EventEndTime, sofern die Quelldaten dies ermöglichen. Verwenden Sie nur dann leere Werte, wenn Zendesk das Attribut für das Ereignis nicht bereitstellt.
Entfernen Sie Duplikate anhand von TicketId, ActivityName, EventTimestamp und, sofern verfügbar, einer stabilen Quellereigniskennung. 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. Verwenden Sie Zeitstempel im ISO-8601-Format mit explizitem UTC-Offset, einen einheitlichen Datentyp für TicketId, exakt die dokumentierten Aktivitätsnamen für ActivityName und denselben Wert für LastDataUpdate in allen Zeilen eines Extraktionslaufs.
Laden Sie das Event Log in ProcessMind hoch und konfigurieren Sie Incident ID als Fallkennung, Activity als Aktivitätsspalte und Event Timestamp als Ereigniszeitspalte. Prüfen Sie, ob jede erforderliche Aktivität als eigene Zeile enthalten ist und nicht erst bei der Visualisierung abgeleitet wird.

Konfiguration

API-Methode: Zendesk Incremental Ticket Export API mit Cursor-Seitennavigation. Verwenden Sie für die ereignisbezogene Extraktion den Ticket-Audits-Endpunkt und bei aktivierten und zugänglichen Zufriedenheitsbewertungen den entsprechenden Zufriedenheits-Endpunkt.
Erforderliche Konfiguration: Zendesk-Subdomain, API-Authentifizierung, anfängliches Startdatum, Extraktions-Wasserstand, Zeitlimit für Anfragen, Wiederholungsrichtlinie und Speicherort der Ausgabe. Ersetzen Sie [Your Zendesk subdomain], [Your API email] und [Your API token] durch sichere Werte für die Bereitstellung.
Datumsbereich: Verwenden Sie beim ersten Laden drei bis sechs Monate, sofern kein längerer Verlauf erforderlich ist. Rufen Sie bei wiederkehrenden Ladevorgängen Datensätze nach dem letzten erfolgreichen Wasserstand ab und berücksichtigen Sie ein kurzes Überlappungsfenster für verspätete Aktualisierungen. Entfernen Sie anschließend Duplikate.
Filter: Wenden Sie Filter für Unternehmen, Marken, Gruppen, Organisationen, Ticketformulare, Kanäle oder benutzerdefinierte Felder nur an, wenn sie für den Prozessumfang ausdrücklich erforderlich sind. Zendesk Support verwendet keine Filter für SAP-typische Buchungskreise oder Belegarten, sofern diese Konzepte nicht durch konfigurierte Zendesk-Felder abgebildet werden.
Ereignissemantik: Behandeln Sie Prüfereignisse als maßgebliche Quelle für explizite Änderungen. Erstellen Sie kein Statusänderungsereignis allein deshalb, weil das aktuelle Ticket einen Statuswert hat. Ein Statusereignis muss aus einem Prüfereignis oder einer anderen dokumentierten Ereignisquelle stammen.
SLA-Konfiguration: Für die Feststellung einer SLA-Verletzung benötigen Sie Zugriff auf die geltende SLA-Richtlinie, die Zieldauer, den Geschäftskalender und die erforderlichen Zeitstempel. Wenn Zendesk ein Verletzungsereignis oder eine entsprechende Kennzahl bereitstellt, verwenden Sie diese Quelle. Berechnen Sie die Verletzung andernfalls nur anhand dokumentierter Richtliniendaten und halten Sie die Berechnungsgrundlage fest.
Konfiguration der Zufriedenheitsbewertung: Für User Satisfaction Rated müssen Zufriedenheitsbewertungen aktiviert und der Bewertungsdatensatz über die API zugänglich sein. Ein gelöstes Ticket ohne Bewertung darf kein künstlich erzeugtes Bewertungsereignis erhalten.
Leistung: Verwenden Sie Cursor-Seitennavigation, eine begrenzte Parallelisierung der Ticket-Audit-Anfragen, wiederverwendete Verbindungen, exponentielle Wartezeiten bei Ratenbegrenzungen und Prüfpunkte nach erfolgreichen Stapeln. Rufen Sie nicht bei jedem Durchlauf erneut alle Ticketprüfverläufe ab.
Vollständigkeit: Inkrementelle Exporte können Tickets enthalten, die nach dem angefragten Zeitpunkt aktualisiert wurden. Der Abruf von Prüfverläufen und verspätete Aktualisierungen müssen jedoch separat berücksichtigt werden. Verwenden Sie ein Überlappungsfenster und stabile Schlüssel zur Duplikaterkennung.
Voraussetzungen: API-Zugriff, Leseberechtigung für Tickets und Prüfverläufe, Zugriff auf Benutzer und Gruppen zur Namensauflösung sowie Zugriff auf Zufriedenheits- und SLA-Daten, sofern erforderlich. Welche Prüfereignistypen verfügbar sind, hängt von der Zendesk-Konfiguration und dem Abonnement ab.

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 Datenintegrations-Tool mit einem geprüften Zendesk-Support-Konnektor, der Ticketprüfverläufe und Kommentare extrahieren und Daten in Ihr Ziel-Warehouse oder Dateisystem schreiben kann. Prüfen Sie, ob der Konnektor inkrementelle Extraktion, Seitennavigation, den Umgang mit Ratenbegrenzungen und die Übernahme von Quellzeitstempeln unterstützt.
Richten Sie im ausgewählten Tool die Zendesk-Verbindung ein. Geben Sie über die Konfigurationsoberfläche des Tools die Zendesk-Subdomain, die Authentifizierungsmethode, Zugangsdaten oder ein Token sowie alle erforderlichen Verbindungseinstellungen ein. Gewähren Sie Zugriff auf Tickets, Ticketprüfverläufe, Kommentare, Benutzer, Gruppen, Zufriedenheitsbewertungen und SLA-Daten, sofern diese Objekte in Ihrem Zendesk-Tarif und im Konnektor verfügbar sind.
Legen Sie den Extraktionszeitraum fest. Verwenden Sie für den ersten Ladevorgang einen rollierenden Zeitraum von drei bis sechs Monaten. Richten Sie anschließend inkrementelle Ladevorgänge anhand des vom Konnektor unterstützten Aktualisierungs- oder Prüfzeitstempels ein. Speichern Sie den letzten erfolgreichen Extraktions-Wasserstand außerhalb des Event Logs, damit spätere Durchläufe keine Ereignisse doppelt erfassen oder auslassen.
Extrahieren Sie die Ticketdaten, die für den Fallkontext erforderlich sind, darunter Ticketkennung, aktueller oder ereignisbezogener Status, zuständiger Agent, Gruppe, Priorität, Meldekanal, SLA-Status und relevante Aktualisierungszeitstempel. Extrahieren Sie auch die Ticketprüfverläufe, da Zuweisungen, Prioritäts- und Statusänderungen sowie andere Feldänderungen als eigene Ereigniszeilen erfasst werden müssen.
Extrahieren Sie die Ticketkommentare und unterscheiden Sie anhand des Kennzeichens für Öffentlichkeit oder Sichtbarkeit zwischen öffentlichen Kommentaren und internen Notizen. Erfassen Sie Kommentarzeitstempel, Ticketkennungen, Autorenkennungen sowie verfügbare End- oder Abschlusszeitstempel. 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-Verletzungsereignisse nicht direkt bereitstellt, konfigurieren Sie im ETL-Tool eine Berechnung anhand der verfügbaren SLA-Ziele, Richtlinien, Geschäftszeiten und Ticketereigniszeitstempel. Erstellen Sie nur dann eine Zeile für eine Verletzung, wenn die Quelldaten oder die konfigurierte Berechnung belegen, dass das Ziel überschritten wurde.
Überführen Sie die extrahierten Quelldatensätze in ein normalisiertes Event Log. Erstellen Sie für jedes explizite Aktivitätsvorkommen eine Zeile. 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 entsprechenden Statusaktivität, Kommentare Public Reply Sent oder Internal Note Added, den Status „solved“ Incident Resolved, Zufriedenheitsbewertungen User Satisfaction Rated und den Status „closed“ Incident Closed.
Wenden Sie die Regeln zur Ereignisklassifizierung in einer festgelegten Reihenfolge an. Verwenden Sie, sofern verfügbar, die vorherigen und neuen Werte aus dem Prüfverlauf. Klassifizieren Sie die erste Gruppenzuweisung als Ticket Assigned to Group, die erste Agentenzuweisung als Ticket Assigned to Agent und spätere Änderungen der Zuständigkeit als Ticket Reassigned. Erstellen Sie für jede zutreffende Änderung eine Zeile, nicht nur für den letzten Ticketstatus.
Befüllen Sie die erforderlichen Spalten TicketId, ActivityName, EventTimestamp, SourceSystem und LastDataUpdate. Befüllen Sie die empfohlenen Spalten TicketStatus, Assignee, AssignedGroup, TicketPriority, Channel, SlaStatus und EventEndTime anhand des Ereigniskontexts oder des nächstliegenden gültigen Quelldatensatzes. Verwenden Sie für Quellzeitstempel eine einheitliche Zeitzone, vorzugsweise UTC, und erhalten Sie die vom Konnektor unterstützte ursprüngliche Genauigkeit.
Prüfen Sie die umgewandelten Daten: Jede TicketId muss eine Zeile mit Incident Created enthalten. Ereigniszeitstempel müssen, sofern zutreffend, im Extraktionszeitraum liegen. Alle 13 erforderlichen Aktivitätsnamen müssen enthalten sein, wenn Quelldaten dafür vorliegen. Behandeln Sie doppelte Ereignisschlüssel anhand der Quellprüfkennung oder eines dokumentierten zusammengesetzten Schlüssels.
Schreiben Sie das Event Log im ProcessMind-kompatiblen Tabellenformat in die Zieltabelle oder Datei, zum Beispiel als CSV oder in einem unterstützten Warehouse-Konnektorformat. Verwenden Sie eine Kopfzeile, stabile Spaltennamen, UTF-8-Kodierung, ISO-8601-Zeitstempel und keine verschachtelten JSON-Daten in den endgültigen Ereignisspalten. Laden Sie das Event Log in ProcessMind hoch oder verbinden Sie es damit. Verlassen Sie sich nicht auf abgeleitete Aktivitäten, da ProcessMind die extrahierten Zeilen unverändert einliest.

Konfiguration

Konnektor und Lizenz: Verwenden Sie ein kommerzielles ETL- oder Datenintegrations-Tool mit einem Zendesk-Support-Konnektor, der Tickets, Ticketprüfverläufe, Kommentare, Benutzer, Gruppen, Zufriedenheitsbewertungen und SLA-Informationen gemäß Zendesk-Tarif und Konnektorversion bereitstellt.
Authentifizierung und Autorisierung: Richten Sie die Zendesk-Subdomain und eine genehmigte Authentifizierungsmethode ein. Gewähren Sie nur die Berechtigungen, die für die Extraktion von Tickets, Prüfverläufen, Kommentaren, Benutzern, Gruppen, Zufriedenheitsbewertungen und SLA-Daten erforderlich sind. Stellen Sie sicher, dass das Integrationskonto historische Datensätze lesen kann.
Datumsbereich: Beginnen Sie mit drei bis sechs Monaten für die Validierung und den ersten Ladevorgang. Erweitern Sie den Zeitraum erst, nachdem Sie Zeilenanzahl, Seitennavigation und Verhalten bei Ratenbegrenzungen geprüft haben. Verwenden Sie für geplante Durchläufe einen inkrementellen Wasserstand.
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 keine Filter für Buchungskreis oder Belegart, sofern diese Felder nicht im konfigurierten Zendesk-Datenmodell vorhanden sind.
Prüfverlauf: Aktivieren Sie die Extraktion von Ticketprüfereignissen und speichern Sie, sofern verfügbar, die Quellprüfkennung, um Duplikate bei inkrementellen Ladevorgängen zu vermeiden.
Kommentare: Extrahieren Sie öffentliche und private Kommentare. Verwenden Sie das Quellkennzeichen für die Sichtbarkeit, 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 Gruppen- oder Agentenwerte. Klassifizieren Sie die erste zutreffende Zuweisung separat und erfassen Sie spätere Änderungen der Zuständigkeit als Ticket Reassigned.
Klassifizierung von Statusänderungen: Erstellen Sie Zeilen nur für explizite Statusübergänge. Ordnen Sie die Werte „new“, „open“, „pending“, „solved“ und „closed“ dem konfigurierten Zendesk-Statusmodell zu. Dokumentieren Sie die Zuordnung, bevor Sie benutzerdefinierte Statuswerte laden.
SLA-Verarbeitung: Verwenden Sie bevorzugt SLA-Verletzungsereignisse aus der Quelle. Falls diese nicht verfügbar sind, richten Sie eine dokumentierte Berechnung anhand der verfügbaren SLA-Ziele, Richtlinien, Geschäftszeiten und Ereigniszeitstempel ein. Halten Sie die Berechnungsgrundlage in den ETL-Metadaten fest, statt Quellfelder zu erfinden.
Zeitstempelverarbeitung: Vereinheitlichen Sie EventTimestamp und EventEndTime auf UTC oder eine andere dokumentierte Zeitzone. Bewahren Sie den Quellzeitstempel auf und ersetzen Sie die Ereigniszeit nicht durch den Extraktionszeitpunkt.
LastDataUpdate: Setzen Sie LastDataUpdate auf den Zeitstempel der erfolgreichen ETL-Aktualisierung. Verwenden Sie für alle Zeilen dieses Ladevorgangs denselben Wert.
Leistung: Verwenden Sie Seitennavigation, inkrementelle Extraktion, Partitionierung nach Ticketaktualisierungs- oder Prüfzeitstempel, kontrollierte Parallelisierung, Wiederholungsversuche und Wartezeiten bei Ratenbegrenzungen. Extrahieren Sie nicht bei jedem geplanten Durchlauf erneut den gesamten Ticketverlauf.
Zielschema: Richten Sie eine flache Ereignistabelle oder Datei mit den erforderlichen Spalten TicketId, ActivityName, EventTimestamp, SourceSystem und LastDataUpdate sowie den verfügbaren empfohlenen Attributen ein.
Verhalten von ProcessMind: Verlassen Sie sich nicht darauf, dass ProcessMind Statusänderungen, Zuweisungen, Antworten, Notizen, SLA-Verletzungen oder Meilensteine des Prozesslebenszyklus ableitet. Jede Aktivität muss bereits vor dem Upload als Ereigniszeile vorliegen.

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 loslegen?

Mit diesem Template vereinfachen Sie die Datenaufbereitung und gewinnen aussagekräftige Erkenntnisse zur Leistung Ihres Vorfallmanagements. Beginnen Sie noch heute mit der Prozessoptimierung.

Zurück zum Leitfaden zur Prozessverbesserung

Template herunterladen

Optimieren Sie Ihr Vorfallmanagement und lösen Sie Vorfälle noch heute schneller

Senken Sie die MTTR um 35 %, vermeiden Sie wiederkehrende Vorfälle und steigern Sie die Zufriedenheit.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. Beginnen Sie in wenigen Minuten mit der Verbesserung Ihrer Prozesse.

Ihr Daten-Template für das Vorfallmanagement

Ihr Daten-Template für das Vorfallmanagement

Attribute des Vorfallmanagements

Aktivitäten im Vorfallmanagement

Anleitungen zur Datenextraktion

Zendesk Explore: Bericht über die Benutzeroberfläche als CSV-Datei exportieren

Schritte

Konfiguration

Beispielabfrage config

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

Schritte

Konfiguration

Beispielabfrage python

Zendesk Incremental Export API für den Massendatenabgleich

Schritte

Konfiguration

Beispielabfrage python

ETL-Tool eines Drittanbieters mit Zendesk-API-Konnektor

Schritte

Konfiguration

Beispielabfrage config

Möchten Sie loslegen?

Optimieren Sie Ihr Vorfallmanagement und lösen Sie Vorfälle noch heute schneller