> Kontinuierliche Prozessoptimierung > Service Requestnnmanagement > Freshservice > Datenvorlage

Ihre Service Request Management Daten-Template

Freshservice

Attribute im Service Request Management (19) Aktivitäten im Service Request Management (15) Extraktionsanleitungen (3)

Ihre Service Request Management Daten-Template

Diese Datenvorlage bietet eine vollständige Anleitung zur Sammlung der notwendigen Daten für die Analyse Ihres Service-Requestnnmanagement-Prozesses. Es beschreibt die wesentlichen Attribute, wichtige Aktivitäten zur Verfolgung und praktische Hinweise zur Extraktion dieser Informationen aus Ihren Quellsystemen. Verwenden Sie diese Ressource, um einen leistungsstarken Event Log für eine detaillierte Prozessanalyse zu erstellen.

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

Attribute im Service Request Management

Dies sind die empfohlenen Datenfelder, die Sie in Ihr Event Log (Event Log) aufnehmen sollten, um eine vollständige Analyse Ihres Service-Requestnnmanagements durchzuführen.

5 Erforderlich 5 Empfohlen 9 Optional

	Name	Beschreibung
	Aktivitätsname ActivityName	Der Name des Ereignisse oder den Antrag bearbeitet.er Aufgabe, die zu einem bestimmten Zeitpunkt für eine Service-Requestn aufgetreten ist.
Beschreibung Der Aktivitätsname beschreibt einen spezifischen Schritt oder ein Event innerhalb des Lebenszyklus der Service-Requestn. Diese Aktivitäten werden aus System-Audit-Logs, Statusänderungen oder spezifischen Benutzeraktionen extrahiert, wie z.B. 'Anfrage Agent zugewiesen', 'Notiz hinzugefügt' oder 'Service-Requestn gelöst'. Dieses Attribut ist maßgeblich für die Erstellung der Prozessablauf, die den Fluss der Service-Requestnn visuell darstellt. Durch die Analyse der Reihenfolge und Häufigkeit verschiedener Aktivitäten können Organisationen den tatsächlichen Prozess verstehen, Engpässe zwischen Schritten identifizieren, Aktivitätsdauern messen und nicht-konforme oder ineffiziente Prozessvarianten erkennen. Bedeutung Dieses Attribut definiert die Schritte in der Prozessablauf und ermöglicht die Visualisierung und Analyse des Service-Requestnn-Workflows. Datenquelle Generiert aus den 'Aktivitäten' oder 'Audits', die einem Ticket in Freshservice zugeordnet sind. Dies erfordert oft Transformationslogik, um System-Ereignisse auf anwenderfreundliche Aktivitätsnamen abzubilden. Beispiele Service-Requestn erstelltAnfrage einem Agenten zugewiesenService-Requestn gelöstService-Requestn geschlossen
	Ereigniszeit EventTime	Der genaue Zeitstempel, wann die Aktivität stattfand.
Beschreibung Die Event Time erfasst Datum und Uhrzeit, zu der eine bestimmte Aktivität für eine Service-Requestn aufgezeichnet wurde. Dieser Zeitstempel ist die Basis für die korrekte Reihenfolge von Ereignisse und die Berechnung der Dauer zwischen ihnen. Im Process Mining wird dieses Attribut verwendet, um die Aktivitäten für jeden Case zu ordnen und bildet die Grundlage für alle zeitbasierten Analysen. Es wird zur Berechnung von Durchlaufzeits, Wartezeiten zwischen Aktivitäten und der Einhaltung von Service Level Agreements (SLAs) geverwendet. Präzise Zeitstempel sind wichtig für die Identifizierung von Engpässen und das Verständnis der Prozess-Performance. Bedeutung Dieser Zeitstempel ordnet Ereignisse chronologisch und ist die Grundlage für alle Leistungsanalysen, einschließlich Durchlaufzeit und Engpasserkennung. Datenquelle Dies entspricht dem Erstellungs-Zeitstempel einer Aktivität oder eines Audit-Log-Eintrags innerhalb von Freshservice. Beispiele 2023-10-26T10:00:00Z2023-10-26T11:35:10Z2023-10-27T14:20:05Z
	Service-Requestn-ID ServiceRequestId	Die eindeutige Kennung für jede Service-Requestn.
Beschreibung Die Service Request ID ist eine eindeutige Nummer oder ein Code, der jeder neuen Service-Requestn in Freshservice zugewiesen wird. Sie dient als Primärschlüssel zur Verfolgung des gesamten Lebenszyklus der Anfrage, von der Erstellung bis zum Abschluss. Im Process Mining ist diese ID wesentlich, da sie als Case-ID fungiert. Alle zugehörigen Ereignisse, wie Statusänderungen, Agentenzuweisungen und Notizen, werden mithilfe dieses Identifikators verknüpft. Die Analyse des Weges jeder Service Request ID ermöglicht eine vollständige End-to-End-Visualisierung des Prozesses, die Identifizierung gängiger Pfade und die Erkennung von Abweichungen oder Engpässen, die einzelne Fälle betreffen. Bedeutung Dies ist die zentrale Case-ID, die alle zugehörigen Ereignisse verbindet und es ermöglicht, den End-to-End-Prozess einer einzelnen Service-Requestn zu verfolgen. Datenquelle Dies ist ein primäres Feld des Ticket-Objekts in Freshservice. Es ist in der Benutzeroberfläche sichtbar und über die Freshservice API verfügbar. Beispiele SR-12943SR-13501SR-14011
	Letzte Datenaktualisierung LastDataUpdate	Zeitstempel, der angibt, wann die Daten zuletzt aus dem Quellsystem aktualisiert wurden.
Beschreibung Dieses Attribut erfasst Datum und Uhrzeit der letzten Extraktion oder Aktualisierung des Datensatzes aus Freshservice. Es gibt Aufschluss über die Aktualität der analysierten Daten. Für jede Prozessanalyse ist die Aktualität der Daten wichtig. Dieser Zeitstempel hilft Benutzern zu verstehen, ob sie die aktuellsten Informationen betrachten, was für zeitnahe operative Entscheidungen und das Vertrauen in die aus der Analyse gewonnenen Erkenntnisse notwendig ist. Bedeutung Informiert Benutzer über die Aktualität der Daten und stellt sicher, dass Analysen und Entscheidungen auf aktuellen Informationen basieren. Datenquelle Dieser Wert wird während des Datenextraktions- und Transformationsprozesses (ETL) generiert und dem Datensatz hinzugefügt. Beispiele 2024-05-21T02:00:00Z2024-05-20T02:00:00Z
	Quellsystem SourceSystem	Identifiziert das System, aus dem die Daten extrahiert wurden.
Beschreibung Dieses Attribut spezifiziert das Ursprungssystem für die ProzessDaten, welches in diesem Fall Freshservice ist. Es ist besonders nützlich in Umgebungen, in denen Daten aus mehreren Systemen für eine vollständige Prozessansicht konsolidiert werden. Obwohl es in einer Einzel-System-Analyse redundant erscheinen mag, ist es eine bewährte Methode, dieses Attribut für zukünftige Skalierbarkeit und Daten Governance einzuschließen. Es stellt ... sicher Klarheit über die Datenherkunft und hilft bei der Verwaltung von Datenintegrations-Pipelines. Bedeutung Gewährleistet Datenherkunft und Nachvollziehbarkeit, was wichtig ist beim Kombinieren von Daten aus mehreren Systemen oder für Daten Governance-Zwecke. Datenquelle Dies ist in der Regel ein statischer Wert, der während des Datenextraktions- und Transformationsprozesses (ETL) hinzugefügt wird. Beispiele FreshserviceFreshservice-API-v2
	Priorität Priority	Das Prioritätslevel der Service-Requestn, z.B. Niedrig, Mittel, Hoch oder Dringend.
Beschreibung Die Priorität gibt die Wichtigkeit und Dringlichkeit einer Service-Requestn an, die oft die Zielbearbeitungszeit und die zugewiesenen Ressourcen bestimmt. Die Priorität kann automatisch basierend auf Regeln oder manuell von Agenten festgelegt werden. Im Process Mining ist Priorität eine kritische Dimension für die Analyse. Sie wird verwendet, um Anfragen zu segmentieren, um Prozessflüsse und Leistungsfähigkeit für hoch- versus niedrigpriorisierte Elemente zu vergleichen. Dies ist wichtig für die SLA-Compliance-Analyse und um zu verstehen, ob die Priorisierung in der Triage-Phase effektiv und schnell erfolgt. Bedeutung Wesentlich für die SLA-Compliance-Analyse und um zu verstehen, ob Anfragen gemäß ihrer geschäftlichen Auswirkungen priorisiert und bearbeitet werden. Datenquelle Verfügbar als Feld 'Priorität' im Ticket-Objekt in Freshservice. Beispiele NiedrigMittelHochDringend
	Serviceart ServiceType	Der spezifische Typ oder den Antrag bearbeitet.ie Kategorie des angefragten Dienste.
Beschreibung Der Servicetyp klassifiziert die Anfrage basierend auf der Art des benötigten Dienste, wie 'Neue Hardware anfordern', 'Softwarezugriff' oder 'Passwort zurücksetzen'. Dies ist oft mit dem vom Benutzer ausgewählten Servicekatalogartikel verknüpft. Dieses Attribut ermöglicht die Segmentierung von Service-Requestnn, um Prozesse und Leistung über verschiedene Servicetypen hinweg zu vergleichen. Es ist wesentlich für die Berechnung von KPIs wie 'Durchschnittliche Aktivitätsanzahl pro Servicetyp', was hilft, zu identifizieren, welche Dienste komplexer oder Ressourcenintensiver sind. Diese Analyse kann Bemühungen zur Prozessvereinfachung und Automatisierung für spezifische Servicetypen vorantreiben. Bedeutung Ermöglicht den Vergleich von Prozessabläufen und Komplexität über verschiedene Anfragekategorien hinweg und hilft so, Bereiche für Standardisierung oder Automatisierung zu identifizieren. Datenquelle Dies entspricht oft der 'Kategorie', dem 'Element' oder einem benutzerdefinierten Feld auf dem Ticketobjekt in Freshservice, abhängig von der Konfiguration. Beispiele Onboarding neuer MitarbeiterSoftwarelizenzanfrageVPN-Zugang
	Status Status	Der aktuelle Status der Service-Requestn in ihrem Lebenszyklus.
