> Kontinuierliche Prozessverbesserung > Incident Management > Freshservice > Datenvorlage

Data Template: Incident Management

Freshservice

Incident Management-Attribute (20) Incident Management-Aktivitäten (14) Extraktionsleitfäden (3)

Ihr Incident Management Data Template

Dieses Template wurde entwickelt, um Sie bei der Vorbereitung Ihrer Daten für eine effektive Incident-Management-Analyse zu unterstützen. Es beschreibt die wesentlichen zu sammelnden Attribute, die kritischen zu verfolgenden Aktivitäten und bietet praktische Anleitungen zur Extraktion dieser Informationen aus Ihrem Quellsystem. Nutzen Sie diese Ressource, um Ihren Datenvorbereitungsprozess zu optimieren.

Empfohlene Attribute zur Erfassung
Wichtige Aktivitäten zur Verfolgung
Extraktionsanleitung

Neu bei Event Logs? Erfahren Sie wie man ein Process Mining Event Log erstellt.

Vorlage herunterladen

Incident Management-Attribute

Dies sind die empfohlenen Datenfelder, die Sie in Ihr Event Log aufnehmen sollten, um eine umfassende Analyse Ihres Incident-Management-Prozesses zu ermöglichen.

5 Erforderlich 7 Empfohlen 8 Optional

	Name	Beschreibung
	Incident-ID IncidentId	Der eindeutige Identifikator für jeden Vorfall-Datensatz, der als Primärschlüssel zur Verfolgung des gesamten Vorfall-Lebenszyklus dient.
Beschreibung Die Incident ID ist der Grundstein der Incident Management Analyse. Sie fungiert als Case ID und verbindet alle zugehörigen Aktivitäten, Timestamps und Attributänderungen zu einer einzigen, zusammenhängenden Reise. Im Process Mining ist jeder Event Log Eintrag mit einer Incident ID verknüpft, was die Rekonstruktion des End-to-End-Prozessflusses für jeden Incident ermöglicht. Dies ist unerlässlich für die Berechnung von Zykluszeiten, die Analyse von Prozessvarianten und die Identifizierung von Engpässen, die spezifisch für einzelne Cases sind. Ohne einen eindeutigen Identifier wäre es unmöglich, zwischen verschiedenen Incidents zu unterscheiden und deren Pfade von der Meldung bis zur Lösung zu analysieren. Warum es wichtig ist Es identifiziert jeden Incident eindeutig und ermöglicht die End-to-End-Verfolgung und Analyse seines Lebenszyklus von der Erstellung bis zur Schließung. Woher erhalten Dies ist die primäre Kennung für ein Ticket, verfügbar über die Freshservice Tickets API als 'id'-Feld im Ticket-Objekt. Beispiele INC-10234INC-10235INC-10236
	Aktivitätsname ActivityName	Der Name der spezifischen Geschäftsaktivität oder des Events, das zu einem bestimmten Zeitpunkt innerhalb des Incident-Lebenszyklus aufgetreten ist.
Beschreibung Der Aktivitätsname beschreibt einen einzelnen Schritt oder ein Event im Incident Management Prozess, wie z.B. 'Incident Assigned to Group', 'Status Changed to Pending' oder 'Incident Resolved'. Diese Aktivitäten ergeben sich aus Änderungen der Incident-Daten im Zeitverlauf. Dieses Attribut ist grundlegend für Process Mining, da es die Knoten in der entdeckten Prozesslandkarte definiert. Durch die Analyse der Sequenz und Frequenz dieser Aktivitäten können Unternehmen den tatsächlichen Incident-Lösungsprozess visualisieren, gängige Pfade identifizieren, Abweichungen vom Standardverfahren erkennen und Nacharbeits-Loops wie häufige Neu-Zuweisungen aufzeigen. Warum es wichtig ist Es definiert die Schritte in der Prozesslandkarte und ermöglicht die Visualisierung und Analyse des Incident-Lösungsflusses, von Bottlenecks und Abweichungen. Woher erhalten Dieses Attribut ist kein direktes Feld in Freshservice, sondern wird aus Änderungen in den Ticket-Eigenschaften wie Status, Priorität, Agenten-/Gruppenzuweisung und 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 genaue Uhrzeit, zu der die Aktivität oder das Event stattfand.
Beschreibung Der Event Timestamp, oder Startzeitpunkt, markiert den genauen Zeitpunkt, zu dem eine Aktivität stattgefunden hat. Jede Aktivität im Lebenszyklus des Incidents, von der Erstellung bis zur Schließung, hat einen zugeordneten Timestamp. Dieses Attribut ist entscheidend für alle zeitbasierten Process Mining Analysen. Es wird verwendet, um Events chronologisch zu ordnen, die Dauer zwischen Aktivitäten zu berechnen, die gesamte Case Cycle Time zu messen und Wartezeiten zu analysieren. Es ist die Grundlage für den Aufbau von Dashboards, die die SLA-Performance, Übergabeverzögerungen und die Gesamtlösungszeiten verfolgen. Warum es wichtig ist Es liefert die chronologische Reihenfolge der Events, was für die Berechnung von Dauern, die Analyse von Cycle Times und das Verständnis der Prozessleistung unerlässlich ist. Woher erhalten Dies wird aus verschiedenen Timestamp-Feldern in Freshservice abgeleitet, wie 'created_at', 'updated_at' und Timestamps innerhalb der Ticket-Konversation oder der Audit Logs. Beispiele 2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
	Letzte Datenaktualisierung LastDataUpdate	Der Timestamp, der den Zeitpunkt der letzten Aktualisierung oder Extraktion der Daten für diesen Prozess angibt.
Beschreibung Dieses Attribut liefert einen Timestamp darüber, wann der gesamte Datensatz zuletzt aus dem Quellsystem aktualisiert wurde. Es ist ein Metadatenfeld, das sich auf den gesamten Datensatz und nicht auf einzelne Events bezieht, wird aber aus Konsistenzgründen oft auf Event-Ebene mitgeführt. In der Analyse sind diese Informationen entscheidend für das Verständnis der Datenaktualität und des Zeitfensters, das von den Dashboards und KPIs abgedeckt wird. Es gibt den Benutzern Vertrauen in die Aktualität der Erkenntnisse und hilft, Erwartungen darüber zu managen, ob die allerneuesten Vorfälle in die Analyse einbezogen sind. Warum es wichtig ist Es informiert Benutzer über die Aktualität der Daten und stellt sicher, dass sie den durch die Analyse abgedeckten Zeitraum verstehen. Woher erhalten Dies ist ein Metadaten-Timestamp, der während des Datenextraktions-(ETL)-Prozesses generiert wird. Beispiele 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	Quellsystem SourceSystem	Das System, aus dem die Daten extrahiert wurden, typischerweise Freshservice.
Beschreibung Dieses Attribut identifiziert die Herkunft der Daten. Obwohl es in diesem Kontext durchgängig Freshservice sein wird, ist es ein entscheidendes Feld in Umgebungen, in denen Daten aus mehreren Systemen für eine ganzheitliche Prozessansicht kombiniert werden könnten. Die Aufnahme des Attributs Quellsystem ist eine Best Practice für Data Governance und Nachvollziehbarkeit. Es gewährleistet Klarheit über die Datenherkunft, was wichtig für Validierung, Fehlerbehebung und die zukünftige Erweiterung des Process Mining Projekts um andere Servicemanagement- oder Betriebssysteme ist. Warum es wichtig ist Es gewährleistet die Datenrückverfolgbarkeit und Governance, indem es den Ursprung der Incident Management Daten klar identifiziert. Woher erhalten Dies ist typischerweise ein statischer Wert, der während des Datentransformations-(ETL)-Prozesses hinzugefügt wird, um den Datensatz zu kennzeichnen. Beispiele FreshserviceFreshservice-EUFreshservice-PROD
	Incident-Kategorie IncidentCategory	Die Kategorie, die zur Klassifizierung des Incidents verwendet wird, z.B. Hardware, Software oder Netzwerk.
