Your Service Request Management Data Template

The Activity attribute describes a specific step or action taken on a service request. These activities form the sequential building blocks of the process, such as 'Request Created', 'Request Assigned', 'Work In Progress', and 'Request Closed'. Each activity represents a distinct point in time in the journey of a service request.

Analyzing activities is the core of process mining. It allows for the discovery and visualization of the actual process flow. By examining the sequence and frequency of activities, analysts can identify common paths, deviations from the standard process, bottlenecks where requests get stuck, and rework loops where steps are repeated unnecessarily.

It defines the steps in the process, enabling the discovery of the actual process flow, bottlenecks, and deviations.

Often derived from status change logs, event tables, or audit trails associated with the service request object.

The Service Request ID is the primary key that uniquely identifies each service request throughout its lifecycle. It acts as the case identifier, linking all related activities, status changes, and attributes together into a coherent process instance.

In process mining analysis, this ID is fundamental for reconstructing the end-to-end journey of every request. By grouping all events under a common CaseId, analysts can visualize process flows, calculate case durations, and identify variations in how different requests are handled. It is the cornerstone of any analysis performed on the service request management process.

This ID is essential for stitching together all the events of a service request, allowing for a complete end-to-end process view.

Typically found in the header or main transaction table for service requests.

The Start Time records the precise date and time that a specific activity started. This timestamp is crucial for ordering events chronologically and for calculating the duration of activities and the overall case lifecycle. Each activity in the process should have a corresponding Start Time to build an accurate event log.

In process analysis, Start Time is used to calculate key performance indicators like cycle time, wait time between activities, and activity processing time. It enables the creation of a time-based view of the process, highlighting delays and helping to identify which steps consume the most time. Accurate timestamps are fundamental for any performance-related analysis.

This timestamp is critical for ordering events correctly and calculating all time-related metrics, such as cycle times and bottlenecks.

Located in the event log or audit trail tables, often recorded as a 'creation date' or 'event timestamp' for each activity record.

Last Data Update provides a timestamp of the most recent data extraction or refresh. It informs users about the freshness of the data they are analyzing, ensuring they understand whether the analysis reflects the current state or a past snapshot.

This attribute is essential for operational monitoring and reporting, as it provides context for the timeliness of the insights generated. It helps users trust the data and make informed decisions based on its recency. For example, a dashboard showing data last updated a week ago would be interpreted differently than one updated an hour ago.

Indicates the freshness of the data, which is vital for ensuring that analyses are relevant and based on up-to-date information.

This is a metadata field typically generated and stored during the data extraction (ETL) process.

The Source System attribute specifies the name of the IT Service Management (ITSM) platform or other application from which the data was extracted. In environments with multiple systems, this field helps differentiate data sources and ensures data lineage is clear.

While not directly used in most process flow analyses, it is critical for data governance, validation, and troubleshooting. When combining data from multiple sources, this attribute allows analysts to segment the process view by system, which can reveal differences in process execution or data quality between different platforms.

Crucial for data governance and troubleshooting, it clarifies the origin of data, especially in environments with multiple integrated systems.

This value is typically added during the data extraction (ETL) process and is not an inherent field in the source system itself.

The Assigned Agent is the specific person responsible for handling the service request at a given point in time. A request may be assigned to different agents throughout its lifecycle.

This attribute is key for performance and workload analysis. It enables organizations to measure and compare the performance of individual agents, including their average resolution times and the volume of requests they handle. It is also used to analyze reassignments between agents, which can indicate issues with initial triage, agent specialization, or workload balancing.

Enables analysis of individual agent performance, workload distribution, and the frequency of reassignments between agents.

Available on the service request record. Changes in this field are often tracked in an audit log or history table.

The Assigned Team refers to the specific support group responsible for the service request. Requests are often routed between different teams, such as a Level 1 help desk, a network team, or a software development team, depending on the required expertise.

Analyzing handoffs between teams is a core part of service management process mining. This attribute allows for the visualization of team-to-team transfers, helping to identify communication gaps or delays. It also enables performance benchmarking between teams, comparing their efficiency, request volume, and ability to resolve requests without further escalation.

Crucial for analyzing process handoffs between teams, identifying delays in transfers, and comparing team performance.

A standard field on the service request record. Changes in this field are tracked in an audit log.

Request Priority is a classification that helps support teams determine the order in which to handle requests. It is typically based on a combination of the request's impact on the business and its urgency. Common priority levels include Low, Medium, High, and Critical.

This attribute is vital for performance analysis and resource allocation. Analysts can compare cycle times and SLA compliance across different priority levels to ensure that high-priority requests are being handled appropriately. It also helps in identifying if low-priority requests are being neglected or if the prioritization system is being followed correctly by the support teams.

Essential for analyzing if requests are handled according to business importance and for understanding how priority impacts resolution time.

Typically a standard field on the main service request record.

The Request Status indicates the state of the service request at a given point in its lifecycle. Common statuses include New, In Progress, Pending, Resolved, and Closed. This attribute provides a snapshot of where the request is in the overall process.

