> Kontinuierliche Prozessverbesserung > Incident Management > Freshservice > Daten Template

Ihr Daten-Template für Incident Management

Freshservice

Attribute des Incident Managements (19) Aktivitäten des Incident Managements (14) Anleitungen zur Extraktion (3)

Ihr Daten-Template für Incident Management

Dieses Template unterstützt Sie dabei, Ihre Daten für eine aussagekräftige Analyse des Incident Managements vorzubereiten. Es beschreibt die wichtigsten zu erfassenden Attribute und relevanten Aktivitäten und enthält praktische Hinweise zum Extrahieren dieser Informationen aus Ihrem Quellsystem. Verwenden Sie diese Vorlage, um die Datenaufbereitung zu vereinfachen.

Empfohlene zu erfassende Attribute
Wichtige zu erfassende Aktivitäten
Hinweise zur Extraktion

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

Template herunterladen

Attribute des Incident Managements

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

5 Erforderlich 7 Empfohlen 7 Optional

	Name	Beschreibung
	Incident-ID IncidentId	Die eindeutige Kennung für jeden Incident-Datensatz. Sie dient als Primärschlüssel zur Nachverfolgung des gesamten Incident-Lebenszyklus.
Beschreibung Die Incident-ID bildet die Grundlage für die Analyse des Incident-Managements. Sie fungiert als Case-ID und verknüpft alle zugehörigen Aktivitäten, Timestamps und Attributänderungen zu einem zusammenhängenden Ablauf. Im Process Mining ist jeder Eintrag im Event Log einer Incident-ID zugeordnet. Dadurch lässt sich der durchgängige Prozessablauf für jeden Incident rekonstruieren. Das ist entscheidend, um Durchlaufzeiten zu berechnen, Prozessvarianten zu analysieren und Engpässe für einzelne Cases zu erkennen. Ohne eine eindeutige Kennung wäre es nicht möglich, verschiedene Incidents voneinander zu unterscheiden und ihre Wege von der Meldung bis zur Lösung zu analysieren. Warum das wichtig ist Sie identifiziert jeden Incident eindeutig und ermöglicht die durchgängige Nachverfolgung und Analyse seines Lebenszyklus von der Erstellung bis zum Abschluss. Bezugsquelle Dies ist die primäre Kennung eines Tickets. Sie ist über die Freshservice Tickets API als Feld „id“ im Ticketobjekt verfügbar. Beispiele INC-10234INC-10235INC-10236
	Aktivitätsname ActivityName	Der Name der konkreten Geschäftsaktivität oder des Ereignisses, das zu einem bestimmten Zeitpunkt im Incident-Lebenszyklus stattgefunden hat.
Beschreibung Der Aktivitätsname beschreibt einen einzelnen Schritt oder ein Ereignis im Incident-Management-Prozess, etwa „Incident Assigned to Group“, „Status Changed to Pending“ oder „Incident Resolved“. Diese Aktivitäten werden aus zeitlichen Änderungen der Incident-Daten abgeleitet. Dieses Attribut ist für Process Mining grundlegend, da es die Knoten in der ermittelten Prozessübersicht definiert. Durch die Analyse von Reihenfolge und Häufigkeit dieser Aktivitäten können Unternehmen den tatsächlichen Prozess zur Lösung von Incidents visualisieren, typische Abläufe erkennen, Abweichungen vom Standardverfahren feststellen und Schleifen durch Nacharbeit wie häufige Neuzuweisungen identifizieren. Warum das wichtig ist Es definiert die Schritte in der Prozessübersicht und ermöglicht die Visualisierung und Analyse des Ablaufs zur Incident-Lösung, von Engpässen und Abweichungen. Bezugsquelle Dieses Attribut ist kein direktes Feld in Freshservice, sondern wird aus Änderungen von Ticketeigenschaften wie Status, Priorität, Agenten- oder Gruppenzuweisung sowie dem Hinzufügen von Notizen abgeleitet. Beispiele Vorfall gemeldetVorfall einer Gruppe zugewiesenLösungsnotiz hinzugefügtVorfall gelöst
	Ereignis-Timestamp EventTimestamp	Das genaue Datum und die genaue Uhrzeit, zu denen die Aktivität oder das Ereignis stattgefunden hat.
Beschreibung Der Ereignis-Timestamp, auch Startzeit genannt, kennzeichnet den genauen Zeitpunkt, zu dem eine Aktivität stattgefunden hat. Jede Aktivität im Lebenszyklus eines Incidents, von der Erstellung bis zum Abschluss, verfügt über einen zugehörigen Timestamp. Dieses Attribut ist für alle zeitbezogenen Process-Mining-Analysen entscheidend. Es dient dazu, Ereignisse chronologisch zu ordnen, die Dauer zwischen Aktivitäten zu berechnen, die gesamte Case-Durchlaufzeit zu messen und Wartezeiten zu analysieren. Es bildet die Grundlage für Dashboards zur Überwachung der SLA-Leistung, von Verzögerungen bei Übergaben und der gesamten Lösungsdauer. Warum das wichtig ist Es liefert die chronologische Reihenfolge der Ereignisse. Diese ist entscheidend für die Berechnung von Dauern, die Analyse von Durchlaufzeiten und das Verständnis der Prozessleistung. Bezugsquelle Dieses Attribut wird aus verschiedenen Timestamp-Feldern in Freshservice abgeleitet, etwa „created_at“, „updated_at“ sowie Timestamps innerhalb der Konversations- oder Audit-Protokolle des Tickets. Beispiele 2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
	Letzte Datenaktualisierung LastDataUpdate	Der Timestamp, der angibt, wann die Daten für diesen Prozess zuletzt aktualisiert oder extrahiert wurden.
Beschreibung Dieses Attribut enthält den Timestamp der letzten Aktualisierung des gesamten Datensatzes aus dem Quellsystem. Es handelt sich um ein Metadatenfeld, das für den gesamten Datensatz und nicht für einzelne Ereignisse gilt. Aus Gründen der Konsistenz wird es jedoch häufig auf Ereignisebene aufgenommen. Für die Analyse ist diese Information wichtig, um die Aktualität der Daten und den von Dashboards und KPIs abgedeckten Zeitraum zu verstehen. Sie schafft Vertrauen in die Aktualität der Erkenntnisse und hilft dabei einzuschätzen, ob die neuesten Incidents bereits in der Analyse enthalten sind. Warum das wichtig ist Es informiert Benutzer über die Aktualität der Daten und stellt sicher, dass der von der Analyse abgedeckte Zeitraum verständlich ist. Bezugsquelle Dieser Metadaten-Timestamp wird während der Datenextraktion (ETL) erzeugt. Beispiele 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	Quellsystem SourceSystem	Das System, aus dem die Daten extrahiert wurden, in der Regel „Freshservice“.
Beschreibung Dieses Attribut identifiziert die Herkunft der Daten. In diesem Kontext lautet der Wert zwar durchgehend „Freshservice“, in Umgebungen mit Daten aus mehreren Systemen ist das Feld jedoch entscheidend für eine umfassende Prozesssicht. Die Aufnahme des Attributs „Quellsystem“ gilt als bewährte Praxis für Data Governance und Nachvollziehbarkeit. Sie schafft Klarheit über die Datenherkunft, was für Validierung und Fehleranalyse wichtig ist. Außerdem erleichtert sie die spätere Erweiterung des Process-Mining-Projekts um weitere Service-Management- oder operative Systeme. Warum das wichtig ist Es gewährleistet die Nachvollziehbarkeit und Governance der Daten, indem es die Herkunft der Incident-Management-Daten eindeutig ausweist. Bezugsquelle In der Regel handelt es sich um einen statischen Wert, der während der Datentransformation (ETL) zur Kennzeichnung des Datensatzes hinzugefügt wird. Beispiele FreshserviceFreshservice-EUFreshservice-PROD
	Incident-Kategorie IncidentCategory	Die Kategorie zur Klassifizierung des Incidents, etwa „Hardware“, „Software“ oder „Network“.
Beschreibung Die Incident-Kategorie ermöglicht die Klassifizierung von Incidents nach der Art des gemeldeten Problems. Diese hierarchische Klassifizierung unterstützt die Weiterleitung an das richtige Team und ist für die Trendanalyse wichtig. Dieses Attribut wird im Dashboard „Genauigkeit der Incident-Kategorisierung“ verwendet, um zu analysieren, ob eine anfänglich falsche Kategorisierung durch Neuzuweisungen zu längeren Lösungszeiten führt. Durch die Gruppierung von Incidents nach Kategorie können Unternehmen wiederkehrende Probleme erkennen, den Schwerpunkt des Supportaufwands verstehen und Verbesserungsmaßnahmen gezielt ausrichten. Warum das wichtig ist Sie ermöglicht die Analyse von Incident-Trends und hilft festzustellen, ob eine falsche Kategorisierung zu Verzögerungen bei der Lösung führt. Bezugsquelle Dies ist ein standardmäßig vorhandenes, aber anpassbares Feld in Freshservice. Es ist in der Tickets API als „category“ verfügbar, ergänzt durch die zugehörigen Felder „sub_category“ und „item_category“. Beispiele HardwareSoftwareNetzwerkproblemKontozugriff
	Incident-Priorität IncidentPriority	Die Prioritätsstufe des Incidents. Sie bestimmt die Dringlichkeit der Reaktion und Lösung.
Beschreibung Die Incident-Priorität ist ein zentrales Feld, das vorgibt, wie schnell und mit welcher Aufmerksamkeit ein Incident bearbeitet werden muss. Üblicherweise wird sie auf einer Skala wie „Low“, „Medium“, „High“ und „Urgent“ festgelegt und bestimmt häufig die SLA-Ziele. Im Process Mining ist die Priorität eine wichtige Dimension für Filterung und Analyse. Sie ermöglicht den Vergleich der Lösungsprozesse für Incidents mit hoher und niedriger Priorität und stellt sicher, dass kritische Probleme effizient bearbeitet werden. Dashboards unterteilen Kennzahlen wie Durchlaufzeit und SLA-Einhaltung häufig nach Priorität, um Managern verwertbare Erkenntnisse bereitzustellen. Warum das wichtig ist Sie hilft dabei, die Analyse auf die kritischsten Incidents zu konzentrieren, und ist für die Bewertung der SLA-Leistung und der Ressourcenverteilung unerlässlich. Bezugsquelle Verfügbar in der Freshservice Tickets API als Feld „priority“. Die Werte sind numerisch, zum Beispiel 1 für „Low“ und 4 für „Urgent“. Beispiele NiedrigMittelHochDringend
	Incident-Schweregrad IncidentSeverity	Die Schweregradstufe des Incidents, die seine geschäftlichen Auswirkungen angibt.
