Ihr Daten-Template für den Kundenservice

ServiceNow CSM
Ihr Daten-Template für den Kundenservice

Ihr Daten-Template für den Kundenservice

Dieses Daten-Template zeigt Ihnen, welche Informationen Sie für die Analyse Ihres Kundenserviceprozesses erfassen sollten. Es beschreibt die wichtigen Datenattribute, legt die zentralen Aktivitäten fest und erklärt, wie Sie die Daten aus Ihrem Quellsystem extrahieren. Mit dieser Vorlage bereiten Sie Ihre Daten präzise und effizient für Process Mining vor.
  • Empfohlene Attribute für die Datenerfassung
  • Wichtige Aktivitäten für die Nachverfolgung
  • Anleitung zur Datenextraktion
Neu bei Event Logs? Erfahren Sie, wie Sie ein Event Log für Process Mining erstellen.

Attribute für den Kundenservice

Diese Datenfelder sollten Sie in Ihr Event Log aufnehmen, um den Kundenservice umfassend zu analysieren.
3 Erforderlich 6 Empfohlen 9 Optional
Name Beschreibung
Ereigniszeit
EventTime
Der genaue Timestamp, der angibt, wann eine bestimmte Aktivität oder ein Ereignis stattgefunden hat.
Beschreibung

Die Ereigniszeit gibt Datum und Uhrzeit einer Aktivität an. Dieser Timestamp ist grundlegend, um Ereignisse chronologisch zu ordnen und die Dauer zwischen verschiedenen Prozessschritten zu berechnen.

Bei der Process-Mining-Analyse dient dieses Attribut zur Berechnung aller zeitbasierten Kennzahlen, darunter Durchlauf-, Warte- und Bearbeitungszeiten. Anhand langer Verzögerungen vor bestimmten Aktivitäten können Analysten Engpässe erkennen und die Leistung mit Service Level Agreements (SLAs) vergleichen. Für eine zuverlässige Analyse sind genaue und einheitliche Timestamps unerlässlich.

Warum das wichtig ist

Dieser Timestamp ist entscheidend, um Ereignisse korrekt zu ordnen und alle Leistungskennzahlen zu berechnen, etwa Durchlaufzeiten und Engpässe.

Woher beziehen

Dies entspricht in der Regel dem Feld „sys_created_on“ in den Audit- und Verlaufstabellen von ServiceNow, zum Beispiel „sys_audit“.

Beispiele
2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:05:11Z
Serviceanfrage
ServiceRequest
Die eindeutige Kennung jeder Kundenserviceanfrage, jedes Falls oder Tickets.
Beschreibung

Die Serviceanfrage ist die zentrale Fallkennung, über die alle zugehörigen Aktivitäten und Ereignisse eines Kundenanliegens von der Erstellung bis zum Abschluss verknüpft werden. Sie bildet den roten Faden, mit dem sich der gesamte Ablauf einer Kundeninteraktion verfolgen lässt.

Im Process Mining ist dieses Attribut grundlegend für die Rekonstruktion des Prozessablaufs. Jeder eindeutige Wert der Serviceanfrage steht für eine Prozessinstanz. So lassen sich Durchlaufzeiten, Pfade und Abweichungen für jeden einzelnen Fall analysieren. Dadurch werden alle Schritte vom ersten Kontakt bis zur endgültigen Lösung und zum Abschluss derselben Kundenanfrage zugeordnet.

Warum das wichtig ist

Dies ist die zentrale Case-ID, die alle Prozessschritte miteinander verknüpft und so die Analyse des vollständigen Lebenszyklus jeder Kundenserviceinteraktion ermöglicht.

Woher beziehen

Dies ist in der Regel das Feld „number“ in der Tabelle „sn_customerservice_case“ von ServiceNow CSM.

Beispiele
CS0010001CS0010045CS0010112
Aktivitätsname
ActivityName
Der Name eines bestimmten Ereignisses oder einer Aufgabe im Lebenszyklus der Serviceanfrage.
Beschreibung

Der Aktivitätsname bezeichnet einen Schritt im Kundenserviceprozess, zum Beispiel „Serviceanfrage erstellt“, „Anfrage einem Agenten zugewiesen“ oder „Lösung vorgeschlagen“. Diese Aktivitäten werden aus Systemprotokollen oder Tabellenaktualisierungen extrahiert und zu einer chronologischen Abfolge von Ereignissen für jede Serviceanfrage zusammengestellt.

Dieses Attribut ist entscheidend für die Visualisierung der Prozessübersicht, das Erkennen von Engpässen und das Verständnis des Arbeitsablaufs. Durch die Analyse der Abfolge und Häufigkeit von Aktivitäten können Analysten häufige Prozesspfade, Abweichungen sowie Bereiche mit Nacharbeit oder Ineffizienz erkennen. Wie detailliert die Aktivitäten definiert sind, bestimmt unmittelbar, wie tiefgehend die Erkenntnisse aus dem Prozessmodell ausfallen.

Warum das wichtig ist

Dieses Attribut bildet das Grundgerüst der Prozessübersicht. Es legt die einzelnen Schritte und Aufgaben fest, deren Abfolge und Dauer analysiert werden.

Woher beziehen

