> Kontinuierliche Prozessverbesserung > Kundenservice > Zendesk Support > Daten Template

Ihr Daten-Template für den Kundenservice

Zendesk Support

← Zurück zum Leitfaden zur Prozessverbesserung

Kundenservice-Attribute (18) Kundenservice-Aktivitäten (14) Anleitungen zur Datenextraktion (4)

Ihr Daten-Template für den Kundenservice

Dieses Template hilft Ihnen, die passenden Daten für die Analyse Ihres Kundenserviceprozesses zusammenzustellen. Es beschreibt die wichtigsten zu erfassenden Attribute und Aktivitäten und enthält praktische Hinweise zur Datenextraktion. Damit können Sie ein aussagekräftiges Event Log erstellen, Erkenntnisse gewinnen und Ihren Service verbessern.

Empfohlene Attribute für die Erfassung
Wichtige Aktivitäten für die Analyse Ihres Kundenserviceprozesses
Hinweise zur Datenextraktion aus Zendesk Support

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

Template herunterladen

Kundenservice-Attribute

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

5 Erforderlich 6 Empfohlen 7 Optional

	Name	Beschreibung
	Serviceanfrage ServiceRequest	Die eindeutige Kennung jeder Kundenserviceanfrage, auch Ticket oder Case genannt.
Beschreibung Die Serviceanfrage ist die primäre Case-Kennung. Sie verknüpft alle Aktivitäten zu einer einzelnen Kundenanfrage oder einem Anliegen, von der Erstellung bis zur endgültigen Lösung. Jede Interaktion, Aktualisierung und interne Maßnahme ist dieser eindeutigen ID zugeordnet. Beim Process Mining ermöglicht die Analyse der nach Serviceanfrage gruppierten Ereignisse einen vollständigen Überblick über den Kundenserviceprozess. Sie bildet die Grundlage für Kennzahlen wie die gesamte Bearbeitungszeit, die Erkennung von Prozessabweichungen und das Verständnis des Lebenszyklus jedes Kundenanliegens. Warum das wichtig ist Dies ist die zentrale Case-ID, die alle Prozessschritte miteinander verknüpft und so die Rekonstruktion und Analyse jedes einzelnen Kundenserviceprozesses ermöglicht. Woher beziehen Zendesk Tickets API, Feld `id`. Beispiele 102451287415332
	Startzeit StartTime	Der Timestamp, der angibt, wann eine Aktivität oder ein Ereignis begonnen hat.
Beschreibung Die Startzeit beziehungsweise der Ereignis-Timestamp erfasst das genaue Datum und die Uhrzeit einer bestimmten Aktivität. Sie hält beispielsweise fest, wann ein Kundenkommentar hinzugefügt, ein Mitarbeiter zugewiesen oder der Ticketstatus auf 'Gelöst' gesetzt wurde. Dieser Timestamp ist für Process Mining grundlegend, da er die chronologische Reihenfolge der Ereignisse festlegt. Er dient dazu, Zeitspannen zwischen Aktivitäten zu berechnen, Zykluszeiten zu messen, die Leistung anhand von SLAs zu analysieren und den zeitlichen Verlauf des Serviceprozesses zu verstehen. Warum das wichtig ist Dieser Timestamp ist wichtig, um Ereignisse zu ordnen, Zeitspannen zu berechnen und den zeitlichen Ablauf der Serviceanfrage zu analysieren. Woher beziehen Zendesk Ticket Audits API, Feld `created_at` für jedes Ereignis im Audit Trail. Beispiele 2023-04-15T10:00:00Z2023-04-15T10:05:14Z2023-04-16T14:30:00Z
	Aktivitätsname ActivityName	Der Name des konkreten Ereignisses oder der Aufgabe, die im Lebenszyklus der Serviceanfrage stattgefunden hat.
Beschreibung Der Aktivitätsname bezeichnet einen einzelnen Schritt oder Meilenstein im Kundenserviceprozess, etwa 'Serviceanfrage erstellt', 'Anfrage einem Mitarbeiter zugewiesen' oder 'Serviceanfrage gelöst'. Diese Ereignisse werden mit einem Timestamp versehen und bilden die Abfolge der Aktionen für jede Serviceanfrage. Dieses Attribut ist entscheidend, um den Prozessablauf zu visualisieren, Prozessvarianten zu erkennen und Häufigkeit sowie Reihenfolge der Ereignisse zu analysieren. Es zeigt, welche Aktionen ausgeführt werden, und hilft, häufige Abläufe, Engpässe und Abweichungen von der Standardvorgehensweise zu erkennen. Warum das wichtig ist Dieses Attribut legt die Prozessschritte fest. Dadurch lassen sich die Prozesskarte visualisieren sowie Prozessabläufe und Varianten analysieren. Woher beziehen Abgeleitet aus Zendesk-Ticket-Audit-Logs oder Event Streams, in denen Änderungen und Aktionen erfasst werden. Beispiele Serviceanfrage erstelltAnfrage einem Mitarbeiter zugewiesenErste öffentliche Antwort eines Mitarbeiters gesendetServiceanfrage gelöst
	Letzte Datenaktualisierung LastDataUpdate	Der Timestamp der letzten Aktualisierung oder Extraktion von Daten aus dem Quellsystem.
Beschreibung Dieses Attribut gibt an, wann der Datensatz zuletzt aus Zendesk Support aktualisiert wurde. Es zeigt, wie aktuell die analysierten Daten sind. Anhand des letzten Aktualisierungszeitpunkts können Analysten und Fachanwender erkennen, ob sie mit den neuesten Prozessinformationen arbeiten. So lassen sich Erwartungen an die Aktualität der Daten steuern. Der Zeitpunkt ist außerdem wichtig für Berichte und Überwachung. Warum das wichtig ist Zeigt, wie aktuell die Daten sind, damit Benutzer den Aktualitätsstand der Prozessanalyse einschätzen können. Woher beziehen Dieses Metadatenfeld wird bei der Datenextraktion erzeugt und gespeichert. Es enthält den Timestamp des Extraktionsauftrags. Beispiele 2023-10-27T02:00:00Z
	Quellsystem SourceSystem	Das führende System, aus dem die Daten extrahiert wurden.
Beschreibung Dieses Attribut gibt das Ursprungssystem der Serviceanfragedaten an, in diesem Fall Zendesk Support. Es unterstützt Data Governance und Datenherkunft, insbesondere wenn Daten aus mehreren Systemen zusammengeführt werden. In der Analyse stellt es sicher, dass Daten der richtigen Quelle zugeordnet sind. Das ist wichtig, um die Datenintegrität zu wahren und den Prozesskontext zu verstehen, besonders in Umgebungen mit mehreren Systemen. Warum das wichtig ist Gibt die Herkunft der Daten an. Das ist wichtig für Data Governance und um Prozessdaten in integrierten Umgebungen voneinander zu unterscheiden. Woher beziehen Dieser statische Wert wird bei der Datenextraktion hinzugefügt, um die Herkunft der Daten zu kennzeichnen. Beispiele Zendesk Support
	Art der Serviceanfrage ServiceRequestType	Die Klassifizierung der Serviceanfrage, zum Beispiel als 'Frage', 'Vorfall', 'Problem' oder 'Aufgabe'.
Beschreibung Dieses Attribut kategorisiert die Serviceanfrage nach ihrer Art. Die Klassifizierung wird üblicherweise bei der Erstellung oder Triage der Anfrage festgelegt und hilft, den passenden Workflow und die richtige Priorität zu bestimmen. Für die Analyse ist eine Aufschlüsselung nach Art der Serviceanfrage grundlegend. So lassen sich Bearbeitungszeiten, Eskalationsraten und Prozessabläufe für verschiedene Anliegen vergleichen, wie in Dashboards wie 'Analyse der Bearbeitungszeit von Serviceanfragen' und 'Interne Eskalationsrate und Ursachen'. Dadurch wird sichtbar, ob bestimmte Anfragearten schwieriger oder weniger effizient zu bearbeiten sind. Warum das wichtig ist Kategorisiert Anfragen, damit sich die Leistung bei verschiedenen Anliegen vergleichen und analysieren lässt. Das ist entscheidend für gezielte Prozessverbesserungen. Woher beziehen Zendesk Tickets API, Feld `type`. Beispiele FrageVorfallProblemAufgabe
	Kommunikationskanal CommunicationChannel	Der Kanal, über den die Serviceanfrage eingereicht oder die Kommunikation geführt wurde.
Beschreibung Dieses Attribut gibt an, über welchen Kommunikationsweg die Anfrage einging, zum Beispiel per E-Mail, Webformular, Chat oder Telefon. Es zeigt, wie Kunden mit dem Service Desk kommunizieren. Die Nutzung der einzelnen Kanäle zu kennen, ist wichtig für die Ressourcenplanung und eine bessere Customer Experience. Das Dashboard „Nutzung der Kommunikationskanäle im Überblick“ wertet diese Daten aus. So sehen Sie, welche Kanäle am häufigsten genutzt werden und ob bestimmte Kanäle mit längeren Lösungszeiten oder anderen Prozesspfaden verbunden sind. Die Ergebnisse können Ihnen dabei helfen, gezielt in Verbesserungen des Service oder in Automatisierung zu investieren. Warum das wichtig ist Zeigt, wie Kunden und Mitarbeitende miteinander kommunizieren. So lässt sich analysieren, wie effizient die einzelnen Kanäle sind und wie sie sich auf den Prozess und die Customer Experience auswirken. Woher beziehen Zendesk Tickets API, Feld `via.channel`. Beispiele WebE-MailAPIChat
	Priorität Priority	Die der Serviceanfrage zugewiesene Priorität, zum Beispiel 'Niedrig', 'Normal', 'Hoch' oder 'Dringend'.
Beschreibung Die Priorität gibt an, wie dringend eine Serviceanfrage ist. Sie beeinflusst häufig ihre Position in der Warteschlange und die angestrebte Bearbeitungszeit. So können Mitarbeitende zuerst die dringendsten Anliegen bearbeiten. Dieses Attribut ist wichtig für die Leistungs- und SLA-Analyse. Das Dashboard 'Analyse der Bearbeitungszeit von Serviceanfragen' schlüsselt die Daten nach Priorität auf. So wird sichtbar, ob Anfragen mit hoher Priorität schneller bearbeitet werden als solche mit niedriger Priorität und ob die Ressourcen entsprechend den geschäftlichen Anforderungen eingesetzt werden. Warum das wichtig ist Gibt die Dringlichkeit einer Anfrage an. Sie ist entscheidend, um die SLA-Einhaltung zu analysieren und dringende Anliegen zeitnah zu bearbeiten. Woher beziehen Zendesk Tickets API, Feld `priority`. Beispiele NiedrigNormalHochDringend
	SLA überschritten IsSlaBreached	Ein boolescher Wert, der angibt, ob die Lösungszeit der Serviceanfrage das SLA-Ziel überschritten hat.
Beschreibung Dieses berechnete Attribut gibt mit einem einfachen Wahr- oder Falschwert an, ob eine Serviceanfrage innerhalb der festgelegten Lösungszeit des Service-Level-Agreements bearbeitet wurde. Der Wert ergibt sich aus dem Vergleich der tatsächlichen Lösungsdauer mit dem SLA-Ziel. Das Attribut vereinfacht die Analyse der SLA-Einhaltung. Es ist die zentrale Datengrundlage für das Dashboard „SLA-Einhaltung“ und die KPI „SLA-Einhaltungsquote“. Damit können Sie schnell zusammenfassen und visualisieren, wie viele Anfragen die Serviceziele erfüllen und wie viele nicht. Warum das wichtig ist Zeigt für jeden Case eindeutig an, ob die SLA-Leistung den Vorgaben entspricht. Das vereinfacht die Überwachung und Berichterstattung zur Compliance. Woher beziehen Wird bei der Datentransformation berechnet, indem die gesamte Lösungszeit mit SlaTargetResolutionTime verglichen wird. Beispiele truefalse
	SLA-Zielzeit für die Lösung SlaTargetResolutionTime	Der Zeitraum, innerhalb dessen eine Serviceanfrage gemäß der geltenden SLA-Richtlinie gelöst werden soll.
