> Kontinuierliche Prozessverbesserung > Problemmanagement > Zendesk Support > Daten Template

Ihr Daten-Template für das Problemmanagement

Zendesk Support

← Zurück zum Leitfaden zur Prozessverbesserung

Attribute des Problemmanagements (19) Aktivitäten im Problemmanagement (12) Anleitungen zur Datenextraktion (3)

Ihr Daten-Template für das Problemmanagement

Dieses Template bietet einen umfassenden Rahmen, um den Lebenszyklus des Problemmanagements in Zendesk Support abzubilden. Es beschreibt die erforderlichen Attribute, Prozessmeilensteine und die Logik für die Datenextraktion, mit denen sich Engpässe bei der Ursachenanalyse erkennen lassen. Anhand dieser Struktur können Sie ein hochwertiges Event Log für eine detaillierte Prozessanalyse erstellen.

Empfohlene Attribute für eine detaillierte Analyse
Wichtige Prozessaktivitäten und Statusübergänge
Anleitung zum Extrahieren von Zendesk-Support-Daten

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

Template herunterladen

Attribute des Problemmanagements

Diese empfohlenen Datenfelder liefern den nötigen Kontext, um Ticketkategorien, Prioritäten und Zuständigkeiten über den gesamten Lebenszyklus der Problemlösung hinweg zu analysieren.

5 Erforderlich 8 Empfohlen 6 Optional

	Name	Beschreibung
	Aktivität ActivityName	Die Bezeichnung des Ereignisses oder der Aktion, die am Problemfall ausgeführt wurde.
Beschreibung Dieses Attribut erfasst den konkreten Schritt oder die Aktion im Lebenszyklus des Problemfalls. Beispiele sind Statusänderungen wie „Offen“ zu „Ausstehend“, Zuweisungsänderungen oder bestimmte Workflow-Schritte wie „Behelfslösung veröffentlicht“. In der Analyse bilden diese Aktivitäten die Knoten der Prozessdarstellung. Ihre Abfolge macht den Arbeitsfluss sichtbar und hilft Analysten, Engpässe zu erkennen und die Dauer zwischen einzelnen Prozessschritten zu messen. Warum das wichtig ist Es beschreibt das „Was“ des Prozesses und ermöglicht die Visualisierung des Prozessflusses sowie die Analyse von Varianten. Woher beziehen Abgeleitet aus Zendesk-Ticket-Audits oder Ticket-Metriken Beispiele Problemfall erfasstUntersuchung begonnenBehelfslösung veröffentlicht
	Letzte Datenaktualisierung LastDataUpdate	Der Timestamp der letzten Änderung am Problemfall.
Beschreibung Dieses Attribut gibt an, wann die Daten des Problemfalls zuletzt im Quellsystem aktualisiert wurden. Anders als der Ereignis-Timestamp bezieht es sich auf den Datensatz und nicht auf die Aktivität. Bei der Analyse hilft es, die Aktualität der Daten zu beurteilen. So lässt sich feststellen, ob der Datensatz aktuell ist oder ob es Verzögerungen bei der Synchronisierung zwischen Quellsystem und Process-Mining-Umgebung gibt. Warum das wichtig ist Es erfasst die Aktualität der Daten und unterstützt Strategien für das schrittweise Laden von Daten. Woher beziehen Zendesk-Ticketobjekt, Feld „updated_at“ Beispiele 2023-11-01T14:20:00Z
	Problemfall ProblemRecordId	Die eindeutige numerische Kennung des Problem-Tickets in Zendesk.
Beschreibung Dieses Attribut enthält den eindeutigen Schlüssel des Problemfalls in Zendesk Support. Als zentrale Case-ID ermöglicht es Process Mining, alle nachfolgenden Ereignisse, Aktualisierungen und Interaktionen einer Prozessinstanz zuzuordnen. Bei der Analyse dient diese ID dazu, jede Untersuchung von der Erstellung bis zum Abschluss eindeutig zu identifizieren. Sie ermöglicht es, zusammengehörige Vorfälle zu verknüpfen und den Lebenszyklus des Problemfalls über verschiedene Supportstufen hinweg zu verfolgen. Warum das wichtig ist Dieser grundlegende Pflichtschlüssel ist erforderlich, um Ereignisse für jede Process-Mining-Analyse zu Cases zusammenzufassen. Woher beziehen Zendesk-Ticketobjekt, Feld „id“ mit dem Typ „problem“ Beispiele 1045293849921
	Quellsystem SourceSystem	Die Bezeichnung des Systems, aus dem die Daten stammen.
Beschreibung Dieses Attribut gibt die Softwareplattform an, aus der die Prozessdaten extrahiert wurden. In diesem Fall enthält es durchgehend den Wert „Zendesk Support“. Bei der Analyse von Daten aus mehreren Systemen, etwa Zendesk und Jira, können Analysten die Daten anhand dieses Feldes nach ihrer Herkunft filtern oder gruppieren. So bleiben Datenherkunft und Nachvollziehbarkeit in systemübergreifenden Prozessansichten gewährleistet. Warum das wichtig ist Es dokumentiert die Datenherkunft und unterstützt Process-Mining-Konfigurationen mit mehreren Systemen. Woher beziehen Bei der Extraktion fest codiert Beispiele Zendesk Support
	Startzeit EventTimestamp	Datum und Uhrzeit, zu denen eine Aktivität stattgefunden hat.
Beschreibung Dieses Attribut erfasst den genauen Zeitpunkt einer Aktivität im Zendesk-System. Es liefert die zeitliche Grundlage, um Ereignisse korrekt anzuordnen und die Dauer zwischen Prozessschritten zu berechnen. Für die Analyse ist es entscheidend, um Zykluszeiten zu berechnen, Verzögerungen zu erkennen, die SLA-Einhaltung zu prüfen und den Prozessverlauf über die Zeit darzustellen. Ohne genaue Timestamps lässt sich die Geschwindigkeit des Problemlösungsprozesses nicht nachvollziehen. Warum das wichtig ist Damit lassen sich Aktivitäten sortieren und alle zeitbasierten KPIs berechnen. Woher beziehen Zendesk-Ticket-Audits, Feld „created_at“ Beispiele 2023-10-12T08:30:00Z2023-10-12T09:15:22Z
	Name der zuständigen Supportkraft AssigneeName	Die Supportkraft, die mit der Bearbeitung des Problems beauftragt ist.
Beschreibung Dieses Attribut enthält den Namen der Person, die aktuell für den Problemfall zuständig ist. Dadurch wird sichtbar, wer bestimmte Aktionen ausgeführt hat. Bei der Analyse hilft es, die individuelle Arbeitslast und Leistung zu verstehen. Während Analysen auf Gruppenebene üblich sind, können Daten zur zuständigen Person auf Schulungsbedarf oder auf Mitarbeitende hinweisen, die komplexe Ursachen besonders wirksam beheben. Warum das wichtig ist Es ermöglicht eine Ressourcenanalyse auf individueller Ebene. Woher beziehen Zendesk-Ticketobjekt, Feld „assignee_id“ (in den Namen aufgelöst) Beispiele Max MustermannErika MusterfrauSystem
	Priorität Priority	Die Dringlichkeitsstufe des Problemfalls.
