> Kontinuierliche Prozessverbesserung > Service Request Management > Zendesk Support > Daten Template

Ihr Daten-Template für das Management von Serviceanfragen

Zendesk Support

← Zurück zum Leitfaden zur Prozessverbesserung

Attribute für das Management von Serviceanfragen (21) Aktivitäten im Management von Serviceanfragen (13) Anleitungen zur Datenextraktion (3)

Ihr Daten-Template für das Management von Serviceanfragen

Dieses Template zeigt Ihnen, wie Sie die erforderlichen Daten für die Analyse Ihres Serviceanfragenprozesses in Zendesk Support extrahieren. Es beschreibt die wichtigsten zu erfassenden Datenattribute und Aktivitäten und erklärt, wie Sie die Informationen direkt aus Ihrem System abrufen. Verwenden Sie diese Anleitung, um ein aussagekräftiges Event Log für Ihre Process-Mining-Initiativen zu erstellen.

Empfohlene Attribute für eine umfassende Analyse
Wichtige Aktivitäten bei Serviceanfragen, die Sie erfassen sollten
Anleitung zur Extraktion von Zendesk-Support-Daten

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

Template herunterladen

Attribute für das Management von Serviceanfragen

Diese empfohlenen Datenfelder sollten Sie in Ihr Event Log aufnehmen, um das Management von Serviceanfragen in Zendesk Support umfassend zu analysieren.

5 Erforderlich 7 Empfohlen 9 Optional

	Name	Beschreibung
	Aktivität ActivityName	Die Bezeichnung der geschäftlichen Aktivität oder des Ereignisses, das bei einer Serviceanfrage eingetreten ist.
Beschreibung Die Aktivität bezeichnet einen einzelnen Schritt oder ein Ereignis im Lebenszyklus einer Serviceanfrage, etwa „Serviceanfrage erstellt“, „Anfrage einem Agenten zugewiesen“ oder „Serviceanfrage gelöst“. Diese Aktivitäten werden aus Änderungen im Auditprotokoll des Zendesk-Tickets abgeleitet. Das Protokoll erfasst Änderungen an Feldern wie Status, zuständigem Agenten und Priorität sowie hinzugefügte Kommentare. Die Analyse von Aktivitäten bildet den Kern von Process Mining. Sie ermöglicht die Visualisierung der Prozesslandkarte, das Erkennen von Engpässen zwischen Schritten und die Analyse von Nacharbeitsschleifen. Anhand der Reihenfolge und Häufigkeit von Aktivitäten können Unternehmen ineffiziente Abläufe und Möglichkeiten zur Prozessverbesserung erkennen. Warum das wichtig ist Dieses Attribut legt die Prozessschritte fest und ermöglicht die Visualisierung von Prozesslandkarten sowie die Analyse von Prozessabläufen, Varianten und Konformität. Woher beziehen Dieses Attribut wird konzeptionell aus Events der Zendesk Ticket Audits API abgeleitet. Eine Änderung des Felds „status“ von „new“ zu „open“ kann beispielsweise der Aktivität „Anfrage geprüft“ zugeordnet werden. Beispiele Serviceanfrage erstelltAgent neu zugewiesenServiceanfrage gelöst
	ID der Serviceanfrage ServiceRequestId	Die eindeutige Kennung jedes Serviceanfragetickets in Zendesk.
Beschreibung Die ID der Serviceanfrage, in Zendesk häufig Ticket-ID genannt, ist der Primärschlüssel für jeden Case. Sie verknüpft alle zugehörigen Aktivitäten, Kommentare und Statusänderungen vom Erstellen bis zum Schließen der Anfrage. So lässt sich der gesamte Verlauf einer einzelnen Anfrage nachvollziehen. Dieses Attribut ist grundlegend für die Process-Mining-Analyse. Es definiert den Case und ermöglicht es, Prozessabläufe zu rekonstruieren, Varianten zu erkennen und Kennzahlen auf Case-Ebene wie die Zykluszeit zu berechnen. Jedes Event im Datensatz muss einer ID der Serviceanfrage zugeordnet sein, damit es im Kontext des Gesamtprozesses ausgewertet werden kann. Warum das wichtig ist Diese zentrale Case-Kennung verknüpft alle Events im Verlauf einer Serviceanfrage und ermöglicht so die Analyse des gesamten Prozesses. Woher beziehen Zendesk Tickets API, Feld „id“. Beispiele 102451024610247
	Startzeit EventTimestamp	Das genaue Datum und die Uhrzeit, zu denen die Aktivität stattgefunden hat.
Beschreibung Der Event-Timestamp, auch Startzeit genannt, erfasst den genauen Zeitpunkt einer Aktivität. Er zeigt beispielsweise, wann ein Agent zugewiesen, eine öffentliche Antwort gesendet oder der Ticketstatus auf „Resolved“ gesetzt wurde. Die Zeitangaben stammen aus dem Auditprotokoll des jeweiligen Zendesk-Tickets. Dieses Attribut ist für jede zeitbasierte Analyse entscheidend. Es ordnet Events chronologisch, ermöglicht die Berechnung der Zeit zwischen Aktivitäten und von Wartezeiten sowie die Analyse der gesamten Zykluszeit eines Cases. Außerdem ist es grundlegend, um Engpässe zu erkennen und die Leistung anhand zeitbasierter Ziele wie SLAs zu bewerten. Warum das wichtig ist Dieser Timestamp ordnet Events chronologisch und ist für alle Analysen von Dauer, Leistung und Engpässen unverzichtbar. Woher beziehen Zendesk Ticket Audits API, Feld „created_at“ für jedes Audit-Event. Beispiele 2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
	Letzte Datenaktualisierung LastDataUpdate	Der Timestamp der letzten Aktualisierung der Daten aus dem Quellsystem.
Beschreibung Dieses Attribut erfasst Datum und Uhrzeit der letzten Datenextraktion aus Zendesk Support. Es gibt Aufschluss darüber, wie aktuell die analysierten Daten sind, und zeigt Benutzern, auf welchem Stand die Prozessansicht ist. Für die laufende Überwachung und Dashboards sind diese Angaben wichtig. Analysten und Fachanwender können damit erkennen, ob sie nahezu Echtzeitdaten oder eine Momentaufnahme aus einem früheren Zeitraum betrachten. Das beeinflusst, wie aussagekräftig ihre Schlussfolgerungen sind. Warum das wichtig ist Gibt wichtigen Aufschluss über die Aktualität der Daten und zeigt, wie aktuell die Analyse ist. Woher beziehen Dies ist ein Metadatenfeld, das bei der Datenextraktion erzeugt und dem Datensatz hinzugefügt wird. Beispiele 2023-10-27T08:00:00Z
	Quellsystem SourceSystem	Gibt an, aus welchem System die Daten extrahiert wurden.
Beschreibung Dieses Attribut gibt an, aus welchem System die Daten der Serviceanfrage stammen. In dieser Prozessansicht lautet der Wert immer „Zendesk Support“. Damit ist das System gekennzeichnet, in dem alle Aktivitäten des Servicemanagements erfasst werden. In Umgebungen mit mehreren integrierten Systemen ist dieses Feld wichtig für die Datenherkunft und die Fehlerbehebung. Es stellt sicher, dass Analysen dem vorgesehenen System zugeordnet werden, und hilft, Daten aus verschiedenen Quellen auseinanderzuhalten. Warum das wichtig ist Kennzeichnet das Ursprungssystem der Daten. So bleibt ihre Herkunft nachvollziehbar und es kommt nicht zu Verwechslungen, wenn Daten aus mehreren Systemen zusammengeführt werden. Woher beziehen Dies ist ein statischer Wert („Zendesk Support“), der bei der Datenextraktion und -transformation hinzugefügt wird. Beispiele Zendesk Support
	Art der Serviceanfrage ServiceType	Die Kategorie oder Art der Serviceanfrage, zum Beispiel Störung, Frage, Problem oder Aufgabe.
Beschreibung Die Art der Serviceanfrage kategorisiert deren Inhalt. Zendesk verwendet dafür das Feld „type“, das verschiedene Arten von Supportanfragen unterscheidet. Diese erste Einordnung hilft, das Ticket an das richtige Team weiterzuleiten und die passenden Abläufe anzuwenden. Dieses Attribut ist wichtig für Filter und Vergleiche. Analysten können damit die Prozessabläufe verschiedener Anfragearten untersuchen, die oft unterschiedliche Lösungswege und SLAs haben. Im Dashboard zur Leistung von Agenten und Teams zeigt diese Dimension, wer bestimmte Anfragearten am besten bearbeitet. Warum das wichtig ist Kategorisiert Anfragen und ermöglicht die getrennte Analyse unterschiedlicher Abläufe, etwa von Störungen und Fragen, die jeweils eigene Prozesswege durchlaufen. Woher beziehen Zendesk Tickets API, Feld „type“. Beispiele FrageStörungProblemAufgabe
	Eingangskanal der Anfrage RequestChannel	Der Kanal, über den die Serviceanfrage eingereicht wurde, zum Beispiel per E-Mail, Webformular oder Telefon.
Beschreibung Dieses Attribut kennzeichnet den Eingangskanal der Serviceanfrage. Zendesk erfasst, wie ein Ticket erstellt wurde, etwa per E-Mail, über ein Webportal, eine API-Integration oder einen Chat. So wird nachvollziehbar, über welchen Weg der Kunde Kontakt aufgenommen hat. Der Eingangskanal ist eine wichtige Analysedimension. Im Dashboard zur Effizienz der Anfragekanäle lassen sich damit Lösungszeiten, Zufriedenheitswerte und Nacharbeitsraten für verschiedene Kanäle vergleichen. Unternehmen können so ihre Supportkanäle gezielt verbessern und Kunden zu den effizientesten Kanälen leiten. Warum das wichtig ist Hilft, Effizienz und Ergebnisse verschiedener Kundensupportkanäle zu analysieren und gezielte Verbesserungen abzuleiten. Woher beziehen Zendesk Tickets API, Objekt „via“ und dessen Eigenschaft „channel“. Beispiele WebE-MailAPIChat
	Name des Agenten AgentName	Der Name des Agenten, der zum Zeitpunkt des Events der Serviceanfrage zugewiesen war.
Beschreibung Dieses Attribut kennzeichnet den Supportagenten, der für die Bearbeitung der Serviceanfrage zuständig ist. Der zuständige Agent kann während des Ticketlebenszyklus mehrfach wechseln. Dieses Feld zeigt, wer in jedem Schritt verantwortlich war. Der Name des Agenten ist für die Leistungsanalyse wichtig. Damit lassen sich Daten filtern und segmentieren, um die Arbeitslastverteilung, Lösungszeiten je Agent und die Häufigkeit von Neuzuweisungen zu bewerten. Diese Auswertungen unterstützen das Dashboard zur Leistung von Agenten und Teams und zeigen, welchen Beitrag Einzelne zur Effizienz des Gesamtprozesses leisten. Warum das wichtig ist Dieses Attribut ist wichtig, um die Leistung der Agenten, die Arbeitslastverteilung und den Einfluss von Neuzuweisungen auf die Lösungszeiten zu analysieren. Woher beziehen Zendesk Users API, durch Verknüpfung der „assignee_id“ aus der Antwort der Tickets API. Beispiele Jane DoeJohn SmithEmily Jones
	Priorität der Anfrage RequestPriority	Die der Serviceanfrage zugewiesene Prioritätsstufe, zum Beispiel niedrig, normal, hoch oder dringend.