Beschreibung Das Statusfeld repräsentiert den Zustand der Service-Requestn zu einem bestimmten Zeitpunkt, z.B. 'Offen', 'Ausstehend', 'Gelöst' oder 'Geschlossen'. Statusänderungen sind oft die Hauptquelle für Aktivitäten im Process Mining. Die Analyse des Status bietet Kontext zum Prozessfluss und hilft zu verstehen, wie viel Zeit Anfragen in bestimmten Zuständen verbringen. Eine lange Dauer im Status 'Ausstehend' könnte beispielsweise auf einen Engpass hindeuten, bei dem auf Informationen des Anfragenden oder externen Anbieters gewartet wird. Es ist ein Schlüsselattribut zur Definition der Start- und Endpunkte verschiedener Prozessphasen. Bedeutung Bietet wichtigen Kontext für jedes Event und hilft, die in verschiedenen Zuständen wie 'Offen' oder 'Ausstehend' verbrachte Zeit zu messen, um Verzögerungen zu identifizieren. Datenquelle Verfügbar als Feld 'Status' im Ticket-Objekt in Freshservice. Beispiele OffenPendingGelöstGeschlossen
	Zugewiesener Agent AssignedAgent	Der Name des einzelnen Agenten, der aktuell der Service-Requestn zugewiesen ist.
Beschreibung Dieses Attribut identifiziert den spezifischen Support-Agenten, der zu einem bestimmten Zeitpunkt für die Bearbeitung der Service-Requestn verantwortlich ist. Agentenzuweisungen können sich während des Lebenszyklus einer Anfrage ändern. Die Analyse des zugewiesenen Agenten ist maßgeblich für das Verständnis der Agentenleistung und der Arbeitslastverteilung. Sie ermöglicht die Berechnung von KPIs wie der den Antrag bearbeitet.urchschnittlichen Lösungszeit pro Agent, der Anzahl aktiver Anfragen und der Neuzuweisungsraten. Dies hilft, leistungsstärksten Agenten, Agenten, die zusätzliche Schulungen benötigen, und Ungleichgewichte in der Arbeitslastverteilung zu identifizieren. Bedeutung Ermöglicht die Analyse der Agentenarbeitslast, Leistung und des Einflusses von Neuzuweisungen auf die Bearbeitungszeiten. Datenquelle Verfügbar als Feld 'Agent' oder 'Bearbeiter' im Ticket-Objekt in Freshservice. Beispiele Alice JohnsonRobert SmithNicht zugewiesen
	Zugewiesenes Team AssignedTeam	Das Supportteam oder den Antrag bearbeitet.ie Gruppe, die für die Bearbeitung der Service-Requestn zuständig ist.
Beschreibung Dieses Attribut gibt die funktionale Gruppe oder den Antrag bearbeitet.as Team an, z.B. 'IT Support Level 2' oder 'Hardware Beschaffung', das für die Service-Requestn verantwortlich ist. Eine Anfrage kann einem Team zugewiesen werden, bevor sie von einem einzelnen Agenten bearbeitet wird. Die Analyse nach zugewiesenem Team hilft, die Teamleistung und -arbeitslast zu verstehen und Engpässe in bestimmten funktionalen Bereichen zu identifizieren. Sie ist maßgeblich für die Bewertung, wie effizient verschiedene Teams Anfragen bearbeiten und für die Optimierung der Ressourcenallokation in der gesamten Support-Organisation. Bedeutung Ermöglicht Leistungs- und Arbeitslastanalysen auf Team- oder Gruppenebene, was für das Ressourcenmanagement und die Identifizierung funktionaler Engpässe notwendig ist. Datenquelle Verfügbar als Feld 'Gruppe' im Ticket-Objekt in Freshservice. Beispiele `Service Desk`NetzwerkbetriebAnwendungssupport
	Abteilung des Antragstellers RequestorDepartment	Die Abteilung, zu der den Antrag bearbeitet.er Anfragende gehört.
Beschreibung Dieses Attribut spezifiziert die organisatorische Abteilung des Benutzers, der den Antrag bearbeitet.ie Service-Requestn eingereicht hat, wie 'Vertrieb', 'Finanzen' oder 'Personalwesen'. Diese Informationen stammen in der Regel aus dem Benutzerprofil im System. Die Analyse der Prozessleistung nach Abteilung ist eine gängige Anforderung. Sie kann hervorheben, ob bestimmte Abteilungen längere Lösungszeiten erleben oder einzigartige Prozessbedürfnisse haben. Diese Einsicht kann die Ressourcenallokation, Schulungsinitiativen oder den Antrag bearbeitet.ie Schaffung abteilungsspezifischer Serviceangebote beeinflussen. Bedeutung Ermöglicht die Segmentierung des Prozesses nach Geschäftsbereichen, um abteilungsspezifische Probleme oder Leistungsvariationen zu identifizieren. Datenquelle Diese Information ist über das Profil des Anfragenden verknüpft. Sie kann in einem Standardfeld 'Abteilung' oder einem benutzerdefinierten Benutzerfeld in Freshservice enthalten sein. Beispiele FinanzenMarketingInformationstechnologie
	Antragsteller Requestor	Der Benutzer, der den Antrag bearbeitet.ie Service-Requestn eingereicht hat.
Beschreibung Dieses Attribut identifiziert die Person, üblicherweise einen Mitarbeiter, die die Service-Requestn initiiert hat. Es bietet Kontext darüber, wer den Service Desk verwendet und welche Bedürfnisse sie haben. Obwohl nicht immer eine primäre Dimension für die Prozessflussanalyse, kann die Analyse nach Anfragendem oder den Antrag bearbeitet.er zugehörigen Abteilung Muster aufdecken. Zum Beispiel könnte sie zeigen, dass eine bestimmte Abteilung häufig unvollständige Anfragen einreicht, was auf einen Bedarf an gezielter Schulung hindeutet. Es ist auch wesentlich für jede Analyse, die sich auf die Customer Experience konzentriert. Bedeutung Bietet Kontext zum Benutzer, der den Antrag bearbeitet.ie Anfrage initiiert hat, und ermöglicht die Analyse von Anfragemustern nach Person, Abteilung oder Standort. Datenquelle Verfügbar als Feld 'Anfragender' im Ticket-Objekt in Freshservice. Beispiele John DoeJane SmithServicekonto
	Anzahl der Neuzuweisungen ReassignmentCount	Die Gesamtzahl der Male, die eine Service-Requestn einem anderen Agenten oder Team neu zugewiesen wurde.
Beschreibung Dies ist ein berechnetes Attribut, das das Auftreten von 'Anfrage neu zugewiesen' oder ähnlichen Aktivitäten für jede Service-Requestn zählt. Eine hohe Neuzuweisungsanzahl deutet oft auf Probleme bei der initialen Triage, Neine fähigkeitsbasierte Weiterleitung oder Arbeitslast-Ungleichgewichte hin. Dieses Attribut unterstützt direkt das Dashboard 'Agent Leistungsfähigkeit & Workload Distribution' und den KPI 'Durchschnittliche Agenten-Neuzuweisungsanzahl/Anfrage'. Die Analyse dieser Metrik hilft Organisationen, Prozessschwächen zu identifizieren, die dazu führen, dass Tickets herumgereicht werden, was die Lösungszeit erhöht und sowohl Agenten als auch Anfragende frustriert. Bedeutung Misst Routing-Ineffizienz und Prozessreibung. Eine hohe Anzahl deutet auf Probleme bei der initialen Triage oder den Antrag bearbeitet.er Agentenarbeitslast hin, was zu Verzögerungen führt. Datenquelle Dies wird durch Zählen spezifischer Zuweisungsänderungsaktivitäten für jede 'ServiceRequestId' während der Datentransformation berechnet. Beispiele 013
	Endzeit EndTime	Der genaue Zeitstempel, wann die Aktivität abgeschlossen wurde.
Beschreibung Die End Time stellt den Abschluss-Zeitstempel einer Aktivität dar. Bei vielen Ereignisse in Freshservice sind Start- und Endzeit identisch, wodurch sie als Punkt-in-Zeit-Ereignisse gelten. Bei statusbasierten Aktivitäten wäre die End Time jedoch der Zeitstempel der nächsten Statusänderung. Dieses Attribut ist wichtig für die Berechnung der Dauer von Aktivitäten und der Wartezeiten dazwischen. Durch Subtraktion der StartTime von der EndTime kann die Bearbeitungszeit für eine spezifische Aufgabe bestimmt werden. Dies ist maßgeblich, um die zeitaufwändigsten Aktivitäten zu identifizieren und als primäre KandiDaten für die Optimierung zu wählen. Bedeutung Ermöglicht die Berechnung von Aktivitätsdauern, was grundlegend für die Identifizierung von Engpässen und die Messung von Bearbeitungszeiten für einzelne Schritte ist. Datenquelle Dies ist kein direktes Feld in den Freshservice-Logs. Es muss abgeleitet werden, indem der Zeitstempel des nachfolgenden Ereignisse in der Sequenz für eine gegebene Service-Requestn verwendet wird. Beispiele 2023-10-26T10:05:15Z2023-10-26T14:00:20Z2023-10-28T09:30:00Z
	Ist Nacharbeit IsRework	Ein boolesches Flag, das anzeigt, ob die Anfrage Nacharbeitsaktivitäten umfasste.
Beschreibung Dieses berechnete Flag wird auf True gesetzt, wenn eine Service-Requestn bestimmte Aktivitäten durchläuft, die auf Nacharbeit hindeuten. Beispiele sind die Wiedereröffnung nach der Lösung ('Service Request Reopened'), mehrere Neuzuweisungen oder wiederholte Informationsanfragen vom Benutzer ('Information Requested from Requestor'). Dieses Attribut vereinfacht die Analyse von Prozessineffizienzen. Es ermöglicht ein einfaches Filtern, um Fälle mit Nacharbeit zu isolieren und ihre Prozessablaufn und Durchlaufzeiten mit 'sauberen' Fällen zu vergleichen. Dies unterstützt direkt das Dashboard 'Service Request Rework Analysis' und hilft, die Auswirkungen ineffizienter Übergaben oder unvollständiger InitialHinweisrmationen zu quantifizieren. Bedeutung Bietet eine einfache Möglichkeit, Fälle mit ineffizienten Schleifen oder wiederholten Schritten zu kennzeichnen und zu analysierenn, um die Kosten schlechter Qualität zu quantifizieren. Datenquelle Berechnet während der Datentransformation durch Anwendung von Geschäftslogik auf die Abfolge von Aktivitäten für jede 'ServiceRequestId'. Beispiele JaNein
	Kanal Channel	Die Methode oder den Antrag bearbeitet.er Kanal, über den die Service-Anfrage eingereicht wurde.
