Viewing User Interaction Context in Zendesk
This article shows you three ways you can leverage existing Zendesk features to give agents insights in user intents so they can resolve tickets faster and give better support.
When defining a good customer care strategy there's 3 main elements that are core items that need to be part of your strategy. Customers need be able to self serve, agent need context and as an admin you need insights.
Self service not only allows customers to solve issues more quickly by offering solutions up front without waiting for an agent, it also removes workload from your team so that they can focus on the complex issues while the easy questions are handled by bots and guide articles.
Similarly, when agents have context they know who the customer is and what they want to accomplish. It reduces duplicate work and makes sure information is available instead of customers needing to repeatedly provide their name, email or intent.
And finally you need good reporting that categorises your inquires and flags repeated scenarios and blockers so you can optimise these flows so you can improve self service and context.
This article will focus on giving agents context based on user actions.
Giving context
Imagine a customer who visits your webshop and looks at a product. They spend some time on the product page and then reach for the Contact Us button. Their question will probably be about that product.
So when an agent sees an incoming conversation it would be pretty convenient if they can see what the customer was looking at right before they send a message so they can open up the product page themselves, check if the customer bought or orders the item, pull up the knowledge articles on the product, ... The customer will be assisted faster, and the agent doesn't need to ask that context from the customer.
Similarly let's say that same customer started the conversation and the Zendesk Bot proposed a few articles. They read the articles, maybe mark a few of them as "did not help", and then reach out to an agent. The worst experience we can offer the customer is having the agent send them those same articles again. So if we can make the list of read/shown articles visible to the agent they won't waste time sending the same information again, but can immediately dive into more complex support questions and solutions.
Both of these scenario's are examples on how Zendesk and the Agent Workspace can give agents insight in user intents to better assist them while working more efficient.
How does it work?
So, how does it work? Let's dive into three concrete examples
- Show browser history next to tickets
- Show prior interactions and actions in external tools next to tickets
- Show FAQ activity next to tickets.
📈 Showing browsing history
One of the benefits of adding your Messaging widget not only to your support site but to every site you own (blog, help center, webshop,..) is that the widget will track page views across all websites where the widget is embedded.
When a user visits your website, navigates to a product page, looks at the product, then goes to a few support articles and finally ends up on the checkout page the widget will store those page views. If the customer then contacts you via the widget the Customer Context Panel in Agent workspace will show those visited webpages to your agent, providing immediate context.
The panel will show the last 20 pages a customer has looked at and the list is updated whenever a new Conversation is started. So the context will change and rotate over time and any interaction will always show the most recent 20 pages (if available).
This feature is enabled by default so there is no configuration to be done.
🔒 Privacy
Tracking user interactions can be frown upon and might even be against local privacy regulations. Luckily Zendesk took this into account when they designed this feature.
By default Zendesk pushes the following object to their servers upon page load:
{
"url": "https://widget.internalnote.com/",
"buid": "fc5ded164c5d4e628163e85c7ba7d04f",
"channel": "web_messenger",
"version": "1a67289",
"timestamp": "2023-08-18T10:02:05.535Z",
"suid": "35092f59253640d89b27a488fe47930d",
"pageView": {
"pageTitle": "Internal Note - Zendesk Messaging Authentication",
"referrer": "https://widget.internalnote.com/",
"time": 10,
"loadTime": 62,
"navigatorLanguage": "en-GB",
"userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Safari/537.36",
"helpCenterDedup": false
}
}Notable here is the buid that is a unique ID for that session, and the url .
For any subsequent request the same buid will be passed along. This is stored in localStorage and has no expiry date so should be considered stable.
However, as long as no conversation is started there is no User information passed along, and the data is not visible anywhere in the Zendesk UI for Agents.
The passed URLs are also limited to 20, so after 21 page visits the first page will be purged. The fact that the buid is fixed on a user device might make it an identifier.
More info on Zendesk cookie usage can be found here:
Now, when a user does click the widget and starts a conversation, the following payload gets send. This one does contain a appUserId and is responsible for linking the current conversation to a user in Zendesk. And since this payload also contains a client.id that is the same as the buid the history already submitted to Zendesk is linked to your user and shows up in their context panel.
{
"author": {
"role": "appUser",
"appUserId": "d36caf93deaded3cea0be14d",
"client": {
"platform": "web",
"id": "fc5ded164c5d4e628163e85c7ba7d04f",
"integrationId": "61ea8723f4aa6100eb8a69e5",
"info": {
"vendor": "zendesk",
"sdkVersion": "0.1",
"URL": "widget.internalnote.com",
"userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Safari/537.36",
"referrer": "",
"browserLanguage": "en-GB",
"currentUrl": "https://widget.internalnote.com/",
"currentTitle": "Internal Note - Zendesk Messaging Authentication"
}
}
},
"activity": {
"type": "conversation:read"
}
}If you want to tie this behaviour into your privacy policy and cookie banner you can leverage the Zendesk Widget API. This will disable the widget if the user declines your cookie settings.
zE("messenger:set", "cookies", false)📅 Showing actions and events
Where the previous flow focussed on actions happening outside of Zendesk, Zendesk Events are there to give agents context on what's happening inside of Zendesk.
The Context Panel by default shows a list of recently created tickets and conversations, but when you dive into the settings you can enable a few other Zendesk events related to Zendesk Guide.
When an agent gets a new ticket they can reference that context panel to see if the user recently created a ticket for a similar topic, or if they read guide articles in the past that referenced that same topic, helping the agent to suggest the right solution without repeating past information.
Shopify Events
If you have the Shopify integration for Zendesk enabled you can also show orders, refunds, deliveries and other interactions with your webshop right next to tickets.
If a customer inquires about an order status but forgets to add an order number, it's probably that order they placed a few days before creating the ticket.
Or if you see a refund processed event, you can use that to let the customer know they've got their money back and resolve the ticket.
Custom Events
When you enable these Zendesk events you'll notice that you can also create Custom Event types. These events can be added via API and allow you to any kind of event in the timeline giving agents context specific for your use case.
For example, I created a custom Event flow that shows me when someone subscribes to Internal Note or, even better, when someone decides to become a paid supporter. 🥳
That way, whenever someone contacts me with feedback I can quickly reference their status without switching between multiple tools.
If you want to know how to do this, take a look at the article below, or if you don't want to code, take a look at Event Manager Pro on the Zendesk marketplace.
Thomas Verschoren
🤖 Show FAQ activity
To wrap up this article on giving agents context, let's dive into a final big one: give agents insights in which articles the customer already read and didn't help them.
Most companies that setup Self Service start with the basics: the set up a good Help Center that handles the usual questions and point customers to that page whenever they need help.
Agents can then use the Knowledge Panel to lookup articles and offer them to customers as a possible solution, if customers didn't already lookup the articles themselves in the first place.
Step two in this flow is turning self service into ticket deflection. Instead of relying on the customer to search for something, or have agents spend time offering solutions, you can let Zendesk automate this flow for you.
You can enable a Zendesk Bot that will offer the customer articles based on their question in the Messaging widget or on social channels, or you can enable auto-replies which will respond to incoming emails by offering three Help Center articles in response to the customers' inquiry. Enabling auto-reply will also intercept webform submissions in your Help Center by presenting a modal view that shows three articles that might help.
Whatever option you choose, the flow is similar:
- Zendesk offers three support articles to the customer
- The customer clicks a link and reads (or looks at) the article
- Zendesk offers the customer the option to mark their question as resolved
When they mark the article is resolved, Zendesk will close the open ticket and tag it with auto-solved via bot tag for reporting purposes.
The two galleries below give you an idea on how this flow works for webforms and email.
What's nice about this setup is that not only will you deflect questions that can be resolved with an article, thus giving agents time to focus on the complex questions, but Zendesk will also list the offered articles in the ticket thread. This way your agents know what's been offered to the customer already, which removes the risk of sending the same link again and again.
Aside from showing the list of articles suggested, Zendesk will also mark articles as viewed or even highlight those deemed "unhelpful" or "unrelated" so you can improve those articles where needed.
Via webform
Via Email
Conclusion
Zendesk offers a lot of code-free solutions out of the box that make it easy and fast to give agents context in what your customers want to achieve which allows them to give better and faster support, leading to better response times and, hopefully a higher CSAT.
So, which of these features do you use already?
