Ihr Daten-Template für den Kundenservice

Salesforce Service Cloud
Ihr Daten-Template für den Kundenservice

Ihr Daten-Template für den Kundenservice

Dieses Template zeigt, wie Sie Ihre Kundenservicedaten für Process Mining aufbereiten. Es beschreibt die wichtigsten zu erfassenden Attribute und Aktivitäten und gibt praktische Hinweise zum Datenexport aus Ihrem Quellsystem. So stellen Sie sicher, dass Ihre Daten für aussagekräftige Analysen und Prozessverbesserungen bereitstehen.
  • Empfohlene Attribute für die Datenerfassung
  • Wichtige Aktivitäten für die Erfassung
  • Anleitung zum Datenexport
Neu bei Event Logs? Erfahren Sie, wie Sie ein Event Log für Process Mining erstellen.

Attribute im Kundenservice

Diese Datenfelder sollten Sie in Ihr Event Log aufnehmen, um Ihren Kundenservice umfassend zu analysieren.
5 Erforderlich 9 Empfohlen 6 Optional
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
Erforderlich Empfohlen Optional

Aktivitäten im Kundenservice

Diese wichtigen Prozessschritte und Meilensteine sollten Sie in Ihrem Event Log erfassen, um Ihre Kundenservice-Workflows zuverlässig zu entdecken und zu analysieren.
6 Empfohlen 9 Optional
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
Empfohlen Optional

Anleitungen zum Datenexport

So exportieren Sie Ihre Daten aus Salesforce Service Cloud

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.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich