> Kontinuierliche Prozessverbesserung > Incident Management > Freshservice > Daten Template

Ihr Daten-Template für Incident Management

Freshservice

← Zurück zum Leitfaden zur Prozessverbesserung

Attribute für Incident Management(19) Aktivitäten im Incident Management(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 Aktivitäten und enthält praktische Hinweise zum Extrahieren dieser Informationen aus Ihrem Quellsystem. Verwenden Sie diese Ressource, um die Datenaufbereitung zu vereinfachen.

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

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

Template herunterladen

Attribute für Incident Management

Diese Datenfelder sollten Sie in Ihr Event Log aufnehmen, um Ihren Incident-Management-Prozess umfassend zu analysieren.

5 Erforderlich 7 Empfohlen 7 Optional

	Name	Beschreibung
	Incident-ID IncidentId	Die eindeutige Kennung jedes Incident-Datensatzes. Sie dient als Primärschlüssel, um den gesamten Lebenszyklus des Incidents nachzuverfolgen.
Beschreibung Die Incident-ID ist die Grundlage für die Analyse des Incident-Managements. Sie dient als Case-ID und verknüpft alle zugehörigen Aktivitäten, Timestamps und Attributänderungen zu einem zusammenhängenden Ablauf. Beim Process Mining ist jeder Eintrag im Event Log einer Incident-ID zugeordnet. So lässt sich der durchgängige Prozessablauf für jeden Incident rekonstruieren. Das ist wichtig, um Zykluszeiten zu berechnen, Prozessvarianten zu analysieren und Engpässe in einzelnen Cases zu erkennen. Ohne eine eindeutige Kennung ließen sich verschiedene Incidents nicht voneinander unterscheiden und ihre Abläufe von der Meldung bis zur Lösung nicht analysieren. Warum das wichtig ist Die Kennung identifiziert jeden Incident eindeutig und ermöglicht es, seinen Lebenszyklus von der Erstellung bis zum Abschluss durchgängig nachzuverfolgen und zu analysieren. Woher beziehen Dies ist die primäre Kennung eines Tickets. Sie ist in der Freshservice Tickets API als Feld 'id' im Ticketobjekt verfügbar. Beispiele INC-10234INC-10235INC-10236
	Aktivitätsname ActivityName	Der Name der konkreten geschäftlichen Aktivität oder des Ereignisses, das zu einem bestimmten Zeitpunkt im Lebenszyklus des Incidents stattgefunden hat.
Beschreibung Der Aktivitätsname bezeichnet einen einzelnen Schritt oder ein Ereignis im Incident-Management-Prozess, zum Beispiel 'Incident Assigned to Group', 'Status Changed to Pending' oder 'Incident Resolved'. Diese Aktivitäten werden aus Änderungen der Incident-Daten im Zeitverlauf abgeleitet. Dieses Attribut ist eine wichtige Grundlage für Process Mining, da es die Knoten in der ermittelten Prozessübersicht definiert. Durch die Analyse der Abfolge und Häufigkeit dieser Aktivitäten können Unternehmen den tatsächlichen Ablauf der Incident-Lösung visualisieren, häufige Pfade erkennen, Abweichungen von der Standardvorgehensweise aufdecken und Schleifen mit 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 der Incident-Lösung, von Engpässen und Abweichungen. Woher beziehen Dieses Attribut ist kein direktes Feld in Freshservice. Es wird aus Änderungen an Ticket-Eigenschaften wie Status, Priorität, Zuweisung an Mitarbeitende oder Gruppen sowie dem Hinzufügen von Notizen abgeleitet. Beispiele Incident gemeldetIncident einer Gruppe zugewiesenLösungsnotiz hinzugefügtIncident gelöst
	Ereignis-Timestamp EventTimestamp	Das genaue Datum und die Uhrzeit, zu der die Aktivität oder das Ereignis stattgefunden hat.
Beschreibung Der Ereignis-Timestamp, auch Startzeit, gibt den genauen Zeitpunkt einer Aktivität an. Jede Aktivität im Lebenszyklus eines Incidents, von der Erstellung bis zum Abschluss, hat einen zugehörigen Timestamp. Dieses Attribut ist für alle zeitbasierten Process-Mining-Analysen entscheidend. Es dient dazu, Ereignisse chronologisch zu ordnen, die Dauer zwischen Aktivitäten zu berechnen, die Zykluszeit eines Cases zu messen und Wartezeiten zu analysieren. Außerdem bildet es die Grundlage für Dashboards, mit denen sich SLA-Leistung, Verzögerungen bei Übergaben und die Gesamtdauer bis zur Lösung verfolgen lassen. Warum das wichtig ist Es gibt die chronologische Reihenfolge der Ereignisse an. Diese ist wichtig, um Zeitspannen und Zykluszeiten zu berechnen und die Prozessleistung zu verstehen. Woher beziehen Wird aus verschiedenen Timestamp-Feldern in Freshservice abgeleitet, etwa 'created_at' und 'updated_at' sowie aus Timestamps in der Ticketkonversation oder den Audit-Protokollen. 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 für den gesamten Datensatz, nicht für einzelne Ereignisse. Aus Gründen der Einheitlichkeit wird es jedoch häufig auf Ereignisebene mitgeführt. Für die Analyse ist diese Information wichtig, um die Aktualität der Daten und den von Dashboards und Kennzahlen abgedeckten Zeitraum zu verstehen. Sie zeigt Benutzern, wie aktuell die Erkenntnisse sind, und macht deutlich, ob die neuesten Incidents bereits in der Analyse enthalten sind. Warum das wichtig ist Es informiert Benutzer über die Aktualität der Daten und zeigt, welchen Zeitraum die Analyse abdeckt. Woher beziehen Dies ist ein Metadaten-Timestamp, der während der Datenextraktion (ETL) erzeugt wird. 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 gibt die Herkunft der Daten an. In diesem Zusammenhang lautet der Wert stets 'Freshservice'. Es ist jedoch ein wichtiges Feld, wenn Daten aus mehreren Systemen für eine umfassende Prozesssicht zusammengeführt werden. Das Attribut Quellsystem aufzunehmen, ist eine bewährte Vorgehensweise für Data Governance und Rückverfolgbarkeit. So bleibt die Herkunft der Daten nachvollziehbar, was für Validierung und Fehlerbehebung wichtig ist. Außerdem erleichtert es, das Process-Mining-Projekt später auf weitere Service-Management- oder Betriebssysteme auszuweiten. Warum das wichtig ist Es unterstützt die Rückverfolgbarkeit und Data Governance, indem es die Herkunft der Incident-Management-Daten eindeutig angibt. Woher beziehen In der Regel handelt es sich um einen statischen Wert, der während der Datentransformation (ETL) hinzugefügt wird, um den Datensatz zu kennzeichnen. Beispiele FreshserviceFreshservice-EUFreshservice-PROD
	Incident-Kategorie IncidentCategory	Die Kategorie zur Klassifizierung des Incidents, zum Beispiel Hardware, Software oder Netzwerk.
Beschreibung Die Incident-Kategorie dient dazu, Incidents nach der Art des gemeldeten Problems zu klassifizieren. Diese hierarchische Einteilung hilft dabei, den Incident an das richtige Team weiterzuleiten, und ist wichtig für die Trendanalyse. Dieses Attribut wird im Dashboard 'Incident Categorization Accuracy' verwendet, um zu untersuchen, ob eine anfänglich falsche Kategorisierung durch Neuzuweisungen zu längeren Lösungszeiten führt. Durch die Gruppierung nach Kategorien können Unternehmen wiederkehrende Probleme erkennen, feststellen, wofür der größte Teil des Support-Aufwands anfällt, und passende Verbesserungsmaßnahmen planen. Warum das wichtig ist Es ermöglicht die Analyse von Incident-Trends und hilft festzustellen, ob eine falsche Kategorisierung die Lösung verzögert. Woher beziehen Dies ist ein Standardfeld in Freshservice, das angepasst werden kann. In der Tickets API ist es als 'category' verfügbar, zusammen mit den Feldern 'sub_category' und 'item_category'. Beispiele HardwareSoftwareNetzwerkproblemKontozugriff
	Incident-Priorität IncidentPriority	Die Prioritätsstufe des Incidents. Sie bestimmt, wie dringend die Reaktion und Lösung erfolgen müssen.
Beschreibung Die Incident-Priorität gibt vor, wie schnell und mit welchem Schwerpunkt ein Incident bearbeitet werden muss. Üblicherweise wird sie auf einer Skala wie Niedrig, Mittel, Hoch und Dringend festgelegt und bestimmt häufig die SLA-Ziele. Beim Process Mining ist die Priorität eine wichtige Dimension für Filter und Analysen. So lassen sich die Abläufe zur Lösung von Incidents mit hoher und niedriger Priorität vergleichen und prüfen, ob kritische Probleme effizient bearbeitet werden. Dashboards schlüsseln Kennzahlen wie Zykluszeit und SLA-Einhaltung häufig nach Priorität auf, damit Support-Verantwortliche konkrete Maßnahmen ableiten können. Warum das wichtig ist Sie hilft, die Analyse auf besonders kritische Incidents auszurichten, und ist wichtig für die Bewertung der SLA-Leistung und die Ressourcenplanung. Woher beziehen In der Freshservice Tickets API als Feld 'priority' verfügbar. Die Werte sind numerisch, zum Beispiel 1 für Niedrig und 4 für Dringend. Beispiele NiedrigMittelHochDringend
	Incident-Status IncidentStatus	Der aktuelle Status des Incidents in seinem Lebenszyklus, zum Beispiel Open, Pending, Resolved oder Closed.
Beschreibung Der Incident-Status gibt den aktuellen Zustand des Incidents an. Statusänderungen sind wichtige Ereignisse, auf denen die ermittelte Prozessübersicht beruht, etwa der Wechsel von 'In Progress' zu 'Pending' oder von 'Resolved' zu 'Closed'. Dieses Attribut ist grundlegend, um den Ablauf eines Incidents nachzuvollziehen. Die Analyse der Verweildauer in den einzelnen Status zeigt Engpässe auf, zum Beispiel Incidents, die zu lange auf eine Rückmeldung des Benutzers warten und deshalb im Status 'Pending' bleiben. Das Attribut ist außerdem wichtig, um Start- und Endpunkte für die Berechnung der Zykluszeit festzulegen. Warum das wichtig ist Es zeigt den Fortschritt des Incidents im Lebenszyklus und hilft, Phasen mit häufigen Verzögerungen zu erkennen. Woher beziehen In der Freshservice Tickets API als Feld 'status' verfügbar. Die Werte sind numerisch. Beispiele OpenIn ProgressPendingResolvedClosed
	Schweregrad des Incidents IncidentSeverity	Der Schweregrad des Incidents gibt dessen Auswirkungen auf das Geschäft an.
Beschreibung Der Schweregrad des Incidents misst dessen Auswirkungen auf das Geschäft. Übliche Kategorien sind Niedrig, Mittel, Hoch und Kritisch. Der Schweregrad hängt mit der Priorität zusammen, beschreibt jedoch die Auswirkungen, während die Priorität die Dringlichkeit angibt. Zusammen mit der Auswirkung bestimmt der Schweregrad 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 sie dazu, Lösungszeiten und SLA-Leistung aufzuschlüsseln. So erhalten Incidents mit den größten Auswirkungen während ihres gesamten Lebenszyklus die angemessene Aufmerksamkeit und die nötigen Ressourcen. Warum das wichtig ist Es misst die geschäftlichen Auswirkungen eines Incidents und ermöglicht Analysen, die sich auf die schwerwiegendsten Probleme konzentrieren. Woher beziehen Dies ist ein Standardfeld in Freshservice, das über die Tickets API als 'impact' verfügbar ist. Die Werte sind numerisch. Beispiele NiedrigMittelHoch
	SLA-Zielzeit für die Lösung ResolutionSlaTargetTime	Der Timestamp, bis zu dem der Incident gemäß der SLA-Richtlinie gelöst werden soll.
Beschreibung Dieses Attribut speichert das genaue Datum und die Uhrzeit, bis zu denen ein Incident gelöst werden soll. Die Frist ergibt sich aus der für das Ticket geltenden Service-Level-Agreement-Richtlinie (SLA) und hängt in der Regel von Faktoren wie der Priorität ab. Diese Zielzeit ist wichtig, um die KPI 'SLA Adherence Rate' zu berechnen und das Dashboard 'SLA Performance Dashboard' zu erstellen. Durch den Vergleich des tatsächlichen Lösungs-Timestamps mit dem Ziel lässt sich feststellen, ob ein Incident rechtzeitig gelöst oder das SLA-Ziel überschritten wurde. Das ist eine wesentliche Grundlage für die Messung der Einhaltung vereinbarter Service-Level. Warum das wichtig ist Es gibt die Frist für die Lösung an. Diese wird benötigt, um die SLA-Einhaltung zu berechnen und gefährdete Incidents zu erkennen. Woher beziehen In der Freshservice Tickets API als Felder 'fr_due_by' (erste Reaktion) und 'due_by' (Lösung) verfügbar. Beispiele 2023-10-26T14:00:00Z2023-10-27T09:00:00Z2023-11-05T17:00:00Z
	Zugewiesene Gruppe AssignedGroup	Die Supportgruppe oder das Team, das derzeit 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 dieses Attributs weisen auf eine Eskalation oder Übergabe zwischen verschiedenen Fachbereichen hin. Die Analyse der zugewiesenen Gruppe ist wichtig, um Verzögerungen bei Übergaben und Weiterleitungen zu verstehen. Process Mining kann den Ablauf von Incidents zwischen Gruppen visualisieren, häufige Eskalationspfade aufzeigen und die Wartezeit messen, bis eine Gruppe tätig wird. So lassen sich organisatorische Engpässe und Möglichkeiten zur Verbesserung der Zusammenarbeit zwischen Teams erkennen. Warum das wichtig ist Es zeigt, welches Team zuständig ist. Das ist wichtig, um Übergaben, Eskalationen und Verzögerungen zwischen Teams zu analysieren. Woher beziehen In der Freshservice Tickets API als Feld 'group_id' verfügbar. Über einen Abgleich mit der Groups API lässt sich anhand dieser ID der Gruppenname ermitteln. Beispiele Service DeskNetzwerkbetriebInfrastruktur-Support
	Zugewiesener Mitarbeitender AssignedAgent	Der Name oder die ID des Support-Mitarbeitenden, der derzeit für die Lösung des Incidents zuständig ist.
Beschreibung Der zugewiesene Mitarbeitende bezeichnet die Person im Service Desk, die zu einem bestimmten Zeitpunkt für den Incident verantwortlich ist. Änderungen dieses Attributs zeigen eine Übergabe der Zuständigkeit zwischen Mitarbeitenden an. Dieses Attribut ist wichtig für die Leistungsanalyse. Damit lassen sich Dashboards erstellen, die die Arbeitslast der Mitarbeitenden, die durchschnittliche Lösungszeit pro Person und die Erstlösungsquote verfolgen. Es dient auch dazu, Übergaben zwischen Mitarbeitenden zu analysieren, die Verzögerungen verursachen können. Anhand der Zuweisungen können Führungskräfte Schulungsbedarf erkennen und leistungsstarke Teammitglieder würdigen. Warum das wichtig ist Es ermöglicht die Analyse der Leistung und Arbeitslast der Mitarbeitenden sowie der Auswirkungen von Übergaben auf die Lösungszeiten. Woher beziehen In der Freshservice Tickets API als Feld 'responder_id' verfügbar. Über einen Abgleich mit der Agents API lässt sich anhand dieser ID der Name des Mitarbeitenden ermitteln. Beispiele John DoeJane SmithSupportBot
	Abteilung der anfragenden Person RequestersDepartment	Die Abteilung, der der Benutzer angehört, der den Incident gemeldet hat.
Beschreibung Dieses Attribut gibt die Fachabteilung der anfragenden Person an, zum Beispiel 'Vertrieb', 'Finanzen' oder 'IT'. Die Information stammt in der Regel aus dem Benutzerprofil in Freshservice. Die Analyse nach Abteilung kann zeigen, ob bestimmte Geschäftseinheiten überproportional von Problemen betroffen sind oder ob es abteilungsspezifische Schwierigkeiten gibt. Sie liefert wichtigen Kontext zu den geschäftlichen Auswirkungen von Incidents und hilft, Fehlerbehebungen 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 deren Auswirkungen auf bestimmte Abteilungen. Woher beziehen Diese Information ist mit der anfragenden Person des Tickets verknüpft. Sie lässt sich über den Endpunkt 'Requesters' API abrufen, indem Sie die 'requester_id' des Tickets verwenden und anschließend 'department_id' und den Namen auslesen. Beispiele VertriebMarketingFinanzenPersonalwesen
	Anzahl der Übergaben HandoffCount	Wie oft ein Incident zwischen verschiedenen Mitarbeitenden oder Gruppen übertragen wurde.
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 den Zähler. Eine hohe Zahl an Übergaben weist häufig auf ineffiziente Abläufe, eine falsche Erstzuweisung oder fehlendes Fachwissen hin. Diese Kennzahl fließt direkt in die KPI 'Incident Handoff Count' und das Dashboard 'Handoff And Transfer Delay Analysis' ein. So lassen sich Incidents und Prozesspfade mit übermäßig vielen Übergaben erkennen, die zu Verzögerungen führen. Warum das wichtig ist Sie erfasst Nacharbeit und Neuzuweisungen und hilft, Ineffizienzen durch falsche Weiterleitung oder Wissenslücken zu erkennen. Woher beziehen Diese berechnete Kennzahl ergibt sich aus der Anzahl unterschiedlicher Werte oder Änderungen in den Feldern 'AssignedAgent' oder 'AssignedGroup' während des Lebenszyklus eines einzelnen Incidents. Beispiele 0125
	Erneut geöffnet? IsReopened	Ein berechnetes Kennzeichen, das den Wert 'true' hat, wenn ein Incident nach seiner Lösung oder seinem Abschluss erneut geöffnet wurde.
Beschreibung Dieses boolesche Attribut ist ein berechnetes Kennzeichen für erneut geöffnete Incidents. Es erhält den Wert 'true', wenn sich der Status eines Incidents nach 'Resolved' oder 'Closed' wieder in einen offenen oder laufenden Status ändert. Dieses Kennzeichen ist wichtig für die Berechnung der KPI 'Incident Reopening Rate' und für das Dashboard 'Recurring Incidents'. Eine hohe Wiedereröffnungsrate kann auf eine mangelhafte Erstlösung, eine unvollständige Ursachenanalyse oder einen verfrühten Abschluss hinweisen. Die Analyse dieser Fälle hilft, die Qualität und Dauerhaftigkeit von Fehlerbehebungen zu verbessern. Warum das wichtig ist Es macht Fehler im Lösungsprozess sichtbar und zeigt Incidents, bei denen die erste Fehlerbehebung nicht wirksam war und Nacharbeit erforderlich wurde. Woher beziehen Dieses berechnete Feld wird aus der Abfolge der Aktivitäten im Event Log abgeleitet. Es hat den Wert 'true', wenn ein Ereignis wie 'Incident Reopened' auftritt oder bei derselben Incident-ID nach einem abgeschlossenen Status ein offener Status folgt. Beispiele truefalse
	Meldekanal ReportingChannel	Die Methode oder der Kanal, über den der Incident gemeldet wurde, zum Beispiel per E-Mail, Portal oder Telefon.
Beschreibung Der Meldekanal, auch Quelle genannt, gibt an, über welchen Weg ein Incident in das Supportsystem gelangt ist. Übliche Kanäle sind E-Mail, ein Self-Service-Portal, Telefon oder Chat. Die Analyse dieses Attributs hilft, die Effizienz der verschiedenen Meldekanäle zu bewerten. Das Dashboard 'Reporting Channel Efficiency' vergleicht das Incident-Aufkommen und die durchschnittliche Lösungszeit nach Kanal. So lässt sich feststellen, welche Wege am effektivsten sind und wo Verbesserungen am Prozess nötig sein könnten. Über das Portal gemeldete Incidents lassen sich beispielsweise möglicherweise schneller lösen, wenn von Anfang an strukturierte Informationen vorliegen. Warum das wichtig ist Es hilft, effiziente Meldekanäle zu erkennen und Möglichkeiten zur Verbesserung der Incident-Erfassung aufzudecken. Woher beziehen In der Freshservice Tickets API als Feld 'source' verfügbar. Die Werte sind numerisch. Beispiele E-MailPortalTelefonChat
	SLA-Ziel überschritten? 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, die angibt, ob die Lösungszeit eines Incidents das SLA-Ziel überschritten hat. Sie wird ermittelt, indem der tatsächliche Lösungs-Timestamp mit 'ResolutionSlaTargetTime' verglichen wird. Dieses Kennzeichen fließt direkt in die KPI 'SLA Adherence Rate' und das Dashboard 'SLA Performance Dashboard' ein. Es vereinfacht die Analyse, indem es für jeden Incident ein eindeutiges Ja-Nein-Ergebnis zur SLA-Leistung liefert. Dadurch lassen sich die Ergebnisse einfach zusammenfassen und Trends analysieren. Außerdem können Sie schnell erkennen, wie viele Incidents ihre Service-Zusagen nicht erfüllen und welchen Anteil sie ausmachen. Warum das wichtig ist Es misst die SLA-Einhaltung für jeden Incident direkt. So lassen sich die Gesamteinhaltungsquote berechnen und Problembereiche erkennen. Woher beziehen Dies ist ein berechnetes Feld, das während der Datentransformation ermittelt wird, indem der Timestamp 'Incident Resolved' mit dem Feld 'ResolutionSlaTargetTime' verglichen wird. Beispiele truefalse
	Ursache RootCause	Der zugrunde liegende Grund oder die Ursache, die nach der Untersuchung für den Incident ermittelt wurde.
Beschreibung Das Attribut Ursache erfasst das grundlegende Problem, das zum Incident geführt hat. Support-Mitarbeitende tragen diese Information in der Regel während oder nach der Lösung im Rahmen einer Ursachenanalyse (RCA) ein. Dieses Attribut ist wichtig für das Dashboard 'Recurring Incidents And Root Causes' und die KPI 'Root Cause Analysis Completion Rate'. Durch die Analyse häufiger Ursachen können Unternehmen vom reaktiven Beheben einzelner Incidents zu einem proaktiven Problemmanagement übergehen. Dauerhafte Lösungen verhindern künftige Incidents und verringern wiederkehrende Probleme. Warum das wichtig ist Es unterstützt ein proaktives Problemmanagement, indem es hilft, die Ursachen wiederkehrender Incidents zu erkennen und zu beseitigen. Woher beziehen In Freshservice ist dies häufig ein benutzerdefiniertes Feld, da die Standardfunktionen möglicherweise nicht ausreichen. Prüfen Sie in der Konfiguration 'Ticket Fields', ob ein Feld namens 'Root Cause' oder eine ähnliche Bezeichnung vorhanden ist. Beispiele SoftwarefehlerFehlerhafte NetzwerkkonfigurationSchulungsbedarf bei BenutzernHardwareausfall
	Workaround bereitgestellt WorkaroundProvided	Ein Kennzeichen dafür, ob dem Benutzer vor der endgültigen Lösung ein vorläufiger Workaround bereitgestellt wurde.
Beschreibung Dieses boolesche Attribut gibt an, ob eine vorläufige Fehlerbehebung oder ein Workaround umgesetzt wurde, um die Auswirkungen des Incidents zu begrenzen, während eine dauerhafte Lösung entwickelt wurde. Dies wird häufig über ein Kontrollkästchen oder einen bestimmten Status erfasst. Beim Process Mining unterstützt dieses Attribut das Dashboard 'Workaround Effectiveness Metrics'. Damit lassen sich die Lösungszeiten von Incidents mit und ohne Workaround vergleichen. So können Sie beurteilen, ob vorläufige Lösungen Betriebsunterbrechungen wirksam verringern und aus Sicht des Benutzers zu einer schnelleren Gesamtlösung beitragen. Warum das wichtig ist Es hilft zu messen, wie wirksam vorläufige Workarounds die Auswirkungen eines Incidents verringern und die wahrgenommene Lösungszeit verkürzen. Woher beziehen Dies ist üblicherweise ein benutzerdefiniertes boolesches Feld (Kontrollkästchen). Prüfen Sie in der Konfiguration 'Ticket Fields' von Freshservice, ob das Feld vorhanden ist. Beispiele truefalse

Erforderlich Empfohlen Optional

Aktivitäten im Incident Management

Diese wichtigen Prozessschritte und Meilensteine sollten Sie in Ihrem Event Log erfassen, damit Sie den Prozess präzise entdecken und Engpässe erkennen können.

7 Empfohlen 7 Optional

	Aktivität	Beschreibung
	Incident einer Gruppe zugewiesen	Kennzeichnet die erste Zuweisung eines Incidents an eine Supportgruppe. Sie kann automatisch über Routing-Regeln oder manuell durch eine disponierende Person erfolgen. Erfasst wird die Aktivität anhand des ersten Eintrags des Felds „Gruppe“ im Audit-Log des Incidents.
Warum das wichtig ist Die Zuweisungen zu verfolgen, ist wichtig, um die Zeit bis zur ersten Reaktion zu messen und Engpässe bei der Weiterleitung zu erkennen. So lässt sich analysieren, wie effizient Incidents an das zuständige Team gelangen. Woher beziehen Abgeleitet aus dem ersten Eintrag im Aktivitätsprotokoll des Incidents, der das Feld „Gruppe“ befüllt oder ändert. Erfassung Ermitteln Sie den ersten Timestamp, zu dem das Feld „Gruppe“ für einen Incident befüllt wird. Ereignistyp inferred
	Incident gelöst	Kennzeichnet den Zeitpunkt, zu dem der Agent eine Korrektur umgesetzt hat und den Incident als gelöst betrachtet. Erfasst wird das Ereignis, wenn der Status des Incidents auf „Gelöst“ gesetzt wird. In Freshservice ist dies ein wichtiger Meilenstein, an dem die SLA-Zeitmessung endet.
Warum das wichtig ist Dieser Meilenstein ist entscheidend, um die Zeit bis zur Lösung (TTR) zu messen. Der Zeitraum zwischen „Gelöst“ und „Geschlossen“ ist wichtig, um Verzögerungen bei der Bestätigung durch Benutzer und Regeln zum automatischen Schließen zu analysieren. Woher beziehen Wird aus dem Aktivitätsprotokoll des Incidents abgeleitet, indem erkannt wird, wann das Feld 'Status' auf 'Resolved' gesetzt wird. Erfassung Verwenden Sie den Timestamp des Eintrags im Aktivitätsprotokoll, in dem der Status auf 'Resolved' geändert wurde. Ereignistyp inferred
	Incident gemeldet	Kennzeichnet die Erstellung eines neuen Incident-Datensatzes in Freshservice. Damit beginnt der Incident-Verlauf. In der Regel meldet ein Endbenutzer den Incident über ein Portal oder per E-Mail, oder ein Service-Desk-Agent erstellt stellvertretend ein Ticket. Dieses Ereignis wird mit einem Erstellungs-Timestamp protokolliert.
Warum das wichtig ist Diese Aktivität ist das zentrale Start-Event des gesamten Prozesses. Die Zeit von diesem Ereignis bis zur Lösung zu analysieren, ist grundlegend, um die gesamte Zykluszeit und die SLA-Einhaltung zu messen. Woher beziehen Aus dem Erstellungs-Timestamp der Incident-Tabelle übernommen. Freshservice protokolliert diesen Wert ausdrücklich für jedes neue Ticket. Erfassung Verwenden Sie den Timestamp „Erstellt am“ aus dem zentralen Incident-Datensatz. Ereignistyp explicit
	Incident geschlossen	Bezeichnet den endgültigen, formalen Abschluss des Incident-Datensatzes. Dieser erfolgt in der Regel automatisch nach einer festgelegten Zeit im Status 'Resolved' oder wird manuell von einem Mitarbeitenden vorgenommen. Mit diesem Ereignis endet der Lebenszyklus des Incidents.
Warum das wichtig ist Diese Aktivität markiert das definitive Ende des Prozesses. Die Gesamtzeit bis zu diesem Ereignis entspricht der Dauer des gesamten Incident-Lebenszyklus, einschließlich etwaiger Wartezeiten auf die Bestätigung durch den Benutzer. Woher beziehen Wird aus dem Aktivitätsprotokoll des Incidents abgeleitet, indem erkannt wird, wann das Feld 'Status' auf 'Closed' gesetzt wird. Erfassung Verwenden Sie den Timestamp des Eintrags im Aktivitätsprotokoll, in dem der Status auf 'Closed' geändert wurde. Ereignistyp inferred
	Incident priorisiert	Diese Aktivität tritt ein, wenn die Priorität eines Incidents festgelegt oder geändert wird. Die Priorität bestimmt die Dringlichkeit und die SLA-Ziele für die Lösung. Erfasst werden Änderungen am Feld „Priorität“ im Verlauf des Incidents.
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 Incidents sofort bearbeitet werden. Woher beziehen Abgeleitet aus dem Aktivitätsprotokoll des Incidents, in dem alle Änderungen am Feld „Priorität“ erfasst werden. Erfassung Verwenden Sie die Timestamps aus dem Audit-Log, zu denen der Wert des Felds „Priorität“ festgelegt oder geändert wurde. Ereignistyp inferred
	Lösungsnotiz hinzugefügt	Diese Aktivität tritt ein, wenn ein Agent die Lösung des Incidents in einer Lösungsnotiz dokumentiert. In Freshservice ist dies eine eigene Aktion, bevor der Status auf „Gelöst“ geändert wird. Die Aktion und ihr Inhalt werden ausdrücklich protokolliert.
Warum das wichtig ist Damit wird die Ermittlung einer Lösung gekennzeichnet. Die Zeit zwischen diesem Ereignis und dem Status „Incident gelöst“ kann auf eine interne Prüfung oder zusätzlichen Dokumentationsaufwand hinweisen. Woher beziehen Erfasst anhand des Timestamps, zu dem eine Lösungsnotiz zum Incident hinzugefügt wird. Dieser wird im Gesprächsverlauf protokolliert. Erfassung Ermitteln Sie den Timestamp des Eintrags „Lösungsnotiz“ im Gesprächsverlauf des Incidents. Ereignistyp explicit
	Status auf „In Bearbeitung“ geändert	Diese Aktivität kennzeichnet den offiziellen Beginn der aktiven Untersuchung und Bearbeitung des Incidents. Sie wird erfasst, wenn ein Agent den Status des Incidents auf „In Bearbeitung“ setzt. Diese übliche Statusänderung wird im Aktivitätsverlauf des Tickets protokolliert.
Warum das wichtig ist Anhand dieses Meilensteins lassen sich Wartezeit und aktive Bearbeitungszeit unterscheiden. Wie lange ein Incident den Status „In Bearbeitung“ hat, ist wichtig, um den Aufwand für die Lösung zu verstehen. Woher beziehen Abgeleitet aus dem Aktivitätsprotokoll des Incidents, indem ermittelt wird, wann das Feld „Status“ auf „In Bearbeitung“ gesetzt wird. Erfassung Filtern Sie das Aktivitätsprotokoll nach einer Statusänderung auf „In Bearbeitung“ und verwenden Sie den zugehörigen Timestamp. Ereignistyp inferred
	Agent einem Incident zugewiesen	Diese Aktivität kennzeichnet, wann ein bestimmter Agent mit der Bearbeitung des Incidents betraut wird. Damit übernimmt eine einzelne Person die Verantwortung für das Ticket. Die Zuweisung wird im Aktivitätsverlauf des Tickets mit dem zuständigen Agent und dem Zeitpunkt protokolliert.
Warum das wichtig ist Damit können Sie die Arbeitslast und Leistung der Agents sowie die Zeit zwischen der Zuweisung an eine Gruppe und der Übernahme durch einen einzelnen Agent analysieren. Diese Daten sind wichtig für Dashboards zur Leistung der Agents. Woher beziehen Erfasst anhand von Änderungen am Feld „Agent“ im Aktivitätsprotokoll oder Audit-Trail des Incidents. Erfassung Ermitteln Sie die Timestamps der Änderungen am Feld „Agent“. Ereignistyp inferred
	Erste Antwort gesendet	Diese Aktivität bezeichnet die erste Mitteilung eines Agents an den Benutzer nach Eingang des Incidents. Dabei kann es sich um eine öffentliche Notiz oder eine direkte Antwort handeln. Freshservice protokolliert alle Mitteilungen der Agents mit Timestamps.
Warum das wichtig ist Die SLA für die erste Antwort einzuhalten, ist eine wichtige Kennzahl für die Kundenzufriedenheit. Anhand dieser Aktivität lässt sich messen und analysieren, wie schnell Agents neue Incidents bearbeiten. Woher beziehen Ermittelt anhand des Timestamps der ersten öffentlichen Notiz oder Antwort eines Agents im Gesprächsverlauf des Incidents. Erfassung Filtern Sie den Gesprächsverlauf des Incidents nach dem frühesten Eintrag eines Agents. Ereignistyp explicit
	Incident erneut geöffnet	Tritt ein, wenn ein zuvor als 'Resolved' markierter Incident wieder geöffnet wird, meist weil der Benutzer mit der Lösung nicht einverstanden ist. Erkennbar ist dies an einer Statusänderung von 'Resolved' zurück zu einem Status wie 'Open' oder 'In Progress'.
Warum das wichtig ist Eine hohe Wiedereröffnungsrate weist auf Probleme mit der Lösungsqualität oder unvollständige Fehlerbehebungen hin. Diese Kennzahl ist wichtig, um Nacharbeit und die Leistung der Mitarbeitenden zu analysieren. Woher beziehen Wird aus dem Aktivitätsprotokoll des Incidents abgeleitet, indem eine Statusänderung von 'Resolved' zu einem aktiven Status erkannt wird. Erfassung Filtern Sie das Aktivitätsprotokoll nach einer Änderung des Felds 'Status' von 'Resolved' zu 'Open' oder 'In Progress'. Ereignistyp inferred
	Incident neu zugewiesen	Zeigt an, dass ein Incident von einem Agent oder einer Gruppe an einen anderen Agent oder eine andere Gruppe übergeben wurde. Damit wird eine Übergabe im Lösungsprozess erfasst. Das Ereignis wird anhand späterer Änderungen an den Feldern „Agent“ oder „Gruppe“ nach der ersten Zuweisung abgeleitet.
Warum das wichtig ist Häufige Neuzuweisungen oder Übergaben deuten oft auf ineffiziente Abläufe, Wissenslücken oder eine falsche Erstzuweisung hin. Die Analyse dieser Ereignisse hilft, Verzögerungen zu erkennen und zu verringern. Woher beziehen Abgeleitet aus dem Aktivitätsprotokoll des Incidents, indem Änderungen an den Feldern „Agent“ oder „Gruppe“ nach der ersten Zuweisung verfolgt werden. Erfassung Ermitteln Sie Änderungen an den Feldern „Agent“ oder „Gruppe“ im Audit-Verlauf des Tickets. Ereignistyp inferred
	SLA-Ziel überschritten	Dieses berechnete Ereignis tritt ein, wenn die für einen Incident verstrichene Zeit das festgelegte SLA-Ziel für die Reaktion oder Lösung überschreitet. Freshservice erfasst den SLA-Status intern. Das Ereignis lässt sich ableiten, indem Timestamps mit den SLA-Richtlinien verglichen werden.
Warum das wichtig ist Misst direkt, ob die vereinbarten Service-Level eingehalten werden. Für das SLA-Leistungs-Dashboard und die kontinuierliche Verbesserung ist es entscheidend zu erkennen, wann und warum SLA-Ziele überschritten werden. Woher beziehen Wird berechnet, indem der Timestamp der Lösung oder Reaktion mit dem Fälligkeitszeitpunkt des SLA-Ziels verglichen wird. Freshservice kennzeichnet Tickets häufig als 'SLA Violated'. Erfassung Leiten Sie das Ereignis ab, indem Sie den Timestamp 'Resolved at' mit dem Timestamp 'Due by' vergleichen oder feststellen, wann sich das Feld 'SLA Status' zu 'Violated' ändert. Ereignistyp calculated
	Status auf „Ausstehend“ geändert	Kennzeichnet eine Unterbrechung des Lösungsprozesses, meist weil Informationen von einem Benutzer oder Dritten fehlen. Das Ereignis wird anhand einer Statusänderung auf einen der Status „Ausstehend“ abgeleitet. Die in diesem Status verbrachte Zeit wird bei SLA-Berechnungen häufig nicht berücksichtigt.
Warum das wichtig ist Die Zeit in ausstehenden Status zu ermitteln, ist wichtig, um externe Abhängigkeiten und Verzögerungen zu verstehen. So lässt sich die Arbeitszeit der Agents von der Wartezeit unterscheiden. Woher beziehen Abgeleitet aus dem Aktivitätsprotokoll des Incidents, wenn das Feld „Status“ auf einen Wert wie „Ausstehend“ oder „Warten auf Antwort des Benutzers“ gesetzt wird. Erfassung Filtern Sie das Aktivitätsprotokoll nach Statusänderungen auf einen ausstehenden Status und verwenden Sie den jeweiligen Timestamp. Ereignistyp inferred
	Workaround bereitgestellt	Diese Aktivität kennzeichnet, dass dem Benutzer eine vorübergehende Lösung oder ein Workaround mitgeteilt wurde, um die Auswirkungen des Incidents zu begrenzen. Für die Erfassung ist häufig eine spezielle Systemkonfiguration erforderlich, etwa ein eigenes Kontrollkästchen, ein bestimmter Notiztyp oder eine Stichwortanalyse der Notizen von Agents.
Warum das wichtig ist So lässt sich analysieren, wie wirksam Workarounds die betrieblichen Auswirkungen verringern und wie sie mit der endgültigen Lösungszeit zusammenhängen. Die Daten unterstützen das Dashboard „Kennzahlen zur Wirksamkeit von Workarounds“. Woher beziehen Wahrscheinlich handelt es sich nicht um ein ausdrücklich protokolliertes Ereignis. Es kann abgeleitet werden, indem Notizen mit Stichwörtern wie „Workaround“ gekennzeichnet werden oder Änderungen an einem benutzerdefinierten Kontrollkästchenfeld „Workaround bereitgestellt“ protokolliert werden. Erfassung Abgeleitet aus einer Änderung an einem benutzerdefinierten Feld oder einer Stichwortanalyse der Notizen von Agents. Ereignistyp inferred

Anleitungen zur Extraktion

So exportieren Sie Ihre Daten aus Freshservice

Schritte

Freshservice-Analysen öffnen: Melden Sie sich mit einem Konto, das Berichte erstellen und darauf zugreifen darf, bei Ihrer Freshservice-Instanz an. Öffnen Sie im Hauptmenü das Modul Analysen.
Neuen Bericht erstellen: Klicken Sie auf Neuer Bericht. Geben Sie einen aussagekräftigen Namen ein, zum Beispiel „Incident-Management-Event-Log“. Wählen Sie bei der Aufforderung zur Auswahl einer Datenquelle das Modul Incident Management aus.
Berichts-Widget auswählen: Fügen Sie im Berichtseditor ein neues Widget hinzu und wählen Sie den Typ Tabelle. Damit legen Sie die Grundlage für Ihr Event Log.
Primäre Datenspalten hinzufügen: Ziehen Sie im Datenquellenbereich rechts die benötigten Felder in die Spaltenkonfiguration der Tabelle. Beginnen Sie mit Incident-ID, Erstellungszeitpunkt, Agent, Gruppe, Priorität, Schweregrad, Status und Kategorie.
Aktivitätsdaten einbeziehen: Um einzelne Ereignisse zu erfassen, müssen Sie Daten zu den Ticketaktivitäten verknüpfen oder einbeziehen. Fügen Sie Ihrem Widget die Datenquelle „Aktivitäten“ hinzu. Übernehmen Sie daraus „Ausgeführt am“ (für den Ereignis-Timestamp) sowie „Aktivitätsbeschreibung“ oder ähnliche Felder, die die jeweilige Änderung beschreiben.
Berechnete Spalte „ActivityName“ erstellen: Dies ist der wichtigste Schritt. Erstellen Sie eine berechnete Spalte oder ein Formelfeld. Verwenden Sie verschachtelte IF-Anweisungen oder eine CASE-Funktion, um die Rohdaten der Aktivitäten den erforderlichen ActivityName-Werten zuzuordnen. Die Query enthält die detaillierte Logik für jede der 14 Aktivitäten.
„EventTimestamp“ konfigurieren: Erstellen Sie eine weitere berechnete Spalte für EventTimestamp. Verwenden Sie für die Aktivität „Incident gemeldet“ den Timestamp der Incident-Erstellung und für alle anderen Ereignisse den Timestamp „Ausgeführt am“ der jeweiligen Aktivität.
Berichtsfilter anwenden: Richten Sie Filter ein, um die Daten einzugrenzen. Legen Sie mindestens einen Datumsbereichsfilter für das Feld „Erstellt am“ fest. Empfohlen wird ein Zeitraum von 3 bis 6 Monaten. Fügen Sie außerdem einen Filter hinzu, der nur Tickets mit dem Tickettyp „Incident“ einschließt.
Bericht ausführen und verfeinern: Führen Sie den Bericht aus, um eine Vorschau der Daten zu erstellen. Prüfen Sie, ob die Spalten ActivityName und EventTimestamp korrekt befüllt sind. Passen Sie Formeln und Filter bei Bedarf an.
Bericht speichern und exportieren: Wenn Sie mit dem Ergebnis zufrieden sind, speichern Sie den Bericht. Wählen Sie Exportieren und anschließend das Format CSV.
Export planen (optional): Für laufende Analysen können Sie den Bericht so planen, dass er automatisch ausgeführt und exportiert wird. Legen Sie einen Zeitplan fest, zum Beispiel täglich oder wöchentlich, und lassen Sie sich die CSV-Datei per E-Mail oder an 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 bereit für den Upload.

Konfiguration

Analysenmodul: Für diese Extraktion benötigen Sie Zugriff auf das Freshservice-Analysenmodul, das in höherwertigen Tarifen wie Pro und Enterprise verfügbar ist.
Erforderliche Berechtigungen: Ihr Benutzerkonto benötigt eine Rolle mit Berechtigungen zum Erstellen, Bearbeiten und Ausführen von Berichten im Analysenmodul.
Datumsbereich: Legen Sie unbedingt einen Datumsbereichsfilter für das Erstellungsdatum der Incidents fest, um das Datenvolumen zu begrenzen. Ein rollierender Zeitraum von 3 bis 6 Monaten bietet einen guten Kompromiss zwischen historischem Kontext und Leistung.
Berichtsfilter: Filtern Sie immer nach „Tickettyp“ gleich „Incident“, damit Serviceanfragen und andere Tickettypen nicht in die Prozessanalyse einfließen.
Berechnete Felder: Bei dieser Methode werden berechnete Felder (Formeln) intensiv genutzt, um ActivityName und EventTimestamp für jedes Ereignis abzuleiten. Kenntnisse des Freshservice-Formeleditors sind hilfreich.
Datenvolumen: Beachten Sie, dass bei dieser Extraktion für jeden Incident mehrere Zeilen entstehen, eine pro Aktivität. Bei großen Freshservice-Instanzen kann die resultierende CSV-Datei sehr umfangreich werden und die Berichtserstellung sowie den Export verlangsamen.

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: Installieren Sie Python 3.6 oder höher sowie die Bibliotheken requests und pandas. Installieren Sie diese mit pip: pip install requests pandas.
API-Schlüssel generieren: Melden Sie sich als Administrator bei Ihrer Freshservice-Instanz an. Öffnen Sie die Profileinstellungen, indem Sie oben rechts auf Ihr Profilbild klicken. Wechseln Sie zum Abschnitt „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 namens extract_freshservice_incidents.py.
Parameter konfigurieren: Öffnen Sie die Skriptdatei in einem Texteditor. Ersetzen Sie die Platzhalterwerte für FRESHSERVICE_DOMAIN (zum Beispiel „ihrunternehmen.freshservice.com“), API_KEY (den soeben kopierten Schlüssel) und START_DATE_STR (den 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 ruft es über einen zweiten API-Aufruf den detaillierten Aktivitätsverlauf ab.
Event Log erstellen: Das Skript verarbeitet die Ticketdaten und das Aktivitätsprotokoll, um Datensätze für jede der 14 erforderlichen Geschäftsaktivitäten zu ermitteln und anzulegen. „Incident gemeldet“ wird beispielsweise anhand des Erstellungsdatums des Tickets erstellt, während „Status geändert zu In Bearbeitung“ aus einem bestimmten Eintrag im Aktivitätsprotokoll abgeleitet wird.
Komplexe Ereignisse ableiten: Ereignisse wie „SLA-Ziel überschritten“ werden abgeleitet. Das Skript prüft, ob das Lösungs-SLA eines Tickets verletzt wurde. Ist dies der Fall, erstellt es ein Ereignis mit dem Fälligkeitsdatum due_by als Timestamp, das den Zeitpunkt der Überschreitung kennzeichnet.
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 den Befehl python extract_freshservice_incidents.py aus.
Ausführung überwachen: Das Skript gibt Fortschrittsmeldungen in der Konsole aus und zeigt an, wie viele Tickets verarbeitet wurden. Je nach Ticketanzahl und API-Ratenbegrenzung kann dies einige Zeit dauern.
Ergebnis prüfen: Nach Abschluss erstellt das Skript im selben Verzeichnis eine CSV-Datei namens freshservice_incident_event_log.csv. Diese Datei enthält das vollständige Event Log.
Upload vorbereiten: Öffnen Sie die CSV-Datei in einem Tabellenkalkulationsprogramm und prüfen Sie, ob die Spalten (IncidentId, ActivityName, EventTimestamp usw.) wie erwartet befüllt sind. Die Datei kann nun in ProcessMind oder ein anderes Process-Mining-Tool hochgeladen werden.

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 aussagekräftige Analysen empfiehlt sich zunächst ein Zeitraum von 3 bis 6 Monaten.
PAGE_SIZE: Auf 100 gesetzt, dem von der Freshservice-API zugelassenen Höchstwert. So lässt sich die Anzahl der API-Aufrufe verringern und die Leistung verbessern. Eine Änderung dieses Werts wird grundsätzlich nicht empfohlen.
API-Ratenbegrenzung: Das Skript enthält nach der Verarbeitung jedes Tickets einen einfachen Aufruf von time.sleep(1), um die Ratenbegrenzung der Freshservice-API einzuhalten. Bei Instanzen mit hohem Datenaufkommen 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 wird sichergestellt, dass der Zugriff auf alle erforderlichen Ticketfelder und Aktivitätsprotokolle in den verschiedenen Service-Desk-Gruppen möglich ist.

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 Workflow-Automator-Regeln, Webhook-Aktionen, den Zugriff auf Incidents und den Zugriff auf den Ticketaktivitätsverlauf erlauben. Stimmen Sie den Zielendpunkt, die Authentifizierungsmethode, die TLS-Anforderungen und die Aufbewahrungsrichtlinie mit dem empfangenden Team ab.
Legen Sie den Ereignisvertrag fest, bevor Sie den Automator konfigurieren. Verwenden Sie pro Webhook-Zustellung ein JSON-Objekt mit IncidentId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate, AssignedAgent, AssignedGroup, IncidentPriority, IncidentSeverity, IncidentStatus, IncidentCategory und ResolutionSlaTargetTime. Konfigurieren Sie den Empfänger so, dass er den ursprünglichen Webhook-Payload und den Zustellungs-Timestamp unverändert speichert.
Erstellen Sie eine Workflow-Automator-Regel für die Incident-Erstellung. Legen Sie fest, dass die Regel bei der Erstellung eines Incidents ausgeführt wird, und 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 Bedingungen anhand der Incident-Felder und des Aktivitätsverlaufs, die in Ihrem Freshservice-Konto verfügbar sind. Jede Regel muss bei Eintritt der entsprechenden Aktivität ein eigenes Webhook-Ereignis senden. Leiten Sie Aktivitäten nicht anhand eines abschließenden Incident-Snapshots in ProcessMind ab.
Richten Sie eine explizite Zuordnung der Aktivitäten ein. 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 festgelegt oder geändert wird, First Response Sent, wenn die erste passende öffentliche Antwort oder Notiz eines Agents erfasst wird, Incident Reassigned, wenn Agent oder Group nach der ersten Zuweisung geändert wird, Status Changed to In Progress und Status Changed to Pending bei den entsprechenden Statusübergängen, Workaround Provided nur, wenn ein konfigurierter Workaround-Indikator vorhanden ist, Resolution Note Added, wenn eine Lösungsnotiz hinzugefügt wird, Incident Resolved, wenn der Status zu Resolved wechselt, SLA Target Breached, wenn die konfigurierte SLA-Verstoßbedingung erfüllt ist, Incident Reopened, wenn der Status von Resolved zu einem offenen Status wechselt, und Incident Closed, wenn der Status zu Closed wechselt.
Konfigurieren Sie den Webhook-Anforderungstext im JSON-Format. Fügen Sie die Incident-ID, den Aktivitätsnamen, den Ereignis-Timestamp, das Quellsystem, die letzte Datenaktualisierung und die empfohlenen Kontextattribute ein. Verwenden Sie die Webhook-Variablen, die Ihr Freshservice-Konto bereitstellt. Ist eine erforderliche Variable im Webhook-Editor nicht verfügbar, ergänzen Sie den Wert im empfangenden Dienst über eine genehmigte Freshservice-Schnittstelle oder lassen Sie ihn leer, statt einen Wert zu erfinden.
Richten Sie am Endpunkt Idempotenz und Zustellungsverarbeitung ein. Verwenden Sie eine stabile Ereignis-ID, sofern Freshservice eine bereitstellt. Andernfalls erstellen Sie einen Deduplizierungsschlüssel aus IncidentId, ActivityName, EventTimestamp und der Quell-Zustellungs-ID. Senden Sie erst dann eine erfolgreiche HTTP-Antwort, wenn der Payload dauerhaft gespeichert wurde.
Testen Sie jede Regel mit kontrollierten Incidents. Erstellen Sie einen Incident, weisen Sie eine Gruppe und einen Agent zu, ändern Sie Priorität und Status, senden Sie eine passende Antwort und fügen Sie, sofern konfiguriert, einen Workaround und eine Lösungsnotiz hinzu. Lösen Sie den Incident, öffnen Sie ihn erneut und schließen Sie ihn. Testen Sie einen SLA-Verstoß separat mit einer kontrollierten Richtlinie oder Testwarteschlange. Prüfen Sie, ob jede erwartete Aktivität als eigener Webhook-Payload eingeht.
Speichern Sie die Webhook-Payloads in einem dauerhaften Staging-Bereich, vereinheitlichen Sie die Zeitzonen der Timestamps und überführen Sie jeden Payload in eine Zeile des Event Logs. Behalten Sie eine Zeile pro expliziter Webhook-Aktivität bei. Befüllen Sie LastDataUpdate mit dem Aktualisierungs-Timestamp der Extraktion oder Datenaufnahme, nicht mit dem Timestamp des Geschäftsereignisses.
Validieren Sie das bereitgestellte Event Log, entfernen Sie ausschließlich exakt doppelte Zustellungen 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 der Case-ID und ActivityName dem Aktivitätsfeld zu.

Konfiguration

Auslöser und Umfang: Richten Sie separate Workflow-Automator-Regeln für die Incident-Erstellung und jede Aktualisierungsbedingung ein. Eine einzelne, weit gefasste Aktualisierungsregel kann doppelte oder mehrdeutige Ereignisse erzeugen, sofern der Empfänger die Aktivitäten nicht strikt zuordnet.
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 die erneute Verarbeitung auf.
Bedeutung der Aktivitäten: Unterscheiden Sie die anfängliche Zuweisung von Gruppe und Agent von späteren Änderungen. Spätere Änderungen erzeugen Incident Reassigned, während die erstmalige Zuweisung die entsprechende Aktivität für die Erstzuweisung auslöst.
Statusverarbeitung: Ordnen Sie die exakten Statuswerte zu, die in Ihrem Freshservice-Konto konfiguriert sind. Wenn das Konto benutzerdefinierte Statuswerte für „Ausstehend“ oder „Offen“ verwendet, richten Sie dafür explizite Zuordnungen ein.
Erste Antwort: Legen Sie fest, ob eine öffentliche Antwort, eine öffentliche Notiz oder eine andere Kommunikationsart als erste Antwort gilt. Wenden Sie diese Definition einheitlich an und erzeugen Sie das Ereignis nur für die erste passende Mitteilung pro Incident.
Workaround-Erkennung: Richten Sie ein eigenes Feld, Kontrollkästchen, einen Notiztyp oder eine genehmigte Schlüsselwortregel ein. Ohne eine solche Konfiguration lässt sich Workaround Provided nicht zuverlässig erkennen.
SLA-Verstoß: Richten Sie einen expliziten Auslöser für SLA-Verstöße oder einen separaten geplanten Prozess ein, der die aktuelle Zeit mit ResolutionSlaTargetTime vergleicht. Ein abschließender Incident-Snapshot allein reicht nicht aus, um den Timestamp des Verstoßes zu rekonstruieren.
Datumsbereich: Verwenden Sie für die erste Validierung Incidents aus einem Zeitraum von etwa 3 bis 6 Monaten. Beginnen Sie für den Echtzeitbetrieb mit der Datenaufnahme vor dem gewünschten Analysezeitraum und bewahren Sie den Webhook-Verlauf zur erneuten Verarbeitung auf.
Filter: Wenden Sie nur genehmigte Filter für Unternehmen, Arbeitsbereiche, Abteilungen, Services, Kategorien oder Datumsangaben 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 und EventTimestamp. Vermeiden Sie synchrone Anreicherungsaufrufe beim Empfang von Webhooks.
Zuverlässigkeit: Richten Sie Wiederholungsversuche, eine Dead-Letter-Verarbeitung, Überwachung und Unterdrückung von Duplikaten ein. Protokollieren Sie fehlgeschlagene Zustellungen und verarbeiten Sie sie nach der Fehlerbehebung erneut.
Voraussetzungen: Administratorzugriff, Verfügbarkeit des Workflow Automator, Webhook-Berechtigungen, ein HTTPS-Endpunkt, konfigurierte Authentifizierung, ausreichende Funktionen des Freshservice-Tarifs sowie ein mit ProcessMind kompatibler Ablage- oder Upload-Prozess.
Sicherheit: Verwenden Sie HTTPS, beschränken Sie nach Möglichkeit den eingehenden Zugriff, wechseln Sie Zugangsdaten regelmäßig, minimieren Sie sensible Felder und schützen Sie Incident-Beschreibungen und Notizen, sofern diese in den Payloads enthalten sind.

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

Richten Sie Ihre Daten mithilfe dieses Templates korrekt ein und gewinnen Sie wertvolle Erkenntnisse zu Ihren Incident-Management-Workflows. Beginnen Sie noch heute damit, die Lösungszeiten zu verkürzen.

Zurück zum Leitfaden zur Prozessverbesserung

Template herunterladen

Verhindern Sie SLA-Verstöße: Optimieren Sie Ihr Incident Management noch heute

Schließen Sie sich Unternehmen an, die ihre MTTR um 35 % senken und kostspielige SLA-Verstöße verhindern.

Starten Sie Ihre kostenlose Testphase

14 Tage kostenlos testen, keine Kreditkarte erforderlich.

Ihr Daten-Template für Incident Management

Ihr Daten-Template für Incident Management

Attribute für Incident Management

Aktivitäten im Incident Management

Anleitungen zur Extraktion

Datenexport aus dem Freshservice-Analysenmodul als CSV

Schritte

Konfiguration

Beispielabfrage config

Datenextraktion mit Python-Skript über die Freshservice-REST-API

Schritte

Konfiguration

Beispielabfrage python

Echtzeit-Datenübertragung über Webhooks des Workflow Automator

Schritte

Konfiguration

Beispielabfrage config

Möchten Sie loslegen?

Verhindern Sie SLA-Verstöße: Optimieren Sie Ihr Incident Management noch heute