Beschreibung Der Kanal gibt an, wie die Service-Requestn erstellt wurde, z.B. über das Self-Service-Portal, E-Mail, Telefonanruf oder Chat. Diese Information hilft, Benutzerpräferenzen und Kanaleffizienz zu verstehen. Die Analyse des Prozesses nach Kanal kann wichtige Erkenntnisse liefern. Zum Beispiel könnten über das Portal eingereichte Anfragen vollständiger und schneller gelöst werden als solche per E-Mail, die möglicherweise mehr Hin- und Her-Kommunikation erfordern. Diese Analyse kann Bemühungen zur Förderung effizienterer Kanäle leiten. Bedeutung Hilft zu analysierenn, ob der Einreichungskanal die Prozesseffizienz, die Lösungszeit oder den Antrag bearbeitet.en Umfang der erforderlichen Nacharbeit beeinflusst. Datenquelle Verfügbar als Feld 'Quelle' im Ticket-Objekt in Freshservice. Beispiele E-MailPortalTelefonChat
	SLA verletzt? IsSlaBreached	Ein boolesches Flag, das anzeigt, ob die Service-Requestn ihr SLA-Ziel für die Bearbeitung überschritten hat.
Beschreibung Dieses berechnete Attribut ist ein einfacher True/False-Flag, der angibt, ob die Service-Requestn nach ihrem SLA-Fälligkeitsdatum geschlossen wurde. Es wird abgeleitet, indem der Zeitstempel von 'Service Request Closed' oder 'Service Request Resolved' mit der 'SLA-Fälligkeitsdatum' verglichen wird. Dieses Attribut vereinfacht die Analyse und Visualisierung für das SLA Compliance Dashboard. Es ermöglicht ein einfaches Filtern und Aggregieren, um den Gesamt-KPI der SLA Compliance Rate zu berechnen. Die Segmentierung nach diesem Flag hilft, die Prozessmerkmale von verletzten Anfragen schnell zu isolieren und zu analysierenn im Vergleich zu jenen, die pünktlich gelöst wurden. Bedeutung Vereinfacht die SLA-Compliance-Analyse durch eine klare Kennzeichnung zum Filtern und Aggregieren von Anfragen, die ihre Ziele nicht erreicht haben. Datenquelle Dies ist ein berechnetes Feld, das während der Datentransformation durch den Vergleich des finalen Lösungs-Zeitstempels mit dem Feld 'SLA-Fälligkeitsdatum' abgeleitet wird. Beispiele JaNein
	SLA-Fälligkeitsdatum (SLA-Fälligkeitsdatum) SlaDueDate	Der Zeitstempel, bis zu dem die Service-Requestn gemäß ihrer SLA gelöst werden soll.
Beschreibung Dieses Attribut spezifiziert die Frist zur Lösung der Service-Requestn, wie sie durch die anwendbare SLA-Richtlinie definiert ist. Es handelt sich um einen berechneten Zeitstempel, der auf der Erstellungszeit der Anfrage, der Priorität und den in der SLA definierten Geschäftszeiten basiert. Dies ist ein kritischer Datenpunkt für die Überwachung der Echtzeit-Leistungsfähigkeit und für die Post-Mortem-SLA-Compliance-Analyse. Durch den Vergleich der tatsächlichen Lösungszeit mit der SLA-Fälligkeitsdatum kann festgestellt werden, ob die SLA 'eingehalten' oder 'verletzt' wurde. Es ist die Grundlage für die Berechnung des KPI der SLA-Compliance-Rate. Bedeutung Dies ist die Zielfrist für die Lösung und bildet die Grundlage für die Berechnung, ob eine Service-Requestn ihre SLA erfüllt oder verletzt hat. Datenquelle Dies ist ein berechnetes Feld innerhalb von Freshservice, das auf dem Ticket als 'Fällig bis' sichtbar ist. Es ist über die API verfügbar. Beispiele 2023-10-28T17:00:00Z2023-11-01T09:00:00Z
	SLA-Richtlinienname SlaPolicyName	Der Name der Service Level Agreement (SLA)-Richtlinie, die auf die Anfrage angewendet wurde.
Beschreibung Dieses Attribut identifiziert die spezifische SLA-Richtlinie, die die Ziel-Antwort- und Lösungszeiten für die Service-Requestn regelt. Richtlinien basieren in der Regel auf Faktoren wie Priorität, Servicetyp oder Anfragenden-Gruppe. Zu wissen, welche SLA-Richtlinie angewendet wird, ist wichtig für das Dashboard zur SLA-Compliance- und Verletzungsanalyse. Es ermöglicht eine genaue Messung der Leistung gegenüber definierten Zielen und hilft bei der Analyse, welche Richtlinien am häufigsten verletzt werden. Dies kann zu Überprüfungen der Prozessleistung oder den Antrag bearbeitet.er Machbarkeit der SLA-Ziele selbst führen. Bedeutung Identifiziert die spezifischen Serviceziele, anhand derer die Anfrage gemessen wird, was für eine genaue SLA-Compliance-Berichterstattung notwendig ist. Datenquelle Diese Information ist Teil der mit einem Ticket verknüpften SLA-Daten. Sie könnte das Abfragen spezifischer SLA-bezogener API-Endpunkte oder Felder erfordern. Beispiele Vorfälle hoher Priorität – 4 Std.Standardanfragen: 3 TageVIP-Support: 1 Stunde

Erforderlich Empfohlen Optional

Aktivitäten im Service Request Management

Dies sind die wichtigsten Prozessschritte und Meilensteine, die in Ihrem Event Log erfasst werden sollten, um Ihre Service-Requestn-Workflows genau zu erkennen und zu analysierenn.

6 Empfohlen 9 Optional

	Aktivität	Beschreibung
	Anfrage einem Agenten zugewiesen	Kennzeichnet den Zeitpunkt, an dem eine Service-Requestn einem bestimmten Agenten zur Bearbeitung zugewiesen wird. Dies ist ein wichtiger Meilenstein und wird durch die Verfolgung von Änderungen im Feld 'Zugewiesener Agent' oder 'Eigentümer' des Tickets abgeleitet.
Bedeutung Diese Aktivität ist maßgeblich für die Analyse der Agentenarbeitslast und die Identifizierung von Engpässen im Zuweisungsprozess. Die Zeit zwischen Erstellung und Zuweisung ist ein wichtiger Leistungsindikator. Datenquelle Abgeleitet aus dem Aktivitäts-Log oder den Antrag bearbeitet.em Feld-Audit-Trail des Tickets durch Überwachung von Änderungen im Feld 'Agent' oder 'Bearbeiter'. Erfassen Erfassen Sie den Zeitstempel, wenn das Feld 'Zugewiesener Agent' ausgefüllt wird oder sich sein Wert ändert. Ereignistyp inferred
	Externer Anbieter beauftragt	Diese Aktivität markiert den Zeitpunkt, an dem ein Ticket zur Lösung an einen externen Anbieter oder Dritte übergeben wird. Sie wird aus einer Statusänderung in einen spezifischen Zustand wie 'Warten auf Anbieter' oder 'Warten auf Dritte' abgeleitet.
Bedeutung Die Einbindung von Anbietern kann erhebliche Verzögerungen verursachen. Die Verfolgung dieser Aktivität ist maßgeblich, um die Anbieterleistung und deren Auswirkungen auf die gesamte Durchlaufzeit der Service-Requestn zu messen. Datenquelle Abgeleitet aus der Statusänderungshistorie des Tickets. Suchen Sie nach einem Status, der speziell zur Verfolgung der Abhängigkeit von externen Anbietern konfiguriert ist. Erfassen Erkennen Sie, wenn das Ticketstatusfeld zu einem Wert wechselt, der eine Wartezeit auf Dritte anzeigt. Ereignistyp inferred
	Service-Requestn erstellt	Diese Aktivität markiert den Beginn des Lebenszyklus einer Service-Requestn, wenn eine neue Anfrage formal in Freshservice protokolliert wird. Dieses Event wird explizit erfasst, wenn ein neuer Ticket-Datensatz generiert wird, entweder über den Servicekatalog, E-Mail oder einen anderen Kanal, wodurch eine eindeutige Service Request ID erstellt wird.
Bedeutung Dies ist das primäre Start-Ereignis für den Prozess. Die Analyse der Zeit von dieser Aktivität zu anderen ist grundlegend, um die gesamten Durchlaufzeiten zu messen und anfängliche Bearbeitungsverzögerungen zu identifizieren. Datenquelle Dieses Event wird explizit in Freshservice erfasst. Es ist im Aktivitätenprotokoll oder Audit-Trail des Tickets zu finden und entspricht in der Regel dem Ticket-Erstellungs-Zeitstempel. Erfassen Verwenden Sie den Ticket-Erstellungs-Zeitstempel aus den Freshservice-TicketDaten. Ereignistyp explicit
	Service-Requestn gelöst	Dieser kritische Meilenstein markiert den Zeitpunkt, an dem der Agent eine Lösung bereitgestellt hat und die Arbeit als abgeschlossen betrachtet. Dies wird aus der Statusänderung des Tickets auf 'Gelöst' abgeleitet.
Bedeutung Diese Aktivität markiert das Ende der aktiven Arbeitsphase. Die Dauer bis zu diesem Zeitpunkt ist ein Schlüsselmaß für die Effizienz von Agent und Prozess und bildet die Grundlage für SLA-Berechnungen. Datenquelle Abgeleitet aus der Statusänderungshistorie des Tickets. Dies entspricht dem Zeitstempel, wenn der Status erstmals auf 'Gelöst' gesetzt wurde. Erfassen Erfassen Sie den Zeitstempel, wenn der Ticketstatus erstmals auf 'Gelöst' wechselt. Ereignistyp inferred
	Service-Requestn geschlossen	Dies ist die finale Aktivität, die das Ende des Lebenszyklus der Service-Requestn markiert. Sie erfolgt in der Regel automatisch nach einer bestimmten Zeitspanne im Status 'Gelöst', ohne wiedereröffnet zu werden.
Bedeutung Dieses Event markiert das definitive Ende der Prozessinstanz. Die Zeit zwischen 'Gelöst' und 'Geschlossen' stellt das Bestätigungsfenster für den Anfragenden dar. Datenquelle Abgeleitet aus der Statusänderungshistorie des Tickets. Es entspricht dem Zeitstempel, wenn der Status auf 'Geschlossen' wechselt. Erfassen Erfassen Sie den Zeitstempel, wenn der Ticketstatus auf 'Geschlossen' wechselt. Ereignistyp inferred
	SLA-Ziel verletzt	Ein berechnetes Event, das auftritt, wenn die Bearbeitungszeit einer Service-Requestn ihr definiertes Service Level Agreement (SLA)-Ziel überschreitet. Dies ist kein direktes System-Event, sondern wird durch den Vergleich der Bearbeitungszeit mit dem SLA-Fälligkeitsdatum abgeleitet.
