Your Customer Service Data Template

An Activity represents a distinct step or event in the lifecycle of a service request. Examples include 'Service Request Created', 'Request Assigned', 'Solution Proposed', and 'Request Closed'. Each activity is associated with a specific service request and has a timestamp indicating when it occurred.

This attribute is critical for building the process map, which is the visual representation of the customer service workflow. Analyzing the sequence and frequency of activities helps uncover the actual paths that service requests take, highlighting common workflows, bottlenecks, deviations, and rework loops. It forms the backbone of any process mining analysis.

This attribute defines the steps in your process map. It is essential for understanding what work is being done and in what sequence.

Often derived from event logs, status change tables, or audit trail records within the customer service system.

Event Time, also known as the start time, captures the moment an activity happened. Every event in the log, from the initial creation of a service request to its final closure, is marked with a timestamp. This temporal data is crucial for ordering events chronologically.

The sequence of these timestamps for a given service request allows process mining tools to reconstruct the process flow as it happened in reality. Event Time is the basis for all time-based analysis, including calculating the duration between activities, measuring the total case resolution time, identifying bottlenecks, and checking for compliance with service level agreements (SLAs).

This timestamp orders events and enables all duration-based analysis, such as calculating resolution times and identifying bottlenecks.

Found in event logs or audit trail tables, often alongside the activity name. It may be named 'Creation Date', 'Event Date', or 'Timestamp'.

The Service Request ID is the primary key that uniquely identifies each customer case from its creation to its final resolution. It serves as the case identifier, grouping all events, communications, and actions related to a specific customer issue into a cohesive timeline.

In process mining, this attribute is fundamental for reconstructing the end-to-end journey of each service request. By correlating every activity to a specific Service Request ID, analysts can visualize process flows, identify deviations, and measure case durations accurately. It enables a case-centric view of the process, which is essential for understanding performance and identifying areas for improvement.

This is the essential case identifier. Without it, you cannot trace the journey of a single customer issue through the process.

Typically found in the header or main table for cases, tickets, or incidents in a customer service management system.

The Last Data Update attribute records the date and time of the most recent data extraction or refresh. This metadata is vital for understanding the freshness of the data being analyzed and for managing the data pipeline.

This attribute provides transparency to business users and analysts about how current their analysis is. It helps in scheduling data refreshes and ensures that decisions are based on data that is as up-to-date as required. For monitoring ongoing processes, knowing the last update time is critical to correctly interpret the current state of open cases.

Indicates data freshness, ensuring that analyses and business decisions are based on timely and relevant information.

This timestamp is typically generated and added during the data extraction (ETL) process.

The Source System attribute identifies the application or platform where the customer service data originated, such as ServiceNow, Salesforce, Zendesk, or a custom in-house system. In environments where data from multiple systems is combined, this field is crucial for data governance and traceability.

While not directly used in most standard process flow analyses, it provides important context. It helps in understanding potential variations in data quality or process execution between different systems. It is also essential for data validation, troubleshooting data extraction issues, and managing data integration pipelines.

Identifies the data's origin, which is crucial for data governance, troubleshooting, and analysis in multi-system environments.

This is typically added during the data extraction (ETL) process and may not exist directly in the source system's tables.

The Agent attribute identifies the individual employee who performed a particular activity or is currently assigned to a service request. This could be a unique ID, an email address, or a full name.

This attribute enables performance and workload analysis at the individual level. It allows managers to see how work is distributed, compare agent performance on metrics like resolution time or customer satisfaction, and identify training opportunities. It is also crucial for analyzing handoffs between agents, which can be a source of delays and customer frustration.

This attribute is essential for analyzing agent workload, performance, and the impact of handoffs between different agents.

Commonly found in case assignment history tables, event logs, or as a field on the main case or ticket record.

The Assigned Group identifies the team or functional unit responsible for a service request at a given point in time. This could be 'Level 1 Support', 'Billing Department', or 'Technical Support Team'. Service requests are often routed between different groups as they progress.

Analyzing the Assigned Group is critical for understanding inter-team collaboration and handoffs. It helps identify which teams are overloaded, where bottlenecks occur between groups, and the paths that different types of requests take through the organization. This information is vital for optimizing team structures, resource allocation, and routing rules.

Allows for analysis of team performance, workload distribution, and delays caused by handoffs between different departments.

Located in the case or ticket record, often in fields like 'Assignment Group', 'Team', or 'Queue'.

The Communication Channel identifies the medium used by the customer to interact with the service desk. Common channels include email, phone, web portal, chat, and social media. The channel can influence customer expectations and the complexity of the resolution process.

Analyzing the process by communication channel can reveal significant differences in performance. For example, requests submitted via phone might have faster resolution times but require more agent resources compared to those from a web portal. This analysis helps organizations optimize their channel strategy, allocate resources effectively, and tailor the service experience to different communication methods.

Reveals how different communication channels impact resolution times, agent effort, and overall process efficiency.

Typically available as a standard field on the case or ticket record, indicating how the request was created.

Customer Satisfaction is a key outcome metric that measures the customer's perception of the service they received. It is typically captured through a post-resolution survey, often on a numerical scale, like 1 to 5, or as a categorical rating like 'Good', 'Neutral', or 'Bad'.

This attribute is crucial for connecting process performance to business outcomes. By correlating satisfaction scores with process metrics, analysts can identify which process behaviors lead to happy or unhappy customers. For instance, analysis might show that cases with multiple reassignments or long resolution times consistently receive low satisfaction scores. This provides a clear, data-driven basis for prioritizing process improvements that will have the greatest impact on customer experience.