Beschreibung Die Priorität der Anfrage gibt an, wie dringend eine Serviceanfrage ist. Sie bestimmt häufig die angestrebte Lösungszeit und die für das Ticket geltenden SLA-Richtlinien. Das System oder ein Benutzer kann die Priorität bei der Erstellung festlegen. Ein Agent kann sie im Verlauf des Tickets ändern. Dieses Attribut ist wichtig für Segmentierungen und Ursachenanalysen. Es zeigt, ob Anfragen mit hoher Priorität schneller gelöst werden als solche mit niedriger Priorität. Außerdem ist es eine zentrale Dimension in den Dashboards zu Eskalationstrends bei Serviceanfragen und zur SLA-Einhaltung. Warum das wichtig ist Ermöglicht die Segmentierung von Anfragen nach Dringlichkeit. Das ist entscheidend, um die Einhaltung von SLAs zu analysieren und dringende Probleme zeitnah zu bearbeiten. Woher beziehen Zendesk Tickets API, Feld „priority“. Beispiele NiedrigNormalHochDringend
	Status der Anfrage RequestStatus	Der Status der Serviceanfrage zum Zeitpunkt des Events, zum Beispiel neu, offen oder ausstehend.
Beschreibung Der Status der Anfrage gibt den Zustand des Tickets zu einem bestimmten Zeitpunkt an. Zendesk kennt mehrere Standardstatus wie „New“, „Open“, „Pending“, „On-hold“, „Solved“ und „Closed“. Sie zeigen den Fortschritt einer Anfrage im Verlauf an. Änderungen dieses Felds sind wichtige Auslöser für die Erstellung von Aktivitäten im Event Log. Die Dauer in den einzelnen Status zu analysieren, gehört zur Engpassanalyse. So lässt sich erkennen, wo Tickets ins Stocken geraten, etwa wenn sie zu lange auf „Pending“ oder „On-hold“ stehen. Das Verständnis der Statusübergänge hilft außerdem, Nacharbeitsschleifen aufzudecken. Warum das wichtig ist Die Erfassung des Status ist grundlegend, um den Fortschritt einer Anfrage nachzuvollziehen und die Dauer von Warte- und aktiven Phasen zu ermitteln. Woher beziehen Zendesk Tickets API, Feld „status“. Beispiele NeuOffenAusstehendGelöstGeschlossen
	Ticket-Tags TicketTags	Eine Liste von Tags, die zur Kategorisierung und Weiterleitung auf die Serviceanfrage angewendet wurden.
Beschreibung Tags sind flexible Kennzeichnungen, die Agenten manuell oder automatisch über Geschäftsregeln zu Tickets hinzufügen können. Sie ergänzen den Kontext oder ordnen Tickets Kategorien zu, die von Standardfeldern wie Art oder Priorität nicht abgedeckt werden. Tags sind ein vielseitiges Attribut für Process-Mining-Analysen. Sie lassen sich verwenden, um gezielt bestimmte Szenarien zu filtern, benutzerdefinierte Workflows nachzuverfolgen oder Ursachen zu erkennen. Mit einem Tag wie „VIP“ können beispielsweise Abläufe für wichtige Kunden analysiert werden. Das Tag „product_bug“ kann helfen, den Verlauf von Fehlermeldungen nachzuvollziehen. Warum das wichtig ist Ermöglicht eine flexible Auswertung der Daten und detaillierte Analysen bestimmter Teilprozesse oder Ticketattribute, die in anderen Feldern nicht erfasst werden. Woher beziehen Zendesk Tickets API, Feld „tags“. Dies ist ein Array aus Zeichenfolgen. Beispiele VertriebsanfrageAbrechnungsproblemFunktionswunschVIP-Kunde
	Zugewiesenes Team AssignedTeam	Das Supportteam oder die Gruppe, der die Serviceanfrage zugewiesen ist.
Beschreibung Dieses Attribut gibt an, welches Team oder welche Gruppe innerhalb des Supports für die Serviceanfrage zuständig ist. In Zendesk werden diese Gruppen als „Groups“ bezeichnet. Tickets werden häufig zuerst einer Gruppe zugewiesen und anschließend von einem einzelnen Agenten übernommen. Die Auswertung nach zugewiesenem Team ist wichtig, um Leistung und Arbeitslast auf Teamebene zu verstehen. Sie zeigt, welche Teams welche Anfragen bearbeiten, wie lange sie durchschnittlich für die Lösung benötigen und wie häufig sie SLA-Ziele einhalten. Diese Dimension ist zentral für das Dashboard zur Leistung von Agenten und Teams. Warum das wichtig ist Ermöglicht die Analyse der Teamleistung, den Ausgleich der Arbeitslast und die Bewertung der Weiterleitung zwischen verschiedenen Supportgruppen. Woher beziehen Zendesk Groups API, durch Verknüpfung der „group_id“ aus der Antwort der Tickets API. Beispiele Support Stufe 1Technischer SupportAbrechnung
	Anzahl der Neuzuweisungen an Agenten AgentReassignmentCount	Gesamtzahl der Neuzuweisungen einer Anfrage von einem Agenten an einen anderen.
Beschreibung Dieses Attribut zählt, wie oft sich das Feld 'assignee_id' eines Tickets ändert. Eine hohe Zahl von Neuzuweisungen bei einem einzelnen Ticket kann auf verschiedene Prozessprobleme hindeuten, etwa eine falsche anfängliche Zuweisung, fehlendes Wissen beim Agenten oder eine zu komplexe Anfrage, die ein einzelner Agent nicht bearbeiten kann. Diese Kennzahl ist wichtig, um die Prozesseffizienz zu messen, und fließt direkt in den KPI „Neuzuweisungsrate an Agenten“ ein. Die Analyse von Fällen mit vielen Neuzuweisungen kann Möglichkeiten aufzeigen, Zuweisungsregeln, Agentenschulungen oder Wissensdatenbankinhalte zu verbessern. So gelangen Tickets schneller zur richtigen Person. Warum das wichtig ist Quantifiziert interne Übergaben und macht Reibungsverluste im Prozess sichtbar. Häufige Neuzuweisungen führen oft zu Verzögerungen und Ineffizienz. Woher beziehen Wird berechnet, indem für jedes Ticket die Änderungen an 'assignee_id' in der Zendesk Ticket Audits API gezählt werden. Beispiele 013
	Beim ersten Kontakt gelöst IsFirstContactResolution	Kennzeichnet, ob der zuerst zugewiesene Agent die Anfrage ohne Neuzuweisung und ohne weitere Antworten des Anfragenden gelöst hat.
Beschreibung Die Erstlösungsquote (First Contact Resolution, FCR) zeigt, ob das Anliegen eines Kunden in einer einzigen Interaktion gelöst wurde. Dieses berechnete boolesche Attribut ist wahr, wenn der zuerst zugewiesene Agent das Ticket ohne Neuzuweisung und mit nur einer Antwort gelöst hat. Das Attribut fließt direkt in den KPI „Erstlösungsquote“ ein. Die Analyse von FCR-Fällen kann zeigen, welche Abläufe zu besonders guten Ergebnissen führen. Bei Fällen ohne FCR lassen sich dagegen Ansatzpunkte für bessere Agentenschulungen, hilfreichere Wissensdatenbankartikel oder eine wirksamere Ersteinschätzung erkennen. Warum das wichtig ist Misst, ob Anliegen mit nur einem Bearbeitungsschritt effizient gelöst werden. Das wirkt sich deutlich auf Kundenzufriedenheit und betriebliche Effizienz aus. Woher beziehen Dieses komplexe berechnete Attribut erfordert eine Analyse des Event Logs eines Tickets. Dabei werden Neuzuweisungen an Agenten und die Anzahl der öffentlichen Antworten von Agenten geprüft. Beispiele truefalse
	Endzeit EndTime	Das genaue Datum und die Uhrzeit, zu denen die Aktivität abgeschlossen wurde.
Beschreibung Die Endzeit kennzeichnet den Abschluss einer Aktivität. Bei vielen Events in Zendesk ist die Dauer null, sodass Endzeit und Startzeit übereinstimmen. Bei zustandsbasierten Aktivitäten wie „Anfrage zurückgestellt“ entspricht die Endzeit dagegen dem Zeitpunkt, an dem das Ticket nicht mehr zurückgestellt ist. Dieses Attribut ist wichtig, um die Dauer einzelner Aktivitäten zu berechnen und Engpässe zu analysieren. Durch den Vergleich von Start- und Endzeit lässt sich die Verarbeitungszeit direkt messen. So wird sichtbar, welche Schritte am meisten Zeit beanspruchen. Warum das wichtig ist Ermöglicht die Berechnung der Dauer einzelner Aktivitäten. Das ist entscheidend, um Engpässe im Prozess zu erkennen und die Effizienz auf Ebene der einzelnen Schritte zu messen. Woher beziehen Bei einzelnen Events entspricht dieser Wert häufig der Startzeit. Bei Statusdauern ist es der Timestamp des nächsten Events, das den Status ändert. Beispiele 2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
	Nacharbeit IsRework	Kennzeichnet, ob die Serviceanfrage nach ihrer Lösung wieder geöffnet wurde.
Beschreibung Dieses boolesche Attribut kennzeichnet Fälle mit Nacharbeit. Eine Serviceanfrage gilt in der Regel als Nacharbeit, wenn ihr Status von „Gelöst“ wieder in einen offenen Status wechselt. Das bedeutet, dass die ursprüngliche Lösung nicht ausgereicht hat und der Kunde sich wegen desselben Problems erneut melden musste. Das Attribut ist für die Berechnung des KPI „Nacharbeitsquote bei Serviceanfragen“ und für das Dashboard „Nacharbeit und erneute Öffnungen analysieren“ erforderlich. Damit können Analysten ineffiziente Prozessabläufe gezielt untersuchen, Ursachen für erneute Öffnungen ermitteln und die Erstlösungsquote verbessern. Warum das wichtig ist Macht Prozessfehler sichtbar, bei denen eine Anfrage nicht endgültig gelöst wurde. So werden Qualitäts- und Effizienzprobleme erkennbar, die sich direkt auf die Kundenzufriedenheit auswirken. Woher beziehen Wird anhand der Statusabfolge eines Tickets in der Zendesk Ticket Audits API berechnet. Ein Wechsel von 'solved' zu 'open' kennzeichnet Nacharbeit. Beispiele truefalse
	Name der SLA-Richtlinie SlaPolicyName	Der Name der Service-Level-Agreement-Richtlinie (SLA), die auf die Anfrage angewendet wird.