Dies ist ein konzeptionelles Attribut, das aus System-Audittabellen wie „sys_audit“ abgeleitet oder durch die Erfassung von Statusänderungen und Aktualisierungen wichtiger Felder in der Tabelle „sn_customerservice_case“ ermittelt wird.

Beispiele
Serviceanfrage erstelltAnfrage einer zuständigen Person zugewiesenInformationen beim Kunden angefordertServiceanfrage gelöst
Kategorie
Category
Die übergeordnete Klassifizierung der Serviceanfrage, zum Beispiel „Abrechnung“ oder „Technisches Problem“.
Beschreibung

Die Kategorie fasst Serviceanfragen nach Art des Kundenanliegens oder Problems zusammen. Sie wird in der Regel bei der Erstellung der Anfrage festgelegt und hilft dabei, sie der passenden Zuweisungsgruppe zuzuleiten.

Dieses Attribut ist wichtig, um die Prozessanalyse aufzuschlüsseln. Durch das Filtern nach Kategorie können Analysten die Abläufe verschiedener Anfragearten vergleichen. Der Lösungsprozess für ein Abrechnungsproblem kann sich beispielsweise deutlich von dem für ein technisches Problem unterscheiden. Daher ist dieses Attribut für die Aufschlüsselung der Daten in fast allen Dashboards relevant.

Warum das wichtig ist

Ermöglicht die Aufschlüsselung der Analyse nach Anfrageart und zeigt, ob bestimmte Kategorien häufiger mit Verzögerungen, Eskalationen oder SLA-Verstößen verbunden sind.

Woher beziehen

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 an, wie wichtig und dringlich eine Serviceanfrage ist. Sie richtet sich häufig danach, welche Auswirkungen das Anliegen auf den Kunden hat und wie dringend es bearbeitet werden muss. Übliche Werte reichen von „Kritisch“ bis „Niedrig“.

Im Process Mining ist die Priorität eine wichtige Dimension für Filter und Vergleiche. Analysten können prüfen, ob Anfragen mit hoher Priorität tatsächlich schneller bearbeitet werden als solche mit niedriger Priorität und ob bestimmte Prioritätsstufen häufiger mit SLA-Verstößen verbunden sind. Das ist grundlegend für das Dashboard „Durchlaufzeit von Serviceanfragen von Anfang bis Ende“.

Warum das wichtig ist

Damit lassen sich Serviceanfragen nach Dringlichkeit aufschlüsseln. So können Sie prüfen, ob kritische Anliegen schneller bearbeitet werden als weniger dringende.

Woher beziehen

Dies entspricht dem Feld „priority“ in der Tabelle „sn_customerservice_case“.

Beispiele
1 - Kritisch2 - Hoch3 - Mittel4 - Niedrig
SLA-Verletzung
IsSlaBreached
Ein boolesches Kennzeichen, das angibt, ob die Serviceanfrage die festgelegte Zielvorgabe des Service Level Agreement (SLA) überschritten hat.
Beschreibung

Dieses berechnete Attribut gibt an, ob eine Serviceanfrage innerhalb des vereinbarten Zeitraums gelöst wurde. Der Wert ist in der Regel 'True', wenn die Lösungszeit die SLA-Zielvorgabe überschritten hat, andernfalls 'False'. Damit lässt sich für jeden Case eindeutig feststellen, ob die SLA-Vorgabe eingehalten wurde.

Das Attribut ist eine wichtige Grundlage für das Dashboard 'Trends zur SLA-Einhaltung und zu SLA-Verletzungen' sowie die KPI 'SLA-Einhaltungsquote'. Es vereinfacht die Analyse, da sich SLA-Verletzungen direkt filtern und zählen lassen. So erkennen Sie schnell, bei welchen Anfragetypen, Prioritäten oder Teams SLA-Verletzungen besonders häufig auftreten.

Warum das wichtig ist

Zeigt eindeutig an, ob ein Case fristgerecht abgeschlossen wurde. Das ist eine wichtige Grundlage, um die SLA-Einhaltung zu messen und darüber zu berichten.

Woher beziehen

Wird anhand des Felds 'made_sla' in der Tabelle 'task_sla' berechnet oder durch den Vergleich der tatsächlichen mit der geplanten Lösungszeit ermittelt.

Beispiele
truefalse
Status
State
Der aktuelle Status der Serviceanfrage im Verlauf ihres Lebenszyklus.
Beschreibung

Das Statusattribut beschreibt den Bearbeitungsstand einer Serviceanfrage zu einem bestimmten Zeitpunkt, zum Beispiel „Neu“, „In Bearbeitung“, „Warten auf Informationen“, „Gelöst“ oder „Geschlossen“. Änderungen dieses Felds dienen häufig dazu, Aktivitäten im Prozessmodell zu definieren.

Die Analyse des Status zeigt auf hoher Ebene, an welcher Stelle im Prozess sich die Fälle befinden. Sie gibt Aufschluss darüber, wie lange Fälle in bestimmten Status verweilen. „Warten auf Informationen“ kann beispielsweise eine erhebliche Verzögerungsquelle sein. Außerdem lassen sich damit Start- und Endpunkte wichtiger KPIs wie „Zeit von der Lösung bis zum Abschluss“ festlegen.

