> Kontinuierliche Prozessoptimierung > Incident Management > Freshservice > Datenvorlage

Ihr Incident-Management Daten Template

Freshservice

Incident-Management-Attribute (19) Incident-Management-Aktivitäten (14) Extraktionsanleitungen (3)

Ihr Incident-Management Daten 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. Verwenden Sie diese Ressource, um Ihren Datenvorbereitungsprozess zu optimieren.

Empfohlene Attribute zur Erfassung
Wichtige Aktivitäten für das Tracking
Extraktionsanleitung

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

Vorlage herunterladen

Incident-Management-Attribute

Dies sind die empfohlenen Datenfelder, die in Ihr Event Log aufgenommen werden sollten, um eine vollständige Analyse Ihres Incident-Management Prozesses zu ermöglichen.

5 Erforderlich 7 Empfohlen 7 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, Zeitstempels 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 Durchlaufzeiten, die Analyse von Prozessvarianten und die Identifizierung von Engpässen, die spezifisch für einzelne Fälle sind. Ohne einen eindeutige Kennung wäre es unmöglich, zwischen verschiedenen Incidents zu unterscheiden und deren Pfade von der Meldung bis zur Lösung zu analysierenn. Bedeutung Es identifiziert jeden Incident eindeutig und ermöglicht die End-to-End-Verfolgung und Analyse seines Lebenszyklus von der Erstellung bis zur Schließung. Datenquelle 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 den Antrag bearbeitet.es Ereignisse, das zu einem bestimmten Zeitpunkt innerhalb des Incident-Lebenszyklus aufgetreten ist.
Beschreibung Der Aktivitätsname beschreibt einen einzelnen Schritt oder ein Ereignis 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 die Basis für Process Mining, da es die Knoten in der entdeckten Prozessablauf 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 Nacharbeitsschleifen wie häufige Neu-Zuweisungen aufzeigen. Bedeutung Es definiert die Schritte in der Prozessablauf und ermöglicht die Visualisierung und Analyse des Incident-Lösungsflusses, von Engpässe und Abweichungen. Datenquelle 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-Zeitstempel EventTimestamp	Das genaue Datum und die genaue Uhrzeit, zu der den Antrag bearbeitet.ie Aktivität oder den Antrag bearbeitet.as Event stattfand.
Beschreibung Der Event Zeitstempel, 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 Zeitstempel. Dieses Attribut ist maßgeblich für alle zeitbasierten Process-Mining-Analysen. Es wird verwendet, um Ereignisse chronologisch zu ordnen, die Dauer zwischen Aktivitäten zu berechnen, die gesamte Case Durchlaufzeit zu messen und Wartezeiten zu analysierenn. Es ist die Grundlage für den Aufbau von Dashboards, die die SLA-Leistungsfähigkeit, Übergabeverzögerungen und die Gesamtlösungszeiten verfolgen. Bedeutung Es liefert die chronologische Reihenfolge der Ereignisse, was für die Berechnung von Dauern, die Analyse von Durchlaufzeits und das Verständnis der Prozessleistung notwendig ist. Datenquelle Dies wird aus verschiedenen Zeitstempel-Feldern in Freshservice abgeleitet, wie 'created_at', 'updated_at' und Zeitstempels innerhalb der Ticket-Konversation oder den Antrag bearbeitet.er Audit-Logs. Beispiele 2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
	Letzte Datenaktualisierung LastDataUpdate	Der Zeitstempel, der den Antrag bearbeitet.en Zeitpunkt der letzten Aktualisierung oder Extraktion der Daten für diesen Prozess angibt.