Beschreibung Dieses Attribut gibt die relative Bedeutung des Problems an. Übliche Kategorien sind „Niedrig“, „Normal“, „Hoch“ und „Dringend“. Es beeinflusst die erwarteten Service Level Agreements (SLAs) und die Ressourcenverteilung. Bei der Analyse dient es dazu, den Prozess nach Dringlichkeit aufzuschlüsseln und die Leistung zwischen den Stufen zu vergleichen. So lässt sich beispielsweise prüfen, ob dringende Probleme tatsächlich schneller gelöst werden als Probleme mit niedriger Priorität, wie es das Dashboard zur Geschwindigkeit der Ursachenanalyse vorgibt. Warum das wichtig ist Es ist wichtig, Cases aufzuschlüsseln, um die SLA-Einhaltung und die Priorisierung von Ressourcen zu analysieren. Woher beziehen Zendesk-Ticketobjekt, Feld „priority“ Beispiele DringendHochNormalNiedrig
	Problemkategorie ProblemCategory	Klassifizierung des Problems (z. B. Software, Hardware, Netzwerk).
Beschreibung Dieses Attribut kategorisiert das Problem anhand des betroffenen Service oder Technologie-Stacks. In Zendesk-Formularen ist es üblicherweise ein benutzerdefiniertes Dropdown-Feld. In der Analyse wird dieses Attribut im Dashboard „Genauigkeit der Problemkategorisierung“ verwendet. Durch den Vergleich der ursprünglichen Kategorie mit der endgültigen Ursache lässt sich feststellen, ob die erste Triage Probleme zuverlässig an die zuständigen Teams weiterleitet. Warum das wichtig ist Damit lassen sich Daten nach Technologie oder Business-Service segmentieren. Woher beziehen Benutzerdefinierte Zendesk-Ticketfelder Beispiele DatenbankUI/UXNetzwerkinfrastruktur
	Problemstatus ProblemStatus	Der aktuelle Status des Problemfalls in seinem Lebenszyklus.
Beschreibung Dieses Attribut zeigt den aktuellen Status des Problems an, etwa „Neu“, „Offen“, „Ausstehend“, „Gelöst“ oder „Geschlossen“. Es bildet den Fortschritt der Untersuchung ab. Bei der Analyse dient es dazu, offene und geschlossene Cases zu filtern. Für das Dashboard zur Überwachung unbearbeiteter Problemfälle ist es wichtig, um aktive Cases zu erkennen, die den erwarteten Statusverlauf nicht durchlaufen. Warum das wichtig ist Damit lassen sich Cases nach ihrem Abschlussstatus filtern. Woher beziehen Zendesk-Ticketobjekt, Feld „status“ Beispiele neuoffenausstehendgelöstgeschlossen
	SLA-Fälligkeitsdatum SlaDueDate	Der Termin, bis zu dem das Problem gelöst sein sollte.
Beschreibung Dieses Attribut gibt die Frist für die Problemlösung gemäß der Konfiguration des Service Level Agreements an. Sie wird üblicherweise anhand der Priorität und des Erstellungszeitpunkts des Tickets berechnet. Bei der Analyse wird die Frist mit dem tatsächlichen Lösungszeitpunkt verglichen, um die Einhaltungsquote der Problem-SLAs zu berechnen. Das Dashboard zur SLA-Leistung und zum SLA-Risiko hebt Cases hervor, deren Frist bald erreicht oder bereits überschritten ist. Warum das wichtig ist Es ist entscheidend, um die Einhaltung von Vorgaben und die Vertragserfüllung zu messen. Woher beziehen Zendesk-Ticket-Metriken oder SLA-Richtlinien-Endpunkt Beispiele 2023-12-01T17:00:00Z
	Supportgruppe SupportGroup	Das Team oder die Abteilung, dem beziehungsweise der der Problemfall aktuell zugewiesen ist.
Beschreibung Dieses Attribut gibt die Gruppe der Supportkräfte an, die zu einem bestimmten Zeitpunkt für den Problemfall zuständig ist. Der Wert ändert sich, wenn das Ticket von einem Team an ein anderes übergeben wird. Für das Dashboard „Analyse der Übergaben zwischen Supportgruppen“ ist dieses Attribut besonders wichtig. Es ermöglicht den Leistungsvergleich zwischen Teams, macht Engpässe bei Übergaben sichtbar und unterstützt die Analyse der Arbeitslastverteilung. Warum das wichtig ist Es ermöglicht Analysen nach Organisationseinheiten und hilft, Engpässe zwischen Abteilungen zu erkennen. Woher beziehen Zendesk-Ticketobjekt, Feld „group_id“ (in den Gruppennamen aufgelöst) Beispiele Support der Stufe 2DatenbankteamNetzwerkbetrieb
	Ursachenkategorie RootCauseCategory	Die ermittelte zugrunde liegende Ursache des Problems (z. B. Codefehler, Konfigurationsfehler).
Beschreibung Dieses Attribut erfasst die abschließende Diagnose der Problemursache. Es wird üblicherweise während der Aktivität „Ursache ermittelt“ ausgefüllt. In der Analyse dient es dazu, den Bericht „Genauigkeit der Problemkategorisierung“ zu erstellen und Trends bei Systemausfällen auszuwerten. So kann das Management erkennen, ob der Schwerpunkt auf Codequalität, Infrastrukturstabilität oder Lieferantenmanagement liegen sollte. Warum das wichtig ist Damit lassen sich Fehlermuster analysieren und langfristige Verbesserungsmaßnahmen gezielt ausrichten. Woher beziehen Benutzerdefinierte Zendesk-Ticketfelder Beispiele SoftwarefehlerKonfigurationsfehlerBenutzerfehler
	Zahl der zugehörigen Vorfälle RelatedIncidentCount	Die Zahl der Vorfall-Tickets, die mit diesem Problemfall verknüpft sind.
Beschreibung Dieses Attribut zählt die einzelnen Vorfall-Tickets, die mit dem Problemfall verknüpft sind. In Zendesk wird dies über das Feld „problem_id“ in den Vorfall-Tickets verwaltet, das auf diesen Problemfall verweist. Bei der Analyse ist dies die zentrale Kennzahl für „Korrelation und Auswirkung von Vorfällen“. Sie hilft, Probleme zu priorisieren, die besonders viele Benutzer betreffen, und unterstützt strategische Entscheidungen darüber, welche Korrekturen die Zahl der Tickets am stärksten senken. Warum das wichtig ist Es zeigt das Ausmaß des Problems und seine Auswirkungen auf Benutzer. Woher beziehen Zendesk-Tickets-API, Anzahl der Tickets mit type='incident' und problem_id=ThisID Beispiele 015342
	ID des Änderungsantrags ChangeRequestId	Die Kennung des Änderungsantrags, der zur Umsetzung der Lösung verknüpft wurde.
Beschreibung Dieses Attribut verknüpft den Problemdatensatz mit einem Datensatz aus dem Änderungsmanagement, möglicherweise in einem anderen System oder einem anderen Tickettyp. Es zeigt an, dass ein formeller Änderungsprozess eingeleitet wurde. In der Analyse unterstützt es das Dashboard „Einleitungsrate von Änderungsanträgen“. Damit lässt sich der Übergang von der Diagnose zur Umsetzung verfolgen und prüfen, ob erkannte Ursachen zu formellen Änderungsmaßnahmen führen. Warum das wichtig ist Damit wird der Problemprozess mit dem Änderungsmanagementprozess verknüpft. Woher beziehen Benutzerdefinierte Zendesk-Ticketfelder oder verknüpfte Tickets Beispiele CR-1002CHG00394
	ID des Wissensdatenbankartikels KnowledgeArticleId	Die ID des Wissensdatenbankartikels, der zum Problem erstellt oder damit verknüpft wurde.