Beschreibung Dieses Attribut kennzeichnet die SLA-Richtlinie, nach der die angestrebten Antwort- und Lösungszeiten für die Serviceanfrage festgelegt werden. Welche Richtlinie gilt, hängt in der Regel von Faktoren wie Priorität und Art der Anfrage oder dem Abonnement des Kunden ab. Die angewendete SLA-Richtlinie ist für das Dashboard „SLA-Einhaltung und SLA-Verstöße analysieren“ unverzichtbar. Sie liefert den nötigen Kontext für die Leistungsbewertung, da für unterschiedliche Richtlinien unterschiedliche Zielwerte gelten. So lässt sich fair und präzise beurteilen, ob ein Ticket seine jeweiligen Service-Level-Ziele erfüllt hat. Warum das wichtig ist Liefert den Kontext für die SLA-Analyse: Sie zeigt, anhand welcher Zielwerte eine Anfrage bewertet wurde, und ermöglicht so eine präzise Compliance-Berichterstattung. Woher beziehen Zendesk Ticket Metrics API. SLA-Daten sind häufig den Ticket-Metriken zugeordnet. Beispiele Dringend: Antwort innerhalb einer StundeStandard: Lösung innerhalb von 24 StundenSLA für Premium-Kunden
	Name des Anfragenden RequestorName	Der Name des Endbenutzers oder Kunden, der die Serviceanfrage eingereicht hat.
Beschreibung Dieses Attribut kennzeichnet die Person, die die Serviceanfrage gestellt hat. Die Zuordnung zu einem bestimmten Kunden ermöglicht eine kundenorientierte Sicht auf den Supportprozess. In der Prozessanalyse lässt sich der Anfragende verwenden, um Muster bei einzelnen Kunden oder Kundensegmenten zu untersuchen. So kann beispielsweise geprüft werden, ob bestimmte Kunden länger auf eine Lösung warten oder häufiger Nacharbeit benötigen. Das kann auf Probleme mit einem von ihnen genutzten Produkt oder Service hindeuten. Warum das wichtig ist Verknüpft den Prozess mit dem Kunden und ermöglicht die Analyse kundenspezifischer Probleme, wiederholter Anfragen und der Zufriedenheit. Woher beziehen Zendesk Users API, durch Verknüpfung der „requester_id“ aus der Antwort der Tickets API. Beispiele Alice JohnsonBob WilliamsCharlie Brown
	Organisation des Anfragenden RequestorOrganization	Die Organisation oder das Unternehmen, zu dem der Anfragende gehört.
Beschreibung Dieses Attribut verknüpft die Serviceanfrage mit einer bestimmten Kundenorganisation. Das ist besonders im B2B-Support relevant, da Service-Level-Agreements und Supportverträge häufig auf Organisationsebene festgelegt werden. Die Auswertung nach Organisation ermöglicht einen Überblick über die Supportleistung für einzelne Unternehmen. Sie kann zeigen, welche Organisationen besonders viele Tickets einreichen, wiederholt mit denselben Problemen konfrontiert sind oder niedrige Zufriedenheitswerte aufweisen. Das ist für die Kundenbetreuung und die Erkennung übergreifender Trends zur Kundengesundheit hilfreich. Warum das wichtig ist Ermöglicht die Analyse von B2B-Services nach Unternehmen. Das ist wichtig, um Kundenbeziehungen und SLAs auf Organisationsebene zu verwalten. Woher beziehen Zendesk Organizations API, durch Verknüpfung der „organization_id“ aus der Antwort der Tickets API. Beispiele Acme CorporationGlobal Tech Inc.Innovate Solutions
	SLA-Verstoß IsSlaBreached	Kennzeichnet, ob die Serviceanfrage eines ihrer SLA-Ziele verfehlt hat.
Beschreibung Dieses boolesche oder kategoriale Attribut zeigt das SLA-Ergebnis eines Tickets an, zum Beispiel „Erfüllt“, „Verfehlt“ oder „Aktiv“. Das Ergebnis ergibt sich aus dem Vergleich der tatsächlichen Reaktions- oder Lösungszeit mit den Zielwerten der angewendeten SLA-Richtlinie. Für das Dashboard „SLA-Einhaltung und -Verstöße analysieren“ ist dieses Attribut besonders wichtig. Damit können Sie regelkonforme und nicht regelkonforme Tickets einfach zählen und visualisieren. Anschließend lässt sich untersuchen, welche Prozessmerkmale bei Tickets mit SLA-Verstoß auftreten, etwa lange Wartezeiten oder häufige Neuzuweisungen. Warum das wichtig ist Misst direkt, ob vereinbarte Service-Level eingehalten werden. Das ist ein wichtiger Indikator für Servicequalität und Kundenzufriedenheit. Woher beziehen Wird aus der Zendesk Ticket Metrics API abgeleitet, die Informationen zum SLA-Status jedes Tickets bereitstellt. Beispiele ErfülltVerfehltAktiv
	Zufriedenheitsbewertung SatisfactionRating	Die Zufriedenheitsbewertung, die der Anfragende nach der Lösung des Tickets abgegeben hat.
Beschreibung Dieses Attribut erfasst die Rückmeldung des Kunden zu seiner Supporterfahrung. Sie wird üblicherweise über eine Umfrage eingeholt, nachdem ein Ticket als gelöst markiert wurde. Gängige Bewertungen sind „Gut“ oder „Schlecht“, manchmal mit einem Kommentar. Die Zufriedenheitsbewertung ist eine wichtige Ergebniskennzahl. Werden Prozessmuster mit den Bewertungen verglichen, zeigt sich, welche Abläufe zu zufriedenen oder unzufriedenen Kunden führen. Eine Analyse kann beispielsweise ergeben, dass häufige Neuzuweisungen oder lange Lösungszeiten stark mit negativen Bewertungen zusammenhängen. Warum das wichtig ist Verknüpft die Prozessausführung direkt mit den Ergebnissen für Kunden und hilft zu erkennen, welche Abläufe die Kundenzufriedenheit beeinflussen. Woher beziehen Zendesk Tickets API, Feld „satisfaction_rating.score“ oder „satisfaction_rating.reason“. Beispiele GutSchlechtAngeboten

Erforderlich Empfohlen Optional

Aktivitäten im Management von Serviceanfragen

Diese wichtigen Prozessschritte und Meilensteine sollten Sie in Ihrem Event Log erfassen, um den Ablauf Ihrer Serviceanfragen präzise zu entdecken.

7 Empfohlen 6 Optional

	Aktivität	Beschreibung
	An Mitarbeitende zugewiesene Anfrage	Diese Aktivität tritt auf, wenn eine Serviceanfrage erstmals einer bestimmten Person im Support zugewiesen wird. Sie wird aus einem „Change“-Ereignis im Ticket-Audit-Log abgeleitet, bei dem das Feld „assignee_id“ von null oder einer Gruppen-ID auf eine Benutzer-ID gesetzt wird.
Warum das wichtig ist Damit beginnt die aktive Bearbeitung durch eine Person im Support. Die Aktivität ist entscheidend, um die Zeit bis zur ersten Reaktion, die Verzögerung bis zur ersten Zuweisung und die Verteilung der Arbeitslast zu messen. Woher beziehen Aus der ersten Änderung des Felds „assignee_id“ im Ticket-Audit-Log abgeleitet, bei der eine bestimmte Benutzer-ID eingetragen wird. Erfassung Aus dem ersten Änderungsereignis abgeleitet, bei dem das Feld „assignee_id“ einer Person im Support zugewiesen wird. Ereignistyp inferred
	Öffentliche Antwort gesendet	Diese Aktivität erfasst jede Mitteilung eines Agenten an den Anfragenden. In den Zendesk-Ticketdaten wird sie als explizites „Comment“-Event mit dem Attribut „public“ = true erfasst.
Warum das wichtig ist Diese Events sind wichtig, um die Häufigkeit der Kommunikation zu analysieren, die Antwortzeiten der Agenten zu messen und die Zahl der für eine Lösung erforderlichen Interaktionen zu ermitteln. Woher beziehen In den Ticketdaten wird dieses Ereignis als explizites „Comment“-Event erfasst. Die Ereignisdetails enthalten das Attribut „public: true“, das öffentliche Kommentare von internen Notizen unterscheidet. Erfassung Wird aus „Comment“-Events des Tickets übernommen, bei denen das Flag „public“ auf true gesetzt ist. Ereignistyp explicit
	Serviceanfrage erstellt	Dieses Ereignis markiert den Beginn des Lebenszyklus einer Serviceanfrage, wenn eine anfragende Person über einen beliebigen Kanal ein neues Ticket einreicht. Im Audit-Log des Zendesk-Tickets wird es als „Create“-Ereignis erfasst und liefert einen eindeutigen Startzeitpunkt für den Prozess.
Warum das wichtig ist Diese Aktivität ist das zentrale Start-Event jeder Serviceanfrage. Sie ist daher wichtig, um End-to-End-Zykluszeiten zu berechnen und das Anfragevolumen zu analysieren. Woher beziehen Im Audit-Log des Zendesk-Tickets wird dieses Ereignis mit dem Typ „Create“ erfasst. Der Timestamp des Ereignisses entspricht dem Erstellungszeitpunkt des Serviceanfrage-Tickets. Erfassung Direkt aus dem „Create“-Ereignis im Ticket-Audit-Log erfasst. Ereignistyp explicit
	Serviceanfrage gelöst	Diese Aktivität kennzeichnet den Zeitpunkt, an dem ein Agent eine Lösung bereitgestellt und den Ticketstatus auf „solved“ gesetzt hat. Aus Sicht des Agenten ist die Anfrage damit abgeschlossen, kann vom Anfragenden jedoch wiedereröffnet werden.
Warum das wichtig ist Dies ist ein wichtiger Meilenstein, der das Ende der aktiven Bearbeitung durch den Agenten markiert. Die Zeit bis zu diesem Status ist eine zentrale Kennzahl für die Effizienz der Lösungsbearbeitung. Woher beziehen Wird aus einem „Change“-Event für das Feld „status“ im Ticket-Auditprotokoll abgeleitet, bei dem der neue Wert „solved“ lautet. Erfassung Wird aus einem Event im Auditprotokoll abgeleitet, bei dem sich der Status auf „solved“ ändert. Ereignistyp inferred
	Serviceanfrage geschlossen	Bezeichnet den endgültigen, dauerhaften Abschluss der Serviceanfrage. Ein Ticket wechselt nach einer festgelegten Zeit im Status „solved“ automatisch in den Status „closed“ und kann danach nicht mehr wiedereröffnet werden.