Beschreibung Dieses Attribut liefert einen Zeitstempel 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 Ereignisse bezieht, wird aber aus Konsistenzgründen oft auf Event-Ebene mitgeführt. In der Analyse sind diese Informationen wichtig 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. Bedeutung Es Hinweisrmiert Benutzer über die Aktualität der Daten und stellt sicher, dass sie den durch die Analyse abgedeckten Zeitraum verstehen. Datenquelle Dies ist ein MetaDaten-Zeitstempel, 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, in der Regel Freshservice.
Beschreibung Dieses Attribut identifiziert die Herkunft der Daten. Obwohl es in diesem Kontext durchgängig Freshservice sein wird, ist es ein wichtiges Feld in Umgebungen, in denen Daten aus mehreren Systemen für eine vollständige Prozessansicht kombiniert werden könnten. Die Aufnahme des Attributs Quellsystem ist eine Best Practice für Daten Governance und Nachvollziehbarkeit. Es stellt ... sicher 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. Bedeutung Es stellt ... sicher die Datenrückverfolgbarkeit und Governance, indem es den Ursprung der Incident-Management Daten klar identifiziert. Datenquelle Dies ist in der Regel 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 maßgeblich für die Trendanalyse. Dieses Attribut wird im Incident Categorization Accuracy Dashboard verwendet, um zu analysierenn, 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. Bedeutung Es ermöglicht die Analyse von Incident-Trends und hilft festzustellen, ob eine Neine Kategorisierung Lösungsverzögerungen verursacht. Datenquelle 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 `Hardware``Software`NetzwerkproblemKontozugang
	Incident-Schweregrad IncidentSeverity	Der Schweregrad des Vorfalls, der den Antrag bearbeitet.essen 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. Bedeutung Es misst die geschäftlichen Auswirkungen eines Incidents und ermöglicht eine Analyse, die sich auf die Minderung der schädlichsten Probleme konzentriert. Datenquelle 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 Prozessablauf bilden, wie z.B. der Übergang von 'In Progress' zu 'Pending' oder von 'Resolved' zu 'Closed'. Dieses Attribut ist die Basis 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 wichtig für die Definition der Start- und Endpunkte für Zykluszeitberechnungen. Bedeutung Es verfolgt den Fortschritt des Incidents durch seinen Lebenszyklus und hilft, Phasen zu identifizieren, in denen Verzögerungen häufig sind. Datenquelle Verfügbar in der Freshservice Tickets API als Feld 'status'. Die Werte sind numerisch. Beispiele OffenIn BearbeitungPendingGelöstGeschlossen
	SLA-Zielzeit für die Lösung ResolutionSlaTargetTime	Der Zeitstempel, 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 in der Regel von Faktoren wie der Priorität abhängt. Diese Zielzeit ist wichtig für die Berechnung des KPI 'SLA-Quote' und als Grundlage für das SLA Leistungsfähigkeit Dashboard. Durch den Vergleich des tatsächlichen Lösungs-Zeitstempels mit diesem Ziel können wir feststellen, ob ein Vorfall pünktlich gelöst oder seine SLA verletzt wurde. Dies ist wesentlich für die Messung der Service-Level-Compliance. Bedeutung 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. Datenquelle 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
	Vorfall-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 in der Regel 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 Durchlaufzeit und SLA-Einhaltung oft nach Priorität, um Support-Managern konkrete Optimierungspotenziale zu liefern. Bedeutung Es hilft, die Analyse auf die kritischsten Incidents zu priorisieren und ist unerlässlich für die Bewertung der SLA-Leistung und Ressourcenzuweisung. Datenquelle 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
	Zugewiesene Gruppe AssignedGroup	Die Supportgruppe oder den Antrag bearbeitet.as Team, das dem Vorfall aktuell zugewiesen ist.
Beschreibung Die zugewiesene Gruppe zeigt an, welches Team, wie z.B. 'Level 1 Support', 'Network Team' oder 'Datenbase Admins', für den Incident verantwortlich ist. Änderungen dieses Attributs bedeuten eine Eskalation oder Übertragung zwischen verschiedenen Funktionsteams. Die Analyse der zugewiesenen Gruppe ist maßgeblich, 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. Bedeutung Es verfolgt, welches Team verantwortlich ist, was wichtig ist für die Analyse von Übergaben, Eskalationen und Verzögerungen zwischen Teams. Datenquelle 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 Desk`NetzwerkbetriebInfrastruktur-Support
	Zugewiesener Agent AssignedAgent	Der Name oder den Antrag bearbeitet.ie 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 Leistungsfähigkeit-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. Bedeutung Es ermöglicht die Analyse der Agentenleistung, der Workload-Verteilung und der Auswirkungen von Agenten-Übergaben auf die Lösungszeiten. Datenquelle 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
	`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 maßgeblich 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. Bedeutung Es ermöglicht proaktives Problemmanagement, indem es hilft, die zugrunde liegenden Ursachen wiederkehrender Incidents zu identifizieren und zu eliminieren. Datenquelle 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
	Abteilung des Anfragenden RequestersDepartment	Die Abteilung, der den Antrag bearbeitet.er Benutzer angehört, der den Antrag bearbeitet.en Incident gemeldet hat.