Bedeutung Dies misst direkt die Serviceleistung im Vergleich zu Verpflichtungen und ist ein wichtiger KPI für das Management. Es hilft zu identifizieren, welche Anfragetypen oder Prioritäten am stärksten gefährdet sind, zu scheitern. Datenquelle Berechnet durch den Vergleich des 'Gelöst'-Zeitstempels mit dem 'SLA-Fälligkeits'-Zeitstempel. Wenn die Bearbeitungszeit später ist, wird dieses Event ausgelöst. Erfassen Vergleichen Sie den Zeitstempel der Lösung mit dem Zeitstempel des SLA-Fälligkeitsdatums. Wenn resolved_at > sla_due_by, erstellen Sie dieses Event. Ereignistyp calculated
	Anfrage neu zugewiesen	Diese Aktivität erfasst jede Änderung des zugewiesenen Agenten oder den Antrag bearbeitet.er Gruppe nach der initialen Zuweisung. Sie wird abgeleitet, indem nachfolgende Aktualisierungen der Felder 'Assigned Agent' oder 'Assigned Group' erkannt werden.
Bedeutung Häufige Neuzuweisungen deuten auf potenzielle Probleme bei der initialen Triage, der Agentenfähigkeitenabgleichung oder den Antrag bearbeitet.er Arbeitslastverteilung hin. Diese Aktivität ist maßgeblich für den KPI der Agenten-Neuzuweisungsanzahl und die Nacharbeitsanalyse. Datenquelle Abgeleitet aus der Feldänderungshistorie des Tickets. Dieses Event wird jedes Mal protokolliert, wenn das Feld 'Zugewiesener Agent' oder 'Zugewiesene Gruppe' nach seiner initialen Festlegung aktualisiert wird. Erfassen Erkennen Sie jede Änderung im Feld 'Zugewiesener Agent' oder 'Zugewiesene Gruppe' nach der ersten Zuweisung. Ereignistyp inferred
	Anfrage priorisiert	Diese Aktivität tritt auf, wenn der Service-Requestn ein Prioritätslevel wie Niedrig, Mittel oder Hoch zugewiesen wird. Sie wird abgeleitet, indem eine Änderung im Feld 'Priorität' innerhalb des Ticketverlaufs erkannt wird.
Bedeutung Priorisierung ist maßgeblich für die Ressourcenzuweisung und die Sicherstellung der Einhaltung von SLA-Zielen. Die Analyse dieser Aktivität hilft zu überprüfen, ob Anfragen korrekt und zeitnah bewertet werden. Datenquelle Abgeleitet aus der Feldänderungshistorie des Tickets in Freshservice. Suchen Sie nach Aktualisierungen des Feldes 'Priorität' und erfassen Sie den Zeitstempel der Änderung. Erfassen Erkennen Sie eine Änderung im Feld 'Priorität' von Null oder seinem vorherigen Wert und zeichnen Sie den Zeitstempel auf. Ereignistyp inferred
	Anfrage vorgeprüft	Stellt die initiale Bewertung und Kategorisierung einer neu erstellten Service-Requestn dar. Diese Aktivität wird in der Regel abgeleitet, wenn zum ersten Mal eine Priorität festgelegt oder den Antrag bearbeitet.ie Anfrage einer Gruppe zugewiesen wird, was darauf hinweist, dass sie geprüft wurde und in die Warteschlange gelangt.
Bedeutung Die Verfolgung der Triage hilft, die Effizienz des initialen Reaktionsteams zu messen. Verzögerungen in dieser Phase können die Gesamt-Lösungszeiten und die SLA-Compliance erheblich beeinträchtigen. Datenquelle Abgeleitet aus dem Aktivitäts-Log. Es kann durch den Zeitstempel des ersten Ereignisse 'Priorität gesetzt' oder 'Gruppe zugewiesen' identifiziert werden, das nach der Erstellung auftritt. Erfassen Identifizieren Sie den frühesten Zeitstempel einer Prioritätsfeldänderung oder einer Zuweisungsgruppenfeldänderung. Ereignistyp inferred
	Informationen vom Anfragenden angefordert	Stellt einen Punkt dar, an dem der zugewiesene Agent weitere Informationen vom Anfragenden benötigt und den Fortschritt pausiert. Dies wird aus einer Statusänderung des Tickets in den Zustand 'Ausstehend' oder 'Warten auf Kunde' abgeleitet.
Bedeutung Diese Aktivität hebt eine häufige Ursache für Verzögerungen und Nacharbeit hervor. Die Analyse ihrer Häufigkeit hilft, Möglichkeiten zur Verbesserung von Anfrage-Templates und der initialen Datenerfassung zu identifizieren. Datenquelle Abgeleitet aus der Statusänderungshistorie des Tickets. Suchen Sie nach einer Änderung zu einem Status wie 'Antwort des Kunden ausstehende Zahlungen identifizieren.end' oder 'Informationen werden erwartet'. Erfassen Erkennen Sie, wenn das Ticketstatusfeld zu einem Wert wechselt, der eine Wartezeit auf Benutzereingaben anzeigt. Ereignistyp inferred
	Informationen vom Anfragenden bereitgestellt	Tritt auf, wenn der Anfragende mit den notwendigen Informationen antwortet, sodass der Agent die Arbeit wieder aufnehmen kann. Dies wird in der Regel abgeleitet, wenn der Ticketstatus automatisch von einem 'Ausstehend'-Zustand zurück zu 'Offen' wechselt.
Bedeutung Diese Aktivität schließt den Kreis der Informationsanfragen. Die Dauer zwischen Anforderung und Bereitstellung von Informationen ist eine kritische Wartezeit, die analysiert und optimiert werden muss. Datenquelle Abgeleitet von einer Statusänderung von einem 'Ausstehend'-Zustand zurück zu einem 'Offen'- oder 'In Bearbeitung'-Zustand, oft ausgelöst durch eine Antwort des Anfragenden. Erfassen Erkennen Sie, wenn der Ticketstatus von einem ausstehende Zahlungen identifizieren.enden Zustand zu einem offenen Zustand wechselt. Ereignistyp inferred
	Interne Überprüfung durchgeführt	Zeigt an, dass eine vorgeschlagene Lösung oder Anfragenerfüllung eine interne Prüfung oder Genehmigung erfordert, bevor fortgefahren wird. Dies wird aus einer Statusänderung in einen Zustand wie 'Genehmigung ausstehende Zahlungen identifizieren.end' oder 'Interne Prüfung' abgeleitet.
Bedeutung Interne Überprüfungen können eine Quelle für Engpässe sein, insbesondere bei komplexen oder hochwirksamen Service-Requestnn. Die Messung dieser Dauer hilft, Genehmigungs-Workflows zu optimieren. Datenquelle Abgeleitet aus der Statusänderungshistorie des Tickets. Dies erfordert die Verwendung eines spezifischen Status wie 'Interne Genehmigung ausstehende Zahlungen identifizieren.end' im Workflow. Erfassen Erkennen Sie, wenn das Ticketstatusfeld zu einem Wert wechselt, der eine interne Prüfung oder Genehmigung anzeigt. Ereignistyp inferred
	Lösung vom Anfragenden bestätigt	Diese Aktivität repräsentiert eine explizite Bestätigung des Anfragenden, dass die bereitgestellte Lösung zufriedenstellend ist. Dies kann aus einer positiven Umfrageantwort oder einem spezifischen Kommentar vor der Schließung des Tickets abgeleitet werden.
Bedeutung Die Bestätigung gibt direktes Feedback zur Qualität der Lösung. Eine geringe Bestätigungsrate kann darauf hindeuten, dass Lösungen die Benutzerbedürfnisse nicht vollständig erfüllen, selbst wenn die Anfragen nicht wiedereröffnet werden. Datenquelle Dies ist schwierig direkt zu erfassen und kann eine benutzerdefinierte Konfiguration erfordern. Es könnte aus einer Kundenumfrage-Antwort, die mit dem Ticket verknüpft ist, oder einem spezifischen angewendeten Tag abgeleitet werden. Erfassen Erfordert die Analyse relevanter Daten wie Zufriedenheitsumfragen oder Tags, die nach der Lösung angewendet wurden. Ereignistyp inferred
	Notiz hinzugefügt	Stellt jede öffentliche oder private Notiz dar, die von einem Agenten oder den Antrag bearbeitet.em Anfragenden zur Service-Requestn hinzugefügt wurde. Dies ist ein explizites Event, das im Konversations- oder Aktivitätenprotokoll des Tickets erfasst wird.
Bedeutung Die Analyse der Häufigkeit und des Zeitpunkts von Notizen kann Kommunikationsmuster, die Effizienz der Zusammenarbeit und Verwirrungspunkte im Prozess aufzeigen. Datenquelle Explizit im Konversationsverlauf des Tickets in Freshservice protokolliert. Jede Notiz hat einen Zeitstempel und einen Autor. Erfassen Extrahieren Sie jeden Eintrag aus dem Konversations- oder Kommentar-Log des Tickets. Ereignistyp explicit
	Service-Requestn wiedereröffnet	Tritt auf, wenn ein Anfragender angibt, dass ein Problem weiterhin besteht, nachdem es als 'Gelöst' markiert wurde, wodurch das Ticket in einen offenen Zustand zurückkehrt. Dies wird aus einer Statusänderung von 'Gelöst' zurück zu 'Offen' oder 'In Bearbeitung' abgeleitet.
Bedeutung Wiedereröffnete Anfragen sind ein starker Indikator für niedrige Erstlösungsraten und Kundenunzufriedenheit. Die Verfolgung dieser Nacharbeitsschleife ist maßgeblich für die Verbesserung der Lösungsqualität. Datenquelle Abgeleitet aus der Statusänderungshistorie des Tickets im Aktivitäts-Log. Dies ist ein direkter Statusübergang von 'Gelöst' zu 'Offen'. Erfassen Erkennen Sie einen Statuswechsel von einem gelösten Zustand zu einem offenen Zustand. Ereignistyp inferred

Extraktionsanleitungen

Wie Sie Ihre Daten aus Freshservice erhalten

Schritte

