> Continuous Process Improvement > Customer Service > Zendesk Support > Data Template

Your Customer Service Data Template

Zendesk Support

Customer Service Attributes (19) Customer Service Activities (14) Extraction Guides (4)

Your Customer Service Data Template

This template helps you gather the right data for analyzing your customer service process. It outlines essential data attributes to collect, key activities to track, and provides practical guidance on how to extract this information. Using this guide, you can build a robust event log to uncover insights and improve your service operations.

Recommended attributes to collect
Key activities to track for your customer service process
Extraction guidance for Zendesk Support

New to event logs? Learn how to create a process mining event log.

Download Template

Customer Service Attributes

These are the recommended data fields to include in your event log for comprehensive customer service analysis.

5 Required 7 Recommended 7 Optional

	Name	Description
	Service Request ServiceRequest	The unique identifier for each customer service request, also known as a ticket or case.
Description The Service Request is the primary case identifier that links all activities related to a single customer inquiry or issue from its creation to final resolution. Each interaction, update, or internal action is tied to this unique ID. In process mining, analyzing events grouped by the Service Request allows for a complete end-to-end view of the customer service journey. It is the foundation for calculating key metrics like total resolution time, identifying process deviations, and understanding the lifecycle of each customer issue. Why it matters This is the essential Case ID that connects all process steps, enabling the reconstruction and analysis of each individual customer service journey. Where to get Zendesk Tickets API, `id` field. Examples 102451287415332
	Start Time StartTime	The timestamp indicating when an activity or event began.
Description The Start Time, or event timestamp, records the exact date and time that a specific activity occurred. For example, it captures when a customer comment was added, when an agent was assigned, or when the ticket status changed to 'Resolved'. This timestamp is fundamental for process mining as it establishes the chronological order of events. It is used to calculate durations between activities, measure cycle times, analyze performance against SLAs, and understand the temporal dynamics of the service process. Why it matters This timestamp is essential for ordering events, calculating durations, and analyzing the timeline of the service request process. Where to get Zendesk Ticket Audits API, `created_at` field for each event in the audit trail. Examples 2023-04-15T10:00:00Z2023-04-15T10:05:14Z2023-04-16T14:30:00Z
	Activity Name ActivityName	The name of the specific event or task that occurred within the service request lifecycle.
Description The Activity Name describes a single step or milestone in the customer service process, such as 'Service Request Created', 'Request Assigned To Agent', or 'Service Request Resolved'. These events are timestamped and form the sequence of actions for each service request. This attribute is critical for visualizing the process flow, discovering process variants, and analyzing the frequency and order of events. It allows analysts to understand what actions are being performed and to identify common paths, bottlenecks, and deviations from the standard procedure. Why it matters This attribute defines the steps in the process, allowing for the visualization of the process map and analysis of process flows and variations. Where to get Derived from Zendesk ticket audit logs or event streams which record changes and actions. Examples Service Request CreatedRequest Assigned To AgentFirst Agent Public Reply SentService Request Resolved
	Last Data Update LastDataUpdate	The timestamp of the most recent data refresh or extraction from the source system.
Description This attribute indicates the last time the dataset was updated from Zendesk Support. It provides context on the freshness of the data being analyzed. Knowing the last update time is crucial for analysts and business users to understand if they are viewing the most current process information. It helps manage expectations about the data's recency and is vital for reporting and monitoring purposes. Why it matters Provides clarity on the recency of the data, ensuring users understand how current the process analysis is. Where to get This is a metadata field generated and stored during the data extraction process, recording the timestamp of the extraction job. Examples 2023-10-27T02:00:00Z
	Source System SourceSystem	The system of record from which the data was extracted.
Description This attribute specifies the originating system for the service request data, which in this case is Zendesk Support. It helps in data governance and lineage, especially when combining data from multiple systems. In analysis, it ensures that data is correctly attributed to its source, which is important for maintaining data integrity and understanding the context of the process, particularly in multi-system environments. Why it matters Identifies the data's origin, which is crucial for data governance and for distinguishing process data in integrated environments. Where to get This is a static value added during the data extraction process to label the data's origin. Examples Zendesk Support
	Assigned Agent AssignedAgent	The name or ID of the customer service agent assigned to handle the service request.
Description This attribute identifies the specific agent responsible for an activity or the service request at a given point in time. It can change throughout the lifecycle if the request is reassigned. Analyzing by Assigned Agent is key to understanding agent workload, performance, and efficiency. It supports the 'Agent Workload and Efficiency' dashboard by allowing for comparisons of handling times and case volumes across different agents, helping to identify coaching opportunities and ensure balanced workloads. Why it matters Tracks which agent performed an action, enabling analysis of individual performance, workload distribution, and resource allocation. Where to get Zendesk Tickets API, `assignee_id` field. User details can be retrieved from the Users API. Examples John SmithJane DoeSupportBot
	Communication Channel CommunicationChannel	The channel through which the service request was submitted or communication occurred.
Description This attribute identifies the method of communication used, such as email, web form, chat, or phone. It reflects how customers are interacting with the service desk. Understanding channel usage is important for resource planning and improving customer experience. The 'Communication Channel Usage Overview' dashboard analyzes this data to see which channels are most popular and if certain channels are associated with longer resolution times or different process paths. It can help in deciding where to invest in service improvements or automation. Why it matters Shows how customers and agents interact, enabling analysis of channel efficiency and its impact on the process and customer experience. Where to get Zendesk Tickets API, `via.channel` field. Examples webemailapichat
	Is SLA Breached IsSlaBreached	A boolean flag indicating whether the service request resolution time exceeded its SLA target.
Description This calculated attribute is a simple true or false flag that shows if a service request failed to meet its defined Service Level Agreement for resolution time. It is derived by comparing the actual resolution duration with the planned SLA target. This flag simplifies SLA compliance analysis. It is the core data point for the 'SLA Compliance Performance' dashboard and the 'SLA Compliance Rate' KPI, allowing for quick aggregation and visualization of how many requests are meeting service targets versus how many are not. Why it matters Provides a clear, binary outcome for SLA performance on each case, simplifying compliance monitoring and reporting. Where to get Calculated during data transformation by comparing the total resolution time with the SlaTargetResolutionTime. Examples truefalse
	Priority Priority	The priority level assigned to the service request, such as 'Low', 'Normal', 'High', or 'Urgent'.
Description Priority indicates the urgency of a service request and often influences its position in the queue and the target resolution time. It helps agents focus on the most critical issues first. This attribute is essential for performance and SLA analysis. The 'Service Request Resolution Time Analysis' dashboard uses priority to segment data, revealing if high-priority requests are being handled faster than lower-priority ones and whether resources are allocated effectively according to business needs. Why it matters Indicates the urgency of a request, which is critical for analyzing SLA compliance and ensuring that critical issues are addressed promptly. Where to get Zendesk Tickets API, `priority` field. Examples LowNormalHighUrgent
	Resolution Time ServiceRequestResolutionTime	The total time elapsed from when a service request was created until it was finally resolved.
Description This metric measures the end-to-end duration of a service request. It is calculated as the difference between the timestamp of the 'Service Request Resolved' activity and the 'Service Request Created' activity. This is one of the most important KPIs for any customer service process. It is the primary metric for the 'Service Request Resolution Time Analysis' dashboard and the 'Average Service Request Resolution Time' KPI. Analyzing this duration helps identify systemic delays and measure the overall efficiency of the support process. Why it matters Measures the end-to-end case duration, a critical KPI for assessing overall process efficiency and customer experience. Where to get Calculated by subtracting the creation timestamp from the final resolution timestamp for each Service Request. Examples 720086400172800
	Service Request Type ServiceRequestType	The classification of the service request, such as 'Question', 'Incident', 'Problem', or 'Task'.