Beschreibung Dieses Attribut identifiziert die Geschäftsabteilung des Anfragenden, z.B. Vertrieb, Finanzen oder IT. Diese Informationen stammen in der Regel 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. Bedeutung Es liefert geschäftlichen Kontext und ermöglicht die Analyse von Incident-Trends und deren Auswirkungen auf bestimmte Abteilungen. Datenquelle 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
	Handoff-Anzahl 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, Neine 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. Bedeutung Es quantifiziert Nacharbeit und Neuzuweisungen und hilft so, Ineffizienzen zu identifizieren, die durch Neine Weiterleitung oder Wissenslücken verursacht werden. Datenquelle 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
	Meldekanal ReportingChannel	Die Methode oder den Antrag bearbeitet.er 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 Prozessoptimierungen aufzuzeigen. So werden beispielsweise über das Portal gemeldete Vorfälle oft schneller gelöst, da sie von Anfang an strukturiertere Informationen enthalten können. Bedeutung Es hilft, die effizientesten Meldekanäle zu identifizieren und zeigt Möglichkeiten zur Verbesserung des Incident-Aufnahmeprozesses auf. Datenquelle Verfügbar in der Freshservice Tickets API als Feld 'source'. Die Werte sind numerisch. Beispiele E-MailPortalTelefonChat
	SLA verletzt? IsSlaBreached	Eine berechnete Kennzeichnung, die Ja ist, wenn der Incident nicht innerhalb der den Antrag bearbeitet.efinierten 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-Zeitstempels mit der ResolutionSlaTargetTime abgeleitet. Dieses Flag ist ein direkter Input für den KPI 'SLA-Quote' und das SLA Leistungsfähigkeit Dashboard. Es vereinfacht die Analyse, indem es ein klares, binäres Ergebnis für die SLA-Leistungsfähigkeit 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. Bedeutung Es misst direkt die SLA-Compliance für jeden Incident, was die Berechnung der Gesamt-Einhalteraten und die Identifizierung von Problembereichen vereinfacht. Datenquelle Dies ist ein berechnetes Feld, das während der Datentransformation durch den Vergleich des Zeitstempel von 'Incident Resolved' mit dem Feld 'ResolutionSlaTargetTime' abgeleitet wird. Beispiele JaNein
	Wiedereröffnet IsReopened	Eine berechnete Kennzeichnung, die Ja 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 Ja 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 maßgeblich 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. Bedeutung Es identifiziert Fehler im Lösungsprozess und hebt Incidents hervor, bei denen die anfängliche Lösung ineffektiv war und zu Nacharbeit führte. Datenquelle Dies ist ein berechnetes Feld, das aus der Abfolge von Aktivitäten im Event Log abgeleitet wird. Es ist Ja, 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 JaNein
	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. Bedeutung Es hilft, die Effektivität temporärer Workarounds bei der Reduzierung der Incident-Auswirkungen und der Beschleunigung der wahrgenommenen Lösung zu messen. Datenquelle Dies ist in der Regel ein benutzerdefiniertes Boolean (Checkbox)-Feld. Seine Existenz muss in der Freshservice 'Ticket Fields' Konfiguration überprüft werden. Beispiele JaNein

Erforderlich Empfohlen Optional

Incident-Management-Aktivitäten

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