Beschreibung Die Incident-Kategorie ermöglicht die Klassifizierung von Incidents basierend auf der Art des gemeldeten Problems. Diese hierarchische Klassifizierung unterstützt die Weiterleitung des Incidents an das richtige Team und ist entscheidend für die Trendanalyse. Dieses Attribut wird im Incident Categorization Accuracy Dashboard verwendet, um zu analysieren, ob eine anfängliche Fehlkategorisierung aufgrund von Umverteilungen zu längeren Lösungszeiten führt. Durch die Gruppierung von Incidents nach Kategorie können Organisationen wiederkehrende Probleme identifizieren, den größten Aufwand im Supportbereich erkennen und Verbesserungsinitiativen zielgerichtet anpassen. Warum es wichtig ist Es ermöglicht die Analyse von Incident-Trends und hilft festzustellen, ob eine falsche Kategorisierung Lösungsverzögerungen verursacht. Woher erhalten Dies ist ein Standardfeld in Freshservice, das jedoch anpassbar ist. Es ist in der Tickets API als 'category' verfügbar, mit den zugehörigen Feldern 'sub_category' und 'item_category'. Beispiele HardwareSoftwareNetzwerkproblemKontozugang
	Incident-Priorität IncidentPriority	Das Prioritätslevel des Incidents, das die Dringlichkeit der Antwort und Lösung bestimmt.
Beschreibung Die Incident-Priorität ist ein Schlüsselfeld, das die erforderliche Geschwindigkeit und den Fokus bei der Bearbeitung eines Incidents vorgibt. Sie wird typischerweise auf einer Skala wie Low, Medium, High und Urgent definiert und steuert oft SLA-Ziele. Im Process Mining ist die Priorität eine kritische Dimension für Filterung und Analyse. Sie ermöglicht den Vergleich der Lösungsprozesse für High-Priority- versus Low-Priority-Incidents und stellt sicher, dass kritische Probleme effizient bearbeitet werden. Dashboards segmentieren Metriken wie cycle time und SLA-Einhaltung oft nach Priorität, um Support-Managern umsetzbare Erkenntnisse zu liefern. Warum es wichtig ist Es hilft, die Analyse auf die kritischsten Incidents zu priorisieren und ist unerlässlich für die Bewertung der SLA-Leistung und Ressourcenzuweisung. Woher erhalten Verfügbar in der Freshservice Tickets API als Feld 'priority'. Die Werte sind numerisch (z.B. 1 für Niedrig, 4 für Dringend). Beispiele NiedrigMittelHochDringend
	Incident-Schweregrad IncidentSeverity	Der Schweregrad des Vorfalls, der dessen Geschäftsauswirkungen anzeigt.
Beschreibung Der Incident-Schweregrad misst die Auswirkungen eines Incidents auf das Unternehmen, oft kategorisiert als Low, Medium, High oder Critical. Während er mit der Priorität verwandt ist, konzentriert sich der Schweregrad auf die Auswirkungen, während die Priorität die Dringlichkeit fokussiert. Die Kombination aus Schweregrad und Auswirkungen bestimmt oft die endgültige Priorität. Die Analyse nach Schweregrad hilft zu verstehen, wie gut die Organisation mit Incidents mit erheblichen geschäftlichen Konsequenzen umgeht. Er wird in Dashboards verwendet, um Lösungszeiten und SLA-Leistung zu segmentieren und sicherzustellen, dass die wirkungsvollsten Probleme während ihres gesamten Lebenszyklus die angemessene Aufmerksamkeit und Ressourcen erhalten. Warum es wichtig ist Es misst die geschäftlichen Auswirkungen eines Incidents und ermöglicht eine Analyse, die sich auf die Minderung der schädlichsten Probleme konzentriert. Woher erhalten 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, wie z.B. Offen, Ausstehend, Gelöst oder Geschlossen.
Beschreibung Der Incident Status zeigt den aktuellen Zustand des Incidents an. Statusänderungen sind Schlüsselereignisse, die die Grundlage der entdeckten Prozesslandkarte bilden, wie z.B. der Übergang von 'In Progress' zu 'Pending' oder von 'Resolved' zu 'Closed'. Dieses Attribut ist grundlegend für das Verständnis des Incident-Verlaufs. Die Analyse der Verweildauer in jedem Status hilft, Engpässe zu identifizieren, z.B. wenn Incidents zu lange im Status 'Pending' auf eine Benutzerantwort warten. Es ist auch entscheidend für die Definition der Start- und Endpunkte für Zykluszeitberechnungen. Warum es wichtig ist Es verfolgt den Fortschritt des Incidents durch seinen Lebenszyklus und hilft, Phasen zu identifizieren, in denen Verzögerungen häufig sind. Woher erhalten Verfügbar in der Freshservice Tickets API als Feld 'status'. Die Werte sind numerisch. Beispiele OffenIn BearbeitungPendingResolvedGeschlossen
	SLA-Zielzeit für die Lösung ResolutionSlaTargetTime	Der Timestamp, bis zu dem der Vorfall gemäß seiner SLA-Richtlinie gelöst werden soll.
Beschreibung Dieses Attribut speichert das spezifische Datum und die Uhrzeit, die als Frist für die Lösung eines Vorfalls dient. Dieses Ziel wird durch die auf das Ticket angewendete Service Level Agreement (SLA)-Richtlinie bestimmt, die typischerweise von Faktoren wie der Priorität abhängt. Diese Zielzeit ist essenziell für die Berechnung des KPI 'SLA-Einhaltungsrate' und als Grundlage für das SLA Performance Dashboard. Durch den Vergleich des tatsächlichen Lösungs-Timestamps mit diesem Ziel können wir feststellen, ob ein Vorfall pünktlich gelöst oder seine SLA verletzt wurde. Dies ist fundamental für die Messung der Service-Level-Compliance. Warum es wichtig ist Es gibt die Frist für die Lösung an, die für die Berechnung der SLA-Compliance notwendig ist und zur Identifizierung gefährdeter Incidents dient. Woher erhalten Verfügbar in der Freshservice Tickets API als 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, das dem Vorfall aktuell zugewiesen ist.
Beschreibung Die zugewiesene Gruppe zeigt an, welches Team, wie z.B. 'Level 1 Support', 'Network Team' oder 'Database Admins', für den Incident verantwortlich ist. Änderungen dieses Attributs bedeuten eine Eskalation oder Übertragung zwischen verschiedenen Funktionsteams. Die Analyse der zugewiesenen Gruppe ist entscheidend, um Übergabe- und Transferverzögerungen zu verstehen. Process Mining kann den Fluss von Incidents zwischen Gruppen visualisieren, gängige Eskalationspfade hervorheben und die Wartezeit messen, die jede Gruppe bis zur Maßnahmenumsetzung benötigt. Dies hilft, organisatorische Engpässe zu identifizieren und Möglichkeiten zur Optimierung der teamübergreifenden Zusammenarbeit zu finden. Warum es wichtig ist Es verfolgt, welches Team verantwortlich ist, was entscheidend ist für die Analyse von Übergaben, Eskalationen und Verzögerungen zwischen Teams. Woher erhalten Verfügbar in der Freshservice Tickets API als Feld 'group_id'. Diese ID kann mit der Groups API verbunden werden, um den Namen der Gruppe abzurufen. Beispiele Service DeskNetzwerkbetriebInfrastruktur-Support
	Zugewiesener Agent AssignedAgent	Der Name oder die ID des Support-Agenten, der aktuell zur Lösung des Incidents zugewiesen ist.