Beschreibung Der Incident-Schweregrad misst die Auswirkungen eines Incidents auf das Unternehmen und wird häufig als „Low“, „Medium“, „High“ oder „Critical“ kategorisiert. Obwohl er mit der Priorität zusammenhängt, beschreibt der Schweregrad die Auswirkung, während die Priorität die Dringlichkeit angibt. Die Kombination aus Schweregrad und Auswirkung bestimmt häufig die endgültige Priorität. Die Analyse nach Schweregrad zeigt, wie gut das Unternehmen Incidents mit erheblichen geschäftlichen Folgen bearbeitet. In Dashboards dient dieses Attribut dazu, Lösungszeiten und SLA-Leistung zu segmentieren. So lässt sich sicherstellen, dass besonders folgenreiche Probleme während ihres gesamten Lebenszyklus die angemessene Aufmerksamkeit und die erforderlichen Ressourcen erhalten. Warum das wichtig ist Es misst die geschäftlichen Auswirkungen eines Incidents und ermöglicht eine Analyse mit Fokus auf der Eindämmung besonders schädlicher Probleme. Bezugsquelle Dies ist ein Standardfeld in Freshservice, das über die Tickets API als „impact“ verfügbar ist. Die Werte sind numerisch. Beispiele NiedrigMittelHoch
	Incident-Status IncidentStatus	Der aktuelle Status des Incidents in seinem Lebenszyklus, etwa „Open“, „Pending“, „Resolved“ oder „Closed“.
Beschreibung Der Incident-Status gibt den aktuellen Zustand des Incidents an. Statusänderungen bilden wichtige Ereignisse und die Grundlage der ermittelten Prozessübersicht, etwa der Wechsel von „In Progress“ zu „Pending“ oder von „Resolved“ zu „Closed“. Dieses Attribut ist grundlegend, um den Verlauf eines Incidents zu verstehen. Die Analyse der in den einzelnen Status verbrachten Zeit hilft, Engpässe zu erkennen, etwa wenn Incidents zu lange im Status „Pending“ auf eine Antwort des Benutzers warten. Außerdem ist der Status entscheidend für die Definition von Start- und Endpunkten bei der Berechnung von Durchlaufzeiten. Warum das wichtig ist Es verfolgt den Fortschritt des Incidents durch seinen Lebenszyklus und hilft, Phasen mit häufigen Verzögerungen zu erkennen. Bezugsquelle Verfügbar in der Freshservice Tickets API als Feld „status“. Die Werte sind numerisch. Beispiele OffenIn BearbeitungAusstehendGelöstGeschlossen
	Zielzeit für die Lösungs-SLA ResolutionSlaTargetTime	Der Timestamp, bis zu dem der Incident gemäß seiner SLA-Richtlinie voraussichtlich gelöst sein soll.
Beschreibung Dieses Attribut speichert das konkrete Datum und die konkrete Uhrzeit, die als Frist für die Lösung eines Incidents gelten. Das Ziel wird durch die auf das Ticket angewendete Service-Level-Agreement-(SLA-)Richtlinie bestimmt und hängt typischerweise von Faktoren wie der Priorität ab. Diese Zielzeit ist für die Berechnung des KPIs „SLA-Einhaltungsquote“ und für das Dashboard „SLA-Leistung“ unerlässlich. Durch den Vergleich des tatsächlichen Lösungs-Timestamps mit diesem Ziel lässt sich feststellen, ob ein Incident fristgerecht gelöst oder die SLA verletzt wurde. Das ist eine zentrale Grundlage für die Messung der Einhaltung von Service-Level-Vereinbarungen. Warum das wichtig ist Es liefert die Frist für die Lösung und ist damit für die Berechnung der SLA-Konformität und die Identifizierung gefährdeter Incidents erforderlich. Bezugsquelle Verfügbar in der Freshservice Tickets API als die Felder „fr_due_by“ (erste Antwort) und „due_by“ (Lösung). Beispiele 2023-10-26T14:00:00Z2023-10-27T09:00:00Z2023-11-05T17:00:00Z
	Zugewiesene Gruppe AssignedGroup	Die Supportgruppe oder das Team, die beziehungsweise das aktuell für den Incident zuständig ist.
Beschreibung Die zugewiesene Gruppe gibt an, welches Team, etwa „Level 1 Support“, „Network Team“ oder „Database Admins“, für den Incident verantwortlich ist. Änderungen an diesem Attribut weisen auf eine Eskalation oder Übergabe zwischen verschiedenen Funktionsteams hin. Die Analyse der zugewiesenen Gruppe ist entscheidend, um Verzögerungen bei Übergaben und Weiterleitungen zu verstehen. Process Mining kann den Fluss von Incidents zwischen Gruppen visualisieren, häufige Eskalationswege hervorheben und die Wartezeit messen, bis die jeweilige Gruppe aktiv wird. So lassen sich organisatorische Engpässe und Möglichkeiten für eine bessere Zusammenarbeit zwischen Teams erkennen. Warum das wichtig ist Es erfasst, welches Team verantwortlich ist. Das ist entscheidend für die Analyse von Übergaben, Eskalationen und Verzögerungen zwischen Teams. Bezugsquelle Verfügbar in der Freshservice Tickets API als Feld „group_id“. Diese ID kann mit der Groups API verknüpft werden, um den Namen der Gruppe abzurufen. Beispiele Service DeskNetzwerkbetriebInfrastruktursupport
	Zugewiesener Agent AssignedAgent	Der Name oder die ID des Support-Agenten, der aktuell für die Lösung des Incidents zuständig ist.
Beschreibung Der zugewiesene Agent bezeichnet den einzelnen Mitarbeiter des Service Desks, der zu einem bestimmten Zeitpunkt für den Incident verantwortlich ist. Änderungen an diesem Attribut zeigen eine Übertragung der Verantwortung zwischen Agenten an. Dieses Attribut ist für die Leistungsanalyse entscheidend. Es ermöglicht Dashboards zur Überwachung der Arbeitslast von Agenten, der durchschnittlichen Lösungsdauer je Agent und der Lösungsquote beim Erstkontakt. Außerdem lässt sich damit die Übergabe zwischen Agenten analysieren, die eine Ursache für Verzögerungen und Ineffizienz sein kann. Durch die Nachverfolgung von Agentenzuweisungen können Manager Schulungsbedarf erkennen und besonders leistungsstarke Teammitglieder identifizieren. Warum das wichtig ist Es ermöglicht die Analyse der Agentenleistung, der Verteilung von Arbeitslasten und des Einflusses von Übergaben zwischen Agenten auf die Lösungsdauer. Bezugsquelle Verfügbar in der Freshservice Tickets API als Feld „responder_id“. Diese ID kann mit der Agents API verknüpft werden, um den Namen des Agenten abzurufen. Beispiele John DoeJane SmithSupportBot
	Abteilung des Meldenden RequestersDepartment	Die Abteilung, der der Benutzer angehört, der den Incident gemeldet hat.
Beschreibung Dieses Attribut identifiziert die Geschäftsabteilung des Meldenden, etwa „Sales“, „Finance“ oder „IT“. Die Information stammt in der Regel aus dem Benutzerprofil in Freshservice. Die Analyse von Incidents nach der Abteilung des Meldenden kann zeigen, ob bestimmte Geschäftsbereiche überproportional von Problemen betroffen sind oder ob abteilungsspezifische Probleme bestehen. Sie liefert wertvollen Kontext zu den geschäftlichen Auswirkungen von Incidents und kann dabei helfen, Korrekturen für besonders wichtige Abteilungen zu priorisieren. Warum das wichtig ist Es liefert geschäftlichen Kontext und ermöglicht die Analyse von Incident-Trends und Auswirkungen auf bestimmte Abteilungen. Bezugsquelle Diese Information ist mit dem Meldenden des Tickets verknüpft. Sie kann über den API-Endpunkt „Requesters“ abgerufen werden, indem „requester_id“ aus dem Ticket verwendet und anschließend auf „department_id“ und den Namen zugegriffen wird. Beispiele VertriebMarketingFinanzenPersonalwesen
	Anzahl der Übergaben HandoffCount	Die Anzahl der Übertragungen eines Incidents zwischen verschiedenen Agenten oder Gruppen.
Beschreibung Die Anzahl der Übergaben ist eine berechnete Kennzahl, die erfasst, wie oft ein Incident während seines Lebenszyklus neu zugewiesen wird. Jede Änderung des Attributs „AssignedAgent“ oder „AssignedGroup“ erhöht diesen Wert. Eine hohe Anzahl von Übergaben weist häufig auf ineffiziente Prozesse, eine falsche anfängliche Weiterleitung oder fehlendes Fachwissen bei Agenten hin. Diese Kennzahl unterstützt direkt den KPI „Anzahl der Incident-Übergaben“ und das Dashboard „Analyse von Verzögerungen durch Übergaben und Übertragungen“. Damit lassen sich Incidents oder Prozesspfade mit übermäßig vielen Übertragungen erkennen, die zu Verzögerungen führen. Warum das wichtig ist Sie quantifiziert Nacharbeit und Neuzuweisungen und hilft, Ineffizienzen durch falsche Weiterleitung oder Wissenslücken zu erkennen. Bezugsquelle Dies ist eine berechnete Kennzahl, die aus der Anzahl unterschiedlicher Werte oder Änderungen in den Feldern „AssignedAgent“ oder „AssignedGroup“ während des Lebenszyklus eines einzelnen Incidents abgeleitet wird. Beispiele 0125
	Meldekanal ReportingChannel	Die Methode oder der Kanal, über den der Incident gemeldet wurde, etwa per E-Mail, Portal oder Telefon.
Beschreibung Der Meldekanal, auch Quelle genannt, gibt an, wie ein Incident in das Supportsystem gelangt ist. Zu den gängigen Kanälen gehören E-Mail, ein Self-Service-Portal, Telefonanrufe und Chat. Die Analyse dieses Attributs hilft, die Effizienz verschiedener Meldekanäle zu bewerten. Das Dashboard „Effizienz der Meldekanäle“ vergleicht Incident-Volumen und durchschnittliche Lösungsdauer je Kanal. So lässt sich feststellen, welche Methoden besonders wirksam sind und wo Prozessverbesserungen erforderlich sein könnten. Über das Portal gemeldete Incidents können beispielsweise schneller gelöst werden, wenn sie von Anfang an strukturiertere Informationen enthalten. Warum das wichtig ist Es hilft, die effizientesten Meldekanäle zu erkennen, und zeigt Möglichkeiten zur Verbesserung der Incident-Erfassung auf. Bezugsquelle Verfügbar in der Freshservice Tickets API als Feld „source“. Die Werte sind numerisch. Beispiele E-MailPortalTelefonChat
	SLA verletzt IsSlaBreached	Ein berechnetes Kennzeichen, das den Wert „true“ hat, wenn der Incident nicht innerhalb der festgelegten SLA-Zielzeit gelöst wurde.
