> Kontinuierliche Prozessoptimierung > Serviceanfragen Management > Freshservice > Datenvorlage

Ihr Datentemplate für das Serviceanfragenmanagement

Freshservice

Attribute im Serviceanfragenmanagement (20) Aktivitäten im Serviceanfragenmanagement (15) Extraktionsleitfäden (3)

Ihr Datentemplate für das Serviceanfragenmanagement

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

Empfohlene Attribute zur Erfassung
Wichtige Aktivitäten zur Verfolgung
Extraktionsanleitung

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

Vorlage herunterladen

Attribute im Serviceanfragenmanagement

Dies sind die empfohlenen Datenfelder, die Sie in Ihren Event Log aufnehmen sollten, um eine umfassende Analyse Ihres Serviceanfragenmanagements durchzuführen.

5 Erforderlich 5 Empfohlen 10 Optional

	Name	Beschreibung
	Aktivitätsname ActivityName	Der Name des Events oder der Aufgabe, die zu einem bestimmten Zeitpunkt für eine Serviceanfrage aufgetreten ist.
Beschreibung Der Aktivitätsname beschreibt einen spezifischen Schritt oder ein Event innerhalb des Lebenszyklus der Serviceanfrage. Diese Aktivitäten werden aus System-Audit-Logs, Statusänderungen oder spezifischen Benutzeraktionen extrahiert, wie z.B. 'Anfrage Agent zugewiesen', 'Notiz hinzugefügt' oder 'Serviceanfrage gelöst'. Dieses Attribut ist entscheidend für die Erstellung der Prozesslandkarte, die den Fluss der Serviceanfragen 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 Prozesslandkarte und ermöglicht die Visualisierung und Analyse des Serviceanfragen-Workflows. Datenquelle Generiert aus den 'Aktivitäten' oder 'Audits', die einem Ticket in Freshservice zugeordnet sind. Dies erfordert oft Transformationslogik, um System-Events auf geschäftsfreundliche Aktivitätsnamen abzubilden. Beispiele Serviceanfrage erstelltAnfrage einem Agenten zugewiesenServiceanfrage gelöstServiceanfrage geschlossen
	Ereigniszeit EventTime	Der genaue Timestamp, wann die Aktivität stattfand.
Beschreibung Die Event Time erfasst Datum und Uhrzeit, zu der eine bestimmte Aktivität für eine Serviceanfrage aufgezeichnet wurde. Dieser Zeitstempel ist grundlegend für die korrekte Reihenfolge von Events 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 Cycle Times, Wartezeiten zwischen Aktivitäten und der Einhaltung von Service Level Agreements (SLAs) genutzt. Präzise Zeitstempel sind entscheidend für die Identifizierung von Engpässen und das Verständnis der Prozessperformance. Bedeutung Dieser Timestamp ordnet Events chronologisch und ist die Grundlage für alle Leistungsanalysen, einschließlich Durchlaufzeit und Engpasserkennung. Datenquelle Dies entspricht dem Erstellungs-Timestamp 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
	Serviceanfrage-ID ServiceRequestId	Die eindeutige Kennung für jede Serviceanfrage.