Beschreibung Der zugewiesene Agent identifiziert den einzelnen Service-Desk-Mitarbeiter, der zu einem bestimmten Zeitpunkt für den Incident verantwortlich ist. Änderungen dieses Attributs stellen eine Eigentumsübertragung zwischen Agenten dar. Dieses Attribut ist unerlässlich für die Performance-Analyse und ermöglicht Dashboards, die die Arbeitslast des Agenten, die durchschnittliche Lösungszeit pro Agent und die First-Contact-Resolution-Raten verfolgen. Es wird auch zur Analyse von Übergaben zwischen Agenten verwendet, die eine Quelle für Verzögerungen und Ineffizienz sein können. Durch die Verfolgung von Agenten-Zuweisungen können Manager den Schulungsbedarf ermitteln und leistungsstarke Teammitglieder erkennen. Warum es wichtig ist Es ermöglicht die Analyse der Agentenleistung, der Workload-Verteilung und der Auswirkungen von Agenten-Übergaben auf die Lösungszeiten. Woher erhalten Verfügbar in der Freshservice Tickets API als Feld 'responder_id'. Diese ID kann mit der Agents API verbunden werden, um den Namen des Agenten abzurufen. Beispiele John DoeJane SmithSupportBot
	Abteilung des Anfragenden RequestersDepartment	Die Abteilung, der der Benutzer angehört, der den Incident gemeldet hat.
Beschreibung Dieses Attribut identifiziert die Geschäftsabteilung des Anfragenden, z.B. Vertrieb, Finanzen oder IT. Diese Informationen stammen typischerweise aus dem Benutzerprofil innerhalb von Freshservice. Die Analyse von Vorfällen nach der Abteilung des Anfragenden kann aufzeigen, ob bestimmte Geschäftsbereiche überproportional von Problemen betroffen sind oder ob abteilungsspezifische Probleme existieren. Sie liefert wertvollen Kontext für das Verständnis der Geschäftsauswirkungen von Vorfällen und kann helfen, die Behebung von Problemen in kritischen Abteilungen zu priorisieren. Warum es wichtig ist Es liefert geschäftlichen Kontext und ermöglicht die Analyse von Incident-Trends und deren Auswirkungen auf bestimmte Abteilungen. Woher erhalten Diese Informationen sind mit dem Anfragenden des Tickets verknüpft. Sie können über den Requesters API Endpoint unter Verwendung der requester_id aus dem Ticket abgerufen werden, um dann auf die department_id und den Namen zuzugreifen. Beispiele VertriebMarketingFinanzenPersonalwesen
	Grundursache RootCause	Die nach der Untersuchung für den Vorfall identifizierte Grundursache.
Beschreibung Das Attribut Ursache (Root Cause) erfasst das grundlegende Problem, das zu einem Vorfall geführt hat. Diese Information wird in der Regel von Support-Mitarbeitern während oder nach der Lösung im Rahmen einer Ursachenanalyse (RCA) eingetragen. Dieses Attribut ist entscheidend für das Dashboard 'Wiederkehrende Vorfälle und Ursachen' und den KPI 'Abschlussrate der Ursachenanalyse'. Durch die Analyse häufiger Ursachen können Organisationen von einer reaktiven Vorfallbehebung zu einem proaktiven Problemmanagement übergehen und dauerhafte Lösungen implementieren, die zukünftige Vorfälle verhindern und wiederkehrende Probleme reduzieren. Warum es wichtig ist Es ermöglicht proaktives Problem Management, indem es hilft, die zugrunde liegenden Ursachen wiederkehrender Incidents zu identifizieren und zu eliminieren. Woher erhalten Dies ist oft ein benutzerdefiniertes Feld in Freshservice, da die Standardfunktionalität möglicherweise begrenzt ist. Überprüfen Sie die Konfiguration der 'Ticket Fields' nach einem Feld namens 'Root Cause' oder Ähnlichem. Beispiele Software-BugNetzwerkkonfigurationsfehlerBenutzer-SchulungsproblemHardware-Ausfall
	Handoff Count HandoffCount	Die Anzahl der Transfers eines Incidents zwischen verschiedenen Agenten oder Gruppen.
Beschreibung Handoff Count ist eine berechnete Metrik, die die Anzahl der Neuzuweisungen quantifiziert, die ein Incident während seines Lebenszyklus durchläuft. Jede Änderung des Attributs 'AssignedAgent' oder 'AssignedGroup' erhöht diesen Zähler. Ein hoher Handoff Count ist oft ein Indikator für Prozessineffizienz, falsche anfängliche Zuweisung oder mangelnde Agentenexpertise. Diese Metrik unterstützt direkt das Incident Handoff Count KPI und das Handoff- und Transfer-Verzögerungsanalyse-Dashboard, indem sie hilft, Incidents oder Prozesspfade mit übermäßigen Übergaben zu identifizieren, die zu Verzögerungen führen. Warum es wichtig ist Es quantifiziert Nacharbeit und Neuzuweisungen und hilft so, Ineffizienzen zu identifizieren, die durch falsche Weiterleitung oder Wissenslücken verursacht werden. Woher erhalten Dies ist eine berechnete Kennzahl, die durch Zählen der Anzahl unterschiedlicher Werte oder Änderungen in den Feldern 'AssignedAgent' oder 'AssignedGroup' über den Lebenszyklus eines einzelnen Incidents abgeleitet wird. Beispiele 0125
	Lösungszykluszeit ResolutionCycleTime	Die gesamte verstrichene Zeit von der ersten Meldung eines Vorfalls bis zu seiner Lösung.
Beschreibung Die Lösungszykluszeit ist ein Key Performance Indicator (KPI), der für jeden Incident berechnet wird. Sie misst die Gesamtdauer des Incident Management-Prozesses aus Sicht des Benutzers, von der initialen Meldung bis zur Bestätigung der Lösung. Diese berechnete Metrik ist die Grundlage des Dashboards 'Incident Resolution Cycle Time'. Sie wird verwendet, um die gesamte Prozesseffizienz zu messen und wird oft über verschiedene Dimensionen wie Priorität, Kategorie und Agent analysiert. Die Identifizierung von Incidents mit langen Zykluszeiten hilft, systemische Verzögerungen und Ineffizienzen genau zu bestimmen. Warum es wichtig ist Es ist eine primäre Kennzahl für die Prozessleistung, die direkt anzeigt, wie lange es dauert, Incidents von Anfang bis Ende zu lösen. Woher erhalten Dies ist eine berechnete Kennzahl. Sie ist die Differenz zwischen dem Timestamp der Aktivität 'Incident Resolved' und dem der Aktivität 'Incident Reported'. Beispiele 259200000864000003600000
	Meldekanal ReportingChannel	Die Methode oder der Kanal, über den der Incident gemeldet wurde, wie z.B. E-Mail, Portal oder Telefon.