Beschreibung Dieses Attribut speichert den Verweis auf einen Zendesk-Guide-Artikel oder einen externen Wissensbeitrag. Es zeigt an, dass die aus dem Problem gewonnenen Erkenntnisse dokumentiert wurden. In der Analyse wird anhand dieses Feldes die „Integrationsrate der Wissensdatenbank“ berechnet. So lässt sich prüfen, ob die Organisation Erkenntnisse dokumentiert und Lösungen für spätere Fälle festhält. Warum das wichtig ist Damit wird die Wirksamkeit des Wissensmanagements gemessen. Woher beziehen Benutzerdefinierte Zendesk-Ticketfelder oder verknüpfte Inhalte Beispiele 360045889KB-2991
	PIR durchgeführt HasPostImplementationReview	Kennzeichnet, ob eine Überprüfung nach der Implementierung durchgeführt wurde.
Beschreibung Dieses Attribut gibt an, ob der Prozess zur Problemlösung eine Überprüfungsphase umfasste. Es wird anhand des Fallverlaufs ermittelt: Entscheidend ist, ob die Aktivität „Überprüfung nach der Implementierung durchgeführt“ vorhanden ist. In der Analyse unterstützt es das Dashboard „Abdeckung durch Überprüfungen nach der Implementierung“. Als Compliance-Kennzahl zeigt es, ob die Organisation aus schwerwiegenden Problemen lernt. Warum das wichtig ist Damit lässt sich die Einhaltung kontinuierlicher Verbesserungsprozesse überprüfen. Woher beziehen Abgeleitet aus der Aktivität „Überprüfung nach der Implementierung durchgeführt“ Beispiele truefalse
	Problembetreff ProblemSubject	Die kurze Zusammenfassung oder der Titel des Problemfalls.
Beschreibung Dieses Attribut enthält die Textzusammenfassung, die beim Erstellen des Problems eingegeben wurde. Sie beschreibt in der Regel das Symptom oder den untersuchten Sachverhalt. Bei der Analyse liefert es Kontext, wenn Analysten einzelne Cases genauer untersuchen. Außerdem können Text-Mining-Verfahren ähnliche Probleme gruppieren oder wiederkehrende Themen erkennen, die in strukturierten Kategoriefeldern nicht erfasst werden. Warum das wichtig ist Es liefert einen verständlichen Kontext zu einzelnen Cases. Woher beziehen Zendesk-Ticketobjekt, Feld „subject“ Beispiele Zahlungen in der EU-Region können nicht verarbeitet werdenLatenzspitzen auf dem AnmeldeserverDatenexport für Administrationsbenutzer schlägt fehl
	Veraltet IsStale	Kennzeichnet Probleme, bei denen seit mehr als 14 Tagen keine Aktivität verzeichnet wurde.
Beschreibung Dieses berechnete Attribut kennzeichnet Datensätze, die seit längerer Zeit nicht aktualisiert wurden. Dazu wird das aktuelle Datum (oder das Analysedatum) mit dem Timestamp der letzten Aktivität verglichen. In der Analyse bildet es die Grundlage für das Dashboard „Überwachung veralteter Problemdatensätze“. Manager können damit schnell unbearbeitete Fälle im Rückstand erkennen, die möglicherweise administrativ geschlossen oder neu zugewiesen werden müssen. Warum das wichtig ist Damit lassen sich unnötiger Aufwand im Prozess und vernachlässigte Arbeitselemente erkennen. Woher beziehen Wird im Process-Mining-Tool berechnet: (Now - LastDataUpdate) > 14 days Beispiele truefalse
	Workaround aktiv WorkaroundActive	Kennzeichnet, ob ein Workaround bereitgestellt oder veröffentlicht wurde.
Beschreibung Dieses boolesche Attribut gibt an, ob für das Problem eine vorübergehende Lösung dokumentiert wurde. Es wird häufig anhand der Aktivität „Workaround veröffentlicht“ oder eines bestimmten Kontrollkästchens im Formular ermittelt. In der Analyse wird es im Dashboard „Einhaltung der Veröffentlichung von Workarounds“ verwendet. Es misst, wie oft das Supportteam Benutzer unmittelbar entlastet, während die langfristige Untersuchung weiterläuft. Warum das wichtig ist Das Attribut ist wichtig, um zu messen, wie die Auswirkungen auf Benutzer während der Untersuchung begrenzt werden. Woher beziehen Abgeleitet aus der Aktivität „Workaround veröffentlicht“ oder einem benutzerdefinierten Feld Beispiele truefalse

Erforderlich Empfohlen Optional

Aktivitäten im Problemmanagement

Erfassen Sie diese wichtigen Prozessschritte und Statusänderungen, um den gesamten Ablauf von der ersten Problemerkennung bis zur Umsetzung einer dauerhaften Lösung abzubilden.

8 Empfohlen 4 Optional

	Aktivität	Beschreibung
	Behelfslösung veröffentlicht	Eine vorübergehende Lösung für das Problem wird dokumentiert und weitergegeben. In Zendesk wird dies häufig durch ein bestimmtes Tag oder ein benutzerdefiniertes Kontrollkästchen erfasst, das die Verfügbarkeit einer Behelfslösung anzeigt.
Warum das wichtig ist Unterstützt das Dashboard zur Einhaltung der Vorgaben für die Veröffentlichung von Behelfslösungen. So erhalten Benutzer während langwieriger Untersuchungen eine vorübergehende Entlastung. Woher beziehen Das Hinzufügen des Tags „workaround_published“ oder eine Änderung an einem benutzerdefinierten booleschen Feld namens „Workaround“ überwachen. Erfassung Werte benutzerdefinierter Felder oder Tags vergleichen Ereignistyp inferred
	Dauerhafte Korrektur angewendet	Zeigt an, dass die technische Lösung in der Umgebung bereitgestellt wurde. Dies wird üblicherweise durch einen benutzerdefinierten Statuswechsel oder ein bestimmtes Tag erfasst, bevor das Ticket endgültig gelöst wird.
Warum das wichtig ist Wichtig für das Dashboard zur Effizienz der Fehlerbehebung, das die Zeit von der Diagnose bis zur Bereitstellung misst. Woher beziehen Abgeleitet aus einem bestimmten Tag, etwa „fix_deployed“, oder aus einem benutzerdefinierten Statusfeld, sofern vorhanden. Erfassung Tags oder benutzerdefinierte Statusauswahlfelder überwachen Ereignistyp inferred
	Lösung bestätigt	Der Problemfall wird offiziell als „Gelöst“ gekennzeichnet. In Zendesk geschieht dies, wenn der Standardstatus des Systems auf „Gelöst“ gesetzt wird. Damit ist die Korrektur bestätigt und der Fall abgeschlossen.
Warum das wichtig ist Der maßgebliche Endpunkt für Berechnungen zur SLA-Leistung und zum SLA-Risiko sowie für die Einhaltungsquote der Problem-SLAs. Woher beziehen Abgeleitet aus der Statusänderung des Tickets zu „Gelöst“. Erfassung Erfasst, wenn sich der Status zu „Gelöst“ ändert Ereignistyp explicit
	Problemfall erfasst	Der Problemfall wird erstmals als Ticket in Zendesk Support angelegt. Dieses Ereignis erfasst den Timestamp der ersten Erfassung im System und löst in der Regel die Prozessinstanz aus.
