> Kontinuierliche Prozessverbesserung > Service Request Management > Freshservice > Daten Template

Ihr Daten-Template für das Service-Request-Management

Freshservice

← Zurück zum Leitfaden zur Prozessverbesserung

Attribute des Service-Request-Managements (19) Aktivitäten im Service-Request-Management (15) Anleitungen zur Datenextraktion (3)

Ihr Daten-Template für das Service-Request-Management

Dieses Template zeigt Ihnen, welche Daten Sie für die Analyse Ihres Service-Request-Prozesses erfassen sollten. Es beschreibt die erforderlichen Attribute, die wichtigsten Aktivitäten und wie Sie diese Informationen aus Ihren Quellsystemen extrahieren. Verwenden Sie die Anleitung, um ein aussagekräftiges Event Log für eine detaillierte Prozessanalyse zu erstellen.

Empfohlene Attribute für die Erfassung
Wichtige Aktivitäten für die Erfassung
Anleitung zur Datenextraktion

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

Template herunterladen

Attribute des Service-Request-Managements

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

5 Erforderlich 5 Empfohlen 9 Optional

	Name	Beschreibung
	Aktivitätsname ActivityName	Name des Ereignisses oder der Aufgabe, die zu einem bestimmten Zeitpunkt im Verlauf einer Serviceanfrage stattgefunden hat.
Beschreibung Der Aktivitätsname bezeichnet einen bestimmten Schritt oder ein Ereignis im Lebenszyklus einer Serviceanfrage. Die Aktivitäten werden aus System-Audit-Logs, Statusänderungen oder konkreten Aktionen von Benutzern abgeleitet, zum Beispiel „Anfrage einem Agent zugewiesen“, „Notiz hinzugefügt“ oder „Serviceanfrage gelöst“. Dieses Attribut ist entscheidend für die Erstellung der Prozesslandkarte, die den Ablauf von Serviceanfragen visuell darstellt. Durch die Analyse der Reihenfolge und Häufigkeit verschiedener Aktivitäten können Unternehmen den tatsächlichen Prozess nachvollziehen, Engpässe zwischen Schritten erkennen, Aktivitätsdauern messen und nicht konforme oder ineffiziente Prozessvarianten aufdecken. Warum das wichtig ist Dieses Attribut legt die Schritte in der Prozesslandkarte fest und ermöglicht so die Visualisierung und Analyse des Workflows für Serviceanfragen. Woher beziehen Abgeleitet aus den mit einem Ticket in Freshservice verknüpften „activities“ oder „audits“. Häufig ist eine Transformationslogik erforderlich, um Systemereignisse verständlichen Aktivitätsnamen zuzuordnen. Beispiele Serviceanfrage erstelltAnfrage einem Agent zugewiesenServiceanfrage gelöstServiceanfrage geschlossen
	Ereigniszeit EventTime	Der genaue Timestamp, zu dem die Aktivität stattgefunden hat.
Beschreibung Die Ereigniszeit erfasst Datum und Uhrzeit, zu denen eine bestimmte Aktivität für eine Serviceanfrage protokolliert wurde. Dieser Timestamp ist entscheidend, um Ereignisse korrekt zu ordnen und Zeitspannen zwischen ihnen zu berechnen. Im Process Mining dient dieses Attribut dazu, die Aktivitäten jedes Cases zu ordnen und bildet die Grundlage für alle zeitbezogenen Analysen. Damit lassen sich Zykluszeiten, Wartezeiten zwischen Aktivitäten und die Einhaltung von Service Level Agreements (SLAs) berechnen. Genaue Timestamps sind wichtig, um Engpässe zu erkennen und die Prozessleistung zu verstehen. Warum das wichtig ist Dieser Timestamp ordnet Ereignisse chronologisch und bildet die Grundlage für alle Leistungsanalysen, einschließlich der Zykluszeit und der Erkennung von Engpässen. Woher beziehen Dies entspricht dem Erstellungs-Timestamp eines Aktivitäts- oder Audit-Log-Eintrags in Freshservice. Beispiele 2023-10-26T10:00:00Z2023-10-26T11:35:10Z2023-10-27T14:20:05Z
	Serviceanfrage-ID ServiceRequestId	Eindeutige Kennung jeder Serviceanfrage.
Beschreibung Die Serviceanfrage-ID ist eine eindeutige Nummer oder ein eindeutiger Code, der jeder neuen, in Freshservice erfassten Serviceanfrage zugewiesen wird. Sie dient als Primärschlüssel, mit dem sich der gesamte Lebenszyklus der Anfrage von der Erstellung bis zum Abschluss verfolgen lässt. Im Process Mining ist diese ID grundlegend, da sie als Case-ID dient. Alle zugehörigen Ereignisse, etwa Statusänderungen, Agentenzuweisungen und Notizen, werden über diese Kennung miteinander verknüpft. Durch die Analyse jeder Serviceanfrage-ID lässt sich der Prozess von Anfang bis Ende vollständig darstellen. So können Sie häufige Abläufe erkennen und Abweichungen oder Engpässe identifizieren, die einzelne Cases betreffen. Warum das wichtig ist Diese zentrale Case-ID verknüpft alle zugehörigen Ereignisse. Damit lässt sich der gesamte Ablauf einer einzelnen Serviceanfrage nachvollziehen. Woher beziehen Dies ist ein Primärfeld des Ticketobjekts 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, zu denen der Datensatz zuletzt aus Freshservice extrahiert oder aktualisiert wurde. Es gibt Aufschluss darüber, wie aktuell die analysierten Daten sind. Für jede Prozessanalyse ist es wichtig zu wissen, wie aktuell die Daten sind. Anhand dieses Timestamps können Benutzer beurteilen, ob sie mit den neuesten Informationen arbeiten. Das ist entscheidend für zeitnahe operative Entscheidungen und dafür, den aus der Analyse gewonnenen Erkenntnissen zu vertrauen. Warum das wichtig ist Informiert Benutzer darüber, wie aktuell die Daten sind. So können Analysen und Entscheidungen auf Grundlage aktueller Informationen erfolgen. Woher beziehen Dieser Wert wird während der Datenextraktion und -transformation (ETL) erzeugt und dem Datensatz hinzugefügt. Beispiele 2024-05-21T02:00:00Z2024-05-20T02:00:00Z
	Quellsystem SourceSystem	Gibt an, aus welchem System die Daten extrahiert wurden.
Beschreibung Dieses Attribut gibt das Ursprungssystem der Prozessdaten an, in diesem Fall Freshservice. Es ist besonders hilfreich, wenn Daten aus mehreren Systemen zusammengeführt werden, um den Prozess umfassend darzustellen. Bei einer Analyse mit nur einem System mag das Attribut überflüssig erscheinen. Dennoch empfiehlt es sich, es im Hinblick auf künftige Skalierung und Data Governance aufzunehmen. Es schafft Klarheit über die Herkunft der Daten und unterstützt die Verwaltung von Datenintegrationspipelines. Warum das wichtig ist Sichert die Herkunft und Rückverfolgbarkeit der Daten. Das ist besonders wichtig, wenn Daten aus mehreren Systemen zusammengeführt werden oder Anforderungen an die Data Governance bestehen. Woher beziehen In der Regel ein statischer Wert, der während der Datenextraktion und -transformation (ETL) hinzugefügt wird. Beispiele FreshserviceFreshservice-API-v2
	Priorität Priority	Die Prioritätsstufe der Serviceanfrage, zum Beispiel niedrig, mittel, hoch oder dringend.
Beschreibung Die Priorität gibt an, wie wichtig und dringlich eine Serviceanfrage ist. Sie bestimmt häufig die angestrebte Lösungszeit und die zugewiesenen Ressourcen. Die Priorität kann automatisch anhand von Regeln oder manuell durch Agents festgelegt werden. Im Process Mining ist die Priorität eine wichtige Analysedimension. Anhand dieser Dimension lassen sich Anfragen gruppieren und Prozessabläufe sowie die Leistung bei Anfragen mit hoher und niedriger Priorität vergleichen. Das ist entscheidend für die Analyse der SLA-Einhaltung und zeigt, ob Anfragen bereits bei der Triage wirksam und zeitnah priorisiert werden. Warum das wichtig ist Entscheidend für die Analyse der SLA-Einhaltung und dafür, zu verstehen, ob Anfragen entsprechend ihrer geschäftlichen Auswirkungen triagiert und bearbeitet werden. Woher beziehen Als Feld „priority“ im Ticketobjekt in Freshservice verfügbar. Beispiele NiedrigMittelHochDringend
	Serviceart ServiceType	Die konkrete Art oder Kategorie der angefragten Serviceleistung.
Beschreibung Die Serviceart ordnet eine Anfrage nach der benötigten Leistung ein, zum Beispiel „Neue Hardware“, „Softwarezugriff“ oder „Passwort zurücksetzen“. Häufig ist sie mit dem Katalogeintrag verknüpft, den der Benutzer ausgewählt hat. Mit diesem Attribut lassen sich Serviceanfragen gruppieren und Prozesse sowie deren Leistung für verschiedene Servicearten vergleichen. Es ist wichtig für die Berechnung von KPIs wie „Durchschnittliche Anzahl von Aktivitäten pro Serviceart“. Damit lässt sich erkennen, welche Services komplexer sind oder mehr Ressourcen beanspruchen. Die Analyse kann dazu beitragen, Prozesse für bestimmte Servicearten zu vereinfachen und zu automatisieren. Warum das wichtig ist Ermöglicht den Vergleich von Prozessabläufen und deren Komplexität für verschiedene Anfragekategorien. So lassen sich Bereiche erkennen, in denen Standardisierung oder Automatisierung sinnvoll ist. Woher beziehen Je nach Konfiguration entspricht dies häufig dem Feld „category“, „item“ oder einem benutzerdefinierten Feld im Ticketobjekt in Freshservice. Beispiele Onboarding neuer MitarbeitenderAnfrage für SoftwarelizenzVPN-Zugriff
	Status Status	Der aktuelle Status der Serviceanfrage im Verlauf ihrer Bearbeitung.