Beschreibung Der Meldekanal, auch als Quelle bezeichnet, gibt an, wie ein Vorfall ins Supportsystem gelangt ist. Typische Kanäle sind E-Mail, ein Self-Service-Portal, Telefonanrufe oder Chat. Die Analyse dieses Attributs hilft, die Effizienz verschiedener Meldekanäle zu bewerten. Das Dashboard zur 'Effizienz des Meldekanals' vergleicht das Vorfallvolumen und die durchschnittliche Lösungszeit pro Kanal, um die effektivsten Methoden zu identifizieren und mögliche Prozessverbesserungen aufzuzeigen. So werden beispielsweise über das Portal gemeldete Vorfälle oft schneller gelöst, da sie von Anfang an strukturiertere Informationen enthalten können. Warum es wichtig ist Es hilft, die effizientesten Meldekanäle zu identifizieren und zeigt Möglichkeiten zur Verbesserung des Incident-Aufnahmeprozesses auf. Woher erhalten Verfügbar in der Freshservice Tickets API als Feld 'source'. Die Werte sind numerisch. Beispiele E-MailPortalTelefonChat
	SLA verletzt IsSlaBreached	Eine berechnete Kennzeichnung, die true ist, wenn der Incident nicht innerhalb der definierten SLA-Zielzeit gelöst wurde.
Beschreibung Dieses boolesche Attribut ist eine berechnete Metrik, die angibt, ob die Lösungszeit eines Vorfalls sein SLA-Ziel überschritten hat. Es wird durch den Vergleich des tatsächlichen Lösungs-Timestamps mit der ResolutionSlaTargetTime abgeleitet. Dieses Flag ist ein direkter Input für den KPI 'SLA-Einhaltungsrate' und das SLA Performance Dashboard. Es vereinfacht die Analyse, indem es ein klares, binäres Ergebnis für die SLA-Performance jedes Vorfalls liefert, was eine einfache Aggregation und Trendanalyse ermöglicht. Es hilft, das Volumen und den Prozentsatz der Vorfälle, die Service-Verpflichtungen nicht erfüllen, schnell zu identifizieren. Warum es wichtig ist Es misst direkt die SLA-Compliance für jeden Incident, was die Berechnung der Gesamt-Einhalteraten und die Identifizierung von Problembereichen erleichtert. Woher erhalten Dies ist ein berechnetes Feld, das während der Datentransformation durch den Vergleich des Timestamp von 'Incident Resolved' mit dem Feld 'ResolutionSlaTargetTime' abgeleitet wird. Beispiele truefalsch
	Wiedereröffnet IsReopened	Eine berechnete Kennzeichnung, die true ist, wenn ein Incident nach der Lösung oder Schließung wiedereröffnet wurde.
Beschreibung Dieses boolesche Attribut ist ein berechnetes Flag, das Vorfälle identifiziert, die wiedereröffnet wurden. Es wird auf true gesetzt, wenn ein Vorfall, nachdem er den Status 'Gelöst' oder 'Geschlossen' erreicht hat, wieder in einen offenen oder in Bearbeitung befindlichen Status geändert wird. Dieses Flag ist entscheidend für die Berechnung des KPI 'Wiedereröffnungsrate von Vorfällen' und für das Dashboard 'Wiederkehrende Vorfälle'. Eine hohe Rate von wiedereröffneten Vorfällen kann auf Probleme mit der Qualität der ursprünglichen Lösung, eine unvollständige Ursachenanalyse oder eine vorzeitige Schließung hinweisen. Die Analyse dieser Fälle hilft, die Qualität und Nachhaltigkeit von Fehlerbehebungen zu verbessern. Warum es wichtig ist Es identifiziert Fehler im Lösungsprozess und hebt Incidents hervor, bei denen die anfängliche Lösung ineffektiv war und zu Nacharbeit führte. Woher erhalten Dies ist ein berechnetes Feld, das aus der Abfolge von Aktivitäten im Event Log abgeleitet wird. Es ist true, wenn eine Aktivität wie 'Incident Reopened' auftritt oder wenn eine Aktivität im offenen Status auf eine im geschlossenen Status für dieselbe Incident-ID folgt. Beispiele truefalsch
	Workaround bereitgestellt WorkaroundProvided	Ein Kennzeichen, das angibt, ob dem Benutzer vor der endgültigen Lösung eine temporäre Umgehungslösung bereitgestellt wurde.
Beschreibung Dieses boolesche Attribut gibt an, ob eine temporäre Fehlerbehebung oder ein Workaround implementiert wurde, um die Auswirkungen des Vorfalls zu mildern, während eine permanente Lösung entwickelt wurde. Dies wird oft über ein Kontrollkästchen oder einen spezifischen Status nachverfolgt. Im Process Mining unterstützt dieses Attribut das Dashboard 'Workaround-Effektivitäts-Metriken'. Es ermöglicht einen Vergleich der Lösungszeiten für Vorfälle mit und ohne Workarounds, um festzustellen, ob temporäre Fehlerbehebungen Geschäftsunterbrechungen effektiv reduzieren und zu einer schnelleren Gesamtlösung aus Benutzersicht beitragen. Warum es wichtig ist Es hilft, die Effektivität temporärer Workarounds bei der Reduzierung der Incident-Auswirkungen und der Beschleunigung der wahrgenommenen Lösung zu messen. Woher erhalten Dies ist typischerweise ein benutzerdefiniertes Boolean (Checkbox)-Feld. Seine Existenz muss in der Freshservice 'Ticket Fields' Konfiguration überprüft werden. Beispiele truefalsch

Erforderlich Empfohlen Optional

Incident Management-Aktivitäten

Dies sind die entscheidenden Prozessschritte und Meilensteine, die Sie in Ihrem Event Log erfassen sollten, um eine präzise Prozessentdeckung und Engpasserkennung zu gewährleisten.

7 Empfohlen 7 Optional

	Aktivität	Beschreibung
	Incident einer Gruppe zugewiesen	Stellt die initiale Zuweisung eines Incidents zu einer Supportgruppe dar. Dies kann automatisch über Routing-Regeln oder manuell durch einen Dispatcher erfolgen. Diese Activity wird durch die Verfolgung der initialen Belegung des Feldes 'Group' im Audit Log des Incidents erfasst.
Warum es wichtig ist Die Verfolgung von Zuweisungen ist entscheidend für die Messung der ersten Reaktionszeiten und die Identifizierung von Bottlenecks im Zuweisungsprozess. Sie hilft zu analysieren, wie effizient Incidents an das richtige Team weitergeleitet werden. Woher erhalten Abgeleitet aus dem ersten Eintrag im Aktivitätsprotokoll des Incidents, der das Feld 'Group' füllt oder ändert. Erfassen Identifizieren Sie den ersten Timestamp, an dem das Feld 'Group' für einen Incident ausgefüllt wird. Ereignistyp inferred
	Incident gelöst	Markiert den Zeitpunkt, an dem der Agent eine Lösung implementiert hat und den Incident als gelöst betrachtet. Dies wird erfasst, wenn der Status des Incidents auf 'Resolved' geändert wird. In Freshservice ist dies ein wichtiger Meilenstein, der die SLA-Uhr stoppt.
