Ihre Kundenservice-Datentemplate
Ihre Kundenservice-Datentemplate
- Empfohlene Attribute zur Erfassung
- Wichtige Aktivitäten zur Verfolgung
- Extraktionsanleitung
Kundenservice-Attribute
| Name | Beschreibung | ||
|---|---|---|---|
|
Ereigniszeit
EventTime
|
Der genaue Zeitstempel, der angibt, wann eine spezifische Aktivität oder ein Ereignis stattfand. | ||
|
Beschreibung
Event Time erfasst Datum und Uhrzeit, zu der eine Aktivität durchgeführt wurde. Dieser Timestamp ist grundlegend für die chronologische Anordnung von Events und für die Berechnung von Dauern zwischen verschiedenen Schritten im Prozess. In der Process Mining Analyse wird dieses Attribut verwendet, um alle zeitbasierten Metriken zu berechnen, einschließlich Cycle Times, Wartezeiten und Bearbeitungsdauern. Es ermöglicht Analysten, Bottlenecks zu identifizieren, indem Aktivitäten mit langen Verzögerungen vor ihnen gefunden werden, und die Performance im Vergleich zu Service Level Agreements (SLAs) zu messen. Genaue und konsistente Timestamps sind für eine zuverlässige Analyse unerlässlich.
Bedeutung
Dieser Zeitstempel ist entscheidend für die korrekte Reihenfolge von Ereignissen und die Berechnung aller Leistungsmetriken, wie Zykluszeiten und Engpässe.
Datenquelle
Dies entspricht typischerweise dem Feld 'sys_created_on' in den Audit- und History-Tabellen von ServiceNow (z.B. 'sys_audit').
Beispiele
2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:05:11Z
|
|||
|
Serviceanfrage
ServiceRequest
|
Der eindeutige Identifikator für jede Kundenserviceanfrage, jeden Fall oder jedes Ticket. | ||
|
Beschreibung
Die Serviceanfrage ist die primäre Fall-ID, die alle zugehörigen Aktivitäten und Ereignisse für ein einzelnes Kundenproblem, von der Erstellung bis zum Abschluss, verknüpft. Sie dient als zentraler Leitfaden zur Verfolgung der End-to-End-Reise einer Kundeninteraktion. Im Process Mining ist dieses Attribut grundlegend für die Rekonstruktion des Prozessflusses. Jeder eindeutige Wert der Serviceanfrage repräsentiert eine Instanz des Prozesses und ermöglicht die Analyse von Zykluszeiten, Pfaden und Variationen auf Fallbasis. Es stellt sicher, dass alle Schritte, vom ersten Kontakt bis zur endgültigen Lösung und zum Abschluss, korrekt der gleichen Kundenanfrage zugeordnet werden.
Bedeutung
Dies ist die essenzielle Fall-ID, die alle Prozessschritte verbindet und die Analyse des gesamten Lebenszyklus jeder Kundenservice-Interaktion ermöglicht.
Datenquelle
Dies ist typischerweise das Feld 'number' aus der Tabelle 'sn_customerservice_case' in ServiceNow CSM.
Beispiele
CS0010001CS0010045CS0010112
|
|||
|
Aktivitätsname
ActivityName
|
Der Name eines spezifischen Ereignisses oder einer Aufgabe, die innerhalb des Serviceanfrage-Lebenszyklus aufgetreten ist. | ||
|
Beschreibung
Der Aktivitätsname beschreibt einen Schritt im Kundenserviceprozess, wie 'Serviceanfrage erstellt', 'Anfrage Agent zugewiesen' oder 'Lösung vorgeschlagen'. Diese Aktivitäten werden aus Systemprotokollen oder Tabellenaktualisierungen extrahiert, um eine chronologische Abfolge von Ereignissen für jede Serviceanfrage zu erstellen. Dieses Attribut ist entscheidend für die Visualisierung der Prozesslandkarte, die Identifizierung von Engpässen und das Verständnis des Arbeitsflusses. Durch die Analyse der Reihenfolge und Häufigkeit von Aktivitäten können Analysten gängige Prozesspfade, Abweichungen und Bereiche von Nacharbeit oder Ineffizienz aufdecken. Die Granularität der definierten Aktivitäten beeinflusst direkt die Tiefe der Erkenntnisse, die aus dem Prozessmodell gewonnen werden können.
Bedeutung
Dieses Attribut bildet das Rückgrat der Prozesslandkarte und definiert die spezifischen Schritte und Aufgaben, deren Reihenfolge und Dauer analysiert werden.
Datenquelle
Dies ist ein konzeptionelles Attribut, das aus System-Audit-Tabellen (z.B. 'sys_audit') oder durch die Verfolgung von Statusänderungen und wichtigen Feldaktualisierungen in der Tabelle 'sn_customerservice_case' abgeleitet wird.
Beispiele
Serviceanfrage erstelltAnfrage einem Agenten zugewiesenVom Kunden angeforderte InformationenServiceanfrage gelöst
|
|||
|
`SLA` verletzt
IsSlaBreached
|
Ein boolesches Flag, das anzeigt, ob die Serviceanfrage ihr definiertes Service Level Agreement (SLA) Ziel überschritten hat. | ||
|
Beschreibung
Dieses berechnete Attribut gibt an, ob eine Serviceanfrage innerhalb des vereinbarten Zeitrahmens gelöst wurde. Es ist typischerweise 'Wahr', wenn die Lösungszeit das SLA-Ziel überschritten hat, und 'Falsch' andernfalls. Dies liefert ein klares, binäres Ergebnis für die SLA-Leistung jedes Falls. Dieses Attribut ist essenziell für das Dashboard 'SLA-Einhaltung und Verletzungstrends' und den KPI 'SLA-Einhaltungsrate'. Es vereinfacht die Analyse, indem es ein direktes Filtern und Zählen von verletzten Fällen ermöglicht, wodurch leicht identifiziert werden kann, welche Arten von Anfragen, Prioritäten oder Teams am häufigsten mit SLA-Verletzungen in Verbindung gebracht werden.
Bedeutung
Bietet eine klare Ja- oder Nein-Antwort darauf, ob ein Fall seine Frist eingehalten hat, was für die Messung und Berichterstattung der SLA-Konformität grundlegend ist.
Datenquelle
Berechnet basierend auf dem Feld 'made_sla' aus der Tabelle 'task_sla' oder abgeleitet durch den Vergleich der tatsächlichen Lösungszeit mit der geplanten Lösungszeit.
Beispiele
truefalsch
|
|||
|
Bearbeitungsgruppe
AssignmentGroup
|
Das Team oder die Abteilung, die für die Serviceanfrage verantwortlich ist. | ||
|
Beschreibung
Die Zuweisungsgruppe repräsentiert die Warteschlange oder das Team, dem eine Serviceanfrage zugewiesen wird. Anfragen werden oft je nach Art des Problems zwischen verschiedenen Gruppen geleitet, z. B. einem Level-1-Support-Desk, einem spezialisierten technischen Team oder einer Abrechnungsabteilung. Dieses Attribut ist unerlässlich für die Analyse von Übergaben zwischen Abteilungen und die Identifizierung von Engpässen auf Teamebene. Es hilft, den Arbeitsfluss zwischen verschiedenen Funktionsbereichen zu visualisieren und kann Gruppen hervorheben, die überlastet sind oder zusätzliche Schulungen benötigen. Dies unterstützt direkt die Dashboards 'Agenten-Übergaben und Neuzuweisungen' und 'Prozessfluss'.
Bedeutung
Identifiziert, welches Team für die Arbeit verantwortlich ist, was entscheidend für die Analyse der Team-Performance, Arbeitslasten und Prozessübergaben zwischen Abteilungen ist.
Datenquelle
Dies entspricht dem Feld 'assignment_group' in der Tabelle 'sn_customerservice_case'.
Beispiele
`Service Desk`AbrechnungsanfragenTechnischer Support Stufe 2
|
|||
|
Kategorie
Category
|
Die primäre Klassifizierung der Serviceanfrage, z. B. 'Abrechnung' oder 'Technisches Problem'. | ||
|
Beschreibung
Die Kategorie bietet eine übergeordnete Gruppierung für Serviceanfragen basierend auf der Art der Kundenanfrage oder des Problems. Diese Klassifizierung erfolgt typischerweise bei der erstmaligen Erstellung der Anfrage und hilft bei der Weiterleitung an die richtige Zuweisungsgruppe. Dieses Attribut ist essenziell für die Segmentierung der Prozessanalyse. Durch das Filtern nach Kategorie können Analysten die Prozessabläufe für verschiedene Anfragetypen vergleichen. Beispielsweise kann der Lösungsprozess für ein 'Abrechnungs'-Problem sehr unterschiedlich von dem eines 'Technischen Problems' sein. Dies ist ein Schlüsselattribut für nahezu alle Dashboards, um die Daten zu segmentieren.
Bedeutung
Ermöglicht die Aufschlüsselung der Analyse nach Anfragetyp und zeigt auf, ob bestimmte Kategorien anfälliger für Verzögerungen, Eskalationen oder SLA-Verletzungen sind.
Datenquelle
Dies entspricht dem Feld 'category' in der Tabelle 'sn_customerservice_case'.
Beispiele
Anfrage / HilfeBestellungenProduktproblemeAbrechnung
|
|||
|
Priorität
Priority
|
Die Prioritätsstufe der Serviceanfrage, die ihre Dringlichkeit beeinflusst. | ||
|
Beschreibung
Die Priorität gibt die Bedeutung und die erforderliche Dringlichkeit für die Bearbeitung einer Serviceanfrage an. Sie wird oft durch eine Kombination aus dem Einfluss der Anfrage auf den Kunden und ihrer Dringlichkeit bestimmt. Gängige Werte reichen von 'Kritisch' bis 'Niedrig'. Im Process Mining ist die Priorität eine leistungsstarke Dimension für Filterung und Vergleich. Sie ermöglicht Analysten zu prüfen, ob Anfragen mit hoher Priorität tatsächlich schneller bearbeitet werden als solche mit niedriger Priorität und ob SLA-Verletzungen bei bestimmten Prioritätsstufen häufiger vorkommen. Dies ist grundlegend für das Dashboard 'End-to-End-Zykluszeit der Serviceanfrage'.
Bedeutung
Dies ermöglicht die Segmentierung von Serviceanfragen nach Dringlichkeit, was essenziell ist, um zu überprüfen, ob kritische Probleme schneller bearbeitet werden als nicht-kritische.
Datenquelle
Dies entspricht dem Feld 'priority' in der Tabelle 'sn_customerservice_case'.
Beispiele
1 - Kritisch2 - Hoch3 - Moderat4 - Niedrig
|
|||
|
Status
State
|
Der aktuelle Status oder Zustand der Serviceanfrage in ihrem Lebenszyklus. | ||
|
Beschreibung
Das Attribut 'Status' beschreibt den operativen Zustand einer Serviceanfrage zu jedem Zeitpunkt, wie z.B. 'Neu', 'In Bearbeitung', 'Wartet auf Info', 'Gelöst' oder 'Geschlossen'. Änderungen in diesem Feld werden oft zur Definition der Aktivitäten im Prozessmodell verwendet. Die Analyse des Status bietet eine übergeordnete Ansicht darüber, wo sich Fälle im Prozess befinden. Sie wird verwendet, um zu identifizieren, wie lange Fälle in bestimmten Zuständen verbleiben, wie z.B. 'Wartet auf Info', was eine erhebliche Verzögerungsquelle sein kann. Es hilft auch, die Start- und Endpunkte für wichtige KPIs wie die 'Lösung bis Abschlusszeit' zu definieren.
Bedeutung
Zeigt den Status einer Anfrage zu jeder Zeit an und hilft, die in unproduktiven Zuständen wie 'In Wartestellung' oder 'Informationen erwartend' verbrachte Zeit zu identifizieren.
Datenquelle
Dies entspricht dem Feld 'state' in der Tabelle 'sn_customerservice_case'.
Beispiele
NeuIn BearbeitungWartet auf BenutzerinformationenGelöstGeschlossen
|
|||
|
Zugewiesener Agent
AssignedAgent
|
Der einzelne Service-Agent, der aktuell mit der Bearbeitung der Serviceanfrage betraut ist. | ||
|
Beschreibung
Dieses Attribut identifiziert den Benutzer, der zu einem bestimmten Zeitpunkt für die Serviceanfrage verantwortlich ist. Es ändert sich oft während des gesamten Falllebenszyklus, da die Anfrage zwischen verschiedenen Agenten oder Spezialisten übergeben wird. Die Analyse des zugewiesenen Agenten ist entscheidend für das Verständnis der Arbeitslastverteilung, der Agentenleistung und der Übergaben. Sie hilft, Fragen zu beantworten, wie welche Agenten die komplexesten Fälle bearbeiten, wie oft Fälle neu zugewiesen werden und ob bestimmte Agenten mit längeren Lösungszeiten oder höherer Kundenzufriedenheit verbunden sind. Dies ist entscheidend für das Dashboard 'Agenten-Übergaben und Neuzuweisungen'.
Bedeutung
Verfolgt die Agentenverantwortlichkeit und ermöglicht die Analyse von Arbeitslast, Leistung und der Häufigkeit von Neuzuweisungen, was oft auf Prozessreibung hinweist.
Datenquelle
Dies entspricht dem Feld 'assigned_to' in der Tabelle 'sn_customerservice_case'.
Beispiele
Beth AnglinDavid LooAbel Tuter
|
|||
|
`Anzahl` der `Neuzuweisungen`
ReassignmentCount
|
Die Gesamtzahl der Male, die die Serviceanfrage einem anderen Agenten oder einer anderen Gruppe neu zugewiesen wurde. | ||
|
Beschreibung
Dieses Attribut ist ein Zähler, der sich jedes Mal erhöht, wenn sich das Feld 'assigned_to' oder 'assignment_group' ändert. Es liefert eine einfache Metrik für die Anzahl der internen Transfers eines Falls. Die Neuzuweisungsanzahl ist ein direktes Maß für Prozessreibung und eine wichtige Eingabe für das Dashboard 'Agenten-Übergaben und Neuzuweisungen' sowie den KPI 'Durchschnittliche Agenten-Übergaben pro Anfrage'. Hohe Neuzuweisungsanzahlen weisen oft auf Probleme bei der anfänglichen Weiterleitung, Lücken in den Agentenfähigkeiten oder schwer kategorisierbare Fälle hin, die alle zu längeren Lösungszeiten führen.
Bedeutung
Misst direkt die Prozessineffizienz durch Zählung von Übergaben (Handoffs). Eine hohe Anzahl korreliert oft mit längeren Lösungszeiten und Kundenunzufriedenheit.
Datenquelle
Dies ist ein standardmäßiges Metrikfeld, 'reassignment_count', in der 'task'-Tabelle, die 'sn_customerservice_case' erweitert.
Beispiele
0135
|
|||
|
Bearbeitungszeit
ProcessingTime
|
Die Dauer der aktiven Bearbeitung einer Aktivität. | ||
|
Beschreibung
Die Bearbeitungszeit, auch als aktive Zeit oder Servicezeit bekannt, misst die Dauer einer Aktivität von ihrem Start bis zu ihrem Ende. Sie stellt die Zeit dar, die ein Agent oder System aktiv mit der Ausführung einer Aufgabe verbringt, im Gegensatz zur Wartezeit zwischen den Aufgaben. Im Process Mining ist diese Metrik entscheidend, um zwischen wertschöpfender Zeit und nicht-wertschöpfender Wartezeit zu unterscheiden. Die Analyse der Bearbeitungszeit hilft dabei, zu identifizieren, welche spezifischen Aufgaben am zeitaufwändigsten sind und wo es Möglichkeiten für Automatisierung oder Schulungen gibt, um die Effizienz zu verbessern. Sie ist eine grundlegende Metrik für die Engpassanalyse.
Bedeutung
Misst die aktive Arbeitszeit für eine Aktivität und hilft so, wertschöpfende Zeit von verschwendeter Wartezeit im Prozess zu unterscheiden.
Datenquelle
Dies ist ein berechnetes Attribut, das typischerweise als Differenz zwischen der Endzeit und der Startzeit einer Aktivität abgeleitet wird.
Beispiele
PT15MPT2H30MP1D
|
|||
|
Behebungscode
ResolutionCode
|
Ein Code, der das Endergebnis oder die Art der Lösung der Serviceanfrage angibt. | ||
|
Beschreibung
Der Lösungscode ist ein strukturierter Wert, der vom Agenten bei der Lösung eines Falls ausgewählt wird. Er liefert spezifische Details zur Lösung, wie 'Vom Benutzer gelöst', 'Bekannter Fehler', 'Duplikat' oder 'Keine Aktion erforderlich'. Dieses Attribut ist wertvoll für die Ursachenanalyse. Durch die Analyse der Häufigkeit verschiedener Lösungscodes können Organisationen wiederkehrende Probleme, Wissenslücken oder Produktprobleme identifizieren. Diese Informationen können dann genutzt werden, um Verbesserungen voranzutreiben, die das Volumen bestimmter Arten von Serviceanfragen reduzieren.
Bedeutung
Bietet Einblicke in die Ergebnisse von Serviceanfragen, was entscheidend für die Ursachenanalyse und die Identifizierung wiederkehrender Probleme ist.
Datenquelle
Dies entspricht dem Feld 'close_code' oder einem benutzerdefinierten Lösungscode-Feld in der Tabelle 'sn_customerservice_case'.
Beispiele
Gelöst (`Workaround`)Gelöst (Dauerhaft)Nicht gelöst (Kunde reagiert nicht)Vom Anrufer geschlossen/gelöst
|
|||
|
Ist Erstkontaktlösung
IsFirstContactResolution
|
Ein boolesches Flag, das anzeigt, ob die Anfrage vom ersten zugewiesenen Agenten ohne Übergaben oder Eskalationen gelöst wurde. | ||
|
Beschreibung
Dieses berechnete Attribut identifiziert Serviceanfragen, die während der ersten Interaktion oder vom ersten Agenten, der den Fall bearbeitet hat, effizient gelöst wurden. Die Logik prüft typischerweise Bedingungen wie null Neuzuweisungen ('ReassignmentCount' ist 0), keine 'Interne Eskalation ausgelöst'-Aktivitäten und keine Anfragen nach weiteren Informationen vom Kunden. Dieses Attribut misst direkt eine kritische Kundenservicemetrik und unterstützt das Dashboard 'Erstkontaktlösungsrate' und den KPI. Es ermöglicht eine einfache Quantifizierung der FCR-Leistung und hilft bei der Analyse der Faktoren, wie Kanal oder Anfragenkategorie, die zur Erreichung der Erstkontaktlösung beitragen oder diese behindern.
Bedeutung
Misst direkt die Effizienz der initialen Antwort. Eine hohe FCR-Rate ist stark mit operativer Effizienz und hoher Kundenzufriedenheit verbunden.
Datenquelle
Dies ist ein berechnetes Attribut. Es wird während der Datentransformation basierend auf Regeln abgeleitet, wie z.B. dass 'ReassignmentCount' null ist und keine Eskalationsaktivitäten auftreten.
Beispiele
truefalsch
|
|||
|
Ist Nacharbeit
IsRework
|
Ein boolesches Flag, das anzeigt, ob signifikante Nacharbeiten stattgefunden haben, wie ein wiedereröffneter Case oder eine wiederholte Untersuchung. | ||
|
Beschreibung
Dies ist ein berechnetes Attribut, das Fälle kennzeichnet, die Muster von Ineffizienz oder Wiederholung aufweisen. Die Logik für dieses Flag könnte durch Ereignisse wie 'Serviceanfrage wiedereröffnet' oder wenn eine Schlüsselsequenz von Aktivitäten, wie 'Agent beginnt Untersuchung' gefolgt von 'Lösung vorgeschlagen', mehrfach innerhalb desselben Falls auftritt, ausgelöst werden. Dieses Flag ist von unschätzbarem Wert, um problematische Fälle schnell zu identifizieren und das Gesamtmaß an Nacharbeit im Prozess zu quantifizieren. Es unterstützt direkt das Dashboard 'Hotspots für Nacharbeit und Wiederholung' und den KPI 'Nacharbeitsrate', wodurch Analysten sich auf die Treiber der Ineffizienz konzentrieren können, ohne repetitive Muster manuell identifizieren zu müssen.
Bedeutung
Hilft, die Prozessineffizienz zu quantifizieren, indem Cases mit sich wiederholenden Schleifen oder Wiedereröffnungs-Events gekennzeichnet werden, was die Messung und gezielte Bearbeitung von Nacharbeiten (Rework) erleichtert.
Datenquelle
Dies ist ein berechnetes Attribut. Es wird während der Datentransformation durch Anwendung von Geschäftslogik abgeleitet, die Muster von Nacharbeit erkennt, wie z.B. eine ungleich null 'ReopenCount' oder wiederholte Aktivitäten.
Beispiele
truefalsch
|
|||
|
Kanal
Channel
|
Der Kommunikationskanal, über den die Serviceanfrage initiiert wurde. | ||
|
Beschreibung
Der Kanal gibt die Methode an, die der Kunde zur Einreichung seiner Anfrage verwendet hat, z. B. 'E-Mail', 'Telefon', 'Webportal' oder 'Chat'. Verschiedene Kanäle können erheblich unterschiedliche Prozessmerkmale und Kundenerwartungen aufweisen. Die Analyse des Prozesses nach Kanal hilft, die Effektivität jeder Kommunikationsmethode zu bewerten. Zum Beispiel kann sie aufzeigen, ob Anfragen, die per 'Telefon' eingereicht wurden, eine höhere Erstkontaktlösungsrate aufweisen oder ob 'E-Mail'-Anfragen tendenziell längere Zykluszeiten haben. Dies unterstützt direkt das Dashboard 'Effektivität der Kommunikationskanäle'.
Bedeutung
Hilft, die Effizienz und Ergebnisse verschiedener Kundeninteraktionskanäle wie Telefon, E-Mail oder Webportal zu bestimmen.
Datenquelle
Dies entspricht typischerweise dem Feld 'contact_type' in der Tabelle 'sn_customerservice_case'.
Beispiele
TelefonE-MailSelf-ServiceChat
|
|||
|
Kunde
Customer
|
Der Name oder die Kennung des Kunden oder Unternehmens, der/das die Serviceanfrage initiiert hat. | ||
|
Beschreibung
Dieses Attribut identifiziert den externen Stakeholder, entweder eine Einzelperson oder eine Organisation, für die die Serviceanfrage bestimmt ist. Es liefert den Kundenkontext für jeden Fall. In der Analyse ermöglicht das Kundenattribut eine kundenorientierte Sicht auf den Serviceprozess. Es kann verwendet werden, um festzustellen, ob bestimmte Kunden mehr Probleme oder längere Verzögerungen erfahren, und kann mit anderen Kundendaten, wie Segment oder Wert, verknüpft werden, um Prozessverbesserungsbemühungen zu priorisieren. Zum Beispiel könnte man prüfen, ob hochrangige Kunden einen schnelleren Service erhalten.
Bedeutung
Verknüpft den Prozess mit bestimmten Kunden und ermöglicht die Analyse von Service Levels und der Häufigkeit von Problemen für Schlüsselkunden oder Kundensegmente.
Datenquelle
Dies könnte das Feld 'caller_id', 'opened_for' oder 'account' in der Tabelle 'sn_customerservice_case' sein, die auf Benutzer- oder Firmentabellen verweisen.
Beispiele
John SmithACME CorporationGlobal Tech Inc.
|
|||
|
Letzte Datenaktualisierung
LastDataUpdate
|
Der Zeitstempel, der angibt, wann die Daten zuletzt aus dem Quellsystem extrahiert oder aktualisiert wurden. | ||
|
Beschreibung
Dieses Attribut zeichnet Datum und Uhrzeit des letzten Datenabrufs auf. Es liefert Kontext zur Aktualität der analysierten Daten und stellt sicher, dass Benutzer wissen, ob sie nahezu Echtzeitinformationen oder einen historischen Schnappschuss betrachten. Während der Analyse ist dies ein entscheidendes Metadatum, um das Zeitfenster des Datensatzes zu verstehen. Es hilft Benutzern, Dashboards und KPIs korrekt zu interpretieren, indem sie beispielsweise wissen, dass die Daten auf dem Stand der letzten Stunde oder des Vortages sind.
Bedeutung
Zeigt die Aktualität der Daten an, was entscheidend für die Relevanz und Zeitnähe der Process Mining Erkenntnisse ist.
Datenquelle
Dieser
Beispiele
2023-11-20T08:00:00Z
|
|||
|
Quellsystem
SourceSystem
|
Das System, aus dem die Daten extrahiert wurden. | ||
|
Beschreibung
Dieses Attribut identifiziert den Datenursprung, was besonders wichtig in Umgebungen ist, in denen Informationen aus mehreren Systemen aggregiert werden. Für diese Prozessansicht wäre der Wert durchgängig 'ServiceNow CSM'. In der Analyse hilft dies bei der Data Governance und Fehlerbehebung. Wenn mehrere Quellsysteme beteiligt sind, ermöglicht es das Filtern des Prozesses, um zu verstehen, wie er innerhalb eines spezifischen Systems funktioniert, oder um Prozessvariationen über verschiedene Systeme hinweg zu vergleichen.
Bedeutung
Liefert den wesentlichen Kontext zum Datenursprung, gewährleistet Klarheit in Multi-System-Umgebungen und unterstützt die Data Governance.
Datenquelle
Dies ist ein statischer Wert, der während des Datentransformationsprozesses hinzugefügt wird, um den Ursprung des Datensatzes zu kennzeichnen.
Beispiele
ServiceNow CSM
|
|||
|
Wiedereröffnungsanzahl
ReopenCount
|
Die Anzahl der Wiedereröffnungen einer gelösten Serviceanfrage durch den Kunden. | ||
|
Beschreibung
Dieser Zähler erfasst, wie oft ein Fall von einem 'Gelöst'- oder 'Geschlossen'-Status zurück in einen 'In Bearbeitung'- oder 'Offen'-Status übergegangen ist. Ein wiedereröffneter Fall deutet darauf hin, dass die ursprüngliche Lösung nicht effektiv oder vollständig war. Dieses Attribut ist ein starker Indikator für Nacharbeit und die Qualität der Erstlösung. Eine hohe Wiedereröffnungszahl deutet auf Probleme im Lösungsprozess hin, wie z.B. Agenten, die Tickets vorzeitig schließen oder das zugrunde liegende Problem des Kunden nicht vollständig angehen. Es ist eine Schlüsselmetrik zum Verständnis der Wirksamkeit vorgeschlagener Lösungen.
Bedeutung
Zeigt fehlgeschlagene Lösungen und Nacharbeiten (Rework) an. Eine hohe Anzahl von Wiedereröffnungen signalisiert eine schlechte Qualität im Lösungsprozess und führt zu Kundenfrustration.
Datenquelle
Dies wird oft in einem Feld namens 'reopen_count' in der Tabelle 'sn_customerservice_case' oder einer verwandten Tabelle verfolgt.
Beispiele
012
|
|||
Kundenservice-Aktivitäten
| Aktivität | Beschreibung | ||
|---|---|---|---|
|
Anfrage einem Agenten zugewiesen
|
Diese Aktivität tritt auf, wenn eine Serviceanfrage einem bestimmten Agenten zur Untersuchung und Lösung zugewiesen wird. Sie wird durch Ableitung der Änderung im Feld 'assigned_to' des Falldatensatzes erfasst. | ||
|
Bedeutung
Dies ist ein entscheidender Meilenstein für die Messung der anfänglichen Reaktionszeiten und der Arbeitslastverteilung der Agenten. Die Verfolgung von Neuzuweisungen dieses Feldes hebt Prozessineffizienzen und potenzielle Engpässe bei der Agentenverfügbarkeit hervor.
Datenquelle
Abgeleitet aus dem Audit-Verlauf (sys_audit) für die Tabelle sn_customerservice_case durch Verfolgung, wann das Feld assigned_to gefüllt oder geändert wird.
Erfassen
Erkennung der Wertänderung für das Feld 'assigned_to' im Audit Log des Cases.
Ereignistyp
inferred
|
|||
|
Interne Eskalation ausgelöst
|
Stellt die formelle Eskalation einer Serviceanfrage an eine höhere Support- oder Managementebene zur Lösung dar. Dies kann aus einer Änderung der Zuweisungsgruppe zu einem Team der nächsthöheren Ebene oder dem Setzen eines Flags abgeleitet werden. | ||
|
Bedeutung
Die Verfolgung von Eskalationen hilft, Prozessschwächen, Wissenslücken im First-Level-Support und komplexe Falltypen zu identifizieren. Dies ist ein Schlüsselindikator für Prozessreibung und Kundenunzufriedenheit.
Datenquelle
Kann aus dem Audit Log abgeleitet werden, indem eine Änderung in der 'assignment_group' zu einem bekannten Eskalationsteam oder eine Änderung im 'escalation'-Feld im Case-Datensatz erkannt wird.
Erfassen
Erkennung der Änderung im 'escalation'-Feld oder eines Wechsels zu einer höherstufigen 'assignment_group'.
Ereignistyp
inferred
|
|||
|
Serviceanfrage erstellt
|
Diese Aktivität markiert den Beginn des Kundenserviceprozesses, wenn ein neuer Fall formal im System protokolliert wird. Dieses Ereignis wird explizit erfasst, wenn ein neuer Datensatz in die Tabelle sn_customerservice_case eingefügt wird. | ||
|
Bedeutung
Als Startpunkt für jeden Case ist diese Aktivität unerlässlich für die Berechnung der End-to-End Cycle Time und die Analyse der Anfragenvolumen. Sie dient als Auslöser für alle nachgelagerten Prozesse und SLA Timer.
Datenquelle
Dieses Ereignis entspricht der Erstellung eines Datensatzes in der Tabelle sn_customerservice_case. Der Zeitstempel wird aus dem Feld sys_created_on entnommen.
Erfassen
Datensatz-Erstellungs-Timestamp (sys_created_on) in der Tabelle sn_customerservice_case.
Ereignistyp
explicit
|
|||
|
Serviceanfrage gelöst
|
Dies ist ein wichtiger Meilenstein, der anzeigt, dass der Service-Agent die Arbeit abgeschlossen hat und das Problem als gelöst gilt. Dies wird erfasst, wenn der Fallstatus auf 'Gelöst' geändert und der resolved_at Zeitstempel gefüllt wird. | ||
|
Bedeutung
Diese Aktivität markiert das Ende des aktiven Lösungsprozesses und ist entscheidend für die Berechnung von Lösungszykluszeiten und der SLA-Einhaltung. Sie dient als primärer Endpunkt für viele Effizienz-KPIs.
Datenquelle
Abgeleitet aus dem Audit-Verlauf, wenn das Feld 'state' in der Tabelle sn_customerservice_case auf 'Resolved' gesetzt wird. Das Feld resolved_at wird typischerweise gleichzeitig gefüllt.
Erfassen
Erkennung der 'state'-Änderung zu 'Gelöst' und Verwendung des entsprechenden Timestamps.
Ereignistyp
inferred
|
|||
|
Serviceanfrage geschlossen
|
Dies ist die letzte Aktivität, die den formalen Abschluss des Serviceanfragen-Datensatzes markiert, oft nach einer Bestätigungsfrist nach der Lösung. Sie wird erfasst, wenn der Fallstatus auf 'Geschlossen' wechselt und der closed_at Zeitstempel gesetzt wird. | ||
|
Bedeutung
Als definitives Ende des Prozesses ist diese Aktivität wesentlich für die Berechnung des gesamten Case Lifecycles. Die Analyse der Zeit zwischen 'Gelöst' und 'Geschlossen' zeigt administrativen Overhead oder Verzögerungen auf.
Datenquelle
Abgeleitet aus dem Audit-Verlauf, wenn das Feld 'state' in der Tabelle sn_customerservice_case auf 'Closed' gesetzt wird. Das Feld closed_at wird gleichzeitig gefüllt.
Erfassen
Erkennung der 'state'-Änderung zu 'Geschlossen' und Verwendung des entsprechenden Timestamps.
Ereignistyp
inferred
|
|||
|
Agent beginnt Untersuchung
|
Diese Aktivität signalisiert, dass ein Agent aktiv mit der Bearbeitung der Serviceanfrage begonnen hat. Sie wird typischerweise abgeleitet, wenn der Fallstatus von einem Status wie 'Neu' oder 'Zugewiesen' zu 'In Bearbeitung' wechselt. | ||
|
Bedeutung
Dieses Ereignis hilft, die Warteschlangenzeit von der aktiven Arbeitszeit zu unterscheiden. Die Analyse der Dauer zwischen Zuweisung und Untersuchungsbeginn zeigt Verzögerungen bei der Aufnahme neuer Fälle durch Agenten auf.
Datenquelle
Abgeleitet aus der Änderung des Statusfelds eines Falls in einen aktiven Arbeitszustand, wie z.B. 'In Bearbeitung'. Die spezifischen Statuswerte können konfiguriert und sollten überprüft werden.
Erfassen
Erkennung der Änderung im 'state'-Feld von einem ausstehenden zu einem aktiven Wert (z. B. 'Neu' zu 'In Bearbeitung').
Ereignistyp
inferred
|
|||
|
Anfrage kategorisiert und priorisiert
|
Stellt die anfängliche Triage dar, bei der die Serviceanfrage klassifiziert und eine Prioritätsstufe zugewiesen wird, um deren Dringlichkeit und Weiterleitung zu bestimmen. Dies wird aus Änderungen in den Feldern Kategorie, Unterkategorie oder Priorität im Audit-Log des Fall-Datensatzes abgeleitet. | ||
|
Bedeutung
Die Analyse dieser Aktivität hilft, Verzögerungen bei der Falltriage zu identifizieren und sicherzustellen, dass Anfragen korrekt weitergeleitet und entsprechend der Dringlichkeit bearbeitet werden. Sie beeinflusst die Zeit bis zur ersten Zuweisung und die gesamte Lösungs-Effizienz.
Datenquelle
Abgeleitet aus dem Audit-Verlauf (sys_audit) für die Tabelle sn_customerservice_case, insbesondere durch Verfolgung der initialen Füllung oder Aktualisierungen der Kategorie- und Prioritätsfelder.
Erfassen
Erkennung des ersten gesetzten Wertes oder einer Wertänderung für 'Kategorie'- oder 'Priorität'-Felder.
Ereignistyp
inferred
|
|||
|
Kundenumfrage gesendet
|
Stellt das Versenden einer Kundenzufriedenheitsumfrage nach der Falllösung dar. Dieses Ereignis wird typischerweise erfasst, wenn ein Umfrage-Instanzdatensatz erstellt und dem Fall zugeordnet wird. | ||
|
Bedeutung
Diese Aktivität hilft, Prozessausführungsmuster mit Kundenfeedback zu korrelieren. Das Verständnis, wann und ob Umfragen versendet werden, ist wichtig für die Analyse der Effektivität des Feedback-Loops.
Datenquelle
Dies ist ein explizites Ereignis, das in einer umfragespezifischen Tabelle wie asmt_assessment_instance protokolliert wird und einen Verweis auf den Quelldatensatz des Falls enthält.
Erfassen
Datensatz-Erstellung in der Tabelle 'asmt_assessment_instance', verknüpft mit dem Fall.
Ereignistyp
explicit
|
|||
|
Lösung vorgeschlagen
|
Diese Aktivität markiert den Zeitpunkt, an dem ein Agent eine Lösung identifiziert und diese dem Kunden zur Bestätigung mitgeteilt hat. Sie wird oft aus einer Statusänderung zu einem Wert wie 'Wartet auf Akzeptanz' oder aus einem spezifischen Arbeitsnotizeintrag abgeleitet. | ||
|
Bedeutung
Dieser Meilenstein trennt die Untersuchungsphase von der Bestätigungs- und Lösungsphase. Die Analyse der Wartezeit auf Kundenbestätigung kann Möglichkeiten aufzeigen, die Abschlussphasen eines Falls zu optimieren.
Datenquelle
Abgeleitet aus dem Audit Log der Tabelle sn_customerservice_case, wenn sich der Status zu einem Wert ändert, der eine vorgeschlagene Lösung anzeigt (z. B. 'Vorgeschlagene Lösung'). Dies kann je nach Implementierung variieren.
Erfassen
Erkennung der Änderung im 'state'-Feld zu einem Wert wie 'Vorgeschlagene Lösung' oder 'Warten auf Annahme'.
Ereignistyp
inferred
|
|||
|
Serviceanfrage wiedereröffnet
|
Tritt auf, wenn eine zuvor gelöste Serviceanfrage in einen aktiven Status zurückkehrt, weil das Problem erneut auftrat oder die Lösung ineffektiv war. Dies wird durch die Erkennung einer Statusänderung von 'Gelöst' zurück zu 'In Bearbeitung' abgeleitet. | ||
|
Bedeutung
Wiedereröffnete Fälle sind ein direktes Maß für die Lösungsqualität und ein Haupttreiber für Nacharbeit. Die Analyse dieser Ereignisse ist entscheidend, um die Erstkontaktlösungsraten und die Kundenzufriedenheit zu verbessern.
Datenquelle
Abgeleitet aus dem Audit-Verlauf der Tabelle sn_customerservice_case durch Identifizierung einer Sequenz, in der das Feld 'state' von 'Resolved' in einen aktiven Status wechselt.
Erfassen
Erkennung der 'state'-Änderung von 'Gelöst' zu einem aktiven Wert wie 'In Bearbeitung'.
Ereignistyp
inferred
|
|||
|
SLA verletzt
|
Stellt den Zeitpunkt dar, an dem eine Serviceanfrage ein definiertes Service Level Agreement, wie z.B. die Lösungszeit, nicht einhält. Dies ist ein kalkuliertes Ereignis, das durch den Vergleich der Lösungszeit mit der geplanten Endzeit des SLA abgeleitet wird. | ||
|
Bedeutung
Die Identifizierung von SLA-Verletzungen ist grundlegend für Compliance-Monitoring und Performance-Management. Dieses Event hilft, genau zu bestimmen, welche Prozessphasen oder Case-Typen am meisten zu SLA-Verletzungen beitragen.
Datenquelle
Berechnet durch Analyse von Datensätzen in der task_sla-Tabelle, die mit dem Case verknüpft sind. Eine Verletzung tritt auf, wenn das Feld has_breached wahr ist oder wenn die actual_elapsed_time die planned_duration überschreitet.
Erfassen
Überprüfen Sie das 'has_breached'-Flag im verknüpften task_sla-Datensatz.
Ereignistyp
calculated
|
|||
|
Vom Kunden angeforderte Informationen
|
Tritt auf, wenn ein Agent zusätzliche Informationen vom Kunden benötigt, um fortzufahren, und den Fall in einen ausstehenden Status versetzt. Dies wird aus einer Statusänderung zu einem Wert wie 'Wartet auf Benutzerinfo' oder 'In Warteschleife' abgeleitet. | ||
|
Bedeutung
Diese Aktivität ist entscheidend für die Analyse der 'Kundeninformation-Wartezeiten'. Sie isoliert Prozessverzögerungen, die durch externe Abhängigkeiten verursacht werden, und trennt sie von der internen Bearbeitungszeit.
Datenquelle
Abgeleitet aus dem Audit-Verlauf der Tabelle sn_customerservice_case, wenn sich das Feld 'state' zu einem Wert ändert, der angibt, dass eine Kundenrückmeldung aussteht (z. B. 'Warten auf Info').
Erfassen
Erkennung der Änderung im 'state'-Feld zu einem bestimmten 'Kunden wartend'-Wert.
Ereignistyp
inferred
|
|||
|
Vom Kunden erhaltene Informationen
|
Diese Aktivität markiert den Zeitpunkt, an dem der Kunde die angeforderten Informationen bereitstellt, wodurch der Agent die Arbeit wieder aufnehmen kann. Sie wird abgeleitet, wenn der Fallstatus von 'Wartet auf Benutzerinfo' zurück in einen aktiven Zustand wechselt. | ||
|
Bedeutung
Dieses Ereignis beendet die Kundenwartezeit und ermöglicht eine präzise Messung der Kundenreaktionszeiten. Es hilft zu identifizieren, welche Falltypen oder Kunden mit den längsten Verzögerungen verbunden sind.
Datenquelle
Abgeleitet aus dem Audit-Verlauf der Tabelle sn_customerservice_case, wenn sich das Feld 'state' von einem 'Warten auf Info'-Status zurück zu einem aktiven Status wie 'In Bearbeitung' ändert.
Erfassen
Erkennung der Änderung im 'state'-Feld von einem 'Kunden wartend'-Wert zurück zu einem aktiven Wert.
Ereignistyp
inferred
|
|||
|
Zuweisungsgruppe geändert
|
Zeigt an, dass die Verantwortung für einen Case von einem Team an ein anderes übertragen wurde. Dieses Event wird abgeleitet, indem Änderungen am Feld assignment_group innerhalb des Case-Datensatzes überwacht werden. | ||
|
Bedeutung
Die Verfolgung von Änderungen in Zuweisungsgruppen ist entscheidend für die Analyse von abteilungsübergreifenden Übergaben und die Identifizierung systematischer Routing-Probleme. Eine hohe Häufigkeit dieser Aktivität kann auf unklare Verantwortlichkeiten oder Prozessdefinitionen hinweisen.
Datenquelle
Abgeleitet aus dem Audit-Verlauf (sys_audit) für die Tabelle sn_customerservice_case durch Verfolgung, wann sich das Feld assignment_group ändert.
Erfassen
Erkennung der Wertänderung für das Feld 'assignment_group' im Audit Log des Cases.
Ereignistyp
inferred
|
|||