Beschreibung Dieses boolesche Attribut ist eine berechnete Kennzahl und gibt an, ob die Lösungszeit eines Incidents die SLA-Zielzeit überschritten hat. Es wird durch den Vergleich des tatsächlichen Lösungs-Timestamps mit „ResolutionSlaTargetTime“ abgeleitet. Dieses Kennzeichen fließt direkt in den KPI „SLA-Einhaltungsquote“ und das Dashboard „SLA-Leistung“ ein. Es vereinfacht die Analyse, da es für die SLA-Leistung jedes Incidents ein eindeutiges binäres Ergebnis liefert und dadurch Aggregationen und Trendanalysen erleichtert. So lässt sich schnell erkennen, wie viele Incidents die Serviceverpflichtungen nicht erfüllen und welcher Anteil davon betroffen ist. Warum das wichtig ist Es misst die SLA-Konformität für jeden Incident direkt und erleichtert dadurch die Berechnung der Gesamteinhaltungsquote sowie die Identifizierung von Problembereichen. Bezugsquelle Dies ist ein berechnetes Feld, das während der Datentransformation durch den Vergleich des Timestamps „Incident Resolved“ mit dem Feld „ResolutionSlaTargetTime“ abgeleitet wird. Beispiele truefalse
	Ursache RootCause	Der nach der Untersuchung ermittelte zugrunde liegende Grund oder die Ursache des Incidents.
Beschreibung Das Attribut „Ursache“ erfasst das grundlegende Problem, das zum Incident geführt hat. Diese Information wird von Support-Agenten in der Regel während oder nach der Lösung im Rahmen einer Ursachenanalyse (RCA) eingetragen. Dieses Attribut ist für das Dashboard „Wiederkehrende Incidents und Ursachen“ sowie für den KPI „Abschlussquote der Ursachenanalyse“ entscheidend. Durch die Analyse häufiger Ursachen können Unternehmen von der reaktiven Incident-Behebung zu einem proaktiven Problem-Management übergehen. So lassen sich dauerhafte Lösungen umsetzen, die künftige Incidents verhindern und wiederkehrende Probleme reduzieren. Warum das wichtig ist Es ermöglicht ein proaktives Problem-Management, indem es hilft, die zugrunde liegenden Ursachen wiederkehrender Incidents zu erkennen und zu beseitigen. Bezugsquelle Dies ist in Freshservice häufig ein benutzerdefiniertes Feld, da die Standardfunktionen möglicherweise nicht ausreichen. Prüfen Sie die Konfiguration der „Ticket Fields“ auf ein Feld mit dem Namen „Root Cause“ oder einer ähnlichen Bezeichnung. Beispiele SoftwarefehlerFehler in der NetzwerkkonfigurationProblem bei der BenutzerschulungHardwareausfall
	Wiedereröffnet IsReopened	Ein berechnetes Kennzeichen, das den Wert „true“ hat, wenn ein Incident nach der Lösung oder dem Abschluss wiedereröffnet wurde.
Beschreibung Dieses boolesche Attribut ist ein berechnetes Kennzeichen für Incidents, die wiedereröffnet wurden. Es wird auf „true“ gesetzt, wenn der Status eines Incidents nach dem Erreichen des Zustands „Resolved“ oder „Closed“ wieder in einen offenen oder in Bearbeitung befindlichen Zustand wechselt. Dieses Kennzeichen ist entscheidend für die Berechnung des KPIs „Wiedereröffnungsquote von Incidents“ und für das Dashboard „Wiederkehrende Incidents“. Eine hohe Wiedereröffnungsquote kann auf eine unzureichende Qualität der ursprünglichen Lösung, eine unvollständige Ursachenanalyse oder einen verfrühten Abschluss hinweisen. Die Analyse dieser Fälle hilft, die Qualität und Nachhaltigkeit von Lösungen zu verbessern. Warum das wichtig ist Es identifiziert Fehler im Lösungsprozess und hebt Incidents hervor, bei denen die ursprüngliche Behebung unwirksam war und zu Nacharbeit führte. Bezugsquelle Dies ist ein berechnetes Feld, das aus der Abfolge der Aktivitäten im Event Log abgeleitet wird. Der Wert ist „true“, wenn eine Aktivität wie „Incident Reopened“ auftritt oder bei derselben Incident-ID nach einem Abschlussstatus eine Aktivität mit offenem Status folgt. Beispiele truefalse
	Workaround bereitgestellt WorkaroundProvided	Ein Kennzeichen dafür, ob dem Benutzer vor der endgültigen Lösung ein vorübergehender Workaround bereitgestellt wurde.
Beschreibung Dieses boolesche Attribut gibt an, ob eine vorübergehende Lösung oder ein Workaround umgesetzt wurde, um die Auswirkungen des Incidents zu begrenzen, während eine dauerhafte Lösung entwickelt wurde. Die Erfassung erfolgt häufig über ein Kontrollkästchen oder einen bestimmten Status. Im Process Mining unterstützt dieses Attribut das Dashboard „Kennzahlen zur Wirksamkeit von Workarounds“. Es ermöglicht den Vergleich der Lösungszeiten von Incidents mit und ohne Workaround. So lässt sich feststellen, ob vorübergehende Lösungen die Geschäftsunterbrechung wirksam reduzieren und aus Sicht des Benutzers zu einer schnelleren Gesamtlösung beitragen. Warum das wichtig ist Es hilft, die Wirksamkeit vorübergehender Workarounds bei der Reduzierung der Incident-Auswirkungen und der Beschleunigung der wahrgenommenen Lösung zu messen. Bezugsquelle Dies ist in der Regel ein benutzerdefiniertes boolesches Feld (Kontrollkästchen). Das Vorhandensein des Felds muss in der Freshservice-Konfiguration „Ticket Fields“ überprüft werden. Beispiele truefalse

Erforderlich Empfohlen Optional

Aktivitäten des Incident Managements

Dies sind die zentralen Prozessschritte und Meilensteine, die Sie für eine präzise Prozesserkennung und Identifizierung von Engpässen in Ihrem Event Log erfassen sollten.

7 Empfohlen 7 Optional

	Aktivität	Beschreibung
	Incident geschlossen	Bezeichnet den endgültigen, formalen Abschluss des Incident-Datensatzes. Dies geschieht in der Regel automatisch nach einem festgelegten Zeitraum im Status „Resolved“ oder kann manuell durch einen Agenten erfolgen. Dieses Ereignis markiert das Ende des Incident-Lebenszyklus.
Warum das wichtig ist Diese Aktivität bildet den endgültigen Endpunkt des Prozesses. Die Gesamtzeit bis zu diesem Ereignis entspricht der vollständigen Dauer des Incident-Lebenszyklus, einschließlich möglicher Zeiträume für die Bestätigung durch den Benutzer. Bezugsquelle Aus dem Aktivitätsprotokoll des Incidents abgeleitet, indem ermittelt wird, wann das Feld „Status“ auf „Closed“ aktualisiert wurde. Erfassen Verwenden Sie den Timestamp des Eintrags im Aktivitätsprotokoll für die Statusänderung zu „Closed“. Ereignistyp inferred
	Lösungsnotiz hinzugefügt	Dieses Ereignis tritt ein, wenn ein Agent die Lösung des Vorfalls durch das Hinzufügen einer Lösungsnotiz dokumentiert. In Freshservice handelt es sich dabei um eine eigenständige Aktion vor der Änderung des Status in „Resolved“. Die Aktion und ihr Inhalt werden ausdrücklich protokolliert.
Warum das wichtig ist Dies kennzeichnet die Identifizierung einer Lösung. Der Zeitraum zwischen diesem Ereignis und dem Status „Incident Resolved“ kann auf internen Prüf- oder Dokumentationsaufwand hinweisen. Bezugsquelle Erfasst anhand des Timestamps, zu dem eine Lösungsnotiz zum Vorfall hinzugefügt wird. Dieser Timestamp wird in der Gesprächshistorie protokolliert. Erfassen Identifizieren Sie den Timestamp des Eintrags „Resolution Note“ im Gesprächsprotokoll des Vorfalls. Ereignistyp explicit
	Priorität des Vorfalls festgelegt	Dieses Ereignis tritt ein, wenn die Priorität eines Vorfalls festgelegt oder aktualisiert wird. Die Prioritätsstufe bestimmt die Dringlichkeit und die SLA-Ziele für die Lösung. Erfasst wird dies durch die Überwachung von Änderungen am Feld „Priority“ in der Historie des Vorfalls.
Warum das wichtig ist Eine falsche oder verspätete Priorisierung kann zu SLA-Verletzungen und einer ineffizienten Ressourcenverteilung führen. Die Analyse dieser Aktivität hilft sicherzustellen, dass kritische Vorfälle sofort bearbeitet werden. Bezugsquelle Abgeleitet aus dem Aktivitätsprotokoll des Vorfalls, das alle Aktualisierungen des Felds „Priority“ erfasst. Erfassen Verwenden Sie die Timestamps aus dem Audit-Log, an denen der Wert des Felds „Priority“ festgelegt oder geändert wurde. Ereignistyp inferred
	Status in „In Progress“ geändert	Diese Aktivität kennzeichnet den offiziellen Beginn der aktiven Untersuchung und Bearbeitung des Vorfalls. Sie wird erfasst, wenn ein Agent den Status des Vorfalls in „In Progress“ ändert. Dies ist eine standardmäßige Statusänderung, die in der Aktivitätshistorie des Tickets protokolliert wird.
Warum das wichtig ist Dieser Meilenstein unterscheidet Wartezeit von aktiver Bearbeitungszeit. Die Analyse der Dauer, während der ein Vorfall den Status „In Progress“ hat, ist entscheidend, um den Lösungsaufwand zu verstehen. Bezugsquelle Abgeleitet aus dem Aktivitätsprotokoll des Vorfalls durch die Identifizierung des Zeitpunkts, an dem das Feld „Status“ in „In Progress“ geändert wird. Erfassen Filtern Sie das Aktivitätsprotokoll nach einer Statusänderung in „In Progress“ und verwenden Sie den zugehörigen Timestamp. Ereignistyp inferred
	Vorfall einer Gruppe zugewiesen	Bezeichnet die erste Zuweisung eines Vorfalls an eine Support-Gruppe. Sie kann automatisch über Routing-Regeln oder manuell durch einen Dispatcher erfolgen. Die Aktivität wird erfasst, indem der erste Eintrag des Felds „Group“ im Audit-Log des Vorfalls verfolgt wird.