Warum das wichtig ist Legt den Startzeitpunkt des gesamten Lösungszyklus fest und dient als Grundlage für alle nachfolgenden Kennzahlen zur Durchlaufzeit. Woher beziehen Abgeleitet aus dem Timestamp „created_at“ im Ticketobjekt oder dem ersten Eintrag im Ticket-Audit-Log. Erfassung Erfasst, wenn die Transaktion „Ticket Created“ ausgeführt wird Ereignistyp explicit
	Problemfall geschlossen	Das abschließende Ereignis im Lebenszyklus: Das Ticket wird gesperrt und kann nicht mehr geändert werden. In Zendesk geschieht dies in der Regel automatisch vier Tage nach dem Status „Gelöst“.
Warum das wichtig ist Kennzeichnet das endgültige Ende des Lebenszyklus des Falls und dient der Datenaufbewahrung sowie der historischen Berichterstattung. Woher beziehen Abgeleitet aus der Statusänderung des Tickets zu „Geschlossen“. Erfassung Erfasst, wenn sich der Status zu „Geschlossen“ ändert Ereignistyp explicit
	Supportgruppe zugewiesen	Der Problemfall wird einem bestimmten technischen Team oder einer Abteilung zugewiesen. Erfasst wird dies, wenn sich das Feld „Group ID“ im Ticket ändert.
Warum das wichtig ist Wichtig für das Dashboard „Analyse der Übergaben zwischen Supportgruppen“, das Wartezeiten zwischen Abteilungen misst. Woher beziehen Änderungen am Feld „group_id“ im Ticket-Audit-Log überwachen. Erfassung Erfasst, wenn die Transaktion „Group Assignment Change“ ausgeführt wird Ereignistyp explicit
	Untersuchung begonnen	Kennzeichnet den Wechsel vom passiven Status „Neu“ zu einem aktiven Bearbeitungsstatus. Das bedeutet, dass eine Supportkraft das Problem übernommen und mit der Diagnose begonnen hat.
Warum das wichtig ist Wird zur Berechnung der Kennzahlen für unbearbeitete Problemfälle verwendet und bildet den Startpunkt für die KPI zur durchschnittlichen Dauer der Ursachenanalyse. Woher beziehen Abgeleitet aus einer Statusänderung des Tickets von „Neu“ zu „Offen“ oder „Ausstehend“. Erfassung Statusfeld vorher und nachher vergleichen Ereignistyp inferred
	Ursache ermittelt	Der Zeitpunkt, an dem die zugrunde liegende Ursache des Problems festgestellt wird. Dies wird üblicherweise erfasst, wenn eine Supportkraft ein benutzerdefiniertes Textfeld oder Auswahlfeld „Root Cause“ ausfüllt.
Warum das wichtig ist Ein wichtiger Meilenstein für das Dashboard zur Geschwindigkeit der Ursachenanalyse und zur Messung der Diagnoseeffizienz. Woher beziehen Änderungen an benutzerdefinierten Feldern mit den Bezeichnungen „Root Cause“, „RCA“ oder „Problem Source“ auf nicht leere Werte überwachen. Erfassung Benutzerdefinierte Felder auf ausgefüllte Werte prüfen Ereignistyp inferred
	Änderungsantrag eingeleitet	Zeigt an, dass zur Behebung des Problems ein formeller Änderungsmanagementprozess gestartet wurde. Dies lässt sich häufig daran erkennen, dass ein benutzerdefiniertes Feld „Change Request ID“ ausgefüllt oder ein Ticket vom Typ „Change“ verknüpft wird.
Warum das wichtig ist Erfasst die Einleitungsrate von Änderungsanträgen und verknüpft das Problemmanagement mit den Workflows des Änderungsmanagements. Woher beziehen Änderungen an einem benutzerdefinierten Feld wie „change_reference“ oder die Erstellung eines Links vom Typ „problem_change“ überwachen. Erfassung Benutzerdefiniertes Feld auf Eintrag einer externen ID überwachen Ereignistyp inferred
	Lösungsvorschlag entworfen	Auf Grundlage der Problemuntersuchung wird ein Wissensdatenbankartikel erstellt. Dies lässt sich an der Verwendung der Zendesk-App Knowledge Capture oder an der Verknüpfung eines neuen Artikels erkennen.
Warum das wichtig ist Unterstützt die KPI zur Integrationsrate der Wissensdatenbank und fördert das Lernen in der Organisation. Woher beziehen Ereignisse zur Integration „Knowledge Capture“ oder Tags wie „kcs_draft“ überwachen. Erfassung Aus bestimmten System-Tags oder Verknüpfungsereignissen ableiten Ereignistyp inferred
	Überprüfung nach der Implementierung durchgeführt	Bestätigt, dass nach der Korrektur eine rückblickende Überprüfung stattgefunden hat. Üblicherweise aktualisiert die Prozesskoordination dafür ein Kontrollkästchen oder Datumsfeld.
Warum das wichtig ist Erforderlich für die KPI zur Häufigkeit von Überprüfungen nach der Implementierung, um die Einhaltung der Qualitätsstandards sicherzustellen. Woher beziehen Änderungen am benutzerdefinierten Kontrollkästchen „PIR Completed“ oder am Datumsfeld „PIR Date“ überwachen. Erfassung Benutzerdefiniertes Feld auf Abschluss überwachen Ereignistyp inferred
	Untersuchung des Problemfalls wieder aufgenommen	Ein zuvor als „Gelöst“ gekennzeichneter Problemfall wird wieder in den Status „Offen“ oder einen anderen aktiven Status versetzt. Dies weist auf eine fehlgeschlagene Korrektur oder eine abgelehnte Lösung hin.
Warum das wichtig ist Unterstützt die KPI zur Wiedereröffnungsquote von Problemfällen und hilft, Qualitätsprobleme im Lösungsprozess zu erkennen. Woher beziehen Abgeleitet aus einem Statuswechsel von „Gelöst“ zurück zu „Offen“, „Neu“ oder „Ausstehend“. Erfassung Statusfeld vorher und nachher vergleichen Ereignistyp inferred

Anleitungen zur Datenextraktion

So exportieren Sie Ihre Daten aus Zendesk Support

Schritte

Melden Sie sich bei Ihrer Zendesk-Instanz an und öffnen Sie über die Produktleiste die Explore-Berichtsoberfläche.
Klicken Sie auf den Ordner Queries (oder in neueren Versionen auf Reports) und wählen Sie New query.
Wählen Sie bei der Aufforderung zur Auswahl eines Datensatzes nacheinander Support, Updates History und Support: Updates History [default]. Dieser Datensatz enthält die für Process Mining erforderlichen Event Logs und nicht nur Daten zum aktuellen Status.
Fügen Sie im Bereich Metrics Count (Tickets) oder Count (Updates) hinzu, damit Daten abgerufen werden.
Fügen Sie im Bereich Filters einen Filter für Ticket > Ticket type hinzu und wählen Sie Problem, um den Datensatz auf den Problemmanagement-Prozess zu beschränken.
Fügen Sie im Bereich Rows die folgenden Attribute in genau dieser Reihenfolge hinzu, um die Struktur des Event Logs festzulegen: Ticket > Ticket ID, Time - Timestamp > Update - Timestamp, Updater > Updater name und Changes > Changes - Field name.
Erstellen Sie für die Spalte Activity Name ein Standard Calculated Attribute. Klicken Sie in der rechten Seitenleiste auf das Berechnungssymbol, wählen Sie Standard calculated attribute, nennen Sie das Attribut Activity Mapper und fügen Sie den Code aus dem folgenden Abschnitt Query ein.
Fügen Sie das neue Attribut Activity Mapper zum Bereich Rows hinzu. Filtern Sie NULL-Werte heraus, um irrelevante Systemereignisse auszuschließen.
Fügen Sie dem Bereich Rows weitere Attribute als Kontext hinzu: Ticket > Priority, Ticket > Group, Ticket > Status sowie alle benutzerdefinierten Felder, die für die Ursachen- oder Kategorieanalyse erforderlich sind, zum Beispiel Ticket > Ticket tags oder bestimmte Custom Fields.
Legen Sie den Zeitraum im Bereich Filters über Time - Timestamp > Update - Date fest, sodass er den gewünschten Analysezeitraum abdeckt, zum Beispiel Last 6 Months.
Klicken Sie auf das Symbol für den Visualisierungstyp und wählen Sie Table. Stellen Sie sicher, dass die Tabelle nicht pivotiert oder flach dargestellt wird, sofern diese Option verfügbar ist. Andernfalls müssen sich alle Attribute im Bereich Rows befinden.
Exportieren Sie das Ergebnis über Export > CSV. Aktivieren Sie Keep attribute formatting, damit die Timestamp-Formate für ProcessMind erhalten bleiben.