Beschreibung Das Feld „Status“ gibt den Zustand der Serviceanfrage zu einem bestimmten Zeitpunkt an, zum Beispiel „Open“, „Pending“, „Resolved“ oder „Closed“. Statusänderungen sind häufig die wichtigste Quelle für Aktivitäten im Process Mining. Die Analyse des Status liefert Kontext zum Prozessablauf und zeigt, wie viel Zeit Anfragen in bestimmten Zuständen verbringen. Eine lange Dauer im Status „Pending“ kann beispielsweise darauf hindeuten, dass eine Rückmeldung der anfragenden Person oder Informationen von einem externen Dienstleister fehlen. Das Attribut ist wichtig, um Anfang und Ende verschiedener Prozessphasen festzulegen. Warum das wichtig ist Liefert wichtigen Kontext zu jedem Ereignis und hilft dabei, die Dauer in verschiedenen Zuständen wie „Open“ oder „Pending“ zu messen und Verzögerungen zu erkennen. Woher beziehen Als Feld „status“ im Ticketobjekt in Freshservice verfügbar. Beispiele OffenAusstehendGelöstGeschlossen
	Zugewiesener Agent AssignedAgent	Name des Agents, der aktuell für die Serviceanfrage zuständig ist.
Beschreibung Dieses Attribut bezeichnet den Support-Agent, der zu einem bestimmten Zeitpunkt für die Bearbeitung der Serviceanfrage zuständig ist. Die Zuständigkeit kann sich im Verlauf einer Anfrage ändern. Die Analyse des zugewiesenen Agents ist wichtig, um die Leistung der Agents und die Verteilung der Arbeitslast zu verstehen. Sie ermöglicht die Berechnung von KPIs wie der durchschnittlichen Lösungszeit pro Agent, der Anzahl aktiver Anfragen und der Häufigkeit von Neuzuweisungen. So lassen sich besonders leistungsstarke Agents, möglicher Schulungsbedarf und eine unausgewogene Arbeitsverteilung erkennen. Warum das wichtig ist Ermöglicht die Analyse der Arbeitslast und Leistung der Agents sowie der Auswirkungen von Neuzuweisungen auf die Lösungszeiten. Woher beziehen Als Feld „agent“ oder „responder“ im Ticketobjekt in Freshservice verfügbar. Beispiele Alice JohnsonRobert SmithNicht zugewiesen
	Zugewiesenes Team AssignedTeam	Das Support-Team oder die Gruppe, die mit der Bearbeitung der Serviceanfrage betraut ist.
Beschreibung Dieses Attribut gibt die zuständige Fachgruppe oder das zuständige Team an, zum Beispiel „IT-Support Ebene 2“ oder „Hardwarebeschaffung“. Eine Anfrage kann einem Team zugewiesen werden, bevor ein einzelner Agent sie übernimmt. Die Analyse nach zugewiesenem Team hilft dabei, die Leistung und Arbeitslast auf Teamebene zu verstehen und Engpässe in bestimmten Fachbereichen zu erkennen. Sie ist wichtig, um zu beurteilen, wie effizient die verschiedenen Teams Anfragen bearbeiten und wie sich Ressourcen innerhalb der Supportorganisation besser verteilen lassen. Warum das wichtig ist Ermöglicht die Analyse von Leistung und Arbeitslast auf Team- oder Gruppenebene. Das ist wichtig für die Ressourcenplanung und die Erkennung von Engpässen in einzelnen Fachbereichen. Woher beziehen Als Feld „group“ im Ticketobjekt in Freshservice verfügbar. Beispiele Service DeskNetzwerkbetriebAnwendungssupport
	Abteilung der anfragenden Person RequestorDepartment	Die Abteilung, der die anfragende Person angehört.
Beschreibung Dieses Attribut gibt die organisatorische Abteilung der Person an, die die Serviceanfrage eingereicht hat, zum Beispiel Vertrieb, Finanzen oder Personal. Die Information stammt in der Regel aus dem Benutzerprofil im System. Die Analyse der Prozessleistung nach Abteilung ist häufig erforderlich. Sie kann zeigen, ob bestimmte Abteilungen längere Lösungszeiten haben oder besondere Prozessanforderungen stellen. Die Erkenntnisse können in die Ressourcenplanung, Schulungsmaßnahmen oder die Entwicklung abteilungsspezifischer Serviceangebote einfließen. Warum das wichtig ist Ermöglicht die Auswertung des Prozesses nach Geschäftseinheit und hilft dabei, abteilungsspezifische Probleme oder Leistungsunterschiede zu erkennen. Woher beziehen Diese Information ist mit dem Profil der anfragenden Person verknüpft. Sie kann in einem Standardfeld „department“ oder einem benutzerdefinierten Benutzerfeld in Freshservice gespeichert sein. Beispiele FinanzenMarketingInformationstechnologie
	Anfragende Person Requestor	Der Benutzer, der die Serviceanfrage eingereicht hat.
Beschreibung Dieses Attribut bezeichnet die Person, in der Regel einen Mitarbeitenden, die die Serviceanfrage gestellt hat. Es gibt Aufschluss darüber, wer den Service Desk in Anspruch nimmt und welchen Bedarf die Person hat. Die anfragende Person ist nicht immer eine zentrale Dimension für die Analyse des Prozessablaufs. Eine Auswertung nach Person oder zugehöriger Abteilung kann dennoch Muster aufdecken. So könnte sich zeigen, dass eine bestimmte Abteilung häufig unvollständige Anfragen einreicht und gezielte Schulungen benötigt. Das Attribut ist außerdem wichtig für Analysen zur Customer Experience. Warum das wichtig ist Liefert Kontext zur Person, die die Anfrage gestellt hat, und ermöglicht die Analyse von Anfragemustern nach Person, Abteilung oder Standort. Woher beziehen Als Feld „requester“ im Ticketobjekt in Freshservice verfügbar. Beispiele John DoeJane SmithServicekonto
	Anzahl der Neuzuweisungen ReassignmentCount	Wie oft eine Serviceanfrage insgesamt einem anderen Agent oder Team zugewiesen wurde.
Beschreibung Dieses berechnete Attribut zählt für jede Serviceanfrage die Ereignisse „Anfrage neu zugewiesen“ oder ähnliche Aktivitäten. Eine hohe Zahl an Neuzuweisungen weist häufig auf Probleme bei der ersten Triage, eine ungeeignete kompetenzbasierte Weiterleitung oder eine unausgewogene Arbeitslast hin. Das Attribut unterstützt direkt das Dashboard zur Leistung und Arbeitslastverteilung der Agents sowie den KPI „Durchschnittliche Anzahl der Neuzuweisungen pro Anfrage“. Die Analyse hilft Unternehmen, Schwachstellen im Prozess zu erkennen, durch die Tickets weitergereicht werden. Das verlängert die Lösungszeit und belastet Agents wie anfragende Personen. Warum das wichtig ist Misst Ineffizienzen bei der Weiterleitung und Reibungsverluste im Prozess. Eine hohe Zahl weist auf Probleme bei der ersten Triage oder der Arbeitslast der Agents hin, die zu Verzögerungen führen. Woher beziehen Wird bei der Datentransformation berechnet, indem für jede „ServiceRequestId“ bestimmte Aktivitäten zur Änderung der Zuweisung gezählt werden. Beispiele 013
	Endzeit EndTime	Der genaue Timestamp, zu dem die Aktivität abgeschlossen wurde.
Beschreibung Die Endzeit bezeichnet den Timestamp, zu dem eine Aktivität abgeschlossen wurde. Bei vielen Ereignissen in Freshservice sind Start- und Endzeit identisch, da sie zu einem bestimmten Zeitpunkt stattfinden. Bei Aktivitäten, die auf Statusänderungen beruhen, entspricht die Endzeit jedoch dem Timestamp der nächsten Statusänderung. Dieses Attribut ist wichtig, um die Dauer von Aktivitäten und die Wartezeiten zwischen ihnen zu berechnen. Wird die Startzeit von der Endzeit abgezogen, lässt sich die Verarbeitungszeit einer bestimmten Aufgabe ermitteln. So können Sie erkennen, welche Aktivitäten am meisten Zeit beanspruchen und sich besonders für eine Optimierung eignen. Warum das wichtig ist Ermöglicht die Berechnung von Aktivitätsdauern. Das ist grundlegend, um Engpässe zu erkennen und die Verarbeitungszeiten einzelner Schritte zu messen. Woher beziehen Dies ist kein direktes Feld in den Freshservice-Logs. Der Wert muss aus dem Timestamp des nachfolgenden Ereignisses in der Abfolge der jeweiligen Serviceanfrage abgeleitet werden. Beispiele 2023-10-26T10:05:15Z2023-10-26T14:00:20Z2023-10-28T09:30:00Z
	Kanal Channel	Der Weg oder Kanal, über den die Serviceanfrage eingereicht wurde.