Warum das wichtig ist Die Nachverfolgung von Zuweisungen ist entscheidend, um Erstreaktionszeiten zu messen und Bottlenecks im Dispatching-Prozess zu erkennen. So lässt sich analysieren, wie effizient Vorfälle an das zuständige Team weitergeleitet werden. Bezugsquelle Abgeleitet aus dem ersten Eintrag im Aktivitätsprotokoll des Vorfalls, der das Feld „Group“ befüllt oder ändert. Erfassen Identifizieren Sie den ersten Timestamp, an dem das Feld „Group“ für einen Vorfall befüllt wird. Ereignistyp inferred
	Vorfall gelöst	Kennzeichnet den Zeitpunkt, an dem der Agent eine Korrektur umgesetzt hat und den Vorfall als gelöst betrachtet. Erfasst wird dies, wenn der Status des Vorfalls in „Resolved“ geändert wird. In Freshservice ist dies ein wichtiger Meilenstein, an dem die SLA-Uhr stoppt.
Warum das wichtig ist Dies ist ein entscheidender Meilenstein für die Messung der Time to Resolution, TTR. Der Zeitraum zwischen „Resolved“ und „Closed“ ist wichtig, um Verzögerungen bei der Benutzerbestätigung und Richtlinien zur automatischen Schließung zu analysieren. Bezugsquelle Abgeleitet aus dem Aktivitätsprotokoll des Vorfalls durch die Identifizierung des Zeitpunkts, an dem das Feld „Status“ in „Resolved“ geändert wird. Erfassen Verwenden Sie den Timestamp des Eintrags zur Statusänderung in „Resolved“ aus dem Aktivitätsprotokoll. Ereignistyp inferred
	Vorfall gemeldet	Kennzeichnet die Erstellung eines neuen Vorfalldatensatzes in Freshservice. Dies ist der Startpunkt des Vorfalllebenszyklus. Typischerweise löst ein Endbenutzer den Vorgang über ein Portal oder per E-Mail aus, oder ein Service-Desk-Agent erstellt stellvertretend ein Ticket. Dieses Ereignis wird mit einem Erstellungs-Timestamp ausdrücklich protokolliert.
Warum das wichtig ist Diese Aktivität ist das zentrale Start-Ereignis des gesamten Prozesses. Die Analyse der Zeit von diesem Ereignis bis zur Lösung ist grundlegend für die Messung der gesamten Durchlaufzeiten und der SLA-Einhaltung. Bezugsquelle Erfasst aus dem Erstellungs-Timestamp der Vorfalltabelle. Freshservice protokolliert diesen Wert ausdrücklich für jedes neue Ticket. Erfassen Verwenden Sie den Timestamp „Created at“ aus dem zentralen Vorfalldatensatz. Ereignistyp explicit
	Agent einem Vorfall zugewiesen	Diese Aktivität kennzeichnet den Zeitpunkt, zu dem ein bestimmter Agent mit der Bearbeitung des Vorfalls beauftragt wird. Damit geht die individuelle Verantwortung für das Ticket über. Die Zuweisung wird in der Aktivitätshistorie des Tickets mit dem zuständigen Agent und dem Zeitpunkt protokolliert.
Warum das wichtig ist Damit lassen sich Arbeitslast und Leistung von Agents sowie die Zeit zwischen der Gruppenzuweisung und der Übernahme durch einen einzelnen Agent analysieren. Die Aktivität ist für Agentenleistungs-Dashboards besonders wichtig. Bezugsquelle Verfolgt über Änderungen am Feld „Agent“ im Aktivitätsprotokoll oder Audit-Trail des Vorfalls. Erfassen Identifizieren Sie die Timestamps, die Änderungen am Feld „Agent“ entsprechen. Ereignistyp inferred
	Erste Antwort gesendet	Diese Aktivität bezeichnet die erste Kommunikation eines Agents mit dem Benutzer nach der Meldung des Vorfalls. Dabei kann es sich um eine öffentliche Notiz oder eine direkte Antwort handeln. Freshservice protokolliert alle Mitteilungen von Agents mit Timestamps.
Warum das wichtig ist Die Einhaltung des SLA für die erste Antwort ist eine wichtige KPI für die Kundenzufriedenheit. Diese Aktivität ermöglicht die Messung und Analyse, wie schnell Agents auf neue Vorfälle reagieren. Bezugsquelle Identifiziert anhand des Timestamps der ersten öffentlichen Notiz oder Antwort eines Agents im Gesprächsprotokoll des Vorfalls. Erfassen Filtern Sie die Gesprächshistorie des Vorfalls nach dem frühesten von einem Agent erstellten Eintrag. Ereignistyp explicit
	SLA-Ziel verfehlt	Dies ist ein berechnetes Ereignis, das eintritt, wenn die verstrichene Zeit eines Vorfalls das definierte SLA-Ziel für Reaktion oder Lösung überschreitet. Freshservice verfolgt den SLA-Status intern. Das Ereignis kann durch den Vergleich von Timestamps mit den SLA-Richtlinien abgeleitet werden.
Warum das wichtig ist Misst die Einhaltung von Servicezusagen direkt. Für das SLA-Performance-Dashboard und die kontinuierliche Verbesserung ist es entscheidend zu erkennen, wann und warum SLA-Verletzungen auftreten. Bezugsquelle Berechnet durch den Vergleich des Lösungs- oder Antwort-Timestamps mit dem Fälligkeitszeitpunkt des SLA-Ziels. Freshservice kennzeichnet Tickets häufig als „SLA Violated“. Erfassen Leiten Sie das Ereignis durch den Vergleich des Timestamps „Resolved at“ mit „Due by“ ab oder wenn sich das Feld „SLA Status“ in „Violated“ ändert. Ereignistyp calculated
	Status in „Pending“ geändert	Bezeichnet einen Zeitpunkt, an dem der Lösungsprozess pausiert, typischerweise weil Informationen von einem Benutzer oder einem Dritten ausstehen. Das Ereignis wird aus einer Statusänderung in einen „Pending“-Status abgeleitet. Die in diesem Status verbrachte Zeit wird bei SLA-Berechnungen häufig nicht berücksichtigt.
Warum das wichtig ist Die Erfassung der in „Pending“-Status verbrachten Zeit ist entscheidend, um externe Abhängigkeiten und Verzögerungen zu verstehen. So lässt sich die Bearbeitungszeit von Agents von der Wartezeit trennen. Bezugsquelle Abgeleitet aus dem Aktivitätsprotokoll des Vorfalls, wenn das Feld „Status“ auf einen Wert wie „Pending“ oder „Awaiting User Response“ geändert wird. Erfassen Filtern Sie das Aktivitätsprotokoll nach Statusänderungen in einen beliebigen „Pending“-Status und verwenden Sie den zugehörigen Timestamp. Ereignistyp inferred
	Vorfall neu zugewiesen	Zeigt an, dass der Vorfall von einem Agent oder einer Gruppe an einen anderen Agent oder eine andere Gruppe übertragen wurde. Dies kennzeichnet eine Übergabe im Lösungsprozess. Das Ereignis wird abgeleitet, indem nach der ersten Zuweisung weitere Änderungen an den Feldern „Agent“ oder „Group“ erkannt werden.
Warum das wichtig ist Häufige Neuzuweisungen oder Übergaben weisen oft auf Prozessineffizienzen, Wissenslücken oder eine falsche Erstweiterleitung hin. Die Analyse dieser Ereignisse hilft, Verzögerungen zu erkennen und zu reduzieren. Bezugsquelle Abgeleitet aus dem Aktivitätsprotokoll des Vorfalls durch die Nachverfolgung jeder Änderung an den Feldern „Agent“ oder „Group“ nach der ersten Zuweisung. Erfassen Erkennen Sie Änderungen an den Feldern „Agent“ oder „Group“ in der Audit-Historie des Tickets. Ereignistyp inferred
	Vorfall wiedereröffnet	Dieses Ereignis tritt ein, wenn ein zuvor als „Resolved“ markierter Vorfall wieder in einen offenen Status versetzt wird, typischerweise weil der Benutzer der Lösung nicht zustimmt. Es wird aus einer Statusänderung von „Resolved“ zurück in einen Status wie „Open“ oder „In Progress“ abgeleitet.
Warum das wichtig ist Eine hohe Wiedereröffnungsrate weist auf Probleme bei der Lösungsqualität oder unvollständige Korrekturen hin. Sie ist eine wichtige Kennzahl für die Analyse von Nacharbeit und Agentenleistung. Bezugsquelle Aus dem Aktivitätsprotokoll des Incidents abgeleitet, indem eine Statusänderung von „Resolved“ zu einem aktiven Status erkannt wird. Erfassen Filtern Sie das Aktivitätsprotokoll nach einer Änderung des Felds „Status“ von „Resolved“ zu „Open“ oder „In Progress“. Ereignistyp inferred
	Workaround bereitgestellt	Diese Aktivität zeigt an, dass dem Benutzer eine temporäre Lösung oder ein Workaround mitgeteilt wurde, um die Auswirkungen des Vorfalls zu begrenzen. Für die Erfassung sind häufig bestimmte Systemkonfigurationen erforderlich, etwa ein eigenes Kontrollkästchen, ein bestimmter Notiztyp oder eine Stichwortanalyse in Notizen von Agents.
Warum das wichtig ist Damit lässt sich die Wirksamkeit von Workarounds bei der Reduzierung betrieblicher Auswirkungen und ihr Zusammenhang mit der endgültigen Lösungszeit analysieren. Die Aktivität unterstützt das Dashboard für Workaround-Wirksamkeitskennzahlen. Bezugsquelle Dies ist wahrscheinlich kein ausdrücklich protokolliertes Ereignis. Es kann abgeleitet werden, indem Notizen mit Stichwörtern wie „workaround“ markiert werden oder wenn ein benutzerdefiniertes Feld „Workaround Provided“ verwendet und dessen Änderung protokolliert wird. Erfassen Abgeleitet aus der Änderung eines benutzerdefinierten Felds oder einer Stichwortanalyse der Notizen von Agents. Ereignistyp inferred