7 Empfohlen 7 Optional

	Aktivität	Beschreibung
	`Incident` gemeldet	Markiert die Erstellung eines neuen Incident-Datensatzes in Freshservice. Dies ist der Startpunkt des Incident-Lebenszyklus, in der Regel 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-Zeitstempel protokolliert.
Bedeutung 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 die Basis für die Messung der Gesamtzykluszeiten und der SLA-Einhaltung. Datenquelle Erfasst aus dem Erstellungs-Zeitstempel der Incident-Tabelle. Freshservice protokolliert dies explizit für jedes neue Ticket. Erfassen Verwenden Sie den 'Created at'-Zeitstempel aus dem Haupt-Incident-Datensatz. Ereignistyp explicit
	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.
Bedeutung Die Verfolgung von Zuweisungen ist maßgeblich für die Messung der ersten Reaktionszeiten und die Identifizierung von Engpässe im Zuweisungsprozess. Sie hilft zu analysierenn, wie effizient Incidents an das richtige Team weitergeleitet werden. Datenquelle Abgeleitet aus dem ersten Eintrag im Aktivitätsprotokoll des Incidents, der den Antrag bearbeitet.as Feld 'Group' füllt oder ändert. Erfassen Identifizieren Sie den ersten Zeitstempel, 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 den Antrag bearbeitet.ie SLA-Uhr stoppt.
Bedeutung 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. Datenquelle Abgeleitet aus dem Aktivitätsprotokoll des Incidents durch Identifizierung, wann das Feld 'Status' auf 'Resolved' aktualisiert wird. Erfassen Verwenden Sie den Zeitstempel aus dem Aktivitäten-Log-Eintrag für die Statusänderung zu 'Resolved'. Ereignistyp inferred
	Incident geschlossen	Stellt den finalen, formellen Abschluss des Incident-Datensatzes dar. Dies geschieht in der Regel 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.
Bedeutung Diese Aktivität ist der den Antrag bearbeitet.efinitive Endpunkt des Prozesses. Die Gesamtzeit bis zu diesem Event stellt die vollständige Vorfall-Lebenszyklusdauer dar, einschließlich etwaiger Benutzerbestätigungsphasen. Datenquelle Abgeleitet aus dem Aktivitätsprotokoll des Incidents durch Identifizierung, wann das Feld 'Status' auf 'Closed' aktualisiert wird. Erfassen Verwenden Sie den Zeitstempel aus dem Aktivitäten-Log-Eintrag für die Statusänderung zu 'Closed'. 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.
Bedeutung 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. Datenquelle Erfasst vom Zeitstempel, zu dem eine Lösungsnotiz zum Incident hinzugefügt wurde, was in der Konversationshistorie protokolliert wird. Erfassen Identifizieren Sie den Zeitstempel 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.
Bedeutung 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 maßgeblich, um den Lösungsaufwand zu verstehen. Datenquelle 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 Zeitstempel. Ereignistyp inferred
	Vorfall 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.