Warum es wichtig ist Dies ist ein kritischer Meilenstein zur Messung der Time to Resolution (TTR). Der Zeitraum zwischen 'Resolved' und 'Closed' ist wichtig für die Analyse von Verzögerungen bei der Benutzerbestätigung und von Auto-Closure-Richtlinien. Woher erhalten Abgeleitet aus dem Aktivitätsprotokoll des Incidents durch Identifizierung, wann das Feld 'Status' auf 'Resolved' aktualisiert wird. Erfassen Verwenden Sie den Timestamp aus dem Aktivitäten-Log-Eintrag für die Statusänderung zu 'Resolved'. Ereignistyp inferred
	Incident gemeldet	Markiert die Erstellung eines neuen Incident-Datensatzes in Freshservice. Dies ist der Startpunkt des Incident-Lebenszyklus, typischerweise ausgelöst durch einen Endbenutzer über ein Portal, E-Mail oder einen Service Desk Agenten, der ein Ticket in deren Namen erstellt. Dieses Event wird explizit mit einem Erstellungs-Timestamp protokolliert.
Warum es wichtig ist Diese Aktivität ist das primäre Start-Event für den gesamten Prozess. Die Analyse der Zeit von diesem Event bis zur Lösung ist grundlegend für die Messung der Gesamtzykluszeiten und der SLA-Einhaltung. Woher erhalten Erfasst aus dem Erstellungs-Timestamp der Incident-Tabelle. Freshservice protokolliert dies explizit für jedes neue Ticket. Erfassen Verwenden Sie den 'Created at'-Timestamp aus dem Haupt-Incident-Datensatz. Ereignistyp explicit
	Incident geschlossen	Stellt den finalen, formellen Abschluss des Incident-Datensatzes dar. Dies geschieht typischerweise automatisch nach einer festgelegten Zeitspanne im Status 'Resolved' oder kann manuell von einem Agenten durchgeführt werden. Dieses Event markiert das Ende des Incident-Lebenszyklus.
Warum es wichtig ist Diese Aktivität ist der definitive Endpunkt des Prozesses. Die Gesamtzeit bis zu diesem Event stellt die vollständige Vorfall-Lebenszyklusdauer dar, einschließlich etwaiger Benutzerbestätigungsphasen. Woher erhalten Abgeleitet aus dem Aktivitätsprotokoll des Incidents durch Identifizierung, wann das Feld 'Status' auf 'Closed' aktualisiert wird. Erfassen Verwenden Sie den Timestamp aus dem Aktivitäten-Log-Eintrag für die Statusänderung zu 'Closed'. Ereignistyp inferred
	Incident priorisiert	Tritt auf, wenn die Priorität des Incidents festgelegt oder aktualisiert wird. Das Prioritätslevel bestimmt die Dringlichkeit und die SLA-Ziele für die Lösung. Dies wird durch die Überwachung von Änderungen im Feld 'Priority' innerhalb der Incident-Historie erfasst.
Warum es wichtig ist Falsche oder verzögerte Priorisierung kann zu SLA-Verstößen und ineffizienter Ressourcenzuweisung führen. Die Analyse dieser Aktivität trägt dazu bei, dass kritische Incidents sofortige Aufmerksamkeit erhalten. Woher erhalten Abgeleitet aus dem Aktivitätsprotokoll des Incidents, das alle Aktualisierungen des Feldes 'Priority' verfolgt. Erfassen Verwenden Sie Timestamps aus dem Audit Log, wo der Wert des Feldes 'Priority' festgelegt oder geändert wurde. Ereignistyp inferred
	Lösungsnotiz hinzugefügt	Tritt auf, wenn ein Agent die Lösung des Incidents dokumentiert, indem er eine Lösungsnotiz hinzufügt. Dies ist eine eigenständige Aktion in Freshservice, bevor der Status auf 'Resolved' geändert wird. Diese Aktion und ihr Inhalt werden explizit protokolliert.
Warum es wichtig ist Dies kennzeichnet die Identifizierung einer Lösung. Die Zeit zwischen diesem Status und dem Status 'Incident Resolved' kann auf interne Überprüfungs- oder Dokumentationsaufwände hindeuten. Woher erhalten Erfasst vom Timestamp, zu dem eine Lösungsnotiz zum Incident hinzugefügt wurde, was in der Konversationshistorie protokolliert wird. Erfassen Identifizieren Sie den Timestamp des 'Resolution Note'-Eintrags im Gesprächsverlauf des Incidents. Ereignistyp explicit
	Status auf 'In Bearbeitung' geändert	Diese Aktivität markiert den offiziellen Beginn der aktiven Untersuchung und Bearbeitung des Vorfalls. Sie wird erfasst, wenn ein Agent den Status des Vorfalls auf 'In Progress' (in Bearbeitung) ändert. Dies ist eine standardmäßige Statusänderung, die in der Aktivitätshistorie des Tickets protokolliert wird.
Warum es wichtig ist Dieser Meilenstein hilft, zwischen Wartezeit und aktiver Arbeitszeit zu unterscheiden. Die Analyse der Dauer, in der sich ein Incident im Status 'In Progress' befindet, ist entscheidend, um den Lösungsaufwand zu verstehen. Woher erhalten Abgeleitet aus dem Aktivitätsprotokoll des Incidents durch Identifizierung, wann das Feld 'Status' auf 'In Progress' aktualisiert wird. Erfassen Filtern Sie das Activity Log nach einer Statusänderung zu 'In Progress' und verwenden Sie dessen Timestamp. Ereignistyp inferred
	Agent dem Incident zugewiesen	Diese Aktivität markiert den Zeitpunkt, zu dem ein bestimmter Agent zur Bearbeitung des Vorfalls zugewiesen wird. Sie kennzeichnet die individuelle Verantwortung für das Ticket. Die Zuweisung wird in der Aktivitätshistorie des Tickets protokolliert und zeigt, welcher Agent wann zugewiesen wurde.
Warum es wichtig ist Dies ermöglicht die Analyse der Agenten-Arbeitslast, der Leistung und der Zeit, die ein Vorfall nach der Gruppenzuweisung von einem einzelnen Mitarbeiter übernommen wird. Es ist entscheidend für Agentenleistungs-Dashboards. Woher erhalten Verfolgt durch Änderungen am Feld 'Agent' im Aktivitäten-Log des Incidents oder Audit Trail. Erfassen Identifizieren Sie Timestamps, die Änderungen im Feld 'Agent' entsprechen. Ereignistyp inferred
	Erste Antwort gesendet	Diese Aktivität stellt die erste Kommunikation eines Agents mit dem Benutzer nach der Meldung des Vorfalls dar. Dies kann eine öffentliche Notiz oder eine direkte Antwort sein. Freshservice protokolliert alle Agenten-Kommunikationen mit Timestamps.