Description This attribute categorizes the service request based on its nature. This classification is typically set when the request is created or triaged and helps determine the appropriate workflow and priority. In analysis, segmenting by Service Request Type is fundamental. It allows for comparing resolution times, escalation rates, and process flows for different types of issues, as shown in dashboards like 'Service Request Resolution Time Analysis' and 'Internal Escalation Rate & Causes'. This helps identify if certain types of requests are more problematic or inefficient to handle. Why it matters Categorizes requests to allow for performance comparison and analysis across different types of issues, which is crucial for targeted process improvement. Where to get Zendesk Tickets API, `type` field. Examples QuestionIncidentProblemTask
	SLA Target Resolution Time SlaTargetResolutionTime	The target duration within which a service request is expected to be resolved, based on its SLA policy.
Description This attribute defines the Service Level Agreement (SLA) target for resolving a ticket. This target is often dynamic and depends on factors like the request's priority, type, or the customer's service plan. This is a foundational attribute for the 'SLA Compliance Performance' dashboard. It serves as the benchmark against which the actual resolution time is measured. Analyzing performance against this target helps quantify service delivery quality and ensures that contractual obligations to customers are being met. Why it matters Defines the service promise to the customer, acting as the benchmark for measuring on-time performance and SLA compliance. Where to get Derived from the SLA policies applied to a ticket. This information is available via the Zendesk Ticket Metrics API. Examples 144002880086400
	Agent Group AgentGroup	The support group or team to which the service request is assigned.
Description This attribute represents the team of agents responsible for the service request. Requests are often routed to specific groups based on skill, product area, or language. Analyzing by Agent Group helps in understanding team-level performance, workload distribution, and escalation patterns between teams. It provides a higher-level view than individual agent analysis and can help identify systemic issues within specific departments or functions. Why it matters Tracks team responsibility, enabling analysis of group performance, inter-team handoffs, and resource allocation across different support tiers or specialties. Where to get Zendesk Tickets API, `group_id` field. Group details can be retrieved from the Groups API. Examples Tier 1 SupportTechnical SupportBilling
	End Time EndTime	The timestamp indicating when an activity or event was completed.
Description The End Time represents the completion time of an activity. In many event log structures, the Start Time of the next activity can serve as the End Time of the current one. For state-based activities like 'Agent Investigates Issue', it marks when that state concluded. This attribute is essential for calculating the precise duration of activities, which is a core component of performance analysis. It helps identify which steps are most time-consuming and provides the basis for detailed bottleneck analysis and resource efficiency calculations. Why it matters Enables the calculation of activity durations, which is critical for identifying bottlenecks and measuring performance. Where to get This is often derived by taking the StartTime of the subsequent event in the sequence for a given Service Request. Examples 2023-04-15T10:05:14Z2023-04-15T11:20:30Z2023-04-16T15:00:00Z
	Information Request Count InformationRequestCount	The total number of times information was requested from the customer for a single service request.
Description This calculated metric counts the occurrences of the 'Information Requested From Customer' activity for each service request. A high count suggests that agents are not gathering all necessary information upfront. This attribute is used in the 'Repeated Information Request Analysis' dashboard. Tracking this count helps identify process inefficiencies and areas for agent training. Reducing the number of times information is requested can significantly shorten resolution times and improve the customer experience. Why it matters Quantifies back-and-forth communication with the customer, highlighting inefficiencies that prolong resolution times and degrade customer experience. Where to get Calculated by counting the number of events where the ActivityName is 'Information Requested From Customer' for each Service Request. Examples 013
	Is Reopened IsReopened	A boolean flag indicating if a service request was reopened after being marked as resolved.
Description This attribute is a flag that becomes true if a service request transitions back to an open state after it had previously been set to resolved or closed. It signals that the initial resolution was not sufficient. This flag is crucial for tracking rework and first-contact resolution failures. It directly supports the 'Reopened Service Request Trends' dashboard and the 'Service Request Reopen Rate' KPI by making it easy to count and analyze the cases that require additional attention, which often indicates deeper underlying issues. Why it matters Identifies rework and failed resolutions, helping to measure the quality and effectiveness of the solutions provided. Where to get Calculated during data transformation by checking if a ticket's status changes from 'resolved' or 'closed' back to 'open'. Examples truefalse
	Product Service Category ProductServiceCategory	The specific product, service, or feature that the customer's request is about.
Description This attribute provides detailed context by categorizing the service request based on a product or service area. It is often set manually by an agent or automatically based on the request content. This categorization is vital for the 'Request Categorization Accuracy' and 'Investigation Cycle Time Breakdown' dashboards. It allows for deep-dive analysis into which products generate the most support requests, which are the most complex to resolve, and whether initial categorization aligns with the final solution, helping to improve routing and agent training. Why it matters Links requests to specific business areas, products, or services, enabling focused analysis on problem areas and their impact on the process. Where to get This is typically a custom ticket field in Zendesk. The exact field name depends on the specific Zendesk configuration. Examples Mobile AppSubscription ManagementAPI IntegrationHardware
	Resolution Code ResolutionCode	A code or category indicating the reason for the final resolution or closure of the request.
Description The Resolution Code provides structured information about the outcome of a service request. Examples include 'Solved by Agent', 'Duplicate', 'No Action Needed', or 'Known Issue'. It offers more context than a simple 'Closed' status. This attribute is particularly valuable for root cause analysis. For the 'Reopened Service Request Trends' dashboard, analyzing reopen rates by resolution code can reveal if certain types of solutions are less effective, leading to customers needing to re-engage with support. Why it matters Provides insight into the outcome of a service request, which is crucial for root cause analysis and understanding why requests are being reopened. Where to get This is typically a custom ticket field in Zendesk. The exact field name depends on the specific Zendesk configuration. Examples First Contact ResolutionEscalated to Tier 2Awaiting CustomerProduct Bug
	Satisfaction Rating SatisfactionRating	The satisfaction score provided by the customer after the service request was resolved.
Description This attribute captures the customer's feedback on their service experience, typically collected through a survey after the ticket is solved. Common ratings include 'Good', 'Bad', or a numeric score. This is a direct measure of customer sentiment and is a key outcome metric. It is used to calculate the 'Customer Sentiment Score' KPI. Analyzing satisfaction ratings in conjunction with process data, such as resolution time or number of agent touches, can reveal which process behaviors lead to better customer outcomes. Why it matters Directly measures customer feedback on the service provided, linking process performance to customer outcomes. Where to get Zendesk Tickets API, `satisfaction_rating.score` field. Examples goodbadoffered

Required Recommended Optional

Customer Service Activities

These are the key process steps and milestones to capture in your event log for accurate customer service process discovery.

6 Recommended 8 Optional

	Activity	Description
	Information Requested From Customer	Occurs when an agent requires more information from a customer to proceed and changes the ticket status to 'pending'. This status change explicitly indicates the process is now waiting on an external party.
Why it matters This activity highlights dependencies on the customer and pauses internal SLA clocks. Frequent or repeated instances on a single ticket can indicate incomplete initial information gathering and lead to longer resolution times. Where to get This is an explicit status change event recorded in the Zendesk Ticket Audits API. It is captured when the 'status' field changes to 'pending'. Capture Identify 'Change' events in the Ticket Audits where the ticket status is set to 'pending'. Event type explicit
	Request Assigned To Agent	This event signifies that the service request has been assigned to a specific agent for handling. It can happen automatically based on routing rules or manually by a team lead or agent.
Why it matters Assignment is a critical milestone for accountability and workload management. Analyzing the time to assignment and reassignment patterns reveals bottlenecks in the triage and distribution process. Where to get This is an explicit 'Change' event in the Zendesk Ticket Audits API, logged whenever the 'assignee_id' field is populated or changed. Capture Track changes to the 'assignee_id' field in the Ticket Audits log. Event type explicit
	Service Request Closed	This is the final activity, marking the permanent closure of the service request. This typically happens automatically after a set period of time has passed since the ticket was marked 'solved', without any new replies from the customer.