Voraussetzungsprüfung: Stellen Sie sicher, dass Sie eine Freshservice-Benutzerrolle mit Berechtigungen zum Zugriff auf und zur Erstellung von Berichten im Analysen-Modul besitzen. Dies erfordert in der Regel einen Pro- oder Enterprise-Plan.
Automatisierungen konfigurieren (falls erforderlich): Für eine präzise Event-Erfassung überprüfen oder erstellen Sie zwei spezifische Automatisierungen in Freshservice unter Admin -> Workflow Automator. Erstens eine Automatisierung, die dem Ticket eine private Notiz oder einen spezifischen Tag (z. B. 'SLA_Breached') hinzufügt, wenn der SLA-Zeitgeber für die Problemlösung abläuft. Zweitens eine Automatisierung, die einen spezifischen Tag (z. B. 'Resolution_Confirmed') hinzufügt, wenn eine positive Kundenzufriedenheitsumfrage für ein Ticket eingeht.
Bericht 'Erstellungs-Ereignisse' erstellen: Navigieren Sie zum Analysen-Tab in Freshservice. Erstellen Sie einen neuen Bericht und wählen Sie das 'Tickets'-Modul als Datenquelle. Dieser Bericht erfasst das erste Event für jede Service-Requestn.
Widgets des Berichts 'Erstellungs-Ereignisse' konfigurieren: Fügen Sie ein 'Daten Table'-Widget hinzu. Konfigurieren Sie die Spalten (Metriken) so, dass sie enthalten: Ticket-ID, Erstellt am, Zugewiesen an, Gruppe, Priorität, Status und Kategorie. Wenden Sie einen Filter für den gewünschten Erstellungsdatumsbereich an, z. B. die letzten 6 Monate.
Daten der 'Erstellungs-Ereignisse' exportieren: Führen Sie den Bericht aus und exportieren Sie das Daten Table-Widget in eine CSV-Datei. Benennen Sie sie 'creation_Events.csv'.
Bericht 'Update-Ereignisse' erstellen: Erstellen Sie einen zweiten Bericht, diesmal mit dem 'Ticket-Aktivitäten'-Modul als Datenquelle. Dieser Bericht erfasst alle nachfolgenden Änderungen und Notizen für jede Service-Requestn.
Widgets des Berichts 'Update-Ereignisse' konfigurieren: Fügen Sie ein 'Daten Table'-Widget hinzu. Konfigurieren Sie die Spalten so, dass sie enthalten: Ticket-ID, Aktivitätsdatum, Ausgeführt von, Aktivitätstyp und unter 'Änderungen' die Felder, Alten Wert und Neuen Wert. Sie sollten auch Ticket-Attribute wie Gruppe, Zugewiesen an, Priorität, Status und Kategorie hinzufügen, um Kontext für jedes Event zu bieten.
Bericht 'Update-Ereignisse' filtern: Wenden Sie einen Filter für das 'Aktivitätsdatum' an, der den Antrag bearbeitet.em im Erstellungsbericht verwendeten Datumsbereich entspricht. Filtern Sie den 'Aktivitätstyp' weiter, um nur relevante Ereignisse wie 'Status geändert', 'Priorität geändert', 'Gruppe geändert', 'Agent geändert', 'Private Notiz hinzugefügt' und 'Öffentliche Notiz hinzugefügt' einzuschließen.
Daten der 'Update-Ereignisse' exportieren: Führen Sie den Bericht aus und exportieren Sie das Daten Table-Widget in eine CSV-Datei. Benennen Sie sie 'update_Events.csv'.
Daten kombinieren und modernisieren: Öffnen Sie die beiden CSV-Dateien in einem Tabellenkalkulationsprogramm oder verwenden Sie ein Datenaufbereitungsskript. Kopieren Sie alle Daten aus 'update_Events.csv' und fügen Sie sie unterhalb der Daten aus 'creation_Events.csv' in eine neue Datei namens 'Event_log.csv' ein.
Aktivitäten und Attribute zuordnen: Erstellen Sie in der kombinierten Datei 'Event_log.csv' neue Spalten: ServiceRequestId, ActivityName, Ereigniszeitpunkt (Event Time), (SourceSystem), LastDatenUpdate, AssignedAgent, AssignedTeam, Priority, Status und ServiceTyp. Füllen Sie diese Spalten mit der Logik aus, die im Abschnitt Query unten definiert ist. Dieser Schritt beinhaltet die Verwendung von Formeln oder eines Skripts, um die RohDaten in das endgültige Event Log-Format zu übersetzen.
Endgültiger Export: Speichern Sie die transformierte Datei 'Event_log.csv'. Stellen Sie sicher, dass das Datumsformat für Ereigniszeitpunkt (Event Time) und LastDatenUpdate in einem Standardformat wie ISO 8601 vorliegt. Diese Datei ist nun bereit für den Upload in ein Process Mining-Tool.

Konfiguration

Freshservice Plan: Ein Plan, der den Antrag bearbeitet.as Analysen-Modul umfasst (in der Regel Pro oder Enterprise), ist erforderlich.
Benutzerberechtigungen: Der Benutzer, der den Antrag bearbeitet.en Export durchführt, benötigt Berechtigungen, um Berichte in Analysen zu erstellen und auszuführen.
Datumsbereich: Es wird empfohlen, Daten für einen aktuellen Zeitraum, z. B. die letzten 3 bis 6 Monate, zu extrahieren, um den Datensatz überschaubar zu halten. Wenden Sie einen konsistenten Datumsbereichsfilter basierend auf 'Erstellt am' für den Erstellungsbericht und 'Aktivitätsdatum' für den Aktualisierungsbericht an.
Berichtsfilter: Filtern Sie im Bericht des 'Tickets'-Moduls nach 'Typ' = 'Service Request', um den korrekten Prozess zu isolieren. Filtern Sie für den 'Ticket-Aktivitäten'-Bericht den 'Aktivitätstyp', um nur relevante Änderungen (Status, Priorität, Zuweisung, Notizen) einzuschließen und Rauschen in den exportierten Daten zu reduzieren.
Erforderliche Automatisierungen: Die Extraktion von Aktivitäten wie 'SLA-Ziel überschritten' und 'Lösung vom Anfragenden bestätigt' hängt von bereits bestehenden Workflow Automator-Regeln ab, die dem Ticket bei diesen Ereignisse eine Notiz oder einen Tag hinzufügen. Ohne diese können die Aktivitäten mit dieser Methode nicht erfasst werden.

a Beispielabfrage config

/*
This extraction method uses the Freshservice UI. The following describes the configuration
and post-processing logic required to generate the event log.
*/

-- Step 1: Configuration for Report 1 (Creation Events)
MODULE: Tickets
WIDGET_TYPE: Data Table
COLUMNS:
  - Ticket ID
  - Created at
  - Assigned to
  - Group
  - Priority
  - Status
  - Category
FILTERS:
  - Created at IS WITHIN [Specify Start Date] and [Specify End Date]
  - Type EQUALS 'Service Request'

-- Step 2: Configuration for Report 2 (Update Events)
MODULE: Ticket Activities
WIDGET_TYPE: Data Table
COLUMNS:
  - Ticket ID
  - Activity Date
  - Activity Type
  - Field (from Changes)
  - Old Value (from Changes)
  - New Value (from Changes)
  - Performed by
  - Group (ticket attribute)
  - Assigned to (ticket attribute)
  - Priority (ticket attribute)
  - Status (ticket attribute)
  - Category (ticket attribute)
FILTERS:
  - Activity Date IS WITHIN [Specify Start Date] and [Specify End Date]
  - Ticket Type EQUALS 'Service Request'
  - Activity Type IN ('Status changed', 'Priority changed', 'Group changed', 'Agent changed', 'Private Note added', 'Public Note added')

-- Step 3: Post-Processing Logic to create the final event log file
/* 
Apply this logic to each row of the combined data from the two exported CSV files.
The logic uses a CASE statement structure to map raw data to the final ActivityName.
*/

-- Column Mapping Logic:
`ServiceRequestId` = `Ticket ID`
`EventTime` = IF row is from creation_events.csv THEN `Created at` ELSE `Activity Date`
`SourceSystem` = 'Freshservice'
`LastDataUpdate` = CURRENT_TIMESTAMP()
`AssignedAgent` = `Assigned to`
`AssignedTeam` = `Group`
`Priority` = `Priority`
`Status` = `Status`
`ServiceType` = `Category`

-- ActivityName Mapping Logic:
CASE
  WHEN row is from creation_events.csv THEN 'Service Request Created'
  WHEN `Activity Type` = 'Group changed' AND `Old Value` IS NULL THEN 'Request Triaged'
  WHEN `Activity Type` = 'Priority changed' THEN 'Request Prioritized'
  WHEN `Activity Type` = 'Agent changed' AND `Old Value` IS NULL THEN 'Request Assigned to Agent'
  WHEN `Activity Type` IN ('Agent changed', 'Group changed') AND `Old Value` IS NOT NULL THEN 'Request Reassigned'
  WHEN `Activity Type` = 'Status changed' AND `New Value` IN ('Pending Customer', 'Awaiting Customer Response') THEN 'Information Requested from Requestor'
  WHEN `Activity Type` = 'Status changed' AND `Old Value` IN ('Pending Customer', 'Awaiting Customer Response') AND `New Value` = 'Open' THEN 'Information Provided by Requestor'
  WHEN `Activity Type` = 'Status changed' AND `New Value` IN ('Pending Vendor', 'Awaiting Third Party') THEN 'External Vendor Engaged'
  WHEN `Activity Type` = 'Status changed' AND `New Value` IN ('Pending Approval', 'Internal Review') THEN 'Internal Review Performed'
  WHEN `Activity Type` = 'Private Note added' AND `Note Content` CONTAINS 'SLA Breached' THEN 'SLA Target Breached' -- Requires custom automation
  WHEN `Activity Type` IN ('Private Note added', 'Public Note added') THEN 'Note Added'
  WHEN `Activity Type` = 'Status changed' AND `Old Value` IN ('Resolved', 'Closed') AND `New Value` IN ('Open', 'In Progress') THEN 'Service Request Reopened'
  WHEN `Activity Type` = 'Status changed' AND `New Value` = 'Resolved' THEN 'Service Request Resolved'
  WHEN `Activity Type` = 'Private Note added' AND `Note Content` CONTAINS 'Resolution Confirmed' THEN 'Resolution Confirmed by Requestor' -- Requires custom automation
  WHEN `Activity Type` = 'Status changed' AND `New Value` = 'Closed' THEN 'Service Request Closed'
  ELSE NULL -- Filter out these rows
END AS ActivityName

Schritte