Beschreibung Dieses Attribut legt das Service-Level-Agreement-Ziel (SLA) für die Lösung eines Tickets fest. Das Ziel ist häufig dynamisch und hängt beispielsweise von der Priorität und Art der Anfrage oder vom Service-Tarif des Kunden ab. Dieses Attribut bildet die Grundlage für das Dashboard „SLA-Einhaltung“. Es dient als Vergleichswert für die tatsächliche Lösungszeit. Der Abgleich mit diesem Ziel macht die Qualität der Servicebereitstellung messbar und zeigt, ob die vertraglichen Verpflichtungen gegenüber Kunden eingehalten werden. Warum das wichtig ist Legt das Serviceversprechen gegenüber dem Kunden fest und dient als Vergleichswert, um die termingerechte Bearbeitung und die SLA-Einhaltung zu messen. Woher beziehen Wird aus den auf ein Ticket angewendeten SLA-Richtlinien abgeleitet. Diese Informationen sind über die Zendesk Ticket Metrics API verfügbar. Beispiele 144002880086400
	Zugewiesener Mitarbeiter AssignedAgent	Der Name oder die ID des Kundenservicemitarbeiters, der für die Serviceanfrage zuständig ist.
Beschreibung Dieses Attribut gibt an, welcher Mitarbeiter zu einem bestimmten Zeitpunkt für eine Aktivität oder die Serviceanfrage zuständig ist. Bei einer Neuzuweisung kann sich der Wert im Laufe des Lebenszyklus ändern. Die Analyse nach zugewiesenem Mitarbeiter ist wichtig, um Arbeitslast, Leistung und Effizienz zu verstehen. Sie unterstützt das Dashboard 'Arbeitslast und Effizienz der Mitarbeitenden', indem Bearbeitungszeiten und Case-Volumen verschiedener Mitarbeitender verglichen werden. So lassen sich Schulungsbedarf erkennen und Arbeitslasten ausgewogen verteilen. Warum das wichtig ist Erfasst, welcher Mitarbeiter eine Aktion ausgeführt hat. So lassen sich individuelle Leistung, Arbeitslastverteilung und Ressourcenzuweisung analysieren. Woher beziehen Zendesk Tickets API, Feld `assignee_id`. Benutzerdetails können über die Users API abgerufen werden. Beispiele John SmithJane DoeSupportBot
	Agentengruppe AgentGroup	Die Supportgruppe oder das Team, dem die Serviceanfrage zugewiesen ist.
Beschreibung Dieses Attribut bezeichnet das Team der Mitarbeitenden, das für die Serviceanfrage zuständig ist. Anfragen werden häufig je nach Fachkenntnis, Produktbereich oder Sprache bestimmten Gruppen zugewiesen. Die Auswertung nach Agentengruppe zeigt die Leistung und Arbeitslast einzelner Teams sowie Eskalationen zwischen Teams. Sie bietet einen Überblick auf Teamebene, der über die Analyse einzelner Mitarbeitender hinausgeht, und kann systemische Probleme in bestimmten Abteilungen oder Funktionen sichtbar machen. Warum das wichtig ist Zeigt, welches Team zuständig ist. So lassen sich die Gruppenleistung, Übergaben zwischen Teams und die Ressourcenverteilung über verschiedene Supportstufen und Fachgebiete hinweg analysieren. Woher beziehen Zendesk Tickets API, Feld `group_id`. Details zu Gruppen können über die Groups API abgerufen werden. Beispiele Support der Stufe 1Technischer SupportAbrechnung
	Anzahl der Informationsanfragen InformationRequestCount	Wie oft der Kunde im Rahmen einer einzelnen Serviceanfrage um Informationen gebeten wurde.
Beschreibung Diese berechnete Kennzahl zählt für jede Serviceanfrage, wie oft die Aktivität „Informationen beim Kunden angefordert“ auftritt. Ein hoher Wert deutet darauf hin, dass Mitarbeitende nicht alle benötigten Informationen von Anfang an einholen. Das Attribut wird im Dashboard „Analyse wiederholter Informationsanfragen“ verwendet. Die Anzahl hilft, ineffiziente Abläufe und Schulungsbedarf bei Mitarbeitenden zu erkennen. Weniger Rückfragen können die Lösungszeiten deutlich verkürzen und die Customer Experience verbessern. Warum das wichtig ist Erfasst den Austausch mit dem Kunden und macht Ineffizienzen sichtbar, die die Lösungszeit verlängern und die Customer Experience beeinträchtigen. Woher beziehen Wird berechnet, indem für jede Serviceanfrage die Ereignisse gezählt werden, bei denen ActivityName den Wert „Information Requested From Customer“ hat. Beispiele 013
	Endzeit EndTime	Der Timestamp, der angibt, wann eine Aktivität oder ein Ereignis abgeschlossen wurde.
Beschreibung Die Endzeit gibt an, wann eine Aktivität abgeschlossen wurde. In vielen Event-Log-Strukturen kann die Startzeit der nächsten Aktivität als Endzeit der aktuellen dienen. Bei zustandsbasierten Aktivitäten wie 'Mitarbeiter prüft Anliegen' markiert sie das Ende des jeweiligen Zustands. Dieses Attribut ist wichtig, um die genaue Dauer von Aktivitäten zu berechnen, einem zentralen Bestandteil der Leistungsanalyse. Es zeigt, welche Schritte am meisten Zeit beanspruchen, und bildet die Grundlage für detaillierte Engpassanalysen und Berechnungen zur Ressourceneffizienz. Warum das wichtig ist Ermöglicht die Berechnung der Aktivitätsdauer. Das ist entscheidend, um Engpässe zu erkennen und die Leistung zu messen. Woher beziehen Wird häufig aus der Startzeit des nachfolgenden Ereignisses in der Abfolge für eine bestimmte Serviceanfrage abgeleitet. Beispiele 2023-04-15T10:05:14Z2023-04-15T11:20:30Z2023-04-16T15:00:00Z
	Erneut geöffnet IsReopened	Ein boolescher Wert, der angibt, ob eine Serviceanfrage nach ihrer Kennzeichnung als gelöst erneut geöffnet wurde.
Beschreibung Dieses Attribut wird auf „Wahr“ gesetzt, wenn eine Serviceanfrage nach dem Status „Gelöst“ oder „Geschlossen“ wieder in den Status „Offen“ wechselt. Es zeigt an, dass die ursprüngliche Lösung nicht ausgereicht hat. Das Attribut ist wichtig, um Nacharbeit und Fälle zu erfassen, die nicht beim ersten Kontakt gelöst wurden. Es unterstützt direkt das Dashboard „Trends bei erneut geöffneten Serviceanfragen“ und die KPI „Wiedereröffnungsrate von Serviceanfragen“. So können Sie die Cases, die weitere Bearbeitung erfordern, einfach zählen und analysieren. Sie weisen häufig auf tiefer liegende Probleme hin. Warum das wichtig ist Macht Nacharbeit und fehlgeschlagene Lösungen sichtbar. So lässt sich die Qualität und Wirksamkeit der angebotenen Lösungen messen. Woher beziehen Wird bei der Datentransformation berechnet. Dazu wird geprüft, ob sich der Ticketstatus von „resolved“ oder „closed“ zurück zu „open“ ändert. Beispiele truefalse
	Lösungscode ResolutionCode	Ein Code oder eine Kategorie, die den Grund für die abschließende Lösung oder Schließung der Anfrage angibt.
Beschreibung Der Lösungscode enthält strukturierte Informationen zum Ergebnis einer Serviceanfrage. Beispiele sind „Vom Agenten gelöst“, „Duplikat“, „Keine Maßnahme erforderlich“ oder „Bekanntes Problem“. Damit liefert er mehr Kontext als ein einfacher Status wie „Geschlossen“. Dieses Attribut ist besonders für die Ursachenanalyse hilfreich. Im Dashboard „Trends bei erneut geöffneten Serviceanfragen“ können Sie die Wiedereröffnungsrate nach Lösungscode auswerten. So erkennen Sie, ob bestimmte Lösungen weniger wirksam sind und Kunden sich deshalb erneut an den Support wenden müssen. Warum das wichtig ist Zeigt das Ergebnis einer Serviceanfrage. Das ist entscheidend für die Ursachenanalyse und dafür, zu verstehen, warum Anfragen erneut geöffnet werden. Woher beziehen In Zendesk handelt es sich in der Regel um ein benutzerdefiniertes Ticketfeld. Der genaue Feldname hängt von der jeweiligen Zendesk-Konfiguration ab. Beispiele Beim ersten Kontakt gelöstAn Support der Stufe 2 eskaliertWarten auf KundenrückmeldungProduktfehler
	Produkt- oder Servicekategorie ProductServiceCategory	Das Produkt, der Service oder die Funktion, auf die sich die Anfrage des Kunden bezieht.
Beschreibung Dieses Attribut liefert zusätzlichen Kontext, indem es die Serviceanfrage einem Produkt- oder Servicebereich zuordnet. Die Zuordnung erfolgt häufig manuell durch Mitarbeitende oder automatisch anhand des Anfrageinhalts. Diese Kategorisierung ist wichtig für die Dashboards „Genauigkeit der Anfragekategorisierung“ und „Aufschlüsselung der Untersuchungszykluszeit“. Sie ermöglicht eine detaillierte Analyse: Welche Produkte führen zu den meisten Supportanfragen? Welche Anfragen sind am schwierigsten zu lösen? Und stimmt die ursprüngliche Kategorisierung mit der endgültigen Lösung überein? Die Erkenntnisse helfen, die Weiterleitung von Anfragen und die Schulung der Mitarbeitenden zu verbessern. Warum das wichtig ist Ordnet Anfragen bestimmten Geschäftsbereichen, Produkten oder Services zu. So können Sie Problembereiche und ihre Auswirkungen auf den Prozess gezielt analysieren. Woher beziehen In Zendesk handelt es sich in der Regel um ein benutzerdefiniertes Ticketfeld. Der genaue Feldname hängt von der jeweiligen Zendesk-Konfiguration ab. Beispiele Mobile AppAbonnementverwaltungAPI-IntegrationHardware
	Zufriedenheitsbewertung SatisfactionRating	Die Zufriedenheitsbewertung, die der Kunde nach der Lösung seiner Serviceanfrage abgibt.
Beschreibung Dieses Attribut erfasst die Rückmeldung des Kunden zu seiner Serviceerfahrung. Sie wird in der Regel über eine Umfrage eingeholt, nachdem das Ticket gelöst wurde. Übliche Bewertungen sind „Gut“, „Schlecht“ oder ein Zahlenwert. Die Bewertung misst direkt die Kundenzufriedenheit und ist eine wichtige Ergebniskennzahl. Sie fließt in die Berechnung der KPI „Kundenzufriedenheit“ ein. Wenn Sie Zufriedenheitsbewertungen zusammen mit Prozessdaten wie der Lösungszeit oder der Anzahl der Kontakte mit Mitarbeitenden auswerten, erkennen Sie, welche Prozessabläufe zu besseren Ergebnissen für Kunden führen. Warum das wichtig ist Misst direkt die Rückmeldung der Kunden zum erbrachten Service und setzt die Prozessleistung mit den Ergebnissen für Kunden in Beziehung. Woher beziehen Zendesk Tickets API, Feld `satisfaction_rating.score`. Beispiele GutSchlechtAngeboten

Erforderlich Empfohlen Optional

Kundenservice-Aktivitäten

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