Warum das wichtig ist

Zeigt den Status einer Anfrage zu jedem Zeitpunkt an und hilft dabei, die Verweildauer in nicht produktiven Status wie „Zurückgestellt“ oder „Warten auf Informationen“ zu erkennen.

Woher beziehen

Dies entspricht dem Feld „state“ in der Tabelle „sn_customerservice_case“.

Beispiele
NeuIn BearbeitungWarten auf BenutzerinformationenGelöstGeschlossen
Zugewiesener Agent
AssignedAgent
Der Serviceagent, der aktuell für die Bearbeitung der Serviceanfrage zuständig ist.
Beschreibung

Dieses Attribut gibt an, welcher Benutzer zu einem bestimmten Zeitpunkt für die Serviceanfrage verantwortlich ist. Im Verlauf eines Falls ändert sich der Wert häufig, wenn die Anfrage an andere Agenten oder Spezialisten übergeben wird.

Die Analyse des zugewiesenen Agenten ist wichtig, um die Arbeitslastverteilung, die Leistung der Agenten und Übergaben zu verstehen. Sie hilft bei Fragen wie: Welche Agenten bearbeiten die komplexesten Fälle? Wie oft werden Fälle neu zugewiesen? Gibt es Agenten, bei denen Fälle länger bis zur Lösung brauchen oder die mit einer höheren Kundenzufriedenheit verbunden sind? Dieses Attribut ist entscheidend für das Dashboard „Übergaben und Neuzuweisungen zwischen Agenten“.

Warum das wichtig ist

Erfasst, wer für den Fall zuständig ist, und ermöglicht so die Analyse von Arbeitslast, Leistung und Häufigkeit der Neuzuweisungen. Häufige Neuzuweisungen weisen auf Reibungsverluste im Prozess hin.

Woher beziehen

Dies entspricht dem Feld „assigned_to“ in der Tabelle „sn_customerservice_case“.

Beispiele
Beth AnglinDavid LooAbel Tuter
Zuweisungsgruppe
AssignmentGroup
Das Team oder die Abteilung, die für die Serviceanfrage zuständig ist.
Beschreibung

Die Zuweisungsgruppe bezeichnet die Warteschlange oder das Team, dem eine Serviceanfrage zugewiesen ist. Je nach Art des Anliegens wird die Anfrage häufig zwischen verschiedenen Gruppen weitergeleitet, etwa zwischen einem Support-Desk der Ebene 1, einem spezialisierten technischen Team oder der Abrechnungsabteilung.

Dieses Attribut ist wichtig, um Übergaben zwischen Abteilungen zu analysieren und Engpässe auf Teamebene zu erkennen. Es zeigt, wie die Arbeit zwischen verschiedenen Fachbereichen weitergegeben wird, und kann auf überlastete Teams oder zusätzlichen Schulungsbedarf hinweisen. Das unterstützt direkt die Dashboards „Übergaben und Neuzuweisungen zwischen Agenten“ und „Prozessablauf“.

Warum das wichtig ist

Zeigt, welches Team für die Arbeit zuständig ist. Das ist entscheidend für die Analyse der Teamleistung, der Arbeitslast und der Übergaben zwischen Abteilungen.

Woher beziehen

Dies entspricht dem Feld „assignment_group“ in der Tabelle „sn_customerservice_case“.

Beispiele
Service DeskAbrechnungsanfragenTechnischer Support, Ebene 2
Anzahl der Neuzuweisungen
ReassignmentCount
Wie oft die Serviceanfrage einem anderen Agenten oder einer anderen Gruppe zugewiesen wurde.
Beschreibung

Dieses Attribut zählt jedes Mal hoch, wenn sich das Feld „assigned_to“ oder „assignment_group“ ändert. Es gibt an, wie oft ein Fall intern weitergegeben wurde.

Die Anzahl der Neuzuweisungen ist ein direktes Maß für Reibungsverluste im Prozess. Sie ist eine wichtige Kennzahl für das Dashboard „Übergaben und Neuzuweisungen zwischen Agenten“ und den KPI „Durchschnittliche Anzahl der Agentenübergaben pro Anfrage“. Häufige Neuzuweisungen weisen oft auf Probleme bei der anfänglichen Weiterleitung, fehlende Kompetenzen oder schwer einzuordnende Fälle hin. All dies verlängert die Zeit bis zur Lösung.

Warum das wichtig ist

Misst Prozessineffizienz direkt anhand der Anzahl der Übergaben. Häufige Übergaben gehen oft mit längeren Lösungszeiten und geringerer Kundenzufriedenheit einher.

Woher beziehen

Dies ist das Standardkennzahlenfeld „reassignment_count“ in der Tabelle „task“, von der „sn_customerservice_case“ abgeleitet ist.

Beispiele
0135
Anzahl der Wiedereröffnungen
ReopenCount
Wie oft der Kunde eine gelöste Serviceanfrage wieder geöffnet hat.
Beschreibung

Dieser Zähler erfasst, wie oft ein Fall vom Status „Gelöst“ oder „Geschlossen“ zurück zu „In Bearbeitung“ oder „Offen“ wechselt. Ein wieder geöffneter Fall deutet darauf hin, dass die ursprüngliche Lösung nicht wirksam oder nicht vollständig war.