Warum es wichtig ist Das Einhalten der First Response SLA ist eine kritische KPI für die Kundenzufriedenheit. Diese Aktivität ermöglicht die Messung und Analyse, wie schnell Agenten auf neue Incidents reagieren. Woher erhalten Identifiziert durch den Timestamp der ersten öffentlichen Notiz oder Antwort, die von einem Agenten im Gesprächsverlauf des Incidents hinzugefügt wurde. Erfassen Filtern Sie den Gesprächsverlauf des Incidents nach dem frühesten Entry eines Agenten. Ereignistyp explicit
	Incident neu zugewiesen	Zeigt an, dass der Incident von einem Agenten oder einer Gruppe an eine andere übertragen wurde. Dies kennzeichnet eine Übergabe im Lösungsprozess. Dieses Event wird abgeleitet, indem nach der ursprünglichen Zuweisung nachfolgende Änderungen in den Feldern 'Agent' oder 'Group' erkannt werden.
Warum es wichtig ist Häufige Neuzuweisungen, oder Handoffs, weisen oft auf Prozessineffizienzen, Wissenslücken oder eine falsche anfängliche Zuweisung hin. Die Analyse dieser Events hilft, Verzögerungen zu identifizieren und zu reduzieren. Woher erhalten Abgeleitet aus dem Aktivitätsprotokoll des Incidents durch Verfolgung jeder Änderung an den Feldern 'Agent' oder 'Group' nach der ersten Zuweisung. Erfassen Erkennung von Änderungen in den Feldern 'Agent' oder 'Group' in der Audit-Historie des Tickets. Ereignistyp inferred
	Incident wiedereröffnet	Tritt auf, wenn ein Incident, der zuvor als 'Resolved' markiert war, wieder in einen offenen Status versetzt wird, typischerweise weil der Benutzer mit der Lösung nicht einverstanden ist. Dies wird durch eine Statusänderung von 'Resolved' zurück zu einem Zustand wie 'Open' oder 'In Progress' abgeleitet.
Warum es wichtig ist Eine hohe Wiedereröffnungsrate deutet auf Probleme mit der Lösungsqualität oder unvollständigen Behebungen hin. Dies ist eine Schlüsselmetrik zur Analyse von Nacharbeit und Agentenleistung. Woher erhalten Abgeleitet aus dem Aktivitätsprotokoll des Incidents durch Erkennung einer Statusänderung von 'Resolved' zu einem aktiven Status. Erfassen Filtern Sie das Activity Log nach einer 'Status'-Änderung von 'Resolved' zu 'Open' oder 'In Progress'. Ereignistyp inferred
	SLA-Ziel verletzt	Dies ist ein berechnetes Event, das auftritt, wenn die verstrichene Zeit für einen Vorfall sein definiertes SLA-Ziel für Reaktion oder Lösung überschreitet. Freshservice verfolgt den SLA-Status intern, und dieses Event kann durch den Vergleich von Timestamps mit SLA-Richtlinien abgeleitet werden.
Warum es wichtig ist Misst direkt die Compliance mit Service-Level-Verpflichtungen. Die Identifizierung, wann und warum Verstöße auftreten, ist essenziell für das SLA Performance Dashboard und die kontinuierliche Verbesserung. Woher erhalten Berechnet durch den Vergleich des Lösungs- oder Antwort-Timestamp mit der fälligen SLA-Zielzeit. Freshservice kennzeichnet Tickets oft als 'SLA violated'. Erfassen Ableitung durch Vergleich des 'Resolved at'-Timestamps mit dem 'Due by'-Timestamp oder wenn sich das Feld 'SLA Status' zu 'Violated' ändert. Ereignistyp calculated
	Status auf 'Ausstehend' geändert	Stellt einen Punkt dar, an dem der Lösungsprozess pausiert wird, typischerweise während auf Informationen vom Benutzer oder einem Drittanbieter gewartet wird. Dies wird durch eine Statusänderung in einen beliebigen 'Pending'-Zustand abgeleitet. Die in diesem Zustand verbrachte Zeit wird oft von den SLA-Berechnungen ausgenommen.
Warum es wichtig ist Die Identifizierung der in Pending States verbrachten Zeit ist entscheidend, um externe Abhängigkeiten und Verzögerungen zu verstehen. Dies hilft, die Arbeitszeit des Agenten von der Wartezeit zu trennen. Woher erhalten Abgeleitet aus dem Aktivitätsprotokoll des Incidents, wenn das Feld 'Status' auf einen Wert wie 'Pending' oder 'Awaiting User Response' aktualisiert wird. Erfassen Filtern Sie das Activity Log nach Statusänderungen in einen beliebigen Pending State und verwenden Sie den zugehörigen Timestamp. Ereignistyp inferred
	Workaround bereitgestellt	Diese Aktivität signalisiert, dass dem Benutzer eine temporäre Lösung oder ein Workaround mitgeteilt wurde, um die Auswirkungen des Vorfalls zu mildern. Die Erfassung erfordert oft eine spezifische Systemkonfiguration, wie z.B. ein dediziertes Kontrollkästchen, einen bestimmten Notiztyp oder eine Keyword-Analyse in den Agentennotizen.
Warum es wichtig ist Dies hilft, die Effektivität von Workarounds bei der Reduzierung von Geschäftsauswirkungen und deren Zusammenhang mit der endgültigen Lösungszeit zu analysieren. Es unterstützt das Dashboard 'Workaround-Effektivitäts-Metriken'. Woher erhalten Dies ist wahrscheinlich kein explizites Event. Es kann durch die Kennzeichnung von Notizen, die Schlüsselwörter wie 'Workaround' enthalten, oder durch die Verwendung eines benutzerdefinierten Checkbox-Feldes 'Workaround Provided', dessen Änderung protokolliert wird, abgeleitet werden. Erfassen Abgeleitet aus einer Änderung in einem benutzerdefinierten Feld oder der Keyword-Analyse von Agentennotizen. Ereignistyp inferred

Extraktionsleitfäden

Wie Sie Ihre Daten aus Freshservice erhalten

Schritte