6 Empfohlen 8 Optional

	Aktivität	Beschreibung
	Anfrage einem Mitarbeiter zugewiesen	Dieses Ereignis zeigt an, dass die Serviceanfrage einem bestimmten Mitarbeiter zur Bearbeitung zugewiesen wurde. Die Zuweisung kann automatisch anhand von Weiterleitungsregeln oder manuell durch eine Teamleitung oder einen Mitarbeiter erfolgen.
Warum das wichtig ist Die Zuweisung ist ein wichtiger Meilenstein für die Verantwortlichkeit und das Arbeitslastmanagement. Die Analyse der Zeit bis zur Zuweisung und der Neuzuweisungen zeigt Engpässe bei der Triage und Verteilung. Woher beziehen Dieses explizite Ereignis 'Change' wird in der Zendesk Ticket Audits API protokolliert, sobald das Feld 'assignee_id' ausgefüllt oder geändert wird. Erfassung Verfolgen Sie Änderungen am Feld 'assignee_id' im Ticket Audits Log. Ereignistyp explicit
	Informationen beim Kunden angefordert	Diese Aktivität tritt auf, wenn ein Mitarbeiter weitere Informationen vom Kunden benötigt und den Ticketstatus auf 'pending' setzt. Die Statusänderung zeigt ausdrücklich an, dass der Prozess auf eine externe Partei wartet.
Warum das wichtig ist Diese Aktivität macht Abhängigkeiten vom Kunden sichtbar und hält die internen SLA-Uhren an. Häufige oder wiederholte Vorkommen in einem Ticket können auf eine unvollständige erste Informationsaufnahme hindeuten und die Bearbeitungszeit verlängern. Woher beziehen Diese explizite Statusänderung wird in der Zendesk Ticket Audits API erfasst, wenn das Feld 'status' auf 'pending' wechselt. Erfassung Ermitteln Sie Ereignisse 'Change' in den Ticket Audits, bei denen der Ticketstatus auf 'pending' gesetzt wird. Ereignistyp explicit
	Serviceanfrage erstellt	Diese Aktivität markiert den Beginn des Kundenserviceprozesses: In Zendesk wird über einen beliebigen Kanal, etwa per E-Mail, Webformular oder Chat, ein neues Ticket angelegt. Das System protokolliert dieses Ereignis bei der Erstellung mit einer eindeutigen Ticket-ID und einem Timestamp.
Warum das wichtig ist Als primäres Start-Event ist diese Aktivität entscheidend, um die gesamte Case-Dauer zu berechnen und das Anfragevolumen im Zeitverlauf zu analysieren. Sie bildet die Grundlage für Kennzahlen wie die Zeit bis zur ersten Antwort und die gesamte Bearbeitungszeit. Woher beziehen Dieses explizite Ereignis wird in der Zendesk Ticket Audits API erfasst. Es entspricht dem Ereignis 'Create' für ein Ticket und enthält den ursprünglichen Erstellungs-Timestamp. Erfassung Aus dem Ereignis zur Ticketerstellung im Ticket Audits Log erfasst. Ereignistyp explicit
	Serviceanfrage gelöst	Ein Mitarbeiter markiert die Serviceanfrage nach einer Lösung für den Kunden als 'solved'. Dieser Status ist vorläufig: Der Kunde kann das Ticket durch eine Antwort wiedereröffnen, bevor es endgültig geschlossen wird.
Warum das wichtig ist Dies ist der wichtigste Meilenstein zur Messung der Bearbeitungszeit und der Effizienz der Mitarbeitenden. Er zeigt an, wann der Mitarbeiter die Arbeit für abgeschlossen hält, und bildet die Grundlage für die Analyse von Nacharbeit, falls das Ticket wiedereröffnet wird. Woher beziehen Diese explizite Statusänderung wird in der Zendesk Ticket Audits API erfasst, wenn das Feld 'status' auf 'solved' gesetzt wird. Erfassung Ermitteln Sie Ereignisse 'Change' in den Ticket Audits, bei denen der Ticketstatus auf 'solved' gesetzt wird. Ereignistyp explicit
	Serviceanfrage geschlossen	Dies ist die letzte Aktivität und markiert den endgültigen Abschluss der Serviceanfrage. Üblicherweise geschieht dies automatisch, nachdem seit der Markierung des Tickets als 'solved' eine festgelegte Zeit vergangen ist, ohne dass der Kunde erneut geantwortet hat.
Warum das wichtig ist Als abschließendes End-Event beendet diese Aktivität den Lebenszyklus des Tickets. Die Zeit zwischen 'solved' und 'closed' ist das Zeitfenster für mögliche Wiedereröffnungen. Das Ereignis 'closed' bestätigt, dass die Lösung angenommen wurde. Woher beziehen Diese explizite Statusänderung wird in der Zendesk Ticket Audits API erfasst, wenn das Feld 'status' auf 'closed' gesetzt wird. Erfassung Ermitteln Sie Ereignisse 'Change' in den Ticket Audits, bei denen der Ticketstatus auf 'closed' gesetzt wird. Ereignistyp explicit
	Serviceanfrage wiedereröffnet	Diese Aktivität tritt auf, wenn ein Kunde auf ein Ticket im Status 'solved' antwortet. Zendesk setzt den Status automatisch wieder auf 'open'. Das zeigt an, dass das Anliegen nicht vollständig gelöst wurde.
Warum das wichtig ist Wiedereröffnungen sind ein wichtiger Hinweis auf eine unzureichende Lösung beim Erstkontakt und eine mangelhafte Lösungsqualität. Die Analyse der Häufigkeit und Gründe wiedereröffneter Tickets hilft, Verbesserungsmöglichkeiten bei der Schulung von Mitarbeitenden und den Lösungsverfahren zu erkennen. Woher beziehen Diese explizite Statusänderung wird in der Ticket Audits API erfasst, wenn der Status von 'solved' zurück auf 'open' wechselt. Erfassung Verfolgen Sie Statusänderungen 'Change' von 'solved' zu 'open'. Ereignistyp explicit
	Anfrage kategorisiert und priorisiert	Diese Aktivität findet statt, wenn ein Mitarbeiter oder eine Automatisierung Ticketfelder wie Typ, Kategorie oder Priorität festlegt oder aktualisiert. Der Schritt wird als Änderungsereignis im Ticketverlauf protokolliert.
Warum das wichtig ist Eine korrekte Kategorisierung und Priorisierung ist entscheidend für die effiziente Weiterleitung und Ressourcenzuweisung. Die Analyse dieser Aktivität zeigt, wie genau die erste Triage erfolgt und wie sie sich auf die Bearbeitungszeiten auswirkt. Woher beziehen Wird in der Zendesk Ticket Audits API als Ereignis 'Change' erfasst. Erkennbar ist die Aktivität an der ersten Aktualisierung von Feldern wie 'priority', 'type' oder benutzerdefinierten Kategorisierungsfeldern. Erfassung Filtern Sie die Ticket Audit Logs nach dem ersten Ereignis 'Change' in wichtigen Kategorisierungsfeldern nach der Ticketerstellung. Ereignistyp explicit
	Erste öffentliche Antwort eines Mitarbeiters gesendet	Diese Aktivität markiert den ersten öffentlichen Kommentar eines Mitarbeiters an den Kunden, im Unterschied zu einer automatischen Eingangsbestätigung. Sie zeigt, wann sich ein Mitarbeiter erstmals aktiv mit dem Anliegen des Kunden befasst.
Warum das wichtig ist Dieser Meilenstein ist wichtig, um das SLA für die 'First Reply Time' zu messen, eine zentrale Kennzahl für die Reaktionsfähigkeit des Kundenservice. Er grenzt die automatische Kommunikation vom Beginn der aktiven Prüfung und Unterstützung durch Mitarbeitende ab. Woher beziehen Erkennbar am ersten öffentlichen Kommentar im Ticket Comments Stream, dessen Verfasser ein menschlicher Mitarbeiter und kein automatisierter Systembenutzer ist. Erfassung Durchsuchen Sie die Ticketkommentare nach öffentlichen Kommentaren von Mitarbeitenden und wählen Sie den mit dem frühesten Timestamp aus. Ereignistyp inferred
	Erste Rückmeldung gesendet	Bezeichnet die automatische erste Antwort an den Kunden, die den Eingang der Anfrage bestätigt. Üblicherweise löst Zendesk diesen Schritt über einen Trigger aus, der direkt nach der Ticketerstellung eine E-Mail auf Basis einer Vorlage versendet.
Warum das wichtig ist Diese Aktivität zu verfolgen ist entscheidend, um die Reaktionszeit beim Erstkontakt zu messen und die Erwartungen der Kunden zu steuern. Die Zeit zwischen der Erstellung der Anfrage und dieser Bestätigung ist eine wichtige Kennzahl für die Kundenzufriedenheit. Woher beziehen Abgeleitet aus dem ersten öffentlichen Kommentar zum Ticket, wenn dieser von einem automatisierten Benutzer stammt oder innerhalb weniger Sekunden nach der Ticketerstellung erfolgt. Dies lässt sich anhand des Ticket Comments Streams ermitteln. Erfassung Ermitteln Sie den ersten öffentlichen Kommentar, der direkt nach der Ticketerstellung durch eine Automatisierung oder einen Trigger erstellt wurde. Ereignistyp inferred
	Interne Eskalation ausgelöst	Bezeichnet die Weitergabe einer Serviceanfrage an ein anderes internes Team oder eine höhere Support-Ebene. Dies lässt sich üblicherweise an einer Änderung der zugewiesenen Ticketgruppe erkennen.
Warum das wichtig ist Die Erfassung von Eskalationen hilft, Schwächen im Prozess, Wissenslücken im First-Level-Support und komplexe Anfragearten zu erkennen. Häufige Eskalationen können auf einen Bedarf an besserer Schulung oder Prozessdokumentation hindeuten. Woher beziehen Abgeleitet aus einem Ereignis 'Change' in der Ticket Audits API, bei dem das Feld 'group_id' geändert wird. Ein Gruppenwechsel bedeutet, dass die Anfrage an ein anderes Team übergeben wird. Erfassung Überwachen Sie Änderungen am Feld 'group_id' im Ticket Audits Log. Ereignistyp inferred
	Kunde hat geantwortet	Dieses Ereignis wird ausgelöst, wenn ein Kunde auf ein Ticket antwortet, das sich üblicherweise im Status 'pending' befindet. Zendesk setzt den Ticketstatus automatisch von 'pending' auf 'open' zurück. Damit wird angezeigt, dass der Mitarbeiter die Bearbeitung fortsetzen kann.
Warum das wichtig ist Diese Aktivität beendet die Wartezeit und setzt den Prozess fort. Die Analyse der Antwortzeiten von Kunden kann Aufschluss darüber geben, wie verständlich die Anfragen der Mitarbeitenden sind. Woher beziehen Dieses Ereignis entspricht einem neuen öffentlichen Kommentar des Endbenutzers. Dadurch wird in der Ticket Audits API eine explizite Statusänderung von 'pending' zu 'open' ausgelöst. Erfassung Verfolgen Sie Statusänderungen 'Change' von 'pending' zu 'open' oder ermitteln Sie neue öffentliche Kommentare eines Endbenutzers. Ereignistyp explicit
	SLA-Verstoß aufgetreten	Diese Aktivität markiert den Zeitpunkt, an dem eine Serviceanfrage eine festgelegte Service Level Agreement-Vorgabe, etwa für die erste Antwort oder die Bearbeitungszeit, nicht erfüllt. Das Ereignis wird anhand der Ticket-Timestamps im Vergleich zu den SLA-Richtlinien berechnet.