Konfiguration

Datensatz: Support: Updates History (Wichtig: Verwenden Sie nicht den Standarddatensatz Tickets, da dieser nur den aktuellen Status zeigt).
Zeitfilter: Update - Date (Empfehlung: die letzten 90 bis 180 Tage, abhängig vom Datenvolumen).
Tickettyp: Beschränken Sie den Filter auf Problem, damit Incidents und Service Requests nicht einbezogen werden.
Zeilenlimit: Zendesk-Explore-Exporte sind häufig auf 50.000 Zeilen begrenzt. Überschreitet Ihr Datensatz diesen Wert, exportieren Sie die Daten mithilfe des Filters Update - Date in kleineren Monatsabschnitten und führen Sie sie anschließend extern zusammen.
Benutzerdefinierte Felder: Ermitteln Sie in Ihrer Zendesk-Instanz die IDs der Felder für Root Cause, Change Request und Workaround. Diese Felder gehören nicht zum Standardumfang.
Systemberechtigungen: Erfordert eine Explore-Viewer- oder Explore-Professional-Lizenz.

a Beispielabfrage config

IF ([Changes - Field name] = "status" AND [Changes - New value] = "New") THEN "Problem Record Logged"
ELIF ([Changes - Field name] = "group_id") THEN "Assigned to Support Group"
ELIF ([Changes - Field name] = "status" AND [Changes - Previous value] = "New" AND [Changes - New value] = "Open") THEN "Investigation Commenced"
ELIF ([Changes - Field name] = "tags" AND CONTAINS([Changes - New value], "workaround_available")) THEN "Workaround Published"
ELIF ([Changes - Field name] = "[Your Root Cause Field Name]") THEN "Root Cause Identified"
ELIF ([Changes - Field name] = "[Your Change Request ID Field Name]") OR ([Changes - Field name] = "type" AND [Changes - New value] = "change") THEN "Change Request Initiated"
ELIF ([Changes - Field name] = "tags" AND CONTAINS([Changes - New value], "fix_deployed")) THEN "Permanent Fix Applied"
ELIF ([Changes - Field name] = "[Your Knowledge Article Linked Field]") THEN "Proposed Solution Drafted"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "Solved") THEN "Resolution Verified"
ELIF ([Changes - Field name] = "status" AND [Changes - Previous value] = "Solved" AND [Changes - New value] = "Open") THEN "Problem Investigation Reopened"
ELIF ([Changes - Field name] = "[Your PIR Completed Checkbox Field]") THEN "Post-Implementation Review Conducted"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "Closed") THEN "Problem Record Closed"
ELSE NULL
ENDIF

Schritte

Voraussetzungen prüfen: Stellen Sie sicher, dass das Zendesk-Data-Sharing-Add-on für Ihre Organisation aktiviert ist. Vergewissern Sie sich, dass Sie schreibgeschützte Zugangsdaten für die replizierte Zendesk-Datenbank haben, die üblicherweise auf Snowflake oder Amazon Redshift gehostet wird.
Mit der Datenbank verbinden: Stellen Sie mit Ihrem bevorzugten SQL-Client, zum Beispiel DBeaver, DataGrip oder der nativen Weboberfläche von Snowflake beziehungsweise Redshift, über die bereitgestellten Zugangsdaten eine Verbindung zu Ihrem Zendesk Data Warehouse her.
Benutzerdefinierte Felder ermitteln: Ermitteln Sie vor der Abfrage die eindeutigen IDs der benutzerdefinierten Felder, die in Ihrem Problemmanagement-Prozess verwendet werden. Öffnen Sie dazu in Zendesk das Admin Center und navigieren Sie zu Objects and rules > Tickets > Fields. Suchen Sie die Felder „Root Cause“, „Change Request ID“, „Workaround Published“, „Permanent Fix Applied“ und „Post-Implementation Review“ und notieren Sie deren jeweilige Feld-IDs. Ersetzen Sie damit die Platzhalter in der Abfrage.
SQL-Abfrage prüfen: Die bereitgestellte Abfrage verwendet eine Common Table Expression (CTE) namens ProblemTickets, um zunächst alle Problem-Datensätze auszuwählen und zu filtern. Das verbessert Leistung und Lesbarkeit. Anschließend führt die Abfrage mit UNION ALL die Ergebnisse von 12 separaten SELECT-Anweisungen zusammen, eine für jede erforderliche Aktivität.
Abfrage anpassen: Öffnen Sie einen neuen Abfrageeditor und fügen Sie das vollständige SQL-Skript ein. Ändern Sie die Platzhalter im Skript:
- Legen Sie in der CTE ProblemTickets den gewünschten Zeitraum fest, indem Sie '[YYYY-MM-DD]' ersetzen.
- Ersetzen Sie bei jeder Aktivität, die auf einem benutzerdefinierten Feld basiert, die Platzhalter-IDs, zum Beispiel [Your 'Root Cause Category' field_id] und [Your 'Change Request ID' field_id], durch die tatsächlichen IDs aus Schritt 3.
Abfrage ausführen: Führen Sie das angepasste SQL-Skript für die Datenbank aus. Die Ausführungsdauer hängt vom Zeitraum und vom Umfang der Ticketdaten ab.
Logik für „Proposed Solution Drafted“ prüfen: Die Abfrage geht davon aus, dass ein Lösungsvorschlag durch das Befüllen eines benutzerdefinierten Felds namens [Your 'KB Article ID' field_id] erfasst wird. Wenn Ihr Prozess anders abläuft, zum Beispiel über ein bestimmtes Tag oder einen Kommentar, müssen Sie diesen Teil der Abfrage entsprechend anpassen.
Daten validieren: Prüfen Sie die Ergebnisse nach Abschluss der Abfrage kurz. Achten Sie auf eine plausible Zeilenanzahl, darauf, dass alle Spalten vorhanden sind, und auf unerwartete NULL-Werte in wichtigen Spalten wie ProblemRecordId und EventTimestamp.
Event Log exportieren: Exportieren Sie das gesamte Ergebnis aus Ihrem SQL-Client in eine CSV-Datei. Verwenden Sie UTF-8-Codierung und stellen Sie sicher, dass die Spaltenüberschriften den Attributnamen entsprechen, die Ihr Process-Mining-Tool benötigt.
Upload vorbereiten: Prüfen Sie die CSV-Datei vor dem Upload auf Formatierungsfehler. Achten Sie darauf, dass Datums- und Zeitangaben in der Spalte EventTimestamp ein einheitliches Format haben, zum Beispiel YYYY-MM-DD HH24:MI:SS.