Beschreibung Der Kanal gibt an, wie die Serviceanfrage erstellt wurde, zum Beispiel über das Self-Service-Portal, per E-Mail, telefonisch oder im Chat. Diese Information hilft dabei, die Präferenzen der Benutzer und die Effizienz der einzelnen Kanäle zu verstehen. Eine Analyse nach Kanal kann wichtige Erkenntnisse liefern. Über das Portal eingereichte Anfragen sind beispielsweise möglicherweise vollständiger und werden schneller gelöst als Anfragen per E-Mail, bei denen oft mehrere Rückfragen nötig sind. Die Ergebnisse können dabei helfen, effizientere Kanäle stärker zu fördern. Warum das wichtig ist Hilft zu analysieren, ob der Einreichungskanal die Prozesseffizienz, die Lösungszeit oder den Umfang der erforderlichen Nacharbeit beeinflusst. Woher beziehen Als Feld „source“ im Ticketobjekt in Freshservice verfügbar. Beispiele E-MailPortalTelefonChat
	Nacharbeit IsRework	Ein boolesches Kennzeichen dafür, ob bei der Anfrage Nacharbeiten angefallen sind.
Beschreibung Dieses berechnete Kennzeichen wird auf „wahr“ gesetzt, wenn bei einer Serviceanfrage bestimmte Aktivitäten auftreten, die auf Nacharbeit hindeuten. Beispiele sind das erneute Öffnen nach der Lösung („Service Request Reopened“), mehrere Neuzuweisungen oder wiederholte Informationsanfragen an die anfragende Person („Information Requested from Requestor“). Das Attribut vereinfacht die Analyse von Prozessineffizienzen. Damit lassen sich Cases mit Nacharbeit filtern und ihre Prozesslandkarten und Zykluszeiten mit denen von Cases ohne Nacharbeit vergleichen. Es unterstützt direkt das Dashboard zur Nacharbeitsanalyse von Serviceanfragen und hilft, die Auswirkungen ineffizienter Übergaben oder unvollständiger Angaben zu Beginn zu beziffern. Warum das wichtig ist Ermöglicht es, Cases mit ineffizienten Schleifen oder wiederholten Schritten einfach zu kennzeichnen und zu analysieren. So lassen sich die Kosten mangelhafter Qualität beziffern. Woher beziehen Wird während der Datentransformation berechnet, indem Geschäftsregeln auf die Abfolge der Aktivitäten für jede „ServiceRequestId“ angewendet werden. Beispiele truefalse
	Name der SLA-Richtlinie SlaPolicyName	Name der Service-Level-Agreement-Richtlinie (SLA), die für die Anfrage gilt.
Beschreibung Dieses Attribut bezeichnet die SLA-Richtlinie, die die angestrebten Reaktions- und Lösungszeiten für die Serviceanfrage festlegt. Die Richtlinien richten sich üblicherweise nach Faktoren wie Priorität, Serviceart oder Gruppe der anfragenden Person. Für das Dashboard zur SLA-Einhaltung und zu SLA-Verstößen muss bekannt sein, welche SLA-Richtlinie gilt. So lässt sich die Leistung genau an den festgelegten Zielen messen und analysieren, welche Richtlinien besonders häufig verletzt werden. Daraus können sich Anpassungen am Prozess oder an der Umsetzbarkeit der SLA-Ziele ergeben. Warum das wichtig ist Gibt die konkreten Serviceziele an, an denen die Anfrage gemessen wird. Das ist wichtig für eine genaue Berichterstattung zur SLA-Einhaltung. Woher beziehen Diese Information ist Teil der SLA-Daten, die einem Ticket zugeordnet sind. Möglicherweise müssen dafür bestimmte SLA-bezogene API-Endpunkte oder Felder abgefragt werden. Beispiele Vorfälle mit hoher Priorität: 4 Std.Standardanfragen: 3 TageVIP-Support: 1 Std.
	SLA überschritten IsSlaBreached	Ein boolesches Kennzeichen dafür, ob die Serviceanfrage die SLA-Zielfrist für die Lösung überschritten hat.
Beschreibung Dieses berechnete Attribut ist ein einfaches Wahr-oder-falsch-Kennzeichen. Es gibt an, ob das Ticket nach dem SLA-Fälligkeitsdatum geschlossen wurde. Der Wert wird ermittelt, indem der Timestamp für „Service Request Closed“ oder „Service Request Resolved“ mit „SlaDueDate“ verglichen wird. Das Attribut vereinfacht die Analyse und Visualisierung im Dashboard zur SLA-Einhaltung. Anfragen lassen sich damit einfach filtern und zusammenfassen, um die SLA-Einhaltungsquote insgesamt zu berechnen. Eine Gruppierung nach diesem Kennzeichen ermöglicht es, die Prozessmerkmale von Anfragen mit überschrittener Frist schnell mit denen von fristgerecht gelösten Anfragen zu vergleichen. Warum das wichtig ist Vereinfacht die Analyse der SLA-Einhaltung durch ein eindeutiges Kennzeichen, mit dem sich Anfragen filtern und zusammenfassen lassen, deren Ziele nicht erreicht wurden. Woher beziehen Dies ist ein berechnetes Feld, das bei der Datentransformation durch den Vergleich des endgültigen Lösungs-Timestamps mit dem Feld „SlaDueDate“ ermittelt wird. Beispiele truefalse
	SLA-Fälligkeitsdatum SlaDueDate	Der Timestamp, bis zu dem die Serviceanfrage gemäß SLA gelöst werden soll.
Beschreibung Dieses Attribut gibt die Frist für die Lösung der Serviceanfrage gemäß der geltenden SLA-Richtlinie an. Es handelt sich um einen berechneten Timestamp, der auf dem Erstellungszeitpunkt der Anfrage, ihrer Priorität und den in der SLA festgelegten Geschäftszeiten basiert. Dieser Datenpunkt ist wichtig, um die aktuelle Leistung zu überwachen und die SLA-Einhaltung im Nachhinein zu analysieren. Durch den Vergleich des tatsächlichen Lösungszeitpunkts mit „SlaDueDate“ lässt sich feststellen, ob die Frist eingehalten oder überschritten wurde. Darauf basiert die Berechnung des KPI zur SLA-Einhaltungsquote. Warum das wichtig ist Dies ist die angestrebte Lösungsfrist. Sie bildet die Grundlage dafür, festzustellen, ob eine Serviceanfrage die SLA eingehalten oder überschritten hat. Woher beziehen Dies ist ein berechnetes Feld in Freshservice, das im Ticket als „Due by“ angezeigt wird. Es ist über die API verfügbar. Beispiele 2023-10-28T17:00:00Z2023-11-01T09:00:00Z

Erforderlich Empfohlen Optional

Aktivitäten im Service-Request-Management

Diese wichtigen Prozessschritte und Meilensteine sollten Sie in Ihrem Event Log erfassen, um Ihre Service-Request-Workflows zuverlässig zu entdecken und zu analysieren.

6 Empfohlen 9 Optional

	Aktivität	Beschreibung
	Anfrage einem Agent zugewiesen	Diese Aktivität markiert den Zeitpunkt, zu dem eine Serviceanfrage einem bestimmten Agent zur Bearbeitung zugewiesen wird. Sie ist ein wichtiger Meilenstein und lässt sich anhand von Änderungen am Feld „Zugewiesener Agent“ oder „Verantwortlicher“ des Tickets ermitteln.
Warum das wichtig ist Diese Aktivität ist wichtig, um die Arbeitslast der Agents zu analysieren und Engpässe bei der Zuweisung zu erkennen. Die Zeit zwischen Erstellung und Zuweisung ist eine wichtige Leistungskennzahl. Woher beziehen Die Aktivität wird anhand des Aktivitätsprotokolls oder des Audit-Trails der Ticketfelder ermittelt. Dazu werden Änderungen am Feld „Agent“ oder „Zuständiger“ überwacht. Erfassung Erfassen Sie den Timestamp, zu dem das Feld „Zugewiesener Agent“ ausgefüllt oder sein Wert geändert wird. Ereignistyp inferred
	Externer Dienstleister eingebunden	Diese Aktivität markiert die Übergabe eines Tickets an einen externen Dienstleister oder Dritten zur Lösung. Sie wird anhand einer Statusänderung in einen bestimmten Status wie „Warten auf Dienstleister“ oder „Warten auf Dritte“ ermittelt.
Warum das wichtig ist Die Einbindung eines Dienstleisters kann erhebliche Verzögerungen verursachen. Die Erfassung dieser Aktivität ist wichtig, um die Leistung des Dienstleisters und ihre Auswirkungen auf die gesamte Durchlaufzeit der Serviceanfrage zu messen. Woher beziehen Die Aktivität wird aus dem Verlauf der Statusänderungen des Tickets abgeleitet. Suchen Sie nach einem Status, der speziell zur Erfassung der Abhängigkeit von externen Dienstleistern eingerichtet wurde. Erfassung Erkennen Sie, wenn sich das Statusfeld des Tickets in einen Wert ändert, der auf eine Wartezeit bei einem Dritten hinweist. Ereignistyp inferred
	Serviceanfrage erstellt	Diese Aktivität markiert den Beginn des Lebenszyklus einer Serviceanfrage. Sie wird erfasst, wenn in Freshservice eine neue Anfrage offiziell angelegt wird. Das geschieht beispielsweise über den Servicekatalog, per E-Mail oder über einen anderen Kanal. Dabei wird eine eindeutige Service Request ID erstellt.