Warum das wichtig ist Diese Aktivität markiert das endgültige Ende des Serviceanfrageprozesses. Sie bildet den Endpunkt für die Berechnung der gesamten Falldauer. Woher beziehen Wird aus einem „Change“-Event für das Feld „status“ im Ticket-Auditprotokoll abgeleitet, bei dem der neue Wert „closed“ lautet. Erfassung Wird aus einem Event im Auditprotokoll abgeleitet, bei dem sich der Status auf „closed“ ändert. Ereignistyp inferred
	Serviceanfrage wiedereröffnet	Tritt ein, wenn ein Anfragender auf eine Anfrage mit dem Status „solved“ antwortet und sich deren Status dadurch automatisch wieder in „open“ ändert. Das bedeutet, dass die vorgeschlagene Lösung nicht ausgereicht hat.
Warum das wichtig ist Diese Aktivität ist der wichtigste Indikator für Nacharbeit. Ihre Häufigkeit zeigt, wie gut Anfragen gelöst werden, und hilft, Ursachen für Unzufriedenheit bei Kunden zu erkennen. Woher beziehen Wird aus einem „Change“-Event für das Feld „status“ im Ticket-Auditprotokoll abgeleitet, bei dem der vorherige Wert „solved“ und der neue Wert „open“ war. Erfassung Abgeleitet aus einer Statusänderung von „solved“ zu „open“. Ereignistyp inferred
	SLA-Ziel verfehlt	Diese Aktivität kennzeichnet den Zeitpunkt, an dem eine Serviceanfrage ein festgelegtes SLA-Ziel, etwa für die Zeit bis zur ersten Antwort oder bis zur Lösung, verfehlt. Zendesk protokolliert dies als explizites Event, wenn ein Ziel nicht erreicht wird.
Warum das wichtig ist Dieses Ereignis ist für die Compliance-Überwachung entscheidend und fließt in die KPI zur SLA-Einhaltungsrate ein. Es zeigt, wann vereinbarte Serviceziele verfehlt wurden. Woher beziehen Wird aus dem Event „SLABreach“ in den Zendesk-Ticket-Events oder im Auditprotokoll übernommen. Das Event gibt an, welche SLA-Kennzahl verfehlt wurde. Erfassung Wird anhand des expliziten Events „SLABreach“ in den Ticketdaten erkannt. Ereignistyp explicit
	Agent neu zugewiesen	Bezeichnet die Übertragung der Zuständigkeit für eine Serviceanfrage von einem Agenten an einen anderen. Abgeleitet wird dieses Ereignis aus jedem „Change“-Event für das Feld „assignee_id“, das auf die erste Zuweisung folgt.
Warum das wichtig ist Die Erfassung von Neuzuweisungen ist wichtig für die Berechnung der KPI zur Neuzuweisungsrate von Agenten. Sie hilft, ineffiziente Abläufe, fehlerhafte Weiterleitungen oder Wissenslücken zu erkennen. Woher beziehen Wird aus „Change“-Events für das Feld „assignee_id“ im Ticket-Auditprotokoll abgeleitet. Das erste Zuweisungsereignis des Tickets bleibt unberücksichtigt. Erfassung Wird aus dem zweiten und allen folgenden „Change“-Events für das Feld „assignee_id“ abgeleitet. Ereignistyp inferred
	Anfrage eskaliert	Bezeichnet die formelle Weiterleitung einer Serviceanfrage an eine höhere Supportstufe, ein anderes Team oder das Management. Abgeleitet wird dieses Ereignis in der Regel aus einer Änderung der zugewiesenen Gruppe des Tickets oder eines benutzerdefinierten Felds zur Erfassung von Eskalationen.
Warum das wichtig ist Die Überwachung von Eskalationen hilft, komplexe Anfragen, Schulungsbedarf bei den Supportmitarbeitenden im Erstkontakt und systemische Probleme zu erkennen, die ein Eingreifen auf höherer Ebene erfordern. Woher beziehen Dies ist kein Standardereignis. Es muss aus einem „Change“-Event für das Feld „group_id“ abgeleitet werden, wenn das Ticket einer Eskalationsgruppe zugewiesen wird, oder aus einer Änderung eines benutzerdefinierten Ticketfelds zur Erfassung von Eskalationen. Erfassung Abgeleitet aus einer Änderung von „group_id“ oder eines benutzerdefinierten Felds „escalation“. Ereignistyp inferred
	Anfrage zurückgestellt	Diese Aktivität tritt ein, wenn der Status der Serviceanfrage auf „on-hold“ gesetzt wird. In der Regel wartet der Agent dann auf Informationen des Anfragenden oder eines Dritten. Abgeleitet wird sie aus einem Statusänderungsereignis.
Warum das wichtig ist So lassen sich Wartezeiten erfassen und messen, die außerhalb der direkten Kontrolle des Supportteams liegen. Dadurch wird die Bearbeitungszeit der Agenten genauer abgebildet. Woher beziehen Wird aus einem „Change“-Event für das Feld „status“ im Ticket-Auditprotokoll abgeleitet, bei dem der neue Wert „on-hold“ lautet. Erfassung Wird aus einem Event im Auditprotokoll abgeleitet, bei dem sich der Status auf „on-hold“ ändert. Ereignistyp inferred
	Interne Notiz hinzugefügt	Ein Agent hat der Serviceanfrage eine interne Notiz oder einen Kommentar hinzugefügt, der nur für andere Agenten sichtbar ist. Erfasst wird dies als „Comment“-Event mit dem Attribut „public“ = false.
Warum das wichtig ist Die Erfassung interner Notizen gibt Aufschluss über die Zusammenarbeit zwischen Agenten und Teams. Diese kann Verzögerungen verursachen oder entscheidend zu einer effizienten Problemlösung beitragen. Woher beziehen In den Ticketdaten wird dieses Ereignis als explizites „Comment“-Event erfasst. Die Ereignisdetails enthalten das Attribut „public: false“, das eine interne Notiz kennzeichnet. Erfassung Wird aus „Comment“-Events des Tickets übernommen, bei denen das Flag „public“ auf false gesetzt ist. Ereignistyp explicit
	Priorität geändert	Gibt an, dass die Priorität der Serviceanfrage geändert wurde, zum Beispiel von „Niedrig“ zu „Normal“, „Hoch“ oder „Dringend“. Im Ticket-Audit-Log wird dies als „Change“-Ereignis für das Feld „priority“ erfasst.
Warum das wichtig ist Die Analyse von Prioritätsänderungen zeigt, bei welchen Anfragen die Dringlichkeit im Laufe der Zeit steigt und ob die Priorisierung wirksam gesteuert wird. Woher beziehen Wird im Zendesk-Ticket-Auditprotokoll als „Change“-Event für das Feld „priority“ erfasst. Dabei werden der vorherige und der neue Wert angezeigt. Erfassung Wird aus „Change“-Events für das Feld „priority“ im Auditprotokoll abgeleitet. Ereignistyp inferred
	SLA-Ziel angewendet	Dieses Ereignis bezeichnet den Zeitpunkt, zu dem eine Service-Level-Agreement-Richtlinie (SLA) auf das Ticket der Serviceanfrage angewendet wird. Es wird ausdrücklich protokolliert, wenn die Eigenschaften des Tickets die Bedingungen einer aktiven SLA-Richtlinie erfüllen.
Warum das wichtig ist Der Zeitpunkt, zu dem ein SLA angewendet wird, ist wichtig für die Überwachung der Einhaltung, die Analyse möglicher Verstöße und das Verständnis der erwarteten Bearbeitungsfristen für verschiedene Anfragearten. Woher beziehen Aus dem Ereignis „SLAPolicyApplied“ in den Zendesk-Ticket-Ereignissen oder im Audit-Log erfasst. Dieses Ereignis gibt an, welche Richtlinie zutrifft. Erfassung Anhand des ausdrücklich protokollierten Ereignisses „SLAPolicyApplied“ in den Ticketdaten ermittelt. Ereignistyp explicit

Anleitungen zur Datenextraktion

So exportieren Sie Ihre Daten aus Zendesk Support

Schritte

Auf Zendesk Explore zugreifen und den Hauptbericht erstellen: Öffnen Sie oben rechts das Zendesk-Produktsymbol und wählen Sie Explore aus. Klicken Sie in Explore links auf das Symbol Queries und anschließend auf New query. Wählen Sie den Datensatz Support: Ticket updates als Quelle aus.
Kennzahlen und Attribute für Ticketereignisse konfigurieren: Fügen Sie im Abfrage-Generator eine Kennzahl wie COUNT(Tickets) hinzu, um Daten zu visualisieren. Wechseln Sie dann zum Bereich Rows und fügen Sie die folgenden Attribute hinzu: Ticket ID, Update - Timestamp, Updater name, Update - Field name, Update - Previous value, Update - New value, Assignee name, Gruppenname, Ticket priority, Ticket status, Submission channel, Ticket type und Ticket tags.
Ein berechnetes Attribut für ActivityName erstellen: Erstellen Sie ein standardmäßiges berechnetes Attribut, um Rohdaten zu aussagekräftigen Aktivitäten zusammenzufassen. Öffnen Sie das Menü Calculations (Taschenrechner-Symbol), wählen Sie Standard calculated attribute aus und nennen Sie das Attribut ActivityName. Fügen Sie die im Abschnitt Query angegebene Logik in das Formelfeld ein. Die Formel ordnet verschiedenen Ticketaktualisierungen die erforderlichen Aktivitätsnamen zu.
Den Hauptbericht verfeinern und filtern: Fügen Sie das neue Attribut ActivityName zum Bereich Rows hinzu. Erstellen Sie für dieses Attribut einen Filter, der alle (null)-Werte und unerwünschten, systemgenerierten Werte ausschließt. So bereinigen Sie den Datensatz. Filtern Sie außerdem nach Ticket created - Date, um den Zeitraum der Abfrage einzugrenzen, zum Beispiel auf die letzten 6 Monate.
Den zweiten Bericht für SLA-Ereignisse erstellen: Erstellen Sie eine weitere Abfrage und wählen Sie diesmal den Datensatz Support: SLAs aus. SLA-Ereignisse sind im Datensatz Ticket updates nicht verfügbar.
Den SLA-Bericht konfigurieren: Fügen Sie in der SLA-Abfrage COUNT(SLA tickets) zu Metrics hinzu. Ergänzen Sie im Bereich Rows die Attribute Ticket ID, SLA policy, SLA target, SLA updated - Timestamp, SLA status und Updater name. Im Transformationsschritt leiten Sie die Aktivität aus SLA status ab.
Beide Datensätze exportieren: Führen Sie beide Abfragen in der Explore-Oberfläche aus. Sobald die Tabellen erstellt sind, klicken Sie auf Export und wählen Sie CSV als Format aus. Sie erhalten zwei separate CSV-Dateien.
Die Daten zusammenführen und transformieren: Führen Sie die beiden CSV-Dateien mit einem Tabellenkalkulationsprogramm wie Microsoft Excel oder einer Skriptsprache wie Python zusammen. Ziel ist ein einzelnes Event Log. Erstellen Sie für die SLA-Datei die Spalte ActivityName. Wenn SLA status den Wert Aktiv hat, lautet die Aktivität SLA Target Applied. Bei SLA status mit dem Wert Breached lautet sie SLA Target Breached. Verwenden Sie SLA updated - Timestamp als EventTimestamp.
Spaltenüberschriften vereinheitlichen: Benennen Sie die Spalten in der zusammengeführten Datei so um, dass sie dem erforderlichen Format für Process Mining entsprechen. Benennen Sie beispielsweise Ticket ID in ServiceRequestId, Update - Timestamp in EventTimestamp und Updater name in AgentName um.
Statische Spalten hinzufügen und Datei fertigstellen: Fügen Sie der fertigen CSV-Datei zwei Spalten hinzu. Tragen Sie in SourceSystem den Wert 'Zendesk' ein. Füllen Sie LastDataUpdate mit dem Timestamp des Exports. Die Datei ist nun bereit für den Upload.