Voraussetzungen: Stellen Sie sicher, dass Python 3.6 oder neuer auf Ihrem System installiert ist, zusammen mit den Bibliotheken requests und pandas. Sie benötigen außerdem einen Freshservice API-Schlüssel mit Berechtigungen zum Lesen von TicketDaten.
API-Schlüssel erhalten: Melden Sie sich als Administrator bei Ihrer Freshservice-Instanz an. Klicken Sie oben rechts auf Ihr Profilsymbol, gehen Sie zu 'Profileinstellungen', und Sie finden Ihren API-Schlüssel im rechten Bereich. Kopieren Sie diesen Schlüssel sicher.
Skript speichern: Speichern Sie den bereitgestellten Python-Code in einer Datei namens extract_freshservice_srm.py auf Ihrem lokalen Computer.
Skriptparameter konfigurieren: Öffnen Sie das gespeicherte Skript in einem Texteditor. Suchen Sie den Konfigurationsbereich am Anfang und ersetzen Sie die Platzhalterwerte für FRESHSERVICE_DOMAIN, API_KEY, START_DATE und END_DATE. Passen Sie das STATUS_MAPPING-Wörterbuch an, falls Ihre Instanz andere numerische IDs für benutzerdefinierte Status verwendet.
Bibliotheken installieren: Wenn Sie die erforderlichen Bibliotheken noch nicht installiert haben, öffnen Sie Ihre Befehlszeile oder Ihr Terminal und führen Sie den Befehl aus: pip install requests pandas.
Skript ausführen: Navigieren Sie im Befehlszeilentool oder Terminal zu dem Verzeichnis, in dem Sie das Skript gespeichert haben. Führen Sie das Skript aus, indem Sie den Befehl eingeben: python extract_freshservice_srm.py.
Ausführung überwachen: Das Skript gibt Fortschrittsaktualisierungen auf der Konsole aus und zeigt an, welche Seite von Tickets gerade verarbeitet wird. Abhängig vom Datumsbereich und der Anzahl der Tickets kann dies einige Zeit in Anspruch nehmen.
Event Log abrufen: Sobald das Skript erfolgreich abgeschlossen ist, wird eine Datei namens freshservice_Event_log.csv im selben Verzeichnis erstellt. Diese Datei enthält den extrahierten Event Log.
Für Upload vorbereiten: Die generierte CSV-Datei ist mit den erforderlichen Spalten (ServiceRequestId, ActivityName, Ereigniszeitpunkt (Event Time), (SourceSystem), LastDatenUpdate) strukturiert und bereit für den Upload in ProcessMind. Eine weitere Formatierung ist in der Regel nicht erforderlich.

Konfiguration

FRESHSERVICE_DOMAIN: Die Freshservice-URL Ihres Unternehmens, z. B. yourcompany.freshservice.com.
API_KEY: Der persönliche API-Schlüssel, den Sie in Ihrem Freshservice-Benutzerprofil erhalten haben. Dieser sollte vertraulich behandelt werden.
START_DATE / END_DATE: Der Datumsbereich für die Ticket-Extraktion, formatiert als 'JJJJ-MM-TT'. Für eine erste Analyse wird ein Zeitraum von 3 bis 6 Monaten empfohlen, um Datenvolumen und Erkenntnisgewinn auszubalancieren.
STATUS_MAPPING: Ein kritisches Python-Wörterbuch im Skript, das benutzerdefinierte Statusnamen, die zur Ableitung von Ereignisse verwendet werden (wie 'External Vendor Engaged'), deren entsprechenden numerischen Status-IDs in Ihrer Freshservice-Instanz zuordnet. Sie müssen diese IDs überprüfen und aktualisieren, um sie an die Konfiguration Ihres Systems anzupassen.
API Rate Limiting: Beachten Sie die API-Ratenbegrenzungen Ihres Freshservice-Plans. Das Skript verarbeitet Tickets sequenziell, um diese Begrenzungen einzuhalten, aber bei extrem großen Datensätzen müssen Sie die Extraktion möglicherweise in kleineren Datumsbereichs-Batches durchführen.
Daten Scope: Das Skript ist so konfiguriert, dass es nur Tickets des Typs 'Service Request' abruft. Dieser Filter wird während des anfänglichen Ticket-Abrufs angewendet.

a Beispielabfrage python

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

class=class="hl-string">"hl-comment"># --- CONFIGURATION ---
class=class="hl-string">"hl-comment"># Replace with your Freshservice domain and API key
FRESHSERVICE_DOMAIN = class="hl-string">"[your_domain].freshservice.com" 
API_KEY = class="hl-string">"[YOUR_API_KEY]"

class=class="hl-string">"hl-comment"># Set the date range for the extraction (YYYY-MM-DD)
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-12-31"

class=class="hl-string">"hl-comment"># --- Map your custom status names to their numeric IDs in Freshservice ---
class=class="hl-string">"hl-comment"># To find these IDs, you may need to inspect API responses or admin settings
class=class="hl-string">"hl-comment"># Common defaults: Open: 2, Pending: 3, Resolved: 4, Closed: 5
STATUS_MAPPING = {
    class="hl-string">'Open': 2,
    class="hl-string">'Pending': 3, 
    class="hl-string">'Resolved': 4, 
    class="hl-string">'Closed': 5,
    class="hl-string">'Awaiting Customer': 3, class=class="hl-string">"hl-comment"># Example, often maps to Pending
    class="hl-string">'Pending Vendor': [6], class=class="hl-string">"hl-comment"># Replace with your actual ID(s) for this status
    class="hl-string">'Pending Approval': [7]  class=class="hl-string">"hl-comment"># Replace with your actual ID(s) for this status
}
class=class="hl-string">"hl-comment"># --- END CONFIGURATION ---

BASE_URL = fclass="hl-string">"https://{FRESHSERVICE_DOMAIN}/api/v2"
AUTH = (API_KEY, class="hl-string">"X")

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

def get_api_data(url):
    class="hl-string">"""Helper function to handle API requests and rate limiting."""
    while True:
        try:
            response = requests.get(url, auth=AUTH)
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raise an exception for bad status codes
            return response.json()
        except requests.exceptions.HTTPError as e:
            if e.response.status_code == 429: class=class="hl-string">"hl-comment"># Rate limit exceeded
                print(class="hl-string">"Rate limit exceeded. Waiting for 60 seconds...")
                time.sleep(60)
                continue
            else:
                print(fclass="hl-string">"HTTP Error: {e}")
                return None
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Request Error: {e}")
            return None

def get_agent_name(agent_id):
    class="hl-string">"""Fetch agent name by ID with caching."""
    if not agent_id: return None
    if agent_id in agent_cache:
        return agent_cache[agent_id]
    data = get_api_data(fclass="hl-string">"{BASE_URL}/agents/{agent_id}")
    if data and class="hl-string">'agent' in data:
        name = data[class="hl-string">'agent'][class="hl-string">'first_name'] + class="hl-string">' ' + data[class="hl-string">'agent'][class="hl-string">'last_name']
        agent_cache[agent_id] = name
        return name
    return None

def get_group_name(group_id):
    class="hl-string">"""Fetch group name by ID with caching."""
    if not group_id: return None
    if group_id in group_cache:
        return group_cache[group_id]
    data = get_api_data(fclass="hl-string">"{BASE_URL}/groups/{group_id}")
    if data and class="hl-string">'group' in data:
        name = data[class="hl-string">'group'][class="hl-string">'name']
        group_cache[group_id] = name
        return name
    return None

def parse_iso_datetime(dt_string):
    if not dt_string: return None
    return datetime.fromisoformat(dt_string.replace(class="hl-string">'Z', class="hl-string">'+00:00'))