Dieses Attribut ist ein aussagekräftiger Indikator für Nacharbeit und die Qualität der Lösung beim ersten Versuch. Eine hohe Zahl an Wiedereröffnungen weist auf Probleme im Lösungsprozess hin, etwa wenn Agenten Tickets zu früh schließen oder das eigentliche Anliegen des Kunden nicht vollständig bearbeiten. Die Kennzahl hilft dabei, die Wirksamkeit vorgeschlagener Lösungen zu beurteilen.

Warum das wichtig ist

Weist auf fehlgeschlagene Lösungen und Nacharbeit hin. Viele Wiedereröffnungen signalisieren eine geringe Qualität des Lösungsprozesses und führen zu Unzufriedenheit bei Kunden.

Woher beziehen

Dies wird häufig in einem Feld namens 'reopen_count' in der Tabelle 'sn_customerservice_case' oder einer zugehörigen Tabelle erfasst.

Beispiele
012
Kanal
Channel
Der Kommunikationskanal, über den die Serviceanfrage eingereicht wurde.
Beschreibung

Der Kanal gibt an, auf welchem Weg der Kunde seine Anfrage eingereicht hat, zum Beispiel per E-Mail, Telefon, Webportal oder Chat. Je nach Kanal können sich Prozessabläufe und Kundenerwartungen deutlich unterscheiden.

Die Analyse nach Kanal hilft dabei, die Wirksamkeit der einzelnen Kommunikationswege zu bewerten. So lässt sich beispielsweise feststellen, ob Anfragen per Telefon häufiger beim Erstkontakt gelöst werden oder ob E-Mail-Anfragen längere Durchlaufzeiten haben. Das unterstützt direkt das Dashboard „Wirksamkeit der Kommunikationskanäle“.

Warum das wichtig ist

Hilft dabei, Effizienz und Ergebnisse verschiedener Kanäle für Kundeninteraktionen zu bewerten, etwa Telefon, E-Mail oder Webportal.

Woher beziehen

Dies entspricht in der Regel 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, das die Serviceanfrage gestellt hat.
Beschreibung

Dieses Attribut bezeichnet den externen Beteiligten, eine Einzelperson oder eine Organisation, für den die Serviceanfrage gestellt wurde. Es ordnet jeden Fall dem jeweiligen Kunden zu.

Bei der Analyse ermöglicht das Kundenattribut eine kundenorientierte Sicht auf den Serviceprozess. Damit lässt sich feststellen, ob bestimmte Kunden häufiger Probleme oder längere Verzögerungen erleben. In Verbindung mit weiteren Kundendaten, etwa Segment oder Kundenwert, unterstützt es die Priorisierung von Prozessverbesserungen. So können Sie beispielsweise prüfen, ob Kunden mit hohem Kundenwert schneller betreut werden.

Warum das wichtig ist

Verknüpft den Prozess mit bestimmten Kunden und ermöglicht die Analyse des Serviceniveaus und der Häufigkeit von Problemen bei wichtigen Kunden oder Kundensegmenten.

Woher beziehen

Dies kann das Feld „caller_id“, „opened_for“ oder „account“ in der Tabelle „sn_customerservice_case“ sein, das auf Benutzer- oder Unternehmenstabellen verweist.

Beispiele
John SmithACME CorporationGlobal Tech Inc.
Letzte Datenaktualisierung
LastDataUpdate
Der Timestamp, der angibt, wann die Daten zuletzt aus dem Quellsystem extrahiert oder aktualisiert wurden.
Beschreibung

Dieses Attribut erfasst Datum und Uhrzeit des letzten Datenabrufs. Es gibt an, wie aktuell die analysierten Daten sind, und zeigt, ob es sich um nahezu Echtzeitdaten oder um einen historischen Stand handelt.

Bei der Analyse ist dieser Metadatenwert wichtig, um den Zeitraum des Datensatzes einzuordnen. So können Benutzer Dashboards und KPIs richtig interpretieren und beispielsweise erkennen, ob die Daten bis zur letzten Stunde oder bis zum Vortag reichen.

Warum das wichtig ist

Gibt an, wie aktuell die Daten sind. Das ist entscheidend dafür, ob die Erkenntnisse aus dem Process Mining relevant und zeitnah sind.

Woher beziehen

Dieser Timestamp wird während des ETL-Prozesses (Extraktion, Transformation und Laden) erzeugt und hinzugefügt.

Beispiele
2023-11-20T08:00:00Z
Lösung beim Erstkontakt
IsFirstContactResolution
Ein boolesches Kennzeichen, das angibt, ob der zuerst zugewiesene Agent die Anfrage ohne Weiterleitung oder Eskalation gelöst hat.
Beschreibung

Dieses berechnete Attribut kennzeichnet Serviceanfragen, die effizient beim ersten Kontakt oder durch den ersten zuständigen Agent gelöst wurden. Die Berechnung prüft üblicherweise Bedingungen wie keine Neuzuweisungen ('ReassignmentCount' ist 0), keine Aktivitäten vom Typ 'Interne Eskalation ausgelöst' und keine Rückfragen an den Kunden.