Warum das wichtig ist SLA-Verstöße wirken sich direkt auf die Kundenzufriedenheit und die Vertragseinhaltung aus. Die Analyse, wann und warum sie auftreten, ist entscheidend, um systematische Verzögerungen, fehlende Ressourcen oder unrealistische Leistungsziele zu erkennen. Woher beziehen Die Daten können aus der Zendesk Ticket Metrics API stammen, in der SLA-Verstoß-Timestamps ('breached_at') gespeichert werden. Alternativ lassen sie sich berechnen, indem die Timestamps der Ticketereignisse mit den festgelegten SLA-Regeln verglichen werden. Erfassung Verwenden Sie den Timestamp 'breached_at' aus der Ticket Metrics API oder berechnen Sie den Verstoß durch einen Vergleich der Bearbeitungszeit mit der SLA-Vorgabe. Ereignistyp calculated
	Zufriedenheitsbewertung eingegangen	Dieses Ereignis tritt ein, wenn der Kunde die Zufriedenheitsumfrage beantwortet und eine Bewertung wie 'Gut' oder 'Schlecht' abgibt. Die Bewertung und ein möglicher Kommentar werden dem Ticket zugeordnet.
Warum das wichtig ist Direktes Kundenfeedback ist wertvoll, um die Servicequalität und die Kundenzufriedenheit zu messen. Wenn Sie die Bewertungen im Kontext des Prozessablaufs analysieren, können Sie bestimmte Aktivitäten oder Mitarbeitende mit den Ergebnissen in Verbindung bringen. Woher beziehen Wird als Ereignis 'Change' in der Ticket Audits API erfasst, wenn das Feld 'satisfaction_rating' mit der Bewertung und dem Kommentar des Kunden ausgefüllt wird. Erfassung Filtern Sie die Ticket Audit Logs nach Änderungen am Feld 'satisfaction_rating'. Ereignistyp explicit
	Zufriedenheitsumfrage gesendet	Bezeichnet den Zeitpunkt, an dem eine Umfrage zur Kundenzufriedenheit (CSAT) automatisch an den Kunden gesendet wird. Dies geschieht üblicherweise kurze Zeit, nachdem das Ticket als 'solved' markiert wurde.
Warum das wichtig ist Diese Aktivität leitet die Kundenrückmeldung ein. Es ist wichtig zu wissen, wann und ob Umfragen versendet werden, um Zufriedenheitswerte einordnen und die Wirksamkeit des Feedbackprogramms messen zu können. Woher beziehen Das Ereignis lässt sich aus einem Automatisierungsprotokoll oder anhand eines bestimmten Tags ableiten, das dem Ticket hinzugefügt wird. Auch der Abschnitt 'satisfaction_rating' in der Ticket Audits API hält fest, wann die Umfrage angeboten wurde. Erfassung Suchen Sie nach Tags wie 'csat_sent' oder verwenden Sie den Timestamp, zu dem die Zufriedenheitsbewertung angeboten wurde. Ereignistyp inferred

Anleitungen zur Datenextraktion

So exportieren Sie Ihre Daten aus Zendesk Support

Schritte

Zendesk Explore öffnen: Melden Sie sich bei Ihrer Zendesk-Instanz an. Öffnen Sie Explore über das Produktauswahl-Symbol in der oberen Leiste und wählen Sie Explore aus.
Neue Abfrage erstellen: Klicken Sie in Explore in der linken Seitenleiste auf das Abfragesymbol und anschließend oben rechts auf „Neue Abfrage“.
Datensatz auswählen: Wählen Sie im Fenster „Datensatz auswählen“ den Datensatz Support: Tickets aus. Er enthält die wichtigsten Ticketattribute und zentrale Ereignis-Timestamps.
Kennzahlen hinzufügen: Öffnen Sie im Abfrageeditor den Bereich „Kennzahlen“ und klicken Sie auf „Hinzufügen“. Wählen Sie COUNT(Tickets) aus. Damit können Sie das Datenvolumen überprüfen.
Attribute zu den Zeilen hinzufügen: Öffnen Sie den Bereich „Zeilen“ und klicken Sie auf „Hinzufügen“. Fügen Sie die folgenden Attribute hinzu. Sie bilden die Grundlage für den Export im breiten Format.
- Ticket ID (dies ist Ihre Case-Kennung, ServiceRequest)
- Assignee name (AssignedAgent)
- Ticket type (ServiceRequestType)
- Ticket priority (Priority)
- Ticket channel (CommunicationChannel)
- SLA resolution time (SlaTargetResolutionTime)
- SLA breach status (IsSlaBreached)
- Full resolution time (min) (ServiceRequestResolutionTime)
Aktivitäts-Timestamps zu den Zeilen hinzufügen: Fügen Sie dem Bereich „Zeilen“ die folgenden Timestamp-Attribute hinzu. Jedes davon steht für eine mögliche Aktivität. Für einige Aktivitäten müssen Sie ein benutzerdefiniertes berechnetes Attribut erstellen.
- Ticket created - Timestamp: für Service Request Created und Initial Acknowledgment Sent.
- Ticket assigned - Timestamp: für Request Assigned To Agent.
- First reply time - Timestamp: für First Agent Public Reply Sent.
- Ticket solved - Timestamp: für Service Request Resolved und Satisfaction Survey Sent.
- Ticket reopened - Timestamp: für Service Request Reopened.
- Satisfaction rating received - Timestamp: für Satisfaction Rating Received.
- Ticket closed - Timestamp: für Service Request Closed.
Benutzerdefinierte berechnete Attribute für weitere Aktivitäten erstellen: Einige Aktivitäten beruhen auf bestimmten Feldänderungen. Um ihren Timestamp zu erfassen, müssen Sie dafür benutzerdefinierte Attribute erstellen. Öffnen Sie das Menü „Berechnungen“ (Taschenrechner-Symbol) und wählen Sie „Standardmäßiges berechnetes Attribut“ aus. Erstellen Sie für jede der folgenden Aktivitäten ein Attribut. Die genauen Feld- und Wertnamen finden Sie in Ihrer Zendesk-Instanz.
- Name: Timestamp - Categorized and Prioritized. Formel: IF ([Changes - Field name] = "priority" OR [Changes - Field name] = "type") THEN [Update - Timestamp] ENDIF. Fügen Sie das neue Attribut anschließend dem Bereich „Zeilen“ hinzu und stellen Sie den Aggregator auf MIN.
- Name: Timestamp - Info Requested. Formel: IF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN [Update - Timestamp] ENDIF. Fügen Sie das Attribut zu „Zeilen“ hinzu und stellen Sie den Aggregator auf MIN.
- Name: Timestamp - Customer Responded. Formel: IF ([Changes - Field name] = "status" AND [Changes - Previous value] = "pending" AND [Changes - New value] = "open") THEN [Update - Timestamp] ENDIF. Fügen Sie das Attribut zu „Zeilen“ hinzu und stellen Sie den Aggregator auf MIN.
- Name: Timestamp - Escalated. Formel: IF ([Changes - Field name] = "group") THEN [Update - Timestamp] ENDIF. Fügen Sie das Attribut zu „Zeilen“ hinzu und stellen Sie den Aggregator auf MIN.
- Name: Timestamp - SLA Breach. Formel: IF ([SLA breach status]=TRUE) THEN [SLA update - Timestamp] ENDIF. Fügen Sie das Attribut zu „Zeilen“ hinzu und stellen Sie den Aggregator auf MIN.
Daten filtern: Öffnen Sie den Bereich „Filter“ und klicken Sie auf „Hinzufügen“. Filtern Sie nach Ticket created - Date und wählen Sie einen passenden Zeitraum, zum Beispiel die letzten 3 bis 6 Monate. So bleibt der Datensatz überschaubar.
Bericht ausführen und exportieren: Klicken Sie auf „Speichern“, um die Abfrage auszuführen. Sobald die Tabelle die Daten anzeigt, klicken Sie auf „Exportieren“ und wählen Sie das gewünschte Format, zum Beispiel CSV oder Excel.
Daten ins Event-Log-Format umwandeln: Die exportierte Datei liegt im „breiten“ Format vor: Jede Zeile entspricht einem Ticket, jede Spalte einem Ereignis-Timestamp. Für Process Mining müssen Sie die Daten in ein „langes“ Format umwandeln. Verwenden Sie dazu beispielsweise Microsoft Excel mit der Funktion „Spalten entpivotieren“ in Power Query, Python oder ein anderes Datenaufbereitungstool.
- Erstellen Sie für jede Zeile (Ticket) mehrere neue Zeilen, eine für jede Timestamp-Spalte mit einem Wert.
- Die fertige Tabelle sollte Spalten wie ServiceRequest, ActivityName, StartTime und die übrigen Attribute enthalten. Die Attribute werden für jede Aktivität eines Service Requests wiederholt.

Konfiguration

Datensatz: Verwenden Sie hauptsächlich den Datensatz Support: Tickets. Damit können Sie in einer Abfrage auf die meisten Ticketeigenschaften und wichtige Timestamps zugreifen.
Berechtigungen: Zum Erstellen und Speichern von Abfragen benötigen Sie in Zendesk Explore mindestens die Rolle Editor oder Admin.
Zeitraum: Legen Sie unbedingt einen Zeitraumfilter für Ticket created - Date fest. Empfohlen werden Daten aus den letzten 3 bis 6 Monaten, um aussagekräftige Ergebnisse bei guter Leistung zu erhalten. Der Export von Millionen Tickets kann lange dauern oder fehlschlagen.
Abfragefilter: Mit Filtern für bestimmte Ticketeigenschaften wie Ticket brand, Ticket form oder Ticket group können Sie die Analyse auf einen bestimmten Service oder ein Team eingrenzen.
Berechnete Attribute: Für diese Methode müssen Sie standardmäßige berechnete Attribute erstellen, um Timestamps von Ereignissen zu erfassen, die nicht als Standardattribute vorliegen, etwa Statusänderungen oder Eskalationen. Stellen Sie sicher, dass Sie die erforderlichen Berechtigungen zum Erstellen dieser Attribute haben.

a Beispielabfrage config

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

**Dataset**: `Support: Tickets`

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

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

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

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

Schritte

Zendesk-API-Zugriff vorbereiten: Melden Sie sich als Administrator bei Zendesk an. Öffnen Sie das Admin Center und gehen Sie zu Apps und Integrationen > APIs > Zendesk API. Aktivieren Sie auf der Registerkarte „Einstellungen“ den Token-Zugriff. Klicken Sie auf „API-Token hinzufügen“, um ein neues Token zu erstellen. Kopieren Sie das generierte Token sicher, da es später nicht erneut angezeigt wird.
Python-Umgebung einrichten: Stellen Sie sicher, dass Python 3.6 oder neuer installiert ist. Installieren Sie die Bibliothek requests, die für HTTP-Anfragen an die Zendesk-API benötigt wird. Verwenden Sie dazu die Befehlszeile: pip install requests.
Python-Skript konfigurieren: Speichern Sie das bereitgestellte Python-Skript in einer Datei, zum Beispiel extract_zendesk_log.py. Öffnen Sie die Datei in einem Texteditor und ersetzen Sie die Platzhaltervariablen am Anfang durch die Angaben und Zugangsdaten Ihrer Zendesk-Instanz: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL und API_TOKEN.
Extraktionszeitraum festlegen: Suchen Sie im Skript die Variable START_TIMESTAMP. Sie legt das historische Startdatum für die Datenextraktion fest und muss als Unix-Epoch-Timestamp angegeben werden. Für eine erste Analyse empfiehlt sich ein Wert, der den letzten 3 bis 6 Monaten entspricht.
Skript ausführen: Öffnen Sie ein Terminal oder eine Eingabeaufforderung und wechseln Sie in das Verzeichnis, in dem Sie das Skript gespeichert haben. Führen Sie es mit folgendem Befehl aus: python extract_zendesk_log.py.
Ausführung überwachen: Das Skript gibt im Terminal Fortschrittsmeldungen aus, darunter die Anzahl der verarbeiteten Tickets. Die Gesamtdauer hängt vom Datenvolumen und den von Zendesk festgelegten API-Ratenlimits ab. Das Skript enthält eine grundlegende Behandlung von Ratenlimit-Antworten.
Event Log abrufen: Nach erfolgreichem Abschluss erstellt das Skript im selben Verzeichnis die Datei zendesk_event_log.csv. Sie enthält das strukturierte Event Log für die Analyse.
Upload vorbereiten: Öffnen Sie die Datei zendesk_event_log.csv und prüfen Sie, ob sie korrekt erstellt wurde. Kontrollieren Sie, ob die Spalten den erforderlichen Attributen entsprechen: ServiceRequest, ActivityName, StartTime, SourceSystem und LastDataUpdate. Anschließend können Sie die Datei in das Process-Mining-Tool hochladen.