Auf Freshservice Analytics zugreifen: Melden Sie sich bei Ihrer Freshservice Instanz mit einem Konto an, das Berechtigungen besitzt, um auf Reports zuzugreifen und diese zu erstellen. Navigieren Sie zum Analytics-Modul im Hauptmenü.
Neuen Bericht erstellen: Klicken Sie auf den Neuen Bericht-Button. Geben Sie einen aussagekräftigen Namen an, z. B. „Incident Management Event Log“. Wählen Sie das Incident Management-Modul, wenn Sie aufgefordert werden, eine Datenquelle auszuwählen.
Berichts-Widget auswählen: Im Berichts-Editor fügen Sie ein neues Widget hinzu und wählen den Typ Tabelle. Dies bildet die Grundlage Ihrer Event Log-Daten.
Primäre Datenspalten hinzufügen: Ziehen Sie aus dem Datenquellen-Panel auf der rechten Seite die erforderlichen Felder in die Spaltenkonfiguration der Tabelle. Beginnen Sie mit Incident ID, Created at, Agent, Group, Priority, Severity, Status und Category.
Aktivitätsdaten einbeziehen: Um einzelne Events zu erfassen, müssen Sie Daten aus den Ticket-Aktivitäten verknüpfen oder einbeziehen. Fügen Sie die Activities-Datenquelle zu Ihrem Widget hinzu. Fügen Sie aus dieser Quelle Performed at (für den EventTimestamp) und Activity description oder ähnliche Felder hinzu, die die erfolgte Änderung beschreiben.
Eine berechnete 'ActivityName'-Spalte erstellen: Dies ist der entscheidendste Schritt. Erstellen Sie eine neue berechnete Spalte oder ein Formelfeld. Verwenden Sie verschachtelte IF-Anweisungen oder eine CASE-Funktion, um rohe Aktivitätsdaten in die erforderlichen ActivityName-Werte zu übersetzen. Details zur Logik für jede der 14 Aktivitäten finden Sie im Query-Bereich.
Den 'EventTimestamp' konfigurieren: Erstellen Sie eine weitere berechnete Spalte für den EventTimestamp. Die Logik für diese Spalte sollte den Created at-Timestamp für die Activity 'Incident Reported' und den Performed at-Timestamp der jeweiligen Aktivität für alle anderen Events wählen.
Berichtsfilter anwenden: Konfigurieren Sie die Berichtsfilter, um die Daten einzugrenzen. Legen Sie mindestens einen Datumsbereichsfilter für das Feld 'Created at' fest. Ein Zeitraum der letzten 3 bis 6 Monate wird empfohlen. Sie sollten auch einen Filter hinzufügen, um nur Tickets einzuschließen, bei denen 'Ticket Type' 'Incident' ist.
Bericht ausführen und verfeinern: Führen Sie den Bericht aus, um eine Datenvorschau zu generieren. Überprüfen Sie die Ausgabe, um sicherzustellen, dass die ActivityName- und EventTimestamp-Spalten korrekt gefüllt werden. Passen Sie Formeln und Filter bei Bedarf an.
Bericht speichern und exportieren: Sobald Sie mit der Ausgabe des Berichts zufrieden sind, speichern Sie ihn. Verwenden Sie die Option Exportieren und wählen Sie CSV als Format.
Export planen (optional): Für die laufende Analyse können Sie den Bericht so planen, dass er automatisch ausgeführt und exportiert wird. Richten Sie einen Zeitplan ein (z. B. täglich oder wöchentlich), um die CSV-Datei an Ihre E-Mail oder ein anderes Ziel liefern zu lassen.
Daten für den Upload vorbereiten: Öffnen Sie die exportierte CSV-Datei. Benennen Sie die Spaltenüberschriften um, um dem erforderlichen Schema für ProcessMind zu entsprechen: IncidentId, ActivityName, EventTimestamp, AssignedAgent, AssignedGroup, etc. Fügen Sie die statischen Spalten SourceSystem (mit dem Wert 'Freshservice') und LastDataUpdate (mit dem aktuellen Timestamp) hinzu. Die Datei ist nun zum Upload bereit.

Konfiguration

Analytics Module: Diese Extraktion erfordert Zugriff auf das Freshservice Analytics-Modul, das in höherwertigen Plänen (z. B. Pro, Enterprise) verfügbar ist.
Required Permissions: Ihr Benutzerkonto benötigt eine Rolle mit Berechtigungen zum Erstellen, Bearbeiten und Ausführen von Reports im Analytics Modul.
Date Range: Es ist entscheidend, einen Datumsbereichsfilter für das Incident-Erstellungsdatum festzulegen, um das Datenvolumen zu steuern. Ein gleitender Zeitraum von 3-6 Monaten wird empfohlen, um ein Gleichgewicht zwischen historischem Kontext und Performance zu gewährleisten.
Report Filters: Filtern Sie immer nach 'Ticket Type' gleich 'Incident', um Service Requests oder andere Ticket-Typen von Ihrer Prozessanalyse auszuschließen.
Calculated Fields: Die Methode basiert stark auf der Verwendung von berechneten Feldern (Formeln), um den ActivityName und EventTimestamp für jedes Event abzuleiten. Vertrautheit mit dem Freshservice Formeleditor ist von Vorteil.
Data Volume: Beachten Sie, dass diese Extraktion für jeden Incident mehrere Zeilen (eine für jede Activity) generiert. Bei großen Freshservice Instanzen kann die resultierende CSV-Datei sehr groß werden, was die Berichtsgenerierungszeit und die Exportgeschwindigkeit beeinträchtigt.

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+ sowie die Bibliotheken requests und pandas installiert sind. Sie können diese mit pip installieren: pip install requests pandas.
API-Schlüssel generieren: Melden Sie sich als Administrator bei Ihrer Freshservice-Instanz an. Navigieren Sie zu Ihren Profileinstellungen, indem Sie auf Ihr Profilbild in der oberen rechten Ecke klicken. Gehen 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 in einer Datei namens extract_freshservice_incidents.py auf Ihrem lokalen Computer.
Parameter konfigurieren: Öffnen Sie die Skriptdatei in einem Texteditor. Aktualisieren Sie die Platzhalterwerte für FRESHSERVICE_DOMAIN (z.B. 'yourcompany.freshservice.com'), API_KEY (den Schlüssel, den Sie gerade kopiert haben) und START_DATE_STR (den Beginn Ihres gewünschten Extraktionszeitraums im Format 'JJJJ-MM-TT').
Skriptlogik verstehen: Das Skript ruft zunächst alle Incident-Tickets ab, die nach dem angegebenen Startdatum erstellt wurden. Es durchläuft jede Seite der von der API zurückgegebenen Ergebnisse. Für jedes Ticket führt es einen zweiten API-Aufruf durch, um dessen detaillierte Aktivitätshistorie abzurufen.
Event Log-Generierung: Das Skript verarbeitet die Kerndaten des Tickets und dessen Aktivitätsprotokoll, um Datensätze für jede der 14 erforderlichen Geschäftsaktivitäten zu identifizieren und zu erstellen. Zum Beispiel wird 'Incident Reported' aus dem Erstellungsdatum des Tickets erstellt, während 'Status Changed to In Progress' aus einem spezifischen Eintrag im Aktivitätsprotokoll abgeleitet wird.
Komplexe Events ableiten: Events wie 'SLA Target Breached' werden abgeleitet. Das Skript prüft, ob die Resolution-SLA eines Tickets verletzt wurde. Falls ja, erstellt es ein Event, das mit dem due_by-Datum versehen ist und den Zeitpunkt des Verstoßes markiert.
Skript ausführen: Öffnen Sie ein Terminal oder eine Eingabeaufforderung, navigieren Sie zu dem Verzeichnis, in dem Sie das Skript gespeichert haben, und führen Sie es mit dem Befehl aus: python extract_freshservice_incidents.py.
Ausführung überwachen: Das Skript gibt Fortschrittsinformationen in der Konsole aus, die zeigen, wie viele Tickets verarbeitet wurden. Je nach Anzahl der Tickets und API-Ratenbegrenzungen kann dies einige Zeit in Anspruch nehmen.
Ergebnis überprüfen: Sobald das Skript beendet ist, wird eine CSV-Datei namens freshservice_incident_event_log.csv im selben Verzeichnis generiert. Diese Datei enthält das vollständige Event Log.
Für den Upload vorbereiten: Öffnen Sie die CSV-Datei in einem Tabellenkalkulationsprogramm, um sicherzustellen, dass die Spalten (IncidentId, ActivityName, EventTimestamp, etc.) wie erwartet ausgefüllt sind. Die Datei ist nun bereit für den Upload in ProcessMind oder ein anderes Process Mining-Tool.

Konfiguration