Bedeutung 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. Datenquelle Abgeleitet aus dem Aktivitätsprotokoll des Incidents, das alle Aktualisierungen des Feldes 'Priority' verfolgt. Erfassen Verwenden Sie Zeitstempels aus dem Audit Log, wo der Wert des Feldes 'Priority' festgelegt oder geändert wurde. 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.
Bedeutung 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 maßgeblich für Agentenleistungs-Dashboards. Datenquelle Verfolgt durch Änderungen am Feld 'Agent' im Aktivitäten-Log des Incidents oder Audit-Trail. Erfassen Identifizieren Sie Zeitstempels, 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-Mitteilungen mit Zeitstempels.
Bedeutung Das Einhalten der First Response SLA ist eine kritischer KPI für die Kundenzufriedenheit. Diese Aktivität ermöglicht die Messung und Analyse, wie schnell Agenten auf neue Incidents reagieren. Datenquelle Identifiziert durch den Zeitstempel 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.
Bedeutung Häufige Neuzuweisungen, oder Übergaben, weisen oft auf Prozessineffizienzen, Wissenslücken oder eine Neine anfängliche Zuweisung hin. Die Analyse dieser Ereignisse hilft, Verzögerungen zu identifizieren und zu reduzieren. Datenquelle 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, in der Regel 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.
Bedeutung 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. Datenquelle 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 Zeitstempels mit SLA-Richtlinien abgeleitet werden.
Bedeutung Misst direkt die Compliance mit Service-Level-Verpflichtungen. Die Identifizierung, wann und warum Verstöße auftreten, ist wichtig für das SLA Leistungsfähigkeit Dashboard und die kontinuierliche Verbesserung. Datenquelle Berechnet durch den Vergleich des Lösungs- oder Antwort-Zeitstempel mit der fälligen SLA-Zielzeit. Freshservice kennzeichnet Tickets oft als 'SLA violated'. Erfassen Ableitung durch Vergleich des 'Resolved at'-Zeitstempels mit dem 'Due by'-Zeitstempel 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, in der Regel 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.
Bedeutung Die Identifizierung der in Pending States verbrachten Zeit ist maßgeblich, um externe Abhängigkeiten und Verzögerungen zu verstehen. Dies hilft, die Arbeitszeit des Agenten von der Wartezeit zu trennen. Datenquelle Abgeleitet aus dem Aktivitätsprotokoll des Incidents, wenn das Feld 'Status' auf einen Wert wie 'Pending' oder 'Awaiting Benutzer Response' aktualisiert wird. Erfassen Filtern Sie das Activity Log nach Statusänderungen in einen beliebigen Pending State und verwenden Sie den zugehörigen Zeitstempel. 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.
Bedeutung Dies hilft, die Effektivität von Workarounds bei der Reduzierung von Geschäftsauswirkungen und deren Zusammenhang mit der endgültigen Lösungszeit zu analysierenn. Es unterstützt das Dashboard 'Workaround-Effektivitäts-Metriken'. Datenquelle Dies ist wahrscheinlich kein explizites Event. Es kann durch die Kennzeichnung von Notizen, die Schlüsselwörter wie 'Workaround' enthalten, oder den Antrag bearbeitet.urch die Verwendung eines benutzerdefinierten Checkbox-Feldes 'Workaround Provided', dessen Änderung protokolliert wird, abgeleitet werden. Erfassen Abgeleitet aus einer Änderung in einem benutzerdefinierten Feld oder den Antrag bearbeitet.er Keyword-Analyse von Agentennotizen. Ereignistyp inferred

Extraktionsanleitungen

Wie Sie Ihre Daten aus Freshservice erhalten

Schritte

Auf Freshservice Analysen 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 Analysen-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 Ereignisse zu erfassen, müssen Sie Daten aus den Ticket-Aktivitäten verknüpfen oder einbeziehen. Fügen Sie die Aktivitäten-Datenquelle zu Ihrem Widget hinzu. Fügen Sie aus dieser Quelle Performed at (für den EventZeitstempel) und Activity description oder ähnliche Felder hinzu, die die erfolgte Änderung beschreiben.
Eine berechnete 'ActivityName'-Spalte erstellen: Dies ist der wichtigste Schritt. Erstellen Sie eine neue berechnete Spalte oder ein Formelfeld. Verwenden Sie verschachtelte IF-Anweisungen oder eine CASE-Funktion, um 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 'EventZeitstempel' konfigurieren: Erstellen Sie eine weitere berechnete Spalte für den EventZeitstempel. Die Logik für diese Spalte sollte den Created at-Zeitstempel für die Activity 'Incident Reported' und den Performed at-Zeitstempel der jeweiligen Aktivität für alle anderen Ereignisse 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 Typ' '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 EventZeitstempel-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, EventZeitstempel, AssignedAgent, AssignedGroup, etc. Fügen Sie die statischen Spalten (SourceSystem) (mit dem Wert 'Freshservice') und LastDatenUpdate (mit dem aktuellen Zeitstempel) hinzu. Die Datei ist nun zum Upload bereit.

Konfiguration