Anleitungen zur Extraktion

So exportieren Sie Ihre Daten aus Freshservice

Schritte

Auf Freshservice Analysen zugreifen: Melden Sie sich mit einem Konto, das über Berechtigungen zum Aufrufen und Erstellen von Berichten verfügt, bei Ihrer Freshservice-Instanz an. Öffnen Sie im Hauptmenü das Modul Analysen.
Neuen Bericht erstellen: Klicken Sie auf die Schaltfläche Neuer Bericht. Geben Sie einen aussagekräftigen Namen ein, zum Beispiel „Incident Management Event Log“. Wählen Sie auf Aufforderung zur Auswahl einer Datenquelle das Modul Incident Management.
Berichts-Widget auswählen: Fügen Sie im Berichtseditor ein neues Widget hinzu und wählen Sie den Typ Tabelle. Dieses Widget bildet die Grundlage für die Daten Ihres Event Logs.
Primäre Datenspalten hinzufügen: Ziehen Sie im Datenquellenbereich auf der rechten Seite die erforderlichen Felder in die Spaltenkonfiguration der Tabelle. Beginnen Sie mit Incident-ID, Erstellt am, Agent, Gruppe, Priority, Severity, Status und Category.
Aktivitätsdaten einbeziehen: Um einzelne Ereignisse zu erfassen, müssen Sie Daten aus den Ticketaktivitäten verknüpfen oder einbeziehen. Fügen Sie Ihrem Widget die Datenquelle Activities hinzu. Fügen Sie aus dieser Quelle „Ausgeführt am“ für den Ereignis-Timestamp sowie „Aktivitätsbeschreibung“ oder ähnliche Felder hinzu, die die eingetretene Änderung beschreiben.
Berechnete Spalte „ActivityName“ erstellen: Dies ist der wichtigste Schritt. Erstellen Sie eine neue berechnete Spalte oder ein Formelfeld. Verwenden Sie verschachtelte IF-Anweisungen oder eine CASE-Funktion, um Rohaktivitätsdaten in die erforderlichen ActivityName-Werte zu überführen. Im Abfrageabschnitt finden Sie die detaillierte Logik für jede der 14 Aktivitäten.
„EventTimestamp“ konfigurieren: Erstellen Sie eine weitere berechnete Spalte für EventTimestamp. Die Logik dieser Spalte sollte für die Aktivität „Incident gemeldet“ den Timestamp von „Erstellt am“ und für alle anderen Ereignisse den Timestamp von „Ausgeführt am“ der Aktivität verwenden.
Berichtsfilter anwenden: Konfigurieren Sie die Berichtsfilter, um den Datenumfang einzugrenzen. Legen Sie mindestens einen Datumsbereichsfilter für das Feld „Erstellt am“ fest. Empfohlen wird ein Zeitraum der letzten 3 bis 6 Monate. Fügen Sie außerdem einen Filter hinzu, der nur Tickets mit „Tickettyp“ „Incident“ einschließt.
Bericht ausführen und verfeinern: Führen Sie den Bericht aus, um eine Datenvorschau zu erzeugen. Prüfen Sie die Ausgabe und stellen Sie sicher, dass die Spalten ActivityName und EventTimestamp korrekt befüllt werden. Passen Sie Formeln und Filter bei Bedarf an.
Bericht speichern und exportieren: Speichern Sie den Bericht, sobald Sie mit seiner Ausgabe zufrieden sind. Verwenden Sie die Option Export und wählen Sie CSV als Format.
Export planen (optional): Für laufende Analysen können Sie den Bericht so planen, dass er automatisch ausgeführt und exportiert wird. Richten Sie einen Zeitplan ein, zum Beispiel täglich oder wöchentlich, und lassen Sie die CSV-Datei an Ihre E-Mail-Adresse oder ein anderes Ziel senden.
Daten für den Upload vorbereiten: Öffnen Sie die exportierte CSV-Datei. Benennen Sie die Spaltenüberschriften gemäß dem erforderlichen Schema für ProcessMind um: IncidentId, ActivityName, EventTimestamp, AssignedAgent, AssignedGroup usw. Fügen Sie die statischen Spalten SourceSystem mit dem Wert „Freshservice“ und LastDataUpdate mit dem aktuellen Timestamp hinzu. Die Datei ist nun für den Upload bereit.

Konfiguration

Analytics-Modul: Für diese Extraktion benötigen Sie Zugriff auf das Freshservice-Analytics-Modul, das in höherwertigen Tarifen wie Pro oder Enterprise verfügbar ist.
Erforderliche Berechtigungen: Ihr Benutzerkonto benötigt eine Rolle mit Berechtigungen zum Erstellen, Bearbeiten und Ausführen von Berichten im Analytics-Modul.
Datumsbereich: Setzen Sie unbedingt einen Filter für das Erstellungsdatum der Incidents, um das Datenvolumen zu steuern. Für ein ausgewogenes Verhältnis zwischen historischem Kontext und Leistung empfiehlt sich ein rollierender Zeitraum von drei bis sechs Monaten.
Berichtsfilter: Filtern Sie immer auf Ticket Type gleich Incident, damit Service Requests und andere Tickettypen nicht in die Prozessanalyse einfließen.
Berechnete Felder: Die Methode stützt sich stark auf berechnete Felder und Formeln, um ActivityName und EventTimestamp für jedes Ereignis abzuleiten. Kenntnisse des Freshservice-Formeleditors sind hilfreich.
Datenvolumen: Beachten Sie, dass diese Extraktion für jeden Incident mehrere Zeilen erzeugt, jeweils eine pro Aktivität. Bei großen Freshservice-Instanzen kann die resultierende CSV-Datei sehr umfangreich werden und die Berichtserstellung sowie die Exportgeschwindigkeit beeinträchtigen.

a Beispielabfrage config

// This is a conceptual configuration for the Freshservice Analytics report builder, not an executable script.
// The logic should be implemented using the UI's formula fields and widget settings.

REPORT_WIDGET_TYPE: Table

DATA_SOURCES:
  - Primary: Incidents
  - Additional: Ticket Activities

COLUMNS_AND_DERIVATION_LOGIC:

1.  **IncidentId**
    - Source: Incidents."ID"

2.  **ActivityName** (Calculated Column using a Formula)
    - This formula combines multiple IF conditions to generate the activity name based on the activity type and data changes. The logic below represents a CASE statement structure.
    - **WHEN** Activity Type is 'Created': 'Incident Reported'
    - **WHEN** Activity Field is 'Group' and it is the first update to this field for the ticket: 'Incident Assigned to Group'
    - **WHEN** Activity Field is 'Agent' and it is the first update to this field for the ticket: 'Agent Assigned to Incident'
    - **WHEN** Activity Field is 'Priority': 'Incident Prioritized'
    - **WHEN** Activity Type is 'First Response Sent': 'First Response Sent'
    - **WHEN** Activity Field is 'Group' and it is NOT the first update: 'Incident Reassigned'
    - **WHEN** Activity Field is 'Agent' and it is NOT the first update: 'Incident Reassigned'
    - **WHEN** Activity Field is 'Status' and New Value is 'In Progress': 'Status Changed to In Progress'
    - **WHEN** Activity Field is 'Status' and New Value is 'Pending': 'Status Changed to Pending'
    - **WHEN** Activity Note contains 'Workaround Provided' or a specific workaround tag is added: 'Workaround Provided'
    - **WHEN** Activity Type is 'Resolution Note Added': 'Resolution Note Added'
    - **WHEN** Activity Field is 'Status' and New Value is 'Resolved': 'Incident Resolved'
    - **WHEN** Activity Type is 'SLA Violated' and SLA Type is 'Resolution': 'SLA Target Breached'
    - **WHEN** Activity Field is 'Status' and Old Value was 'Resolved' and New Value is 'Open': 'Incident Reopened'
    - **WHEN** Activity Field is 'Status' and New Value is 'Closed': 'Incident Closed'

3.  **EventTimestamp** (Calculated Column using a Formula)
    - **IF** ActivityName is 'Incident Reported', THEN use Incidents."Created at"
    - **ELSE**, use Ticket Activities."Performed at"

4.  **SourceSystem** (Calculated Column)
    - Value: 'Freshservice'

5.  **LastDataUpdate** (Calculated Column)
    - Value: Use a formula function that returns the current timestamp of the report execution.

6.  **AssignedAgent**
    - Source: Ticket Activities."Performed By" if available, otherwise the current Incidents."Agent"

7.  **AssignedGroup**
    - Source: The value of the 'Group' field at the time of the activity.

8.  **IncidentPriority**
    - Source: The value of the 'Priority' field at the time of the activity.

9.  **IncidentSeverity**
    - Source: The value of the 'Severity' field at the time of the activity.

10. **IncidentStatus**
    - Source: The new value from the 'Status' field change activity.

11. **IncidentCategory**
    - Source: The value of the 'Category' field at the time of the activity.

12. **ResolutionSlaTargetTime**
    - Source: Incidents."Resolution due by"

REPORT_FILTERS:
  - Incidents."Created at" BETWEEN '[Specify Start Date]' AND '[Specify End Date]'
  - Incidents."Type" EQUALS 'Incident'

Schritte