Why it matters As the definitive end event, it finalizes the ticket lifecycle. The time from 'solved' to 'closed' represents the window for potential reopens, and the 'closed' event confirms the resolution was accepted. Where to get This is an explicit status change recorded in the Zendesk Ticket Audits API when the 'status' field is set to 'closed'. Capture Identify 'Change' events in the Ticket Audits where the ticket status is set to 'closed'. Event type explicit
	Service Request Created	This activity marks the beginning of the customer service process, when a new ticket is generated in Zendesk from any channel like email, web form, or chat. This event is explicitly logged by the system with a unique ticket ID and timestamp upon creation.
Why it matters As the primary start event, it is essential for calculating the overall case duration and analyzing incoming request volumes over time. It serves as the baseline for measuring key performance indicators like time to first response and total resolution time. Where to get This is an explicit event captured in the Zendesk Ticket Audits API. It corresponds to the 'Create' event for a ticket, providing the initial creation timestamp. Capture Captured from the ticket creation event in the Ticket Audits log. Event type explicit
	Service Request Reopened	This activity occurs if a customer replies to a ticket that is in the 'solved' status. Zendesk automatically changes the status back to 'open', indicating the issue was not fully resolved.
Why it matters Reopens are a critical indicator of First Contact Resolution failure and poor solution quality. Analyzing the frequency and reasons for reopened tickets helps identify areas for improving agent training and resolution procedures. Where to get This is an explicit status change in the Ticket Audits API, captured when the 'status' moves from 'solved' back to 'open'. Capture Track status 'Change' events from 'solved' to 'open'. Event type explicit
	Service Request Resolved	An agent marks the service request as 'solved' after providing a solution to the customer. This is a temporary state, as the ticket can be reopened by a customer reply before it is permanently closed.
Why it matters This is the primary milestone for measuring resolution time and agent efficiency. It signifies the point where the agent believes the work is complete, providing a basis for analyzing rework if the ticket is reopened. Where to get This is an explicit status change recorded in the Zendesk Ticket Audits API when the 'status' field is set to 'solved'. Capture Identify 'Change' events in the Ticket Audits where the ticket status is set to 'solved'. Event type explicit
	Customer Responded	This event is triggered when a customer replies to a ticket, typically one that was in a 'pending' state. Zendesk automatically transitions the ticket status from 'pending' back to 'open', signaling that the agent can resume work.
Why it matters This activity marks the end of a wait time and is a trigger for the process to continue. Analyzing the time customers take to respond can provide insights into the clarity of agent requests. Where to get This event corresponds to a new public comment from the end-user, which triggers an explicit status change from 'pending' to 'open' in the Ticket Audits API. Capture Track status 'Change' events from 'pending' to 'open' or identify new public comments by an end-user. Event type explicit
	First Agent Public Reply Sent	This activity marks the first time an agent sends a public comment to the customer, as opposed to an automated acknowledgment. This event is a crucial indicator of the agent's initial engagement with the customer's issue.
Why it matters This is a key milestone for measuring the 'First Reply Time' SLA, a critical indicator of service responsiveness. It separates automated communication from the start of active, human-led investigation and support. Where to get Identified by finding the first public comment in the Ticket Comments stream where the author is a human agent (not an automated system user). Capture Scan ticket comments, filtering for public comments from agents and selecting the one with the earliest timestamp. Event type inferred
	Initial Acknowledgment Sent	Represents the automated first response sent to the customer, confirming that their request has been received. This is typically handled by a Zendesk trigger that sends a templated email notification immediately after ticket creation.
Why it matters Tracking this activity is crucial for measuring initial responsiveness and managing customer expectations. The time between request creation and this acknowledgment is a key metric for customer satisfaction. Where to get Inferred from the first public comment on the ticket if its author is an automated user or if it occurs within seconds of ticket creation. This can be identified by analyzing the Ticket Comments stream. Capture Identify the first public comment created by an automation or trigger immediately following ticket creation. Event type inferred
	Internal Escalation Triggered	Represents the transfer of a service request to a different internal team or a higher support tier. This is typically inferred when the ticket's assigned group is changed.
Why it matters Tracking escalations is key to identifying process weaknesses, knowledge gaps in front-line support, and complex request types. High escalation rates can indicate a need for better training or process documentation. Where to get Inferred from a 'Change' event in the Ticket Audits API where the 'group_id' field is modified. A change in group signifies a handoff between teams. Capture Monitor changes to the 'group_id' field in the Ticket Audits log. Event type inferred
	Request Categorized And Prioritized	This activity occurs when an agent or automation sets or updates ticket fields such as type, category, and priority. This step is logged as a change event in the ticket's history.
Why it matters Proper categorization and prioritization are vital for efficient routing and resource allocation. Analyzing this activity helps determine the accuracy of initial triage and its impact on resolution times. Where to get Captured from the Zendesk Ticket Audits API as 'Change' events. It can be identified by looking for the first update to fields like 'priority', 'type', or custom fields related to categorization. Capture Filter Ticket Audit logs for the first 'Change' event on key categorization fields after creation. Event type explicit
	Satisfaction Rating Received	This event occurs when the customer submits their response to the satisfaction survey, providing a rating like 'Good' or 'Bad'. The rating and any associated comment are logged against the ticket.
Why it matters Direct customer feedback is invaluable for measuring service quality and customer sentiment. Analyzing these ratings in the context of the process flow helps correlate specific activities or agents with outcomes. Where to get Captured as a 'Change' event in the Ticket Audits API when the 'satisfaction_rating' field is populated with the customer's score and comment. Capture Filter Ticket Audit logs for changes to the 'satisfaction_rating' field. Event type explicit
	Satisfaction Survey Sent	Represents the point when a customer satisfaction (CSAT) survey is automatically sent to the customer. This usually happens a short time after the ticket is marked as solved.
Why it matters This activity initiates the customer feedback loop. Understanding when and if surveys are sent is important for contextualizing satisfaction scores and measuring the effectiveness of the feedback program. Where to get This can be inferred from an automation log or by a specific tag being added to the ticket. The 'satisfaction_rating' section in the Ticket Audits API also records when the survey was offered. Capture Look for tags like 'csat_sent' or use the timestamp from when the satisfaction rating was offered. Event type inferred
	SLA Breach Occurred	This activity marks the point in time when a service request fails to meet a predefined Service Level Agreement, such as first reply time or resolution time. This event is calculated based on ticket activity timestamps compared against SLA policies.
Why it matters SLA breaches directly impact customer satisfaction and contract compliance. Analyzing when and why they occur is critical for identifying systemic delays, resource shortages, or unrealistic performance targets. Where to get This can be sourced from the Zendesk Ticket Metrics API, which stores SLA breach timestamps ('breached_at'). Alternatively, it can be calculated by comparing ticket event timestamps against the defined SLA rules. Capture Use the 'breached_at' timestamp from the Ticket Metrics API or calculate by comparing resolution time to the SLA policy time. Event type calculated

Recommended Optional

Extraction Guides

How to get your data from Zendesk Support

Steps