Das Attribut misst direkt eine wichtige Kennzahl im Kundenservice und unterstützt das Dashboard und die KPI 'Lösungsquote beim Erstkontakt'. Damit lässt sich die FCR-Leistung einfach quantifizieren. Außerdem können Sie Faktoren wie Kanal oder Anfragekategorie analysieren, die eine Lösung beim Erstkontakt begünstigen oder erschweren.

Warum das wichtig ist

Misst direkt die Effizienz der ersten Reaktion. Eine hohe FCR-Quote steht in engem Zusammenhang mit effizienteren Abläufen und einer hohen Kundenzufriedenheit.

Woher beziehen

Dies ist ein berechnetes Attribut. Es wird bei der Datentransformation anhand von Regeln ermittelt, zum Beispiel wenn 'ReassignmentCount' null ist und keine Eskalationsaktivitäten aufgetreten sind.

Beispiele
truefalse
Lösungscode
ResolutionCode
Ein Code, der das endgültige Ergebnis oder die Art der Lösung der Serviceanfrage angibt.
Beschreibung

Der Lösungscode ist ein strukturierter Wert, den der Agent beim Lösen eines Falls auswählt. Er beschreibt die Lösung genauer, zum Beispiel „Vom Benutzer gelöst“, „Bekannter Fehler“, „Duplikat“ oder „Keine Aktion erforderlich“.

Dieses Attribut ist für die Ursachenanalyse hilfreich. Durch die Auswertung der Häufigkeit verschiedener Lösungscodes können Unternehmen wiederkehrende Probleme, Wissenslücken oder Produktprobleme erkennen. Diese Erkenntnisse lassen sich anschließend nutzen, um die Zahl bestimmter Arten von Serviceanfragen zu verringern.

Warum das wichtig ist

Gibt Aufschluss über die Ergebnisse von Serviceanfragen und ist damit wichtig für die Ursachenanalyse und das Erkennen wiederkehrender Probleme.

Woher beziehen

Dies entspricht dem Feld „close_code“ oder einem benutzerdefinierten Lösungscodefeld in der Tabelle „sn_customerservice_case“.

Beispiele
Gelöst (Behelfslösung)Gelöst (dauerhaft)Nicht gelöst (Kunde reagiert nicht)Vom Anrufer geschlossen/gelöst
Nacharbeit
IsRework
Ein boolesches Kennzeichen, das auf erhebliche Nacharbeit hinweist, etwa auf einen erneut geöffneten Case oder wiederholte Untersuchungen.
Beschreibung

Dieses berechnete Attribut kennzeichnet Cases mit Anzeichen für Ineffizienz oder Wiederholungen. Das Kennzeichen kann beispielsweise durch Ereignisse wie 'Serviceanfrage erneut geöffnet' ausgelöst werden oder wenn eine wichtige Abfolge von Aktivitäten, etwa 'Agent beginnt Untersuchung' gefolgt von 'Lösung vorgeschlagen', innerhalb desselben Case mehrfach auftritt.

Mit diesem Kennzeichen lassen sich problematische Cases schnell erkennen und Umfang sowie Häufigkeit der Nacharbeit im Prozess quantifizieren. Es unterstützt direkt das Dashboard 'Schwerpunkte bei Nacharbeit und Wiederholungen' und die KPI 'Nacharbeitsquote'. So können Analysten die Ursachen der Ineffizienz untersuchen, ohne wiederkehrende Muster manuell identifizieren zu müssen.

Warum das wichtig ist

Kennzeichnet Cases mit wiederholten Schleifen oder erneuten Öffnungen. So lässt sich die Ineffizienz im Prozess quantifizieren und Nacharbeit gezielt angehen.

Woher beziehen

Dies ist ein berechnetes Attribut. Es wird bei der Datentransformation anhand von Geschäftsregeln ermittelt, die Nacharbeitsmuster erkennen, etwa einen Wert ungleich null für 'ReopenCount' oder wiederholte Aktivitäten.

Beispiele
truefalse
Quellsystem
SourceSystem
Das System, aus dem die Daten extrahiert wurden.
Beschreibung

Dieses Attribut gibt die Herkunft der Daten an. Das ist besonders wichtig, wenn Informationen aus mehreren Systemen zusammengeführt werden. In dieser Prozessansicht lautet der Wert durchgehend „ServiceNow CSM“.

Bei der Analyse unterstützt dieses Attribut die Data Governance und die Fehlerbehebung. Sind mehrere Quellsysteme beteiligt, können Sie den Prozess nach System filtern und nachvollziehen, wie er dort abläuft oder wie er sich zwischen den Systemen unterscheidet.

Warum das wichtig ist

Gibt wichtige Informationen zur Herkunft der Daten und sorgt so für Klarheit in Umgebungen mit mehreren Systemen. Außerdem unterstützt das Attribut die Data Governance.

Woher beziehen

Dies ist ein statischer Wert, der während der Datentransformation hinzugefügt wird, um die Herkunft des Datensatzes zu kennzeichnen.

Beispiele
ServiceNow CSM
Erforderlich Empfohlen Optional

Aktivitäten im Kundenservice