Analyzing the Request Status is key to understanding the process flow and state transitions. It can be used to filter cases, identify requests stuck in a particular state, and measure the time spent in each status. For example, analyzing how long requests remain in a 'Pending' status can reveal delays caused by waiting for information from users or external teams.

It allows for analysis of how long requests spend in each state, highlighting bottlenecks or delays in the process.

Available in the main service request table or in status history logs.

Service Type classifies the nature of the service request. This could range from requests for new hardware or software access to general inquiries or technical support. This categorization helps in routing the request to the correct team and understanding the demand for different services.

In process analysis, Service Type is a powerful dimension for segmenting the data. By filtering the process map by different service types, organizations can uncover that certain types of requests follow vastly different processes, have longer cycle times, or experience more rework. This insight allows for targeted process improvement efforts for specific service categories.

Allows for filtering and comparing processes for different request categories, revealing unique bottlenecks or inefficiencies for each type.

A standard field on the service request record, often linked to a service catalog.

The SLA Due Date is a target timestamp calculated based on the service level agreement associated with the request. It is determined by factors like the request's priority, type, and creation time, defining the expected resolution timeframe.

This attribute is the basis for all SLA compliance analysis. By comparing the actual resolution time with the SLA Due Date, organizations can determine if a request was resolved on time or if the SLA was breached. This is a critical KPI for measuring service quality and is used to identify systemic issues that cause delays and lead to breaches.

This is the benchmark for measuring performance. It is used to calculate SLA compliance rates and identify which requests are breached.

Often a calculated field on the service request record, determined by the applied SLA policy.

The End Time records the precise date and time that a specific activity was finished. While Start Time marks the beginning, End Time marks the conclusion, defining the duration of a single process step. Not all events have a distinct End Time, as some can be instantaneous.

This attribute is essential for calculating the processing time of individual activities. By subtracting the Start Time from the End Time, analysts can measure how long agents or systems spend actively working on a task. This helps pinpoint which specific activities are time-consuming and are primary candidates for optimization or automation.

Enables the calculation of activity processing times, helping to identify which specific steps in the process are most time-consuming.

Found in event log or audit trail tables. It may need to be derived by using the Start Time of the next activity if not explicitly available.

This boolean attribute indicates whether the service request failed to meet its defined service level agreement. It is true if the request was resolved after the 'SlaDueDate', and false otherwise.

This attribute simplifies SLA compliance reporting and analysis. Instead of performing date comparisons in every query, this simple flag allows for easy filtering and aggregation. It is a primary metric for dashboards focusing on SLA performance and helps quickly identify the volume and percentage of requests that are not meeting service targets.

Provides a clear and simple flag for SLA performance analysis, making it easy to filter for and report on breached requests.

This is a derived attribute, calculated by comparing the final resolution timestamp with the 'SlaDueDate' field during data transformation.

Reassignment Count is a metric that totals the number of times a service request was transferred from one agent or team to another. A high count can indicate issues such as incorrect initial routing, lack of agent knowledge, or unclear process ownership.

This is a key indicator of process inefficiency. In process mining, this metric helps quantify the amount of 'ping-pong' a request experiences. Analyzing cases with high reassignment counts can reveal opportunities to improve the triage process, enhance agent training, or refine team responsibilities to ensure requests are routed correctly the first time.

A key metric for identifying process inefficiency. High reassignment counts often correlate with longer resolution times and user dissatisfaction.

This is a calculated metric, derived by counting the number of times the 'AssignedAgent' or 'AssignedTeam' field changes for a given 'CaseId'.

This attribute identifies the department or business unit of the person who initiated the service request. It provides organizational context to the request.

Analyzing requests by department can help identify department-specific needs, trends, or issues. For example, a high volume of a certain request type from the Finance department could indicate a need for targeted training or a system improvement. It also allows for chargeback reporting and understanding the demand for IT services across the organization.

Provides organizational context, allowing for analysis of request patterns and service demand by business unit.

This information is typically pulled from the requestor's user profile in the employee directory or ITSM system.

The Resolution Code provides a structured way to classify the outcome of a service request. Examples include 'Solved by User', 'Hardware Replaced', 'Software Deployed', or 'Duplicate Request'. This information is typically entered by the agent upon closing the request.

These codes are valuable for root cause analysis. By analyzing the frequency of different resolution codes, organizations can identify recurring problems, common solutions, and opportunities for creating knowledge base articles or automated resolutions. For example, a high number of 'Password Reset' resolutions might justify investment in a self-service password reset tool.

Enables root cause analysis by categorizing how requests are resolved, helping to identify trends and areas for proactive problem management.

A field that is typically manually populated by the agent when resolving or closing the service request.

The Submission Channel indicates how the service request was created, for example, via a self-service portal, email, phone call, or API. Different channels may have different associated processes or user expectations.

Analyzing the process by submission channel can reveal important insights. For instance, requests submitted via a self-service portal might be more structured and resolved faster than those submitted via email, which may require manual data entry. This analysis can help organizations promote more efficient channels or improve the processes for less efficient ones.

Helps determine if the submission method impacts the process efficiency, resolution time, or rate of first contact resolution.

Typically found as a standard field on the service request record.