Konfiguration

Zendesk-Tarif: Für benutzerdefinierte Abfragen und Attribute benötigen Sie einen Zendesk-Support-Tarif mit Zendesk Explore Professional oder Enterprise.
Berechtigungen: Sie benötigen Agentenrechte, mit denen Sie Abfragen in Explore erstellen und bearbeiten können. In der Regel handelt es sich dabei um Administratoren oder Agenten mit einer benutzerdefinierten Rolle.
Datensatzauswahl: Bei dieser Methode erstellen Sie zwei separate Berichte auf Grundlage unterschiedlicher Datensätze: Support: Ticket updates für allgemeine Ereignisse und Support: SLAs für SLA-spezifische Ereignisse.
Datumsfilter: Ein Datumsfilter, zum Beispiel für Ticket created - Date, ist wichtig, damit das Datenvolumen überschaubar bleibt. Für die erste Analyse empfehlen sich 3 bis 6 Monate.
Berechnete Attribute: Die Aktivitätsnamen werden mithilfe eines komplexen, benutzerdefinierten berechneten Attributs in Explore abgeleitet. Achten Sie darauf, die Formel korrekt anzulegen, damit die Ergebnisse stimmen.
Datenvolumen: Die Zendesk-Explore-Benutzeroberfläche und der Export können bei sehr großen Datensätzen langsam sein oder eine Zeitüberschreitung verursachen. Bei Extraktionen von mehr als einem Jahr oder mehreren Millionen Tickets empfiehlt es sich, den Export in kleinere Zeiträume aufzuteilen.

a Beispielabfrage config

This method uses the Zendesk Explore UI, where queries are built visually. The following describes the configuration for the two required reports.

**Report 1: Ticket Events Configuration**
* **Dataset**: `Support: Ticket updates`
* **Metrics**: `COUNT(Tickets)`
* **Rows**:
  * `Ticket ID`
  * `ActivityName` (This is the custom calculated attribute defined below)
  * `Update - Timestamp`
  * `Updater name`
  * `Assignee name`
  * `Group name`
  * `Ticket priority`
  * `Ticket status`
  * `Submission channel`
  * `Ticket type`
  * `Ticket tags`
* **Standard Calculated Attribute (`ActivityName`) Formula**:
```
IF [Update - Field name] = "assignee_id" AND ([Update - Previous value] = "" OR [Update - Previous value] = NULL) THEN
    "Request Assigned to Agent"
ELIF [Update - Field name] = "assignee_id" AND [Update - Previous value] != "" AND [Update - Previous value] != NULL THEN
    "Agent Reassigned"
ELIF [Update - Field name] = "group_id" THEN
    "Request Escalated"
ELIF [Update - Field name] = "priority" AND [Update - New value] != [Update - Previous value] THEN
    "Priority Changed"
ELIF [Update - Field name] = "status" AND [Update - New value] = "hold" THEN
    "Request Placed On-Hold"
ELIF [Update - Field name] = "status" AND [Update - New value] = "solved" THEN
    "Service Request Resolved"
ELIF [Update - Field name] = "status" AND [Update - New value] = "closed" THEN
    "Service Request Closed"
ELIF [Update - Field name] = "status" AND [Update - New value] = "open" AND [Update - Previous value] = "solved" THEN
    "Service Request Reopened"
ELIF [Update - Field name] = "requester_id" AND [Update - Previous value] = NULL THEN
    "Service Request Created"
ELSE
    NULL
ENDIF
```
* **Note on Comment Activities**: Capturing `Public Reply Sent` and `Internal Note Added` from the `Ticket updates` dataset is not reliably possible as the public vs. internal distinction is often missing. For these events, creating a third report on the `Support: Comments` dataset and merging it is the recommended, though more complex, approach.

**Report 2: SLA Events Configuration**
* **Dataset**: `Support: SLAs`
* **Metrics**: `COUNT(SLA tickets)`
* **Rows**:
  * `Ticket ID`
  * `SLA updated - Timestamp`
  * `SLA status`
  * `Updater name`
  * `Assignee name`
  * `Group name`
  * `Ticket priority`
* **Note**: The `ActivityName` for this report (`SLA Target Applied`, `SLA Target Breached`) must be generated after export based on the value in the `SLA status` column.

Schritte

Voraussetzungen: Stellen Sie sicher, dass Python 3.6 oder neuer auf Ihrem System installiert ist. Außerdem benötigen Sie Administratorzugriff auf Ihre Zendesk-Support-Instanz, um ein API-Token zu erstellen.
Python-Bibliotheken installieren: Öffnen Sie Ihr Terminal oder die Eingabeaufforderung und installieren Sie die benötigten Python-Bibliotheken mit pip. Die Bibliothek requests führt API-Aufrufe aus, pandas dient der Datenverarbeitung und dem Export in eine CSV-Datei.
```
pip install requests pandas
```
Zendesk-API-Token erstellen: Melden Sie sich als Administrator bei Zendesk an. Öffnen Sie Admin Center > Apps und Integrationen > APIs > Zendesk API. Aktivieren Sie im Bereich „Tokenzugriff“ den Zugriff, falls er noch nicht aktiviert ist, und klicken Sie auf „API-Token hinzufügen“. Geben Sie eine Beschreibung ein, zum Beispiel „ProcessMind-Extraktion“, und kopieren Sie das erstellte Token. Es wird später nicht erneut angezeigt.
Python-Skript konfigurieren: Öffnen Sie das bereitgestellte Python-Skript in einem Texteditor. Tragen Sie oben in der Datei die Konfigurationswerte ein: ZENDESK_SUBDOMAIN (Ihre Zendesk-Domain), ZENDESK_EMAIL (E-Mail-Adresse des Administrators, der dem Token zugeordnet ist) und ZENDESK_API_TOKEN. Legen Sie außerdem mit START_TIME_STR den Beginn des Extraktionszeitraums fest, üblicherweise 3 bis 6 Monate zurück.
Funktionsweise des Skripts verstehen: Zunächst ruft das Skript mithilfe der effizienten Incremental Tickets API eine Liste der Tickets ab, die im angegebenen Zeitraum aktualisiert wurden. Anschließend ruft es für jedes Ticket den vollständigen Audit-Trail, die Kommentare und die SLA-Metriken ab. Die Ereignisse werden chronologisch verarbeitet, um einen detaillierten Verlauf zu erstellen.
Zendesk-Ereignisse Aktivitäten zuordnen: Das Skript enthält eine Logik, die Rohereignisse aus Zendesk den erforderlichen Geschäftsaktivitäten zuordnet. Ein Ereignis vom Typ 'Change' im Feld 'status' wird beispielsweise Aktivitäten wie 'Service Request Resolved' oder 'Request Placed On-Hold' zugeordnet. Bei Kommentarereignissen wird geprüft, ob es sich um 'Public Reply Sent' oder 'Internal Note Added' handelt.
Extraktionsskript ausführen: Starten Sie das Skript im Terminal mit python your_script_name.py. Während das Skript Daten aus der Zendesk API abruft, zeigt es den Fortschritt an. Je nach Datenvolumen und API-Ratenbegrenzungen kann der Vorgang einige Zeit dauern.
Ausgabedatei prüfen: Nach Abschluss erstellt das Skript im selben Verzeichnis eine CSV-Datei namens zendesk_event_log.csv. Sie enthält das extrahierte Event Log mit allen angegebenen Aktivitäten und Attributen.
Upload vorbereiten: Öffnen Sie die CSV-Datei und prüfen Sie, ob sie korrekt formatiert ist. Die Spaltenüberschriften müssen den erforderlichen Attributen entsprechen, darunter ServiceRequestId, ActivityName, EventTimestamp, SourceSystem und LastDataUpdate. Anschließend kann die Datei in ProcessMind hochgeladen werden.

Konfiguration

Zendesk-API-Zugriff: Das Skript benötigt ein aktives API-Token, das einem Administrator oder einem Agenten mit ausreichenden Berechtigungen zugeordnet ist. Für die Skriptkonfiguration muss die E-Mail-Adresse des Benutzers verwendet werden, der das API-Token erstellt hat.
Skriptparameter: Konfigurieren Sie vor der Ausführung die folgenden Variablen im Skript: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL, ZENDESK_API_TOKEN und START_TIME_STR. Für START_TIME_STR ist das Format 'YYYY-MM-DD' erforderlich.
Datumsbereich: Für den Anfang empfehlen wir, Daten der letzten 3 bis 6 Monate zu extrahieren (START_TIME_STR). So erhalten Sie einen repräsentativen Datensatz, ohne die Laufzeit unnötig zu verlängern oder häufig an API-Grenzen zu stoßen. Ein längerer Zeitraum erhöht die Extraktionsdauer deutlich.
Incremental Exports API: Das Skript verwendet den Incremental-Exports-Endpunkt (/api/v2/incremental/tickets/cursor.json), um effizient nur Tickets abzurufen, die seit der letzten Ausführung oder einem festgelegten Startzeitpunkt aktualisiert wurden. Das ist deutlich effizienter, als alle Tickets zu durchsuchen.
Ratenbegrenzung: Zendesk begrenzt die Anzahl der API-Aufrufe. Das Skript kann die Verarbeitung bei Erreichen einer Ratenbegrenzung vorübergehend anhalten. Bei sehr großen Instanzen kann die Extraktion dennoch längere Zeit dauern. Führen Sie das Skript am besten außerhalb der Hauptgeschäftszeiten aus.
Logik für Eskalationen: Die Aktivität 'Request Escalated' wird anhand einer Änderung im Feld group_id abgeleitet. Wenn Ihre Organisation einen anderen Mechanismus verwendet, etwa ein benutzerdefiniertes Ticketfeld, müssen Sie die Skriptlogik anpassen, damit Eskalationen korrekt erkannt werden.

a Beispielabfrage python

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

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Zendesk subdomain, admin email, and API token
ZENDESK_SUBDOMAIN = class="hl-string">'[Your Subdomain]'
ZENDESK_EMAIL = class="hl-string">'[Your Zendesk Admin Email]'
ZENDESK_API_TOKEN = class="hl-string">'[Your Zendesk API Token]'

class=class="hl-string">"hl-comment"># Set the start date for the data extraction (YYYY-MM-DD)
START_TIME_STR = class="hl-string">'2023-01-01'

