Your Customer Service Data Template
Your Customer Service Data Template
- Recommended attributes to collect
- Key activities to track
- Extraction guidance
Customer Service Attributes
| Name | Description | ||
|---|---|---|---|
|
Activity Name
ActivityName
|
The name of the specific event or task that occurred at a point in time within the service request lifecycle. | ||
|
Description
This attribute describes a specific step or status change within the customer service process. Each activity represents a distinct event, such as 'Agent Accepted Interaction' or 'Wrap-Up Code Assigned'. Analyzing the sequence and frequency of these activities is fundamental to process mining. It helps visualize process flows, identify deviations, and pinpoint bottlenecks or inefficient steps.
Why it matters
Activities form the backbone of the process map, allowing for the visualization and analysis of the actual process flow against the designed flow.
Where to get
This is typically derived by mapping system events, agent states, or specific audit trail entries in Genesys Cloud CX to standardized activity names.
Examples
Interaction StartedAgent Accepted InteractionAfter-Call Work EndedService Request Re-Opened
|
|||
|
Service Request
ServiceRequest
|
The primary identifier for a customer service interaction, linking all related activities. | ||
|
Description
The Service Request, often referred to as a Ticket or Case, serves as the primary identifier for a single customer inquiry or issue. It groups all related events, from initial contact to final resolution, into a single process instance. Analyzing by Service Request allows for a complete, end-to-end view of the customer journey and the internal handling process. It is the foundation for calculating key metrics like total resolution time and first contact resolution rate.
Why it matters
This is the essential Case ID that connects all process steps, enabling a holistic analysis of each customer interaction from start to finish.
Where to get
This is the conceptual case identifier. In Genesys, this often corresponds to the Conversation ID, but may be a custom identifier depending on the implementation.
Examples
SR-20240521-00123SR-20240521-00124SR-20240522-00001
|
|||
|
Start Time
EventTime
|
The timestamp indicating when an activity or event started. | ||
|
Description
This attribute provides the precise date and time for when each activity occurred. It is essential for sequencing events correctly and for all time-based analysis. The Start Time is used to construct the process flow in chronological order and is the basis for calculating durations, wait times, and cycle times between different activities. Accurate timestamps are critical for reliable process analysis and performance monitoring.
Why it matters
This timestamp orders all activities chronologically, making it possible to analyze process flows, durations, and bottlenecks accurately.
Where to get
Found in event logs or interaction details in Genesys Cloud CX, often associated with every recorded system or user event.
Examples
2024-05-21T10:00:15Z2024-05-21T10:02:30Z2024-05-21T10:15:00Z
|
|||
|
Last Data Update
LastDataUpdate
|
The timestamp of the most recent data refresh. | ||
|
Description
This attribute indicates the last time the dataset was updated from the source system. It provides context on the freshness of the data being analyzed, which is critical for making timely and relevant business decisions. Dashboards and reports should display this information prominently so that users are aware of the data's currency and can assess the validity of the insights.
Why it matters
Indicates data freshness, ensuring that analyses and decisions are based on up-to-date information.
Where to get
This value is generated and stamped onto the dataset at the time of data extraction or loading into the process mining tool.
Examples
2024-05-23T04:00:00Z2024-05-24T04:00:00Z
|
|||
|
Source System
SourceSystem
|
The system from which the data was extracted. | ||
|
Description
This attribute identifies the originating system for the event data, which in this case is Genesys Cloud CX. In environments with multiple integrated systems, this field is crucial for data lineage, troubleshooting, and understanding the context of the data. It helps ensure that analysis is based on the correct data source and allows for filtering or segmenting data when multiple systems contribute to a single process view.
Why it matters
Identifies the data's origin, which is crucial for data governance, validation, and when merging data from multiple systems.
Where to get
This is typically a static value added during the data extraction and transformation process to label the origin of the records.
Examples
Genesys Cloud CXGenesysCloudCX_US1Genesys
|
|||
|
Agent ID
AgentId
|
The unique identifier for the agent who handled the interaction or activity. | ||
|
Description
The Agent ID is a unique key for each customer service representative. This attribute is essential for any analysis related to agent performance, workload distribution, and efficiency. It allows for filtering the process map to see how specific agents or teams handle requests, comparing their performance metrics like resolution time, rework rate, and adherence to standard procedures. This is a cornerstone for the 'Agent Performance & Efficiency' dashboard.
Why it matters
This attribute connects process activities to specific employees, enabling analysis of individual performance, workload, and team efficiency.
Where to get
Available in Genesys Cloud CX conversation detail records, associated with the user who handled a specific segment of the interaction.
Examples
a1b2c3d4-e5f6-7890-1234-567890abcdeff0e9d8c7-b6a5-4321-fedc-ba0987654321
|
|||
|
Agent Name
AgentName
|
The full name of the agent who handled the interaction or activity. | ||
|
Description
The Agent Name provides a human-readable identifier for the service representative, corresponding to the Agent ID. This attribute makes dashboards and reports more intuitive for managers and team leads. It is used extensively in agent-centric analyses to review performance, identify training needs, and ensure fair workload distribution without needing to cross-reference system IDs.
Why it matters
Provides a user-friendly name for the agent, making it easier to analyze performance and communicate findings without using technical IDs.
Where to get
Retrieved from the Users or Directory service in Genesys Cloud CX by looking up the AgentId.
Examples
John SmithJane DoePeter Jones
|
|||
|
Communication Channel
MediaType
|
The communication channel used for the interaction, such as voice, chat, or email. | ||
|
Description
This attribute specifies the medium through which the customer and agent communicated. Common channels include voice, chat, email, and social media. Analyzing performance by channel, as done in the 'Communication Channel Performance' dashboard, helps businesses understand channel-specific volumes, resolution times, and customer satisfaction. This insight is critical for optimizing channel strategy and resource allocation.
Why it matters
Segmenting the process by communication channel is crucial for understanding channel-specific performance, customer behavior, and resource needs.
Where to get
A standard field within Genesys Cloud CX conversation detail records.
Examples
voicechatemailmessage
|
|||
|
End Time
EventEndTime
|
The timestamp indicating when an activity or event ended. | ||
|
Description
This attribute records the precise moment an activity concludes. Paired with the Start Time, it enables the exact calculation of the duration for each individual activity. Analyzing activity durations is key to identifying which steps in the process consume the most time, helping to locate inefficiencies and opportunities for optimization. For example, it can highlight long 'Hold Placed on Interaction' times or extended 'After-Call Work' durations.
Why it matters
Enables the precise calculation of individual activity durations, which is essential for identifying time-consuming steps and performance bottlenecks.
Where to get
Found in event logs or interaction details in Genesys Cloud CX. It can also be derived from the start time of the subsequent event.
Examples
2024-05-21T10:02:30Z2024-05-21T10:15:00Z2024-05-21T10:18:45Z
|
|||
|
Queue Name
QueueName
|
The name of the queue to which the interaction was routed. | ||
|
Description
This attribute identifies the specific queue that an interaction waited in before being assigned to an agent. Analyzing data by Queue Name is essential for the 'Service Queue Bottleneck Detection' dashboard. It helps managers understand workload distribution across different skill groups or service lines, measure wait times per queue, and identify queues that are consistently understaffed or overloaded. This information is key to optimizing resource allocation and improving customer wait times.
Why it matters
Helps identify bottlenecks and analyze workload distribution by showing where service requests are waiting for assignment.
Where to get
Available in Genesys Cloud CX conversation detail records. Each interaction can pass through one or more queues.
Examples
Tier 1 Support - VoiceBilling Inquiries - ChatTechnical Support - Email
|
|||
|
Wrap-Up Code
WrapUpCode
|
A code assigned by an agent at the end of an interaction to categorize its outcome or topic. | ||
|
Description
The Wrap-Up Code is a label selected by an agent to classify the nature or resolution of a customer interaction. These codes provide structured data about why customers are contacting support. Analyzing Wrap-Up Codes helps identify common issue types, track resolution outcomes, and measure the frequency of specific requests. This data is valuable for root cause analysis and understanding service demand patterns.
Why it matters
Categorizes the outcome of an interaction, providing structured data for analyzing common issues, resolution effectiveness, and contact reasons.
Where to get
Available in Genesys Cloud CX conversation detail records, specifically in the session details for agent participants.
Examples
Password ResetBilling Dispute ResolvedProduct Information RequestEscalated to Tier 2
|
|||
|
Conversation ID
ConversationId
|
The unique identifier assigned by Genesys to an entire conversation. | ||
|
Description
The Conversation ID is the primary technical key in Genesys Cloud CX that groups all related interactions, segments, and participants for a single customer conversation. While the conceptual 'Service Request' is used as the Case ID, the Conversation ID is the underlying key used to retrieve all related data from the Genesys APIs. It is essential for data extraction, joining different data sets, and for technical validation of the process data.
Why it matters
This is the primary technical key in Genesys, essential for data extraction, troubleshooting, and linking back to the source system.
Where to get
This is a primary field in all Genesys Cloud CX analytics and conversation APIs.
Examples
d8a7c6b5-e4f3-2109-8765-fedcba098765c7b6a5d4-f3e2-1098-7654-edcbaf987654
|
|||
|
CSAT Score
CustomerSatisfactionScore
|
The satisfaction score provided by the customer in a post-interaction survey. | ||
|
Description
The Customer Satisfaction Score, or CSAT, is a direct measure of the customer's perception of the service they received. It is typically collected via a survey sent after the interaction is closed. Analyzing CSAT scores in conjunction with process data can reveal how process variations, resolution times, or specific agents impact customer happiness. This is a key outcome metric for evaluating overall process success.
Why it matters
Directly measures customer happiness, allowing for correlation analysis between process performance and customer outcomes.
Where to get
This data usually comes from the Genesys Cloud CX Quality Management module or a third-party survey tool integrated with Genesys.
Examples
5413
|
|||
|
Is First Contact Resolution
IsFirstContactResolution
|
A flag indicating if the service request was resolved within a single interaction. | ||
|
Description
This boolean attribute identifies cases that were resolved during the first interaction, without requiring any follow-up from the customer or internal transfers. A 'true' value signifies an ideal, efficient resolution. This attribute is the basis for the 'First Contact Resolution Rate' KPI and its corresponding dashboard. Analyzing the characteristics of cases that are not resolved on first contact can reveal opportunities for agent training, knowledge base improvements, or process changes.
Why it matters
Directly measures efficiency and customer satisfaction, as resolving issues on the first try is a key driver of a positive service experience.
Where to get
Calculated field, derived by analyzing the event sequence for a case. A case is FCR if it is resolved without certain intervening activities like transfers or re-opens.
Examples
truefalse
|
|||
|
Is Reopened
IsReopened
|
A flag indicating if a resolved service request was later re-opened. | ||
|
Description
This boolean attribute flags service requests that were set to a resolved or closed state but later became active again. Re-opened cases often indicate that the initial solution was not effective or complete, leading to customer dissatisfaction and additional work. This attribute powers the 'Service Request Re-opening Trends' dashboard and the 'Service Request Re-opening Rate' KPI. Analyzing these cases helps identify the root causes of ineffective resolutions.
Why it matters
Highlights failures in the resolution process, pointing to issues with solution quality and leading to rework and poor customer experience.
Where to get
Calculated field, derived by detecting an activity that re-activates the case after a 'Service Request Resolved' activity has occurred.
Examples
truefalse
|
|||
|
Is SLA Compliant
IsSlaCompliant
|
A flag indicating whether the service request was resolved within its SLA target time. | ||
|
Description
This boolean attribute indicates if a service request met its resolution time target. It is calculated by comparing the 'ServiceResolutionTime' to the 'SlaTargetResolutionTime'. This flag simplifies analysis and visualization for the 'SLA Compliance Overview' dashboard and is the basis for calculating the 'SLA Compliance Rate' KPI. It allows for quick filtering and segmentation of compliant versus non-compliant cases to identify common patterns in SLA breaches.
Why it matters
Simplifies SLA performance analysis by clearly flagging each case as compliant or breached, enabling root cause analysis of failures.
Where to get
Calculated field: True if ServiceResolutionTime <= SlaTargetResolutionTime, otherwise False.
Examples
truefalse
|
|||
|
Processing Time
Duration
|
The time taken to complete a single activity, measured in seconds. | ||
|
Description
This attribute quantifies the duration of an individual process step, calculated as the difference between its End Time and Start Time. Analyzing processing time helps identify which activities are the most time-consuming. This information is vital for performance dashboards, such as the 'Agent Performance & Efficiency' dashboard, to assess agent efficiency and find opportunities for training or process improvements.
Why it matters
Quantifies the time spent on each activity, helping to pinpoint inefficiencies and measure performance at a granular level.
Where to get
Calculated field: EventEndTime - EventTime. Some Genesys APIs may provide duration fields directly for certain segments.
Examples
12075045
|
|||
|
Service Request Type
ServiceRequestType
|
The classification of the service request, such as 'Inquiry', 'Complaint', or 'Technical Issue'. | ||
|
Description
This attribute categorizes the service request based on its nature or purpose. It allows for segmenting the analysis to understand how different types of requests are handled. For example, the process flow and resolution time for a 'Complaint' may differ significantly from a 'General Inquiry'. This dimension is vital for dashboards like 'Internal Escalation Analysis' to see if certain request types are escalated more often.
Why it matters
Allows for process segmentation to compare how different types of requests are handled and identify type-specific bottlenecks or inefficiencies.
Where to get
This information might be captured via an IVR selection, a customer's choice on a web form, or assigned by an agent. In Genesys, it can be stored as a participant attribute or a wrap-up code.
Examples
Billing InquiryTechnical SupportAccount ManagementProduct Complaint
|
|||
|
Service Resolution Time
ServiceResolutionTime
|
The total time elapsed from the start of the first customer interaction to the final resolution. | ||
|
Description
This metric measures the total duration of a service request, from the moment the customer initiates contact until the issue is marked as resolved. It is a key performance indicator for overall process efficiency and customer experience. This calculated attribute is the primary focus of the 'Service Request Resolution Time' dashboard and the 'Average Service Resolution Time' KPI. Analyzing its distribution helps identify long-running cases and systemic delays.
Why it matters
This is a critical KPI for measuring overall process efficiency and its impact on the customer experience.
Where to get
Calculated field: Timestamp of the final resolution activity minus the timestamp of the first customer contact activity.
Examples
90010800172800
|
|||
|
SLA Target Resolution Time
SlaTargetResolutionTime
|
The contractually agreed upon target time for resolving the service request. | ||
|
Description
This attribute defines the maximum time allowed for a service request to be resolved, according to the Service Level Agreement (SLA). It serves as the benchmark against which actual resolution times are measured. This data is essential for the 'SLA Compliance Overview' dashboard and the 'SLA Compliance Rate' KPI, enabling the organization to monitor its performance against customer commitments and identify potential breaches before they happen.
Why it matters
Provides the benchmark for measuring SLA compliance, a critical indicator of service performance and contractual obligation.
Where to get
This may be stored as a custom attribute on the conversation or derived based on rules involving the queue, customer type, or request type.
Examples
86400144003600
|
|||
Customer Service Activities
| Activity | Description | ||
|---|---|---|---|
|
Agent Accepted Interaction
|
Marks the point where an agent accepts the offered interaction and is connected to the customer. This is a key milestone where the direct handling of the service request begins. | ||
|
Why it matters
This activity is crucial for measuring First Contact Resolution and agent handle time. It signifies the start of the agent's work on the request.
Where to get
Available in the conversation detail records. It is marked by the agent participant's state changing to 'connected', with an associated timestamp.
Capture
Logged when an agent participant's state changes to 'connected'.
Event type
explicit
|
|||
|
Interaction Disconnected
|
This activity signifies the end of the conversation, when all participants have disconnected. This often serves as the technical closure of the service request interaction. | ||
|
Why it matters
This is a definitive end event for the interaction itself. It is crucial for calculating total interaction duration and is often used as a proxy for request closure.
Where to get
This is captured from the conversation detail records. It corresponds to the end time of the conversation object, typically found in the conversationEnd timestamp.
Capture
Logged when all participants have disconnected and the conversation ends.
Event type
explicit
|
|||
|
Interaction Started
|
This activity marks the beginning of a customer service interaction, such as an inbound call, chat, or email. Genesys Cloud CX explicitly logs this event when a new conversation object is created in the system. | ||
|
Why it matters
This is the primary start event for the service request process. It is essential for calculating the total resolution time and understanding incoming customer demand patterns.
Where to get
This event is captured from the conversation detail records. It corresponds to the start time of the conversation object itself, typically found in the conversationStart timestamp.
Capture
Logged when a new conversation is initiated in the system.
Event type
explicit
|
|||
|
Interaction Transferred
|
Represents an agent transferring an interaction to another queue or agent. This can be a blind transfer where the agent immediately disconnects or a consult transfer where they speak with the recipient first. | ||
|
Why it matters
This activity is essential for the Internal Escalation Rate KPI. High transfer rates can indicate training needs, incorrect routing, or process complexity.
Where to get
This is identified in the conversation detail records when a new ACD or agent participant is added to the conversation following the initial agent's involvement, often initiated by a 'transfer' event.
Capture
Identified by a transfer event in the participant's session data.
Event type
explicit
|
|||
|
Wrap-Up Code Assigned
|
An agent assigns a predefined wrap-up code, or disposition code, to the interaction. This explicitly categorizes the outcome of the service request, such as 'Resolved' or 'Escalated'. | ||
|
Why it matters
Wrap-up codes are a primary source for determining the business outcome of a request. They are vital for calculating resolution rates and segmenting cases for analysis.
Where to get
This is an explicit event found in the conversation detail records, typically within the agent participant's session data. The wrapUp code and timestamp are recorded.
Capture
Logged when an agent selects a wrap-up code for the interaction.
Event type
explicit
|
|||
|
After-Call Work Ended
|
This marks the end of the after-call work period for an agent. At this point, the agent becomes available to handle another interaction. | ||
|
Why it matters
This activity, combined with 'After-Call Work Started', provides the precise duration of the wrap-up phase, helping to analyze agent productivity and process overhead.
Where to get
This is inferred when the agent's state changes from 'acw' to an available state, such as 'idle'. The timestamp of this state change is used.
Capture
Inferred from the agent's state changing from 'acw' to an available state.
Event type
inferred
|
|||
|
After-Call Work Started
|
This activity marks the beginning of the after-call work (ACW) period. The agent has disconnected from the customer but is now in a dedicated state to complete tasks like logging notes or updating systems. | ||
|
Why it matters
Measuring ACW duration is important for understanding agent efficiency and overall handle time. Extended ACW can be a sign of inefficient post-interaction processes.
Where to get
Captured from the agent participant's session data. It is logged when the agent's state changes to 'acw' after the customer participant disconnects.
Capture
Logged when an agent participant's state changes to 'acw'.
Event type
explicit
|
|||
|
Agent Offered Interaction
|
This event occurs when the system offers an interaction to a specific agent. The agent's status changes to 'alerting' as the system waits for them to accept or reject the conversation. | ||
|
Why it matters
This activity helps analyze agent responsiveness and the effectiveness of the routing algorithm. Delays after this point can indicate agents are not accepting work promptly.
Where to get
Found in conversation detail records within the participant data for the agent. The participant's session will show a metric with an 'alerting' state and a corresponding timestamp.
Capture
Logged when the routing engine alerts an agent of a new interaction.
Event type
explicit
|
|||
|
Conversation Routed to Queue
|
Represents the moment a new interaction is placed into a specific queue to wait for an available agent. This is an explicit event logged by the Genesys routing engine (ACD). | ||
|
Why it matters
Tracking this activity is critical for measuring queue wait times and identifying bottlenecks in the routing process. High durations between this and agent assignment indicate staffing or routing logic issues.
Where to get
Captured from conversation detail records, specifically looking at the 'purpose' and 'state' of the ACD participant within the conversation. The 'enterTime' for the queue in the metrics array indicates this event.
Capture
Logged when the ACD routing engine places a conversation into a queue.
Event type
explicit
|
|||
|
Customer Satisfaction Survey Sent
|
This activity occurs when a customer satisfaction (CSAT) survey is sent following the closure of an interaction. This is often triggered automatically by the system based on predefined rules. | ||
|
Why it matters
This activity is necessary to measure the CSAT Survey Delivery Timeliness KPI. Ensuring timely survey delivery helps capture accurate feedback while the experience is fresh in the customer's mind.
Where to get
This information is typically available from survey or quality management data within Genesys Cloud CX, which can be linked back to the original conversation ID.
Capture
Logged by the survey module when a survey is dispatched for a specific conversation.
Event type
explicit
|
|||
|
Hold Placed on Interaction
|
This activity is recorded when an agent places a customer on hold during an interaction. This is an explicit state change for the agent participant within the conversation. | ||
|
Why it matters
Analyzing hold frequency and duration can reveal process inefficiencies, such as agents frequently needing to search for information or consult with others.
Where to get
Captured from the agent participant's session data in the conversation detail records. The state changes to 'held' and a timestamp is recorded.
Capture
Logged when an agent participant's state changes to 'held'.
Event type
explicit
|
|||
|
Hold Removed from Interaction
|
Occurs when an agent takes a customer off hold and resumes the conversation. This event marks the end of a hold period and is logged as a state change. | ||
|
Why it matters
Paired with 'Hold Placed on Interaction', this activity allows for precise calculation of total hold time, a key component of overall handle time and customer experience.
Where to get
Derived from the agent participant's session data when their state changes from 'held' back to 'connected'.
Capture
Logged when an agent participant's state changes from 'held' to 'connected'.
Event type
explicit
|
|||
|
Service Request Re-Opened
|
Represents a situation where a customer contacts the service center again about the same issue shortly after it was considered resolved. This is not an explicit event but is calculated based on business logic. | ||
|
Why it matters
Tracking re-opened requests is key to measuring the Service Request Re-opening Rate. It indicates that the initial resolution was not effective, impacting customer satisfaction and operational efficiency.
Where to get
This activity is inferred by identifying a new 'Interaction Started' event for the same customer (Customer ID) and related issue (e.g., Service Request Type) within a predefined time window after a previous interaction was resolved.
Capture
Calculated by linking a new interaction to a recently closed one for the same customer and issue.
Event type
calculated
|
|||