Zendesk Integration
This feature is in Preview and its behavior is likely to change based on user feedback. The feature also may have lower availability and have more maintenance windows.
You can connect multiple Zendesk instances to a single Salted CX account and mix data in Zendesk with other data sources.
Zendesk Data in Logical Model
We translate data from all platforms into a unified Logical Model that enables you to report on data from multiple platforms in the same way. We use unified concepts with unified naming and the same meaning in every platform.
As each platform has its own vocabulary and concepts we cannot adopt any single platform vocabulary. Platforms have different names for the same concepts (for example ticket, case, issue, or task for a single customer-related request). Or different platforms use the same name for different concepts (for example “Contact” means a single conversation with a customer in one platform, but it means a customer email/phone in another platform).
This article covers how Zendesk concepts translate into Salted CX concepts and vocabulary.
To understand Zendesk data in the Logical Model it is recommended to have a basic understanding of our Customer Journey and Logical Model. You can also check our Glossary to understand the naming and meaning of our concepts.
Customers
Salted CX creates individual customers that correspond to Zendesk users. Zendesk creates users for both agents and actual customers. Every ticket associated with that use becomes part of the given customer’s customer journey. So you see all those tickets chronologically one after another.
Conversations
Each Zendesk ticket translates to one conversation.
Engagements
Zendesk does not have a built-in concept similar to engagements. We define engagement as the participation of a single agent or a service in a conversation with a customer. We use heuristics to extract a similar concept from Zendesk data.
We create engagements based on actual agent activity on the ticket. A new engagement is started when a new agent responds to a ticket or when a ticket is reopened. The engagement ends when another agent starts to engage with the customer or the ticket is resolved. The start time of an engagement is when an agent sends their first message. The end time of an engagement is when an agent sends their last message.
For example, if an agent Alice replies to a customer at 8:00 AM with one message, then Alice asks Bob for help with the customer. Bob starts to chat with the customer at 8:15 AM until 8:30 AM. Bob returns the ticket to Alice who chats with the customer from 8:45 AM to 9:00 AM and marks the ticket as resolved. Custom reaches back and Alice chats again with the customer from 10:00 AM to 10:30 AM. We create 4 engagements:
- Engagement with Alice with start time and end time 8:00 AM
- Engagement with Bob with start time 8:15 AM and end time 8:30 AM
- Engagement with Alice with start time 8:45 AM and end time 9:00 AM
- Engagement with Alice with start time 10:00 AM and end time 10:30 AM
Depending on your exact process and setup in Zendesk our metric Engagement Time and metrics based on it may not be reliable indicator of an agent performance. Unlike many other contact center platform Zendesk does not have a concept of an agent actively working on a ticket by accepting it which is in common cases the trigger to start counting Engagement Time.
You can use metrics such as Engagements per Hour to get glimpse of the agent performance. More engagements per hour typically means agents are faster in handling them.
Turns
Each individual message or email from an agent or from a customer creates a new turn associated with an engagement of the currently engaged agent.
Data not Available from Zendesk
Different platforms provide different granularity of data and have different concepts. These features may prevent us from reporting on certain useful metrics or impose other significant restrictions.
This typically leads to inability to use certain attributes and/or metrics in reporting for the given platform. This section covers the most noticeable limitations. Remember that when one metric is affected also metrics based on that one (using the affected metric as part of their definition) are affected.
Queue Engagements
Zendesk does not have a concept of queues similar to many other contact center platforms. Thus we do not create any queue engagements that typically represent waiting customers in a specific queue and enable visibility into customer movement between queues.
Affected attributes: Queue
Affected metrics: Wait Time, Queue Engagements
Invitation Engagements
Zendesk does not have a concept of inviting agents to conversations (showing agents that they can handle the customer) similar to many other contact center platforms. Thus we do not create any invitation engagements in case the agent misses or rejects the invitation to join conversations.
Affected metrics: Invitation Time, Rejected Invitations, Missed Invitations
Wrap Up Time
Zendesk does not have a concept of wrap up that agent has to perform after an engagement with a customer. Although agent can perform additional actions in Zendesk after they resolve the customer ticket this time is not tracked by Zendesk.
Affected metrics: Wrap Up Time
Agent Status
We do not import agent activity (agent status, AUX codes) from Zendesk. This status codes are typically used for routing decisions and WFM purposes. When using Zendesk we expect you have another source for this data such as WFM or a contact center platform.
Affected metrics: Activity Time, Available Time, Unavailable Time