Konfiguration

API-Zugangsdaten: Das Skript benötigt eine gültige Zendesk-Subdomain, die E-Mail-Adresse eines Agenten oder Administrators sowie ein aktives API-Token. Der Benutzer, zu dem die Zugangsdaten gehören, muss Tickets, Ticket-Audits, Benutzer und Ticketkennzahlen lesen dürfen.
Zeitraum: Das Startdatum der Extraktion wird über die Variable START_TIMESTAMP im Skript festgelegt. Der Wert muss ein Unix-Epoch-Timestamp sein. Beginnen Sie am besten mit einem kürzeren Zeitraum, zum Beispiel 3 Monaten, um Ausgabe und Leistung des Skripts zu prüfen, bevor Sie einen längeren Zeitraum abrufen.
Incremental Export API: Diese Lösung verwendet die Incremental Export API von Zendesk. Sie eignet sich besonders für den effizienten Abruf großer Ticketmengen, da sie für den Massendatenexport ausgelegt ist und typische Probleme mit der Seitennavigation vermeidet.
Leistung und Ratenlimits: Zendesk setzt je nach Abonnementtarif unterschiedliche API-Ratenlimits durch. Wenn ein Ratenlimit erreicht wird, pausiert das Skript anhand des von der API zurückgegebenen Headers Retry-After. Bei sehr großen Instanzen kann die Extraktion mehrere Stunden dauern.
Voraussetzungen: Für diese Extraktionsmethode benötigen Sie eine funktionierende Python-3.6+-Umgebung und die externe Bibliothek requests. Zum Erstellen des erforderlichen API-Tokens ist Administratorzugriff auf die betreffende Zendesk-Instanz notwendig.

a Beispielabfrage python

import requests
import json
import time
import datetime
import csv

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                first_agent_reply_sent = False

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

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

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

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

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

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

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

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

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

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

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

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

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

Schritte

Prüfen Sie, ob Ihr Zendesk-Support-Konto den Zugriff auf die Incremental Exports API erlaubt und ob die Integrationsidentität Tickets, Ticketereignisse, Benutzer, Gruppen, Kommentare, Zufriedenheitsbewertungen und SLA-Daten lesen darf, sofern diese Funktionen aktiviert sind. Bestätigen Sie die Konto-Subdomain und die Authentifizierungsmethode anhand der von Ihrer Organisation freigegebenen Konfiguration.
Legen Sie eine Extraktionsstartzeit fest, die den benötigten Analysezeitraum abdeckt. Inkrementelle Ticketexporte verwenden einen Unix-Timestamp und geben Datensätze zurück, die ab diesem Zeitpunkt erstellt oder aktualisiert wurden. Für einen vollständigen historischen Ladevorgang verwenden Sie [Configure based on your system] als anfängliche Startzeit und speichern Sie anschließend die zurückgegebene Endzeit für weitere inkrementelle Läufe. Für regelmäßige Analysen empfiehlt sich ein Zeitraum von 3 bis 6 Monaten, sofern die Betriebshistorie ausreicht.
Führen Sie das Python-Extraktionsskript mit der Zendesk-Subdomain, den Authentifizierungsdaten, dem Start-Timestamp und optionalen unternehmensspezifischen Filtern aus. Das Skript ruft inkrementelle Ticketdaten ab, durchläuft die Seiten und speichert die Rohdatensätze sowie verfügbare Ereignisdetails vor der Umwandlung.
Rufen Sie für jedes Ticket den Audit- oder Ereignisverlauf ab, wenn die inkrementelle Ticketantwort nicht genügend Details zu Feldänderungen, Zuweisungen, Kommentaren oder Status enthält. Verwenden Sie nur Zendesk-API-Ressourcen, die in Ihrem Konto aktiviert und autorisiert sind. Speichern Sie, sofern verfügbar, die Quell-Ticket-ID, Audit-ID, Kommentar-ID, den Ereignis-Timestamp, den Akteur, den Feldnamen sowie den vorherigen und den neuen Wert.
Vereinheitlichen Sie die Timestamps auf UTC und wandeln Sie Unix-Timestamps oder ISO-8601-Werte in ein einheitliches Datums- und Zeitformat um. Sortieren Sie die Quelldatensätze nach ServiceRequest, Ereignis-Timestamp und Quellereignis-ID. Entfernen Sie Duplikate anhand der spezifischsten verfügbaren stabilen Quellkennung, zum Beispiel einer Audit- oder Kommentar-ID.
Erstellen Sie für alle 14 erforderlichen Aktivitäten explizite Event-Log-Zeilen. Gehen Sie nicht davon aus, dass ProcessMind Aktivitäten aus Statusänderungen oder Feldwerten ableitet. Erzeugen Sie Service Request Created anhand der Ticketerstellung, Initial Acknowledgment Sent anhand einer bestätigten automatisierten ersten Antwort, Request Categorized And Prioritized anhand von Änderungen an Kategorie, Typ oder Priorität, Request Assigned To Agent anhand von Änderungen am zuständigen Agenten, First Agent Public Reply Sent anhand des ersten passenden öffentlichen Kommentars eines Agenten, Information Requested From Customer anhand eines Übergangs zu „pending“, der mit einer Informationsanfrage verbunden ist, Customer Responded anhand einer passenden Kundenantwort, Internal Escalation Triggered anhand einer Änderung der zugewiesenen Gruppe, SLA Breach Occurred anhand eines bestätigten SLA-Verstoß-Timestamps oder eines ausdrücklich berechneten Verstoßes, Service Request Resolved anhand eines Übergangs zu „solved“, Service Request Reopened anhand eines durch eine Kundenantwort ausgelösten Übergangs von „solved“ zu „open“, Satisfaction Survey Sent anhand eines bestätigten Versands der Umfrage, Satisfaction Rating Received anhand einer abgegebenen Bewertung und Service Request Closed anhand eines Übergangs zu „closed“ oder eines bestätigten endgültigen Abschlussereignisses.
Füllen Sie die erforderlichen Spalten ServiceRequest, ActivityName, StartTime, SourceSystem und LastDataUpdate aus. Ergänzen Sie die empfohlenen Spalten AssignedAgent, ServiceRequestType, Priority, CommunicationChannel, SlaTargetResolutionTime und IsSlaBreached, sofern die Quelle zuverlässige Werte liefert. Verwenden Sie für nicht verfügbare optionale Attribute Nullwerte, statt Werte zu erfinden.
Wenden Sie freigegebene unternehmensspezifische Filter nach der Extraktion und vor dem Export an. Bewahren Sie die Quellkennungen und Quell-Timestamps in einer internen Staging-Kopie auf, damit sich die Entscheidungen zu den Ereignissen prüfen und erneut ausführen lassen.
Prüfen Sie Zeilenanzahl, Abdeckung der Aktivitäten, Timestamp-Reihenfolge, Umgang mit Duplikaten und Befüllung der Attribute. Stellen Sie sicher, dass jede ausgegebene Zeile ServiceRequest, ActivityName, StartTime, SourceSystem und LastDataUpdate enthält.
Exportieren Sie das umgewandelte Event Log als UTF-8-CSV oder in einem anderen von ProcessMind unterstützten Tabellenformat. Achten Sie darauf, dass die Spaltennamen exakt den erforderlichen Attributnamen entsprechen, jede Aktivität einmal pro Zeile steht und die Datei über den konfigurierten ProcessMind-Import hochgeladen wird.

Konfiguration

Extraktionsmethode: Verwenden Sie für den Abruf großer Ticketmengen die Zendesk Incremental Exports API. Das Skript sollte Daten ab einem gespeicherten Unix-Start-Timestamp abrufen, alle Seiten durchlaufen, Ratenlimits beachten und den zurückgegebenen End-Timestamp für den nächsten Lauf speichern.
Authentifizierung: Richten Sie die von Ihrer Organisation freigegebene Zendesk-Authentifizierungsmethode, Konto-Subdomain, Zugangsdaten und API-Berechtigungen gemäß den Sicherheitsrichtlinien ein. Speichern Sie Zugangsdaten nicht direkt in der Versionsverwaltung.
Zeitraum: Verwenden Sie für regelmäßige Prozessanalysen Daten aus den letzten 3 bis 6 Monaten. Wählen Sie für den ersten Ladevorgang eine Startzeit, die vor dem benötigten Prozesszeitraum liegt, da Aktivitäten zu Tickets, die früher erstellt wurden, in den Analysezeitraum fallen können. Verwenden Sie für inkrementelle Ladevorgänge den Zeitstempel des letzten erfolgreichen Abrufs mit einem kleinen Überlappungszeitraum, um verspätete Aktualisierungen zu erfassen. Entfernen Sie anschließend Duplikate anhand der Quellkennungen.
Filter: Verwenden Sie nur Filter, die von den in Ihrem Konto verfügbaren Zendesk-Ressourcen unterstützt werden, etwa freigegebene Filter für Organisation, Gruppe, Marke, Tickettyp, Status oder benutzerdefinierte Felder. Richten Sie unternehmensspezifische Filter anhand Ihres Systems ein. Gehen Sie nicht davon aus, dass Zendesk ein Feld für Company Code oder Document Type enthält.
Erforderliche Ausgabespalten: ServiceRequest, ActivityName, StartTime, SourceSystem und LastDataUpdate.
Empfohlene Ausgabespalten: AssignedAgent, ServiceRequestType, Priority, CommunicationChannel, SlaTargetResolutionTime und IsSlaBreached.
Ereignisdetails: Inkrementelle Ticketdatensätze allein enthalten möglicherweise nicht alle historischen Übergänge. Rufen Sie bei Bedarf autorisierte Ticket-Audits, Kommentare, Zufriedenheitsdaten und SLA-Ereignisse ab. Geben Sie jede erforderliche Aktivität ausdrücklich als eigene Zeile aus.
SLA-Konfiguration: Verwenden Sie nach Möglichkeit die tatsächlichen SLA-Richtlinien und Verstoß-Timestamps des Kontos. Wenn Sie den Verstoßstatus berechnen, dokumentieren Sie die verwendete Richtlinie, Geschäftszeiten, Pausen und Zeitzone. Berechnen Sie einen Verstoß nicht allein anhand der verstrichenen Echtzeit, wenn Regeln zu Geschäftszeiten gelten.
Leistung: Verarbeiten Sie die Seiten schrittweise, lesen Sie Datensätze als Stream oder in Stapeln ein, speichern Sie Ticketdetails zwischen, begrenzen Sie parallele Anfragen, beachten Sie Zendesk-Ratenlimit-Antworten und sichern Sie den Fortschritt nach erfolgreich verarbeiteten Seiten. Rufen Sie nicht wiederholt den gesamten Verlauf ab.
Datenaufbewahrung: Bewahren Sie rohe API-Antworten, Extraktionszeitstempel, Anfragemetadaten und Umwandlungsprotokolle für Abgleiche und erneute Läufe auf.
Voraussetzungen: Erforderlich sind Zendesk-API-Zugriff, Leseberechtigungen für die relevanten Ticket- und Ereignisressourcen, aktivierte Ticket-Audits und Kommentare, sofern benötigt, Zugriff auf Zufriedenheitsdaten für CSAT-Aktivitäten sowie Zugriff auf SLA-Daten für SLA-Verstoß-Aktivitäten. Die Verfügbarkeit von Funktionen hängt vom Zendesk-Tarif und der Kontokonfiguration ab.