Konfiguration

Voraussetzungen: Für diese Extraktion benötigen Sie das Zendesk-Data-Sharing-Add-on und direkten SQL-Zugriff auf die replizierten Daten in einer Snowflake- oder Amazon-Redshift-Instanz.
Tickettypfilter: Die Abfrage ist so konfiguriert, dass nur Tickets analysiert werden, deren type den Wert 'problem' hat. So wird der Problemmanagement-Prozess gezielt von Incidents und anderen Tickettypen abgegrenzt.
Zeitraumfilter: Filtern Sie die Daten unbedingt nach einem bestimmten Zeitraum, um die Leistung zu steuern. Die erste CTE der Abfrage enthält den Platzhalter created_at >= '[YYYY-MM-DD]'. Für eine erste Analyse sind drei bis sechs Monate üblich.
Konfiguration benutzerdefinierter Felder: Diese Extraktion hängt stark von Ihrer Zendesk-Konfiguration ab. Ermitteln Sie die korrekte field_id für benutzerdefinierte Felder, mit denen Aktivitäten wie 'Root Cause Identified', 'Change Request Initiated' und 'Workaround Published' erfasst werden, und tragen Sie sie ein. Werden die Platzhalter-IDs nicht ersetzt, schlägt die Abfrage fehl oder liefert für diese Aktivitäten keine Daten.
Datenverzögerung: Die replizierte Datenbank enthält keine Echtzeitdaten. Zwischen einem Ereignis in Zendesk und seiner Übernahme ins Data Warehouse liegen üblicherweise einige Stunden. Berücksichtigen Sie dies bei der Analyse sehr aktueller Aktivitäten.

a Beispielabfrage sql

WITH ProblemTickets AS (
  SELECT
    t.id,
    t.created_at,
    t.updated_at,
    t.priority,
    g.name AS group_name,
    u.name AS assignee_name,
    t.status,
    (SELECT COUNT(*) FROM problem_incident_links pil WHERE pil.problem_id = t.id) AS related_incident_count,
    t.due_at AS sla_due_date,
    cf_cat.value AS problem_category,
    cf_root.value AS root_cause_category
  FROM tickets t
  LEFT JOIN users u ON t.assignee_id = u.id
  LEFT JOIN groups g ON t.group_id = g.id
  LEFT JOIN custom_field_values cf_cat ON t.id = cf_cat.ticket_id AND cf_cat.custom_field_id = [Your 'Problem Category' field_id]
  LEFT JOIN custom_field_values cf_root ON t.id = cf_root.ticket_id AND cf_root.custom_field_id = [Your 'Root Cause Category' field_id]
  WHERE t.type = 'problem'
  AND t.created_at >= '[YYYY-MM-DD]' -- Set start date for the extraction
)
-- 1. Problem Record Logged
SELECT
  pt.id AS "ProblemRecordId",
  'Problem Record Logged' AS "ActivityName",
  pt.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'new' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ProblemTickets pt

UNION ALL

-- 2. Assigned to Support Group
SELECT
  pt.id AS "ProblemRecordId",
  'Assigned to Support Group' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'group'

UNION ALL

-- 3. Investigation Commenced
SELECT
  pt.id AS "ProblemRecordId",
  'Investigation Commenced' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'open' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'status' AND tme.value = 'open' AND tme.previous_value = 'new'

UNION ALL

-- 4. Workaround Published
SELECT
  pt.id AS "ProblemRecordId",
  'Workaround Published' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Workaround Published'' custom field name]' AND tme.value IS NOT NULL -- Example: checkbox being checked or field being filled

UNION ALL

-- 5. Root Cause Identified
SELECT
  pt.id AS "ProblemRecordId",
  'Root Cause Identified' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Root Cause Category'' custom field name]' AND tme.value IS NOT NULL

UNION ALL

-- 6. Change Request Initiated
SELECT
  pt.id AS "ProblemRecordId",
  'Change Request Initiated' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Change Request ID'' custom field name]' AND tme.value IS NOT NULL

UNION ALL

-- 7. Permanent Fix Applied
SELECT
  pt.id AS "ProblemRecordId",
  'Permanent Fix Applied' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Permanent Fix Applied'' custom field name]' AND tme.value IS NOT NULL -- Assumes a custom field indicates this status

UNION ALL

-- 8. Proposed Solution Drafted
SELECT
  pt.id AS "ProblemRecordId",
  'Proposed Solution Drafted' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''KB Article ID'' custom field name]' AND tme.value IS NOT NULL

UNION ALL

-- 9. Resolution Verified
SELECT
  pt.id AS "ProblemRecordId",
  'Resolution Verified' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'solved' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'status' AND tme.value = 'solved'

UNION ALL

-- 10. Problem Investigation Reopened
SELECT
  pt.id AS "ProblemRecordId",
  'Problem Investigation Reopened' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'open' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'status' AND tme.value = 'open' AND tme.previous_value IN ('pending', 'solved')

UNION ALL

-- 11. Post-Implementation Review Conducted
SELECT
  pt.id AS "ProblemRecordId",
  'Post-Implementation Review Conducted' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Post-Implementation Review'' custom field name]' AND tme.value IS NOT NULL -- Assumes a checkbox or date field

UNION ALL

-- 12. Problem Record Closed
SELECT
  pt.id AS "ProblemRecordId",
  'Problem Record Closed' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'closed' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'status' AND tme.value = 'closed' AND tme.previous_value = 'solved';

Schritte

Voraussetzungen: Stellen Sie sicher, dass Python 3.6 oder höher auf Ihrem System installiert ist. Installieren Sie die erforderlichen Bibliotheken requests und pandas, indem Sie im Terminal oder in der Eingabeaufforderung pip install requests pandas ausführen.
Zendesk-API-Token erstellen: Melden Sie sich als Administrator bei Zendesk Support an. Navigieren Sie zu Admin Center > Apps and integrations > APIs > Zendesk API. Klicken Sie im Abschnitt Token Access auf 'Add API token', um ein neues Token zu erstellen. Kopieren Sie das Token sofort und bewahren Sie es sicher auf, da es später nicht erneut angezeigt wird.
Python-Skript konfigurieren: Erstellen Sie eine neue Python-Datei, zum Beispiel extract_zendesk_problems.py, und kopieren Sie das vollständige Skript aus dem Abschnitt Query hinein. Aktualisieren Sie die Platzhaltervariablen am Anfang des Skripts: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL, ZENDESK_API_TOKEN und START_TIME. Legen Sie für den ersten Lauf START_TIME auf den Unix-Timestamp des gewünschten Startdatums der Extraktion fest.
IDs benutzerdefinierter Felder zuordnen: Ermitteln Sie die numerischen IDs der benutzerdefinierten Felder, die in Ihrem Problemmanagement-Prozess verwendet werden. Sie finden sie unter Admin Center > Objects and rules > Tickets > Fields, indem Sie die URL oder die Feldeigenschaften prüfen. Tragen Sie Ihre IDs im Wörterbuch CUSTOM_FIELD_MAPPING des Skripts ein.
Skript ausführen: Starten Sie das Skript im Terminal mit dem Befehl python extract_zendesk_problems.py. Das Skript ruft dann Daten über die Zendesk Incremental Export API ab.
Ausführung überwachen: Das Skript gibt den Fortschritt aus, darunter die Anzahl der verarbeiteten Tickets und den aktuellen Timestamp, für den Daten abgerufen werden. API-Ratenbegrenzungen werden automatisch berücksichtigt, indem das Skript bei Bedarf pausiert.
Daten abrufen und umwandeln: Zunächst ruft das Skript alle Problem-Tickets ab, die seit START_TIME erstellt oder aktualisiert wurden. Anschließend ruft es für jedes Problem-Ticket den vollständigen Audit-Trail mit allen historischen Änderungen ab.
Event Log erstellen: Das Skript verarbeitet jedes Audit-Ereignis und ordnet Feldänderungen, etwa an Status, Gruppe oder benutzerdefinierten Feldern, den festgelegten Geschäftsaktivitäten zu. Außerdem ruft es Benutzer- und Gruppennamen ab und speichert sie zwischen, um die Daten anzureichern.
Inkrementelle Ladevorgänge durchführen: Aktualisieren Sie nach dem ersten vollständigen Ladevorgang bei jedem weiteren Lauf die Variable START_TIME auf den end_time, der am Ende des letzten erfolgreichen Laufs ausgegeben wurde. So rufen Sie nur neue und aktualisierte Daten ab und vermeiden Duplikate.
Ergebnis prüfen: Nach Abschluss des Skripts wird im selben Verzeichnis die Datei zendesk_problem_event_log.csv erstellt. Sie enthält das strukturierte Event Log für die Analyse.
Upload vorbereiten: Öffnen Sie die CSV-Datei in einem Tabellenprogramm und prüfen Sie den Inhalt. Stellen Sie vor dem Upload in ProcessMind sicher, dass alle erforderlichen Spalten (ProblemRecordId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate) vorhanden und korrekt befüllt sind.