Voraussetzungen: Stellen Sie sicher, dass Python 3.6 oder höher sowie die Bibliotheken requests und pandas installiert sind. Installieren Sie sie bei Bedarf mit pip: pip install requests pandas.
API-Schlüssel erzeugen: Melden Sie sich als Administrator bei Ihrer Freshservice-Instanz an. Öffnen Sie Ihre Profileinstellungen, indem Sie oben rechts auf Ihr Profilbild klicken. Wechseln Sie zum Bereich „API Key“ und kopieren Sie Ihren persönlichen API-Schlüssel. Behandeln Sie diesen Schlüssel wie ein Passwort.
Skript einrichten: Speichern Sie den bereitgestellten Python-Code auf Ihrem lokalen Rechner in einer Datei mit dem Namen extract_freshservice_incidents.py.
Parameter konfigurieren: Öffnen Sie die Skriptdatei in einem Texteditor. Aktualisieren Sie die Platzhalterwerte für FRESHSERVICE_DOMAIN, zum Beispiel „yourcompany.freshservice.com“, API_KEY mit dem soeben kopierten Schlüssel und START_DATE_STR mit dem Beginn des gewünschten Extraktionszeitraums im Format „YYYY-MM-DD“.
Skriptlogik verstehen: Das Skript ruft zunächst alle Incident-Tickets ab, die nach dem angegebenen Startdatum erstellt wurden. Es durchläuft jede von der API zurückgegebene Ergebnisseite. Für jedes Ticket führt es einen zweiten API-Aufruf aus, um den detaillierten Aktivitätsverlauf abzurufen.
Event Log erzeugen: Das Skript verarbeitet die Kerndaten des Tickets und sein Aktivitätsprotokoll, um Datensätze für die 14 erforderlichen Geschäftsaktivitäten zu identifizieren und zu erstellen. Beispielsweise wird „Incident Reported“ aus dem Erstellungsdatum des Tickets erzeugt, während „Status Changed to In Progress“ aus einem bestimmten Eintrag im Aktivitätsprotokoll abgeleitet wird.
Komplexe Ereignisse ableiten: Ereignisse wie „SLA Target Breached“ werden abgeleitet. Das Skript prüft, ob die Lösungs-SLA eines Tickets verletzt wurde. Falls ja, erstellt es ein Ereignis mit dem Fälligkeitsdatum due_by als Timestamp und markiert damit den Zeitpunkt der Verletzung.
Skript ausführen: Öffnen Sie ein Terminal oder eine Eingabeaufforderung, wechseln Sie in das Verzeichnis, in dem Sie das Skript gespeichert haben, und führen Sie es mit folgendem Befehl aus: python extract_freshservice_incidents.py.
Ausführung überwachen: Das Skript gibt im Terminal Fortschrittsmeldungen aus und zeigt, wie viele Tickets verarbeitet wurden. Je nach Ticketanzahl und API-Ratenbegrenzungen kann die Ausführung einige Zeit dauern.
Ergebnis prüfen: Nach Abschluss erzeugt das Skript im selben Verzeichnis eine CSV-Datei mit dem Namen freshservice_incident_event_log.csv. Diese Datei enthält das vollständige Event Log.
Für den Upload vorbereiten: Öffnen Sie die CSV-Datei in einem Tabellenkalkulationsprogramm und prüfen Sie, ob die Spalten IncidentId, ActivityName, EventTimestamp usw. erwartungsgemäß befüllt sind. Die Datei ist nun für den Upload in ProcessMind oder ein anderes Process-Mining-Tool bereit.

Konfiguration

FRESHSERVICE_DOMAIN: Die spezifische Freshservice-URL Ihres Unternehmens, zum Beispiel mycompany.freshservice.com. Dieser Parameter ist im Skript erforderlich.
API_KEY: Der persönliche API-Schlüssel eines Benutzers mit ausreichenden Berechtigungen zum Lesen aller Incident-Daten. Dieser Parameter ist erforderlich.
START_DATE_STR: Das Startdatum für die Datenextraktion im Format „YYYY-MM-DD“. Für eine aussagekräftige Analyse empfiehlt sich zunächst ein Zeitraum von drei bis sechs Monaten.
PAGE_SIZE: Setzen Sie den Wert auf 100, das von der Freshservice-API zugelassene Maximum, um die Anzahl der API-Aufrufe zu reduzieren und die Leistung zu verbessern. Es wird im Allgemeinen nicht empfohlen, diesen Wert zu ändern.
API-Ratenbegrenzung: Das Skript enthält nach der Verarbeitung jedes Tickets einen einfachen Aufruf von time.sleep(1), um die API-Ratenbegrenzungen von Freshservice einzuhalten. Bei Instanzen mit hohem Volumen muss dieser Wert möglicherweise angepasst werden, um Fehler zu vermeiden.
Erforderliche Berechtigungen: Der verwendete API-Schlüssel muss zu einem Benutzerkonto gehören, zum Beispiel einem dedizierten Servicekonto, das mindestens über die Berechtigungen der Rolle „SD Agent“ verfügt. So stellen Sie sicher, dass das Konto auf alle erforderlichen Ticketfelder und Aktivitätsprotokolle in den verschiedenen Service-Desk-Gruppen zugreifen kann.

a Beispielabfrage python

import requests
import pandas as pd
import time
import datetime
import os

class=class="hl-string">"hl-comment"># --- Configuration Settings ---
class=class="hl-string">"hl-comment"># Replace with your Freshservice domain
FRESHSERVICE_DOMAIN = class="hl-string">"[your_domain].freshservice.com"
class=class="hl-string">"hl-comment"># Replace with your Freshservice API Key
API_KEY = class="hl-string">"[your_api_key]"
class=class="hl-string">"hl-comment"># Set the start date for the extraction (YYYY-MM-DD)
START_DATE_STR = class="hl-string">"2023-01-01"

class=class="hl-string">"hl-comment"># --- Constants ---
BASE_URL = fclass="hl-string">"https протокол://{FRESHSERVICE_DOMAIN}/api/v2"
PAGE_SIZE = 100
OUTPUT_FILENAME = class="hl-string">"freshservice_incident_event_log.csv"

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---
def create_event(incident_id, activity_name, event_timestamp, ticket_data, source_system, last_data_update):
    class="hl-string">"""Helper function to create a structured event dictionary."""
    class=class="hl-string">"hl-comment"># Use latest known values for attributes if available
    sla_policy = ticket_data.get(class="hl-string">'sla_policy', {})
    resolution_due = None
    if sla_policy and sla_policy.get(class="hl-string">'resolution_sla', {}):
        resolution_due = sla_policy.get(class="hl-string">'resolution_sla', {}).get(class="hl-string">'due_by')

    return {
        class="hl-string">"IncidentId": incident_id,
        class="hl-string">"ActivityName": activity_name,
        class="hl-string">"EventTimestamp": event_timestamp,
        class="hl-string">"SourceSystem": source_system,
        class="hl-string">"LastDataUpdate": last_data_update,
        class="hl-string">"AssignedAgent": ticket_data.get(class="hl-string">'responder_id'),
        class="hl-string">"AssignedGroup": ticket_data.get(class="hl-string">'group_id'),
        class="hl-string">"IncidentPriority": ticket_data.get(class="hl-string">'priority'),
        class="hl-string">"IncidentSeverity": ticket_data.get(class="hl-string">'impact'), class=class="hl-string">"hl-comment"># Impact is often used for Severity
        class="hl-string">"IncidentStatus": ticket_data.get(class="hl-string">'status'),
        class="hl-string">"IncidentCategory": ticket_data.get(class="hl-string">'category'),
        class="hl-string">"ResolutionSlaTargetTime": resolution_due
    }

def get_all_tickets(session, start_date):
    class="hl-string">"""Fetches all tickets from Freshservice updated since the start date, handling pagination."""
    tickets = []
    page = 1
    while True:
        params = {
            class="hl-string">"updated_since": start_date + class="hl-string">"T00:00:00Z",
            class="hl-string">"per_page": PAGE_SIZE,
            class="hl-string">"page": page,
            class="hl-string">"order_type": class="hl-string">"asc" class=class="hl-string">"hl-comment"># Process tickets in chronological order
        }
        try:
            response = session.get(fclass="hl-string">"{BASE_URL}/tickets", params=params)
            response.raise_for_status()
            data = response.json().get(class="hl-string">"tickets", [])
            if not data:
                break
            tickets.extend(data)
            print(fclass="hl-string">"Fetched page {page}, {len(data)} tickets...")
            page += 1
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching tickets: {e}")
            break
    return tickets

