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 zum Datenexport
Attribute im Kundenservice
| Name | Beschreibung | ||
|---|---|---|---|
|
Service Request
ServiceRequest
|
Eindeutige Kennung eines Kundenservice-Case oder Tickets, die alle zugehörigen Aktivitäten miteinander verknüpft. | ||
|
Beschreibung
Der Service Request, häufig auch Ticket oder Case genannt, dient als primäre Kennung und verknüpft alle Aktivitäten zu einer einzelnen Kundenanfrage oder einem Anliegen. In Salesforce Service Cloud entspricht dies der Case Number. Dieses Attribut ist entscheidend, um den gesamten Ablauf jeder Kundeninteraktion zu rekonstruieren. Das Process-Mining-Tool kann damit alle zugehörigen Ereignisse, etwa „Case erstellt“, „Mitarbeitende untersuchen das Anliegen“ und „Case gelöst“, zu einer Prozessinstanz zusammenfassen. So lässt sich der Ablauf von Anfang bis Ende analysieren.
Warum das wichtig ist
Dieses Attribut ist die grundlegende Voraussetzung für Process Mining: Es verknüpft alle Ereignisse zu einem Kundenanliegen in einer zusammenhängenden Prozessinstanz.
Woher beziehen
Salesforce Case-Objekt, Feld: CaseNumber
Beispiele
000010240000105800001193
|
|||
|
Aktivitätsname
ActivityName
|
Bezeichnung eines bestimmten geschäftlichen Ereignisses oder Prozessschritts im Kundenservice. | ||
|
Beschreibung
Dieses Attribut beschreibt einen einzelnen Schritt oder Meilenstein im Lebenszyklus eines Service Requests. Aktivitäten bilden die Knoten in der Prozesslandkarte und stehen für Handlungen von Mitarbeitenden, automatisierten Systemen oder Kunden. Die Analyse von Reihenfolge und Häufigkeit der Aktivitäten, etwa „Case erstellt“, „Interne Eskalation ausgelöst“ und „Case geschlossen“, ist zentral für Process Mining. Sie macht den tatsächlichen Prozessablauf sichtbar, zeigt Engpässe auf und deckt Abweichungen von der Standardvorgehensweise auf.
Warum das wichtig ist
Aktivitäten definieren die Prozessschritte. Ihre Reihenfolge bildet die Grundlage für die Prozesslandkarte und alle weiteren Analysen.
Woher beziehen
In der Regel aus einer Kombination von Feldern abgeleitet, etwa aus Statusänderungen im Case-Objekt (Feld Status) oder aus Datensätzen in den Objekten CaseHistory oder EmailMessage.
Beispiele
Case erstelltCase einer zuständigen Person zugewiesenLösung für den Kunden vorgeschlagenCase geschlossen
|
|||
|
Ereigniszeit
EventTime
|
Der genaue Timestamp, der angibt, wann eine Aktivität stattgefunden hat. | ||
|
Beschreibung
Die Ereigniszeit erfasst Datum und Uhrzeit, zu denen eine bestimmte Aktivität im System protokolliert wurde. Sie liefert den zeitlichen Kontext für den gesamten Prozess und ermöglicht die Berechnung von Dauer, Wartezeit und Zykluszeit. Bei der Analyse werden die Ereignisse anhand dieses Timestamps für jeden Service Request chronologisch geordnet. Das bildet die Grundlage für die Prozesserkennung. Die Ereigniszeit ist außerdem entscheidend für leistungsbezogene KPIs, etwa für die Messung der Zeit zwischen „Case erstellt“ und „Erste Eingangsbestätigung gesendet“ oder die Berechnung der gesamten Lösungszeit.
Warum das wichtig ist
Dieser Timestamp ist entscheidend, um den zeitlichen Ablauf des Prozesses zu verstehen, Leistungskennzahlen zu berechnen und Verzögerungen zwischen Aktivitäten zu erkennen.
Woher beziehen
Abgeleitet aus verschiedenen Datumsfeldern zu bestimmten Ereignissen, etwa aus CreatedDate im Case-Objekt oder CreatedDate in CaseHistory-Datensätzen.
Beispiele
2023-04-15T10:00:00Z2023-04-15T11:23:14Z2023-04-16T09:05:30Z
|
|||
|
Letzte Datenaktualisierung
LastDataUpdateTime
|
Timestamp der letzten Aktualisierung der Daten für diesen Prozess. | ||
|
Beschreibung
Dieses Attribut speichert den Timestamp der letzten Datenextraktion oder Aktualisierung aus dem Quellsystem. Es handelt sich um ein Metadatenfeld für den gesamten Datensatz, nicht für einzelne Ereignisse. Es informiert Benutzer darüber, wie aktuell die analysierten Daten sind. Das ist wichtig, damit Erkenntnisse und Entscheidungen auf aktuellen, relevanten Informationen beruhen. Außerdem hilft es, Erwartungen an die Aktualität der Daten zu steuern.
Warum das wichtig ist
Das Attribut macht transparent, wie aktuell die Daten sind, und hilft Benutzern einzuschätzen, auf welchem Stand ihre Analyse ist.
Woher beziehen
Dieser Wert wird üblicherweise während der Datenextraktion, -transformation und -ladung (ETL) erzeugt und gespeichert.
Beispiele
2023-10-27T04:00:00Z
|
|||
|
Quellsystem
SourceSystemName
|
Das System, aus dem die Prozessdaten stammen. | ||
|
Beschreibung
Dieses Attribut bezeichnet die Quellanwendung, in der die Daten erzeugt wurden. In diesem Fall ist das Salesforce Service Cloud. Es ist besonders hilfreich, wenn für eine umfassende Prozessansicht Daten aus mehreren Systemen zusammengeführt werden. Auch bei der Analyse eines einzelnen Systems liefert das Attribut wichtige Informationen zur Herkunft der Daten. Es unterstützt die Data Governance und die Fehlerbehebung und stellt sicher, dass Analysen auf dem richtigen Datensatz beruhen.
Warum das wichtig ist
Das Attribut liefert wichtige Informationen zur Herkunft der Daten. Diese sind für die Data Governance und für Analysen mit Daten aus mehreren Systemen unerlässlich.
Woher beziehen
Dieser statische Wert wird üblicherweise bei der Datenextraktion und -transformation hinzugefügt, um die Herkunft des Datensatzes zu kennzeichnen.
Beispiele
Salesforce Service CloudSFSC
|
|||
|
Beim Erstkontakt gelöst
IsFirstContactResolution
|
Kennzeichnet, ob der Case bereits beim ersten Kundenkontakt gelöst wurde. | ||
|
Beschreibung
Dieses boolesche Attribut kennzeichnet Serviceanfragen, die ohne weitere Rückfragen nach dem ersten Kundenkontakt gelöst wurden. Zur Ermittlung werden häufig die Abfolge und die Zeitpunkte der Aktivitäten analysiert. Eine hohe Erstlösungsquote (First Contact Resolution, FCR) ist ein wichtiger Indikator für einen effizienten und wirksamen Kundenservice. Dieses berechnete Attribut bildet die Grundlage für die KPI zur Erstlösungsquote. Eine Analyse der Cases, die nicht beim ersten Kontakt gelöst wurden, kann Verbesserungsmöglichkeiten bei der Agent-Schulung, den Inhalten der Wissensdatenbank und dem Prozessdesign aufzeigen.
Warum das wichtig ist
Das Attribut misst direkt einen wichtigen Aspekt der Serviceeffizienz und Kundenzufriedenheit. So lassen sich Faktoren erkennen, die zu einer erfolgreichen Problemlösung beitragen.
Woher beziehen
Wird während der Datentransformation durch Analyse des Event Logs für den jeweiligen Case berechnet. Eine gängige Regel prüft, ob „Case gelöst“ vor „Informationen beim Kunden angefordert“ oder einer späteren Aktivität zur Kontaktaufnahme mit dem Kunden auftritt.
Beispiele
truefalse
|
|||
|
Case-Priorität
CasePriority
|
Die Prioritätsstufe des Service Requests, zum Beispiel Hoch, Mittel oder Niedrig. | ||
|
Beschreibung
Die Case-Priorität ist eine Standardklassifizierung, mit der die Dringlichkeit eines Service Requests festgelegt wird. Sie bestimmt häufig die angestrebten Reaktions- und Lösungszeiten gemäß den Service Level Agreements (SLAs). Die Analyse der Prozessleistung nach Priorität ist entscheidend, um die Wirksamkeit der Priorisierungsstrategie zu bewerten. Sie zeigt, ob dringende Cases tatsächlich schneller gelöst werden und die anspruchsvollen SLA-Ziele erreichen. Damit unterstützt sie direkt das Dashboard zur Priorisierung und Auswirkung von Cases.
Warum das wichtig ist
Damit lässt sich analysieren, ob der Prozess dringende Cases wirksam priorisiert und je nach Bedeutung des Case die unterschiedlichen Service-Level-Ziele erreicht.
Woher beziehen
Salesforce Case-Objekt, Feld: Priority
Beispiele
HochMittelNiedrig
|
|||
|
Case-Status
CaseStatus
|
Der aktuelle Status des Service Requests in seinem Lebenszyklus, zum Beispiel Neu, In Bearbeitung oder Geschlossen. | ||
|
Beschreibung
Der Case-Status zeigt den aktuellen Status eines Service Requests an. Statusänderungen sind häufig die wichtigste Quelle zur Ermittlung von Aktivitäten im Prozess. So kann beispielsweise eine Änderung von „Neu“ zu „In Bearbeitung“ der Aktivität „Mitarbeitende untersuchen das Anliegen“ zugeordnet werden. Der endgültige Status eines Case hilft, das Ergebnis der Bearbeitung zu verstehen. Außerdem lässt sich damit nach offenen oder geschlossenen Cases filtern und erkennen, welche Cases zu lange in einem bestimmten Status feststecken.
Warum das wichtig ist
Das Attribut gibt Aufschluss über den aktuellen Status und das Ergebnis eines Cases. Statusänderungen dienen häufig dazu, die Abfolge der Aktivitäten abzuleiten.
Woher beziehen
Salesforce-Case-Objekt, Feld: Status
Beispiele
NeuIn BearbeitungWarten auf KundenGeschlossen
|
|||
|
Case-Typ
CaseType
|
Die Klassifizierung der Serviceanfrage, zum Beispiel Frage, Problem oder Funktionswunsch. | ||
|
Beschreibung
Der Case-Typ ist ein kategorisches Attribut, mit dem sich die Art der Kundenanfrage oder des Kundenproblems klassifizieren lässt. So können Sie Serviceanfragen segmentieren und nachvollziehen, wie unterschiedliche Anliegen bearbeitet werden. Eine Analyse des Prozesses nach Case-Typ kann zeigen, dass bestimmte Anfragen andere Prozesspfade durchlaufen, länger bis zur Lösung brauchen oder häufiger übergeben werden. Diese Erkenntnisse helfen dabei, den Prozess gezielt für bestimmte Arbeitskategorien anzupassen und zu verbessern.
Warum das wichtig ist
Damit lässt sich der Prozess segmentieren. So können Sie feststellen, ob unterschiedliche Anfragen verschieden bearbeitet werden, und gezielt Verbesserungsbedarf in einzelnen Bereichen erkennen.
Woher beziehen
Salesforce-Case-Objekt, Feld: Type
Beispiele
ProblemFunktionswunschFrage
|
|||
|
Endzeit
EndTime
|
Der Timestamp, der angibt, wann eine Aktivität abgeschlossen wurde. | ||
|
Beschreibung
Die Endzeit gibt an, wann eine Aktivität abgeschlossen wurde. Zusammen mit der Startzeit ermöglicht sie die genaue Berechnung der Bearbeitungszeit einer Aktivität. Bei vielen Ereignissen in Salesforce handelt es sich um punktuelle Vorgänge, bei denen Start- und Endzeit identisch sind. Bei länger dauernden Aktivitäten ist eine separate Endzeit jedoch entscheidend, um die tatsächlich für eine Aufgabe aufgewendete Zeit zu messen. Sie unterstützt die Leistungsanalyse, indem sie die aktive Bearbeitungszeit von den Wartezeiten zwischen den Schritten unterscheidet.
Warum das wichtig ist
Damit lässt sich die tatsächliche Dauer einer Aktivität berechnen. Das ist wichtig, um die Leistung der Mitarbeitenden zu analysieren und zeitaufwendige Schritte zu erkennen.
Woher beziehen
Bei punktuellen Ereignissen entspricht dieser Wert häufig der StartTime. Bei Aktivitäten mit einer Dauer muss er aus einem bestimmten Abschlussfeld stammen, für das möglicherweise eine benutzerdefinierte Konfiguration erforderlich ist.
Beispiele
2023-04-15T10:00:00Z2023-04-15T11:55:00Z2023-04-16T14:20:00Z
|
|||
|
Kommunikationskanal
CommunicationChannel
|
Der Kanal, über den der Service Request eingegangen ist, zum Beispiel per E-Mail, Telefon oder Web. | ||
|
Beschreibung
Dieses Attribut gibt an, über welchen Kommunikationsweg der Kunde seinen Service Request eingereicht hat. In Salesforce wird dies häufig im Feld Case Origin erfasst. Der Kommunikationskanal ist wichtig, um den Ressourceneinsatz zu optimieren und den Service effizienter zu gestalten. Durch den Vergleich von Lösungszeiten und Prozessabläufen nach Kanal können Unternehmen erkennen, welche Kanäle sich für welche Anliegen am besten eignen. Das unterstützt das Dashboard zur Effizienz der Kommunikationskanäle.
Warum das wichtig ist
Damit lässt sich die Leistung verschiedener Kundenkontaktkanäle vergleichen. So können Sie die Kanalstrategie und den Ressourceneinsatz optimieren.
Woher beziehen
Salesforce Case-Objekt, Feld: Origin
Beispiele
E-MailTelefonWebChat
|
|||
|
SLA-Status
SlaStatus
|
Gibt an, ob der Case innerhalb der SLA-Zielzeit gelöst wurde. | ||
|
Beschreibung
Dieses Attribut ordnet jeden gelösten Case danach ein, ob das festgelegte Service Level Agreement eingehalten wurde. Dazu wird der tatsächliche Lösungszeitpunkt mit der „SLA-Zielzeit für die Lösung“ verglichen. Als direkte Eingangsgröße für die KPI zur SLA-Einhaltungsquote vereinfacht das Attribut die Leistungsüberwachung. Sie können alle nicht konformen Cases schnell filtern und analysieren, um häufige Ursachen für SLA-Verletzungen zu erkennen, etwa bestimmte Case-Typen, Produkte oder Prozessengpässe.
Warum das wichtig ist
Das Attribut zeigt für jeden Case eindeutig an, ob das SLA eingehalten wurde. Diese Information ist grundlegend für die Leistungsüberwachung und die Ursachenanalyse bei Verzögerungen.
Woher beziehen
Wird in der Datentransformationsschicht berechnet, indem der Timestamp von „Case gelöst“ mit dem Attribut „SlaTargetResolutionTime“ verglichen wird.
Beispiele
EingehaltenVerletzt
|
|||
|
SLA-Zielzeit für die Lösung
SlaTargetResolutionTime
|
Der laut SLA festgelegte Zeitpunkt, bis zu dem die Serviceanfrage gelöst sein soll. | ||
|
Beschreibung
Dieses Attribut legt die Frist zur Lösung eines Cases gemäß Service Level Agreement (SLA) fest. Sie richtet sich in der Regel nach Faktoren wie Priorität und Typ des Cases sowie der Kundenstufe. Salesforce kann die Frist mithilfe der Funktionen für Berechtigungen und Meilensteine automatisch berechnen. Dieser Timestamp ist entscheidend, um die Einhaltung des SLA zu messen. Durch den Vergleich der tatsächlichen Lösungszeit mit der Zielzeit kann das Unternehmen die KPI zur SLA-Einhaltungsquote berechnen und Cases erkennen, bei denen eine SLA-Verletzung droht. Das unterstützt direkt das Dashboard zur SLA-Einhaltung bei Cases.
Warum das wichtig ist
Das Attribut dient als Vergleichswert für die tatsächliche Leistung. Es ist daher entscheidend, um die SLA-Einhaltung zu berechnen und gefährdete Cases zu erkennen.
Woher beziehen
Der Wert ist häufig im Feld SlaExitDate des Objekts Case Milestone gespeichert, das zu Salesforce Entitlement Management gehört.
Beispiele
2023-04-16T17:00:00Z2023-04-18T09:00:00Z2023-05-01T12:00:00Z
|
|||
|
Zugewiesene Person
AssignedAgent
|
Die Person oder Warteschlange, der der Service Request derzeit zugewiesen ist. | ||
|
Beschreibung
Dieses Attribut bezeichnet die Person oder das Team, die beziehungsweise das zu einem bestimmten Zeitpunkt für die Bearbeitung des Service Requests zuständig ist. In Salesforce ist dies üblicherweise der Case Owner. Die Erfassung von Änderungen an diesem Attribut ist grundlegend für die Analyse der Leistung einzelner Mitarbeitender, der Arbeitsverteilung und der Übergaben. Damit lässt sich beispielsweise ermitteln, wie oft ein Case neu zugewiesen wird, wer die komplexesten Cases bearbeitet und ob die Arbeitslast im Team ausgewogen ist. Das Attribut ist wichtig für die Dashboards zu Übergaben zwischen Mitarbeitenden und zur Arbeitsverteilung.
Warum das wichtig ist
Das Attribut ist wichtig, um die Arbeitslast und Leistung der Mitarbeitenden sowie die Häufigkeit von Übergaben zu analysieren. Diese Faktoren wirken sich direkt auf Effizienz und Lösungszeit aus.
Woher beziehen
Salesforce Case-Objekt, Feld: OwnerId. Dieses Feld enthält die ID eines Benutzers oder einer Warteschlange.
Beispiele
Sarah JonesDavid ChenTier-2-Support-Warteschlange
|
|||
|
Anzahl der Agent-Übergaben
AgentHandoffCount
|
Wie oft ein Case von einem Agent oder einer Warteschlange an einen anderen Agent oder eine andere Warteschlange weitergeleitet wurde. | ||
|
Beschreibung
Diese Kennzahl erfasst, wie oft eine Serviceanfrage vor ihrer Lösung neu zugewiesen wird. Sie wird berechnet, indem die unterschiedlichen Änderungen des Attributs „AssignedAgent“ im Lebenszyklus eines einzelnen Cases gezählt werden. Dieses Attribut bildet die Grundlage für die KPI zu den durchschnittlichen Agent-Übergaben pro Case und wird im Dashboard zu Agent-Übergaben und Nacharbeitsmustern visualisiert. Eine hohe Zahl an Übergaben weist häufig auf ineffiziente Abläufe, unklare Zuständigkeiten oder Wissenslücken hin. All dies kann die Lösungszeit verlängern und Kunden frustrieren.
Warum das wichtig ist
Das Attribut macht interne Reibungsverluste im Prozess messbar. Zu viele Übergaben führen häufig zu Verzögerungen und Unzufriedenheit bei Kunden.
Woher beziehen
Wird während der Datentransformation auf Case-Ebene berechnet. Dazu wird für jedes „ServiceRequest“ die Anzahl der eindeutigen Werte im Feld „AssignedAgent“ gezählt und um eins verringert.
Beispiele
0135
|
|||
|
Betreff des Cases
CaseSubject
|
Eine kurze Zusammenfassung oder Überschrift des Kundenproblems oder der Kundenanfrage. | ||
|
Beschreibung
Der Betreff des Cases fasst die Serviceanfrage in einem kurzen Freitext zusammen. Häufig handelt es sich um den Betreff einer E-Mail oder einen Titel, den ein Agent oder Kunde eingegeben hat. Der Betreff ist kein strukturiertes Feld für die direkte Prozessanalyse, enthält aber viele Kontextinformationen. Mit Text-Mining-Verfahren können Sie Cases kategorisieren, neu auftretende Probleme erkennen oder quantitative Prozessanalysen um qualitative Informationen ergänzen.
Warum das wichtig ist
Der Betreff liefert schnell einen groben Überblick über den Case. Das ist für Analysen auf einer tieferen Ebene hilfreich und lässt sich auch für Text Mining verwenden.
Woher beziehen
Salesforce-Case-Objekt, Feld: Subject
Beispiele
Anmeldung im Portal nicht möglichFrage zur AbrechnungFunktionswunsch für das Reporting-Dashboard
|
|||
|
Betroffenes Produkt
ProductInvolved
|
Das konkrete Produkt oder die Dienstleistung, auf die sich die Kundenanfrage bezieht. | ||
|
Beschreibung
Dieses Attribut ordnet eine Serviceanfrage einem bestimmten Produkt oder einer bestimmten Dienstleistung zu. In Salesforce erfolgt die Zuordnung häufig über ein Lookup-Feld zum Product-Objekt. Für die Analyse der Produktqualität ist es wichtig, Prozessdaten nach Produkt zu segmentieren. So lässt sich feststellen, welche Produkte die meisten Supportanfragen verursachen, welche Probleme auftreten und ob sich der Lösungsprozess je nach Produktlinie unterscheidet. Diese Informationen sind wertvolles Feedback für die Produktentwicklung.
Warum das wichtig ist
Damit können Sie Prozesse nach Produkt analysieren und Qualitätsprobleme oder Lücken im Support für bestimmte Produkte aufdecken.
Woher beziehen
Salesforce-Case-Objekt, Feld: ProductId. Dies ist ein standardmäßiges, aber optionales Lookup-Feld.
Beispiele
Alpha CRM SuiteBeta Analytics ToolGamma Data Connector
|
|||
|
Eskaliert
IsEscalated
|
Kennzeichnet, ob der Case eskaliert wurde. | ||
|
Beschreibung
Dieses boolesche Attribut gibt an, ob eine Serviceanfrage eskaliert wurde. In Salesforce lässt sich dies über das Standardfeld IsEscalated erfassen, das anhand von Eskalationsregeln automatisch gesetzt wird. Das Attribut fließt direkt in das Dashboard zur Analyse interner Eskalationen und in die KPI zur internen Eskalationsrate ein. Damit lassen sich alle eskalierten Cases einfach filtern und zusammenfassen. So können Sie ihre Häufigkeit messen und ihren Einfluss auf die gesamte Lösungszeit und Prozesskomplexität untersuchen.
Warum das wichtig ist
Das Attribut misst Eskalationen bei Cases direkt. Sie können auf Reibungsverluste im Prozess, hohe Komplexität oder Wissenslücken bei Agents hinweisen.
Woher beziehen
Salesforce-Case-Objekt, Feld: IsEscalated
Beispiele
truefalse
|
|||
|
Kundenname
CustomerName
|
Der Name des Kunden oder Kontos, dem die Serviceanfrage zugeordnet ist. | ||
|
Beschreibung
Dieses Attribut gibt an, welcher Kunde die Serviceanfrage gestellt hat. In Salesforce kann es sich dabei um einen Contact (eine Einzelperson) oder einen Account (ein Unternehmen) handeln. Eine Analyse aus Kundensicht kann wertvolle Erkenntnisse liefern. Sie kann zum Beispiel zeigen, ob bestimmte Kunden häufiger Probleme haben oder länger auf eine Lösung warten. Diese Erkenntnisse können in die Kundenbeziehungsstrategie einfließen und Möglichkeiten für proaktiven Support aufzeigen.
Warum das wichtig ist
Das Attribut ermöglicht eine kundenorientierte Analyse. So lassen sich Muster und Leistungsunterschiede bei einzelnen Kunden oder Kundensegmenten erkennen.
Woher beziehen
Salesforce-Case-Objekt, Felder: ContactId oder AccountId. Diese verweisen jeweils auf die Objekte Contact und Account.
Beispiele
Global Tech Inc.Emily WhiteInnovate Solutions
|
|||
|
Nacharbeit
IsRework
|
Kennzeichnet, ob bei einem Case Nacharbeit oder eine Rückkehr zu einer früheren Prozessphase auftrat. | ||
|
Beschreibung
Dieses boolesche Attribut kennzeichnet Cases mit Nacharbeitsmustern, zum Beispiel wenn ein Case nach dem Schließen wieder geöffnet wird oder wiederholt zwischen „Agent untersucht“ und „Lösung vorgeschlagen“ wechselt. Um Nacharbeit zu erkennen, muss die Abfolge der Aktivitäten auf unerwünschte Schleifen untersucht werden. Das Attribut unterstützt direkt die KPI zur Nacharbeitsquote und das Dashboard zu Agent-Übergaben und Nacharbeitsmustern. Wenn Sie Cases mit Nacharbeit gezielt untersuchen, können Sie die Ursachen ermitteln. Dazu zählen etwa unzureichende Lösungen oder eine unvollständige Informationsbeschaffung. Anschließend können Sie Korrekturmaßnahmen ergreifen.
Warum das wichtig ist
Das Attribut macht ineffiziente Abläufe und unnötigen Aufwand sichtbar. So können Sie Aktivitäten gezielt untersuchen, die häufig wiederholt werden.
Woher beziehen
Wird während der Datentransformation durch Analyse der Aktivitätsabfolgen berechnet. Eine Abfolge wie „Case geschlossen“ -> „Case wieder geöffnet“ oder „Lösung vorgeschlagen“ -> „Agent untersucht Problem“ innerhalb desselben Cases wird beispielsweise als Nacharbeit gekennzeichnet.
Beispiele
truefalse
|
|||
Aktivitäten im Kundenservice
| Aktivität | Beschreibung | ||
|---|---|---|---|
|
Case einer zuständigen Person zugewiesen
|
Diese Aktivität markiert den Zeitpunkt, an dem ein Service Request einer bestimmten Person oder Warteschlange zur Bearbeitung zugewiesen wird. Dieser grundlegende Prozessschritt wird durch eine Änderung des Eigentümerfeldes des Case erfasst. | ||
|
Warum das wichtig ist
Diese Aktivität ist wichtig, um die Arbeitslast der Mitarbeitenden, Verzögerungen bei der Zuweisung und die Häufigkeit von Übergaben zu verfolgen. Sie bildet die Grundlage für die Analyse der Leistung einzelner Mitarbeitender und hilft, Engpässe bei der Zuweisung zu erkennen.
Woher beziehen
Abgeleitet aus einer Änderung des Feldes OwnerId im Case-Objekt. Der Timestamp dieser Änderung wird im CaseHistory-Objekt gespeichert.
Erfassung
Den Timestamp der ersten Aktualisierung des Feldes OwnerId ermitteln.
Ereignistyp
inferred
|
|||
|
Case erstellt
|
Diese Aktivität markiert den offiziellen Beginn des Kundenservice-Prozesses: Ein neuer Service Request, auch Case genannt, wird in Salesforce erfasst. Das Ereignis wird mit einem präzisen Timestamp festgehalten, sobald ein neuer Datensatz im Case-Objekt angelegt wird. | ||
|
Warum das wichtig ist
Als primäres Start-Event ist diese Aktivität entscheidend, um den gesamten Lebenszyklus eines Case und die Lösungszeiten zu berechnen. Sie bildet die Grundlage für den Leistungsvergleich mit SLAs und die Analyse des Case-Aufkommens.
Woher beziehen
Dieses Ereignis entspricht dem Anlegen eines Datensatzes im Case-Objekt. Der Timestamp wird im Standardfeld CreatedDate erfasst.
Erfassung
Direkt aus dem Erstellungs-Timestamp des Case-Datensatzes.
Ereignistyp
explicit
|
|||
|
Case gelöst
|
Dieser wichtige Meilenstein zeigt an, dass die zuständige Person die erforderlichen Arbeiten zur Lösung des Kundenanliegens abgeschlossen hat. Der Case wartet nun auf den endgültigen Abschluss, der nach einer bestimmten Zeit automatisch erfolgen kann. | ||
|
Warum das wichtig ist
Dieser zentrale Endpunkt dient zur Messung der Lösungszeit und ist entscheidend für die Berechnung der SLA-Einhaltung. Er markiert das Ende der aktiven Bearbeitung des Case.
Woher beziehen
Abgeleitet aus dem CaseHistory-Objekt, wenn das Feld Status auf „Resolved“ gesetzt wird. Das Feld IsClosed kann zu diesem Zeitpunkt noch auf „false“ stehen.
Erfassung
Timestamp der Statusänderung des Case zu „Resolved“.
Ereignistyp
inferred
|
|||
|
Case geschlossen
|
Diese Aktivität markiert das endgültige Ende des Lebenszyklus eines Service Requests. Nach dem Schließen eines Case sind keine weiteren Arbeiten vorgesehen, sofern er nicht wieder geöffnet wird. | ||
|
Warum das wichtig ist
Als abschließendes Ereignis bildet diese Aktivität den Endpunkt für die Berechnung der gesamten Dauer eines Case. Auch die Zeit zwischen „Resolved“ und „Closed“ kann Ineffizienzen beim Abschluss sichtbar machen.
Woher beziehen
Abgeleitet aus dem Timestamp, zu dem das Feld IsClosed im Case-Objekt auf „true“ gesetzt wird. Zu diesem Zeitpunkt wird auch das Feld ClosedDate ausgefüllt.
Erfassung
Timestamp, zu dem das Feld IsClosed auf „true“ gesetzt und in CaseHistory protokolliert wird.
Ereignistyp
inferred
|
|||
|
Interne Eskalation ausgelöst
|
Diese Aktivität findet statt, wenn ein Case ein höheres Maß an Support oder Fachwissen erfordert und offiziell eskaliert wird. Salesforce kann sie über Eskalationsregeln direkt erfassen oder aus einer Feldänderung ableiten. | ||
|
Warum das wichtig ist
Die Analyse von Eskalationen hilft, komplexe Case-Typen, Schulungsbedarf bei Mitarbeitenden im First-Level-Support und systemische Probleme zu erkennen. Sie ist ein wichtiger Indikator für Reibungsverluste im Prozess und deren Einfluss auf die Lösungszeit.
Woher beziehen
Das Ereignis kann direkt aus CaseEscalation-Datensätzen erfasst werden. Häufiger wird es aus CaseHistory abgeleitet, wenn ein Kontrollkästchen wie „IsEscalated“ auf „true“ gesetzt wird.
Erfassung
Timestamp, zu dem das Feld „IsEscalated“ auf „true“ gesetzt wird.
Ereignistyp
inferred
|
|||
|
SLA-Meilenstein verfehlt
|
Dieses Ereignis wird ausgelöst, wenn eine Servicezusage, etwa zur ersten Reaktion oder zur Lösungszeit, nicht eingehalten wird. Salesforce erfasst dies über Entitlement-Prozesse und Meilenstein-Datensätze. | ||
|
Warum das wichtig ist
Diese Aktivität ist entscheidend für die Analyse der SLA-Einhaltung und die Compliance-Überwachung. Sie zeigt direkt, bei welchen Cases die Kundenerwartungen nicht erfüllt wurden, und ermöglicht gezielte Prozessverbesserungen.
Woher beziehen
Erfasst über das CaseMilestone-Objekt. Ein Ereignis wird generiert, wenn das Feld IsViolated eines Meilenstein-Datensatzes auf „true“ gesetzt wird.
Erfassung
Der Timestamp des Ereignisses entspricht dem Zeitpunkt, zu dem das IsViolated-Kennzeichen eines CaseMilestone-Datensatzes auf „true“ gesetzt wird.
Ereignistyp
explicit
|
|||
|
Case kategorisiert und priorisiert
|
Diese Aktivität findet statt, wenn einem Case ein Typ, eine Kategorie und eine Prioritätsstufe zugewiesen werden. Das übernimmt häufig ein Triage-Team oder eine Automatisierungsregel. Die Aktivität lässt sich aus Änderungen an den entsprechenden Case-Feldern ableiten. | ||
|
Warum das wichtig ist
Die Kategorisierung ist entscheidend, um die Verteilung der Cases und die Wirksamkeit der Weiterleitung zu verstehen. Die Analyse dieses Schritts hilft, die Arbeitsverteilung zu optimieren und sicherzustellen, dass dringende Cases zeitnah bearbeitet werden.
Woher beziehen
Abgeleitet aus dem CaseHistory-Objekt, indem ermittelt wird, wann die Felder Priority, Type oder andere Klassifizierungsfelder erstmals ausgefüllt oder von ihren Standardwerten geändert wurden.
Erfassung
Änderungen an Feldern wie Priority oder Type in CaseHistory erfassen.
Ereignistyp
inferred
|
|||
|
Case neu zugewiesen
|
Diese Aktivität bezeichnet die Übergabe eines Case von einer Person oder Warteschlange an eine andere, nachdem die erste Zuweisung bereits erfolgt ist. Sie lässt sich aus späteren Änderungen des Eigentümerfeldes des Case ableiten. | ||
|
Warum das wichtig ist
Häufige Neuzuweisungen können auf eine falsche anfängliche Weiterleitung, ineffiziente Abläufe oder fehlendes Wissen hindeuten. Sie führen zu Verzögerungen und einer schlechten Customer Experience. Mit dieser Aktivität lässt sich die Zahl der Übergaben zwischen Mitarbeitenden ermitteln.
Woher beziehen
Abgeleitet aus jeder Änderung des Feldes OwnerId im CaseHistory-Objekt nach der ersten Zuweisung.
Erfassung
Alle Aktualisierungen des Feldes OwnerId nach der ersten erfassen.
Ereignistyp
inferred
|
|||
|
Case wieder geöffnet
|
Diese Aktivität tritt auf, wenn ein zuvor gelöster oder geschlossener Case erneut bearbeitet wird, weil das Problem wieder auftritt oder die Lösung nicht funktioniert hat. Sie ist ein wichtiger Hinweis auf Nacharbeit. | ||
|
Warum das wichtig ist
Wieder geöffnete Cases weisen häufig auf Lösungen von geringer Qualität oder eine nicht erfolgreiche First Contact Resolution hin. Um die Servicequalität zu verbessern, müssen ihre Häufigkeit und Ursachen analysiert werden.
Woher beziehen
Abgeleitet aus dem CaseHistory-Objekt, wenn sich das Feld IsClosed von „true“ zu „false“ ändert oder der Status von „Geschlossen“ beziehungsweise „Gelöst“ zurück zu „Offen“ wechselt.
Erfassung
Timestamp, zu dem sich Status oder IsClosed-Feld von einem abgeschlossenen zu einem aktiven Status ändert.
Ereignistyp
inferred
|
|||
|
Erste Eingangsbestätigung gesendet
|
Diese Aktivität bezeichnet die erste Mitteilung an den Kunden, mit der der Eingang seines Service Requests bestätigt wird. Meist handelt es sich um eine automatische E-Mail, die durch Regeln zur Case-Erstellung ausgelöst wird. Sie lässt sich anhand der ersten ausgehenden Mitteilung ermitteln. | ||
|
Warum das wichtig ist
Die Erfassung dieser Aktivität ist wichtig, um die anfängliche Reaktionszeit zu messen und sicherzustellen, dass Kunden zeitnah informiert werden. Sie unterstützt die Analyse der KPI „Verzögerung bis zur ersten Eingangsbestätigung“ und damit die Verbesserung der Kundenkommunikation.
Woher beziehen
Abgeleitet aus dem Timestamp des ersten ausgehenden EmailMessage-Datensatzes, der mit dem Case verknüpft ist. Alternativ lässt sich die Aktivität aus einer Aktualisierung eines benutzerdefinierten Feldes ableiten, die durch eine Automatisierungsregel ausgelöst wird.
Erfassung
Den Timestamp der ersten ausgehenden EmailMessage ermitteln, die mit dem Case verknüpft ist.
Ereignistyp
inferred
|
|||
|
Informationen beim Kunden angefordert
|
Diese Aktivität findet statt, wenn eine zuständige Person weitere Informationen vom Kunden benötigt, um den Case zu bearbeiten. Sie wird in der Regel aus einer Statusänderung des Case zu „Warten auf Kunden“ abgeleitet. | ||
|
Warum das wichtig ist
Mit dieser Aktivität beginnt eine Wartezeit, die nicht von den Mitarbeitenden beeinflusst werden kann. Wenn Sie diese Zeit separat betrachten, können Sie die interne Prozesseffizienz und die Leistung der Mitarbeitenden genauer messen.
Woher beziehen
Abgeleitet aus dem CaseHistory-Objekt, wenn das Feld Status auf einen Wert wie „Waiting on Customer Response“ oder „Pending“ gesetzt wird.
Erfassung
Timestamp der Statusänderung des Case zu einem Warte-Status.
Ereignistyp
inferred
|
|||
|
Informationen vom Kunden erhalten
|
Diese Aktivität markiert das Ende der Wartezeit, sobald der Kunde die angeforderten Informationen bereitstellt. Sie lässt sich häufig daran erkennen, dass der Case nach einer eingehenden Mitteilung wieder auf einen aktiven Status gesetzt wird. | ||
|
Warum das wichtig ist
Die Erfassung dieses Ereignisses ist wichtig, um die Reaktionszeiten der Kunden und deren Einfluss auf den gesamten Lebenszyklus des Case zu verstehen. Es zeigt an, dass die aktive Bearbeitung durch die zuständige Person wieder aufgenommen wird.
Woher beziehen
Abgeleitet aus dem Timestamp einer eingehenden EmailMessage, die mit dem Case verknüpft ist, oder aus einer Statusänderung von „Waiting on Customer“ zurück zu „In Progress“ im CaseHistory-Objekt.
Erfassung
Timestamp der eingehenden E-Mail oder der Statusänderung aus einem Warte-Status.
Ereignistyp
inferred
|
|||
|
Lösung für den Kunden vorgeschlagen
|
Diese Aktivität bezeichnet den Zeitpunkt, an dem eine zuständige Person dem Kunden eine mögliche Lösung mitteilt. Dieser konzeptionelle Schritt wird meist aus einer ausgehenden Mitteilung oder einer bestimmten Statusänderung abgeleitet. | ||
|
Warum das wichtig ist
Mit diesem Meilenstein lässt sich die Zeit von der Untersuchung bis zum Lösungsvorschlag messen. Wird der Vorschlag nicht angenommen, kann hier auch eine Rückkopplungsschleife beginnen.
Woher beziehen
Abgeleitet aus einer ausgehenden EmailMessage mit bestimmten Schlüsselwörtern oder aus einer Statusänderung zu „Solution Provided“ im CaseHistory-Objekt.
Erfassung
Timestamp der Statusänderung oder der ausgehenden Mitteilung.
Ereignistyp
inferred
|
|||
|
Mitarbeitende untersuchen das Anliegen
|
Diese Phase umfasst die aktive Diagnose und Analyse des Kundenanliegens durch eine zuständige Person. Sie wird nicht als eigenes Ereignis erfasst, sondern aus einer Statusänderung des Case von „Neu“ oder „Offen“ zu „In Bearbeitung“ abgeleitet. | ||
|
Warum das wichtig ist
Die Dauer der Untersuchungsphase zeigt, welche Service Requests besonders komplex sind und wo Mitarbeitende möglicherweise zusätzliche Schulungen oder Ressourcen benötigen. So lässt sich die aktive Bearbeitungszeit von der Wartezeit unterscheiden.
Woher beziehen
Abgeleitet aus dem CaseHistory-Objekt, wenn das Feld Status auf einen Wert für aktive Bearbeitung gesetzt wird, etwa „In Progress“ oder „Working“.
Erfassung
Timestamp der Statusänderung des Case zu einem Wert für „In Bearbeitung“.
Ereignistyp
inferred
|
|||
|
Zufriedenheitsumfrage gesendet
|
Diese Aktivität bezeichnet den Versand einer Kundenzufriedenheitsumfrage (CSAT) oder einer Umfrage zum Net Promoter Score (NPS). In der Regel wird sie automatisch nach der Lösung oder dem Abschluss eines Case ausgelöst. | ||
|
Warum das wichtig ist
Diese Aktivität gehört zwar nicht zum eigentlichen Lösungsprozess, ist aber wichtig, um die Rückmeldeschleife zu verstehen. Die Analyse von Zeitpunkt und Häufigkeit stellt sicher, dass die Kundenstimme regelmäßig erfasst wird.
Woher beziehen
Abgeleitet aus einem mit dem Case verknüpften ausgehenden EmailMessage-Datensatz, der einer Umfragevorlage entspricht. Alternativ lässt sich die Aktivität anhand der Erstellung eines SurveyInvitation-Datensatzes erfassen.
Erfassung
Ausgehende Umfrage-E-Mail oder Erstellung eines SurveyInvitation-Datensatzes ermitteln.
Ereignistyp
inferred
|
|||
Anleitungen zum Datenexport
Möchten Sie loslegen?
Mit diesem Daten-Template können Sie Ihre Process-Mining-Analyse starten und bislang unerkannte Verbesserungsmöglichkeiten im Kundenservice aufdecken. Verbessern Sie Ihren Service noch heute!
Steigern Sie jetzt die Effizienz Ihres Kundenservice
Erreichen Sie eine Erstlösungsquote von 80 % und steigern Sie die CSAT-Werte.
Keine Kreditkarte erforderlich