Beschreibung Die Service Request ID ist eine eindeutige Nummer oder ein Code, der jeder neuen Serviceanfrage 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 fundamental, da sie als Case ID fungiert. Alle zugehörigen Events, 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 Cases betreffen. Bedeutung Dies ist die essentielle Case ID, die alle zugehörigen Events verbindet und es ermöglicht, den End-to-End-Weg einer einzelnen Serviceanfrage 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	Timestamp, 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 entscheidend. Dieser Timestamp 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 unerlässlich 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 umfassende 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 Data Governance einzuschließen. Es gewährleistet Klarheit über die Datenherkunft und hilft bei der Verwaltung von Datenintegrations-Pipelines. Bedeutung Gewährleistet Datenherkunft und Nachvollziehbarkeit, was entscheidend ist beim Kombinieren von Daten aus mehreren Systemen oder für Data Governance-Zwecke. Datenquelle Dies ist typischerweise 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 Serviceanfrage, z.B. Niedrig, Mittel, Hoch oder Dringend.
Beschreibung Die Priorität gibt die Wichtigkeit und Dringlichkeit einer Serviceanfrage 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 Performance für hoch- versus niedrigpriorisierte Elemente zu vergleichen. Dies ist essenziell für die SLA-Compliance-Analyse und um zu verstehen, ob die Priorisierung in der Triage-Phase effektiv und schnell erfolgt. Bedeutung Entscheidend 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 die Kategorie des angefragten Services.
Beschreibung Der Servicetyp klassifiziert die Anfrage basierend auf der Art des benötigten Services, 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 Serviceanfragen, 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 Services 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 Serviceanfrage in ihrem Lebenszyklus.
Beschreibung Das Statusfeld repräsentiert den Zustand der Serviceanfrage 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 Serviceanfrage zugewiesen ist.
Beschreibung Dieses Attribut identifiziert den spezifischen Support-Agenten, der zu einem bestimmten Zeitpunkt für die Bearbeitung der Serviceanfrage verantwortlich ist. Agentenzuweisungen können sich während des Lebenszyklus einer Anfrage ändern. Die Analyse des zugewiesenen Agenten ist entscheidend für das Verständnis der Agentenleistung und der Arbeitslastverteilung. Sie ermöglicht die Berechnung von KPIs wie der durchschnittlichen Lösungszeit pro Agent, der Anzahl aktiver Anfragen und der Neuzuweisungsraten. Dies hilft, Top-Performing-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 die Gruppe, die für die Bearbeitung der Serviceanfrage zuständig ist.
Beschreibung Dieses Attribut gibt die funktionale Gruppe oder das Team an, z.B. 'IT Support Level 2' oder 'Hardware Procurement', das für die Serviceanfrage 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 entscheidend 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 unerlässlich ist. Datenquelle Verfügbar als Feld 'Gruppe' im Ticket-Objekt in Freshservice. Beispiele `Service Desk`NetzwerkbetriebAnwendungsunterstützung
	`Anzahl` der `Neuzuweisungen` ReassignmentCount	Die Gesamtzahl der Male, die eine Serviceanfrage 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 Serviceanfrage zählt. Eine hohe Neuzuweisungsanzahl deutet oft auf Probleme bei der initialen Triage, falsche fähigkeitsbasierte Weiterleitung oder Arbeitslast-Ungleichgewichte hin. Dieses Attribut unterstützt direkt das Dashboard 'Agent Performance & 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 der 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
	`SLA Due Date` SlaDueDate	Der Timestamp, bis zu dem die Serviceanfrage gemäß ihrer SLA gelöst werden soll.