class=class="hl-string">"hl-comment"># --- End of Configuration ---

class=class="hl-string">"hl-comment"># Set up constants and session
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.now(timezone.utc).isoformat()

session = requests.Session()
session.auth = AUTH

class=class="hl-string">"hl-comment"># Caches for user and group names to reduce API calls
user_cache = {}
group_cache = {}

def get_user_name(user_id):
    if not user_id:
        return None
    if user_id in user_cache:
        return user_cache[user_id]
    try:
        response = session.get(fclass="hl-string">'{BASE_URL}/users/{user_id}.json')
        response.raise_for_status()
        user_cache[user_id] = response.json()[class="hl-string">'user'][class="hl-string">'name']
        return user_cache[user_id]
    except requests.exceptions.RequestException:
        return fclass="hl-string">'User ID {user_id}'

def get_group_name(group_id):
    if not group_id:
        return None
    if group_id in group_cache:
        return group_cache[group_id]
    try:
        response = session.get(fclass="hl-string">'{BASE_URL}/groups/{group_id}.json')
        response.raise_for_status()
        group_cache[group_id] = response.json()[class="hl-string">'group'][class="hl-string">'name']
        return group_cache[group_id]
    except requests.exceptions.RequestException:
        return fclass="hl-string">'Group ID {group_id}'

def handle_rate_limit(response):
    if response.status_code == 429:
        retry_after = int(response.headers.get(class="hl-string">'Retry-After', 60))
        print(fclass="hl-string">'Rate limit reached. Waiting for {retry_after} seconds...')
        time.sleep(retry_after)
        return True
    response.raise_for_status()
    return False

def fetch_paginated_data(url):
    while url:
        try:
            response = session.get(url)
            if handle_rate_limit(response):
                continue
            data = response.json()
            yield data
            url = data.get(class="hl-string">'next_page')
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">'Error fetching data from {url}: {e}')
            break

def process_ticket(ticket, event_log):
    ticket_id = ticket[class="hl-string">'id']
    print(fclass="hl-string">'Processing Ticket ID: {ticket_id}')

    class=class="hl-string">"hl-comment"># --- 1. Fetch Ticket Audits ---
    audits_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/audits.json'
    all_events = [] class=class="hl-string">"hl-comment"># A temporary list to hold all events for sorting

    for audit_page in fetch_paginated_data(audits_url):
        for audit in audit_page.get(class="hl-string">'audits', []):
            author_id = audit.get(class="hl-string">'author_id')
            timestamp = audit[class="hl-string">'created_at']

            class=class="hl-string">"hl-comment"># Store ticket state at the time of the audit
            ticket_state = {}
            for event in audit.get(class="hl-string">'events', []):
                if event.get(class="hl-string">'field_name') in [class="hl-string">'assignee_id', class="hl-string">'group_id', class="hl-string">'priority', class="hl-string">'status', class="hl-string">'channel', class="hl-string">'type', class="hl-string">'tags']:
                    ticket_state[event[class="hl-string">'field_name']] = event.get(class="hl-string">'value')

            for event in audit.get(class="hl-string">'events', []):
                event[class="hl-string">'timestamp'] = timestamp
                event[class="hl-string">'author_id'] = author_id
                event[class="hl-string">'ticket_state'] = ticket_state
                all_events.append(event)

    class=class="hl-string">"hl-comment"># --- 2. Fetch Comments (which are not fully detailed in audits) ---
    comments_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/comments.json'
    for comment_page in fetch_paginated_data(comments_url):
        for comment in comment_page.get(class="hl-string">'comments', []):
            comment[class="hl-string">'type'] = class="hl-string">'Comment'
            comment[class="hl-string">'timestamp'] = comment[class="hl-string">'created_at']
            class=class="hl-string">"hl-comment"># Add ticket_state placeholder, though it's less relevant for comments
            comment[class="hl-string">'ticket_state'] = {}
            all_events.append(comment)

    class=class="hl-string">"hl-comment"># --- 3. Fetch SLA Metrics ---
    metrics_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/metrics.json'
    try:
        response = session.get(metrics_url)
        if not handle_rate_limit(response):
            metrics_data = response.json().get(class="hl-string">'ticket_metric', {})
            if metrics_data.get(class="hl-string">'sla_policy'):
                for sla in metrics_data[class="hl-string">'sla_policy'][class="hl-string">'policy_metrics']:
                    all_events.append({
                        class="hl-string">'type': class="hl-string">'SlaApply',
                        class="hl-string">'timestamp': metrics_data[class="hl-string">'created_at'],
                        class="hl-string">'policy_name': sla[class="hl-string">'policy'][class="hl-string">'title'],
                        class="hl-string">'ticket_state': {}
                    })
                    if sla.get(class="hl-string">'breach_at') and datetime.fromisoformat(sla[class="hl-string">'breach_at'].replace(class="hl-string">'Z', class="hl-string">'+00:00')) < datetime.now(timezone.utc):
                        all_events.append({
                            class="hl-string">'type': class="hl-string">'SlaBreach',
                            class="hl-string">'timestamp': sla[class="hl-string">'breach_at'],
                            class="hl-string">'policy_name': sla[class="hl-string">'policy'][class="hl-string">'title'],
                            class="hl-string">'metric': sla[class="hl-string">'metric'],
                            class="hl-string">'ticket_state': {}
                        })
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">'Could not fetch SLA metrics for ticket {ticket_id}: {e}')


    class=class="hl-string">"hl-comment"># --- 4. Sort all collected events by timestamp ---
    all_events.sort(key=lambda x: x[class="hl-string">'timestamp'])

    class=class="hl-string">"hl-comment"># --- 5. Process sorted events to create event log rows ---
    last_assignee = None

    for event in all_events:
        activity_name = None
        timestamp = event[class="hl-string">'timestamp']

        event_type = event.get(class="hl-string">'type')
        field_name = event.get(class="hl-string">'field_name')

        if event_type == class="hl-string">'Create':
            activity_name = class="hl-string">'Service Request Created'
            last_assignee = event.get(class="hl-string">'value') if field_name == class="hl-string">'assignee_id' else None

        elif event_type == class="hl-string">'Change':
            prev_value = event.get(class="hl-string">'previous_value')
            new_value = event.get(class="hl-string">'value')

            if field_name == class="hl-string">'status':
                if new_value == class="hl-string">'solved': activity_name = class="hl-string">'Service Request Resolved'
                elif new_value == class="hl-string">'closed': activity_name = class="hl-string">'Service Request Closed'
                elif new_value == class="hl-string">'hold': activity_name = class="hl-string">'Request Placed On-Hold'
                elif new_value == class="hl-string">'open' and prev_value == class="hl-string">'solved': activity_name = class="hl-string">'Service Request Reopened'
            elif field_name == class="hl-string">'priority': activity_name = class="hl-string">'Priority Changed'
            elif field_name == class="hl-string">'assignee_id':
                if prev_value is None and new_value is not None:
                    activity_name = class="hl-string">'Request Assigned to Agent'
                elif prev_value is not None and new_value is not None:
                    activity_name = class="hl-string">'Agent Reassigned'
                last_assignee = new_value
            elif field_name == class="hl-string">'group_id':
                if prev_value is not None and new_value is not None:
                    activity_name = class="hl-string">'Request Escalated'

        elif event_type == class="hl-string">'Comment':
            if event.get(class="hl-string">'public', False):
                activity_name = class="hl-string">'Public Reply Sent'
            else:
                activity_name = class="hl-string">'Internal Note Added'

        elif event_type == class="hl-string">'SlaApply':
            activity_name = class="hl-string">'SLA Target Applied'
        elif event_type == class="hl-string">'SlaBreach':
            activity_name = class="hl-string">'SLA Target Breached'

        if activity_name:
            class=class="hl-string">"hl-comment"># Get attribute values from the ticket object itself as a baseline
            agent_id = ticket.get(class="hl-string">'assignee_id')
            group_id = ticket.get(class="hl-string">'group_id')
            priority = ticket.get(class="hl-string">'priority')
            status = ticket.get(class="hl-string">'status')
            
            class=class="hl-string">"hl-comment"># Override with values at the time of the event if available
            state = event.get(class="hl-string">'ticket_state', {})
            agent_id = state.get(class="hl-string">'assignee_id', agent_id)
            group_id = state.get(class="hl-string">'group_id', group_id)
            priority = state.get(class="hl-string">'priority', priority)
            status = state.get(class="hl-string">'status', status)
            
            event_log.append({
                class="hl-string">'ServiceRequestId': ticket_id,
                class="hl-string">'ActivityName': activity_name,
                class="hl-string">'EventTimestamp': timestamp,
                class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                class="hl-string">'AgentName': get_user_name(agent_id),
                class="hl-string">'AssignedTeam': get_group_name(group_id),
                class="hl-string">'RequestPriority': priority,
                class="hl-string">'RequestStatus': status,
                class="hl-string">'RequestChannel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
                class="hl-string">'ServiceType': ticket.get(class="hl-string">'type'),
                class="hl-string">'TicketTags': class="hl-string">', '.join(ticket.get(class="hl-string">'tags', [])),
            })


def main():
    print(class="hl-string">'Starting Zendesk data extraction...')
    event_log = []
    start_unix_time = int(datetime.strptime(START_TIME_STR, class="hl-string">'%Y-%m-%d').timestamp())
    
    class=class="hl-string">"hl-comment"># Use the incremental export endpoint for efficiency
    url = fclass="hl-string">'{BASE_URL}/incremental/tickets/cursor.json?start_time={start_unix_time}'

    while url:
        try:
            response = session.get(url)
            if handle_rate_limit(response):
                continue
            data = response.json()
            tickets = data.get(class="hl-string">'tickets', [])
            print(fclass="hl-string">'Fetched {len(tickets)} tickets...')
            for ticket in tickets:
                process_ticket(ticket, event_log)
            
            if not data.get(class="hl-string">'after_cursor'):
                break
            url = data[class="hl-string">'next_page']

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

    print(fclass="hl-string">'Extraction complete. Total events found: {len(event_log)}')
    
    if not event_log:
        print(class="hl-string">'No events were extracted. Please check your configuration and date range.')
        return

    df = pd.DataFrame(event_log)

    class=class="hl-string">"hl-comment"># Reorder columns to match requirements
    columns = [
        class="hl-string">'ServiceRequestId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'AgentName', class="hl-string">'AssignedTeam', class="hl-string">'RequestPriority', class="hl-string">'RequestStatus',
        class="hl-string">'RequestChannel', class="hl-string">'ServiceType', class="hl-string">'TicketTags'
    ]
    df = df[columns]
    df = df.sort_values(by=[class="hl-string">'ServiceRequestId', class="hl-string">'EventTimestamp']).reset_index(drop=True)

    class=class="hl-string">"hl-comment"># Save to CSV
    output_filename = class="hl-string">'zendesk_event_log.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%SZ')
    print(fclass="hl-string">'Event log saved to {output_filename}')

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

