Your Customer Service Data Template
Your Customer Service Data Template
- Recommended attributes to collect
- Key activities to track
- Extraction guidance
Customer Service Attributes
| Name | Description | ||
|---|---|---|---|
|
Event Time
EventTime
|
The precise timestamp indicating when a specific activity or event occurred. | ||
|
Description
Event Time records the date and time that an activity was performed. This timestamp is fundamental for ordering events chronologically and for calculating durations between different steps in the process. In process mining analysis, this attribute is used to calculate all time-based metrics, including cycle times, waiting times, and processing durations. It allows analysts to identify bottlenecks by finding activities with long delays preceding them and to measure performance against service level agreements (SLAs). Accurate and consistent timestamps are essential for a reliable analysis.
Why it matters
This timestamp is critical for sequencing events correctly and calculating all performance metrics, such as cycle times and bottlenecks.
Where to get
This typically corresponds to the 'sys_created_on' field in ServiceNow's audit and history tables (e.g., 'sys_audit').
Examples
2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:05:11Z
|
|||
|
Service Request
ServiceRequest
|
The unique identifier for each customer service request, case, or ticket. | ||
|
Description
The Service Request is the primary case identifier that links all related activities and events for a single customer issue, from creation to closure. It acts as the central thread for tracking the end-to-end journey of a customer interaction. In process mining, this attribute is fundamental for reconstructing the process flow. Each unique Service Request value represents one instance of the process, allowing for the analysis of cycle times, paths, and variations on a case-by-case basis. It ensures that all steps, from initial contact to final resolution and closure, are correctly associated with the same customer inquiry.
Why it matters
This is the essential Case ID that connects all process steps, making it possible to analyze the complete lifecycle of each customer service interaction.
Where to get
This is typically the 'number' field from the 'sn_customerservice_case' table in ServiceNow CSM.
Examples
CS0010001CS0010045CS0010112
|
|||
|
Activity Name
ActivityName
|
The name of a specific event or task that occurred within the service request lifecycle. | ||
|
Description
The Activity Name describes a step in the customer service process, such as 'Service Request Created', 'Request Assigned to Agent', or 'Solution Proposed'. These activities are extracted from system logs or table updates to build a chronological sequence of events for each service request. This attribute is crucial for visualizing the process map, identifying bottlenecks, and understanding the flow of work. By analyzing the sequence and frequency of activities, analysts can discover common process paths, deviations, and areas of rework or inefficiency. The granularity of activities defined directly impacts the depth of insights that can be gained from the process model.
Why it matters
This attribute forms the backbone of the process map, defining the specific steps and tasks whose sequence and duration are analyzed.
Where to get
This is a conceptual attribute derived from system audit tables (e.g., 'sys_audit') or by tracking state changes and key field updates in the 'sn_customerservice_case' table.
Examples
Service Request CreatedRequest Assigned to AgentInformation Requested from CustomerService Request Resolved
|
|||
|
Assigned Agent
AssignedAgent
|
The individual service agent currently assigned to handle the service request. | ||
|
Description
This attribute identifies the user responsible for the service request at a given point in time. It often changes throughout the case lifecycle as the request is handed off between different agents or specialists. Analyzing the Assigned Agent is key to understanding workload distribution, agent performance, and handoffs. It helps answer questions like which agents handle the most complex cases, how often cases are reassigned, and whether certain agents are associated with longer resolution times or higher customer satisfaction. This is crucial for the 'Agent Handoffs and Reassignments' dashboard.
Why it matters
Tracks agent responsibility, enabling analysis of workload, performance, and the frequency of reassignments, which often indicates process friction.
Where to get
This corresponds to the 'assigned_to' field on the 'sn_customerservice_case' table.
Examples
Beth AnglinDavid LooAbel Tuter
|
|||
|
Assignment Group
AssignmentGroup
|
The team or department responsible for the service request. | ||
|
Description
The Assignment Group represents the queue or team that a service request is assigned to. Requests are often routed between different groups, such as a Level 1 support desk, a specialized technical team, or a billing department, depending on the nature of the issue. This attribute is essential for analyzing inter-departmental handoffs and identifying bottlenecks at the team level. It helps visualize how work flows between different functional areas and can highlight groups that are overloaded or require additional training. This directly supports the 'Agent Handoffs and Reassignments' and 'Process Flow' dashboards.
Why it matters
Identifies which team is responsible for the work, which is critical for analyzing team performance, workloads, and process handoffs between departments.
Where to get
This corresponds to the 'assignment_group' field on the 'sn_customerservice_case' table.
Examples
Service DeskBilling InquiriesTechnical Support Tier 2
|
|||
|
Category
Category
|
The primary classification of the service request, such as 'Billing' or 'Technical Issue'. | ||
|
Description
The Category provides a high-level grouping for service requests based on the nature of the customer's inquiry or problem. This classification is typically done when the request is first created and helps in routing it to the correct assignment group. This attribute is essential for segmenting the process analysis. By filtering on Category, analysts can compare the process flows for different types of requests. For example, the resolution process for a 'Billing' issue might be very different from that of a 'Technical Issue'. This is a key attribute for nearly all dashboards to slice the data.
Why it matters
Allows for breaking down the analysis by request type, revealing if certain categories are more prone to delays, escalations, or SLA breaches.
Where to get
This corresponds to the 'category' field on the 'sn_customerservice_case' table.
Examples
Inquiry / HelpOrdersProduct IssuesBilling
|
|||
|
Is SLA Breached
IsSlaBreached
|
A boolean flag indicating whether the service request exceeded its defined Service Level Agreement (SLA) target. | ||
|
Description
This calculated attribute indicates if a service request was resolved within the agreed-upon time frame. It is typically 'True' if the resolution time surpassed the SLA target and 'False' otherwise. This provides a clear, binary outcome for SLA performance on each case. This attribute is essential for the 'SLA Adherence and Violation Trends' dashboard and the 'SLA Adherence Rate' KPI. It simplifies analysis by allowing direct filtering and counting of breached cases, making it easy to identify which types of requests, priorities, or teams are most associated with SLA violations.
Why it matters
Provides a clear yes or no answer to whether a case met its deadline, which is fundamental for measuring and reporting on SLA compliance.
Where to get
Calculated based on the 'made_sla' field from the 'task_sla' table, or derived by comparing the actual resolution time to the planned resolution time.
Examples
truefalse
|
|||
|
Priority
Priority
|
The priority level of the service request, which influences its urgency. | ||
|
Description
Priority indicates the importance and required urgency for addressing a service request. It is often determined by a combination of the request's impact on the customer and its urgency. Common values range from Critical to Low. In process mining, Priority is a powerful dimension for filtering and comparison. It allows analysts to check if high-priority requests are actually being processed faster than low-priority ones, and to see if SLA breaches are more common for certain priority levels. This is fundamental for the 'Service Request End-to-End Cycle Time' dashboard.
Why it matters
This allows for segmenting service requests by urgency, which is essential for verifying that critical issues are handled faster than non-critical ones.
Where to get
This corresponds to the 'priority' field on the 'sn_customerservice_case' table.
Examples
1 - Critical2 - High3 - Moderate4 - Low
|
|||
|
State
State
|
The current status or state of the service request in its lifecycle. | ||
|
Description
The State attribute describes the operational status of a service request at any point in time, such as 'New', 'In Progress', 'Awaiting Info', 'Resolved', or 'Closed'. Changes in this field are often used to define the activities in the process model. Analyzing the State provides a high-level view of where cases are in the process. It is used to identify how long cases spend in certain states, such as 'Awaiting Info', which can be a significant source of delay. It also helps define the start and end points for key KPIs like 'Resolution to Closure Time'.
Why it matters
Indicates the status of a request at any time, helping to identify time spent in non-productive states like 'On Hold' or 'Awaiting Information'.
Where to get
This corresponds to the 'state' field on the 'sn_customerservice_case' table.
Examples
NewIn ProgressAwaiting User InfoResolvedClosed
|
|||
|
Channel
Channel
|
The communication channel through which the service request was initiated. | ||
|
Description
The Channel indicates the method used by the customer to submit their request, for example, 'Email', 'Phone', 'Web Portal', or 'Chat'. Different channels can have significantly different process characteristics and customer expectations. Analyzing the process by Channel helps to evaluate the effectiveness of each communication method. For instance, it can reveal if requests submitted via 'Phone' have a higher first contact resolution rate or if 'Email' requests tend to have longer cycle times. This directly supports the 'Communication Channel Effectiveness' dashboard.
Why it matters
Helps determine the efficiency and outcomes of different customer interaction channels, such as phone, email, or web portal.
Where to get
This typically corresponds to the 'contact_type' field on the 'sn_customerservice_case' table.
Examples
PhoneEmailSelf-serviceChat
|
|||
|
Customer
Customer
|
The name or identifier of the customer or company who initiated the service request. | ||
|
Description
This attribute identifies the external stakeholder, either an individual or an organization, that the service request is for. It provides the customer context for each case. In analysis, the Customer attribute allows for a customer-centric view of the service process. It can be used to identify if certain customers experience more issues or longer delays, and can be joined with other customer data, like segment or value, to prioritize process improvement efforts. For instance, one could check if high-value customers receive faster service.
Why it matters
Links the process to specific customers, enabling analysis of service levels and issue frequency for key accounts or customer segments.
Where to get
This could be the 'caller_id', 'opened_for', or 'account' field on the 'sn_customerservice_case' table, which reference user or company tables.
Examples
John SmithACME CorporationGlobal Tech Inc.
|
|||
|
Is First Contact Resolution
IsFirstContactResolution
|
A boolean flag indicating if the request was resolved by the first assigned agent without any transfers or escalations. | ||
|
Description
This calculated attribute identifies service requests that were resolved efficiently during the first interaction or by the first agent who handled the case. The logic typically checks for conditions like zero reassignments ('ReassignmentCount' is 0), no 'Internal Escalation Triggered' activities, and no requests for more information from the customer. This attribute directly measures a critical customer service metric and supports the 'First Contact Resolution Rate' dashboard and KPI. It allows for easy quantification of FCR performance and helps in analyzing the factors, such as channel or request category, that contribute to or hinder achieving first contact resolution.
Why it matters
Directly measures the efficiency of the initial response. A high FCR rate is strongly linked to both operational efficiency and high customer satisfaction.
Where to get
This is a calculated attribute. It is derived during data transformation based on rules, such as 'ReassignmentCount' being zero and no escalation activities occurring.
Examples
truefalse
|
|||
|
Is Rework
IsRework
|
A boolean flag that indicates if significant rework has occurred, such as a reopened case or repeated investigation. | ||
|
Description
This is a calculated attribute that flags cases exhibiting patterns of inefficiency or repetition. The logic for this flag might be triggered by events like 'Service Request Reopened' or if a key sequence of activities, like 'Agent Starts Investigation' followed by 'Solution Proposed', occurs multiple times within the same case. This flag is invaluable for quickly identifying problematic cases and quantifying the overall level of rework in the process. It directly supports the 'Rework and Repetition Hotspots' dashboard and the 'Rework Rate' KPI, allowing analysts to focus on the drivers of inefficiency without needing to manually identify repetitive patterns.
Why it matters
Helps quantify process inefficiency by flagging cases with repetitive loops or reopen events, making it easy to measure and target rework.
Where to get
This is a calculated attribute. It is derived during data transformation by applying business logic that detects patterns of rework, such as a non-zero 'ReopenCount' or repeated activities.
Examples
truefalse
|
|||
|
Last Data Update
LastDataUpdate
|
The timestamp indicating when the data was last extracted or refreshed from the source system. | ||
|
Description
This attribute records the date and time of the most recent data pull. It provides context on the freshness of the data being analyzed, ensuring that users are aware of whether they are looking at near real-time information or a historical snapshot. During analysis, this is a critical piece of metadata for understanding the time window of the dataset. It helps users interpret dashboards and KPIs correctly, knowing, for example, that the data is current as of the last hour or the previous day.
Why it matters
Indicates the freshness of the data, which is crucial for the relevance and timeliness of the process mining insights.
Where to get
This timestamp is generated and added during the data extraction, transformation, and loading (ETL) process.
Examples
2023-11-20T08:00:00Z
|
|||
|
Processing Time
ProcessingTime
|
The duration of time spent actively working on an activity. | ||
|
Description
Processing Time, also known as active time or service time, measures the duration of an activity from its start to its end. It represents the time an agent or system spends actively performing a task, as opposed to waiting time between tasks. In process mining, this metric is critical for distinguishing between value-added time and non-value-added waiting time. Analyzing processing time helps identify which specific tasks are the most time-consuming and where there are opportunities for automation or training to improve efficiency. It's a foundational metric for bottleneck analysis.
Why it matters
Measures the active work time for an activity, helping to distinguish value-added time from wasteful waiting time in the process.
Where to get
This is a calculated attribute, typically derived as the difference between an activity's EndTime and its StartTime.
Examples
PT15MPT2H30MP1D
|
|||
|
Reassignment Count
ReassignmentCount
|
The total number of times the service request has been reassigned to a different agent or group. | ||
|
Description
This attribute is a counter that increments each time the 'assigned_to' or 'assignment_group' field changes. It provides a simple metric for the amount of internal transfer a case has undergone. Reassignment Count is a direct measure of process friction and is a key input for the 'Agent Handoffs and Reassignments' dashboard and the 'Average Agent Handoffs per Request' KPI. High reassignment counts often indicate issues with initial routing, agent skill gaps, or cases that are difficult to categorize, all of which lead to longer resolution times.
Why it matters
Directly measures process inefficiency by counting handoffs. A high count often correlates with longer resolution times and customer dissatisfaction.
Where to get
This is a standard metric field, 'reassignment_count', on the 'task' table, which 'sn_customerservice_case' extends.
Examples
0135
|
|||
|
Reopen Count
ReopenCount
|
The number of times a resolved service request has been reopened by the customer. | ||
|
Description
This counter tracks how many times a case has transitioned from a 'Resolved' or 'Closed' state back to an 'In Progress' or 'Open' state. A reopened case suggests that the initial solution was not effective or complete. This attribute is a strong indicator of rework and first-time resolution quality. A high reopen count points to problems in the resolution process, such as agents closing tickets prematurely or not fully addressing the customer's underlying issue. It is a key metric for understanding the effectiveness of proposed solutions.
Why it matters
Indicates failed resolutions and rework. A high number of reopens signals poor quality in the resolution process and leads to customer frustration.
Where to get
This is often tracked in a field named 'reopen_count' on the 'sn_customerservice_case' table or a related table.
Examples
012
|
|||
|
Resolution Code
ResolutionCode
|
A code indicating the final outcome or how the service request was resolved. | ||
|
Description
The Resolution Code is a structured value selected by the agent upon resolving a case. It provides specific details about the solution, such as 'Solved by User', 'Known Error', 'Duplicate', or 'No Action Needed'. This attribute is valuable for root cause analysis. By analyzing the frequency of different resolution codes, organizations can identify recurring problems, knowledge gaps, or product issues. This information can then be used to drive improvements that reduce the volume of certain types of service requests.
Why it matters
Provides insight into the outcomes of service requests, which is crucial for root cause analysis and identifying recurring problems.
Where to get
This corresponds to the 'close_code' or a custom resolution code field on the 'sn_customerservice_case' table.
Examples
Solved (Workaround)Solved (Permanently)Not Solved (Customer Unresponsive)Closed/Resolved by Caller
|
|||
|
Source System
SourceSystem
|
The system from which the data was extracted. | ||
|
Description
This attribute identifies the origin of the data, which is especially important in environments where information is aggregated from multiple systems. For this process view, the value would consistently be 'ServiceNow CSM'. In analysis, this helps in data governance and troubleshooting. When multiple source systems are involved, it allows for filtering the process to understand how it operates within a specific system or to compare process variations across different systems.
Why it matters
Provides essential context about the data's origin, ensuring clarity in multi-system environments and aiding in data governance.
Where to get
This is a static value added during the data transformation process to label the dataset's origin.
Examples
ServiceNow CSM
|
|||
Customer Service Activities
| Activity | Description | ||
|---|---|---|---|
|
Internal Escalation Triggered
|
Represents the formal escalation of a service request to a higher level of support or management for resolution. This can be inferred from a change in the assignment group to a higher-tier team or a flag being set. | ||
|
Why it matters
Tracking escalations helps identify process weaknesses, knowledge gaps in front-line support, and complex case types. This is a key indicator of process friction and customer dissatisfaction.
Where to get
Can be inferred from the audit log by detecting a change in the 'assignment_group' to a known escalation team, or a change in the 'escalation' field on the case record.
Capture
Detect change in the 'escalation' field or a move to a higher-tier 'assignment_group'.
Event type
inferred
|
|||
|
Request Assigned to Agent
|
This activity occurs when a service request is assigned to a specific agent for investigation and resolution. It is captured by inferring the change in the assigned_to field on the case record. | ||
|
Why it matters
This is a critical milestone for measuring initial response times and agent workload distribution. Tracking reassignments of this field highlights process inefficiencies and potential bottlenecks in agent availability.
Where to get
Inferred from the audit history (sys_audit) for the sn_customerservice_case table by tracking when the assigned_to field is populated or changed.
Capture
Detect value change for the 'assigned_to' field in the case's audit log.
Event type
inferred
|
|||
|
Service Request Closed
|
This is the final activity, marking the formal closure of the service request record, often after a confirmation period post-resolution. It is captured when the case state changes to 'Closed' and the closed_at timestamp is set. | ||
|
Why it matters
As the definitive end of the process, this activity is essential for calculating the full case lifecycle. Analyzing the time between 'Resolved' and 'Closed' reveals administrative overhead or delays.
Where to get
Inferred from the audit history when the state field on the sn_customerservice_case table is set to 'Closed'. The closed_at field is populated at the same time.
Capture
Detect 'state' change to 'Closed' and use the corresponding timestamp.
Event type
inferred
|
|||
|
Service Request Created
|
This activity marks the beginning of the customer service process, when a new case is formally logged in the system. This event is captured explicitly when a new record is inserted into the sn_customerservice_case table. | ||
|
Why it matters
As the starting point for every case, this activity is essential for calculating the end-to-end cycle time and analyzing request intake volumes. It serves as the trigger for all downstream processes and SLA timers.
Where to get
This event corresponds to the creation of a record in the sn_customerservice_case table. The timestamp is taken from the sys_created_on field.
Capture
Record creation timestamp (sys_created_on) in sn_customerservice_case table.
Event type
explicit
|
|||
|
Service Request Resolved
|
This is a key milestone indicating that the service agent has completed the work and the issue is considered solved. This is captured when the case state is changed to 'Resolved' and the resolved_at timestamp is populated. | ||
|
Why it matters
This activity marks the end of the active resolution process and is crucial for calculating resolution cycle times and SLA adherence. It serves as a primary endpoint for many efficiency KPIs.
Where to get
Inferred from the audit history when the state field on the sn_customerservice_case table is set to 'Resolved'. The resolved_at field is typically populated at the same time.
Capture
Detect 'state' change to 'Resolved' and use the corresponding timestamp.
Event type
inferred
|
|||
|
Agent Starts Investigation
|
This activity signifies that an agent has actively started working on the service request. It is typically inferred when the case state changes from a status like 'New' or 'Assigned' to 'Work in Progress'. | ||
|
Why it matters
This event helps distinguish queue time from active work time. Analyzing the duration between assignment and the start of investigation reveals delays in agents picking up new cases.
Where to get
Inferred from the case's state field changing to an active work state, such as 'Work in Progress'. The specific state values can be configured and should be verified.
Capture
Detect change in 'state' field from a pending to an active value (e.g., 'New' to 'Work in Progress').
Event type
inferred
|
|||
|
Assignment Group Changed
|
Indicates that the responsibility for a case has been transferred from one team to another. This event is inferred by monitoring changes to the assignment_group field within the case record. | ||
|
Why it matters
Tracking changes in assignment groups is crucial for analyzing inter-departmental handoffs and identifying systematic routing issues. High frequency of this activity can indicate unclear ownership or process definitions.
Where to get
Inferred from the audit history (sys_audit) for the sn_customerservice_case table by tracking when the assignment_group field changes.
Capture
Detect value change for the 'assignment_group' field in the case's audit log.
Event type
inferred
|
|||
|
Customer Survey Sent
|
Represents the sending of a customer satisfaction survey following the resolution of a case. This event is typically captured when a survey instance record is created and associated with the case. | ||
|
Why it matters
This activity helps correlate process execution patterns with customer feedback. Understanding when and if surveys are sent is important for analyzing the effectiveness of the feedback loop.
Where to get
This is an explicit event logged in a survey-specific table like asmt_assessment_instance, which contains a reference to the source case record.
Capture
Record creation in the 'asmt_assessment_instance' table linked to the case.
Event type
explicit
|
|||
|
Information Received from Customer
|
This activity marks the point when the customer provides the requested information, allowing the agent to resume work. It is inferred when the case state moves from 'Awaiting User Info' back to an active state. | ||
|
Why it matters
This event concludes the customer waiting period, enabling precise measurement of customer response times. It helps identify which case types or customers are associated with the longest delays.
Where to get
Inferred from the audit history of the sn_customerservice_case table when the state field changes from an 'Awaiting Info' status back to an active one like 'Work in Progress'.
Capture
Detect change in 'state' field from an 'awaiting customer' value back to an active value.
Event type
inferred
|
|||
|
Information Requested from Customer
|
Occurs when an agent requires additional information from the customer to proceed and places the case in a pending state. This is inferred from a state change to a value like 'Awaiting User Info' or 'On Hold'. | ||
|
Why it matters
This activity is crucial for the 'Customer Information Waiting Times' analysis. It isolates process delays caused by external dependencies, separating them from internal processing time.
Where to get
Inferred from the audit history of the sn_customerservice_case table when the state field changes to a value indicating it is pending customer input (e.g., 'Awaiting Info').
Capture
Detect change in 'state' field to a designated 'awaiting customer' value.
Event type
inferred
|
|||
|
Request Categorized and Prioritized
|
Represents the initial triage where the service request is classified and assigned a priority level to determine its urgency and routing. This is inferred from changes to the category, subcategory, or priority fields in the case record's audit log. | ||
|
Why it matters
Analyzing this activity helps identify delays in case triage and ensures that requests are routed correctly and handled according to urgency. It impacts the time to first assignment and overall resolution efficiency.
Where to get
Inferred from the audit history (sys_audit) for the sn_customerservice_case table, specifically tracking the initial population or updates to the category and priority fields.
Capture
Detect first value set or value change for 'category' or 'priority' fields.
Event type
inferred
|
|||
|
Service Request Reopened
|
Occurs when a previously resolved service request is returned to an active state because the issue recurred or the solution was ineffective. This is inferred by detecting a state change from 'Resolved' back to 'Work in Progress'. | ||
|
Why it matters
Reopened cases are a direct measure of resolution quality and a primary driver of rework. Analyzing these events is critical for improving first-contact resolution rates and customer satisfaction.
Where to get
Inferred from the audit history of the sn_customerservice_case table by identifying a sequence where the state field moves from 'Resolved' to an active state.
Capture
Detect 'state' change from 'Resolved' to an active value like 'Work in Progress'.
Event type
inferred
|
|||
|
SLA Breached
|
Represents the moment a service request fails to meet a defined Service Level Agreement, such as time to resolution. This is a calculated event, derived by comparing the resolution time to the SLA's planned end time. | ||
|
Why it matters
Identifying SLA breaches is fundamental for compliance monitoring and performance management. This event helps pinpoint which process stages or case types contribute most to SLA violations.
Where to get
Calculated by analyzing records in the task_sla table related to the case. A breach occurs if the has_breached field is true, or if the actual_elapsed_time exceeds the planned_duration.
Capture
Check the 'has_breached' flag on the linked task_sla record.
Event type
calculated
|
|||
|
Solution Proposed
|
This activity marks when an agent has identified a solution and communicated it to the customer for their confirmation. It is often inferred from a state change to a value like 'Awaiting Acceptance' or from a specific work note entry. | ||
|
Why it matters
This milestone separates the investigation phase from the confirmation and resolution phase. Analyzing the time spent waiting for customer confirmation can reveal opportunities to streamline the closing stages of a case.
Where to get
Inferred from the audit log of the sn_customerservice_case table when the state changes to a value indicating a proposed solution (e.g., 'Proposed Solution'). This may vary by implementation.
Capture
Detect change in 'state' field to a value like 'Proposed Solution' or 'Awaiting Acceptance'.
Event type
inferred
|
|||