Diese wichtigen Prozessschritte und Meilensteine sollten Sie in Ihrem Event Log erfassen, um den Prozess präzise zu entdecken.
5 Empfohlen 9 Optional
Aktivität Beschreibung
Anfrage einer zuständigen Person zugewiesen
Diese Aktivität tritt ein, wenn eine Serviceanfrage einer bestimmten Person zur Untersuchung und Lösung zugewiesen wird. Sie wird anhand einer Änderung des Feldes assigned_to im Case-Datensatz abgeleitet.
Warum das wichtig ist

Dieser wichtige Meilenstein dient dazu, die Reaktionszeit zu Beginn und die Verteilung der Arbeitslast zu messen. Werden Änderungen an diesem Feld erfasst, lassen sich Ineffizienzen im Prozess und mögliche Engpässe bei der Verfügbarkeit von Mitarbeitenden erkennen.

Woher beziehen

Abgeleitet aus dem Audit-Verlauf (sys_audit) der Tabelle sn_customerservice_case. Erfasst wird, wann das Feld assigned_to befüllt oder geändert wird.

Erfassung

Wertänderung im Feld 'assigned_to' im Audit-Log des Case erkennen.

Ereignistyp inferred
Interne Eskalation ausgelöst
Bezeichnet die formelle Eskalation einer Serviceanfrage an eine höhere Support- oder Managementebene, damit der Fall gelöst wird. Sie lässt sich an einer Änderung der Zuweisungsgruppe zu einem Team einer höheren Supportstufe oder an einem gesetzten Kennzeichen erkennen.
Warum das wichtig ist

Die Erfassung von Eskalationen hilft dabei, Schwachstellen im Prozess, Wissenslücken im First-Level-Support und komplexe Falltypen zu erkennen. Sie ist ein wichtiger Indikator für Reibungsverluste im Prozess und Unzufriedenheit bei Kunden.

Woher beziehen

Lässt sich im Auditprotokoll daran erkennen, dass sich „assignment_group“ zu einem bekannten Eskalationsteam ändert oder das Feld „escalation“ im Falldatensatz geändert wird.

Erfassung

Erkennen Sie eine Änderung des Felds „escalation“ oder eine Zuweisung an eine „assignment_group“ einer höheren Supportstufe.

Ereignistyp inferred
Serviceanfrage erstellt
Diese Aktivität markiert den Beginn des Kundenserviceprozesses, wenn ein neuer Case offiziell im System erfasst wird. Das Ereignis wird direkt erfasst, sobald ein neuer Datensatz in die Tabelle sn_customerservice_case eingefügt wird.
Warum das wichtig ist

Als Ausgangspunkt jedes Case ist diese Aktivität entscheidend für die Berechnung der Zykluszeit von Anfang bis Ende und die Analyse des Anfragevolumens. Sie löst alle nachfolgenden Prozesse und SLA-Zeitmessungen aus.

Woher beziehen

Dieses Ereignis entspricht der Erstellung eines Datensatzes in der Tabelle sn_customerservice_case. Der Timestamp stammt aus dem Feld sys_created_on.

Erfassung

Timestamp der Datensatzerstellung (sys_created_on) in der Tabelle sn_customerservice_case.

Ereignistyp explicit
Serviceanfrage gelöst
Dieser wichtige Meilenstein zeigt an, dass der Serviceagent die Arbeit abgeschlossen hat und das Problem als gelöst gilt. Er wird erfasst, wenn der Fallstatus auf „Gelöst“ gesetzt und der Timestamp „resolved_at“ ausgefüllt wird.
Warum das wichtig ist

Diese Aktivität markiert das Ende des aktiven Lösungsprozesses. Sie ist entscheidend für die Berechnung der Lösungsdurchlaufzeit und die Einhaltung von SLAs und dient als wichtiger Endpunkt für viele Effizienz-KPIs.

Woher beziehen

Wird anhand des Auditverlaufs erkannt, wenn das Feld „state“ der Tabelle sn_customerservice_case auf „Gelöst“ gesetzt wird. Das Feld „resolved_at“ wird in der Regel gleichzeitig ausgefüllt.

Erfassung

Erkennen Sie eine Änderung von „state“ zu „Gelöst“ und verwenden Sie den zugehörigen Timestamp.

Ereignistyp inferred
Serviceanfrage geschlossen
Dies ist die letzte Aktivität. Sie markiert den formellen Abschluss des Serviceanfragedatensatzes, häufig nach einer Bestätigungsfrist im Anschluss an die Lösung. Sie wird erfasst, wenn sich der Fallstatus zu „Geschlossen“ ändert und der Timestamp „closed_at“ gesetzt wird.
Warum das wichtig ist

Als endgültiger Prozessabschluss ist diese Aktivität für die Berechnung des gesamten Falllebenszyklus unerlässlich. Die Analyse der Zeit zwischen „Gelöst“ und „Geschlossen“ zeigt den Verwaltungsaufwand oder mögliche Verzögerungen.

Woher beziehen

Wird anhand des Auditverlaufs erkannt, wenn das Feld „state“ der Tabelle sn_customerservice_case auf „Geschlossen“ gesetzt wird. Das Feld „closed_at“ wird gleichzeitig ausgefüllt.

Erfassung