Schritte

Fordern Sie im Zendesk Admin Center den nativen JSON-Export des vollständigen Kontos an oder starten Sie ihn. Verwenden Sie dazu die Exportfunktion Ihres Zendesk-Abonnements und Kontos. Der genaue Menüpfad und die erforderlichen Berechtigungen hängen von der Kontokonfiguration ab. Verwenden Sie die Exportoption im Admin Center und folgen Sie dem Freigabeprozess Ihrer Organisation.
Wählen Sie einen Datumsbereich, der den benötigten Analysezeitraum abdeckt, vorzugsweise drei bis sechs Monate. Wenn der native Export keinen Datumsfilter bietet, laden Sie den vollständigen Kontoexport herunter und wenden Sie den Filter bei der Transformation an.
Laden Sie alle vom Export erzeugten JSON-Dateien herunter und bewahren Sie sie auf. Erhalten Sie die Originaldateien, den Export-Timestamp, die Konto-ID sowie alle Manifest- und Metadatendateien unverändert. Überschreiben Sie die Quelldateien während der Verarbeitung nicht.
Verarbeiten Sie die im Export enthaltenen Ticketdatensätze, Ticket-Audit-Datensätze, Audit-Ereignisse, Kommentare, Benutzer, Organisationen, Gruppen, SLA-bezogenen Datensätze und benutzerdefinierten Felder. Da Dateinamen und JSON-Strukturen je nach Zendesk-Exportversion variieren können, konfigurieren Sie vor der Ausführung die Quellpfade und JSON-Eigenschaftszuordnungen in den Platzhaltern des Skripts.
Überführen Sie jedes Ticket-Audit-Ereignis in eine einheitliche Struktur mit ServiceRequestId, Audit-Timestamp, Ereignistyp, Feldname, vorherigem Wert, neuem Wert, Akteurskennung, Kennzeichen für öffentliche Inhalte, Ticketstatus, zugewiesenem Agenten, Gruppe, Priorität, Kanal, Servicetyp, Tags, Quellsystem und LastDataUpdate.
Erstellen Sie für jede relevante Aktivität eine Zeile im Event Log. Die Extraktion muss ausdrücklich Zeilen für Service Request Created, SLA Target Applied, Request Assigned to Agent, Priority Changed, Agent Reassigned, Public Reply Sent, Internal Note Added, Request Placed On-Hold, Request Escalated, SLA Target Breached, Service Request Reopened, Service Request Resolved und Service Request Closed erzeugen. ProcessMind übernimmt diese Zeilen unverändert und leitet keine zusätzlichen Ereignisse ab.
Ordnen Sie Kennungen von Agenten, Gruppen, Organisationen und Anfragenden den entsprechenden exportierten Benutzer-, Gruppen- und Organisationsdatensätzen zu, sofern diese verfügbar sind. Füllen Sie AgentName und AssignedTeam anhand des Zuweisungsstands zum Ereigniszeitpunkt aus. Wenn sich ein Anzeigename nicht ermitteln lässt, behalten Sie die Kennung bei oder lassen Sie das Feld leer.
Wenden Sie eindeutige Ereignisregeln an. Verwenden Sie das Ticket-Audit-Ereignis „Create“ für Service Request Created, explizite SLA-Audit-Ereignisse für SLA Target Applied und SLA Target Breached, die erste relevante Änderung des zugewiesenen Agenten für Request Assigned to Agent und spätere Änderungen für Agent Reassigned. Nutzen Sie Kennzeichen für öffentliche und private Kommentare für Antwort- und Notizereignisse sowie Statusübergänge für „On-Hold“, erneutes Öffnen, Lösen und Schließen. Änderungen an der Gruppe oder an einem konfigurierten Eskalationsfeld kennzeichnen Request Escalated.
Sortieren Sie die resultierenden Zeilen nach ServiceRequestId und EventTimestamp. Verwenden Sie dabei die Reihenfolge der Quellereignisse als stabilen Tie-Breaker. Entfernen Sie Ereignisse nicht allein deshalb, weil ihre Timestamps identisch sind, da mehrere Kommentare oder Audit-Ereignisse gleichzeitig auftreten können.
Prüfen Sie, ob alle erforderlichen Spalten vorhanden sind und jede Aktivität mindestens eine passende Zeile enthält, sofern das Quellsystem das entsprechende Ereignis aufweist. Exportieren Sie das Ergebnis als UTF-8-CSV oder in einem anderen von ProcessMind unterstützten Event-Log-Format. Verwenden Sie eine Zeile pro Ereignis und die erforderlichen Spaltennamen ServiceRequestId, ActivityName, EventTimestamp, SourceSystem und LastDataUpdate.

Konfiguration

Exportumfang: Verwenden Sie den nativen JSON-Export des vollständigen Zendesk-Support-Kontos und bewahren Sie alle dabei erzeugten JSON-Dateien auf. Der Export sollte Ticketdaten sowie Ticket-Audit- oder Ereignisdaten enthalten. Werden SLA-, Kommentar-, Benutzer-, Organisations-, Gruppen- oder benutzerdefinierte Felddaten separat bereitgestellt, nehmen Sie diese Dateien ebenfalls in die Transformation auf.
Datumsbereich: Für die erste Extraktion und Validierung empfehlen sich drei bis sechs Monate. Wenn der native Export das gesamte Konto umfasst und sich nicht nach Datum einschränken lässt, filtern Sie nach dem Parsen anhand von EventTimestamp und bewahren Sie das vollständige Quellarchiv auf.
Aktivitätsregeln: Konfigurieren Sie explizite Zuordnungen für alle 13 Aktivitäten. Verlassen Sie sich nicht darauf, dass ProcessMind Zuweisungs-, Eskalations-, SLA-, Status- oder Kommentarereignisse aus anderen Zeilen ableitet.
SLA-Konfiguration: Ordnen Sie die tatsächlich exportierten Ereignisnamen oder Eigenschaften zu, die das Konto für das Anwenden von SLA-Zielen und für SLA-Verstöße verwendet. Enthält der Export keine expliziten SLA-Ereignisse, erfinden Sie keine. Konfigurieren Sie die entsprechenden Quellpfade in den Platzhaltern und dokumentieren Sie nicht verfügbare Aktivitäten.
Eskalationskonfiguration: Ermitteln Sie das kontospezifische Gruppenfeld oder benutzerdefinierte Feld, das eine Eskalation kennzeichnet. Legen Sie vor der Ausführung in ESCALATION_FIELD_ID oder der entsprechenden Konfiguration die tatsächliche exportierte Feldkennung fest.
Quellpfade: Legen Sie die JSON-Dateipfade und JSON-Eigenschaftszuordnungen im Skript fest. Dateinamen und Verschachtelung der Zendesk-Exporte können je nach Exportversion und Kontokonfiguration variieren.
Erforderliche Ausgabefelder: ServiceRequestId, ActivityName, EventTimestamp, SourceSystem und LastDataUpdate müssen für jede Ereigniszeile ausgefüllt sein. Empfohlene Spalten sind AgentName, AssignedTeam, RequestPriority, RequestStatus, RequestChannel, ServiceType und TicketTags.
Filter: Wenden Sie den erforderlichen Analysezeitraum, den Konto- oder Markenbereich sowie unternehmensspezifische Filter erst an, nachdem Sie die entsprechenden exportierten Eigenschaften bestätigt haben. Verwenden Sie keine Filter auf Grundlage nicht unterstützter oder ungeprüfter Feldnamen.
Leistung: Verarbeiten Sie JSON-Dateien nach Möglichkeit schrittweise, vermeiden Sie es, den vollständigen Kontoexport in den Arbeitsspeicher zu laden, und indexieren Sie Ticket- und Audit-Kennungen. Schreiben Sie normalisierte Zwischendateien, bevor Sie das endgültige Event Log erstellen. Große Exporte müssen möglicherweise nach Datum oder Ticketkennung aufgeteilt werden.
Voraussetzungen: Administratorzugriff zum Anfordern oder Herunterladen des nativen Kontoexports, Berechtigung zum Zugriff auf Ticket-Audits sowie Benutzer- oder Gruppenreferenzdaten, ein Zendesk-Abonnement mit Unterstützung für die Exportfunktion, lokaler Speicherplatz für den vollständigen Export und eine Laufzeitumgebung, die JSON verarbeiten und UTF-8-CSV-Dateien schreiben kann.
Datenschutz: Behandeln Sie Daten zu Anfragenden, Agenten, Organisationen, Kommentaren und Tickets als potenziell sensibel. Speichern Sie Quelldateien und transformierte Dateien gemäß den Vorgaben Ihrer Organisation zu Aufbewahrung, Zugriffskontrolle und Datenschutz.

a Beispielabfrage config

import csv
import json
import os
from datetime import datetime, timezone
from pathlib import Path

SOURCE_DIRECTORY = "[Path to extracted Zendesk JSON directory]"
OUTPUT_FILE = "[Path to ProcessMind event log CSV]"
START_DATE = "[YYYY-MM-DD or blank]"
END_DATE = "[YYYY-MM-DD or blank]"
SOURCE_SYSTEM = "Zendesk Support"
LAST_DATA_UPDATE = "[ISO-8601 timestamp of source refresh]"
ESCALATION_FIELD_ID = "[Zendesk custom field identifier used for escalation, or blank]"


def load_json_files(directory):
    documents = []
    for path in Path(directory).rglob("*.json"):
        with path.open("r", encoding="utf-8") as handle:
            documents.append((path.name, json.load(handle)))
    return documents


def as_list(value):
    if isinstance(value, list):
        return value
    if isinstance(value, dict):
        for key in ("tickets", "ticket", "audits", "events", "comments", "users", "groups", "organizations", "data", "results"):
            if isinstance(value.get(key), list):
                return value[key]
    return []


def parse_timestamp(value):
    if not value:
        return None
    text = str(value).replace("Z", "+00:00")
    try:
        parsed = datetime.fromisoformat(text)
        if parsed.tzinfo is None:
            parsed = parsed.replace(tzinfo=timezone.utc)
        return parsed.astimezone(timezone.utc)
    except ValueError:
        return None


def in_range(timestamp):
    if timestamp is None:
        return False
    if START_DATE and timestamp.date().isoformat() < START_DATE:
        return False
    if END_DATE and timestamp.date().isoformat() > END_DATE:
        return False
    return True


def value(record, *keys):
    for key in keys:
        if isinstance(record, dict) and record.get(key) is not None:
            return record.get(key)
    return None


def identifier(record):
    return value(record, "id", "user_id", "group_id", "organization_id", "ticket_id")


def normalize_id(value_to_normalize):
    if value_to_normalize is None or value_to_normalize == "":
        return None
    return str(value_to_normalize)


def audit_events(audit):
    events = value(audit, "events", "audit_events")
    return events if isinstance(events, list) else []


def event_type(event):
    return str(value(event, "type", "event_type", "action") or "").lower()


def event_field(event):
    return str(value(event, "field_name", "field", "property") or "").lower()