FRESHSERVICE_DOMAIN: Die spezifische Freshservice-URL Ihres Unternehmens, zum Beispiel mycompany.freshservice.com. Dies ist ein erforderlicher Parameter im Skript.
API_KEY: Der persönliche API-Key für einen Benutzer mit ausreichenden Berechtigungen, um alle Incident-Daten zu lesen. Dies ist ein erforderlicher Parameter.
START_DATE_STR: Das Startdatum für die Datenextraktion im Format 'JJJJ-MM-TT'. Es wird empfohlen, für eine aussagekräftige Analyse Daten für einen anfänglichen Zeitraum von 3-6 Monaten zu extrahieren.
PAGE_SIZE: Auf 100 gesetzt, dem von der Freshservice API maximal erlaubten Wert, um die Anzahl der API-Aufrufe zu minimieren und die Leistung zu verbessern. Es wird generell nicht empfohlen, diesen Wert zu ändern.
API Rate Limiting: Das Skript enthält einen einfachen time.sleep(1)-Aufruf nach der Verarbeitung jedes Tickets, um die API Rate Limits von Freshservice einzuhalten. Bei Instanzen mit hohem Datenvolumen muss dieser möglicherweise angepasst werden, um Fehler zu vermeiden.
Required Permissions: Der verwendete API-Key muss zu einem Benutzerkonto gehören (z. B. einem dedizierten Service Account) mit mindestens den Berechtigungen der Rolle 'SD Agent', um sicherzustellen, dass es auf alle notwendigen Ticket-Felder und Activity Logs über verschiedene Service-Desk-Gruppen hinweg 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

Auf Freshservice Analytics zugreifen: Melden Sie sich bei Ihrer Freshservice Instanz mit einem Konto an, das Berechtigungen besitzt, um auf Reports zuzugreifen und diese zu erstellen. Navigieren Sie zum Analytics-Modul im Hauptmenü.
Neuen Bericht erstellen: Klicken Sie auf den Neuen Bericht-Button. Geben Sie einen aussagekräftigen Namen an, z. B. „Incident Management Event Log“. Wählen Sie das Incident Management-Modul, wenn Sie aufgefordert werden, eine Datenquelle auszuwählen.
Berichts-Widget auswählen: Im Berichts-Editor fügen Sie ein neues Widget hinzu und wählen den Typ Tabelle. Dies bildet die Grundlage Ihrer Event Log-Daten.
Primäre Datenspalten hinzufügen: Ziehen Sie aus dem Datenquellen-Panel auf der rechten Seite die erforderlichen Felder in die Spaltenkonfiguration der Tabelle. Beginnen Sie mit Incident ID, Created at, Agent, Group, Priority, Severity, Status und Category.
Aktivitätsdaten einbeziehen: Um einzelne Events zu erfassen, müssen Sie Daten aus den Ticket-Aktivitäten verknüpfen oder einbeziehen. Fügen Sie die Activities-Datenquelle zu Ihrem Widget hinzu. Fügen Sie aus dieser Quelle Performed at (für den EventTimestamp) und Activity description oder ähnliche Felder hinzu, die die erfolgte Änderung beschreiben.
Eine berechnete 'ActivityName'-Spalte erstellen: Dies ist der entscheidendste Schritt. Erstellen Sie eine neue berechnete Spalte oder ein Formelfeld. Verwenden Sie verschachtelte IF-Anweisungen oder eine CASE-Funktion, um rohe Aktivitätsdaten in die erforderlichen ActivityName-Werte zu übersetzen. Details zur Logik für jede der 14 Aktivitäten finden Sie im Query-Bereich.
Den 'EventTimestamp' konfigurieren: Erstellen Sie eine weitere berechnete Spalte für den EventTimestamp. Die Logik für diese Spalte sollte den Created at-Timestamp für die Activity 'Incident Reported' und den Performed at-Timestamp der jeweiligen Aktivität für alle anderen Events wählen.
Berichtsfilter anwenden: Konfigurieren Sie die Berichtsfilter, um die Daten einzugrenzen. Legen Sie mindestens einen Datumsbereichsfilter für das Feld 'Created at' fest. Ein Zeitraum der letzten 3 bis 6 Monate wird empfohlen. Sie sollten auch einen Filter hinzufügen, um nur Tickets einzuschließen, bei denen 'Ticket Type' 'Incident' ist.
Bericht ausführen und verfeinern: Führen Sie den Bericht aus, um eine Datenvorschau zu generieren. Überprüfen Sie die Ausgabe, um sicherzustellen, dass die ActivityName- und EventTimestamp-Spalten korrekt gefüllt werden. Passen Sie Formeln und Filter bei Bedarf an.
Bericht speichern und exportieren: Sobald Sie mit der Ausgabe des Berichts zufrieden sind, speichern Sie ihn. Verwenden Sie die Option Exportieren und wählen Sie CSV als Format.
Export planen (optional): Für die laufende Analyse können Sie den Bericht so planen, dass er automatisch ausgeführt und exportiert wird. Richten Sie einen Zeitplan ein (z. B. täglich oder wöchentlich), um die CSV-Datei an Ihre E-Mail oder ein anderes Ziel liefern zu lassen.
Daten für den Upload vorbereiten: Öffnen Sie die exportierte CSV-Datei. Benennen Sie die Spaltenüberschriften um, um dem erforderlichen Schema für ProcessMind zu entsprechen: IncidentId, ActivityName, EventTimestamp, AssignedAgent, AssignedGroup, etc. Fügen Sie die statischen Spalten SourceSystem (mit dem Wert 'Freshservice') und LastDataUpdate (mit dem aktuellen Timestamp) hinzu. Die Datei ist nun zum Upload bereit.

Konfiguration

Analytics Module: Diese Extraktion erfordert Zugriff auf das Freshservice Analytics-Modul, das in höherwertigen Plänen (z. B. Pro, Enterprise) verfügbar ist.
Required Permissions: Ihr Benutzerkonto benötigt eine Rolle mit Berechtigungen zum Erstellen, Bearbeiten und Ausführen von Reports im Analytics Modul.
Date Range: Es ist entscheidend, einen Datumsbereichsfilter für das Incident-Erstellungsdatum festzulegen, um das Datenvolumen zu steuern. Ein gleitender Zeitraum von 3-6 Monaten wird empfohlen, um ein Gleichgewicht zwischen historischem Kontext und Performance zu gewährleisten.
Report Filters: Filtern Sie immer nach 'Ticket Type' gleich 'Incident', um Service Requests oder andere Ticket-Typen von Ihrer Prozessanalyse auszuschließen.
Calculated Fields: Die Methode basiert stark auf der Verwendung von berechneten Feldern (Formeln), um den ActivityName und EventTimestamp für jedes Event abzuleiten. Vertrautheit mit dem Freshservice Formeleditor ist von Vorteil.
Data Volume: Beachten Sie, dass diese Extraktion für jeden Incident mehrere Zeilen (eine für jede Activity) generiert. Bei großen Freshservice Instanzen kann die resultierende CSV-Datei sehr groß werden, was die Berichtsgenerierungszeit und die Exportgeschwindigkeit beeinträchtigt.

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'

Data Template: Incident Management

Ihr Incident Management Data Template

Incident Management-Attribute

Incident Management-Aktivitäten

Extraktionsleitfäden

Datenexport des Freshservice Analytics Module als CSV

Schritte

Konfiguration

a Beispielabfrage config

Python-Skript-Extraktion via Freshservice REST API

Schritte

Konfiguration

a Beispielabfrage python

Echtzeit-Data Push via Workflow Automator Webhooks

Schritte

Konfiguration

a Beispielabfrage config

Bereit, um loszulegen?

SLA-Verstöße stoppen: Incident Management heute optimieren