Erkennen Sie eine Änderung von „state“ zu „Geschlossen“ und verwenden Sie den zugehörigen Timestamp.

Ereignistyp inferred
Agent beginnt mit der Untersuchung
Diese Aktivität zeigt an, dass ein Agent aktiv mit der Bearbeitung der Serviceanfrage begonnen hat. Sie wird in der Regel daran erkannt, dass sich der Status des Falls von „Neu“ oder „Zugewiesen“ zu „In Bearbeitung“ ändert.
Warum das wichtig ist

Dieses Ereignis trennt die Wartezeit in der Warteschlange von der aktiven Bearbeitungszeit. Die Analyse der Zeit zwischen der Zuweisung und dem Beginn der Untersuchung zeigt, ob es zu Verzögerungen kommt, bevor Agenten neue Fälle übernehmen.

Woher beziehen

Wird daran erkannt, dass das Statusfeld des Falls in einen Status für aktive Bearbeitung wechselt, zum Beispiel „In Bearbeitung“. Die konkreten Statuswerte lassen sich konfigurieren und sollten überprüft werden.

Erfassung

Erkennen Sie eine Änderung des Felds „state“ von einem ausstehenden zu einem aktiven Wert, zum Beispiel von „Neu“ zu „In Bearbeitung“.

Ereignistyp inferred
Anfrage kategorisiert und priorisiert
Beschreibt die erste Prüfung, bei der die Serviceanfrage klassifiziert und einer Prioritätsstufe zugeordnet wird. So werden Dringlichkeit und Routing festgelegt. Die Aktivität wird aus Änderungen an den Feldern für Kategorie, Unterkategorie oder Priorität im Audit-Log des Case-Datensatzes abgeleitet.
Warum das wichtig ist

Die Analyse dieser Aktivität hilft, Verzögerungen bei der ersten Prüfung zu erkennen und sicherzustellen, dass Anfragen korrekt weitergeleitet und entsprechend ihrer Dringlichkeit bearbeitet werden. Sie wirkt sich auf die Zeit bis zur ersten Zuweisung und die Effizienz der gesamten Bearbeitung aus.

Woher beziehen

Abgeleitet aus dem Audit-Verlauf (sys_audit) der Tabelle sn_customerservice_case. Dabei werden die erstmalige Befüllung oder Änderungen der Felder für Kategorie und Priorität erfasst.

Erfassung

Ersten gesetzten Wert oder Wertänderung in den Feldern 'category' oder 'priority' erkennen.

Ereignistyp inferred
Informationen beim Kunden angefordert
Tritt auf, wenn ein Agent weitere Informationen vom Kunden benötigt, um fortzufahren, und den Fall auf „Ausstehend“ setzt. Dies lässt sich an einer Statusänderung zu einem Wert wie „Warten auf Benutzerinformationen“ oder „Zurückgestellt“ erkennen.
Warum das wichtig ist

Diese Aktivität ist für die Analyse der Wartezeiten auf Kundeninformationen entscheidend. Sie grenzt Prozessverzögerungen durch externe Abhängigkeiten von der internen Bearbeitungszeit ab.

Woher beziehen

Wird anhand des Auditverlaufs der Tabelle sn_customerservice_case erkannt, wenn das Feld „state“ zu einem Wert wechselt, der auf ausstehende Kundeninformationen hinweist, zum Beispiel „Warten auf Informationen“.

Erfassung

Erkennen Sie eine Änderung des Felds „state“ zu einem festgelegten Wert für „Warten auf den Kunden“.

Ereignistyp inferred
Informationen vom Kunden erhalten
Diese Aktivität markiert den Zeitpunkt, an dem der Kunde die angeforderten Informationen bereitstellt und der Agent die Arbeit fortsetzen kann. Sie wird daran erkannt, dass der Fallstatus von „Warten auf Benutzerinformationen“ wieder zu einem aktiven Status wechselt.
Warum das wichtig ist

Dieses Ereignis beendet die Wartezeit auf den Kunden und ermöglicht eine genaue Messung der Antwortzeiten. So lässt sich feststellen, bei welchen Falltypen oder Kunden die längsten Verzögerungen auftreten.

Woher beziehen

Wird anhand des Auditverlaufs der Tabelle sn_customerservice_case erkannt, wenn das Feld „state“ von einem Status wie „Warten auf Informationen“ zu einem aktiven Status wie „In Bearbeitung“ wechselt.

Erfassung

Erkennen Sie eine Änderung des Felds „state“ von einem Wert für „Warten auf den Kunden“ zurück zu einem aktiven Wert.

Ereignistyp inferred
Kundenumfrage versendet
Bezeichnet den Versand einer Kundenzufriedenheitsumfrage nach der Lösung eines Falls. Dieses Ereignis wird in der Regel erfasst, wenn ein Umfragedatensatz erstellt und mit dem Fall verknüpft wird.
Warum das wichtig ist

Diese Aktivität ermöglicht es, Prozessabläufe mit Kundenfeedback in Beziehung zu setzen. Für die Analyse der Wirksamkeit des Feedbackprozesses ist es wichtig zu wissen, ob und wann Umfragen versendet werden.

Woher beziehen