Konfiguration

Zendesk-API-Zugangsdaten: Für die Authentifizierung benötigt das Skript Ihre Zendesk-Subdomain, die E-Mail-Adresse des Benutzers, dem das API-Token zugeordnet ist, sowie das API-Token selbst.
Startzeit: Die Variable START_TIME ist ein Unix-Epoch-Timestamp, der den Beginn der Datenextraktion festlegt. Setzen Sie sie beim ersten Lauf auf ein Datum in der Vergangenheit, zum Beispiel vor sechs Monaten, um historische Daten abzurufen. Verwenden Sie bei späteren Läufen die Endzeit des vorherigen Laufs, um die Daten inkrementell abzurufen.
Zuordnung benutzerdefinierter Felder: Das Wörterbuch CUSTOM_FIELD_MAPPING ist entscheidend. Ersetzen Sie die Platzhalter-IDs durch die tatsächlichen IDs der benutzerdefinierten Felder Ihrer Zendesk-Instanz, damit Aktivitäten wie 'Workaround Published' und 'Root Cause Identified' korrekt erfasst werden.
Tickettypfilter: Das Skript verarbeitet ausschließlich Tickets, deren type den Wert 'problem' hat. Dadurch werden Incidents, Aufgaben und Fragen aus dem Event Log des Problemmanagements ausgeschlossen.
API-Ratenbegrenzung: Das Skript enthält eine einfache Funktion time.sleep(60), um Fehler 429 'Too Many Requests' zu behandeln. Je nach Zendesk-Tarif und Umfang der extrahierten Daten muss die Pausendauer möglicherweise angepasst werden.
Voraussetzungen: Für die Ausführung benötigen Sie eine Python-3-Umgebung mit den Bibliotheken requests und pandas. Das API-Token muss zu einem Konto gehören, das Tickets lesen darf.

a Beispielabfrage python

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

class=class="hl-string">"hl-comment"># --- CONFIGURATION --- 
class=class="hl-string">"hl-comment"># Replace with your Zendesk subdomain, email, and API token
ZENDESK_SUBDOMAIN = class="hl-string">'[your_subdomain]'
ZENDESK_EMAIL = class="hl-string">'[your_email@example.com]'
ZENDESK_API_TOKEN = class="hl-string">'[your_zendesk_api_token]'

class=class="hl-string">"hl-comment"># Start time for the incremental export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1641013200 is for Jan 1, 2022 00:00:00 GMT
START_TIME = 1641013200

class=class="hl-string">"hl-comment"># Map your custom field IDs to the corresponding activity names
class=class="hl-string">"hl-comment"># Find IDs in Admin Center > Objects and rules > Tickets > Fields
CUSTOM_FIELD_MAPPING = {
    class="hl-string">'[Your Workaround Published Field ID]': class="hl-string">'Workaround Published',
    class="hl-string">'[Your Root Cause Identified Field ID]': class="hl-string">'Root Cause Identified',
    class="hl-string">'[Your Change Request Initiated Field ID]': class="hl-string">'Change Request Initiated',
    class="hl-string">'[Your Permanent Fix Applied Field ID]': class="hl-string">'Permanent Fix Applied',
    class="hl-string">'[Your Proposed Solution Drafted Field ID]': class="hl-string">'Proposed Solution Drafted',
    class="hl-string">'[Your Post-Implementation Review Field ID]': class="hl-string">'Post-Implementation Review Conducted'
}

class=class="hl-string">"hl-comment"># --- SCRIPT --- 
BASE_URL = fclass="hl-string">'https://{ZENDESK_SUBDOMAIN}.zendesk.com/api/v2'
API_USER = fclass="hl-string">'{ZENDESK_EMAIL}/token'

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

session = requests.Session()
session.auth = (API_USER, ZENDESK_API_TOKEN)

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

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

def fetch_tickets(start_time):
    tickets_url = fclass="hl-string">'{BASE_URL}/incremental/tickets.json'
    params = {class="hl-string">'start_time': start_time, class="hl-string">'include': class="hl-string">'metric_sets'}
    all_tickets = []
    while tickets_url:
        try:
            print(fclass="hl-string">"Fetching from: {tickets_url}")
            response = session.get(tickets_url, params=params)
            class=class="hl-string">"hl-comment"># params are only needed for the first request
            params = {}
            if response.status_code == 429:
                print(class="hl-string">"Rate limit reached. Waiting for 60 seconds.")
                time.sleep(60)
                continue
            response.raise_for_status()
            data = response.json()
            all_tickets.extend(data.get(class="hl-string">'tickets', []))
            tickets_url = data.get(class="hl-string">'next_page')
            if not data.get(class="hl-string">'end_of_stream', True):
                 class=class="hl-string">"hl-comment"># Wait a moment before the next page request to be safe
                 time.sleep(1)
            else:
                print(fclass="hl-string">"End of stream reached. Final timestamp: {data.get('end_time')}")
                tickets_url = None
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching tickets: {e}")
            break
    return all_tickets

