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 Erfassung
- Anleitung zur Datenextraktion für Microsoft Dynamics 365 Customer Service
Attribute des Kundenservice
| Name | Beschreibung | ||
|---|---|---|---|
|
Serviceanfrage
ServiceRequest
|
Die eindeutige Kennung einer Kundenserviceanfrage, auch Case oder Ticket genannt. | ||
|
Beschreibung
Die Serviceanfrage dient als primäre Kennung und verknüpft alle Aktivitäten zu einer einzelnen Kundenanfrage oder einem Anliegen. Als Case-ID für Process Mining ermöglicht sie eine vollständige, konsistente Sicht auf jede Kundeninteraktion von der Erstellung bis zum Abschluss. Die Analyse nach Serviceanfrage zeigt den durchgängigen Verlauf, macht Lösungszeiten messbar und deckt Muster bei ähnlichen Cases auf.
Warum das wichtig ist
Dies ist die erforderliche Case-ID, die alle zugehörigen Ereignisse zu einer einzelnen Prozessinstanz zusammenführt und so eine durchgängige Prozessanalyse ermöglicht.
Woher beziehen
Dies ist der Primärschlüssel der Case-Entität (incident) in Microsoft Dynamics 365 Customer Service.
Beispiele
CAS-01024-F3B4V6SR-2023-00589TKT-4815162342
|
|||
|
Aktivität
ActivityName
|
Der Name des konkreten Geschäftsereignisses, das zu einem bestimmten Zeitpunkt bei einer Serviceanfrage eingetreten ist. | ||
|
Beschreibung
Dieses Attribut bezeichnet einen einzelnen Schritt oder eine Statusänderung im Kundenserviceprozess, etwa 'Case erstellt', 'Mitarbeitender untersucht Anliegen' oder 'Case gelöst'. Diese Aktivitäten bilden die Grundlage der Prozessübersicht und ermöglichen die Visualisierung und Analyse des Prozessflusses. Zusammen mit einem Timestamp wird jede Aktivität zu einem Ereignis, das die Prozessabfolge festlegt.
Warum das wichtig ist
Aktivitäten bilden die einzelnen Prozessschritte ab. Ihre Abfolge und Häufigkeit zu analysieren, ist entscheidend, um Prozessabläufe zu verstehen, Abweichungen zu erkennen und Engpässe aufzudecken.
Woher beziehen
Üblicherweise wird dieses Attribut abgeleitet, indem Statusänderungen (statuscode) oder bestimmte Ereignisse aus verknüpften Entitäten wie Tasks, E-Mails oder Telefonanrufen standardisierten Aktivitätsnamen zugeordnet werden.
Beispiele
Case erstelltMitarbeitender untersucht AnliegenLösungsvorschlag an Kunden übermitteltCase geschlossen
|
|||
|
Letzte Datenaktualisierung
LastDataUpdate
|
Der Timestamp der letzten Datenaktualisierung oder -extraktion aus dem Quellsystem. | ||
|
Beschreibung
Dieses Attribut gibt an, wann die Daten zuletzt aus Microsoft Dynamics 365 abgerufen wurden. Es zeigt, wie aktuell die analysierten Daten sind, und ist für Berichte und Überwachung wichtig. So wissen Benutzer bei der Interpretation von Dashboards und Analysen, wie aktuell die Daten sind.
Warum das wichtig ist
Das Attribut informiert Benutzer darüber, wie aktuell die Daten sind. Das ist wichtig, um auf Grundlage der Prozessanalyse zeitnah fundierte Geschäftsentscheidungen zu treffen.
Woher beziehen
Dieser Wert wird bei der Datenextraktion erzeugt und dem Datensatz als Timestamp hinzugefügt.
Beispiele
2023-10-27T08:00:00Z
|
|||
|
Quellsystem
SourceSystem
|
Gibt an, aus welchem Quellsystem die Daten extrahiert wurden. | ||
|
Beschreibung
Dieses Attribut bezeichnet die Herkunft der Ereignisdaten. Für diesen Prozess ist Microsoft Dynamics 365 Customer Service durchgängig als Quelle angegeben. In Umgebungen mit mehreren Systemen ist dieses Feld entscheidend, um Datenquellen zu unterscheiden und die Datenherkunft nachvollziehbar zu machen.
Warum das wichtig ist
Das Attribut sorgt für eine klare Nachverfolgbarkeit der Datenherkunft. Das ist wichtig für die Data Governance und die Untersuchung von Datenabweichungen, insbesondere bei Analysen aus mehreren Systemen.
Woher beziehen
In der Regel wird während der Datenextraktion und -transformation ein statischer Wert hinzugefügt, der die Herkunft des Datensatzes kennzeichnet.
Beispiele
Microsoft Dynamics 365 Customer Service
|
|||
|
Startzeit
EventTime
|
Der Timestamp, der angibt, wann die Aktivität stattgefunden hat. | ||
|
Beschreibung
Dieses Attribut erfasst Datum und Uhrzeit einer bestimmten Aktivität präzise. Es ist unerlässlich, um Ereignisse korrekt anzuordnen und zeitbasierte Analysen durchzuführen, etwa zur Berechnung von Zykluszeiten, Dauern und Wartezeiten zwischen Aktivitäten. Ein genauer und einheitlicher Timestamp ist entscheidend für die Integrität der Process-Mining-Analyse.
Warum das wichtig ist
Dieser Timestamp ordnet Ereignisse chronologisch und ermöglicht alle Berechnungen von Zeitspannen. Diese sind entscheidend für die Leistungsanalyse und das Erkennen von Engpässen.
Woher beziehen
Dies entspricht Feldern wie 'createdon' oder 'modifiedon' der Case-Entität (incident) oder verknüpfter Aktivitätsentitäten, zum Beispiel Email, Task oder Phone Call.
Beispiele
2023-04-15T10:00:00Z2023-05-20T14:35:10Z2023-06-01T09:12:45Z
|
|||
|
Art der Serviceanfrage
ServiceRequestType
|
Die Hauptkategorie oder Klassifizierung der Serviceanfrage. | ||
|
Beschreibung
Dieses Attribut kategorisiert die Serviceanfrage nach ihrer Art, zum Beispiel 'Rechnungsanfrage', 'Technischer Support' oder 'Produktfeedback'. Es ist grundlegend, um die Prozessanalyse nach Anfrageart aufzuschlüsseln und zu verstehen, wie unterschiedliche Anliegen bearbeitet werden. Die Analyse nach Art kann zeigen, dass bestimmte Kategorien längere Lösungszeiten, höhere Eskalationsraten oder andere Prozessverläufe aufweisen.
Warum das wichtig ist
Die Aufschlüsselung nach Prozessart macht spezifische Engpässe, den Ressourcenbedarf und Verbesserungsmöglichkeiten sichtbar. Sie unterstützt bessere Strategien für Weiterleitung und Bearbeitung.
Woher beziehen
Diese Information ist häufig im Feld 'Subject' (subjectid) oder in einem benutzerdefinierten Kategoriefeld der Case-Entität (incident) gespeichert.
Beispiele
RechnungsanfrageTechnischer SupportProduktfeedbackKontoverwaltung
|
|||
|
Kanal
Channel
|
Der Kommunikationskanal, über den die Serviceanfrage eingegangen ist. | ||
|
Beschreibung
Dieses Attribut gibt an, über welchen Kanal die Kundeninteraktion begonnen hat, zum Beispiel per Telefon, E-Mail, Webportal oder Chat. Je nach Kanal unterscheiden sich Prozessabläufe, Kundenerwartungen und die Komplexität der Lösung. Eine Analyse nach Kanal hilft, die jeweiligen Workflows und den Ressourceneinsatz zu verbessern.
Warum das wichtig ist
Das Attribut zeigt, wie sich die verschiedenen Kontaktkanäle auf Prozesseffizienz, Lösungszeit und Kundenzufriedenheit auswirken.
Woher beziehen
Dies entspricht dem Feld 'Case Origin' (caseorigincode) der Case-Entität (incident).
Beispiele
TelefonE-MailWebChat
|
|||
|
Kundenname
CustomerName
|
Der Name des Kunden oder Kontos, das mit der Serviceanfrage verknüpft ist. | ||
|
Beschreibung
Dieses Attribut identifiziert den Kunden, der die Serviceanfrage gestellt hat. Es ermöglicht eine kundenorientierte Prozessanalyse und zeigt, welche Kunden die meisten Anfragen stellen, die längsten Lösungszeiten haben oder besonders komplexe Anliegen melden. Das ist wichtig für die Pflege von Kundenbeziehungen und die Verbesserung des Service für einzelne Kunden.
Warum das wichtig ist
Die Analyse auf Kundenebene zeigt Muster auf, hilft, den Service für wichtige Kunden zu verbessern, und macht den Verlauf der Customer Journey nachvollziehbar.
Woher beziehen
Dies ist das Suchfeld 'Customer' (customerid) der Case-Entität (incident). Es kann auf einen Account- oder Contact-Datensatz verweisen.
Beispiele
Global Tech Inc.Jane DoeInnovate Solutions
|
|||
|
Name des Mitarbeitenden
AgentName
|
Der Name des Mitarbeitenden im Kundenservice oder des Benutzers, der für die Aktivität verantwortlich ist. | ||
|
Beschreibung
Dieses Attribut identifiziert den Mitarbeitenden oder Systembenutzer, der eine Aktivität ausgeführt hat, etwa einen Eintrag aus einer Warteschlange übernommen oder einen Case gelöst hat. Es ist entscheidend für die Analyse der individuellen Leistung, der Arbeitslastverteilung und des Ressourceneinsatzes. Durch die Erfassung von Aktivitäten auf Mitarbeitendenebene können Unternehmen besonders leistungsstarke Mitarbeitende, Schulungsbedarf und eine unausgewogene Arbeitslast erkennen.
Warum das wichtig ist
Das Attribut ermöglicht die Analyse der Leistung einzelner Mitarbeitender und Teams, unterstützt eine ausgewogene Arbeitslast und zeigt Coaching-Möglichkeiten zur Verbesserung der Servicequalität auf.
Woher beziehen
Dies entspricht dem Feld 'Owner' (ownerid) der Case-Entität (incident), das mit der Entität System User (systemuser) verknüpft ist.
Beispiele
Alice SmithBob JohnsonSystem
|
|||
|
Priorität
Priority
|
Die der Serviceanfrage zugewiesene Priorität, die ihre Dringlichkeit angibt. | ||
|
Beschreibung
Dieses Attribut gibt die Dringlichkeit einer Serviceanfrage an. Übliche Kategorien sind Niedrig, Normal, Hoch und Dringend. Die Priorität bestimmt, in welcher Reihenfolge Cases bearbeitet werden, und legt häufig die SLA-Ziele fest. Entscheidend ist zu analysieren, wie sich die Priorität auf den Prozessfluss, den Ressourceneinsatz und die Lösungszeiten auswirkt, damit dringende Anliegen zeitnah bearbeitet werden.
Warum das wichtig ist
Das Attribut zeigt, ob Anfragen mit hoher Priorität schneller bearbeitet und ihre Ziele erreicht werden und wie sich Prioritätsstufen auf die Gesamtleistung des Prozesses auswirken.
Woher beziehen
Dies entspricht dem Feld 'Priority' (prioritycode) der Case-Entität (incident).
Beispiele
NiedrigNormalHoch
|
|||
|
SLA-Ziel für die Lösungszeit
SlaTargetResolutionTime
|
Die vertraglich vereinbarte Zielzeit für die Lösung der Serviceanfrage. | ||
|
Beschreibung
Dieses Attribut gibt die Zieldauer an, innerhalb derer eine Serviceanfrage gemäß dem geltenden Service Level Agreement (SLA) gelöst werden soll. Sie dient als Vergleichswert für die tatsächliche Leistung. Dieser Wert ist entscheidend für das Dashboard zur Überwachung der SLA-Einhaltung und für die Berechnung der Kennzahl zur SLA-Einhaltungsrate. So wird sichtbar, wo der Prozess die Servicezusagen nicht erfüllt.
Warum das wichtig ist
Dieser Wert ist der wichtigste Vergleichsmaßstab, um die Serviceleistung an den Zusagen zu messen. Er ermöglicht direkt die Analyse der SLA-Einhaltung und von SLA-Verstößen.
Woher beziehen
Dieser Wert ergibt sich aus der SLA-Konfiguration in Dynamics 365 und wird über SLA-KPI-Instances einem Case zugeordnet.
Beispiele
2592008640014400
|
|||
|
Statusgrund
StatusReason
|
Gibt den aktuellen Status der Serviceanfrage genauer an. | ||
|
Beschreibung
Ein Case hat einen allgemeinen Status wie 'Active' oder 'Resolved'. Der Statusgrund liefert genauere Angaben, etwa 'Information Provided' oder 'Problem Solved'. Dieses Attribut ist wichtig, um die Einzelheiten des Case-Verlaufs und die Gründe dafür zu verstehen. So lässt sich beispielsweise unterscheiden, ob ein Case erfolgreich gelöst oder vom Kunden storniert wurde. Das ist für eine genaue Ergebnisanalyse entscheidend.
Warum das wichtig ist
Das Attribut liefert detaillierte Erkenntnisse zum Ergebnis eines Case und zu den Gründen für Statusänderungen. So lassen sich Lösungsverläufe und Ursachen genauer analysieren.
Woher beziehen
Dies entspricht dem Feld 'Status Reason' (statuscode) der Case-Entität (incident).
Beispiele
In BearbeitungZurückgestelltProblem gelöstInformationen bereitgestellt
|
|||
|
Beim Erstkontakt gelöst
IsFirstContactResolution
|
Ein Kennzeichen dafür, ob die Anfrage beim ersten Kontakt gelöst wurde. | ||
|
Beschreibung
Dieses berechnete Attribut kennzeichnet Serviceanfragen, die ohne weitere Rückfragen des Kunden oder erhebliche Verzögerungen mit einer Neuzuweisung an Mitarbeitende gelöst wurden. Die genaue Definition kann komplex sein. Üblicherweise werden dafür eine kurze Durchlaufzeit sowie das Ausbleiben einer Wiedereröffnung oder weiterer Kundenanfragen nach dem ersten Kontakt geprüft. Das Attribut bildet die Grundlage für die KPI „Lösungsrate beim Erstkontakt“.
Warum das wichtig ist
Diese wichtige Kennzahl für Serviceeffizienz und Kundenzufriedenheit zeigt, ob Anliegen schnell und vollständig gelöst werden.
Woher beziehen
Wird anhand der Abfolge und Zeitpunkte der Aktivitäten im Event Log für jeden Case berechnet.
Beispiele
truefalse
|
|||
|
Betroffenes Produkt
ProductInvolved
|
Das Produkt, auf das sich die Serviceanfrage des Kunden bezieht. | ||
|
Beschreibung
Dieses Attribut gibt an, welches Produkt oder welche Dienstleistung vom Anliegen des Kunden betroffen ist. Damit lässt sich der Serviceprozess nach Produkten aufschlüsseln. So wird sichtbar, ob bestimmte Produkte mehr Supportanfragen oder komplexere Probleme verursachen oder besondere Fachkenntnisse erfordern. Die Analyse unterstützt die Produktverbesserung und die Ressourcenplanung.
Warum das wichtig ist
Ermöglicht eine produktspezifische Prozessanalyse, mit der sich wiederkehrende Produktprobleme erkennen, Supportdokumentationen verbessern und Fachkräfte gezielt einsetzen lassen.
Woher beziehen
Entspricht dem Suchfeld „Product“ (productid) in der Entität Case (incident).
Beispiele
Alpha-100-DruckerZeta-CRM-SoftwareOmega-Datentarif
|
|||
|
CSAT-Wert
CustomerSatisfactionScore
|
Der Zufriedenheitswert, den Kunden nach der Bearbeitung eines Falls angeben. | ||
|
Beschreibung
Dieses Attribut enthält die numerische oder kategorische Bewertung aus einer Kundenzufriedenheitsumfrage (CSAT), die in der Regel nach dem Schließen einer Serviceanfrage erhoben wird. Sie misst direkt, wie Kunden die Servicequalität wahrnehmen. Diese Daten sind wichtig für das Dashboard „Entwicklung der Kundenzufriedenheit“ und die KPI „Durchschnittlicher CSAT-Wert nach der Bearbeitung“. So lässt sich die Prozessleistung mit den Ergebnissen für Kunden in Beziehung setzen.
Warum das wichtig ist
Misst direkt die Kundenzufriedenheit. So kann die Organisation Prozessabläufe mit der Einschätzung der Kunden vergleichen und gezielte Verbesserungen vornehmen.
Woher beziehen
Die Daten stammen in der Regel aus einer verknüpften Umfrageentität, etwa Customer Voice, und werden mit der Entität Case (incident) verknüpft.
Beispiele
5341
|
|||
|
Eskaliert
IsEscalated
|
Ein Kennzeichen dafür, ob die Serviceanfrage eskaliert wurde. | ||
|
Beschreibung
Dieses boolesche Attribut gibt an, ob eine Serviceanfrage eskaliert wurde. Eine Eskalation erfolgt, wenn der Support der ersten Ebene ein Problem nicht lösen kann und ein erfahreneres Team oder eine Fachkraft hinzugezogen werden muss. Das Kennzeichen ist wichtig für das Dashboard „Interne Eskalationswege“ und die KPI „Interne Eskalationsrate“. Damit lassen sich die Ursachen von Eskalationen und Schwachstellen in den ersten Supportebenen ermitteln.
Warum das wichtig ist
Misst direkt die Häufigkeit von Eskalationen. So werden Probleme bei der Lösung beim Erstkontakt sichtbar und Bereiche erkennbar, in denen Prozessverbesserungen oder zusätzliche Schulungen für Mitarbeitende erforderlich sind.
Woher beziehen
Entspricht dem Feld „Is Escalated“ (isescalated) in der Entität Case (incident).
Beispiele
truefalse
|
|||
|
Nacharbeit
IsRework
|
Ein berechnetes Kennzeichen dafür, ob ein Fall Nacharbeitsaktivitäten umfasst. | ||
|
Beschreibung
Dieses boolesche Kennzeichen identifiziert Fälle mit Nacharbeitsschleifen oder wiederholten Aktivitäten, etwa mehreren Ereignissen vom Typ „Informationen beim Kunden angefordert“ oder einem Ereignis „Fall wiedereröffnet“ nach der Lösung. Es wird berechnet, indem die Aktivitätsabfolge auf Muster untersucht wird, die auf Ineffizienz oder eine nicht erfolgreiche Lösung beim ersten Versuch hindeuten. Das Attribut ist wichtig für das Dashboard „Analyse von Nacharbeit und wiederholten Kontakten“.
Warum das wichtig ist
Hilft dabei, Ineffizienzen im Prozess zu quantifizieren und einzugrenzen. So können Analysten die Ursachen wiederholter Arbeit und unnötigen Aufwands gezielt untersuchen.
Woher beziehen
Wird berechnet, indem mit Process Mining bestimmte Aktivitätsabfolgen (z. B. Gelöst -> Wiedereröffnet) oder wiederholte Aktivitäten innerhalb eines Falls erkannt werden.
Beispiele
truefalse
|
|||
|
SLA überschritten
IsSlaBreached
|
Ein berechnetes Kennzeichen dafür, ob die Serviceanfrage die SLA-Zielzeit überschritten hat. | ||
|
Beschreibung
Dieses boolesche Kennzeichen ergibt sich aus dem Vergleich der tatsächlichen Bearbeitungszeit einer Serviceanfrage mit der „SLA-Zielbearbeitungszeit“. Es wird auf „true“ gesetzt, wenn die tatsächliche Zeit über der Zielzeit liegt. Das Attribut ist eine wichtige Grundlage für das Dashboard „Überwachung der SLA-Einhaltung“ und die Berechnung der KPI „SLA-Einhaltungsrate“. Es zeigt für jeden Fall eindeutig an, ob die SLA eingehalten wurde.
Warum das wichtig ist
Zeigt für jeden Fall eindeutig, ob die SLA eingehalten wurde. So lassen sich Überschreitungen einfach filtern, zusammenfassen und auf ihre Ursachen untersuchen.
Woher beziehen
Wird durch den Vergleich von „ServiceRequestCycleTime“ und „SlaTargetResolutionTime“ berechnet.
Beispiele
truefalse
|
|||
|
Wissensartikel-ID
KnowledgeArticleId
|
Die Kennung eines Wissensdatenbankartikels, der mit der Serviceanfrage verknüpft ist. | ||
|
Beschreibung
Dieses Attribut erfasst die ID eines Wissensartikels, der bei der Bearbeitung einer Serviceanfrage verwendet oder verknüpft wurde. Es zeigt direkt, wie effektiv Mitarbeitende die Wissensdatenbank zur Lösung von Kundenanliegen einsetzen. Diese Daten sind wichtig für das Dashboard „Nutzung von Wissensartikeln“ und die zugehörige KPI. Sie helfen dabei, den Nutzen und die Vollständigkeit der Wissensdatenbank zu bewerten.
Warum das wichtig ist
Erfasst die Nutzung der Wissensdatenbank. So lässt sich nachvollziehen, ob Mitarbeitende verfügbare Ressourcen einsetzen, um Anliegen schneller und einheitlicher zu lösen.
Woher beziehen
Diese Information findet sich in der Beziehung zwischen den Entitäten Case (incident) und Knowledge Article (knowledgearticle).
Beispiele
KA-01337KA-02048
|
|||
|
Zuständiges Team
OwnerTeam
|
Das Team, das aktuell für die Serviceanfrage zuständig ist. | ||
|
Beschreibung
Dieses Attribut gibt das Team an, das für die Serviceanfrage verantwortlich ist. Eine Anfrage kann einer einzelnen Supportkraft oder einem Team (einer Warteschlange) zugewiesen sein. Die Auswertung nach Teams ist wichtig, um die Leistung einzelner Teams und die Arbeitslastverteilung zwischen Supportebenen oder Fachbereichen zu verstehen. Außerdem lassen sich Prozessunterschiede zwischen Teams erkennen.
Warum das wichtig ist
Ermöglicht die Leistungsanalyse auf Teamebene. Das ist wichtig, um Supportebenen und spezialisierte Gruppen wirksam zu steuern.
Woher beziehen
Wird aus dem Feld „Owner“ (ownerid) der Entität Case (incident) abgeleitet, wenn als Besitzer ein Teamdatensatz und kein Systembenutzer hinterlegt ist.
Beispiele
Support der ersten EbeneAbteilung für AbrechnungTechnische Fachkräfte
|
|||
Aktivitäten im Kundenservice
| Aktivität | Beschreibung | ||
|---|---|---|---|
|
Case erstellt
|
Diese Aktivität markiert den Beginn des Kundenserviceprozesses: Im System wird ein neuer Case-Datensatz angelegt. Das Ereignis wird ausdrücklich erfasst und mit einem Timestamp versehen, sobald der Datensatz der Entität 'Incident' erstmals gespeichert wird. | ||
|
Warum das wichtig ist
Als primäres Start-Event ist diese Aktivität entscheidend, um die Gesamtdauer des Case-Lebenszyklus zu berechnen und Entwicklungen beim Case-Volumen zu verstehen. Sie bildet den Ausgangspunkt für alle weiteren Prozessanalysen.
Woher beziehen
Dieses Ereignis wird für jeden neuen Datensatz anhand des Timestamps 'createdon' der Entität 'Incident' erfasst.
Erfassung
Verwenden Sie den Timestamp 'createdon' des Incident-Datensatzes.
Ereignistyp
explicit
|
|||
|
Case eskaliert
|
Bezeichnet die formelle Weiterleitung eines Case an eine höhere Supportstufe oder ein anderes Team. Dies kann eine ausdrückliche Aktion eines Benutzers sein, der den Case einer festgelegten Eskalationswarteschlange oder einem zuständigen Benutzer zuweist. | ||
|
Warum das wichtig ist
Die Überwachung von Eskalationen ist wichtig für die Kennzahl 'Interne Eskalationsrate' und hilft, die Ursachen von Anliegen zu erkennen, die der First-Level-Support nicht lösen kann. Sie macht Schwächen im Prozess und Schulungsbedarf sichtbar.
Woher beziehen
Abgeleitet aus einer Änderung des Felds 'ownerid' zu einer festgelegten Eskalationswarteschlange oder einem Team. Alternativ kann eine ausdrückliche benutzerdefinierte Aktion den Case als eskaliert kennzeichnen.
Erfassung
Ermitteln Sie eine mit Timestamp versehene Änderung von 'ownerid' zu einer bekannten Eskalationswarteschlange.
Ereignistyp
inferred
|
|||
|
Case gelöst
|
Dieser wichtige Meilenstein bezeichnet den Zeitpunkt, an dem der Mitarbeitende das Anliegen des Kunden als gelöst betrachtet. In Dynamics 365 wird dafür ausdrücklich ein Aktivitätsdatensatz 'Case Resolution' erstellt und mit dem Case verknüpft. | ||
|
Warum das wichtig ist
Als primäres, erfolgsbasiertes End-Event ist diese Aktivität entscheidend für die Berechnung von Lösungszeiten und Erfolgsquoten. Sie ist Bestandteil fast aller Kundenservice-Kennzahlen.
Woher beziehen
Dieses Ereignis entspricht der Erstellung eines Aktivitätsdatensatzes 'Resolution' (Case Resolution). Der Timestamp 'actualend' dieses Datensatzes markiert den Zeitpunkt der Lösung.
Erfassung
Verwenden Sie den Timestamp 'actualend' oder 'createdon' des zugehörigen Aktivitätsdatensatzes 'Resolution'.
Ereignistyp
explicit
|
|||
|
Case geschlossen
|
Dies ist der abschließende administrative Abschluss des Case-Datensatzes. Er kann gleichzeitig mit der Lösung oder erst später erfolgen. Erfasst wird die Aktivität, wenn sich der Status des Case zu 'Closed' ändert. | ||
|
Warum das wichtig ist
Dieses Ereignis markiert das endgültige Ende des Prozesslebenszyklus im System. Die Zeit zwischen 'Resolved' und 'Closed' kann auf administrativen Aufwand oder Verzögerungen beim endgültigen Abschluss der Datensätze hinweisen.
Woher beziehen
Erfasst wird eine Änderung des Felds 'statecode' der Entität 'Incident' zu 'Canceled' (2) oder zu einem benutzerdefinierten Status für geschlossene Cases. Der Timestamp ist im Auditverlauf verfügbar.
Erfassung
Erfassen Sie den Timestamp, zu dem 'statecode' in den endgültigen Endstatus wechselt, zum Beispiel Canceled/Closed.
Ereignistyp
explicit
|
|||
|
Case zugewiesen
|
Diese Aktivität bezeichnet die Zuweisung eines Case an eine bestimmte Warteschlange oder einen Benutzer zur Bearbeitung. Das System protokolliert Änderungen am Case-Verantwortlichen ausdrücklich. Sie lassen sich über die Auditprotokolle des Systems nachvollziehen. | ||
|
Warum das wichtig ist
Die Erfassung von Zuweisungen ist wichtig, um die Verteilung der Arbeitslast zu analysieren, zuweisungsbedingte Verzögerungen zu erkennen und die Effizienz der Weiterleitung zu beurteilen. So lässt sich nachvollziehen, wie schnell Cases beim zuständigen Team oder bei der richtigen Person ankommen.
Woher beziehen
Erfasst werden Änderungen am Feld 'ownerid' der Entität 'Incident'. Der Timestamp der Änderung ist in den Auditprotokollen verfügbar.
Erfassung
Extrahieren Sie die mit einem Timestamp versehenen Änderungen am Feld 'ownerid' aus den Auditprotokollen.
Ereignistyp
explicit
|
|||
|
SLA-Timer gestartet
|
Zeigt an, dass für den Case ein Timer für ein Service Level Agreement (SLA) aktiviert wurde. Dieser erfasst die Zeit im Verhältnis zu einer festgelegten Servicekennzahl, etwa 'First Response By' oder 'Resolve By'. Das Ereignis wird ausdrücklich von der SLA-Engine in Dynamics 365 verwaltet. | ||
|
Warum das wichtig ist
Diese Aktivität ist grundlegend, um die SLA-Einhaltung zu überwachen und den Startzeitpunkt der Servicezusagen zu bestimmen. Sie ermöglicht direkt die Analyse, ob die Serviceziele erreicht werden.
Woher beziehen
Das Ereignis wird in der Entität 'SLA KPI Instance' protokolliert, die mit der Entität 'Incident' verknüpft ist. Der Timestamp 'createdon' des betreffenden SLA-KPI-Instance-Datensatzes markiert den Start.
Erfassung
Verwenden Sie den Erstellungs-Timestamp des mit dem Case verknüpften Datensatzes 'SLA KPI Instance'.
Ereignistyp
explicit
|
|||
|
Case reaktiviert
|
Dieses Ereignis tritt ein, wenn ein zuvor gelöster Case automatisch oder manuell wieder geöffnet wird, meist weil der Kunde geantwortet oder gemeldet hat, dass das Anliegen nicht behoben wurde. Dabei ändert das System den Case-Status standardmäßig von 'Resolved' zurück zu 'Active'. | ||
|
Warum das wichtig ist
Diese Aktivität ist wichtig, um Nacharbeit zu erkennen und die Kennzahl 'Lösungsrate beim Erstkontakt' zu analysieren. Viele Reaktivierungen deuten auf unvollständige oder unwirksame Erstlösungen hin.
Woher beziehen
Erfasst wird eine Änderung des Felds 'statecode' der Entität 'Incident' von 'Resolved' (1) zurück zu 'Active' (0). Der Timestamp dieser Änderung wird im Auditverlauf protokolliert.
Erfassung
Erfassen Sie in den Auditprotokollen den Timestamp der Änderung von 'statecode' von Resolved zu Active.
Ereignistyp
explicit
|
|||
|
Case-Kategorisierung geändert
|
Dieses Ereignis tritt ein, wenn ein Mitarbeitender nach der Erstellung die Kategorie oder das Thema eines Case ändert. Das System protokolliert diese Änderung ausdrücklich über die Auditfunktion. | ||
|
Warum das wichtig ist
Die Erfassung von Neukategorisierungen ist für die Kennzahl 'Neukategorisierungsrate von Serviceanfragen' wichtig. Häufige Änderungen weisen auf Probleme bei der ersten Triage hin, die zu falschen Weiterleitungen und Verzögerungen führen.
Woher beziehen
Erfasst anhand des Auditverlaufs der Entität 'Incident', insbesondere durch die Nachverfolgung von Änderungen am Feld 'subjectid' oder an anderen benutzerdefinierten Kategorisierungsfeldern.
Erfassung
Extrahieren Sie die mit einem Timestamp versehenen Änderungen am Feld 'subjectid' aus den Auditprotokollen.
Ereignistyp
explicit
|
|||
|
Informationen beim Kunden angefordert
|
Diese Aktivität markiert den Zeitpunkt, an dem der Mitarbeitende weitere Informationen vom Kunden benötigt, um fortzufahren. Sie wird häufig daraus abgeleitet, dass der Case-Status in einen Wartezustand wechselt oder eine ausgehende E-Mail über die Case-Zeitleiste versendet wird. | ||
|
Warum das wichtig ist
Diese Aktivität ist entscheidend, um kundenbedingte Verzögerungen und die Kennzahl 'Wartezeit auf Kundeninformationen' zu messen. Sie zeigt, wie viel Prozesszeit auf externe Rückmeldungen entfällt.
Woher beziehen
Das Ereignis lässt sich aus einer Änderung des Felds 'statuscode' der Entität 'Incident' ableiten, etwa auf den Wert 'On Hold' mit dem Grund 'Waiting for Customer'. Verwendet wird der Timestamp dieser Statusänderung.
Erfassung
Erfassen Sie den Timestamp einer Änderung von statuscode in einen festgelegten Status 'waiting for customer'.
Ereignistyp
inferred
|
|||
|
Lösungsvorschlag an Kunden übermittelt
|
Diese Aktivität zeigt an, dass der Mitarbeitende eine Lösung erarbeitet und dem Kunden mitgeteilt hat. Sie wird üblicherweise aus einer über die Case-Zeitleiste versendeten E-Mail oder einer Statusänderung zu 'Pending Customer Confirmation' abgeleitet. | ||
|
Warum das wichtig ist
Dieser Meilenstein markiert den Übergang von der Untersuchung zur Lösung. Die Analyse der Zeit zwischen dem Lösungsvorschlag und seiner Bestätigung kann Verzögerungen bei der Rückmeldung des Kunden oder Probleme mit dem Lösungsvorschlag aufdecken.
Woher beziehen
Das Ereignis lässt sich aus dem Timestamp eines ausgehenden, mit dem Case verknüpften Aktivitätsdatensatzes 'Email' oder aus einer Änderung des statuscode in einen Status vor der Lösung ableiten.
Erfassung
Verwenden Sie den Timestamp einer ausgehenden E-Mail-Aktivität oder einer Statusänderung zu 'Solution Proposed'.
Ereignistyp
inferred
|
|||
|
Mitarbeitender untersucht Anliegen
|
Diese Aktivität steht dafür, dass ein Mitarbeitender das Anliegen des Kunden untersucht und die Ursache ermittelt. Sie wird indirekt abgeleitet, häufig daran, dass der Mitarbeitende einen Knowledge-Artikel mit dem Case verknüpft. Das weist darauf hin, dass eine Recherche stattgefunden hat. | ||
|
Warum das wichtig ist
Die Erfassung zeigt, wie Wissensressourcen eingesetzt werden und welchen Einfluss sie auf die Lösungszeiten haben. So lässt sich erkennen, ob Mitarbeitende verfügbare Hilfsmittel wirksam einsetzen, um Anliegen effizient zu lösen.
Woher beziehen
Abgeleitet aus der Erstellung eines Datensatzes in der Entität 'IncidentKnowledgeBaseRecord', der einen Knowledge-Artikel mit einem Case verknüpft. Verwendet wird der Timestamp der Datensatzerstellung.
Erfassung
Verwenden Sie den Timestamp, zu dem ein Knowledge-Artikel mit dem Incident verknüpft wird.
Ereignistyp
inferred
|
|||
|
Warteschlangeneintrag von Mitarbeitendem übernommen
|
Dieses Ereignis tritt ein, wenn ein Mitarbeitender einen Case aktiv aus einer gemeinsamen Warteschlange übernimmt, um mit der Bearbeitung zu beginnen. Es handelt sich um eine bewusste Aktion des Benutzers, die sich von der Zuweisung des Case zur Warteschlange durch das System unterscheidet. | ||
|
Warum das wichtig ist
Mit dieser Aktivität lässt sich messen, wie lange ein Case tatsächlich in einer Warteschlange wartet, bevor ein Mitarbeitender mit der Bearbeitung beginnt. Sie ist wichtig, um Engpässe in Warteschlangen zu erkennen und die Eigeninitiative der Mitarbeitenden zu beurteilen.
Woher beziehen
Erfasst wird das Ereignis, wenn ein Benutzer das Feld 'workedbyid' der mit dem Case verknüpften Entität 'QueueItem' aktualisiert oder wenn sich der Case-Verantwortliche von einer Warteschlange zu einem Benutzer ändert.
Erfassung
Ermitteln Sie den Timestamp, zu dem das Feld 'workedbyid' des QueueItem befüllt wird.
Ereignistyp
explicit
|
|||
|
Zufriedenheitsumfrage versendet
|
Markiert den Versand einer Kundenzufriedenheitsumfrage, die üblicherweise automatisch nach der Lösung eines Case ausgelöst wird. Erfasst wird dies meist als ausgehende E-Mail oder als Aktivität einer Customer-Voice-Umfrage. | ||
|
Warum das wichtig ist
Diese Aktivität stellt den Zusammenhang zwischen dem operativen Prozess und den Ergebnissen der Customer Experience her. Sie ermöglicht es, Zufriedenheitswerte im Kontext des Prozessverlaufs eines Case zu analysieren.
Woher beziehen
Abgeleitet aus der Erstellung einer ausgehenden Aktivität 'Email' mit Umfragelink oder eines mit dem Case verknüpften Aktivitätsdatensatzes 'Customer Voice survey invite'.
Erfassung
Verwenden Sie den Erstellungs-Timestamp des umfragebezogenen Aktivitätsdatensatzes.
Ereignistyp
inferred
|
|||
Anleitungen zur Datenextraktion
Bereit für den Einstieg?
Mit dieser Datenvorlage starten Sie direkt mit Process Mining und entdecken neue Effizienzpotenziale in Ihrem Kundenservice. Optimieren Sie Ihre Workflows und verbessern Sie die Customer Experience.
Kundenservice optimieren: Erstlösungsquote steigern und Kosten senken
Erkennen Sie Engpässe und erreichen Sie eine Erstlösungsquote von 80 % beim ersten Kundenkontakt.
Keine Kreditkarte erforderlich. In wenigen Minuten eingerichtet.