def main():
    event_log = []
    last_data_update = datetime.now().isoformat()

    page = 1
    while True:
        print(fclass="hl-string">"Fetching tickets, page {page}...")
        query = fclass="hl-string">'"created_at:>\\'{START_DATE}\\class="hl-string">' AND created_at:<\\'{END_DATE}\\class="hl-string">' AND ticket_type:\\\'Service Request\\\class="hl-string">'"'
        url = fclass="hl-string">"{BASE_URL}/tickets?query={query}&page={page}&per_page=100"

        data = get_api_data(url)

        if not data or class="hl-string">'tickets' not in data or not data[class="hl-string">'tickets']:
            break

        tickets = data[class="hl-string">'tickets']

        for ticket in tickets:
            service_request_id = ticket[class="hl-string">'id']
            created_at = parse_iso_datetime(ticket[class="hl-string">'created_at'])
            due_by = parse_iso_datetime(ticket[class="hl-string">'due_by'])
            resolved_at = parse_iso_datetime(ticket[class="hl-string">'resolved_at'])
            closed_at = parse_iso_datetime(ticket[class="hl-string">'closed_at'])

            class=class="hl-string">"hl-comment"># --- Activity: Service Request Created ---
            event_log.append({
                class="hl-string">'ServiceRequestId': service_request_id,
                class="hl-string">'ActivityName': class="hl-string">'Service Request Created',
                class="hl-string">'EventTime': created_at,
                class="hl-string">'SourceSystem': class="hl-string">'Freshservice',
                class="hl-string">'LastDataUpdate': last_data_update,
                class="hl-string">'AssignedAgent': get_agent_name(ticket.get(class="hl-string">'responder_id')),
                class="hl-string">'AssignedTeam': get_group_name(ticket.get(class="hl-string">'group_id')),
                class="hl-string">'Priority': ticket[class="hl-string">'priority'],
                class="hl-string">'Status': ticket[class="hl-string">'status'],
                class="hl-string">'ServiceType': ticket.get(class="hl-string">'category')
            })
            
            class=class="hl-string">"hl-comment"># Fetch conversations for detailed history
            conv_url = fclass="hl-string">"{BASE_URL}/tickets/{service_request_id}/conversations"
            conversations = get_api_data(conv_url)
            
            if not conversations or class="hl-string">'conversations' not in conversations:
                continue
                
            class=class="hl-string">"hl-comment"># Sort conversations chronologically
            sorted_convos = sorted(conversations[class="hl-string">'conversations'], key=lambda x: parse_iso_datetime(x[class="hl-string">'created_at']))

            initial_group_assigned = False
            initial_priority_set = False
            initial_agent_assigned = False
            triaged = False

            for conv in sorted_convos:
                conv_time = parse_iso_datetime(conv[class="hl-string">'created_at'])

                class=class="hl-string">"hl-comment"># --- Activity: Note Added ---
                if conv[class="hl-string">'body_text']:
                     event_log.append({
                        class="hl-string">'ServiceRequestId': service_request_id,
                        class="hl-string">'ActivityName': class="hl-string">'Note Added',
                        class="hl-string">'EventTime': conv_time,
                        class="hl-string">'SourceSystem': class="hl-string">'Freshservice',
                        class="hl-string">'LastDataUpdate': last_data_update,
                        class="hl-string">'AssignedAgent': get_agent_name(ticket.get(class="hl-string">'responder_id')),
                        class="hl-string">'AssignedTeam': get_group_name(ticket.get(class="hl-string">'group_id')),
                        class="hl-string">'Priority': ticket[class="hl-string">'priority'],
                        class="hl-string">'Status': ticket[class="hl-string">'status'],
                        class="hl-string">'ServiceType': ticket.get(class="hl-string">'category')
                    })

                class=class="hl-string">"hl-comment"># Process system activities from the activity log within conversations
                if class="hl-string">'activities' in conv and conv[class="hl-string">'activities']:
                    for activity in conv[class="hl-string">'activities']:
                        shipping_info = activity.get(class="hl-string">'shipping_info', {})
                        changes = shipping_info.get(class="hl-string">'changes', {})
                        
                        class=class="hl-string">"hl-comment"># --- Priority Change Activities ---
                        if class="hl-string">'priority' in changes:
                            event_log.append({
                                class="hl-string">'ServiceRequestId': service_request_id,
                                class="hl-string">'ActivityName': class="hl-string">'Request Prioritized',
                                class="hl-string">'EventTime': conv_time,
                                class="hl-string">'SourceSystem': class="hl-string">'Freshservice',
                                class="hl-string">'LastDataUpdate': last_data_update,
                                class="hl-string">'AssignedAgent': get_agent_name(ticket.get(class="hl-string">'responder_id')),
                                class="hl-string">'AssignedTeam': get_group_name(ticket.get(class="hl-string">'group_id')),
                                class="hl-string">'Priority': changes[class="hl-string">'priority'][1], class=class="hl-string">"hl-comment"># New value
                                class="hl-string">'Status': ticket[class="hl-string">'status'],
                                class="hl-string">'ServiceType': ticket.get(class="hl-string">'category')
                            })
                            if not initial_priority_set and not triaged:
                                initial_priority_set = True
                                triaged = True
                                event_log.append({**event_log[-1], class="hl-string">'ActivityName': class="hl-string">'Request Triaged'})
                        
                        class=class="hl-string">"hl-comment"># --- Assignment Change Activities ---
                        if class="hl-string">'responder_id' in changes:
                            activity_name = class="hl-string">'Request Assigned to Agent' if not initial_agent_assigned else class="hl-string">'Request Reassigned'
                            initial_agent_assigned = True
                            event_log.append({
                                class="hl-string">'ServiceRequestId': service_request_id,
                                class="hl-string">'ActivityName': activity_name,
                                class="hl-string">'EventTime': conv_time,
                                class="hl-string">'SourceSystem': class="hl-string">'Freshservice',
                                class="hl-string">'LastDataUpdate': last_data_update,
                                class="hl-string">'AssignedAgent': get_agent_name(changes[class="hl-string">'responder_id'][1]),
                                class="hl-string">'AssignedTeam': get_group_name(ticket.get(class="hl-string">'group_id')),
                                class="hl-string">'Priority': ticket[class="hl-string">'priority'],
                                class="hl-string">'Status': ticket[class="hl-string">'status'],
                                class="hl-string">'ServiceType': ticket.get(class="hl-string">'category')
                            })
                        
                        if class="hl-string">'group_id' in changes:
                            activity_name = class="hl-string">'Request Reassigned' class=class="hl-string">"hl-comment"># Any group change after creation is a reassignment
                            if not initial_group_assigned and not triaged:
                                activity_name = class="hl-string">'Request Triaged'
                                initial_group_assigned = True
                                triaged = True
                            event_log.append({
                                class="hl-string">'ServiceRequestId': service_request_id,
                                class="hl-string">'ActivityName': activity_name,
                                class="hl-string">'EventTime': conv_time,
                                class="hl-string">'SourceSystem': class="hl-string">'Freshservice',
                                class="hl-string">'LastDataUpdate': last_data_update,
                                class="hl-string">'AssignedAgent': get_agent_name(ticket.get(class="hl-string">'responder_id')),
                                class="hl-string">'AssignedTeam': get_group_name(changes[class="hl-string">'group_id'][1]),
                                class="hl-string">'Priority': ticket[class="hl-string">'priority'],
                                class="hl-string">'Status': ticket[class="hl-string">'status'],
                                class="hl-string">'ServiceType': ticket.get(class="hl-string">'category')
                            })
                        
                        class=class="hl-string">"hl-comment"># --- Status Change Activities ---
                        if class="hl-string">'status' in changes:
                            old_status, new_status = changes[class="hl-string">'status']
                            
                            if new_status == STATUS_MAPPING[class="hl-string">'Resolved']:
                                event_log.append({**event_log[-1], class="hl-string">'ActivityName': class="hl-string">'Service Request Resolved', class="hl-string">'EventTime': conv_time, class="hl-string">'Status': new_status})
                            elif new_status == STATUS_MAPPING[class="hl-string">'Closed']:
                                event_log.append({**event_log[-1], class="hl-string">'ActivityName': class="hl-string">'Service Request Closed', class="hl-string">'EventTime': conv_time, class="hl-string">'Status': new_status})
                            elif new_status == STATUS_MAPPING[class="hl-string">'Awaiting Customer']:
                                event_log.append({**event_log[-1], class="hl-string">'ActivityName': class="hl-string">'Information Requested from Requestor', class="hl-string">'EventTime': conv_time, class="hl-string">'Status': new_status})
                            elif old_status == STATUS_MAPPING[class="hl-string">'Awaiting Customer'] and new_status == STATUS_MAPPING[class="hl-string">'Open']:
                                event_log.append({**event_log[-1], class="hl-string">'ActivityName': class="hl-string">'Information Provided by Requestor', class="hl-string">'EventTime': conv_time, class="hl-string">'Status': new_status})
                            elif old_status in [STATUS_MAPPING[class="hl-string">'Resolved'], STATUS_MAPPING[class="hl-string">'Closed']] and new_status == STATUS_MAPPING[class="hl-string">'Open']:
                                event_log.append({**event_log[-1], class="hl-string">'ActivityName': class="hl-string">'Service Request Reopened', class="hl-string">'EventTime': conv_time, class="hl-string">'Status': new_status})
                            elif new_status in STATUS_MAPPING[class="hl-string">'Pending Vendor']:
                                event_log.append({**event_log[-1], class="hl-string">'ActivityName': class="hl-string">'External Vendor Engaged', class="hl-string">'EventTime': conv_time, class="hl-string">'Status': new_status})
                            elif new_status in STATUS_MAPPING[class="hl-string">'Pending Approval']:
                                event_log.append({**event_log[-1], class="hl-string">'ActivityName': class="hl-string">'Internal Review Performed', class="hl-string">'EventTime': conv_time, class="hl-string">'Status': new_status})
            
            class=class="hl-string">"hl-comment"># --- Derived/Calculated Activities ---
            class=class="hl-string">"hl-comment"># --- Activity: SLA Target Breached ---
            resolution_time = closed_at or resolved_at
            if due_by and resolution_time and resolution_time > due_by:
                event_log.append({
                    class="hl-string">'ServiceRequestId': service_request_id,
                    class="hl-string">'ActivityName': class="hl-string">'SLA Target Breached',
                    class="hl-string">'EventTime': due_by,
                    class="hl-string">'SourceSystem': class="hl-string">'Freshservice',
                    class="hl-string">'LastDataUpdate': last_data_update,
                    class="hl-string">'AssignedAgent': get_agent_name(ticket.get(class="hl-string">'responder_id')),
                    class="hl-string">'AssignedTeam': get_group_name(ticket.get(class="hl-string">'group_id')),
                    class="hl-string">'Priority': ticket[class="hl-string">'priority'],
                    class="hl-string">'Status': ticket[class="hl-string">'status'],
                    class="hl-string">'ServiceType': ticket.get(class="hl-string">'category')
                })

            class=class="hl-string">"hl-comment"># --- Activity: Resolution Confirmed by Requestor (Inferred from survey) ---
            if ticket.get(class="hl-string">'satisfaction_ratings'):
                for rating in ticket[class="hl-string">'satisfaction_ratings']:
                    if rating.get(class="hl-string">'ratings'): class=class="hl-string">"hl-comment"># Check if there is a rating
                        rating_time = parse_iso_datetime(rating.get(class="hl-string">'created_at'))
                        if resolved_at and rating_time > resolved_at:
                            event_log.append({
                                class="hl-string">'ServiceRequestId': service_request_id,
                                class="hl-string">'ActivityName': class="hl-string">'Resolution Confirmed by Requestor',
                                class="hl-string">'EventTime': rating_time,
                                class="hl-string">'SourceSystem': class="hl-string">'Freshservice',
                                class="hl-string">'LastDataUpdate': last_data_update,
                                class="hl-string">'AssignedAgent': get_agent_name(ticket.get(class="hl-string">'responder_id')),
                                class="hl-string">'AssignedTeam': get_group_name(ticket.get(class="hl-string">'group_id')),
                                class="hl-string">'Priority': ticket[class="hl-string">'priority'],
                                class="hl-string">'Status': ticket[class="hl-string">'status'],
                                class="hl-string">'ServiceType': ticket.get(class="hl-string">'category')
                            })
                            break class=class="hl-string">"hl-comment"># Only add one confirmation event

        page += 1

    if not event_log:
        print(class="hl-string">"No events were generated. Please check your configuration and date range.")
        return

    class=class="hl-string">"hl-comment"># Create DataFrame and save to CSV
    df = pd.DataFrame(event_log)
    df = df.sort_values(by=[class="hl-string">'ServiceRequestId', class="hl-string">'EventTime'])
    df[class="hl-string">'EventTime'] = df[class="hl-string">'EventTime'].dt.strftime(class="hl-string">'%Y-%m-%d %H:%M:%S')
    df[class="hl-string">'LastDataUpdate'] = pd.to_datetime(df[class="hl-string">'LastDataUpdate']).dt.strftime(class="hl-string">'%Y-%m-%d %H:%M:%S')
    output_filename = class="hl-string">'freshservice_event_log.csv'
    df.to_csv(output_filename, index=False)
    print(fclass="hl-string">"Successfully extracted {len(df)} events to {output_filename}")

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

Schritte