a Beispielabfrage python

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

import requests

ZENDESK_SUBDOMAIN = os.environ.get(class="hl-string">"ZENDESK_SUBDOMAIN", class="hl-string">"[Configure based on your system]")
ZENDESK_EMAIL = os.environ.get(class="hl-string">"ZENDESK_EMAIL", class="hl-string">"[Configure based on your system]")
ZENDESK_API_TOKEN = os.environ.get(class="hl-string">"ZENDESK_API_TOKEN", class="hl-string">"[Configure based on your system]")
START_TIME = os.environ.get(class="hl-string">"START_TIME", class="hl-string">"[Configure based on your system]")
OUTPUT_FILE = os.environ.get(class="hl-string">"OUTPUT_FILE", class="hl-string">"zendesk_processmind_event_log.csv")
SOURCE_SYSTEM = class="hl-string">"Zendesk Support"

REQUIRED_COLUMNS = [
    class="hl-string">"ServiceRequest",
    class="hl-string">"ActivityName",
    class="hl-string">"StartTime",
    class="hl-string">"SourceSystem",
    class="hl-string">"LastDataUpdate",
]
RECOMMENDED_COLUMNS = [
    class="hl-string">"AssignedAgent",
    class="hl-string">"ServiceRequestType",
    class="hl-string">"Priority",
    class="hl-string">"CommunicationChannel",
    class="hl-string">"SlaTargetResolutionTime",
    class="hl-string">"IsSlaBreached",
]
ALL_COLUMNS = REQUIRED_COLUMNS + RECOMMENDED_COLUMNS


def fail(message: str) -> None:
    raise RuntimeError(message)


def parse_start_time(value: str) -> int:
    if value.isdigit():
        return int(value)
    try:
        return int(datetime.fromisoformat(value.replace(class="hl-string">"Z", class="hl-string">"+00:00")).timestamp())
    except ValueError as exc:
        raise RuntimeError(class="hl-string">"START_TIME must be a Unix timestamp or ISO 8601 timestamp") from exc


def iso_timestamp(value: Any) -> Optional[str]:
    if value is None or value == class="hl-string">"":
        return None
    if isinstance(value, (int, float)):
        return datetime.fromtimestamp(value, tz=timezone.utc).isoformat().replace(class="hl-string">"+00:00", class="hl-string">"Z")
    text = str(value)
    if text.isdigit():
        return datetime.fromtimestamp(int(text), tz=timezone.utc).isoformat().replace(class="hl-string">"+00:00", class="hl-string">"Z")
    return text


def now_utc() -> str:
    return datetime.now(timezone.utc).isoformat().replace(class="hl-string">"+00:00", class="hl-string">"Z")


def api_get(session: requests.Session, path: str, params: Optional[Dict[str, Any]] = None) -> Dict[str, Any]:
    url = fclass="hl-string">"https://{ZENDESK_SUBDOMAIN}.zendesk.com{path}"
    while True:
        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, 1))
            continue
        response.raise_for_status()
        return response.json()


def paged_get(session: requests.Session, path: str, params: Optional[Dict[str, Any]] = None) -> Iterable[Dict[str, Any]]:
    next_url: Optional[str] = fclass="hl-string">"https://{ZENDESK_SUBDOMAIN}.zendesk.com{path}"
    next_params = params
    while next_url:
        while True:
            response = session.get(next_url, params=next_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, 1))
                continue
            response.raise_for_status()
            payload = response.json()
            break
        for item in payload.get(class="hl-string">"tickets", payload.get(class="hl-string">"audits", payload.get(class="hl-string">"comments", payload.get(class="hl-string">"results", [])))):
            yield item
        next_url = payload.get(class="hl-string">"next_page")
        next_params = None


def get_user_name(session: requests.Session, user_id: Any, cache: Dict[str, str]) -> Optional[str]:
    if not user_id:
        return None
    key = str(user_id)
    if key in cache:
        return cache[key]
    try:
        user = api_get(session, fclass="hl-string">"/api/v2/users/{key}.json").get(class="hl-string">"user", {})
        name = user.get(class="hl-string">"name") or user.get(class="hl-string">"email") or key
        cache[key] = str(name)
        return cache[key]
    except requests.HTTPError:
        cache[key] = key
        return key


def get_group_name(session: requests.Session, group_id: Any, cache: Dict[str, str]) -> Optional[str]:
    if not group_id:
        return None
    key = str(group_id)
    if key in cache:
        return cache[key]
    try:
        group = api_get(session, fclass="hl-string">"/api/v2/groups/{key}.json").get(class="hl-string">"group", {})
        name = group.get(class="hl-string">"name") or key
        cache[key] = str(name)
        return cache[key]
    except requests.HTTPError:
        cache[key] = key
        return key


def ticket_field(ticket: Dict[str, Any], names: List[str]) -> Any:
    for name in names:
        if ticket.get(name) is not None:
            return ticket.get(name)
    return None


def base_row(ticket: Dict[str, Any], activity: str, event_time: Any, last_update: str, user_cache: Dict[str, str]) -> Dict[str, Any]:
    return {
        class="hl-string">"ServiceRequest": str(ticket.get(class="hl-string">"id")),
        class="hl-string">"ActivityName": activity,
        class="hl-string">"StartTime": iso_timestamp(event_time),
        class="hl-string">"SourceSystem": SOURCE_SYSTEM,
        class="hl-string">"LastDataUpdate": last_update,
        class="hl-string">"AssignedAgent": get_user_name(session, ticket.get(class="hl-string">"assignee_id"), user_cache),
        class="hl-string">"ServiceRequestType": ticket.get(class="hl-string">"type"),
        class="hl-string">"Priority": ticket.get(class="hl-string">"priority"),
        class="hl-string">"CommunicationChannel": ticket.get(class="hl-string">"via", {}).get(class="hl-string">"channel") if isinstance(ticket.get(class="hl-string">"via"), dict) else ticket.get(class="hl-string">"via"),
        class="hl-string">"SlaTargetResolutionTime": ticket.get(class="hl-string">"sla_target_resolution_time"),
        class="hl-string">"IsSlaBreached": ticket.get(class="hl-string">"is_sla_breached"),
    }


def add_event(events: List[Dict[str, Any]], seen: set, ticket: Dict[str, Any], activity: str, event_time: Any, last_update: str, user_cache: Dict[str, str], source_key: str) -> None:
    if event_time is None:
        return
    key = (str(ticket.get(class="hl-string">"id")), activity, source_key, str(event_time))
    if key in seen:
        return
    seen.add(key)
    events.append(base_row(ticket, activity, event_time, last_update, user_cache))


def audit_events(session: requests.Session, ticket_id: Any) -> List[Dict[str, Any]]:
    return list(paged_get(session, fclass="hl-string">"/api/v2/tickets/{ticket_id}/audits.json"))


def audit_events_for_field(audit: Dict[str, Any], field_names: List[str]) -> List[Tuple[str, Any, Any]]:
    output: List[Tuple[str, Any, Any]] = []
    for event in audit.get(class="hl-string">"events", []):
        if event.get(class="hl-string">"type") != class="hl-string">"Change":
            continue
        field = str(event.get(class="hl-string">"field_name") or event.get(class="hl-string">"field") or class="hl-string">"")
        if field in field_names:
            output.append((field, event.get(class="hl-string">"previous_value"), event.get(class="hl-string">"value")))
    return output


def is_customer_actor(audit: Dict[str, Any], ticket: Dict[str, Any]) -> bool:
    author_id = audit.get(class="hl-string">"author_id")
    requester_id = ticket.get(class="hl-string">"requester_id")
    return author_id is not None and requester_id is not None and str(author_id) == str(requester_id)


def is_public_comment(event: Dict[str, Any]) -> bool:
    return event.get(class="hl-string">"type") in {class="hl-string">"Comment", class="hl-string">"VoiceComment"} and event.get(class="hl-string">"public") is not False


def is_automated_acknowledgment(event: Dict[str, Any]) -> bool:
    body = str(event.get(class="hl-string">"body") or event.get(class="hl-string">"html_body") or class="hl-string">"").lower()
    marker = str(event.get(class="hl-string">"via", {}).get(class="hl-string">"channel") if isinstance(event.get(class="hl-string">"via"), dict) else event.get(class="hl-string">"via") or class="hl-string">"").lower()
    return class="hl-string">"acknowledg" in body or class="hl-string">"received your request" in body or marker in {class="hl-string">"trigger", class="hl-string">"automation", class="hl-string">"system"}


def extract_ticket_events(session: requests.Session, ticket: Dict[str, Any], last_update: str, user_cache: Dict[str, str], group_cache: Dict[str, str], seen: set) -> List[Dict[str, Any]]:
    events: List[Dict[str, Any]] = []
    ticket_id = ticket.get(class="hl-string">"id")
    audits = audit_events(session, ticket_id)
    audits.sort(key=lambda item: (str(item.get(class="hl-string">"created_at") or class="hl-string">""), str(item.get(class="hl-string">"id") or class="hl-string">"")))
    add_event(events, seen, ticket, class="hl-string">"Service Request Created", ticket.get(class="hl-string">"created_at"), last_update, user_cache, class="hl-string">"ticket_created")
    first_public_agent_reply = False
    first_ack = False
    for audit in audits:
        audit_time = audit.get(class="hl-string">"created_at")
        audit_id = str(audit.get(class="hl-string">"id") or audit_time)
        for event in audit.get(class="hl-string">"events", []):
            event_type = event.get(class="hl-string">"type")
            if event_type in {class="hl-string">"Comment", class="hl-string">"VoiceComment"} and is_public_comment(event):
                if not first_ack and is_automated_acknowledgment(event):
                    add_event(events, seen, ticket, class="hl-string">"Initial Acknowledgment Sent", audit_time, last_update, user_cache, audit_id + class="hl-string">":ack")
                    first_ack = True
                if not is_customer_actor(audit, ticket) and not first_public_agent_reply and not is_automated_acknowledgment(event):
                    add_event(events, seen, ticket, class="hl-string">"First Agent Public Reply Sent", audit_time, last_update, user_cache, audit_id + class="hl-string">":first_agent_reply")
                    first_public_agent_reply = True
                if is_customer_actor(audit, ticket):
                    add_event(events, seen, ticket, class="hl-string">"Customer Responded", audit_time, last_update, user_cache, audit_id + class="hl-string">":customer_reply")
            if event_type == class="hl-string">"Change":
                field = str(event.get(class="hl-string">"field_name") or event.get(class="hl-string">"field") or class="hl-string">"")
                previous = event.get(class="hl-string">"previous_value")
                value = event.get(class="hl-string">"value")
                if field in {class="hl-string">"type", class="hl-string">"priority", class="hl-string">"custom_fields"}:
                    add_event(events, seen, ticket, class="hl-string">"Request Categorized And Prioritized", audit_time, last_update, user_cache, audit_id + class="hl-string">":category_priority:" + field)
                if field in {class="hl-string">"assignee_id", class="hl-string">"assignee"} and value not in (None, class="hl-string">"", 0, class="hl-string">"0"):
                    add_event(events, seen, ticket, class="hl-string">"Request Assigned To Agent", audit_time, last_update, user_cache, audit_id + class="hl-string">":assignee")
                if field in {class="hl-string">"group_id", class="hl-string">"group"} and previous not in (None, class="hl-string">"", 0, class="hl-string">"0") and value not in (None, class="hl-string">"", 0, class="hl-string">"0") and str(previous) != str(value):
                    get_group_name(session, value, group_cache)
                    add_event(events, seen, ticket, class="hl-string">"Internal Escalation Triggered", audit_time, last_update, user_cache, audit_id + class="hl-string">":group")
                if field == class="hl-string">"status":
                    old_status = str(previous or class="hl-string">"").lower()
                    new_status = str(value or class="hl-string">"").lower()
                    if new_status == class="hl-string">"pending":
                        add_event(events, seen, ticket, class="hl-string">"Information Requested From Customer", audit_time, last_update, user_cache, audit_id + class="hl-string">":pending")
                    if new_status == class="hl-string">"solved":
                        add_event(events, seen, ticket, class="hl-string">"Service Request Resolved", audit_time, last_update, user_cache, audit_id + class="hl-string">":solved")
                    if old_status == class="hl-string">"solved" and new_status == class="hl-string">"open":
                        add_event(events, seen, ticket, class="hl-string">"Service Request Reopened", audit_time, last_update, user_cache, audit_id + class="hl-string">":reopened")
                    if new_status == class="hl-string">"closed":
                        add_event(events, seen, ticket, class="hl-string">"Service Request Closed", audit_time, last_update, user_cache, audit_id + class="hl-string">":closed")
                if field in {class="hl-string">"satisfaction_survey_sent", class="hl-string">"csat_survey_sent"} and str(value).lower() in {class="hl-string">"true", class="hl-string">"1", class="hl-string">"yes", class="hl-string">"sent"}:
                    add_event(events, seen, ticket, class="hl-string">"Satisfaction Survey Sent", audit_time, last_update, user_cache, audit_id + class="hl-string">":survey_sent")
                if field in {class="hl-string">"sla_breached", class="hl-string">"is_sla_breached"} and str(value).lower() in {class="hl-string">"true", class="hl-string">"1", class="hl-string">"yes"}:
                    row = base_row(ticket, class="hl-string">"SLA Breach Occurred", audit_time, last_update, user_cache)
                    row[class="hl-string">"IsSlaBreached"] = True
                    key = (str(ticket_id), class="hl-string">"SLA Breach Occurred", audit_id, str(audit_time))
                    if key not in seen:
                        seen.add(key)
                        events.append(row)
    try:
        satisfaction = api_get(session, fclass="hl-string">"/api/v2/tickets/{ticket_id}/satisfaction_rating.json").get(class="hl-string">"satisfaction_rating")
    except requests.HTTPError:
        satisfaction = None
    if satisfaction:
        add_event(events, seen, ticket, class="hl-string">"Satisfaction Rating Received", satisfaction.get(class="hl-string">"created_at") or satisfaction.get(class="hl-string">"updated_at"), last_update, user_cache, str(satisfaction.get(class="hl-string">"id") or class="hl-string">"rating"))
    return events