def event_value(event, key):
    return value(event, key, key.replace("_", ""))


def status_value(ticket, event, new=True):
    if new:
        return value(event, "value", "new_value", "to") or value(ticket, "status")
    return value(event, "previous_value", "old_value", "from")


def comment_public(event):
    public_value = value(event, "public", "is_public")
    return public_value is True or str(public_value).lower() == "true"


def add_row(rows, ticket, activity, timestamp, agent_name=None, assigned_team=None, priority=None, status=None, channel=None, service_type=None, tags=None, sequence=0):
    parsed = parse_timestamp(timestamp)
    if not in_range(parsed):
        return
    rows.append({
        "ServiceRequestId": str(value(ticket, "id", "ticket_id")),
        "ActivityName": activity,
        "EventTimestamp": parsed.isoformat(),
        "SourceSystem": SOURCE_SYSTEM,
        "LastDataUpdate": LAST_DATA_UPDATE,
        "AgentName": agent_name or "",
        "AssignedTeam": assigned_team or "",
        "RequestPriority": priority or "",
        "RequestStatus": status or "",
        "RequestChannel": channel or "",
        "ServiceType": service_type or "",
        "TicketTags": ",".join(tags) if isinstance(tags, list) else (tags or ""),
        "SourceSequence": sequence
    })


def main():
    documents = load_json_files(SOURCE_DIRECTORY)
    tickets = {}
    audits_by_ticket = {}
    users = {}
    groups = {}
    organizations = {}
    standalone_comments = []
    standalone_sla_events = []

    for filename, document in documents:
        records = as_list(document)
        lower_name = filename.lower()
        for record in records:
            if not isinstance(record, dict):
                continue
            record_id = normalize_id(identifier(record))
            if any(token in lower_name for token in ("user", "agent")) and record_id:
                users[record_id] = record
            elif "group" in lower_name and record_id:
                groups[record_id] = record
            elif "organization" in lower_name and record_id:
                organizations[record_id] = record
            elif "audit" in lower_name and value(record, "ticket_id") is not None:
                audits_by_ticket.setdefault(normalize_id(value(record, "ticket_id")), []).append(record)
            elif "comment" in lower_name:
                standalone_comments.append(record)
            elif "sla" in lower_name:
                standalone_sla_events.append(record)
            elif value(record, "ticket_id") is not None and value(record, "type", "event_type") is not None:
                standalone_sla_events.append(record)
            elif value(record, "id") is not None and any(key in record for key in ("status", "priority", "assignee_id", "group_id", "tags")):
                tickets[record_id] = record

    rows = []
    for ticket_id, ticket in tickets.items():
        if not ticket_id:
            continue
        ticket_audits = audits_by_ticket.get(ticket_id, [])
        ticket_audits.sort(key=lambda item: (parse_timestamp(value(item, "created_at", "timestamp", "time")) or datetime.min.replace(tzinfo=timezone.utc), str(value(item, "id") or "")))
        current_assignee = normalize_id(value(ticket, "assignee_id"))
        current_group = normalize_id(value(ticket, "group_id"))
        assignment_seen = False
        sequence = 0
        base_priority = value(ticket, "priority")
        base_status = value(ticket, "status")
        base_channel = value(ticket, "via", "channel")
        base_service_type = value(ticket, "type", "service_type")
        base_tags = value(ticket, "tags") or []

        for audit in ticket_audits:
            audit_time = value(audit, "created_at", "timestamp", "time")
            actor_id = normalize_id(value(audit, "author_id", "actor_id", "user_id"))
            actor = users.get(actor_id, {})
            agent_name = value(actor, "name", "display_name", "email") or ""
            audit_group = groups.get(current_group, {})
            assigned_team = value(audit_group, "name", "display_name") or ""
            for event in audit_events(audit):
                sequence += 1
                kind = event_type(event)
                field = event_field(event)
                timestamp = value(event, "created_at", "timestamp", "time") or audit_time
                new_value = event_value(event, "value") or event_value(event, "new_value") or event_value(event, "to")
                old_value = event_value(event, "previous_value") or event_value(event, "old_value") or event_value(event, "from")
                event_agent = agent_name
                event_team = assigned_team
                if field in ("assignee_id", "assignee"):
                    new_assignee = normalize_id(new_value)
                    old_assignee = normalize_id(old_value)
                    if new_assignee and not assignment_seen and new_assignee != current_group:
                        assigned_agent = users.get(new_assignee, {})
                        add_row(rows, ticket, "Request Assigned to Agent", timestamp, value(assigned_agent, "name", "display_name", "email") or event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                        assignment_seen = True
                    elif new_assignee and assignment_seen and new_assignee != old_assignee:
                        assigned_agent = users.get(new_assignee, {})
                        add_row(rows, ticket, "Agent Reassigned", timestamp, value(assigned_agent, "name", "display_name", "email") or event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                    current_assignee = new_assignee or current_assignee
                elif field in ("priority",):
                    add_row(rows, ticket, "Priority Changed", timestamp, event_agent, event_team, new_value, base_status, base_channel, base_service_type, base_tags, sequence)
                    base_priority = new_value or base_priority
                elif field in ("group_id", "group"):
                    new_group = normalize_id(new_value)
                    new_group_record = groups.get(new_group, {})
                    new_team = value(new_group_record, "name", "display_name") or event_team
                    if new_group and new_group != current_group:
                        add_row(rows, ticket, "Request Escalated", timestamp, event_agent, new_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                    current_group = new_group or current_group
                elif field in ("status", "status_category"):
                    status_text = str(new_value or "").lower()
                    old_status_text = str(old_value or "").lower()
                    if status_text == "on-hold":
                        add_row(rows, ticket, "Request Placed On-Hold", timestamp, event_agent, event_team, base_priority, status_text, base_channel, base_service_type, base_tags, sequence)
                    if status_text == "solved":
                        add_row(rows, ticket, "Service Request Resolved", timestamp, event_agent, event_team, base_priority, status_text, base_channel, base_service_type, base_tags, sequence)
                    if status_text == "closed":
                        add_row(rows, ticket, "Service Request Closed", timestamp, event_agent, event_team, base_priority, status_text, base_channel, base_service_type, base_tags, sequence)
                    if old_status_text == "solved" and status_text in ("open", "pending", "on-hold"):
                        add_row(rows, ticket, "Service Request Reopened", timestamp, event_agent, event_team, base_priority, status_text, base_channel, base_service_type, base_tags, sequence)
                    base_status = new_value or base_status
                elif kind in ("comment", "comment_created", "comment_added") or field in ("comment", "comment_body"):
                    if comment_public(event):
                        add_row(rows, ticket, "Public Reply Sent", timestamp, event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                    else:
                        add_row(rows, ticket, "Internal Note Added", timestamp, event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                elif "sla" in kind or "sla" in field:
                    sla_text = str(value(event, "target_status", "status", "action", "event_type", "type") or "").lower()
                    if any(token in sla_text for token in ("breach", "breached", "missed", "failed")):
                        add_row(rows, ticket, "SLA Target Breached", timestamp, event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                    elif any(token in sla_text for token in ("applied", "active", "started", "target")):
                        add_row(rows, ticket, "SLA Target Applied", timestamp, event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                elif ESCALATION_FIELD_ID and field == ESCALATION_FIELD_ID.lower():
                    add_row(rows, ticket, "Request Escalated", timestamp, event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)

            if str(value(audit, "action", "type", "event_type") or "").lower() == "create":
                add_row(rows, ticket, "Service Request Created", audit_time, agent_name, assigned_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)

        for record in standalone_sla_events:
            if normalize_id(value(record, "ticket_id")) != ticket_id:
                continue
            timestamp = value(record, "created_at", "timestamp", "time")
            text = str(value(record, "event_type", "type", "status", "action") or "").lower()
            if "breach" in text or "missed" in text or "failed" in text:
                add_row(rows, ticket, "SLA Target Breached", timestamp, "", "", base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
            elif "sla" in text or "applied" in text or "active" in text:
                add_row(rows, ticket, "SLA Target Applied", timestamp, "", "", base_priority, base_status, base_channel, base_service_type, base_tags, sequence)

    rows.sort(key=lambda row: (row["ServiceRequestId"], row["EventTimestamp"], int(row["SourceSequence"])))
    output_columns = ["ServiceRequestId", "ActivityName", "EventTimestamp", "SourceSystem", "LastDataUpdate", "AgentName", "AssignedTeam", "RequestPriority", "RequestStatus", "RequestChannel", "ServiceType", "TicketTags"]
    with open(OUTPUT_FILE, "w", encoding="utf-8", newline="") as handle:
        writer = csv.DictWriter(handle, fieldnames=output_columns)
        writer.writeheader()
        for row in rows:
            writer.writerow({column: row.get(column, "") for column in output_columns})


if __name__ == "__main__":
    main()

Möchten Sie loslegen?

Optimieren Sie noch heute Ihren Serviceanfragenprozess. Mit diesem Daten-Template erkennen Sie Engpässe und steigern die Effizienz in Zendesk Support.

Zurück zum Leitfaden zur Prozessverbesserung Template herunterladen

Optimieren Sie das Management von Serviceanfragen. Verkürzen Sie Verzögerungen noch heute.

Beenden Sie langsame Bearbeitung und Frust bei Benutzern. Erreichen Sie einen Automatisierungsgrad von 70 %.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. Schnell eingerichtet.

Ihr Daten-Template für das Management von Serviceanfragen

Ihr Daten-Template für das Management von Serviceanfragen

Attribute für das Management von Serviceanfragen

Aktivitäten im Management von Serviceanfragen

Anleitungen zur Datenextraktion

Zendesk Explore: Benutzeroberfläche für Berichte und Datenexport

Schritte

Konfiguration

a Beispielabfrage config

Zendesk-REST-API-Extraktion mit einem Python-Skript

Schritte

Konfiguration

a Beispielabfrage python

Zendesk Support: nativer JSON-Export des vollständigen Kontos

Schritte

Konfiguration

a Beispielabfrage config

Möchten Sie loslegen?

Optimieren Sie das Management von Serviceanfragen. Verkürzen Sie Verzögerungen noch heute.

Ihr Daten-Template für das Management von Serviceanfragen

Ihr Daten-Template für das Management von Serviceanfragen

Attribute für das Management von Serviceanfragen

Aktivitäten im Management von Serviceanfragen

Anleitungen zur Datenextraktion

Zendesk Explore: Benutzeroberfläche für Berichte und Datenexport

Schritte

Konfiguration

a Beispielabfrage config

Zendesk-REST-API-Extraktion mit einem Python-Skript

Schritte

Konfiguration

a Beispielabfrage python

Zendesk Support: nativer JSON-Export des vollständigen Kontos

Schritte

Konfiguration

a Beispielabfrage config

Möchten Sie loslegen?

Optimieren Sie das Management von Serviceanfragen. Verkürzen Sie Verzögerungen noch heute.

Der Schutz Ihrer Daten ist uns wichtig