Warum das wichtig ist Dies ist das primäre Start-Event des Prozesses. Die Zeitspanne zwischen dieser Aktivität und den folgenden Aktivitäten ist eine wichtige Grundlage, um die gesamte Durchlaufzeit zu messen und Verzögerungen zu Beginn der Bearbeitung zu erkennen. Woher beziehen Dieses Ereignis wird in Freshservice ausdrücklich erfasst. Sie finden es im Aktivitätsprotokoll oder im Audit-Trail des Tickets. In der Regel entspricht es dem Timestamp der Ticketerstellung. Erfassung Verwenden Sie den Timestamp der Ticketerstellung aus den Freshservice-Ticketdaten. Ereignistyp explicit
	Serviceanfrage gelöst	Dieser wichtige Meilenstein markiert den Zeitpunkt, zu dem der Agent eine Lösung bereitgestellt hat und die Arbeit als abgeschlossen betrachtet. Er wird anhand einer Änderung des Ticketstatus zu „Gelöst“ ermittelt.
Warum das wichtig ist Diese Aktivität markiert das Ende der aktiven Bearbeitungsphase. Die Dauer bis zu diesem Zeitpunkt ist eine wichtige Kennzahl für die Effizienz der Agents und des Prozesses. Sie bildet außerdem die Grundlage für SLA-Berechnungen. Woher beziehen Die Aktivität wird aus dem Verlauf der Statusänderungen des Tickets abgeleitet. Sie entspricht dem Timestamp, zu dem der Status erstmals auf „Gelöst“ gesetzt wurde. Erfassung Erfassen Sie den Timestamp, zu dem sich der Ticketstatus erstmals zu „Gelöst“ ändert. Ereignistyp inferred
	Serviceanfrage geschlossen	Dies ist die letzte Aktivität und markiert das Ende des Lebenszyklus der Serviceanfrage. Sie tritt üblicherweise automatisch ein, nachdem das Ticket eine festgelegte Zeit lang den Status „Gelöst“ hatte, ohne wiedereröffnet zu werden.
Warum das wichtig ist Dieses Ereignis markiert das endgültige Ende der Prozessinstanz. Die Zeit zwischen „Resolved“ und „Closed“ bildet das Bestätigungsfenster für die anfragende Person. Woher beziehen Abgeleitet aus dem Verlauf der Statusänderungen des Tickets. Der Timestamp entspricht dem Zeitpunkt, an dem sich der Status zu „Closed“ ändert. Erfassung Erfassen Sie den Timestamp, zu dem sich der Ticketstatus zu „Closed“ ändert. Ereignistyp inferred
	SLA-Ziel verfehlt	Dieses berechnete Ereignis tritt ein, wenn die Bearbeitungszeit einer Serviceanfrage das festgelegte Ziel des Service Level Agreement (SLA) überschreitet. Es handelt sich nicht um ein direktes Systemereignis. Das Ereignis wird abgeleitet, indem die Bearbeitungszeit mit dem SLA-Fälligkeitstermin verglichen wird.
Warum das wichtig ist Dieses Ereignis misst die Serviceleistung direkt an den vereinbarten Zusagen und ist eine wichtige KPI für das Management. Es hilft dabei, die Anfragearten und Prioritäten zu ermitteln, bei denen die Zielerreichung am stärksten gefährdet ist. Woher beziehen Das Ereignis wird berechnet, indem der Timestamp „Gelöst“ mit dem Timestamp „SLA fällig am“ verglichen wird. Liegt der Lösungszeitpunkt später, wird das Ereignis ausgelöst. Erfassung Vergleichen Sie den Timestamp der Lösung mit dem Timestamp, zu dem das SLA fällig ist. Wenn resolved_at > sla_due_by gilt, erstellen Sie dieses Ereignis. Ereignistyp calculated
	Anfrage neu zugewiesen	Diese Aktivität erfasst jede Änderung des zugewiesenen Agents oder der Gruppe nach der ersten Zuweisung. Sie wird anhand nachfolgender Aktualisierungen der Felder „Zugewiesener Agent“ oder „Zugewiesene Gruppe“ ermittelt.
Warum das wichtig ist Häufige Neuzuweisungen weisen auf mögliche Probleme bei der anfänglichen Vorsortierung, der Zuordnung nach Kompetenzen oder der Arbeitslastverteilung hin. Diese Aktivität ist wichtig für die KPI zur Anzahl der Neuzuweisungen an Agents und für die Nacharbeitsanalyse. Woher beziehen Die Aktivität wird aus dem Verlauf der Ticketfeldänderungen abgeleitet. Sie wird jedes Mal protokolliert, wenn das Feld „Zugewiesener Agent“ oder „Zugewiesene Gruppe“ nach der ersten Festlegung aktualisiert wird. Erfassung Erkennen Sie nach der ersten Zuweisung jede Änderung am Feld „Zugewiesener Agent“ oder „Zugewiesene Gruppe“. Ereignistyp inferred
	Anfrage priorisiert	Diese Aktivität tritt ein, wenn der Serviceanfrage eine Prioritätsstufe wie niedrig, mittel oder hoch zugewiesen wird. Sie wird anhand einer Änderung des Felds „Priorität“ im Ticketverlauf ermittelt.
Warum das wichtig ist Die Priorisierung ist entscheidend für die Ressourcenzuweisung und die Einhaltung der SLA-Ziele. Durch die Analyse dieser Aktivität lässt sich prüfen, ob Anfragen korrekt und rechtzeitig bewertet werden. Woher beziehen Die Aktivität wird aus dem Verlauf der Feldänderungen in Freshservice abgeleitet. Suchen Sie nach Aktualisierungen des Felds „Priorität“ und erfassen Sie den Timestamp der Änderung. Erfassung Erkennen Sie eine Änderung des Felds „Priorität“ von null oder vom vorherigen Wert und erfassen Sie den Timestamp. Ereignistyp inferred
	Anfrage vorsortiert	Diese Aktivität steht für die erste Prüfung und Kategorisierung einer neu erstellten Serviceanfrage. Sie wird üblicherweise anhand des ersten Zeitpunkts ermittelt, zu dem eine Priorität festgelegt oder die Anfrage einer Gruppe zugewiesen wird. Das zeigt, dass die Anfrage geprüft wurde und in die Warteschlange gelangt.
Warum das wichtig ist Die Erfassung der Vorsortierung hilft dabei, die Effizienz des Teams für die erste Reaktion zu messen. Verzögerungen in dieser Phase können die gesamte Bearbeitungszeit und die Einhaltung der SLA-Ziele erheblich beeinträchtigen. Woher beziehen Die Aktivität wird aus dem Aktivitätsprotokoll abgeleitet. Ermitteln lässt sie sich anhand des Timestamps des ersten Ereignisses „Priorität festgelegt“ oder „Gruppe zugewiesen“, das nach der Erstellung auftritt. Erfassung Ermitteln Sie den frühesten Timestamp einer Änderung am Prioritätsfeld oder am Feld für die zugewiesene Gruppe. Ereignistyp inferred
	Informationen bei Anfragenden angefordert	Diese Aktivität zeigt, dass der zuständige Agent weitere Informationen von den Anfragenden benötigt und die Bearbeitung pausiert. Sie wird anhand einer Statusänderung des Tickets in einen Status wie „Ausstehend“ oder „Warten auf Kunden“ ermittelt.
Warum das wichtig ist Diese Aktivität macht eine häufige Ursache für Verzögerungen und Nacharbeit sichtbar. Anhand ihrer Häufigkeit lässt sich erkennen, wie sich Anfrage-Templates und die anfängliche Datenerfassung verbessern lassen. Woher beziehen Die Aktivität wird aus dem Verlauf der Statusänderungen des Tickets abgeleitet. Suchen Sie nach einem Status wie „Warten auf Kundenantwort“ oder „Warten auf Informationen“. Erfassung Erkennen Sie, wenn sich das Statusfeld des Tickets in einen Wert ändert, der auf eine ausstehende Rückmeldung der Benutzer hinweist. Ereignistyp inferred
	Informationen von Anfragenden erhalten	Diese Aktivität tritt ein, wenn die Anfragenden die benötigten Informationen bereitstellen und der Agent die Bearbeitung fortsetzen kann. Sie wird üblicherweise daran erkannt, dass sich der Ticketstatus automatisch von „Ausstehend“ zurück zu „Offen“ ändert.
Warum das wichtig ist Diese Aktivität schließt die Informationsanforderung ab. Die Zeit zwischen der Anforderung und der Bereitstellung der Informationen ist eine wichtige Wartezeit, die analysiert und verkürzt werden sollte. Woher beziehen Die Aktivität wird aus einer Statusänderung von „Ausstehend“ zurück zu „Offen“ oder „In Bearbeitung“ abgeleitet. Häufig wird sie durch eine Antwort der Anfragenden ausgelöst. Erfassung Erkennen Sie, wenn sich der Ticketstatus von einem ausstehenden in einen offenen Status ändert. Ereignistyp inferred
	Interne Prüfung durchgeführt	Diese Aktivität zeigt an, dass eine vorgeschlagene Lösung oder die Erfüllung einer Anfrage vor der Fortsetzung intern geprüft oder freigegeben werden muss. Sie wird anhand einer Statusänderung in einen Status wie „Freigabe ausstehend“ oder „Interne Prüfung“ ermittelt.