def process_ticket_audits(ticket, event_log):
    ticket_id = ticket[class="hl-string">'id']
    audits_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/audits.json'
    try:
        response = session.get(audits_url)
        response.raise_for_status()
        audits = response.json().get(class="hl-string">'audits', [])
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error fetching audits for ticket {ticket_id}: {e}")
        return

    base_attributes = {
        class="hl-string">'ProblemRecordId': ticket_id,
        class="hl-string">'SourceSystem': class="hl-string">'Zendesk Support',
        class="hl-string">'LastDataUpdate': ticket[class="hl-string">'updated_at'],
        class="hl-string">'Priority': ticket.get(class="hl-string">'priority'),
        class="hl-string">'RelatedIncidentCount': ticket.get(class="hl-string">'metric_set', {}).get(class="hl-string">'replies', 0), class=class="hl-string">"hl-comment"># Using replies as a proxy if incident_count is not available
        class="hl-string">'SlaDueDate': ticket.get(class="hl-string">'due_at'),
        class="hl-string">'ProblemCategory': next((f[class="hl-string">'value'] for f in ticket.get(class="hl-string">'custom_fields', []) if f.get(class="hl-string">'id') == class="hl-string">'[Your Problem Category Field ID]'), None)
    }

    class=class="hl-string">"hl-comment"># 1. Problem Record Logged
    event_log.append({
        **base_attributes,
        class="hl-string">'ActivityName': class="hl-string">'Problem Record Logged',
        class="hl-string">'EventTimestamp': ticket[class="hl-string">'created_at'],
        class="hl-string">'SupportGroup': get_group_name(ticket.get(class="hl-string">'group_id')),
        class="hl-string">'AssigneeName': get_user_name(ticket.get(class="hl-string">'assignee_id')),
        class="hl-string">'ProblemStatus': class="hl-string">'new',
        class="hl-string">'RootCauseCategory': None
    })

    class=class="hl-string">"hl-comment"># Process audit trail for other activities
    for audit in audits:
        audit_ts = audit[class="hl-string">'created_at']
        for event in audit.get(class="hl-string">'events', []):
            activity_name = None
            field_name = event.get(class="hl-string">'field_name')
            value = event.get(class="hl-string">'value')
            previous_value = event.get(class="hl-string">'previous_value')

            class=class="hl-string">"hl-comment"># 2. Assigned to Support Group
            if field_name == class="hl-string">'group_id' and value is not None:
                activity_name = class="hl-string">'Assigned to Support Group'
            
            class=class="hl-string">"hl-comment"># 3. Investigation Commenced (New -> Open)
            elif field_name == class="hl-string">'status' and value == class="hl-string">'open' and previous_value == class="hl-string">'new':
                activity_name = class="hl-string">'Investigation Commenced'

            class=class="hl-string">"hl-comment"># 4-9. Activities from Custom Fields
            elif str(field_name) in CUSTOM_FIELD_MAPPING and value is not None and value not in [False, class="hl-string">'0', class="hl-string">'']:
                activity_name = CUSTOM_FIELD_MAPPING[str(field_name)]

            class=class="hl-string">"hl-comment"># 10. Resolution Verified (Any -> Solved)
            elif field_name == class="hl-string">'status' and value == class="hl-string">'solved':
                activity_name = class="hl-string">'Resolution Verified'
            
            class=class="hl-string">"hl-comment"># 11. Problem Investigation Reopened (Solved/Closed -> Open)
            elif field_name == class="hl-string">'status' and value == class="hl-string">'open' and previous_value in [class="hl-string">'solved', class="hl-string">'closed']:
                activity_name = class="hl-string">'Problem Investigation Reopened'

            class=class="hl-string">"hl-comment"># 12. Problem Record Closed (Any -> Closed)
            elif field_name == class="hl-string">'status' and value == class="hl-string">'closed':
                activity_name = class="hl-string">'Problem Record Closed'

            if activity_name:
                class=class="hl-string">"hl-comment"># Find the state of attributes at the time of the event
                temp_status = value if field_name == class="hl-string">'status' else None
                temp_group = get_group_name(value) if field_name == class="hl-string">'group_id' else None
                temp_assignee = get_user_name(value) if field_name == class="hl-string">'assignee_id' else None
                temp_root_cause = value if str(field_name) == class="hl-string">'[Your Root Cause Category Field ID]' else None

                event_log.append({
                    **base_attributes,
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventTimestamp': audit_ts,
                    class="hl-string">'SupportGroup': temp_group,
                    class="hl-string">'AssigneeName': temp_assignee,
                    class="hl-string">'ProblemStatus': temp_status,
                    class="hl-string">'RootCauseCategory': temp_root_cause
                })

def main():
    print(class="hl-string">"Starting Zendesk Problem ticket extraction...")
    tickets = fetch_tickets(START_TIME)
    problem_tickets = [t for t in tickets if t.get(class="hl-string">'type') == class="hl-string">'problem']
    print(fclass="hl-string">"Found {len(problem_tickets)} problem tickets to process.")

    event_log_data = []
    for i, ticket in enumerate(problem_tickets):
        print(fclass="hl-string">"Processing ticket {i+1}/{len(problem_tickets)}: ID {ticket['id']}")
        process_ticket_audits(ticket, event_log_data)

    if not event_log_data:
        print(class="hl-string">"No events were generated. Exiting.")
        return

    df = pd.DataFrame(event_log_data)

    class=class="hl-string">"hl-comment"># Post-processing to fill forward null values for state attributes
    df = df.sort_values(by=[class="hl-string">'ProblemRecordId', class="hl-string">'EventTimestamp']).reset_index(drop=True)
    df[class="hl-string">'SupportGroup'] = df.groupby(class="hl-string">'ProblemRecordId')[class="hl-string">'SupportGroup'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'AssigneeName'] = df.groupby(class="hl-string">'ProblemRecordId')[class="hl-string">'AssigneeName'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'ProblemStatus'] = df.groupby(class="hl-string">'ProblemRecordId')[class="hl-string">'ProblemStatus'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'RootCauseCategory'] = df.groupby(class="hl-string">'ProblemRecordId')[class="hl-string">'RootCauseCategory'].fillna(method=class="hl-string">'ffill')

    class=class="hl-string">"hl-comment"># Define column order
    column_order = [
        class="hl-string">'ProblemRecordId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'Priority', class="hl-string">'SupportGroup', class="hl-string">'AssigneeName', class="hl-string">'ProblemStatus', class="hl-string">'RelatedIncidentCount',
        class="hl-string">'SlaDueDate', class="hl-string">'ProblemCategory', class="hl-string">'RootCauseCategory'
    ]
    df = df[column_order]

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

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

Möchten Sie loslegen?

Verbessern Sie noch heute die Stabilität Ihrer IT, indem Sie dieses Template auf Ihre Zendesk-Umgebung anwenden. Unser Team unterstützt Sie dabei, die Datenextraktion zu optimieren und mit Process Mining zu beginnen.

Zurück zum Leitfaden zur Prozessverbesserung Template herunterladen

Optimieren Sie Ihr Problemmanagement für schnellere IT-Lösungen

Verkürzen Sie Lösungszyklen um 30 Prozent und beseitigen Sie Engpässe in der IT.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. In wenigen Minuten eingerichtet.

Ihr Daten-Template für das Problemmanagement

Ihr Daten-Template für das Problemmanagement

Attribute des Problemmanagements

Aktivitäten im Problemmanagement

Anleitungen zur Datenextraktion

Zendesk Explore: Export des Änderungsverlaufs

Schritte

Konfiguration

a Beispielabfrage config

SQL-Abfrage über Zendesk Data Sharing

Schritte

Konfiguration

a Beispielabfrage sql

Python-Extraktion über die Incremental Export API

Schritte

Konfiguration

a Beispielabfrage python

Möchten Sie loslegen?

Optimieren Sie Ihr Problemmanagement für schnellere IT-Lösungen

Ihr Daten-Template für das Problemmanagement

Ihr Daten-Template für das Problemmanagement

Attribute des Problemmanagements

Aktivitäten im Problemmanagement

Anleitungen zur Datenextraktion

Zendesk Explore: Export des Änderungsverlaufs

Schritte

Konfiguration

a Beispielabfrage config

SQL-Abfrage über Zendesk Data Sharing

Schritte

Konfiguration

a Beispielabfrage sql

Python-Extraktion über die Incremental Export API

Schritte

Konfiguration

a Beispielabfrage python

Möchten Sie loslegen?

Optimieren Sie Ihr Problemmanagement für schnellere IT-Lösungen

Der Schutz Ihrer Daten ist uns wichtig