def get_ticket_activities(session, ticket_id):
    class="hl-string">"""Fetches all activities (audit log) for a specific ticket."""
    try:
        response = session.get(fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/activities")
        response.raise_for_status()
        return response.json().get(class="hl-string">"activities", [])
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error fetching activities for ticket {ticket_id}: {e}")
        return []

def main():
    class="hl-string">"""Main function to run the extraction process."""
    session = requests.Session()
    session.auth = (API_KEY, class="hl-string">'X') class=class="hl-string">"hl-comment"># class="hl-string">'X' is a placeholder password
    session.headers.update({class="hl-string">'Content-Type': class="hl-string">'application/json'})

    last_data_update = datetime.datetime.now(datetime.timezone.utc).isoformat()
    source_system = class="hl-string">'Freshservice'
    event_log = []

    print(class="hl-string">"Starting Freshservice incident extraction...")
    all_tickets = get_all_tickets(session, START_DATE_STR)
    print(fclass="hl-string">"Total tickets to process: {len(all_tickets)}")

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

        class=class="hl-string">"hl-comment"># 1. Incident Reported
        event_log.append(create_event(incident_id, class="hl-string">"Incident Reported", ticket[class="hl-string">'created_at'], ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># Fetch detailed activities for more events
        activities = get_ticket_activities(session, incident_id)
        
        assigned_group_done = False
        agent_assigned_done = False
        first_response_done = False

        for activity in sorted(activities, key=lambda x: x[class="hl-string">'performed_at']):
            activity_ts = activity[class="hl-string">'performed_at']
            class=class="hl-string">"hl-comment"># 2. Incident Assigned to Group (first occurrence)
            if not assigned_group_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'group_id' in activity.get(class="hl-string">'changes', {}):
                event_log.append(create_event(incident_id, class="hl-string">"Incident Assigned to Group", activity_ts, ticket, source_system, last_data_update))
                assigned_group_done = True
            
            class=class="hl-string">"hl-comment"># 3. Agent Assigned to Incident (first occurrence)
            if not agent_assigned_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'responder_id' in activity.get(class="hl-string">'changes', {}):
                event_log.append(create_event(incident_id, class="hl-string">"Agent Assigned to Incident", activity_ts, ticket, source_system, last_data_update))
                agent_assigned_done = True

            class=class="hl-string">"hl-comment"># 4. Incident Prioritized
            if activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'priority' in activity.get(class="hl-string">'changes', {}):
                event_log.append(create_event(incident_id, class="hl-string">"Incident Prioritized", activity_ts, ticket, source_system, last_data_update))

            class=class="hl-string">"hl-comment"># 5. First Response Sent (first public note by an agent)
            if not first_response_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Note' and activity.get(class="hl-string">'note', {}).get(class="hl-string">'private') is False and activity.get(class="hl-string">'performer_type') == class="hl-string">'User':
                event_log.append(create_event(incident_id, class="hl-string">"First Response Sent", activity_ts, ticket, source_system, last_data_update))
                first_response_done = True

            class=class="hl-string">"hl-comment"># 6. Incident Reassigned (subsequent assignments)
            if (assigned_group_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'group_id' in activity.get(class="hl-string">'changes', {})) or \
               (agent_assigned_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'responder_id' in activity.get(class="hl-string">'changes', {})):
                event_log.append(create_event(incident_id, class="hl-string">"Incident Reassigned", activity_ts, ticket, source_system, last_data_update))

            class=class="hl-string">"hl-comment"># Status Changes
            if activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'status' in activity.get(class="hl-string">'changes', {}):
                new_status = activity[class="hl-string">'changes'][class="hl-string">'status'][1]
                class=class="hl-string">"hl-comment"># 7. Status Changed to In Progress
                if new_status == 3: class=class="hl-string">"hl-comment"># Assuming 3 is class="hl-string">'In Progress'
                    event_log.append(create_event(incident_id, class="hl-string">"Status Changed to In Progress", activity_ts, ticket, source_system, last_data_update))
                class=class="hl-string">"hl-comment"># 8. Status Changed to Pending
                elif new_status == 6: class=class="hl-string">"hl-comment"># Assuming 6 is class="hl-string">'Pending'
                    event_log.append(create_event(incident_id, class="hl-string">"Status Changed to Pending", activity_ts, ticket, source_system, last_data_update))

            class=class="hl-string">"hl-comment"># 9. Workaround Provided (Keyword search in notes)
            if activity[class="hl-string">'activity_type'] == class="hl-string">'Note' and class="hl-string">'workaround' in activity.get(class="hl-string">'note', {}).get(class="hl-string">'body_text', class="hl-string">'').lower():
                event_log.append(create_event(incident_id, class="hl-string">"Workaround Provided", activity_ts, ticket, source_system, last_data_update))
            
            class=class="hl-string">"hl-comment"># 10. Resolution Note Added
            if activity[class="hl-string">'activity_type'] == class="hl-string">'Note' and activity.get(class="hl-string">'note', {}).get(class="hl-string">'note_type') == class="hl-string">'resolution':
                event_log.append(create_event(incident_id, class="hl-string">"Resolution Note Added", activity_ts, ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># 11. Incident Resolved
        if ticket.get(class="hl-string">'resolved_at'):
            event_log.append(create_event(incident_id, class="hl-string">"Incident Resolved", ticket[class="hl-string">'resolved_at'], ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># 12. SLA Target Breached
        if ticket.get(class="hl-string">'sla_policy') and ticket[class="hl-string">'sla_policy'].get(class="hl-string">'violation_details', {}).get(class="hl-string">'resolution_sla', {}).get(class="hl-string">'is_violated'):
            breach_time = ticket[class="hl-string">'sla_policy'][class="hl-string">'violation_details'][class="hl-string">'resolution_sla'][class="hl-string">'due_by']
            event_log.append(create_event(incident_id, class="hl-string">"SLA Target Breached", breach_time, ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># 13. Incident Reopened
        if ticket.get(class="hl-string">'reopened'):
            class=class="hl-string">"hl-comment"># Finding the exact reopened timestamp can be tricky, we approximate from class="hl-string">'stats'
            reopen_ts = ticket.get(class="hl-string">'stats', {}).get(class="hl-string">'reopened_at', ticket[class="hl-string">'updated_at'])
            event_log.append(create_event(incident_id, class="hl-string">"Incident Reopened", reopen_ts, ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># 14. Incident Closed
        if ticket.get(class="hl-string">'closed_at'):
            event_log.append(create_event(incident_id, class="hl-string">"Incident Closed", ticket[class="hl-string">'closed_at'], ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># Be respectful of API rate limits
        time.sleep(1)

    class=class="hl-string">"hl-comment"># Convert to DataFrame and save
    if event_log:
        df = pd.DataFrame(event_log)
        df[class="hl-string">'EventTimestamp'] = pd.to_datetime(df[class="hl-string">'EventTimestamp'])
        df = df.sort_values(by=[class="hl-string">'IncidentId', class="hl-string">'EventTimestamp'])
        df.to_csv(OUTPUT_FILENAME, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%S.%f%z')
        print(fclass="hl-string">"\nSuccessfully extracted {len(df)} events for {df['IncidentId'].nunique()} incidents.")
        print(fclass="hl-string">"Event log saved to {OUTPUT_FILENAME}")
    else:
        print(class="hl-string">"No events were generated.")

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

Schritte

Prüfen Sie, ob Ihr Freshservice-Tarif und Ihre Administratorberechtigungen Regeln im Workflow Automator, Webhook-Aktionen, den Zugriff auf Incidents sowie den Zugriff auf die Ticket-Aktivitätshistorie erlauben. Stimmen Sie Zielendpunkt, Authentifizierungsmethode, TLS-Anforderungen und Aufbewahrungsrichtlinie mit dem empfangenden Team ab.
Definieren Sie den Ereignisvertrag, bevor Sie den Automator konfigurieren. Verwenden Sie pro Webhook-Übermittlung ein JSON-Objekt mit IncidentId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate, AssignedAgent, AssignedGroup, IncidentPriority, IncidentSeverity, IncidentStatus, IncidentCategory und ResolutionSlaTargetTime. Konfigurieren Sie den Empfänger so, dass der ursprüngliche Webhook-Payload und der Übermittlungs-Timestamp erhalten bleiben.
Erstellen Sie eine Workflow-Automator-Regel für die Erstellung von Incidents. Konfigurieren Sie die Regel so, dass sie bei der Erstellung eines Incidents ausgeführt wird. Fügen Sie anschließend eine Webhook-Aktion hinzu, die die Aktivität Incident Reported übermittelt. Setzen Sie EventTimestamp auf den Erstellungs-Timestamp des Incidents und ActivityName auf Incident Reported.
Erstellen Sie Aktualisierungsregeln für Änderungen an Zuweisung, Priorität, Status, Kommunikation, Notizen, SLA und Abschluss. Konfigurieren Sie die Bedingungen anhand der Incident-Felder und der in Ihrem Freshservice-Konto verfügbaren Aktivitätshistorie. Jede Regel muss bei Auftreten der entsprechenden Aktivität ein separates Webhook-Ereignis senden. Verlassen Sie sich nicht darauf, dass ProcessMind Aktivitäten aus einem abschließenden Incident-Snapshot ableitet.
Konfigurieren Sie eine eindeutige Aktivitätszuordnung. Senden Sie Incident Assigned to Group, wenn das Feld Group erstmals einen Wert erhält, Agent Assigned to Incident, wenn das Feld Agent erstmals einen Wert erhält, Incident Prioritized, wenn Priority gesetzt oder geändert wird, First Response Sent, sobald die erste qualifizierende öffentliche Antwort oder Notiz eines Agents erfasst wird, Incident Reassigned, wenn sich Agent oder Group nach der ersten Zuweisung ändern, Status Changed to In Progress und Status Changed to Pending bei den entsprechenden Statusübergängen, Workaround Provided nur bei vorhandenem konfiguriertem Behelfslösungskennzeichen, Resolution Note Added beim Hinzufügen einer Lösungsnotiz, Incident Resolved beim Wechsel des Status zu Resolved, SLA Target Breached bei erfüllter konfigurierter SLA-Verletzungsbedingung, Incident Reopened beim Wechsel von Resolved zu einem offenen Status und Incident Closed beim Wechsel des Status zu Closed.
Konfigurieren Sie den Webhook-Request-Body als JSON und nehmen Sie die Incident-Kennung, den Aktivitätsnamen, den Event-Timestamp, das Quellsystem, den letzten Datenaktualisierungszeitpunkt sowie die empfohlenen Kontextattribute auf. Verwenden Sie die in Ihrem Konto verfügbaren Freshservice-Webhook-Variablen. Wenn eine erforderliche Variable im Webhook-Editor nicht verfügbar ist, befüllen Sie den Wert im empfangenden Service über eine freigegebene Freshservice-Schnittstelle oder lassen Sie ihn leer, statt einen Wert zu erfinden.
Konfigurieren Sie am Endpunkt Idempotenz und Zustellverarbeitung. Verwenden Sie eine stabile Ereigniskennung, sofern Freshservice eine solche bereitstellt. Andernfalls erstellen Sie einen Deduplizierungsschlüssel aus IncidentId, ActivityName, EventTimestamp und der Kennung der Quellübermittlung. Geben Sie erst dann eine erfolgreiche HTTP-Antwort zurück, wenn der Payload dauerhaft angenommen wurde.
Testen Sie jede Regel mit kontrollierten Incidents. Erstellen Sie einen Incident, weisen Sie Gruppe und Agent zu, ändern Sie Priorität und Status, senden Sie eine qualifizierende Antwort, fügen Sie, sofern konfiguriert, eine Behelfslösung und eine Lösungsnotiz hinzu, lösen Sie den Incident, öffnen Sie ihn erneut und schließen Sie ihn. Testen Sie eine SLA-Verletzung separat mit einer kontrollierten Richtlinie oder Testwarteschlange. Prüfen Sie, ob jede erwartete Aktivität als eigener Webhook-Payload eintrifft.
Speichern Sie die Webhook-Payloads in einem dauerhaften Staging-Bereich, vereinheitlichen Sie die Timestamps auf eine Zeitzone und überführen Sie jeden Payload in eine Zeile des Event Logs. Bewahren Sie pro expliziter Webhook-Aktivität genau eine Zeile auf. Befüllen Sie LastDataUpdate mit dem Aktualisierungszeitpunkt der Extraktion oder Aufnahme, nicht mit dem Timestamp des Geschäftsereignisses.
Validieren Sie das bereitgestellte Event Log, entfernen Sie nur exakt doppelte Übermittlungen und behalten Sie legitime wiederholte Aktivitäten wie mehrere Prioritätsänderungen oder Statusübergänge bei. Stellen Sie sicher, dass IncidentId, ActivityName, EventTimestamp, SourceSystem und LastDataUpdate in jeder Zeile vorhanden sind.
Exportieren Sie das normalisierte Event Log als CSV oder in einem anderen von ProcessMind unterstützten Format. Verwenden Sie exakt die Spaltennamen IncidentId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate, AssignedAgent, AssignedGroup, IncidentPriority, IncidentSeverity, IncidentStatus, IncidentCategory und ResolutionSlaTargetTime. Laden Sie die Datei hoch oder verbinden Sie die vorbereitete Ereignisquelle mit ProcessMind. Ordnen Sie IncidentId als Case-Kennung und ActivityName als Aktivitätsfeld zu.

Konfiguration

Geltungsbereich der Auslöser: Konfigurieren Sie separate Workflow-Automator-Regeln für die Erstellung von Incidents und für jede Aktualisierungsbedingung. Eine einzige breit gefasste Aktualisierungsregel kann doppelte oder mehrdeutige Ereignisse erzeugen, sofern der Empfänger keine strikte Aktivitätszuordnung anwendet.
Webhook-Payload: Nehmen Sie alle erforderlichen Attribute in jeden Payload auf. Ergänzen Sie empfohlene Attribute, sofern sie zum Ereigniszeitpunkt verfügbar sind. Bewahren Sie den Roh-Payload für Audits und eine erneute Verarbeitung auf.
Bedeutung der Aktivitäten: Unterscheiden Sie die erstmalige Zuweisung von Gruppe und Agent von späteren Änderungen. Spätere Änderungen erzeugen Incident Reassigned, während die erstmalige Befüllung die entsprechende anfängliche Zuweisungsaktivität erzeugt.
Statusverarbeitung: Ordnen Sie die exakten Statuswerte zu, die im Freshservice-Konto konfiguriert sind. Wenn das Konto benutzerdefinierte Status für „Pending“ oder „Open“ verwendet, richten Sie für diese Werte explizite Zuordnungen ein.
Erste Antwort: Definieren Sie, ob eine öffentliche Antwort, eine öffentliche Notiz oder ein anderer Kommunikationstyp als qualifizierend gilt. Wenden Sie diese Definition einheitlich an und erzeugen Sie das Ereignis nur für die erste qualifizierende Kommunikation pro Incident.
Erkennung von Behelfslösungen: Konfigurieren Sie ein eigenes Feld, Kontrollkästchen, einen Notiztyp oder eine freigegebene Schlüsselwortregel. Ohne eine solche Konfiguration lässt sich Workaround Provided nicht zuverlässig identifizieren.
SLA-Verletzung: Konfigurieren Sie einen expliziten Auslöser für SLA-Verletzungen oder einen separaten geplanten Prozess, der die aktuelle Zeit mit ResolutionSlaTargetTime vergleicht. Ein abschließender Incident-Snapshot reicht nicht aus, um den Timestamp der Verletzung zu rekonstruieren.
Datumsbereich: Verwenden Sie für die erste Validierung Incidents aus einem Zeitraum von etwa drei bis sechs Monaten. Beginnen Sie für den Echtzeitbetrieb mit der Aufnahme vor dem gewünschten Analysezeitraum und bewahren Sie die Webhook-Historie für eine erneute Verarbeitung auf.
Filter: Wenden Sie nur freigegebene Filter für Unternehmen, Arbeitsbereiche, Abteilungen, Services, Kategorien oder Datumsbereiche an. Gehen Sie nicht von Freshservice-Feldnamen oder einer Filtersyntax aus, die in der Kontokonfiguration nicht verfügbar sind.
Leistung: Verarbeiten Sie Webhooks asynchron, stellen Sie eingehende Anfragen in eine Warteschlange, bündeln Sie nachgelagerte Schreibvorgänge und indexieren Sie IncidentId sowie EventTimestamp. Vermeiden Sie synchrone Anreicherungsaufrufe während des Webhook-Empfangs.
Zuverlässigkeit: Konfigurieren Sie Wiederholungsversuche, Dead-Letter-Verarbeitung, Überwachung und Unterdrückung von Duplikaten. Protokollieren Sie fehlgeschlagene Übermittlungen und verarbeiten Sie sie nach der Fehlerbehebung erneut.
Voraussetzungen: Administratorzugriff, Verfügbarkeit des Workflow Automator, Webhook-Berechtigungen, ein HTTPS-Endpunkt, eine konfigurierte Authentifizierung, ausreichende Funktionen des Freshservice-Tarifs sowie ein mit ProcessMind kompatibler Ablage- oder Upload-Prozess.
Sicherheit: Verwenden Sie HTTPS, beschränken Sie den eingehenden Zugriff nach Möglichkeit, wechseln Sie Zugangsdaten regelmäßig, minimieren Sie sensible Felder und schützen Sie Incident-Beschreibungen sowie Notizen, sofern diese in den Payloads enthalten sind.

a Beispielabfrage config

const REQUIRED_ACTIVITIES = [
  "Incident Reported",
  "Incident Assigned to Group",
  "Agent Assigned to Incident",
  "Incident Prioritized",
  "First Response Sent",
  "Incident Reassigned",
  "Status Changed to In Progress",
  "Status Changed to Pending",
  "Workaround Provided",
  "Resolution Note Added",
  "Incident Resolved",
  "SLA Target Breached",
  "Incident Reopened",
  "Incident Closed"
];

const REQUIRED_COLUMNS = [
  "IncidentId",
  "ActivityName",
  "EventTimestamp",
  "SourceSystem",
  "LastDataUpdate",
  "AssignedAgent",
  "AssignedGroup",
  "IncidentPriority",
  "IncidentSeverity",
  "IncidentStatus",
  "IncidentCategory",
  "ResolutionSlaTargetTime"
];

function normalizeTimestamp(value) {
  if (value === null || value === undefined || value === "") {
    return null;
  }
  const date = new Date(value);
  if (Number.isNaN(date.getTime())) {
    throw new Error("Invalid timestamp: " + String(value));
  }
  return date.toISOString();
}

function textOrNull(value) {
  if (value === null || value === undefined || value === "") {
    return null;
  }
  return String(value);
}

function getField(payload, names) {
  for (const name of names) {
    if (payload[name] !== undefined && payload[name] !== null) {
      return payload[name];
    }
  }
  return null;
}

function normalizeWebhookPayload(payload, receivedAt) {
  const incidentId = getField(payload, ["IncidentId", "incident_id", "ticket_id", "id"]);
  const activityName = getField(payload, ["ActivityName", "activity_name"]);
  const eventTimestamp = getField(payload, ["EventTimestamp", "event_timestamp", "timestamp", "created_at", "updated_at"]);

  if (incidentId === null || incidentId === "") {
    throw new Error("IncidentId is required");
  }
  if (activityName === null || activityName === "") {
    throw new Error("ActivityName is required");
  }
  if (!REQUIRED_ACTIVITIES.includes(String(activityName))) {
    throw new Error("Unsupported ActivityName: " + String(activityName));
  }
  if (eventTimestamp === null || eventTimestamp === "") {
    throw new Error("EventTimestamp is required");
  }

  const row = {
    IncidentId: textOrNull(incidentId),
    ActivityName: textOrNull(activityName),
    EventTimestamp: normalizeTimestamp(eventTimestamp),
    SourceSystem: textOrNull(getField(payload, ["SourceSystem", "source_system"])) || "Freshservice",
    LastDataUpdate: normalizeTimestamp(getField(payload, ["LastDataUpdate", "last_data_update"])) || normalizeTimestamp(receivedAt),
    AssignedAgent: textOrNull(getField(payload, ["AssignedAgent", "assigned_agent", "agent"])),
    AssignedGroup: textOrNull(getField(payload, ["AssignedGroup", "assigned_group", "group"])),
    IncidentPriority: textOrNull(getField(payload, ["IncidentPriority", "incident_priority", "priority"])),
    IncidentSeverity: textOrNull(getField(payload, ["IncidentSeverity", "incident_severity", "severity"])),
    IncidentStatus: textOrNull(getField(payload, ["IncidentStatus", "incident_status", "status"])),
    IncidentCategory: textOrNull(getField(payload, ["IncidentCategory", "incident_category", "category"])),
    ResolutionSlaTargetTime: normalizeTimestamp(getField(payload, ["ResolutionSlaTargetTime", "resolution_sla_target_time"]))
  };

  for (const column of REQUIRED_COLUMNS) {
    if (!(column in row)) {
      throw new Error("Missing output column: " + column);
    }
  }
  return row;
}

function deduplicateRows(rows) {
  const seen = new Set();
  return rows.filter((row) => {
    const key = [
      row.IncidentId,
      row.ActivityName,
      row.EventTimestamp,
      row.SourceSystem
    ].join("|");
    if (seen.has(key)) {
      return false;
    }
    seen.add(key);
    return true;
  });
}

async function processWebhookBatch(webhookPayloads, receivedAt) {
  const rows = webhookPayloads.map((payload) => normalizeWebhookPayload(payload, receivedAt));
  const deduplicatedRows = deduplicateRows(rows);
  deduplicatedRows.sort((left, right) => {
    if (left.IncidentId !== right.IncidentId) {
      return left.IncidentId.localeCompare(right.IncidentId);
    }
    return left.EventTimestamp.localeCompare(right.EventTimestamp);
  });
  return deduplicatedRows;
}

module.exports = {
  REQUIRED_ACTIVITIES,
  REQUIRED_COLUMNS,
  normalizeWebhookPayload,
  deduplicateRows,
  processWebhookBatch
};

Möchten Sie jetzt starten?

Verwenden Sie dieses Template, um Ihre Daten korrekt einzurichten und wertvolle Erkenntnisse zu Ihren Incident-Management-Workflows zu gewinnen. Beginnen Sie noch heute damit, Ihre Lösungszeiten zu verkürzen.

Zurück zum Leitfaden zur Verbesserung Template herunterladen

Verhindern Sie SLA-Verletzungen: Optimieren Sie Ihr Incident Management noch heute

Schließen Sie sich Unternehmen an, die ihre MTTR um 35 % senken und kostspielige SLA-Verletzungen vermeiden.

Starten Sie Ihre kostenlose Testphase

Kostenlose 14-tägige Testphase, keine Kreditkarte erforderlich.

Ihr Daten-Template für Incident Management

Ihr Daten-Template für Incident Management

Attribute des Incident Managements

Aktivitäten des Incident Managements

Anleitungen zur Extraktion

Datenexport des Freshservice-Analytics-Moduls als CSV

Schritte

Konfiguration

a Beispielabfrage config

Extraktion per Python-Skript über die Freshservice-REST-API

Schritte

Konfiguration

a Beispielabfrage python

Echtzeit-Datenübertragung über Webhooks des Workflow Automator

Schritte

Konfiguration

a Beispielabfrage config

Möchten Sie jetzt starten?

Verhindern Sie SLA-Verletzungen: Optimieren Sie Ihr Incident Management noch heute

Ihr Daten-Template für Incident Management

Ihr Daten-Template für Incident Management

Attribute des Incident Managements

Aktivitäten des Incident Managements

Anleitungen zur Extraktion

Datenexport des Freshservice-Analytics-Moduls als CSV

Schritte

Konfiguration

a Beispielabfrage config

Extraktion per Python-Skript über die Freshservice-REST-API

Schritte

Konfiguration

a Beispielabfrage python

Echtzeit-Datenübertragung über Webhooks des Workflow Automator

Schritte

Konfiguration

a Beispielabfrage config

Möchten Sie jetzt starten?

Verhindern Sie SLA-Verletzungen: Optimieren Sie Ihr Incident Management noch heute

Ihre Privatsphäre ist uns wichtig