Warum das wichtig ist Interne Prüfungen können Engpässe verursachen, insbesondere bei komplexen oder besonders wichtigen Serviceanfragen. Die Messung ihrer Dauer hilft dabei, Freigabeabläufe zu vereinfachen. Woher beziehen Die Aktivität wird aus dem Verlauf der Statusänderungen des Tickets abgeleitet. Dafür muss im Workflow ein bestimmter Status wie „Interne Freigabe ausstehend“ verwendet werden. Erfassung Erkennen Sie, wenn sich das Statusfeld des Tickets in einen Wert ändert, der auf eine interne Prüfung oder Freigabe hinweist. Ereignistyp inferred
	Lösung von Anfragenden bestätigt	Diese Aktivität steht für die ausdrückliche Bestätigung der Anfragenden, dass die bereitgestellte Lösung zufriedenstellend ist. Sie lässt sich beispielsweise anhand einer positiven Umfrageantwort oder eines bestimmten Kommentars vor dem Schließen des Tickets ermitteln.
Warum das wichtig ist Die Bestätigung liefert direktes Feedback zur Qualität der Lösung. Eine niedrige Bestätigungsquote kann darauf hindeuten, dass Lösungen den Bedarf der Benutzer nicht vollständig erfüllen, auch wenn die Tickets nicht wiedereröffnet werden. Woher beziehen Diese Aktivität lässt sich nur schwer direkt erfassen und erfordert möglicherweise eine benutzerdefinierte Konfiguration. Sie kann beispielsweise anhand einer mit dem Ticket verknüpften Kundenzufriedenheitsumfrage oder eines bestimmten Tags ermittelt werden. Erfassung Dafür müssen zugehörige Daten wie Zufriedenheitsumfragen oder nach der Lösung hinzugefügte Tags analysiert werden. Ereignistyp inferred
	Notiz hinzugefügt	Diese Aktivität umfasst jede öffentliche oder private Notiz, die ein Agent oder eine anfragende Person zur Serviceanfrage hinzufügt. Das Ereignis wird ausdrücklich im Gesprächs- oder Aktivitätsprotokoll des Tickets erfasst.
Warum das wichtig ist Die Häufigkeit und den Zeitpunkt von Notizen zu analysieren, kann Kommunikationsmuster, die Effizienz der Zusammenarbeit und Unklarheiten im Prozess aufzeigen. Woher beziehen Die Notiz wird ausdrücklich im Gesprächsverlauf des Tickets in Freshservice protokolliert. Jede Notiz enthält einen Timestamp und den Namen der verfassenden Person. Erfassung Extrahieren Sie jeden Eintrag aus dem Gesprächs- oder Kommentarprotokoll des Tickets. Ereignistyp explicit
	Serviceanfrage wiedereröffnet	Diese Aktivität tritt ein, wenn Anfragende mitteilen, dass ein Problem nach der Markierung als „Gelöst“ weiterhin besteht. Das Ticket wechselt dadurch zurück in einen offenen Status. Die Aktivität wird anhand einer Statusänderung von „Gelöst“ zurück zu „Offen“ oder „In Bearbeitung“ ermittelt.
Warum das wichtig ist Wiedereröffnete Anfragen weisen deutlich auf eine niedrige Lösungsquote beim ersten Kontakt und auf Unzufriedenheit der Kunden hin. Diese Nachbearbeitungsschleife zu erfassen, ist entscheidend, um die Lösungsqualität zu verbessern. Woher beziehen Die Aktivität wird aus dem Verlauf der Statusänderungen im Aktivitätsprotokoll des Tickets abgeleitet. Sie entspricht einem direkten Statuswechsel von „Gelöst“ zu „Offen“. Erfassung Erkennen Sie eine Statusänderung von „Gelöst“ zu „Offen“. Ereignistyp inferred

Anleitungen zur Datenextraktion

So exportieren Sie Ihre Daten aus Freshservice

Schritte

Voraussetzungen prüfen: Stellen Sie sicher, dass Ihre Freshservice-Benutzerrolle über die Berechtigungen verfügt, im Analytics-Modul auf Berichte zuzugreifen und diese zu erstellen. Dafür ist in der Regel ein Pro- oder Enterprise-Tarif erforderlich.
Automatisierungen konfigurieren (falls erforderlich): Prüfen Sie, ob in Freshservice unter Admin -> Workflow Automator zwei bestimmte Automatisierungen eingerichtet sind, oder erstellen Sie diese. Damit Aktivitäten zuverlässig erfasst werden, muss die erste Automatisierung einem Ticket eine private Notiz oder ein bestimmtes Tag (z. B. 'SLA_Breached') hinzufügen, wenn der SLA-Timer für die Lösung abläuft. Die zweite Automatisierung muss ein bestimmtes Tag (z. B. 'Resolution_Confirmed') hinzufügen, wenn für ein Ticket eine positive Kundenzufriedenheitsumfrage eingeht.
Bericht „Creation Events“ erstellen: Öffnen Sie in Freshservice den Tab Analytics. Erstellen Sie einen neuen Bericht und wählen Sie das Modul 'Tickets' als Datenquelle aus. Der Bericht erfasst das erste Ereignis jeder Serviceanfrage.
Widgets für den Bericht „Creation Events“ konfigurieren: Fügen Sie ein Widget 'Data Table' hinzu. Nehmen Sie folgende Spalten (Kennzahlen) auf: Ticket-ID, Created at, Assigned to, Group, Priority, Status und Category. Filtern Sie nach dem gewünschten Erstellungszeitraum, zum Beispiel nach den letzten 6 Monaten.
Daten aus „Creation Events“ exportieren: Führen Sie den Bericht aus und exportieren Sie die Daten des Tabellen-Widgets in eine CSV-Datei. Nennen Sie die Datei 'creation_events.csv'.
Bericht „Update Events“ erstellen: Erstellen Sie einen zweiten Bericht und wählen Sie diesmal das Modul 'Ticket Activities' als Datenquelle aus. Dieser Bericht erfasst alle nachfolgenden Änderungen und Notizen zu jeder Serviceanfrage.
Widgets für den Bericht „Update Events“ konfigurieren: Fügen Sie ein Widget 'Data Table' hinzu. Nehmen Sie folgende Spalten auf: Ticket-ID, Activity Date, Performed by und Activity Type. Fügen Sie unter 'Changes' die Felder Field, Old Value und New Value hinzu. Ergänzen Sie außerdem Attribute auf Ticketebene wie Group, Assigned to, Priority, Status und Category, damit jedes Ereignis im Kontext steht.
Bericht „Update Events“ filtern: Filtern Sie nach 'Activity Date' und verwenden Sie denselben Zeitraum wie im Bericht zur Erstellung. Schränken Sie 'Activity Type' außerdem auf relevante Ereignisse ein, etwa 'Status changed', 'Priority changed', 'Group changed', 'Agent changed', 'Private Note added' und 'Public Note added'.
Daten aus „Update Events“ exportieren: Führen Sie den Bericht aus und exportieren Sie die Daten des Tabellen-Widgets in eine CSV-Datei. Nennen Sie die Datei 'update_events.csv'.
Daten zusammenführen und umwandeln: Öffnen Sie die beiden CSV-Dateien in einem Tabellenkalkulationsprogramm oder verwenden Sie ein Skript zur Datenaufbereitung. Kopieren Sie alle Daten aus 'update_events.csv' und fügen Sie sie in einer neuen Datei namens 'event_log.csv' unter den Daten aus 'creation_events.csv' ein.
Aktivitäten und Attribute zuordnen: Erstellen Sie in der zusammengeführten Datei 'event_log.csv' die folgenden Spalten: ServiceRequestId, ActivityName, EventTime, SourceSystem, LastDataUpdate, AssignedAgent, AssignedTeam, Priority, Status und ServiceType. Befüllen Sie die Spalten anhand der im folgenden Abschnitt „Abfrage“ beschriebenen Logik. Verwenden Sie Formeln oder ein Skript, um die Rohdaten in das endgültige Event-Log-Format zu überführen.
Abschließender Export: Speichern Sie die umgewandelte Datei 'event_log.csv'. Achten Sie darauf, dass EventTime und LastDataUpdate ein Standardformat wie ISO 8601 verwenden. Die Datei kann nun in ein Process-Mining-Tool hochgeladen werden.

Konfiguration

Freshservice-Tarif: Erforderlich ist ein Tarif mit Analytics-Modul, in der Regel Pro oder Enterprise.
Benutzerberechtigungen: Der Benutzer, der den Export durchführt, benötigt die Berechtigung, Berichte in Analytics zu erstellen und auszuführen.
Zeitraum: Es empfiehlt sich, Daten aus einem aktuellen Zeitraum von beispielsweise 3 bis 6 Monaten zu extrahieren, damit der Datensatz überschaubar bleibt. Verwenden Sie für den Erstellungsbericht einen einheitlichen Datumsfilter auf 'Created at' und für den Aktualisierungsbericht auf 'Activity Date'.
Berichtsfilter: Filtern Sie den Bericht im Modul 'Tickets' nach 'Type' = 'Service Request', um nur den gewünschten Prozess zu erfassen. Schränken Sie im Bericht für 'Ticket Activities' den 'Activity Type' auf relevante Änderungen ein (Status, Priorität, Zuweisung, Notizen), damit der Export möglichst wenige irrelevante Daten enthält.
Erforderliche Automatisierungen: Die Aktivitäten 'SLA Target Breached' und 'Resolution Confirmed by Requestor' lassen sich nur extrahieren, wenn bereits Workflow-Automator-Regeln vorhanden sind, die bei diesen Ereignissen eine Notiz oder ein Tag zum Ticket hinzufügen. Ohne diese Regeln können die Aktivitäten mit dieser Methode nicht erfasst werden.

