Your Customer Service Data Template
Your Customer Service Data Template
- Recommended attributes to collect
- Key activities to track
- Extraction guidance for Microsoft Dynamics 365 Customer Service
Customer Service Attributes
| Name | Description | ||
|---|---|---|---|
|
Service Request
ServiceRequest
|
The unique identifier for a customer service request, also known as a case or ticket. | ||
|
Description
The Service Request serves as the primary identifier, linking all activities related to a single customer inquiry or issue. It acts as the Case ID for process mining, ensuring a complete and consistent view of each customer interaction from creation to closure. Analyzing by Service Request allows for tracking the end-to-end journey, measuring resolution times, and identifying patterns across similar cases.
Why it matters
This is the essential Case ID that connects all related events into a single process instance, making end-to-end process analysis possible.
Where to get
This is the primary key of the Case (incident) entity in Microsoft Dynamics 365 Customer Service.
Examples
CAS-01024-F3B4V6SR-2023-00589TKT-4815162342
|
|||
|
Activity
ActivityName
|
The name of the specific business event that occurred at a point in time for a service request. | ||
|
Description
This attribute describes a single step or status change within the customer service process, such as 'Case Created', 'Agent Investigated Issue', or 'Case Resolved'. These activities form the backbone of the process map, allowing for the visualization and analysis of the process flow. Each activity, when combined with a timestamp, creates an event that defines the process sequence.
Why it matters
Activities define the steps in the process. Analyzing the sequence and frequency of activities is fundamental to understanding process flows, identifying deviations, and finding bottlenecks.
Where to get
Typically derived by mapping status changes (statuscode) or specific events from related entities like Tasks, Emails, or Phone Calls to a standardized activity name.
Examples
Case CreatedAgent Investigated IssueSolution Proposed To CustomerCase Closed
|
|||
|
Last Data Update
LastDataUpdate
|
The timestamp of the last data refresh or extraction from the source system. | ||
|
Description
This attribute indicates when the data was last pulled from Microsoft Dynamics 365. It is used to understand the freshness of the data being analyzed and is essential for reporting and monitoring purposes. It ensures that users are aware of the data's timeliness when interpreting dashboards and analyses.
Why it matters
Informs users about the recency of the data, which is vital for making timely and accurate business decisions based on the process analysis.
Where to get
This value is generated and stamped on the dataset at the time of data extraction.
Examples
2023-10-27T08:00:00Z
|
|||
|
Source System
SourceSystem
|
Identifies the source system from which the data was extracted. | ||
|
Description
This attribute specifies the origin of the event data. For this process, it will consistently identify Microsoft Dynamics 365 Customer Service as the source. In environments with multiple systems, this field is critical for distinguishing data sources and ensuring data lineage.
Why it matters
Provides clear data lineage, which is crucial for data governance and for troubleshooting data inconsistencies, especially in blended-system analyses.
Where to get
This is typically a static value added during the data extraction and transformation process to label the dataset's origin.
Examples
Microsoft Dynamics 365 Customer Service
|
|||
|
Start Time
EventTime
|
The timestamp indicating when the activity occurred. | ||
|
Description
This attribute records the precise date and time that a specific activity took place. It is essential for sequencing events correctly and for all time-based analysis, including calculating cycle times, durations, and wait times between activities. An accurate and consistent timestamp is critical for the integrity of the process mining analysis.
Why it matters
This timestamp orders events chronologically and enables all duration-based calculations, which are crucial for performance analysis and bottleneck identification.
Where to get
This corresponds to fields like 'createdon' or 'modifiedon' on the Case (incident) entity or related activity entities (e.g., Email, Task, Phone Call).
Examples
2023-04-15T10:00:00Z2023-05-20T14:35:10Z2023-06-01T09:12:45Z
|
|||
|
Agent Name
AgentName
|
The name of the customer service agent or user responsible for the activity. | ||
|
Description
This attribute identifies the specific agent or system user who performed an activity, such as picking an item from a queue or resolving a case. It is crucial for analyzing agent performance, workload distribution, and resource allocation. By tracking activities at the agent level, organizations can identify top performers, training needs, and imbalances in workload.
Why it matters
Enables analysis of individual and team performance, helps balance workload, and identifies coaching opportunities to improve overall service quality.
Where to get
Corresponds to the 'Owner' (ownerid) field on the Case (incident) entity, which links to the System User (systemuser) entity.
Examples
Alice SmithBob JohnsonSystem
|
|||
|
Channel
Channel
|
The communication channel through which the service request was initiated. | ||
|
Description
This attribute identifies the origin of the customer interaction, such as Phone, Email, Web Portal, or Chat. Different channels often have distinct process flows, customer expectations, and resolution complexities. Analyzing the process by channel helps optimize channel-specific workflows and resource allocation.
Why it matters
Provides insights into how different customer contact channels impact process efficiency, resolution time, and customer satisfaction.
Where to get
This corresponds to the 'Case Origin' (caseorigincode) field on the Case (incident) entity.
Examples
PhoneEmailWebChat
|
|||
|
Customer Name
CustomerName
|
The name of the customer or account associated with the service request. | ||
|
Description
This attribute identifies the customer who initiated the service request. It allows for analysis of the process from a customer-centric view, helping to identify which customers submit the most requests, experience the longest resolution times, or have the most complex issues. This is essential for managing customer relationships and improving customer-specific service delivery.
Why it matters
Enables customer-level analysis to identify patterns, improve service for key accounts, and understand the customer journey.
Where to get
This is the 'Customer' (customerid) lookup field on the Case (incident) entity, which can point to either an Account or Contact record.
Examples
Global Tech Inc.Jane DoeInnovate Solutions
|
|||
|
Priority
Priority
|
The priority level assigned to the service request, indicating its urgency. | ||
|
Description
This attribute defines the urgency of a service request, typically categorized as Low, Normal, High, or Urgent. Priority is used to determine the order in which cases are addressed and often dictates SLA targets. Analyzing how priority impacts process flow, resource allocation, and resolution times is key to ensuring that critical issues are handled promptly.
Why it matters
Helps in understanding if high-priority requests are processed faster and meet their targets, and how priority levels affect overall process performance.
Where to get
This corresponds to the 'Priority' (prioritycode) field on the Case (incident) entity.
Examples
LowNormalHigh
|
|||
|
Service Request Type
ServiceRequestType
|
The primary category or classification of the service request. | ||
|
Description
This attribute categorizes the service request based on its nature, such as 'Billing Inquiry', 'Technical Support', or 'Product Feedback'. It is fundamental for segmenting the process analysis to understand how different types of requests are handled. Analyzing by type can reveal that certain categories have longer resolution times, higher escalation rates, or follow different process paths.
Why it matters
Allows for process segmentation to uncover type-specific bottlenecks, resource needs, and improvement opportunities, supporting better routing and handling strategies.
Where to get
This information is often stored in the 'Subject' (subjectid) field or a custom category field on the Case (incident) entity.
Examples
Billing InquiryTechnical SupportProduct FeedbackAccount Management
|
|||
|
SLA Target Resolution Time
SlaTargetResolutionTime
|
The contractually agreed upon target time for resolving the service request. | ||
|
Description
This attribute specifies the target duration within which a service request should be resolved according to the active Service Level Agreement (SLA). It serves as the benchmark against which actual performance is measured. This value is critical for the SLA Compliance Monitoring dashboard and for calculating the SLA Compliance Rate KPI, highlighting where the process is failing to meet service commitments.
Why it matters
This is the primary benchmark for measuring service performance against commitments, directly enabling the analysis of SLA compliance and breaches.
Where to get
This value is determined by the SLA configuration in Dynamics 365 and is associated with a case through SLA KPI Instances.
Examples
2592008640014400
|
|||
|
Status Reason
StatusReason
|
Provides a more detailed reason for the current status of the service request. | ||
|
Description
While a case has a broad status like 'Active' or 'Resolved', the Status Reason provides more specific context, such as 'Information Provided' or 'Problem Solved'. This attribute is crucial for understanding the nuances of how and why cases progress through their lifecycle. For example, it can differentiate between cases resolved successfully versus those canceled by the customer, which is vital for accurate outcome analysis.
Why it matters
Offers granular insight into the outcome of a case and the reasons for its status changes, enabling more precise analysis of resolution pathways and root causes.
Where to get
This corresponds to the 'Status Reason' (statuscode) field on the Case (incident) entity.
Examples
In ProgressOn HoldProblem SolvedInformation Provided
|
|||
|
CSAT Score
CustomerSatisfactionScore
|
The satisfaction score provided by the customer after case resolution. | ||
|
Description
This attribute holds the numeric or categorical rating from a customer satisfaction (CSAT) survey, typically collected after a service request is closed. It is a direct measure of the customer's perception of the service quality. This data is essential for the Customer Satisfaction Trends dashboard and the Average Post-Resolution CSAT Score KPI, linking process performance to customer outcomes.
Why it matters
Provides a direct measure of customer satisfaction, allowing the organization to correlate process behaviors with customer sentiment and drive improvements.
Where to get
This is typically sourced from a related survey entity, like Customer Voice, and linked back to the Case (incident) entity.
Examples
5341
|
|||
|
Is Escalated
IsEscalated
|
A flag indicating whether the service request has been escalated. | ||
|
Description
This boolean attribute indicates if a service request has undergone an escalation. Escalations occur when first-level support is unable to resolve an issue, requiring intervention from a more senior team or specialist. Tracking this flag is essential for the Internal Escalation Pathways dashboard and the Internal Escalation Rate KPI, helping to identify the root causes of escalations and weaknesses in the initial support tiers.
Why it matters
Directly measures the frequency of escalations, highlighting issues with first-contact resolution and pointing to areas needing process or agent skill improvements.
Where to get
This corresponds to the 'Is Escalated' (isescalated) field on the Case (incident) entity.
Examples
truefalse
|
|||
|
Is First Contact Resolution
IsFirstContactResolution
|
A flag indicating if the request was resolved during the first contact. | ||
|
Description
This calculated attribute identifies service requests that were resolved without any follow-up interactions from the customer or significant delays requiring agent reassignment. Defining the exact logic can be complex, but it typically involves checking for a short cycle time and the absence of re-opening or customer inquiry activities after the initial interaction. It is the basis for the First Contact Resolution Rate KPI.
Why it matters
This is a critical measure of service efficiency and customer satisfaction, as it highlights the ability to resolve issues quickly and completely.
Where to get
Calculated based on the sequence and timing of activities in the event log for each case.
Examples
truefalse
|
|||
|
Is Rework
IsRework
|
A calculated flag indicating if a case involved rework activities. | ||
|
Description
This boolean flag identifies cases that contain rework loops or repeated activities, such as multiple 'Information Requested From Customer' events or a 'Case Reactivated' event after being resolved. It is calculated by analyzing the sequence of activities for patterns that indicate inefficiency or a failure to resolve the issue correctly the first time. This attribute is key for the Rework and Repeat Contact Analysis dashboard.
Why it matters
Helps to quantify and isolate process inefficiencies, allowing analysts to focus on the root causes of repeated work and wasted effort.
Where to get
Calculated by detecting specific activity sequences (e.g., Resolved -> Reactivated) or repeated activities within a case using process mining analytics.
Examples
truefalse
|
|||
|
Is SLA Breached
IsSlaBreached
|
A calculated flag indicating if the service request exceeded its SLA target. | ||
|
Description
This boolean flag is determined by comparing the actual resolution time of a service request against its 'SLA Target Resolution Time'. It is set to true if the actual time is greater than the target time. This attribute is fundamental for the SLA Compliance Monitoring dashboard and for calculating the SLA Compliance Rate KPI, providing a clear, binary outcome for each case's SLA performance.
Why it matters
Provides a clear success or failure outcome for SLA adherence on every case, making it easy to filter, aggregate, and analyze the root causes of breaches.
Where to get
Calculated by comparing 'ServiceRequestCycleTime' with 'SlaTargetResolutionTime'.
Examples
truefalse
|
|||
|
Knowledge Article ID
KnowledgeArticleId
|
The identifier of a knowledge base article linked to the service request. | ||
|
Description
This attribute captures the ID of any knowledge article that was used or linked during the resolution of a service request. It provides a direct measure of how effectively the knowledge base is being utilized by agents to solve customer issues. This data is key for the Knowledge Article Utilization dashboard and the corresponding KPI, helping to assess the value and completeness of the knowledge base.
Why it matters
Tracks knowledge base usage, helping to understand if agents are leveraging available resources to resolve issues faster and more consistently.
Where to get
This information is found in the relationship between the Case (incident) and Knowledge Article (knowledgearticle) entities.
Examples
KA-01337KA-02048
|
|||
|
Owner Team
OwnerTeam
|
The team that currently owns the service request. | ||
|
Description
This attribute identifies the team responsible for the service request. A request can be owned by an individual agent or a team (queue). Analyzing by team is crucial for understanding team-level performance, workload distribution across different support tiers or specialties, and identifying process variations between teams.
Why it matters
Allows for performance analysis at the team level, which is essential for managing support tiers and specialized groups effectively.
Where to get
Derived from the 'Owner' (ownerid) field on the Case (incident) entity when the owner is a Team record rather than a System User.
Examples
Tier 1 SupportBilling DepartmentTechnical Specialists
|
|||
|
Product Involved
ProductInvolved
|
The product associated with the customer's service request. | ||
|
Description
This attribute identifies the specific product or service that the customer's issue pertains to. It allows for product-based segmentation of the service process, which can reveal if certain products generate more support requests, have more complex issues, or require specialized agent skills. This analysis helps in product improvement and resource planning.
Why it matters
Enables product-specific process analysis to identify recurring product issues, improve support documentation, and allocate expert resources effectively.
Where to get
This corresponds to the 'Product' (productid) lookup field on the Case (incident) entity.
Examples
Alpha-100 PrinterZeta CRM SoftwareOmega Data Plan
|
|||
|
Service Request Cycle Time
ServiceRequestCycleTime
|
The total time elapsed from the creation to the resolution of a service request. | ||
|
Description
This calculated metric measures the end-to-end duration for each service request. It is calculated as the time difference between the 'Case Created' activity and the 'Case Resolved' activity. This is a primary KPI for evaluating overall process efficiency and is central to the Service Request Resolution Times dashboard. It helps pinpoint cases that take exceptionally long and identifies systemic delays.
Why it matters
This is a core process performance metric that directly measures the efficiency of the end-to-end resolution process and helps identify long-running cases.
Where to get
Calculated by subtracting the timestamp of the first event from the timestamp of the last resolution event for each Case ID.
Examples
1728006048003600
|
|||
Customer Service Activities
| Activity | Description | ||
|---|---|---|---|
|
Case Assigned
|
This activity represents the assignment of a case to a specific queue or user for handling. The system explicitly records changes to the case owner, which can be tracked through the system's audit logs. | ||
|
Why it matters
Tracking assignments is crucial for analyzing workload distribution, identifying assignment-related delays, and understanding routing efficiency. It helps answer questions about how quickly cases are routed to the right team or person.
Where to get
Captured by tracking changes to the 'ownerid' field on the 'Incident' entity. The timestamp of the change is available in the audit history logs.
Capture
Extract timestamped changes to the 'ownerid' field from the audit logs.
Event type
explicit
|
|||
|
Case Closed
|
This is the final administrative closure of the case record, which may occur at the same time as resolution or sometime after. This activity is captured by a change in the case's state to 'Closed'. | ||
|
Why it matters
This represents the absolute end of the process lifecycle in the system. The time between 'Resolved' and 'Closed' can indicate administrative overhead or delays in finalizing records.
Where to get
Captured by a change in the 'statecode' field on the 'Incident' entity to 'Canceled' (2) or a custom closed state. The timestamp is available in the audit history.
Capture
Track the timestamp of the 'statecode' changing to its final terminal state (e.g., Canceled/Closed).
Event type
explicit
|
|||
|
Case Created
|
This activity marks the beginning of the customer service process, when a new case record is created in the system. The creation is an explicit event, logged with a specific timestamp when the 'Incident' entity record is first saved. | ||
|
Why it matters
As the primary start event, this activity is essential for calculating the overall case lifecycle duration and understanding case volume trends. It serves as the anchor for all subsequent process analysis.
Where to get
This event is captured from the 'createdon' timestamp on the 'Incident' (Case) entity for each new record.
Capture
Use the 'createdon' timestamp of the Incident record.
Event type
explicit
|
|||
|
Case Escalated
|
Represents the formal escalation of a case to a higher tier of support or a different team. This can be an explicit user action that reassigns the case to a designated escalation queue or user. | ||
|
Why it matters
Monitoring escalations is vital for the 'Internal Escalation Rate' KPI and identifying root causes of issues that first-line support cannot resolve. It highlights process weaknesses and training opportunities.
Where to get
Inferred from a change in the 'ownerid' field to a designated escalation queue or team. It can also be an explicit custom action that flags the case as escalated.
Capture
Identify a timestamped change of the 'ownerid' to a known escalation queue.
Event type
inferred
|
|||
|
Case Resolved
|
This is a key milestone representing the point at which the agent considers the customer's issue addressed. This is an explicit action in Dynamics 365, creating a 'Case Resolution' activity record linked to the case. | ||
|
Why it matters
As the primary success-based end event, this activity is essential for calculating resolution times and success rates. It is a critical component of nearly every customer service KPI.
Where to get
This event corresponds to the creation of a 'Resolution' (Case Resolution) activity record. The 'actualend' timestamp on this record marks the resolution time.
Capture
Use the 'actualend' or 'createdon' timestamp from the associated 'Resolution' activity record.
Event type
explicit
|
|||
|
SLA Timer Started
|
Indicates the activation of a Service Level Agreement (SLA) timer for the case, which starts tracking time against a defined service metric like 'First Response By' or 'Resolve By'. This is an explicit event managed by the Dynamics 365 SLA engine. | ||
|
Why it matters
This activity is fundamental for monitoring SLA compliance and understanding when the clock starts for service commitments. It directly supports analysis of whether service targets are being met.
Where to get
Logged in the 'SLA KPI Instance' entity, which is related to the 'Incident' entity. The 'createdon' timestamp of the relevant SLA KPI Instance record marks the start.
Capture
Use the creation timestamp of the 'SLA KPI Instance' record associated with the case.
Event type
explicit
|
|||
|
Agent Investigated Issue
|
Represents the agent actively working to understand and diagnose the customer's issue. This is an inferred activity, often identified by the agent linking a Knowledge Article to the case, indicating research has occurred. | ||
|
Why it matters
Tracking this helps measure the utilization of knowledge resources and its impact on resolution times. It provides insight into whether agents are leveraging available tools to solve issues efficiently.
Where to get
Inferred from the creation of a record in the 'IncidentKnowledgeBaseRecord' entity, which links a Knowledge Article to a Case. The timestamp of this record creation is used.
Capture
Use the timestamp when a Knowledge Article is associated with the Incident.
Event type
inferred
|
|||
|
Case Categorization Changed
|
This event occurs when an agent modifies the category or subject of a case after its initial creation. This is an explicit change tracked by the system's audit functionality. | ||
|
Why it matters
Tracking recategorization is essential for the 'Service Request Recategorization Rate' KPI. A high frequency indicates issues with initial triage, leading to incorrect routing and delays.
Where to get
Captured from the audit history for the 'Incident' entity, specifically by tracking changes to the 'subjectid' field or other custom categorization fields.
Capture
Extract timestamped changes to the 'subjectid' field from the audit logs.
Event type
explicit
|
|||
|
Case Reactivated
|
Occurs when a previously resolved case is automatically or manually reopened, usually because the customer replied or reported the issue was not fixed. This is a standard system behavior that changes the case status from 'Resolved' back to 'Active'. | ||
|
Why it matters
This activity is crucial for identifying rework and analyzing the 'First Contact Resolution Rate'. A high number of reactivations points to incomplete or ineffective initial solutions.
Where to get
Captured by a change in the 'statecode' field on the 'Incident' entity from 'Resolved' (1) back to 'Active' (0). The timestamp of this change is recorded in the audit history.
Capture
Track timestamp of 'statecode' change from Resolved to Active in audit logs.
Event type
explicit
|
|||
|
Information Requested From Customer
|
This activity marks a point where the agent requires more information from the customer to proceed. It is often inferred by the case status being changed to a 'waiting' state or by an outbound email being sent from the case timeline. | ||
|
Why it matters
This is critical for measuring customer-related delays and understanding the 'Customer Information Wait Time' KPI. It helps isolate process time spent waiting for external input.
Where to get
Can be inferred from a change in the 'statuscode' field on the 'Incident' entity to a value like 'On Hold' with a reason of 'Waiting for Customer'. The timestamp of this status change is used.
Capture
Track the timestamp of a statuscode change to a designated 'waiting for customer' state.
Event type
inferred
|
|||
|
Queue Item Picked By Agent
|
This event occurs when an agent actively takes a case from a shared queue to begin working on it. This is a deliberate action by the user, distinct from the system assigning the case to the queue. | ||
|
Why it matters
This activity helps measure the actual time a case waits in a queue before an agent begins work. It's key to identifying queue bottlenecks and understanding agent proactiveness.
Where to get
Tracked when a user updates the 'workedbyid' field on the 'QueueItem' entity associated with the case, or when the case owner changes from a queue to a user.
Capture
Identify the timestamp when the 'workedbyid' field on the QueueItem is populated.
Event type
explicit
|
|||
|
Satisfaction Survey Sent
|
Marks the sending of a customer satisfaction survey, typically triggered automatically after a case is resolved. This is usually captured as an outbound email or a Customer Voice survey activity. | ||
|
Why it matters
This activity links the operational process to customer experience outcomes. It enables analysis of satisfaction scores in the context of the process path that a case followed.
Where to get
Inferred from the creation of an outbound 'Email' activity with a survey link, or from a 'Customer Voice survey invite' activity record related to the case.
Capture
Use the creation timestamp of the survey-related activity record.
Event type
inferred
|
|||
|
Solution Proposed To Customer
|
This activity signifies that the agent has formulated a solution and communicated it to the customer. It is typically inferred from an outbound email sent from the case timeline or a status change to 'Pending Customer Confirmation'. | ||
|
Why it matters
This milestone marks the transition from investigation to resolution. Analyzing the time between proposing and confirming a solution can reveal delays in customer response or issues with the proposed fixes.
Where to get
Can be inferred from the timestamp of an outbound 'Email' activity record related to the case or a statuscode change to a pre-resolution state.
Capture
Use timestamp of an outbound email activity or a status change to 'Solution Proposed'.
Event type
inferred
|
|||