def validate_rows(rows: List[Dict[str, Any]]) -> None:
    activities = {
        class="hl-string">"Service Request Created",
        class="hl-string">"Initial Acknowledgment Sent",
        class="hl-string">"Request Categorized And Prioritized",
        class="hl-string">"Request Assigned To Agent",
        class="hl-string">"First Agent Public Reply Sent",
        class="hl-string">"Information Requested From Customer",
        class="hl-string">"Customer Responded",
        class="hl-string">"Internal Escalation Triggered",
        class="hl-string">"SLA Breach Occurred",
        class="hl-string">"Service Request Resolved",
        class="hl-string">"Service Request Reopened",
        class="hl-string">"Satisfaction Survey Sent",
        class="hl-string">"Satisfaction Rating Received",
        class="hl-string">"Service Request Closed",
    }
    missing_columns = [column for column in ALL_COLUMNS if column not in rows[0]] if rows else ALL_COLUMNS
    if missing_columns:
        fail(class="hl-string">"Missing output columns: " + class="hl-string">", ".join(missing_columns))
    invalid = [row for row in rows if not row.get(class="hl-string">"ServiceRequest") or not row.get(class="hl-string">"ActivityName") or not row.get(class="hl-string">"StartTime") or not row.get(class="hl-string">"SourceSystem") or not row.get(class="hl-string">"LastDataUpdate")]
    if invalid:
        fail(fclass="hl-string">"{len(invalid)} rows are missing required values")
    unexpected = sorted({row[class="hl-string">"ActivityName"] for row in rows} - activities)
    if unexpected:
        fail(class="hl-string">"Unexpected activity names: " + class="hl-string">", ".join(unexpected))


def main() -> None:
    global session
    if ZENDESK_SUBDOMAIN.startswith(class="hl-string">"[") or ZENDESK_EMAIL.startswith(class="hl-string">"[") or ZENDESK_API_TOKEN.startswith(class="hl-string">"[") or START_TIME.startswith(class="hl-string">"["):
        fail(class="hl-string">"Configure ZENDESK_SUBDOMAIN, ZENDESK_EMAIL, ZENDESK_API_TOKEN, and START_TIME")
    start_time = parse_start_time(START_TIME)
    session = requests.Session()
    session.auth = (fclass="hl-string">"{ZENDESK_EMAIL}/token", ZENDESK_API_TOKEN)
    session.headers.update({class="hl-string">"Accept": class="hl-string">"application/json"})
    last_update = now_utc()
    user_cache: Dict[str, str] = {}
    group_cache: Dict[str, str] = {}
    seen = set()
    rows: List[Dict[str, Any]] = []
    tickets = paged_get(session, class="hl-string">"/api/v2/incremental/tickets/cursor.json", {class="hl-string">"start_time": start_time})
    for ticket in tickets:
        rows.extend(extract_ticket_events(session, ticket, last_update, user_cache, group_cache, seen))
    rows.sort(key=lambda row: (row[class="hl-string">"ServiceRequest"], row[class="hl-string">"StartTime"], row[class="hl-string">"ActivityName"]))
    validate_rows(rows)
    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=ALL_COLUMNS, extrasaction=class="hl-string">"ignore")
        writer.writeheader()
        writer.writerows(rows)
    print(json.dumps({class="hl-string">"output_file": OUTPUT_FILE, class="hl-string">"rows": len(rows), class="hl-string">"last_data_update": last_update}))


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

Schritte

Wählen Sie eine kommerzielle ETL- oder ELT-Plattform mit einem unterstützten Zendesk-Support-Konnektor aus. Prüfen Sie, ob der Konnektor Tickets, Ticketereignisse oder Audits, Kommentare, Benutzer, Gruppen, Zufriedenheitsbewertungen, SLA-Daten sowie in Ihrem Zendesk-Konto verfügbare Trigger- oder Automatisierungsergebnisse replizieren kann.
Richten Sie eine Zendesk-API-Integration mit der von Ihrer Organisation und dem ausgewählten Konnektor unterstützten Authentifizierungsmethode ein. Gewähren Sie nur die erforderlichen Leseberechtigungen für Ticket-, Audit-, Kommentar-, Benutzer-, Gruppen-, Zufriedenheits- und SLA-Daten. Speichern Sie Verbindungszeichenfolge und Zugangsdaten im sicheren Zugangsdaten-Speicher des Tools.
Konfigurieren Sie den Konnektor so, dass er die benötigten Zendesk-Objekte in das Ziel-Data-Warehouse repliziert. Verwenden Sie die vom Konnektor erzeugten Quellobjekte, statt feste Tabellen- oder Spaltennamen vorauszusetzen. Dokumentieren Sie die tatsächlichen Objekt- und Feldzuordnungen im Projekt, zum Beispiel als [Your table name] und [Your column name], wenn der Konnektor kontospezifische Namen verwendet.
Richten Sie die inkrementelle Extraktion anhand des unterstützten Aktualisierungs-Timestamps, Cursors oder Änderungsverfolgungsmechanismus des Quellsystems ein. Berücksichtigen Sie historische Daten für den ausgewählten Analysezeitraum, üblicherweise drei bis sechs Monate, und bewahren Sie die Quellereignis- oder Audit-ID auf, damit wiederholte Aktualisierungen dedupliziert werden können.
Erstellen Sie ein normalisiertes Staging-Modell, das Ticketdatensätze mit Ticketverläufen, Audit- oder Ereignisdatensätzen, Kommentaren, Benutzern, Gruppen, Zufriedenheitsbewertungen, SLA-Datensätzen sowie konnektorspezifischen Trigger- oder Automatisierungsdatensätzen zusammenführt. Bewahren Sie nach Möglichkeit den ursprünglichen Quell-Timestamp, die Quell-Datensatz-ID, die Ticket-ID, die Akteur-ID, den Ereignistyp, den Feldnamen sowie den vorherigen und neuen Wert auf.
Erstellen Sie eine Ereignisumwandlung, die für jede ausdrücklich erfasste Aktivität eine Zeile ausgibt. Ordnen Sie die Ticketerstellung Service Request Created zu, die passende automatisierte erste Antwort Initial Acknowledgment Sent, Änderungen an Typ, Kategorie oder Priorität Request Categorized And Prioritized, Änderungen am zuständigen Agenten Request Assigned To Agent, die erste passende öffentliche Antwort eines Agenten First Agent Public Reply Sent, einen mit einer Informationsanfrage verbundenen Übergang zu „pending“ Information Requested From Customer, eine Kundenantwort Customer Responded, Gruppenänderungen Internal Escalation Triggered, einen erfassten SLA-Verstoßdatensatz oder ein Verstoßereignis SLA Breach Occurred, Übergänge zu „solved“ Service Request Resolved, durch eine Kundenantwort ausgelöste Übergänge von „solved“ zu „open“ Service Request Reopened, einen erfassten Versand der Umfrage Satisfaction Survey Sent, eine abgegebene Bewertung Satisfaction Rating Received und einen endgültigen Übergang zu „closed“ Service Request Closed.
Erstellen Sie keine abgeleiteten Zeilen allein anhand des aktuellen Ticketstatus oder der verstrichenen Zeit. Wenn die Quelle keinen Versand einer Umfrage, keinen SLA-Verstoß, keine automatisierte Bestätigung oder kein endgültiges Abschlussereignis ausdrücklich erfasst, lassen Sie die Aktivität weg oder verwenden Sie einen separat dokumentierten Datenfeed, der sie ausdrücklich protokolliert. ProcessMind übernimmt das Event Log unverändert und leitet fehlende Ereignisse nicht ab.
Entfernen Sie Duplikate nach Möglichkeit anhand der Quellereignis- oder Audit-ID. Gibt es keine stabile Kennung, verwenden Sie einen dokumentierten zusammengesetzten Schlüssel aus ServiceRequest, ActivityName, StartTime, Akteur und Quell-Datensatz-ID. Bewahren Sie mehrere legitime Vorkommen von Aktivitäten wie Customer Responded, Information Requested From Customer, Internal Escalation Triggered und Service Request Reopened auf.
Füllen Sie die erforderlichen Ausgabespalten ServiceRequest, ActivityName, StartTime, SourceSystem und LastDataUpdate aus. Ergänzen Sie AssignedAgent, ServiceRequestType, Priority, CommunicationChannel, SlaTargetResolutionTime und IsSlaBreached, sofern die Quelle diese Werte bereitstellt. Verwenden Sie ein einheitliches UTC-Timestamp-Format und bewahren Sie die Regel zur Umrechnung der Quellzeitzone auf.
Exportieren Sie das fertige Event Log als ProcessMind-kompatible CSV-Datei oder laden Sie es in den konfigurierten ProcessMind-Eingangsbereich. Stellen Sie sicher, dass jede Aktivität einmal pro Zeile steht, ServiceRequest die Case-Kennung ist, ActivityName die exakten Aktivitätsbezeichnungen enthält, StartTime ein gültiger Timestamp ist und die erforderlichen Attribute in jeder technisch verfügbaren Ausgabezeile vorhanden sind.

Konfiguration

Konnektor und Quellumfang: Richten Sie das ausgewählte kommerzielle ETL- oder ELT-Tool für Zendesk Support ein und wählen Sie die Quellobjekte aus, die Tickets, Ticket-Audits oder -Ereignisse, Kommentare, Benutzer, Gruppen, Zufriedenheitsbewertungen, SLA-Informationen sowie Automatisierungs- oder Triggerergebnisse enthalten. Die Objektnamen unterscheiden sich je nach Konnektor und Konto. Verwenden Sie daher den tatsächlichen Katalog des Konnektors und keine angenommenen Tabellennamen.
Authentifizierung und Autorisierung: Verwenden Sie die von Ihrer Organisation freigegebene Zendesk-Authentifizierungsmethode. Gewähren Sie Lesezugriff auf alle ausgewählten Quellobjekte, einschließlich historischer Ticketereignisse und Kundenzufriedenheitsdaten. Prüfen Sie, ob API-Zugriff, erforderliche Zendesk-Tariffunktionen und eine etwaige Konnektorlizenz aktiviert sind.
Zeitraum: Beginnen Sie mit drei bis sechs Monaten Datenhistorie. Erweitern Sie den Zeitraum erst, nachdem Sie API-Kontingente, Data-Warehouse-Kapazität, Ereignisvolumen und Verfügbarkeit historischer Audit-, SLA- und Zufriedenheitsdaten geprüft haben.
Inkrementelles Laden: Verwenden Sie bevorzugt den nativen Cursor, die Änderungsverfolgung oder den Aktualisierungs-Timestamp des Konnektors. Planen Sie zunächst einen historischen Ladevorgang und anschließend häufige inkrementelle Ladevorgänge. Berücksichtigen Sie einen Rückblickzeitraum für verspätete Kommentare, Bewertungen, SLA-Ergebnisse und Ticketaktualisierungen.
Aktivitätsfilter: Filtern Sie Quelldatensätze nach dem ausgewählten Analysezeitraum und der relevanten Zendesk-Support-Instanz. Filtern Sie nicht ausschließlich nach dem aktuellen Ticketstatus, da historische Aktivitäten zu Tickets gehören können, deren Status sich inzwischen geändert hat.
Unternehmens- oder Kontofilter: Wenn der Konnektor mehrere Zendesk-Instanzen, Marken, Organisationen oder Geschäftseinheiten bereitstellt, wenden Sie den freigegebenen Unternehmens- oder Kontofilter anhand des tatsächlichen Feldes im Konnektor an. Gehen Sie nicht davon aus, dass ein Feld für Company Code vorhanden ist.
Ereigniszuordnung: Führen Sie eine explizite Zuordnungstabelle von Quellereignistyp, Feldname, Statusübergang, Akteurtyp und Automatisierungskennzeichen zu den 14 erforderlichen ActivityName-Werten. Geben Sie eine Zeile nur aus, wenn die Quelle den jeweiligen Vorgang ausdrücklich belegt.
Erkennung von Bestätigungen: Ordnen Sie Initial Acknowledgment Sent nur dann zu, wenn die Quelle eine automatisierte erste Antwort oder eine gleichwertige, durch einen Trigger erzeugte Benachrichtigung ausweist. Klassifizieren Sie eine Antwort eines Agenten nicht ohne Beleg aus der Quelle als automatisierte Bestätigung.
SLA-Verarbeitung: Verwenden Sie explizite SLA-Verstoßdatensätze oder vom Konnektor bereitgestellte SLA-Ergebnisse. Speichern Sie die Zieldauer in SlaTargetResolutionTime und das Verstoß-Ergebnis in IsSlaBreached. Berechnen Sie einen Verstoß nur dann anhand der verstrichenen Zeit, wenn SLA-Kalender, Richtlinie, Geschäftszeiten und Zielwert vorliegen und die Berechnung dokumentiert ist.
Leistung: Begrenzen Sie den ersten Ladevorgang auf einen Zeitraum, übernehmen Sie nur erforderliche Spalten, verwenden Sie inkrementelle Replikation, aktivieren Sie nach Möglichkeit Partitionierung oder Clustering im Data Warehouse für ServiceRequest und StartTime und materialisieren Sie das normalisierte Ereignismodell nach der Rohdatenübernahme. Vermeiden Sie wiederholte vollständige Scans des Ticketverlaufs.
Datenqualität: Bewahren Sie Quellkennungen und Timestamps auf, vereinheitlichen Sie Timestamps auf UTC, standardisieren Sie boolesche Werte und übernehmen Sie Nullwerte, wenn die Quelle ein Attribut nicht bereitstellt. Ersetzen Sie fehlende Angaben zu Agent, Kategorie, Priorität, SLA oder Kanal nicht durch erfundene Werte.
Aktualisierungszeitpunkt: Setzen Sie LastDataUpdate auf den Timestamp des abgeschlossenen Extraktions- oder Umwandlungslaufs. Verwenden Sie im gesamten Event Log eine einheitliche Zeitzone und ein einheitliches Format.

a Beispielabfrage config

WITH source_data AS (
    SELECT
        [Your ticket identifier column] AS service_request,
        [Your source event identifier column] AS source_event_id,
        [Your event type column] AS source_event_type,
        [Your field name column] AS source_field_name,
        [Your previous value column] AS previous_value,
        [Your new value column] AS new_value,
        [Your event timestamp column] AS event_time,
        [Your actor type column] AS actor_type,
        [Your actor identifier column] AS actor_id,
        [Your assigned agent column] AS assigned_agent,
        [Your request type column] AS service_request_type,
        [Your priority column] AS priority,
        [Your communication channel column] AS communication_channel,
        [Your SLA target resolution time column] AS sla_target_resolution_time,
        [Your SLA breached flag column] AS is_sla_breached,
        [Your automated response flag column] AS is_automated_response,
        [Your public comment flag column] AS is_public_comment,
        [Your customer reply flag column] AS is_customer_reply,
        [Your survey sent flag column] AS is_survey_sent,
        [Your satisfaction rating column] AS satisfaction_rating,
        [Your source system value] AS source_system,
        [Your extraction timestamp column] AS last_data_update
    FROM [Your normalized Zendesk event source]
    WHERE [Your event timestamp column] >= [Your start date parameter]
      AND [Your event timestamp column] < [Your end date parameter]
),
activity_events AS (
    SELECT service_request, 'Service Request Created' AS activity_name, event_time AS start_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_created'
    UNION ALL
    SELECT service_request, 'Initial Acknowledgment Sent', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'comment_added' AND is_automated_response = TRUE AND is_public_comment = TRUE
    UNION ALL
    SELECT service_request, 'Request Categorized And Prioritized', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_field_changed' AND source_field_name IN ('type', 'category', 'priority')
    UNION ALL
    SELECT service_request, 'Request Assigned To Agent', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_field_changed' AND source_field_name IN ('assignee', 'assigned_agent')
    UNION ALL
    SELECT service_request, 'First Agent Public Reply Sent', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'comment_added' AND is_public_comment = TRUE AND actor_type = 'agent' AND is_automated_response = FALSE
    UNION ALL
    SELECT service_request, 'Information Requested From Customer', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_status_changed' AND new_value = 'pending'
    UNION ALL
    SELECT service_request, 'Customer Responded', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'comment_added' AND is_public_comment = TRUE AND is_customer_reply = TRUE
    UNION ALL
    SELECT service_request, 'Internal Escalation Triggered', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_field_changed' AND source_field_name IN ('group', 'assigned_group')
    UNION ALL
    SELECT service_request, 'SLA Breach Occurred', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, TRUE, source_system, last_data_update
    FROM source_data
    WHERE source_event_type IN ('sla_breach', 'sla_breached') OR is_sla_breached = TRUE
    UNION ALL
    SELECT service_request, 'Service Request Resolved', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_status_changed' AND new_value = 'solved'
    UNION ALL
    SELECT service_request, 'Service Request Reopened', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_status_changed' AND previous_value = 'solved' AND new_value = 'open' AND is_customer_reply = TRUE
    UNION ALL
    SELECT service_request, 'Satisfaction Survey Sent', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type IN ('satisfaction_survey_sent', 'csat_survey_sent') OR is_survey_sent = TRUE
    UNION ALL
    SELECT service_request, 'Satisfaction Rating Received', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type IN ('satisfaction_rating_received', 'csat_rating_received') OR satisfaction_rating IS NOT NULL
    UNION ALL
    SELECT service_request, 'Service Request Closed', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_status_changed' AND new_value = 'closed'
),
deduplicated_events AS (
    SELECT
        service_request,
        activity_name,
        start_time,
        assigned_agent,
        service_request_type,
        priority,
        communication_channel,
        sla_target_resolution_time,
        is_sla_breached,
        source_system,
        last_data_update,
        ROW_NUMBER() OVER (PARTITION BY service_request, activity_name, source_event_id ORDER BY start_time) AS event_rank
    FROM activity_events
)
SELECT
    service_request AS ServiceRequest,
    activity_name AS ActivityName,
    start_time AS StartTime,
    source_system AS SourceSystem,
    last_data_update AS LastDataUpdate,
    assigned_agent AS AssignedAgent,
    service_request_type AS ServiceRequestType,
    priority AS Priority,
    communication_channel AS CommunicationChannel,
    sla_target_resolution_time AS SlaTargetResolutionTime,
    is_sla_breached AS IsSlaBreached
FROM deduplicated_events
WHERE event_rank = 1
ORDER BY service_request, start_time, activity_name;

Möchten Sie loslegen?

Optimieren Sie Ihren Kundenservice: Bereiten Sie Ihre Daten mit diesem Template auf und starten Sie noch heute. Gewinnen Sie wertvolle Erkenntnisse und steigern Sie die Effizienz Ihrer Zendesk-Support-Prozesse.

Zurück zum Leitfaden zur Prozessverbesserung Template herunterladen

Beseitigen Sie Engpässe im Kundenservice und steigern Sie jetzt Ihren CSAT-Wert

Vermeiden Sie wiederholte Kundenkontakte. Erreichen Sie eine FCR-Quote von 80 % und steigern Sie die Kundenzufriedenheit.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich

Ihr Daten-Template für den Kundenservice

Ihr Daten-Template für den Kundenservice

Kundenservice-Attribute

Kundenservice-Aktivitäten

Anleitungen zur Datenextraktion

Zendesk-Explore-Oberfläche für Berichte und Datenexport

Schritte

Konfiguration

a Beispielabfrage config

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

Schritte

Konfiguration

a Beispielabfrage python

Zendesk Incremental Exports API für Massendaten

Schritte

Konfiguration

a Beispielabfrage python

Zendesk-Konnektor für ETL-Tools von Drittanbietern

Schritte

Konfiguration

a Beispielabfrage config

Möchten Sie loslegen?

Beseitigen Sie Engpässe im Kundenservice und steigern Sie jetzt Ihren CSAT-Wert

Ihr Daten-Template für den Kundenservice

Ihr Daten-Template für den Kundenservice

Kundenservice-Attribute

Kundenservice-Aktivitäten

Anleitungen zur Datenextraktion

Zendesk-Explore-Oberfläche für Berichte und Datenexport

Schritte

Konfiguration

a Beispielabfrage config

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

Schritte

Konfiguration

a Beispielabfrage python

Zendesk Incremental Exports API für Massendaten

Schritte

Konfiguration

a Beispielabfrage python

Zendesk-Konnektor für ETL-Tools von Drittanbietern

Schritte

Konfiguration

a Beispielabfrage config

Möchten Sie loslegen?

Beseitigen Sie Engpässe im Kundenservice und steigern Sie jetzt Ihren CSAT-Wert

Der Schutz Ihrer Daten ist uns wichtig