Voraussetzungsprüfung: Stellen Sie sicher, dass Sie eine Freshservice-Benutzerrolle mit Berechtigungen zum Zugriff auf und zur Erstellung von Berichten im Analysen-Modul besitzen. Dies erfordert in der Regel einen Pro- oder Enterprise-Plan.
Automatisierungen konfigurieren (falls erforderlich): Für eine präzise Event-Erfassung überprüfen oder erstellen Sie zwei spezifische Automatisierungen in Freshservice unter Admin -> Workflow Automator. Erstens eine Automatisierung, die dem Ticket eine private Notiz oder einen spezifischen Tag (z. B. 'SLA_Breached') hinzufügt, wenn der SLA-Zeitgeber für die Problemlösung abläuft. Zweitens eine Automatisierung, die einen spezifischen Tag (z. B. 'Resolution_Confirmed') hinzufügt, wenn eine positive Kundenzufriedenheitsumfrage für ein Ticket eingeht.
Bericht 'Erstellungs-Ereignisse' erstellen: Navigieren Sie zum Analysen-Tab in Freshservice. Erstellen Sie einen neuen Bericht und wählen Sie das 'Tickets'-Modul als Datenquelle. Dieser Bericht erfasst das erste Event für jede Service-Requestn.
Widgets des Berichts 'Erstellungs-Ereignisse' konfigurieren: Fügen Sie ein 'Daten Table'-Widget hinzu. Konfigurieren Sie die Spalten (Metriken) so, dass sie enthalten: Ticket-ID, Erstellt am, Zugewiesen an, Gruppe, Priorität, Status und Kategorie. Wenden Sie einen Filter für den gewünschten Erstellungsdatumsbereich an, z. B. die letzten 6 Monate.
Daten der 'Erstellungs-Ereignisse' exportieren: Führen Sie den Bericht aus und exportieren Sie das Daten Table-Widget in eine CSV-Datei. Benennen Sie sie 'creation_Events.csv'.
Bericht 'Update-Ereignisse' erstellen: Erstellen Sie einen zweiten Bericht, diesmal mit dem 'Ticket-Aktivitäten'-Modul als Datenquelle. Dieser Bericht erfasst alle nachfolgenden Änderungen und Notizen für jede Service-Requestn.
Widgets des Berichts 'Update-Ereignisse' konfigurieren: Fügen Sie ein 'Daten Table'-Widget hinzu. Konfigurieren Sie die Spalten so, dass sie enthalten: Ticket-ID, Aktivitätsdatum, Ausgeführt von, Aktivitätstyp und unter 'Änderungen' die Felder, Alten Wert und Neuen Wert. Sie sollten auch Ticket-Attribute wie Gruppe, Zugewiesen an, Priorität, Status und Kategorie hinzufügen, um Kontext für jedes Event zu bieten.
Bericht 'Update-Ereignisse' filtern: Wenden Sie einen Filter für das 'Aktivitätsdatum' an, der den Antrag bearbeitet.em im Erstellungsbericht verwendeten Datumsbereich entspricht. Filtern Sie den 'Aktivitätstyp' weiter, um nur relevante Ereignisse wie 'Status geändert', 'Priorität geändert', 'Gruppe geändert', 'Agent geändert', 'Private Notiz hinzugefügt' und 'Öffentliche Notiz hinzugefügt' einzuschließen.
Daten der 'Update-Ereignisse' exportieren: Führen Sie den Bericht aus und exportieren Sie das Daten Table-Widget in eine CSV-Datei. Benennen Sie sie 'update_Events.csv'.
Daten kombinieren und modernisieren: Öffnen Sie die beiden CSV-Dateien in einem Tabellenkalkulationsprogramm oder verwenden Sie ein Datenaufbereitungsskript. Kopieren Sie alle Daten aus 'update_Events.csv' und fügen Sie sie unterhalb der Daten aus 'creation_Events.csv' in eine neue Datei namens 'Event_log.csv' ein.
Aktivitäten und Attribute zuordnen: Erstellen Sie in der kombinierten Datei 'Event_log.csv' neue Spalten: ServiceRequestId, ActivityName, Ereigniszeitpunkt (Event Time), (SourceSystem), LastDatenUpdate, AssignedAgent, AssignedTeam, Priority, Status und ServiceTyp. Füllen Sie diese Spalten mit der Logik aus, die im Abschnitt Query unten definiert ist. Dieser Schritt beinhaltet die Verwendung von Formeln oder eines Skripts, um die RohDaten in das endgültige Event Log-Format zu übersetzen.
Endgültiger Export: Speichern Sie die transformierte Datei 'Event_log.csv'. Stellen Sie sicher, dass das Datumsformat für Ereigniszeitpunkt (Event Time) und LastDatenUpdate in einem Standardformat wie ISO 8601 vorliegt. Diese Datei ist nun bereit für den Upload in ein Process Mining-Tool.

Konfiguration

Freshservice Plan: Ein Plan, der den Antrag bearbeitet.as Analysen-Modul umfasst (in der Regel Pro oder Enterprise), ist erforderlich.
Benutzerberechtigungen: Der Benutzer, der den Antrag bearbeitet.en Export durchführt, benötigt Berechtigungen, um Berichte in Analysen zu erstellen und auszuführen.
Datumsbereich: Es wird empfohlen, Daten für einen aktuellen Zeitraum, z. B. die letzten 3 bis 6 Monate, zu extrahieren, um den Datensatz überschaubar zu halten. Wenden Sie einen konsistenten Datumsbereichsfilter basierend auf 'Erstellt am' für den Erstellungsbericht und 'Aktivitätsdatum' für den Aktualisierungsbericht an.
Berichtsfilter: Filtern Sie im Bericht des 'Tickets'-Moduls nach 'Typ' = 'Service Request', um den korrekten Prozess zu isolieren. Filtern Sie für den 'Ticket-Aktivitäten'-Bericht den 'Aktivitätstyp', um nur relevante Änderungen (Status, Priorität, Zuweisung, Notizen) einzuschließen und Rauschen in den exportierten Daten zu reduzieren.
Erforderliche Automatisierungen: Die Extraktion von Aktivitäten wie 'SLA-Ziel überschritten' und 'Lösung vom Anfragenden bestätigt' hängt von bereits bestehenden Workflow Automator-Regeln ab, die dem Ticket bei diesen Ereignisse eine Notiz oder einen Tag hinzufügen. Ohne diese können die Aktivitäten mit dieser Methode nicht erfasst werden.

a Beispielabfrage config

/*
This extraction method uses the Freshservice UI. The following describes the configuration
and post-processing logic required to generate the event log.
*/

-- Step 1: Configuration for Report 1 (Creation Events)
MODULE: Tickets
WIDGET_TYPE: Data Table
COLUMNS:
  - Ticket ID
  - Created at
  - Assigned to
  - Group
  - Priority
  - Status
  - Category
FILTERS:
  - Created at IS WITHIN [Specify Start Date] and [Specify End Date]
  - Type EQUALS 'Service Request'

-- Step 2: Configuration for Report 2 (Update Events)
MODULE: Ticket Activities
WIDGET_TYPE: Data Table
COLUMNS:
  - Ticket ID
  - Activity Date
  - Activity Type
  - Field (from Changes)
  - Old Value (from Changes)
  - New Value (from Changes)
  - Performed by
  - Group (ticket attribute)
  - Assigned to (ticket attribute)
  - Priority (ticket attribute)
  - Status (ticket attribute)
  - Category (ticket attribute)
FILTERS:
  - Activity Date IS WITHIN [Specify Start Date] and [Specify End Date]
  - Ticket Type EQUALS 'Service Request'
  - Activity Type IN ('Status changed', 'Priority changed', 'Group changed', 'Agent changed', 'Private Note added', 'Public Note added')

-- Step 3: Post-Processing Logic to create the final event log file
/* 
Apply this logic to each row of the combined data from the two exported CSV files.
The logic uses a CASE statement structure to map raw data to the final ActivityName.
*/

-- Column Mapping Logic:
`ServiceRequestId` = `Ticket ID`
`EventTime` = IF row is from creation_events.csv THEN `Created at` ELSE `Activity Date`
`SourceSystem` = 'Freshservice'
`LastDataUpdate` = CURRENT_TIMESTAMP()
`AssignedAgent` = `Assigned to`
`AssignedTeam` = `Group`
`Priority` = `Priority`
`Status` = `Status`
`ServiceType` = `Category`

-- ActivityName Mapping Logic:
CASE
  WHEN row is from creation_events.csv THEN 'Service Request Created'
  WHEN `Activity Type` = 'Group changed' AND `Old Value` IS NULL THEN 'Request Triaged'
  WHEN `Activity Type` = 'Priority changed' THEN 'Request Prioritized'
  WHEN `Activity Type` = 'Agent changed' AND `Old Value` IS NULL THEN 'Request Assigned to Agent'
  WHEN `Activity Type` IN ('Agent changed', 'Group changed') AND `Old Value` IS NOT NULL THEN 'Request Reassigned'
  WHEN `Activity Type` = 'Status changed' AND `New Value` IN ('Pending Customer', 'Awaiting Customer Response') THEN 'Information Requested from Requestor'
  WHEN `Activity Type` = 'Status changed' AND `Old Value` IN ('Pending Customer', 'Awaiting Customer Response') AND `New Value` = 'Open' THEN 'Information Provided by Requestor'
  WHEN `Activity Type` = 'Status changed' AND `New Value` IN ('Pending Vendor', 'Awaiting Third Party') THEN 'External Vendor Engaged'
  WHEN `Activity Type` = 'Status changed' AND `New Value` IN ('Pending Approval', 'Internal Review') THEN 'Internal Review Performed'
  WHEN `Activity Type` = 'Private Note added' AND `Note Content` CONTAINS 'SLA Breached' THEN 'SLA Target Breached' -- Requires custom automation
  WHEN `Activity Type` IN ('Private Note added', 'Public Note added') THEN 'Note Added'
  WHEN `Activity Type` = 'Status changed' AND `Old Value` IN ('Resolved', 'Closed') AND `New Value` IN ('Open', 'In Progress') THEN 'Service Request Reopened'
  WHEN `Activity Type` = 'Status changed' AND `New Value` = 'Resolved' THEN 'Service Request Resolved'
  WHEN `Activity Type` = 'Private Note added' AND `Note Content` CONTAINS 'Resolution Confirmed' THEN 'Resolution Confirmed by Requestor' -- Requires custom automation
  WHEN `Activity Type` = 'Status changed' AND `New Value` = 'Closed' THEN 'Service Request Closed'
  ELSE NULL -- Filter out these rows
END AS ActivityName

Ihre Service Request Management Daten-Template

Ihre Service Request Management Daten-Template

Attribute im Service Request Management

Aktivitäten im Service Request Management

Extraktionsanleitungen

Freshservice Analysen Modul Datenexport

Schritte

Konfiguration

a Beispielabfrage config

Python-Skript mit Freshservice REST API

Schritte

Konfiguration

a Beispielabfrage python

Freshservice Geplanter Datenexport zu Cloud Storage

Schritte

Konfiguration

a Beispielabfrage config

Bereit, um loszulegen?

Steigern Sie noch heute die Effizienz Ihres Service-Anforderungsmanagements in Freshservice.

Ihre Service Request Management Daten-Template

Ihre Service Request Management Daten-Template

Attribute im Service Request Management

Aktivitäten im Service Request Management

Extraktionsanleitungen

Freshservice Analysen Modul Datenexport

Schritte

Konfiguration

a Beispielabfrage config

Python-Skript mit Freshservice REST API

Schritte

Konfiguration

a Beispielabfrage python

Freshservice Geplanter Datenexport zu Cloud Storage

Schritte

Konfiguration

a Beispielabfrage config

Ihre Privatsphäre ist uns wichtig

Bereit, um loszulegen?

Steigern Sie noch heute die Effizienz Ihres Service-Anforderungsmanagements in Freshservice.