Ihr Daten-Template für den Kundenservice
Ihr Daten-Template für den Kundenservice
- Empfohlene Attribute für die Datenerfassung
- Wichtige Aktivitäten für die Nachverfolgung
- Anleitung zur Datenextraktion
Attribute für den Kundenservice
| 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
|
|||
Aktivitäten im Kundenservice
| 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
|
|||
Anleitungen zur Datenextraktion
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.
Keine Kreditkarte erforderlich. In wenigen Minuten können Sie loslegen.