Directly measures the customer's perception of service quality, linking process efficiency to business outcomes.

Usually stored in a separate survey response table that can be linked to the service request record.

The End Time attribute marks the completion point of an activity. While Event Time marks the start, End Time provides the other necessary point to measure how long a specific task took. Not all events have a distinct end time, but for those that do, such as 'Agent Investigation' or a customer call, it is valuable information.

In analysis, the difference between End Time and Event Time yields the activity's processing time. This is fundamental for bottleneck analysis, where the goal is to find which steps in the process consume the most time. Understanding activity durations helps in resource planning, performance evaluation, and identifying opportunities to streamline operations.

This attribute is key to calculating individual activity durations, which is essential for identifying bottlenecks and measuring efficiency.

Usually found in event logs or audit trail tables alongside the start time. If not available, it may need to be derived from the start time of the subsequent event.

The Is Escalated attribute is a boolean flag (true or false) that marks a service request as having been formally escalated. Escalations typically occur when an issue is too complex for the current support tier, is not resolved within a specified time, or when a customer is highly dissatisfied.

This attribute is essential for escalation analysis. It allows organizations to calculate the escalation rate, a key performance indicator. By analyzing the process flow of escalated cases, companies can identify the root causes of escalations, such as skill gaps in frontline support, unclear processes, or product issues. Reducing escalations is often a major goal, as they are costly and can negatively impact customer satisfaction.

Helps identify the frequency and root causes of escalations, highlighting opportunities to improve first-contact resolution.

This is often a checkbox or flag field on the case or ticket record. It can also be derived by detecting an 'Escalate' activity.

The Priority attribute indicates the urgency of a service request, which often influences how quickly it needs to be addressed. This level is typically determined based on the business impact and severity of the issue reported by the customer. SLAs are often tied to the priority level.

In process analysis, priority is a key dimension for filtering and comparison. Analysts can check if high-priority requests are actually being resolved faster than low-priority ones, as expected. It helps to verify if prioritization rules are being followed and to assess whether resource allocation aligns with business priorities. Comparing the process flows for different priority levels can reveal inefficiencies in handling critical issues.

Allows analysis of whether urgent requests are handled faster and helps verify that resources are aligned with business needs.

A standard field on the case or ticket form in most customer service systems.

The Request Status indicates the state of a service request at a specific point in its lifecycle. The status changes as the request is worked on, for example, moving from 'New' to 'In Progress', then 'Pending Customer', and finally 'Resolved'. The sequence of status changes often forms the basis for the activities in the process model.

Analyzing status changes is a primary way to understand the process flow. It helps identify how much time requests spend in certain states, such as 'Pending', which can highlight dependencies on external parties. It is also used to differentiate between open and closed cases, which is fundamental for reporting on active caseloads and resolution rates.

Tracks the lifecycle stage of a request, helping to identify time spent in waiting states and to define process activities.

A core field on the case or ticket record. Status changes are often logged in an audit history table.

The Request Type provides a high-level categorization of the customer's issue or inquiry. This classification helps segment service requests to understand the different types of demand being placed on the support organization. Common types include technical problems, billing questions, information requests, or complaints.

This attribute is extremely valuable for analysis as it allows for filtering and comparing processes for different kinds of requests. For example, the resolution process for a 'Billing Question' might be much simpler and faster than for a 'Technical Incident'. Understanding these differences is key to setting appropriate SLAs, designing efficient workflows, and allocating resources effectively.

Segmenting requests by type is crucial for understanding different process paths and tailoring improvements to specific issues.

This is a standard field on the main case or ticket form, often named 'Type', 'Category', or 'Classification'.

The Customer attribute identifies the external client, either an individual or an organization, associated with the service request. This allows for the grouping and analysis of all service interactions for a particular customer.

A customer-centric view is crucial for understanding the overall customer experience. By analyzing data filtered by customer, businesses can identify clients who submit a high volume of requests, which might indicate issues with a product or a need for better training. It also helps in tracking the service history for key accounts to ensure they are receiving the expected level of support.

Enables a customer-centric view of the process, helping to identify frequent issues for specific clients and manage key accounts.

A standard field on the case or ticket record, linking to the contact or account object in the CRM.

The Product attribute specifies the particular product, service, or feature that is the subject of the customer's request. This allows for the categorization of service requests based on the area of the business they pertain to.

Analyzing service requests by product is vital for root cause analysis and product improvement. A high volume of tickets for a specific product can signal quality issues, bugs, or usability problems. This data provides valuable feedback to product development and engineering teams, helping them prioritize fixes and enhancements that will reduce the support workload and improve the customer experience.

Links service requests to specific products, providing critical feedback for product improvement and root cause analysis.

Often a field on the case or ticket form that links to a product catalog or can be manually entered.

The SLA Target Time represents the deadline by which a service request is expected to be resolved according to the governing Service Level Agreement (SLA). This target is often dependent on the request's priority, type, or the customer's contract level. It can be stored as a specific timestamp or as a duration from the creation time.

This attribute is fundamental for SLA compliance analysis. By comparing the actual resolution time with the SLA Target Time, organizations can determine their SLA compliance rate. Process mining can further break this down, showing which types of requests or which process steps are contributing most to SLA breaches. This allows for targeted improvements to meet service commitments.

This is essential for measuring SLA compliance, a critical KPI for customer service organizations.

Typically calculated and stored on the case or ticket record based on defined SLA policies within the system.