Navigate to Zendesk Explore: Log in to your Zendesk instance and open the Explore product by clicking the product launcher icon in the top bar and selecting Explore.
Create a New Query: In Explore, click the Queries icon on the left sidebar, then click the "New query" button on the top right.
Select the Dataset: In the "Choose a dataset" window, select the Support: Tickets dataset. This dataset contains the primary ticket attributes and key event timestamps.
Add Metrics: In the query builder, go to the "Metrics" panel and click "Add". Select COUNT(Tickets). This helps in validating the data volume.
Add Attributes to Rows: Go to the "Rows" panel and click "Add". Add the following attributes. These will form the base columns of your wide-format export.
- Ticket ID (This is your Case Identifier, ServiceRequest)
- Assignee name (AssignedAgent)
- Ticket type (ServiceRequestType)
- Ticket priority (Priority)
- Ticket channel (CommunicationChannel)
- SLA resolution time (SlaTargetResolutionTime)
- SLA breach status (IsSlaBreached)
- Full resolution time (min) (ServiceRequestResolutionTime)
Add Activity Timestamps to Rows: Add the following timestamp attributes to the "Rows" panel. Each of these represents a potential activity. Some activities require creating a custom calculated attribute.
- Ticket created - Timestamp: For Service Request Created and Initial Acknowledgment Sent.
- Ticket assigned - Timestamp: For Request Assigned To Agent.
- First reply time - Timestamp: For First Agent Public Reply Sent.
- Ticket solved - Timestamp: For Service Request Resolved and Satisfaction Survey Sent.
- Ticket reopened - Timestamp: For Service Request Reopened.
- Satisfaction rating received - Timestamp: For Satisfaction Rating Received.
- Ticket closed - Timestamp: For Service Request Closed.
Create Custom Calculated Attributes for Other Activities: Some activities are based on specific field changes and require creating custom attributes to capture their timestamp. Go to the Calculations menu (calculator icon) and select "Standard calculated attribute". Create one attribute for each of the following activities. You will need to find the exact names for fields and values in your Zendesk instance.
- Name: Timestamp - Categorized and Prioritized. Formula: IF ([Changes - Field name] = "priority" OR [Changes - Field name] = "type") THEN [Update - Timestamp] ENDIF. After creating it, add this new attribute to the "Rows" panel and change its aggregator to MIN.
- Name: Timestamp - Info Requested. Formula: IF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN [Update - Timestamp] ENDIF. Add it to "Rows" and set aggregator to MIN.
- Name: Timestamp - Customer Responded. Formula: IF ([Changes - Field name] = "status" AND [Changes - Previous value] = "pending" AND [Changes - New value] = "open") THEN [Update - Timestamp] ENDIF. Add it to "Rows" and set aggregator to MIN.
- Name: Timestamp - Escalated. Formula: IF ([Changes - Field name] = "group") THEN [Update - Timestamp] ENDIF. Add it to "Rows" and set aggregator to MIN.
- Name: Timestamp - SLA Breach. Formula: IF ([SLA breach status]=TRUE) THEN [SLA update - Timestamp] ENDIF. Add it to "Rows" and set aggregator to MIN.
Filter the Data: Go to the "Filters" panel and click "Add". Add a filter for Ticket created - Date and select an appropriate date range, such as the last 3 to 6 months, to keep the dataset manageable.
Run and Export the Report: Click "Save" to run the query. Once the table displays the data, click the "Export" button and choose your preferred format, such as CSV or Excel.
Transform Data to Event Log Format: The exported file is in a "wide" format where each row is a ticket and each column is an event timestamp. You must transform this into a "long" format for process mining. Use a tool like Microsoft Excel (with Power Query's Unpivot feature), Python, or another data preparation tool.
- For each row (ticket), create multiple new rows, one for each non-empty timestamp column.
- The final table should have columns like ServiceRequest, ActivityName, StartTime, and the other attributes, which will be duplicated for each activity of a given service request.

Configuration

Dataset: The primary dataset to use is Support: Tickets. This allows access to most ticket properties and key timestamps in a single query.
Permissions: You need at least an Editor or Admin role in Zendesk Explore to create and save queries.
Date Range: It is crucial to set a date range filter on Ticket created - Date. A range of 3 to 6 months of data is recommended to balance insight with performance. Exporting millions of tickets can be slow or may fail.
Query Filters: Consider adding filters for specific ticket properties like Ticket brand, Ticket form, or Ticket group to focus the analysis on a particular service or team.
Calculated Attributes: This method relies heavily on creating standard calculated attributes to capture timestamps for events that are not default attributes, such as status changes or escalations. Ensure you have the permissions to create these attributes.

a Sample Query config

This extraction is configured through the Zendesk Explore graphical user interface. There is no single script to execute. The configuration below outlines the components to add in the query builder.

**Dataset**: `Support: Tickets`

**Metrics**:
1.  `COUNT(Tickets)`

**Rows (Attributes)**:
1.  `Ticket ID`
2.  `Assignee name`
3.  `Ticket type`
4.  `Ticket priority`
5.  `Ticket channel`
6.  `SLA resolution time`
7.  `SLA breach status`
8.  `Full resolution time (min)`
9.  `MIN(Ticket created - Timestamp)`
10. `MIN(Ticket assigned - Timestamp)`
11. `MIN(First reply time - Timestamp)`
12. `MIN(Ticket solved - Timestamp)`
13. `MIN(Ticket reopened - Timestamp)`
14. `MIN(Satisfaction rating received - Timestamp)`
15. `MIN(Ticket closed - Timestamp)`
16. `MIN(Timestamp - Categorized and Prioritized)` (Custom calculated attribute)
17. `MIN(Timestamp - Info Requested)` (Custom calculated attribute)
18. `MIN(Timestamp - Customer Responded)` (Custom calculated attribute)
19. `MIN(Timestamp - Escalated)` (Custom calculated attribute)
20. `MIN(Timestamp - SLA Breach)` (Custom calculated attribute)

**Filters**:
1.  `Ticket created - Date`: Select a date range (e.g., last 180 days)

**Standard Calculated Attribute Formulas**:
*   `Timestamp - Categorized and Prioritized`: `IF ([Changes - Field name] = "priority" OR [Changes - Field name] = "type") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Info Requested`: `IF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Customer Responded`: `IF ([Changes - Field name] = "status" AND [Changes - Previous value] = "pending" AND [Changes - New value] = "open") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Escalated`: `IF ([Changes - Field name] = "group") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - SLA Breach`: `IF ([SLA breach status]=TRUE) THEN [SLA update - Timestamp] ENDIF`

Steps

Prepare Zendesk API Access: Log in to Zendesk as an administrator. Navigate to the Admin Center, then go to Apps and integrations > APIs > Zendesk API. Under the Settings tab, ensure Token Access is enabled. Click 'Add API token' to create a new token. Securely copy the generated token, as it will not be displayed again.
Set Up Python Environment: Ensure you have Python 3.6 or newer installed. Install the requests library, which is necessary for making HTTP requests to the Zendesk API. You can install it using the command line: pip install requests.
Configure the Python Script: Save the provided Python script to a file, such as extract_zendesk_log.py. Open the file in a text editor and update the placeholder variables at the top: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL, and API_TOKEN with your specific Zendesk instance details and credentials.
Define Extraction Period: Locate the START_TIMESTAMP variable within the script. This value determines the historical start date for the data extraction. It must be a Unix epoch timestamp. For an initial analysis, a value corresponding to the last 3 to 6 months is recommended.
Execute the Script: Open a terminal or command prompt, navigate to the directory where you saved the script, and run it using the command: python extract_zendesk_log.py.
Monitor Execution: The script will print progress updates to the console, indicating the number of tickets processed. The total execution time will depend on the volume of data being extracted and any API rate limiting imposed by Zendesk. The script includes basic logic to handle rate limit responses.
Retrieve the Event Log: Upon successful completion, the script will create a file named zendesk_event_log.csv in the same directory. This file contains the structured event log ready for analysis.
Prepare for Upload: Open the zendesk_event_log.csv file to ensure it was generated correctly. Verify that the columns match the required attributes: ServiceRequest, ActivityName, StartTime, SourceSystem, and LastDataUpdate. The file is now ready for upload into the process mining tool.

Configuration

API Credentials: The script requires a valid Zendesk subdomain, the email address of an agent or admin user, and an active API token. The user associated with the credentials must have permissions to read tickets, ticket audits, users, and ticket metrics.
Date Range: The extraction's start date is controlled by the START_TIMESTAMP variable in the script, which must be a Unix epoch timestamp. It is advisable to begin with a shorter period, such as 3 months, to validate the script's output and performance before attempting a larger historical data pull.
Incremental Export API: This solution uses Zendesk's Incremental Export API. This is the most efficient and recommended method for fetching a large number of tickets, as it is designed for bulk data export and avoids common pagination pitfalls.
Performance and Rate Limiting: Zendesk enforces API rate limits that vary based on the subscription plan. The script has built-in logic to pause execution when a rate limit is hit, based on the Retry-After header returned by the API. For very large instances, the extraction may take several hours.
Prerequisites: This extraction method requires a working Python 3.6+ environment and the requests external library. Administrator access to the target Zendesk instance is necessary to generate the required API token.

a Sample Query python

import requests
import json
import time
import datetime
import csv

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Zendesk details
ZENDESK_SUBDOMAIN = class="hl-string">'[your_zendesk_subdomain]'
ZENDESK_EMAIL = class="hl-string">'[your_zendesk_login_email]'
API_TOKEN = class="hl-string">'[your_zendesk_api_token]'

class=class="hl-string">"hl-comment"># Set the start time for the export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1672531200 is Jan 1, 2023 00:00:00 GMT
START_TIMESTAMP = 1672531200

class=class="hl-string">"hl-comment"># --- Script --- 

BASE_URL = fclass="hl-string">'https://{ZENDESK_SUBDOMAIN}.zendesk.com/api/v2'
AUTH = (fclass="hl-string">'{ZENDESK_EMAIL}/token', API_TOKEN)
SOURCE_SYSTEM = class="hl-string">'Zendesk Support'
LAST_DATA_UPDATE = datetime.datetime.utcnow().isoformat() + class="hl-string">'Z'

CSV_FILENAME = class="hl-string">'zendesk_event_log.csv'
CSV_HEADERS = [
    class="hl-string">'ServiceRequest', class="hl-string">'ActivityName', class="hl-string">'StartTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
    class="hl-string">'AssignedAgent', class="hl-string">'ServiceRequestType', class="hl-string">'Priority', class="hl-string">'CommunicationChannel',
    class="hl-string">'SlaTargetResolutionTime', class="hl-string">'IsSlaBreached', class="hl-string">'ServiceRequestResolutionTime'
]

def get_user_name(user_id, users_cache, session):
    if user_id in users_cache:
        return users_cache[user_id]
    if user_id is None:
        return None
    try:
        response = session.get(fclass="hl-string">'{BASE_URL}/users/{user_id}.json')
        response.raise_for_status()
        user_name = response.json().get(class="hl-string">'user', {}).get(class="hl-string">'name')
        users_cache[user_id] = user_name
        return user_name
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">'Warning: Could not fetch user {user_id}. Error: {e}')
        users_cache[user_id] = str(user_id)
        return str(user_id)

def format_duration(seconds):
    if seconds is None:
        return None
    return str(datetime.timedelta(seconds=seconds))

def main():
    session = requests.Session()
    session.auth = AUTH
    users_cache = {}
    event_log = []

    class=class="hl-string">"hl-comment"># Fetch tickets using the incremental export API
    url = fclass="hl-string">'{BASE_URL}/incremental/tickets/cursor.json?start_time={START_TIMESTAMP}'
    ticket_count = 0

    while url:
        print(fclass="hl-string">'Fetching tickets from: {url}')
        try:
            response = session.get(url)

            if response.status_code == 429:
                retry_after = int(response.headers.get(class="hl-string">'Retry-After', 60))
                print(fclass="hl-string">'Rate limit hit. Retrying after {retry_after} seconds.')
                time.sleep(retry_after)
                continue

            response.raise_for_status()
            data = response.json()
            tickets = data.get(class="hl-string">'tickets', [])

            for ticket in tickets:
                ticket_count += 1
                ticket_id = ticket[class="hl-string">'id']
                print(fclass="hl-string">'Processing ticket {ticket_id} ({ticket_count} total)...')

                class=class="hl-string">"hl-comment"># Fetch ticket metrics for SLA and resolution time
                metrics_response = session.get(fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/metrics.json')
                ticket_metrics = metrics_response.json().get(class="hl-string">'ticket_metric', {}) if metrics_response.ok else {}

                resolution_time_seconds = ticket_metrics.get(class="hl-string">'full_resolution_time_in_minutes', {}).get(class="hl-string">'business')
                if resolution_time_seconds:
                    resolution_time_seconds *= 60

                class=class="hl-string">"hl-comment"># Fetch ticket audits for events
                audits_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/audits.json'
                audits_response = session.get(audits_url)
                audits = audits_response.json().get(class="hl-string">'audits', []) if audits_response.ok else []

                first_agent_reply_sent = False

                for audit in audits:
                    audit_created_at = audit[class="hl-string">'created_at']
                    base_event = {
                        class="hl-string">'ServiceRequest': ticket_id,
                        class="hl-string">'StartTime': audit_created_at,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'AssignedAgent': get_user_name(ticket.get(class="hl-string">'assignee_id'), users_cache, session),
                        class="hl-string">'ServiceRequestType': ticket.get(class="hl-string">'type'),
                        class="hl-string">'Priority': ticket.get(class="hl-string">'priority'),
                        class="hl-string">'CommunicationChannel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
                        class="hl-string">'SlaTargetResolutionTime': None, class=class="hl-string">"hl-comment"># Requires parsing SLA policies, complex
                        class="hl-string">'IsSlaBreached': ticket_metrics.get(class="hl-string">'sla_breach_at') is not None,
                        class="hl-string">'ServiceRequestResolutionTime': format_duration(resolution_time_seconds)
                    }

                    for event in audit.get(class="hl-string">'events', []):
                        event_type = event.get(class="hl-string">'type')
                        class=class="hl-string">"hl-comment"># Service Request Created
                        if event_type == class="hl-string">'Create' and event.get(class="hl-string">'field_name') == class="hl-string">'id':
                            new_event = base_event.copy()
                            new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Created'
                            event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># Initial Acknowledgment Sent (Proxy by Notification event)
                        if event_type == class="hl-string">'Notification':
                            new_event = base_event.copy()
                            new_event[class="hl-string">'ActivityName'] = class="hl-string">'Initial Acknowledgment Sent'
                            event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># Request Categorized And Prioritized, Assigned, Status Changes
                        if event_type == class="hl-string">'Change':
                            field = event.get(class="hl-string">'field_name')
                            if field in [class="hl-string">'type', class="hl-string">'priority', class="hl-string">'custom_field_[your_category_field_id]']:
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Request Categorized And Prioritized'
                                event_log.append(new_event)
                            
                            if field == class="hl-string">'assignee_id':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Request Assigned To Agent'
                                new_event[class="hl-string">'AssignedAgent'] = get_user_name(event.get(class="hl-string">'value'), users_cache, session)
                                event_log.append(new_event)

                            if field == class="hl-string">'group_id':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Internal Escalation Triggered'
                                event_log.append(new_event)

                            if field == class="hl-string">'status':
                                new_status = event.get(class="hl-string">'value')
                                if new_status == class="hl-string">'pending':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Information Requested From Customer'
                                    event_log.append(new_event)
                                elif new_status == class="hl-string">'solved':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Resolved'
                                    event_log.append(new_event)
                                    class=class="hl-string">"hl-comment"># Satisfaction Survey Sent (Proxy: occurs after solve)
                                    solve_time = datetime.datetime.fromisoformat(audit_created_at.replace(class="hl-string">'Z', class="hl-string">'+00:00'))
                                    survey_time = solve_time + datetime.timedelta(hours=1)
                                    survey_event = new_event.copy()
                                    survey_event[class="hl-string">'ActivityName'] = class="hl-string">'Satisfaction Survey Sent'
                                    survey_event[class="hl-string">'StartTime'] = survey_time.isoformat().replace(class="hl-string">'+00:00', class="hl-string">'Z')
                                    event_log.append(survey_event)
                                elif new_status == class="hl-string">'closed':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Closed'
                                    event_log.append(new_event)
                                elif new_status == class="hl-string">'open' and event.get(class="hl-string">'previous_value') in [class="hl-string">'solved', class="hl-string">'pending']:
                                    activity = class="hl-string">'Service Request Reopened' if event.get(class="hl-string">'previous_value') == class="hl-string">'solved' else class="hl-string">'Customer Responded'
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = activity
                                    event_log.append(new_event)
                            
                            if field == class="hl-string">'satisfaction_score':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Satisfaction Rating Received'
                                event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># First Agent Public Reply Sent & Customer Responded
                        if event_type == class="hl-string">'Comment':
                            author_id = event.get(class="hl-string">'author_id')
                            author_details_response = session.get(fclass="hl-string">'{BASE_URL}/users/{author_id}.json')
                            author_role = author_details_response.json().get(class="hl-string">'user',{}).get(class="hl-string">'role', class="hl-string">'end-user') if author_details_response.ok else class="hl-string">'end-user'

                            if author_role in [class="hl-string">'agent', class="hl-string">'admin'] and event.get(class="hl-string">'public') and not first_agent_reply_sent:
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'First Agent Public Reply Sent'
                                event_log.append(new_event)
                                first_agent_reply_sent = True

                class=class="hl-string">"hl-comment"># SLA Breach Occurred
                if ticket_metrics.get(class="hl-string">'sla_breach_at'):
                    sla_breach_time = ticket_metrics.get(class="hl-string">'sla_breach_at')
                    new_event = base_event.copy()
                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'SLA Breach Occurred'
                    new_event[class="hl-string">'StartTime'] = sla_breach_time
                    event_log.append(new_event)

            url = data.get(class="hl-string">'after_url')
            if not data.get(class="hl-string">'end_of_stream', False):
                time.sleep(1) class=class="hl-string">"hl-comment"># Be a good API citizen
            else:
                url = None

        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">'An error occurred: {e}')
            break

    class=class="hl-string">"hl-comment"># Write to CSV
    print(fclass="hl-string">'Writing {len(event_log)} events to {CSV_FILENAME}...')
    with open(CSV_FILENAME, class="hl-string">'w', newline=class="hl-string">'', encoding=class="hl-string">'utf-8') as csvfile:
        writer = csv.DictWriter(csvfile, fieldnames=CSV_HEADERS)
        writer.writeheader()
        class=class="hl-string">"hl-comment"># Sort events by ticket and then by time for chronological order
        sorted_log = sorted(event_log, key=lambda x: (x[class="hl-string">'ServiceRequest'], x[class="hl-string">'StartTime']))
        for row in sorted_log:
            writer.writerow(row)
    print(class="hl-string">'Extraction complete.')

if __name__ == class="hl-string">'__main__':
    main()

Steps

Prepare Zendesk API Access: Log in to Zendesk as an administrator. Navigate to the Admin Center, then go to Apps and integrations > APIs > Zendesk API. Under the Settings tab, ensure Token Access is enabled. Click 'Add API token' to create a new token. Securely copy the generated token, as it will not be displayed again.
Set Up Python Environment: Ensure you have Python 3.6 or newer installed. Install the requests library, which is necessary for making HTTP requests to the Zendesk API. You can install it using the command line: pip install requests.
Configure the Python Script: Save the provided Python script to a file, such as extract_zendesk_log.py. Open the file in a text editor and update the placeholder variables at the top: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL, and API_TOKEN with your specific Zendesk instance details and credentials.
Define Extraction Period: Locate the START_TIMESTAMP variable within the script. This value determines the historical start date for the data extraction. It must be a Unix epoch timestamp. For an initial analysis, a value corresponding to the last 3 to 6 months is recommended.
Execute the Script: Open a terminal or command prompt, navigate to the directory where you saved the script, and run it using the command: python extract_zendesk_log.py.
Monitor Execution: The script will print progress updates to the console, indicating the number of tickets processed. The total execution time will depend on the volume of data being extracted and any API rate limiting imposed by Zendesk. The script includes basic logic to handle rate limit responses.
Retrieve the Event Log: Upon successful completion, the script will create a file named zendesk_event_log.csv in the same directory. This file contains the structured event log ready for analysis.
Prepare for Upload: Open the zendesk_event_log.csv file to ensure it was generated correctly. Verify that the columns match the required attributes: ServiceRequest, ActivityName, StartTime, SourceSystem, and LastDataUpdate. The file is now ready for upload into the process mining tool.

Configuration

API Credentials: The script requires a valid Zendesk subdomain, the email address of an agent or admin user, and an active API token. The user associated with the credentials must have permissions to read tickets, ticket audits, users, and ticket metrics.
Date Range: The extraction's start date is controlled by the START_TIMESTAMP variable in the script, which must be a Unix epoch timestamp. It is advisable to begin with a shorter period, such as 3 months, to validate the script's output and performance before attempting a larger historical data pull.
Incremental Export API: This solution uses Zendesk's Incremental Export API. This is the most efficient and recommended method for fetching a large number of tickets, as it is designed for bulk data export and avoids common pagination pitfalls.
Performance and Rate Limiting: Zendesk enforces API rate limits that vary based on the subscription plan. The script has built-in logic to pause execution when a rate limit is hit, based on the Retry-After header returned by the API. For very large instances, the extraction may take several hours.
Prerequisites: This extraction method requires a working Python 3.6+ environment and the requests external library. Administrator access to the target Zendesk instance is necessary to generate the required API token.

a Sample Query python

import requests
import json
import time
import datetime
import csv

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Zendesk details
ZENDESK_SUBDOMAIN = class="hl-string">'[your_zendesk_subdomain]'
ZENDESK_EMAIL = class="hl-string">'[your_zendesk_login_email]'
API_TOKEN = class="hl-string">'[your_zendesk_api_token]'

class=class="hl-string">"hl-comment"># Set the start time for the export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1672531200 is Jan 1, 2023 00:00:00 GMT
START_TIMESTAMP = 1672531200

class=class="hl-string">"hl-comment"># --- Script --- 

BASE_URL = fclass="hl-string">'https://{ZENDESK_SUBDOMAIN}.zendesk.com/api/v2'
AUTH = (fclass="hl-string">'{ZENDESK_EMAIL}/token', API_TOKEN)
SOURCE_SYSTEM = class="hl-string">'Zendesk Support'
LAST_DATA_UPDATE = datetime.datetime.utcnow().isoformat() + class="hl-string">'Z'

CSV_FILENAME = class="hl-string">'zendesk_event_log.csv'
CSV_HEADERS = [
    class="hl-string">'ServiceRequest', class="hl-string">'ActivityName', class="hl-string">'StartTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
    class="hl-string">'AssignedAgent', class="hl-string">'ServiceRequestType', class="hl-string">'Priority', class="hl-string">'CommunicationChannel',
    class="hl-string">'SlaTargetResolutionTime', class="hl-string">'IsSlaBreached', class="hl-string">'ServiceRequestResolutionTime'
]

def get_user_name(user_id, users_cache, session):
    if user_id in users_cache:
        return users_cache[user_id]
    if user_id is None:
        return None
    try:
        response = session.get(fclass="hl-string">'{BASE_URL}/users/{user_id}.json')
        response.raise_for_status()
        user_name = response.json().get(class="hl-string">'user', {}).get(class="hl-string">'name')
        users_cache[user_id] = user_name
        return user_name
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">'Warning: Could not fetch user {user_id}. Error: {e}')
        users_cache[user_id] = str(user_id)
        return str(user_id)

def format_duration(seconds):
    if seconds is None:
        return None
    return str(datetime.timedelta(seconds=seconds))

def main():
    session = requests.Session()
    session.auth = AUTH
    users_cache = {}
    event_log = []

    class=class="hl-string">"hl-comment"># Fetch tickets using the incremental export API
    url = fclass="hl-string">'{BASE_URL}/incremental/tickets/cursor.json?start_time={START_TIMESTAMP}'
    ticket_count = 0

    while url:
        print(fclass="hl-string">'Fetching tickets from: {url}')
        try:
            response = session.get(url)

            if response.status_code == 429:
                retry_after = int(response.headers.get(class="hl-string">'Retry-After', 60))
                print(fclass="hl-string">'Rate limit hit. Retrying after {retry_after} seconds.')
                time.sleep(retry_after)
                continue

            response.raise_for_status()
            data = response.json()
            tickets = data.get(class="hl-string">'tickets', [])

            for ticket in tickets:
                ticket_count += 1
                ticket_id = ticket[class="hl-string">'id']
                print(fclass="hl-string">'Processing ticket {ticket_id} ({ticket_count} total)...')

                class=class="hl-string">"hl-comment"># Fetch ticket metrics for SLA and resolution time
                metrics_response = session.get(fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/metrics.json')
                ticket_metrics = metrics_response.json().get(class="hl-string">'ticket_metric', {}) if metrics_response.ok else {}

                resolution_time_seconds = ticket_metrics.get(class="hl-string">'full_resolution_time_in_minutes', {}).get(class="hl-string">'business')
                if resolution_time_seconds:
                    resolution_time_seconds *= 60

                class=class="hl-string">"hl-comment"># Fetch ticket audits for events
                audits_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/audits.json'
                audits_response = session.get(audits_url)
                audits = audits_response.json().get(class="hl-string">'audits', []) if audits_response.ok else []

                first_agent_reply_sent = False

                for audit in audits:
                    audit_created_at = audit[class="hl-string">'created_at']
                    base_event = {
                        class="hl-string">'ServiceRequest': ticket_id,
                        class="hl-string">'StartTime': audit_created_at,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'AssignedAgent': get_user_name(ticket.get(class="hl-string">'assignee_id'), users_cache, session),
                        class="hl-string">'ServiceRequestType': ticket.get(class="hl-string">'type'),
                        class="hl-string">'Priority': ticket.get(class="hl-string">'priority'),
                        class="hl-string">'CommunicationChannel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
                        class="hl-string">'SlaTargetResolutionTime': None, class=class="hl-string">"hl-comment"># Requires parsing SLA policies, complex
                        class="hl-string">'IsSlaBreached': ticket_metrics.get(class="hl-string">'sla_breach_at') is not None,
                        class="hl-string">'ServiceRequestResolutionTime': format_duration(resolution_time_seconds)
                    }

                    for event in audit.get(class="hl-string">'events', []):
                        event_type = event.get(class="hl-string">'type')
                        class=class="hl-string">"hl-comment"># Service Request Created
                        if event_type == class="hl-string">'Create' and event.get(class="hl-string">'field_name') == class="hl-string">'id':
                            new_event = base_event.copy()
                            new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Created'
                            event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># Initial Acknowledgment Sent (Proxy by Notification event)
                        if event_type == class="hl-string">'Notification':
                            new_event = base_event.copy()
                            new_event[class="hl-string">'ActivityName'] = class="hl-string">'Initial Acknowledgment Sent'
                            event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># Request Categorized And Prioritized, Assigned, Status Changes
                        if event_type == class="hl-string">'Change':
                            field = event.get(class="hl-string">'field_name')
                            if field in [class="hl-string">'type', class="hl-string">'priority', class="hl-string">'custom_field_[your_category_field_id]']:
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Request Categorized And Prioritized'
                                event_log.append(new_event)
                            
                            if field == class="hl-string">'assignee_id':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Request Assigned To Agent'
                                new_event[class="hl-string">'AssignedAgent'] = get_user_name(event.get(class="hl-string">'value'), users_cache, session)
                                event_log.append(new_event)

                            if field == class="hl-string">'group_id':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Internal Escalation Triggered'
                                event_log.append(new_event)

                            if field == class="hl-string">'status':
                                new_status = event.get(class="hl-string">'value')
                                if new_status == class="hl-string">'pending':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Information Requested From Customer'
                                    event_log.append(new_event)
                                elif new_status == class="hl-string">'solved':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Resolved'
                                    event_log.append(new_event)
                                    class=class="hl-string">"hl-comment"># Satisfaction Survey Sent (Proxy: occurs after solve)
                                    solve_time = datetime.datetime.fromisoformat(audit_created_at.replace(class="hl-string">'Z', class="hl-string">'+00:00'))
                                    survey_time = solve_time + datetime.timedelta(hours=1)
                                    survey_event = new_event.copy()
                                    survey_event[class="hl-string">'ActivityName'] = class="hl-string">'Satisfaction Survey Sent'
                                    survey_event[class="hl-string">'StartTime'] = survey_time.isoformat().replace(class="hl-string">'+00:00', class="hl-string">'Z')
                                    event_log.append(survey_event)
                                elif new_status == class="hl-string">'closed':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Closed'
                                    event_log.append(new_event)
                                elif new_status == class="hl-string">'open' and event.get(class="hl-string">'previous_value') in [class="hl-string">'solved', class="hl-string">'pending']:
                                    activity = class="hl-string">'Service Request Reopened' if event.get(class="hl-string">'previous_value') == class="hl-string">'solved' else class="hl-string">'Customer Responded'
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = activity
                                    event_log.append(new_event)
                            
                            if field == class="hl-string">'satisfaction_score':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Satisfaction Rating Received'
                                event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># First Agent Public Reply Sent & Customer Responded
                        if event_type == class="hl-string">'Comment':
                            author_id = event.get(class="hl-string">'author_id')
                            author_details_response = session.get(fclass="hl-string">'{BASE_URL}/users/{author_id}.json')
                            author_role = author_details_response.json().get(class="hl-string">'user',{}).get(class="hl-string">'role', class="hl-string">'end-user') if author_details_response.ok else class="hl-string">'end-user'

                            if author_role in [class="hl-string">'agent', class="hl-string">'admin'] and event.get(class="hl-string">'public') and not first_agent_reply_sent:
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'First Agent Public Reply Sent'
                                event_log.append(new_event)
                                first_agent_reply_sent = True

                class=class="hl-string">"hl-comment"># SLA Breach Occurred
                if ticket_metrics.get(class="hl-string">'sla_breach_at'):
                    sla_breach_time = ticket_metrics.get(class="hl-string">'sla_breach_at')
                    new_event = base_event.copy()
                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'SLA Breach Occurred'
                    new_event[class="hl-string">'StartTime'] = sla_breach_time
                    event_log.append(new_event)

            url = data.get(class="hl-string">'after_url')
            if not data.get(class="hl-string">'end_of_stream', False):
                time.sleep(1) class=class="hl-string">"hl-comment"># Be a good API citizen
            else:
                url = None

        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">'An error occurred: {e}')
            break

    class=class="hl-string">"hl-comment"># Write to CSV
    print(fclass="hl-string">'Writing {len(event_log)} events to {CSV_FILENAME}...')
    with open(CSV_FILENAME, class="hl-string">'w', newline=class="hl-string">'', encoding=class="hl-string">'utf-8') as csvfile:
        writer = csv.DictWriter(csvfile, fieldnames=CSV_HEADERS)
        writer.writeheader()
        class=class="hl-string">"hl-comment"># Sort events by ticket and then by time for chronological order
        sorted_log = sorted(event_log, key=lambda x: (x[class="hl-string">'ServiceRequest'], x[class="hl-string">'StartTime']))
        for row in sorted_log:
            writer.writerow(row)
    print(class="hl-string">'Extraction complete.')

if __name__ == class="hl-string">'__main__':
    main()

Steps

Navigate to Zendesk Explore: Log in to your Zendesk instance and open the Explore product by clicking the product launcher icon in the top bar and selecting Explore.
Create a New Query: In Explore, click the Queries icon on the left sidebar, then click the "New query" button on the top right.
Select the Dataset: In the "Choose a dataset" window, select the Support: Tickets dataset. This dataset contains the primary ticket attributes and key event timestamps.
Add Metrics: In the query builder, go to the "Metrics" panel and click "Add". Select COUNT(Tickets). This helps in validating the data volume.
Add Attributes to Rows: Go to the "Rows" panel and click "Add". Add the following attributes. These will form the base columns of your wide-format export.
- Ticket ID (This is your Case Identifier, ServiceRequest)
- Assignee name (AssignedAgent)
- Ticket type (ServiceRequestType)
- Ticket priority (Priority)
- Ticket channel (CommunicationChannel)
- SLA resolution time (SlaTargetResolutionTime)
- SLA breach status (IsSlaBreached)
- Full resolution time (min) (ServiceRequestResolutionTime)
Add Activity Timestamps to Rows: Add the following timestamp attributes to the "Rows" panel. Each of these represents a potential activity. Some activities require creating a custom calculated attribute.
- Ticket created - Timestamp: For Service Request Created and Initial Acknowledgment Sent.
- Ticket assigned - Timestamp: For Request Assigned To Agent.
- First reply time - Timestamp: For First Agent Public Reply Sent.
- Ticket solved - Timestamp: For Service Request Resolved and Satisfaction Survey Sent.
- Ticket reopened - Timestamp: For Service Request Reopened.
- Satisfaction rating received - Timestamp: For Satisfaction Rating Received.
- Ticket closed - Timestamp: For Service Request Closed.
Create Custom Calculated Attributes for Other Activities: Some activities are based on specific field changes and require creating custom attributes to capture their timestamp. Go to the Calculations menu (calculator icon) and select "Standard calculated attribute". Create one attribute for each of the following activities. You will need to find the exact names for fields and values in your Zendesk instance.
- Name: Timestamp - Categorized and Prioritized. Formula: IF ([Changes - Field name] = "priority" OR [Changes - Field name] = "type") THEN [Update - Timestamp] ENDIF. After creating it, add this new attribute to the "Rows" panel and change its aggregator to MIN.
- Name: Timestamp - Info Requested. Formula: IF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN [Update - Timestamp] ENDIF. Add it to "Rows" and set aggregator to MIN.
- Name: Timestamp - Customer Responded. Formula: IF ([Changes - Field name] = "status" AND [Changes - Previous value] = "pending" AND [Changes - New value] = "open") THEN [Update - Timestamp] ENDIF. Add it to "Rows" and set aggregator to MIN.
- Name: Timestamp - Escalated. Formula: IF ([Changes - Field name] = "group") THEN [Update - Timestamp] ENDIF. Add it to "Rows" and set aggregator to MIN.
- Name: Timestamp - SLA Breach. Formula: IF ([SLA breach status]=TRUE) THEN [SLA update - Timestamp] ENDIF. Add it to "Rows" and set aggregator to MIN.
Filter the Data: Go to the "Filters" panel and click "Add". Add a filter for Ticket created - Date and select an appropriate date range, such as the last 3 to 6 months, to keep the dataset manageable.
Run and Export the Report: Click "Save" to run the query. Once the table displays the data, click the "Export" button and choose your preferred format, such as CSV or Excel.
Transform Data to Event Log Format: The exported file is in a "wide" format where each row is a ticket and each column is an event timestamp. You must transform this into a "long" format for process mining. Use a tool like Microsoft Excel (with Power Query's Unpivot feature), Python, or another data preparation tool.
- For each row (ticket), create multiple new rows, one for each non-empty timestamp column.
- The final table should have columns like ServiceRequest, ActivityName, StartTime, and the other attributes, which will be duplicated for each activity of a given service request.

Configuration

Dataset: The primary dataset to use is Support: Tickets. This allows access to most ticket properties and key timestamps in a single query.
Permissions: You need at least an Editor or Admin role in Zendesk Explore to create and save queries.
Date Range: It is crucial to set a date range filter on Ticket created - Date. A range of 3 to 6 months of data is recommended to balance insight with performance. Exporting millions of tickets can be slow or may fail.
Query Filters: Consider adding filters for specific ticket properties like Ticket brand, Ticket form, or Ticket group to focus the analysis on a particular service or team.
Calculated Attributes: This method relies heavily on creating standard calculated attributes to capture timestamps for events that are not default attributes, such as status changes or escalations. Ensure you have the permissions to create these attributes.

a Sample Query config

This extraction is configured through the Zendesk Explore graphical user interface. There is no single script to execute. The configuration below outlines the components to add in the query builder.

**Dataset**: `Support: Tickets`

**Metrics**:
1.  `COUNT(Tickets)`

**Rows (Attributes)**:
1.  `Ticket ID`
2.  `Assignee name`
3.  `Ticket type`
4.  `Ticket priority`
5.  `Ticket channel`
6.  `SLA resolution time`
7.  `SLA breach status`
8.  `Full resolution time (min)`
9.  `MIN(Ticket created - Timestamp)`
10. `MIN(Ticket assigned - Timestamp)`
11. `MIN(First reply time - Timestamp)`
12. `MIN(Ticket solved - Timestamp)`
13. `MIN(Ticket reopened - Timestamp)`
14. `MIN(Satisfaction rating received - Timestamp)`
15. `MIN(Ticket closed - Timestamp)`
16. `MIN(Timestamp - Categorized and Prioritized)` (Custom calculated attribute)
17. `MIN(Timestamp - Info Requested)` (Custom calculated attribute)
18. `MIN(Timestamp - Customer Responded)` (Custom calculated attribute)
19. `MIN(Timestamp - Escalated)` (Custom calculated attribute)
20. `MIN(Timestamp - SLA Breach)` (Custom calculated attribute)

**Filters**:
1.  `Ticket created - Date`: Select a date range (e.g., last 180 days)

**Standard Calculated Attribute Formulas**:
*   `Timestamp - Categorized and Prioritized`: `IF ([Changes - Field name] = "priority" OR [Changes - Field name] = "type") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Info Requested`: `IF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Customer Responded`: `IF ([Changes - Field name] = "status" AND [Changes - Previous value] = "pending" AND [Changes - New value] = "open") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Escalated`: `IF ([Changes - Field name] = "group") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - SLA Breach`: `IF ([SLA breach status]=TRUE) THEN [SLA update - Timestamp] ENDIF`

Your Customer Service Data Template

Your Customer Service Data Template

Customer Service Attributes

Customer Service Activities

Extraction Guides

Zendesk Explore UI for Report and Data Export

Steps

Configuration

a Sample Query config

Python Script using Zendesk Support REST API

Steps

Configuration

a Sample Query python

Zendesk Incremental Exports API for Bulk Data

Steps

Configuration

a Sample Query python

Third-Party ETL Tool Connector for Zendesk

Steps

Configuration

a Sample Query config

Ready to Get Started?

End Customer Service Bottlenecks, Boost CSAT Now

Your Customer Service Data Template

Your Customer Service Data Template

Customer Service Attributes

Customer Service Activities

Extraction Guides

Zendesk Explore UI for Report and Data Export

Steps

Configuration

a Sample Query config

Python Script using Zendesk Support REST API

Steps

Configuration

a Sample Query python

Zendesk Incremental Exports API for Bulk Data

Steps

Configuration

a Sample Query python

Third-Party ETL Tool Connector for Zendesk

Steps

Configuration

a Sample Query config

We value your privacy

Ready to Get Started?

End Customer Service Bottlenecks, Boost CSAT Now