a Beispielabfrage sql

/*
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: Installieren Sie Python 3.6 oder neuer sowie die Bibliotheken requests und pandas auf Ihrem System. Außerdem benötigen Sie einen Freshservice-API-Schlüssel mit Leseberechtigung für Ticketdaten.
API-Schlüssel abrufen: Melden Sie sich als Administrator bei Ihrer Freshservice-Instanz an. Klicken Sie oben rechts auf Ihr Profilsymbol und öffnen Sie 'Profile Settings'. Ihren API-Schlüssel finden Sie im rechten Bereich. Kopieren Sie ihn und bewahren Sie ihn sicher auf.
Skript speichern: Speichern Sie den bereitgestellten Python-Code auf Ihrem Computer in einer Datei namens extract_freshservice_srm.py.
Skriptparameter konfigurieren: Öffnen Sie das gespeicherte Skript in einem Texteditor. Suchen Sie den Konfigurationsabschnitt am Anfang und ersetzen Sie die Platzhalterwerte für FRESHSERVICE_DOMAIN, API_KEY, START_DATE und END_DATE. Passen Sie das Wörterbuch STATUS_MAPPING an, wenn Ihre Instanz für benutzerdefinierte Status andere numerische IDs verwendet.
Bibliotheken installieren: Falls die erforderlichen Bibliotheken noch nicht installiert sind, öffnen Sie die Befehlszeile oder das Terminal und führen Sie den Befehl pip install requests pandas aus.
Skript ausführen: Wechseln Sie über die Befehlszeile oder das Terminal in das Verzeichnis, in dem Sie das Skript gespeichert haben. Führen Sie es mit dem Befehl python extract_freshservice_srm.py aus.
Ausführung überwachen: Das Skript gibt im Terminal Fortschrittsmeldungen aus und zeigt an, welche Ticketseite gerade verarbeitet wird. Je nach Zeitraum und Ticketvolumen kann die Ausführung einige Zeit dauern.
Event Log abrufen: Nach erfolgreicher Ausführung erstellt das Skript im selben Verzeichnis die Datei freshservice_event_log.csv. Sie enthält das extrahierte Event Log.
Für den Upload vorbereiten: Die erstellte CSV-Datei enthält die erforderlichen Spalten (ServiceRequestId, ActivityName, EventTime, SourceSystem, LastDataUpdate) und kann in ProcessMind hochgeladen werden. Weitere Formatierung ist in der Regel nicht erforderlich.

Konfiguration

FRESHSERVICE_DOMAIN: Die Freshservice-URL Ihrer Organisation, zum Beispiel yourcompany.freshservice.com.
API_KEY: Der persönliche API-Schlüssel aus Ihrem Freshservice-Benutzerprofil. Behandeln Sie ihn vertraulich.
START_DATE / END_DATE: Der Zeitraum für den Ticket-Export im Format 'YYYY-MM-DD'. Für eine erste Analyse empfiehlt sich ein Zeitraum von 3 bis 6 Monaten, um Datenumfang und Erkenntnisgewinn auszubalancieren.
STATUS_MAPPING: Ein wichtiges Python-Wörterbuch im Skript, das benutzerdefinierte Statusnamen zur Ableitung von Ereignissen (z. B. 'External Vendor Engaged') den entsprechenden numerischen Status-IDs in Ihrer Freshservice-Instanz zuordnet. Prüfen und aktualisieren Sie diese IDs unbedingt entsprechend der Konfiguration Ihres Systems.
API-Ratenbegrenzung: Beachten Sie die API-Ratenbegrenzungen Ihres Freshservice-Tarifs. Das Skript verarbeitet Tickets nacheinander, um diese Grenzen einzuhalten. Bei sehr großen Datensätzen müssen Sie den Export möglicherweise in kleinere Zeiträume aufteilen.
Datenumfang: Das Skript ruft nur Tickets vom Typ 'Service Request' ab. Dieser Filter wird beim ersten Abruf der Tickets 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

Prüfen Sie, ob Ihr Freshservice-Abonnement und Ihre Administratorberechtigungen den geplanten Datenexport und die Übermittlung an den ausgewählten Cloud-Speicheranbieter umfassen. Menünamen und Exportfunktionen können je nach Tarif und Mandant variieren. Prüfen Sie daher die aktuelle Administrator-Dokumentation und verwenden Sie [Configure based on your system], wenn der Mandant andere Bezeichnungen anzeigt.
Öffnen Sie in Freshservice den Administrationsbereich und suchen Sie die Konfiguration für den geplanten Datenexport. Wählen Sie die Datenquelle für Serviceanfragen oder Tickets aus, die Service Request ID, Status, Priorität, Zuweisung, Serviceart, Zeitstempel, SLA-Felder, Konversations- oder Aktivitätsverlauf sowie Informationen zu Antworten der Anfragenden enthält. Gehen Sie nicht davon aus, dass ein aktueller Ticketexport historische Feldänderungen enthält.
Legen Sie den Exportumfang fest. Wählen Sie für die erste Validierung einen rollierenden Zeitraum von 3 bis 6 Monaten und anschließend einen wiederkehrenden Zeitplan, der zu den Berichtsanforderungen passt. Nehmen Sie alle Serviceanfragen sowie die erforderlichen historischen Aktivitäts- oder Auditdaten auf, um Feldänderungen, Notizen, Statuswechsel, SLA-Ergebnisse, Freigaben und Bestätigungen durch Anfragende zu erkennen. Verwenden Sie Unternehmens- oder Servicefilter nur, wenn sie ausdrücklich erforderlich sind, und zwar mit [Company or service filter based on your system].
Wählen Sie CSV als Ausgabeformat und richten Sie die Übermittlung an den genehmigten Cloud-Speicherort ein, zum Beispiel Amazon S3. Geben Sie [Cloud storage connection details] und [Credentials or role configuration] über die unterstützte Freshservice-Konfiguration an. Stimmen Sie Bucket, Pfad, Verschlüsselung, Aufbewahrungsdauer und Zugriffsrichtlinie mit der zuständigen Plattformverantwortung ab. Hinterlegen Sie Zugangsdaten nicht direkt in Skripten oder exportierten Dateien.
Führen Sie einen Testexport aus und prüfen Sie die bereitgestellten CSV-Dateien. Ermitteln Sie die tatsächlich exportierten Spaltennamen für Service Request ID, Status, Priorität, zuständigen Agenten, zuständige Gruppe, Serviceart, Erstellungszeitpunkt, Aktualisierungszeitpunkt, Lösungszeitpunkt, Schließungszeitpunkt, SLA-Fälligkeit, Verlaufszeitstempel, Verlaufsfeld, alten Wert, neuen Wert, Notiztyp, Verfasser der Notiz, Zeitstempel der Notiz sowie Antwort der anfragenden Person oder Umfrageergebnis. Ist ein erforderliches Quellfeld nicht verfügbar, dokumentieren Sie diese Einschränkung, statt einen Feldnamen zu erfinden.
Laden Sie die CSV-Dateien in eine Staging-Tabelle oder einen Data Frame. Ersetzen Sie in der folgenden Abfrage die Quellenverweise, darunter [Your ticket table name], [Your ticket history table name], [Your conversation table name], [Your SLA table name] und [Your survey or confirmation table name], durch die tatsächlichen Strukturen aus dem Export. Ordnen Sie die Quellspalten den logischen Feldern der Abfrage zu. Bewahren Sie die Quellzeitstempel auf und vereinheitlichen Sie sie auf eine Zeitzone, vorzugsweise UTC.
Richten Sie die inkrementelle Verarbeitung anhand von [Last successful export timestamp] oder dem Bereitstellungszeitstempel der Exportdatei ein. Verwenden Sie ein ausreichend großes Überlappungsfenster, zum Beispiel 24 bis 48 Stunden, um verspätet eintreffende Verlaufsdaten und Korrekturen zu erfassen. Entfernen Sie Duplikate anhand von ServiceRequestId, ActivityName, EventTime und einer stabilen Quellereignis-ID, sofern verfügbar. Entfernen Sie Duplikate nicht allein anhand von ServiceRequestId, da für eine Anfrage mehrere Ereigniszeilen erforderlich sind.
Führen Sie die vollständige SQL-Transformation aus. Die Abfrage erstellt ausdrücklich Zeilen für alle 15 erforderlichen Aktivitäten, einschließlich abgeleiteter Aktivitäten wie Triage, Neuzuweisung, SLA-Verstoß, Bestätigung durch Anfragende und Abschluss. Wenn der Export keine historischen Belege für eine Aktivität enthält, lässt sich diese nicht zuverlässig erzeugen. Dokumentieren Sie dies als Lücke in den Quelldaten.
Prüfen Sie Zeilenanzahl, Aktivitätsabdeckung, Zeitstempel, Kennungen und befüllte Attribute anhand der folgenden Validierungsprüfungen. Stellen Sie sicher, dass jede ServiceRequestId mehrere chronologisch geordnete Ereignisse haben kann und für jede ausgegebene Zeile ein EventTime vorhanden ist.
Exportieren Sie das Abfrageergebnis als UTF-8-CSV mit den erforderlichen Spalten ServiceRequestId, ActivityName, EventTime, SourceSystem, LastDataUpdate, AssignedAgent, AssignedTeam, Priority, Status und ServiceType. Laden Sie das resultierende Event Log in ProcessMind hoch und ordnen Sie ServiceRequestId als Case-Kennung, ActivityName als Aktivität und EventTime als Ereigniszeitstempel zu. Behandeln Sie SourceSystem und LastDataUpdate je nach ProcessMind-Importkonfiguration als Ereignisattribute oder Metadaten.

Konfiguration

Exportquelle: Wählen Sie den Freshservice-Datensatz für Serviceanfragen oder Tickets sowie, sofern verfügbar, die zugehörigen Verlaufs-, Konversations-, SLA-, Freigabe- und Umfragedatensätze aus. Ein reiner Export des aktuellen Ticketstands reicht nicht aus, um alle angeforderten Aktivitäten zu rekonstruieren.
Zeitplan: Richten Sie einen wiederkehrenden Export ein, der zum betrieblichen Berichtszyklus passt. Verwenden Sie für den ersten Ladevorgang einen Zeitraum von 3 bis 6 Monaten. Nutzen Sie bei inkrementellen Ladevorgängen ein Überlappungsfenster, um verspätet eintreffende Aktualisierungen zu erfassen.
Erforderliche Quelldaten: Stellen Sie sicher, dass der Export eine stabile Service Request ID, Ereignis- oder Aktualisierungszeitstempel, den Statusverlauf, den Prioritätsverlauf, den Zuweisungsverlauf, den Gruppenverlauf, Notizen oder Konversationen, SLA-Fälligkeits- und Abschlussinformationen, Zeitstempel für Lösung und Schließung sowie, sofern verfügbar, Nachweise für Bestätigungen durch Anfragende enthält.
Filter: Verwenden Sie [Company or service filter based on your system] nur, wenn dies erforderlich ist. Vermeiden Sie restriktive Statusfilter, da sie wiedereröffnete, gelöste, geschlossene, ausstehende, an Anbieter übergebene, freizugebende und historische Datensätze ausschließen können.
Cloud-Speicher: Konfigurieren Sie den genehmigten Bucket oder Container, den Pfad, die Verschlüsselung, die Aufbewahrungsdauer und die Zugriffsrichtlinie. Verwenden Sie eine verwaltete Rolle oder einen vom Mandanten unterstützten Mechanismus für Geheimnisse, statt Zugangsdaten in SQL- oder CSV-Dateien einzubetten.
Dateiverarbeitung: Bewahren Sie die ursprünglichen CSV-Dateien, Exportzeitstempel, Schema-Version und Bereitstellungsmetadaten auf. Teilt Freshservice große Exporte auf mehrere Dateien auf, verarbeiten Sie alle Dateien desselben Exportlaufs.
Zeitzonen: Dokumentieren Sie die Quellzeitzone und vereinheitlichen Sie EventTime auf UTC. Bewahren Sie den ursprünglichen Zeitstempel auf, wenn dies für die Auditierbarkeit erforderlich ist.
Leistung: Teilen Sie die Verarbeitung, sofern unterstützt, nach Exportdatum, Ereignisdatum oder ServiceRequestId auf. Laden Sie Rohdateien zunächst in eine Staging-Umgebung, vermeiden Sie wiederholte vollständige Scans des Verlaufs und verwenden Sie inkrementelle Ladevorgänge mit einem kontrollierten Überlappungszeitraum.
Berechtigungen und Lizenzierung: Erforderlich sind Administratorzugriff, die Berechtigung zur Konfiguration geplanter Exporte, Leseberechtigung für die ausgewählten Freshservice-Daten, Schreibzugriff auf den Cloud-Speicher sowie alle Abonnementfunktionen oder Lizenzen, die für die geplante Exportübermittlung benötigt werden.
Datenqualität: Leiten Sie keine Ereignisse allein aus dem aktuellen Wert ab, wenn historische Belege fehlen. Ein aktueller Prioritätswert belegt beispielsweise die Aktivität Request Prioritized nur dann, wenn ein Zeitstempel für die Prioritätszuweisung oder ein Verlaufsdatensatz vorhanden ist.
Quellzuordnung: Ersetzen Sie in der Abfrage alle in eckigen Klammern stehenden Verweise auf Quellobjekte und -spalten durch die tatsächlichen Namen aus dem bereitgestellten Export. Die logischen Namen der Ausgabespalten müssen für die Zuordnung in ProcessMind unverändert bleiben.

a Beispielabfrage sql

WITH
base_requests AS (
    SELECT
        CAST(r.[Service Request ID] AS VARCHAR(255)) AS ServiceRequestId,
        CAST(r.[Assigned Agent] AS VARCHAR(255)) AS AssignedAgent,
        CAST(r.[Assigned Team] AS VARCHAR(255)) AS AssignedTeam,
        CAST(r.[Priority] AS VARCHAR(100)) AS Priority,
        CAST(r.[Status] AS VARCHAR(100)) AS Status,
        CAST(r.[Service Type] AS VARCHAR(255)) AS ServiceType,
        CAST(r.[Created Time] AS TIMESTAMP) AS CreatedTime,
        CAST(r.[Resolved Time] AS TIMESTAMP) AS ResolvedTime,
        CAST(r.[Closed Time] AS TIMESTAMP) AS ClosedTime,
        CAST(r.[SLA Due Time] AS TIMESTAMP) AS SLADueTime,
        CAST(r.[Last Updated Time] AS TIMESTAMP) AS LastUpdatedTime
    FROM [Your ticket table name] r
    WHERE CAST(r.[Created Time] AS TIMESTAMP) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND CAST(r.[Created Time] AS TIMESTAMP) < CAST('[End date parameter]' AS TIMESTAMP)
),
history AS (
    SELECT
        CAST(h.[Service Request ID] AS VARCHAR(255)) AS ServiceRequestId,
        CAST(h.[Event Time] AS TIMESTAMP) AS EventTime,
        CAST(h.[Changed Field] AS VARCHAR(255)) AS ChangedField,
        CAST(h.[Old Value] AS VARCHAR(4000)) AS OldValue,
        CAST(h.[New Value] AS VARCHAR(4000)) AS NewValue,
        CAST(h.[Assigned Agent] AS VARCHAR(255)) AS AssignedAgentAtEvent,
        CAST(h.[Assigned Team] AS VARCHAR(255)) AS AssignedTeamAtEvent,
        CAST(h.[Priority] AS VARCHAR(100)) AS PriorityAtEvent,
        CAST(h.[Status] AS VARCHAR(100)) AS StatusAtEvent,
        CAST(h.[Service Type] AS VARCHAR(255)) AS ServiceTypeAtEvent
    FROM [Your ticket history table name] h
    WHERE CAST(h.[Event Time] AS TIMESTAMP) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND CAST(h.[Event Time] AS TIMESTAMP) < CAST('[End date parameter]' AS TIMESTAMP)
),
conversations AS (
    SELECT
        CAST(c.[Service Request ID] AS VARCHAR(255)) AS ServiceRequestId,
        CAST(c.[Created Time] AS TIMESTAMP) AS EventTime,
        CAST(c.[Author Type] AS VARCHAR(100)) AS AuthorType,
        CAST(c.[Visibility] AS VARCHAR(100)) AS Visibility,
        CAST(c.[Message Type] AS VARCHAR(100)) AS MessageType,
        CAST(c.[Message Text] AS VARCHAR(4000)) AS MessageText
    FROM [Your conversation table name] c
    WHERE CAST(c.[Created Time] AS TIMESTAMP) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND CAST(c.[Created Time] AS TIMESTAMP) < CAST('[End date parameter]' AS TIMESTAMP)
),
sla_events AS (
    SELECT
        CAST(s.[Service Request ID] AS VARCHAR(255)) AS ServiceRequestId,
        CAST(s.[SLA Due Time] AS TIMESTAMP) AS SLADueTime,
        CAST(s.[Resolution Time] AS TIMESTAMP) AS ResolutionTime,
        CAST(s.[SLA Breached] AS VARCHAR(20)) AS SLABreached
    FROM [Your SLA table name] s
),
confirmations AS (
    SELECT
        CAST(f.[Service Request ID] AS VARCHAR(255)) AS ServiceRequestId,
        CAST(f.[Confirmation Time] AS TIMESTAMP) AS EventTime,
        CAST(f.[Confirmation Result] AS VARCHAR(255)) AS ConfirmationResult
    FROM [Your survey or confirmation table name] f
    WHERE CAST(f.[Confirmation Time] AS TIMESTAMP) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND CAST(f.[Confirmation Time] AS TIMESTAMP) < CAST('[End date parameter]' AS TIMESTAMP)
),
events AS (
    SELECT b.ServiceRequestId, 'Service Request Created' AS ActivityName, b.CreatedTime AS EventTime, b.AssignedAgent, b.AssignedTeam, b.Priority, b.Status, b.ServiceType FROM base_requests b WHERE b.CreatedTime IS NOT NULL
    UNION ALL
    SELECT h.ServiceRequestId, 'Request Triaged', h.EventTime, h.AssignedAgentAtEvent, h.AssignedTeamAtEvent, h.PriorityAtEvent, h.StatusAtEvent, h.ServiceTypeAtEvent FROM history h WHERE h.EventTime IS NOT NULL AND (LOWER(h.ChangedField) IN ('priority','assigned agent','owner','assigned group','group') OR LOWER(h.NewValue) IN ('triaged','in queue'))
    UNION ALL
    SELECT h.ServiceRequestId, 'Request Prioritized', h.EventTime, h.AssignedAgentAtEvent, h.AssignedTeamAtEvent, h.PriorityAtEvent, h.StatusAtEvent, h.ServiceTypeAtEvent FROM history h WHERE h.EventTime IS NOT NULL AND LOWER(h.ChangedField) = 'priority' AND COALESCE(h.OldValue, '') <> COALESCE(h.NewValue, '') AND NULLIF(TRIM(h.NewValue), '') IS NOT NULL
    UNION ALL
    SELECT h.ServiceRequestId, 'Request Assigned to Agent', h.EventTime, h.AssignedAgentAtEvent, h.AssignedTeamAtEvent, h.PriorityAtEvent, h.StatusAtEvent, h.ServiceTypeAtEvent FROM history h WHERE h.EventTime IS NOT NULL AND LOWER(h.ChangedField) IN ('assigned agent','owner') AND NULLIF(TRIM(h.NewValue), '') IS NOT NULL AND (h.OldValue IS NULL OR TRIM(h.OldValue) = '')
    UNION ALL
    SELECT h.ServiceRequestId, 'Request Reassigned', h.EventTime, h.AssignedAgentAtEvent, h.AssignedTeamAtEvent, h.PriorityAtEvent, h.StatusAtEvent, h.ServiceTypeAtEvent FROM history h WHERE h.EventTime IS NOT NULL AND LOWER(h.ChangedField) IN ('assigned agent','owner','assigned group','group') AND COALESCE(h.OldValue, '') <> COALESCE(h.NewValue, '') AND NULLIF(TRIM(h.OldValue), '') IS NOT NULL
    UNION ALL
    SELECT h.ServiceRequestId, 'Information Requested from Requestor', h.EventTime, h.AssignedAgentAtEvent, h.AssignedTeamAtEvent, h.PriorityAtEvent, h.StatusAtEvent, h.ServiceTypeAtEvent FROM history h WHERE h.EventTime IS NOT NULL AND LOWER(h.ChangedField) = 'status' AND LOWER(h.NewValue) IN ('pending','awaiting customer','awaiting requestor')
    UNION ALL
    SELECT h.ServiceRequestId, 'Information Provided by Requestor', h.EventTime, h.AssignedAgentAtEvent, h.AssignedTeamAtEvent, h.PriorityAtEvent, h.StatusAtEvent, h.ServiceTypeAtEvent FROM history h WHERE h.EventTime IS NOT NULL AND LOWER(h.ChangedField) = 'status' AND LOWER(h.OldValue) IN ('pending','awaiting customer','awaiting requestor') AND LOWER(h.NewValue) IN ('open','in progress')
    UNION ALL
    SELECT h.ServiceRequestId, 'External Vendor Engaged', h.EventTime, h.AssignedAgentAtEvent, h.AssignedTeamAtEvent, h.PriorityAtEvent, h.StatusAtEvent, h.ServiceTypeAtEvent FROM history h WHERE h.EventTime IS NOT NULL AND LOWER(h.ChangedField) = 'status' AND LOWER(h.NewValue) IN ('pending vendor','awaiting third party','vendor')
    UNION ALL
    SELECT h.ServiceRequestId, 'Internal Review Performed', h.EventTime, h.AssignedAgentAtEvent, h.AssignedTeamAtEvent, h.PriorityAtEvent, h.StatusAtEvent, h.ServiceTypeAtEvent FROM history h WHERE h.EventTime IS NOT NULL AND LOWER(h.ChangedField) = 'status' AND LOWER(h.NewValue) IN ('pending approval','internal review','awaiting approval')
    UNION ALL
    SELECT c.ServiceRequestId, 'Note Added', c.EventTime, b.AssignedAgent, b.AssignedTeam, b.Priority, b.Status, b.ServiceType FROM conversations c LEFT JOIN base_requests b ON b.ServiceRequestId = c.ServiceRequestId WHERE c.EventTime IS NOT NULL AND (LOWER(COALESCE(c.MessageType, '')) IN ('note','comment','reply') OR LOWER(COALESCE(c.Visibility, '')) IN ('public','private'))
    UNION ALL
    SELECT h.ServiceRequestId, 'Service Request Reopened', h.EventTime, h.AssignedAgentAtEvent, h.AssignedTeamAtEvent, h.PriorityAtEvent, h.StatusAtEvent, h.ServiceTypeAtEvent FROM history h WHERE h.EventTime IS NOT NULL AND LOWER(h.ChangedField) = 'status' AND LOWER(h.OldValue) = 'resolved' AND LOWER(h.NewValue) IN ('open','in progress')
    UNION ALL
    SELECT s.ServiceRequestId, 'SLA Target Breached', COALESCE(s.ResolutionTime, s.SLADueTime), b.AssignedAgent, b.AssignedTeam, b.Priority, b.Status, b.ServiceType FROM sla_events s LEFT JOIN base_requests b ON b.ServiceRequestId = s.ServiceRequestId WHERE LOWER(COALESCE(s.SLABreached, '')) IN ('true','yes','1') AND s.SLADueTime IS NOT NULL AND COALESCE(s.ResolutionTime, CURRENT_TIMESTAMP) > s.SLADueTime
    UNION ALL
    SELECT h.ServiceRequestId, 'Service Request Resolved', h.EventTime, h.AssignedAgentAtEvent, h.AssignedTeamAtEvent, h.PriorityAtEvent, h.StatusAtEvent, h.ServiceTypeAtEvent FROM history h WHERE h.EventTime IS NOT NULL AND LOWER(h.ChangedField) = 'status' AND LOWER(h.NewValue) = 'resolved'
    UNION ALL
    SELECT c.ServiceRequestId, 'Resolution Confirmed by Requestor', c.EventTime, b.AssignedAgent, b.AssignedTeam, b.Priority, b.Status, b.ServiceType FROM confirmations c LEFT JOIN base_requests b ON b.ServiceRequestId = c.ServiceRequestId WHERE c.EventTime IS NOT NULL AND LOWER(c.ConfirmationResult) IN ('positive','satisfied','confirmed','yes','resolved')
    UNION ALL
    SELECT h.ServiceRequestId, 'Service Request Closed', h.EventTime, h.AssignedAgentAtEvent, h.AssignedTeamAtEvent, h.PriorityAtEvent, h.StatusAtEvent, h.ServiceTypeAtEvent FROM history h WHERE h.EventTime IS NOT NULL AND LOWER(h.ChangedField) = 'status' AND LOWER(h.NewValue) = 'closed'
)
SELECT
    e.ServiceRequestId,
    e.ActivityName,
    e.EventTime,
    'Freshservice' AS SourceSystem,
    CAST('[Last data update timestamp]' AS TIMESTAMP) AS LastDataUpdate,
    e.AssignedAgent,
    e.AssignedTeam,
    e.Priority,
    e.Status,
    e.ServiceType
FROM events e
WHERE e.ServiceRequestId IS NOT NULL
  AND e.EventTime IS NOT NULL
ORDER BY e.ServiceRequestId, e.EventTime, e.ActivityName;

Möchten Sie loslegen?

Bereiten Sie Ihre Daten vor und machen Sie den ersten Schritt zur Optimierung Ihres Service-Request-Prozesses. Wir unterstützen Sie dabei, Ihre Servicebereitstellung zu verbessern.

Zurück zum Leitfaden zur Prozessverbesserung Template herunterladen

Steigern Sie jetzt die Effizienz des Service-Request-Prozesses in Freshservice

Verkürzen Sie lange Bearbeitungszeiten und reduzieren Sie die Frustration der Benutzer. Erreichen Sie eine Automatisierungsquote von 70 %.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. In wenigen Minuten eingerichtet.

Ihr Daten-Template für das Service-Request-Management

Ihr Daten-Template für das Service-Request-Management

Attribute des Service-Request-Managements

Aktivitäten im Service-Request-Management

Anleitungen zur Datenextraktion

Datenexport aus dem Freshservice Analytics-Modul

Schritte

Konfiguration

a Beispielabfrage sql

Python-Skript mit der Freshservice-REST-API

Schritte

Konfiguration

a Beispielabfrage python

Geplanter Freshservice-Datenexport in Cloud-Speicher

Schritte

Konfiguration

a Beispielabfrage sql

Möchten Sie loslegen?

Steigern Sie jetzt die Effizienz des Service-Request-Prozesses in Freshservice

Ihr Daten-Template für das Service-Request-Management

Ihr Daten-Template für das Service-Request-Management

Attribute des Service-Request-Managements

Aktivitäten im Service-Request-Management

Anleitungen zur Datenextraktion

Datenexport aus dem Freshservice Analytics-Modul

Schritte

Konfiguration

a Beispielabfrage sql

Python-Skript mit der Freshservice-REST-API

Schritte

Konfiguration

a Beispielabfrage python

Geplanter Freshservice-Datenexport in Cloud-Speicher

Schritte

Konfiguration

a Beispielabfrage sql

Möchten Sie loslegen?

Steigern Sie jetzt die Effizienz des Service-Request-Prozesses in Freshservice

Der Schutz Ihrer Daten ist uns wichtig