Analysen Module: Diese Extraktion erfordert Zugriff auf das Freshservice Analysen-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 Analysen Modul.
Date Range: Es ist maßgeblich, 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 Leistungsfähigkeit zu sicherstellen.
Report Filters: Filtern Sie immer nach 'Ticket Typ' gleich 'Incident', um Service Requests oder andere Ticket-Typn von Ihrer Prozessanalyse auszuschließen.
Calculated Fields: Die Methode basiert stark auf der Verwendung von berechneten Feldern (Formeln), um den ActivityName und EventZeitstempel für jedes Event abzuleiten. Vertrautheit mit dem Freshservice Formeleditor ist von Vorteil.
Daten 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 Resultate. 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 Ereignisse ableiten: Ereignisse 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, bewältigen 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 FortschrittsHinweisrmationen 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, EventZeitstempel, 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 Analysen 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 Analysen-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 Ereignisse zu erfassen, müssen Sie Daten aus den Ticket-Aktivitäten verknüpfen oder einbeziehen. Fügen Sie die Aktivitäten-Datenquelle zu Ihrem Widget hinzu. Fügen Sie aus dieser Quelle Performed at (für den EventZeitstempel) und Activity description oder ähnliche Felder hinzu, die die erfolgte Änderung beschreiben.
Eine berechnete 'ActivityName'-Spalte erstellen: Dies ist der wichtigste Schritt. Erstellen Sie eine neue berechnete Spalte oder ein Formelfeld. Verwenden Sie verschachtelte IF-Anweisungen oder eine CASE-Funktion, um 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 'EventZeitstempel' konfigurieren: Erstellen Sie eine weitere berechnete Spalte für den EventZeitstempel. Die Logik für diese Spalte sollte den Created at-Zeitstempel für die Activity 'Incident Reported' und den Performed at-Zeitstempel der jeweiligen Aktivität für alle anderen Ereignisse 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 Typ' '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 EventZeitstempel-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, EventZeitstempel, AssignedAgent, AssignedGroup, etc. Fügen Sie die statischen Spalten (SourceSystem) (mit dem Wert 'Freshservice') und LastDatenUpdate (mit dem aktuellen Zeitstempel) hinzu. Die Datei ist nun zum Upload bereit.

Konfiguration

Analysen Module: Diese Extraktion erfordert Zugriff auf das Freshservice Analysen-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 Analysen Modul.
Date Range: Es ist maßgeblich, 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 Leistungsfähigkeit zu sicherstellen.
Report Filters: Filtern Sie immer nach 'Ticket Typ' gleich 'Incident', um Service Requests oder andere Ticket-Typn von Ihrer Prozessanalyse auszuschließen.
Calculated Fields: Die Methode basiert stark auf der Verwendung von berechneten Feldern (Formeln), um den ActivityName und EventZeitstempel für jedes Event abzuleiten. Vertrautheit mit dem Freshservice Formeleditor ist von Vorteil.
Daten 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'

Ihr Incident-Management Daten Template

Ihr Incident-Management Daten Template

Incident-Management-Attribute

Incident-Management-Aktivitäten

Extraktionsanleitungen

Datenexport des Freshservice Analysen Module als CSV

Schritte

Konfiguration

a Beispielabfrage config

`Python`-Skript-Extraktion via `Freshservice REST API`

Schritte

Konfiguration

a Beispielabfrage python

Echtzeit-Daten Push via Workflow Automator Webhooks

Schritte

Konfiguration

a Beispielabfrage config

Bereit, um loszulegen?

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

Ihr Incident-Management Daten Template

Ihr Incident-Management Daten Template

Incident-Management-Attribute

Incident-Management-Aktivitäten

Extraktionsanleitungen

Datenexport des Freshservice Analysen Module als CSV

Schritte

Konfiguration

a Beispielabfrage config

`Python`-Skript-Extraktion via `Freshservice REST API`

Schritte

Konfiguration

a Beispielabfrage python

Echtzeit-Daten Push via Workflow Automator Webhooks

Schritte

Konfiguration

a Beispielabfrage config

Ihre Privatsphäre ist uns wichtig

Bereit, um loszulegen?

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