Beschreibung Dieses Attribut spezifiziert die Frist zur Lösung der Serviceanfrage, wie sie durch die anwendbare SLA-Richtlinie definiert ist. Es handelt sich um einen berechneten Timestamp, 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-Performance und für die Post-Mortem-SLA-Compliance-Analyse. Durch den Vergleich der tatsächlichen Lösungszeit mit der SlaDueDate 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 Serviceanfrage 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` verletzt IsSlaBreached	Ein boolesches Flag, das anzeigt, ob die Serviceanfrage ihr SLA-Ziel für die Bearbeitung überschritten hat.
Beschreibung Dieses berechnete Attribut ist ein einfacher True/False-Flag, der angibt, ob die Serviceanfrage nach ihrem SLA-Fälligkeitsdatum geschlossen wurde. Es wird abgeleitet, indem der Timestamp von 'Service Request Closed' oder 'Service Request Resolved' mit der 'SlaDueDate' 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 analysieren 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-Timestamps mit dem Feld 'SlaDueDate' abgeleitet wird. Beispiele truefalsch
	Abteilung des Anfragenden RequestorDepartment	Die Abteilung, zu der der Anfragende gehört.
Beschreibung Dieses Attribut spezifiziert die organisatorische Abteilung des Benutzers, der die Serviceanfrage eingereicht hat, wie 'Vertrieb', 'Finanzen' oder 'Personalwesen'. Diese Informationen stammen typischerweise 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 die 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 die Serviceanfrage eingereicht hat.
Beschreibung Dieses Attribut identifiziert die Person, üblicherweise einen Mitarbeiter, die die Serviceanfrage initiiert hat. Es bietet Kontext darüber, wer den Service Desk nutzt und welche Bedürfnisse sie haben. Obwohl nicht immer eine primäre Dimension für die Prozessflussanalyse, kann die Analyse nach Anfragendem oder der 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 die 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
	Bearbeitungszeit ProcessingTime	Die Dauer der aktiven Bearbeitung einer Aktivität.
Beschreibung Die Bearbeitungszeit ist eine berechnete Kennzahl, die die Dauer einer einzelnen Aktivität darstellt. Sie wird ermittelt, indem die StartTime der Aktivität von ihrer EndTime subtrahiert wird. Diese Kennzahl ist grundlegend für die Engpassanalyse. Durch die Aggregation der Bearbeitungszeiten für jede Aktivitätstyp ergibt sich ein klares Bild darüber, wo im Prozess die meiste Zeit verbracht wird. Dies ermöglicht es Analysten, Verbesserungsbemühungen auf die zeitaufwändigsten Schritte zu konzentrieren, wie zum Beispiel 'Interne Prüfung durchgeführt' oder 'Externer Anbieter involviert'. Bedeutung Quantifiziert die Dauer einzelner Prozessschritte und hebt die zeitaufwändigsten Aktivitäten und Engpässe direkt hervor. Datenquelle Berechnet während der Datenaufbereitung durch Subtraktion des 'EventTime' (Startzeit) eines Events vom 'EndTime' (dem Zeitstempel des nächsten Events). Beispiele 360086400300
	Endzeit EndTime	Der genaue Timestamp, wann die Aktivität abgeschlossen wurde.
Beschreibung Die End Time stellt den Abschluss-Timestamp einer Aktivität dar. Bei vielen Events in Freshservice sind Start- und Endzeit identisch, wodurch sie als Punkt-in-Zeit-Events gelten. Bei statusbasierten Aktivitäten wäre die End Time jedoch der Timestamp der nächsten Statusänderung. Dieses Attribut ist essenziell 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 entscheidend, 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 Timestamp des nachfolgenden Events in der Sequenz für eine gegebene Serviceanfrage 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 Serviceanfrage 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 Prozesslandkarten 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 Initialinformationen zu quantifizieren. Bedeutung Bietet eine einfache Möglichkeit, Fälle mit ineffizienten Schleifen oder wiederholten Schritten zu kennzeichnen und zu analysieren, 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 truefalsch
	Kanal Channel	Die Methode oder der Kanal, über den die Serviceanfrage eingereicht wurde.
Beschreibung Der Kanal gibt an, wie die Serviceanfrage 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 analysieren, ob der Einreichungskanal die Prozesseffizienz, die Lösungszeit oder den Umfang der erforderlichen Nacharbeit beeinflusst. Datenquelle Verfügbar als Feld 'Quelle' im Ticket-Objekt in Freshservice. Beispiele E-MailPortalTelefonChat
	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 Serviceanfrage regelt. Richtlinien basieren typischerweise auf Faktoren wie Priorität, Servicetyp oder Anfragenden-Gruppe. Zu wissen, welche SLA-Richtlinie angewendet wird, ist essenziell 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 der 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 unerlässlich 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 Serviceanfragenmanagement

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

6 Empfohlen 9 Optional

	Aktivität	Beschreibung
	Anfrage einem Agenten zugewiesen	Kennzeichnet den Zeitpunkt, an dem eine Serviceanfrage 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 entscheidend 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 dem 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 entscheidend, um die Anbieterleistung und deren Auswirkungen auf die gesamte Durchlaufzeit der Serviceanfrage 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
	Serviceanfrage erstellt	Diese Aktivität markiert den Beginn des Lebenszyklus einer Serviceanfrage, 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 Zykluszeiten 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 typischerweise dem Ticket-Erstellungs-Timestamp. Erfassen Verwenden Sie den Ticket-Erstellungs-Timestamp aus den Freshservice-Ticketdaten. Ereignistyp explicit
	Serviceanfrage 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
	Serviceanfrage geschlossen	Dies ist die finale Aktivität, die das Ende des Lebenszyklus der Serviceanfrage markiert. Sie erfolgt typischerweise 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 Serviceanfrage 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 der 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 der Arbeitslastverteilung hin. Diese Aktivität ist entscheidend 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 Serviceanfrage 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 entscheidend 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 Serviceanfrage dar. Diese Aktivität wird typischerweise abgeleitet, wenn zum ersten Mal eine Priorität festgelegt oder die 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 Events '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 ausstehend' 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 typischerweise 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 ausstehenden 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 ausstehend' oder 'Interne Prüfung' abgeleitet.
Bedeutung Interne Überprüfungen können eine Quelle für Engpässe sein, insbesondere bei komplexen oder hochwirksamen Serviceanfragen. 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 ausstehend' 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 dem Anfragenden zur Serviceanfrage 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
	Serviceanfrage 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 entscheidend 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

Extraktionsleitfäden

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 Analytics-Modul besitzen. Dies erfordert typischerweise 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-Timer 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-Events' erstellen: Navigieren Sie zum Analytics-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 Serviceanfrage.
Widgets des Berichts 'Erstellungs-Events' konfigurieren: Fügen Sie ein 'Data 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-Events' exportieren: Führen Sie den Bericht aus und exportieren Sie das Data Table-Widget in eine CSV-Datei. Benennen Sie sie 'creation_events.csv'.
Bericht 'Update-Events' 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 Serviceanfrage.
Widgets des Berichts 'Update-Events' konfigurieren: Fügen Sie ein 'Data 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-Events' filtern: Wenden Sie einen Filter für das 'Aktivitätsdatum' an, der dem im Erstellungsbericht verwendeten Datumsbereich entspricht. Filtern Sie den 'Aktivitätstyp' weiter, um nur relevante Events 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-Events' exportieren: Führen Sie den Bericht aus und exportieren Sie das Data Table-Widget in eine CSV-Datei. Benennen Sie sie 'update_events.csv'.
Daten kombinieren und transformieren: Ö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, EventTime, SourceSystem, LastDataUpdate, AssignedAgent, AssignedTeam, Priority, Status und ServiceType. 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 EventTime und LastDataUpdate 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 das Analytics-Modul umfasst (typischerweise Pro oder Enterprise), ist erforderlich.
Benutzerberechtigungen: Der Benutzer, der den Export durchführt, benötigt Berechtigungen, um Berichte in Analytics 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 Events 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, EventTime, SourceSystem, LastDataUpdate) strukturiert und bereit für den Upload in ProcessMind. Eine weitere Formatierung ist typischerweise 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 Events 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.
Data 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 Analytics-Modul besitzen. Dies erfordert typischerweise 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-Timer 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-Events' erstellen: Navigieren Sie zum Analytics-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 Serviceanfrage.
Widgets des Berichts 'Erstellungs-Events' konfigurieren: Fügen Sie ein 'Data 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-Events' exportieren: Führen Sie den Bericht aus und exportieren Sie das Data Table-Widget in eine CSV-Datei. Benennen Sie sie 'creation_events.csv'.
Bericht 'Update-Events' 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 Serviceanfrage.
Widgets des Berichts 'Update-Events' konfigurieren: Fügen Sie ein 'Data 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-Events' filtern: Wenden Sie einen Filter für das 'Aktivitätsdatum' an, der dem im Erstellungsbericht verwendeten Datumsbereich entspricht. Filtern Sie den 'Aktivitätstyp' weiter, um nur relevante Events 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-Events' exportieren: Führen Sie den Bericht aus und exportieren Sie das Data Table-Widget in eine CSV-Datei. Benennen Sie sie 'update_events.csv'.
Daten kombinieren und transformieren: Ö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, EventTime, SourceSystem, LastDataUpdate, AssignedAgent, AssignedTeam, Priority, Status und ServiceType. 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 EventTime und LastDataUpdate 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 das Analytics-Modul umfasst (typischerweise Pro oder Enterprise), ist erforderlich.
Benutzerberechtigungen: Der Benutzer, der den Export durchführt, benötigt Berechtigungen, um Berichte in Analytics 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 Events 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

Ihr Datentemplate für das Serviceanfragenmanagement

Ihr Datentemplate für das Serviceanfragenmanagement

Attribute im Serviceanfragenmanagement

Aktivitäten im Serviceanfragenmanagement

Extraktionsleitfäden

Freshservice Analytics 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 Serviceanforderungsmanagements in Freshservice.

Ihr Datentemplate für das Serviceanfragenmanagement

Ihr Datentemplate für das Serviceanfragenmanagement

Attribute im Serviceanfragenmanagement

Aktivitäten im Serviceanfragenmanagement

Extraktionsleitfäden

Freshservice Analytics 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 Serviceanforderungsmanagements in Freshservice.