Dies ist ein explizit protokolliertes Ereignis in einer umfragespezifischen Tabelle wie asmt_assessment_instance, die einen Verweis auf den Quelldatensatz des Falls enthält.

Erfassung

Erstellung eines Datensatzes in der Tabelle „asmt_assessment_instance“, der mit dem Fall verknüpft ist.

Ereignistyp explicit
Lösung vorgeschlagen
Diese Aktivität markiert den Zeitpunkt, an dem ein Agent eine Lösung gefunden und dem Kunden zur Bestätigung mitgeteilt hat. Sie lässt sich häufig an einer Statusänderung zu einem Wert wie „Warten auf Annahme“ oder an einem bestimmten Arbeitsvermerk erkennen.
Warum das wichtig ist

Dieser Meilenstein trennt die Untersuchungsphase von der Bestätigungs- und Lösungsphase. Die Analyse der Wartezeit auf die Bestätigung des Kunden kann Möglichkeiten aufzeigen, die letzten Schritte eines Falls zu beschleunigen.

Woher beziehen

Wird anhand des Auditprotokolls der Tabelle sn_customerservice_case erkannt, wenn sich der Status zu einem Wert für einen Lösungsvorschlag ändert, zum Beispiel „Lösung vorgeschlagen“. Dies kann je nach Implementierung variieren.

Erfassung

Erkennen Sie eine Änderung des Felds „state“ zu einem Wert wie „Lösung vorgeschlagen“ oder „Warten auf Annahme“.

Ereignistyp inferred
Serviceanfrage wieder geöffnet
Tritt auf, wenn eine zuvor gelöste Serviceanfrage wieder in einen aktiven Status versetzt wird, weil das Problem erneut aufgetreten oder die Lösung unwirksam war. Dies lässt sich an einer Statusänderung von „Gelöst“ zurück zu „In Bearbeitung“ erkennen.
Warum das wichtig ist

Wieder geöffnete Fälle geben direkt Aufschluss über die Qualität der Lösung und sind eine wesentliche Ursache für Nacharbeit. Die Analyse dieser Ereignisse ist entscheidend, um die Lösungsquote beim Erstkontakt und die Kundenzufriedenheit zu verbessern.

Woher beziehen

Wird anhand des Auditverlaufs der Tabelle sn_customerservice_case erkannt, indem eine Abfolge ermittelt wird, in der das Feld „state“ von „Gelöst“ zu einem aktiven Status wechselt.

Erfassung

Erkennen Sie eine Änderung von „state“ von „Gelöst“ zu einem aktiven Wert wie „In Bearbeitung“.

Ereignistyp inferred
SLA nicht eingehalten
Bezeichnet den Zeitpunkt, an dem eine Serviceanfrage eine festgelegte Service Level Agreement-Vorgabe, etwa die Lösungszeit, nicht erfüllt. Dieses berechnete Ereignis ergibt sich aus dem Vergleich der Lösungszeit mit dem geplanten Endzeitpunkt des SLA.
Warum das wichtig ist

Die Erkennung von SLA-Verstößen ist grundlegend für die Compliance-Überwachung und das Leistungsmanagement. Dieses Ereignis zeigt, welche Prozessphasen oder Falltypen am häufigsten zu SLA-Verstößen beitragen.

Woher beziehen

Wird anhand der zur Anfrage gehörenden Datensätze in der Tabelle task_sla berechnet. Ein Verstoß liegt vor, wenn das Feld has_breached den Wert true hat oder actual_elapsed_time die planned_duration überschreitet.

Erfassung

Prüfen Sie das Kennzeichen „has_breached“ im verknüpften task_sla-Datensatz.

Ereignistyp calculated
Zuweisungsgruppe geändert
Zeigt an, dass die Verantwortung für einen Case von einem Team an ein anderes übertragen wurde. Das Ereignis wird anhand von Änderungen am Feld assignment_group im Case-Datensatz abgeleitet.
Warum das wichtig ist

Änderungen an Zuweisungsgruppen zu verfolgen ist wichtig, um Übergaben zwischen Abteilungen zu analysieren und systematische Routing-Probleme zu erkennen. Häufige Änderungen können auf unklare Zuständigkeiten oder Prozessvorgaben hindeuten.

Woher beziehen

Abgeleitet aus dem Audit-Verlauf (sys_audit) der Tabelle sn_customerservice_case. Erfasst werden Änderungen am Feld assignment_group.

Erfassung

Wertänderung im Feld 'assignment_group' im Audit-Log des Case erkennen.

Ereignistyp inferred
Empfohlen Optional

Anleitungen zur Datenextraktion

So exportieren Sie Ihre Daten aus ServiceNow CSM

Möchten Sie loslegen?

Mit diesem Template bereiten Sie Ihre Daten gezielt vor, gewinnen aussagekräftige Erkenntnisse und verbessern Ihre Kundenserviceabläufe. Beginnen Sie noch heute mit der Optimierung Ihres Prozesses, damit er effizienter und stärker auf Ihre Kunden ausgerichtet ist.

Steigern Sie noch heute die Effizienz Ihres Kundenservice

Steigern Sie die Kundenzufriedenheit und erreichen Sie eine Lösungsquote von 80 % beim Erstkontakt.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. In wenigen Minuten können Sie loslegen.