Zendesk is an incredibly useful tool for any customer service team. It helps organise queries, improve and automate responses, report on essential data, and much, much more. But with so much going on, how do we fix our processes when they go wrong, or when agents report that something doesn’t seem right?

In this article, I’ll share some simple solutions to common Zendesk ticket errors, as well as show you best practice when it comes to investigating the causes of unexpected ticket behaviour.

The best first step - View events

Tickets can behave unexpectedly in numerous ways. They might be appearing in the wrong view, perhaps their SLA isn’t activating, or perhaps a key automation you need isn’t firing when it’s meant to.

Whether it’s views, SLAs, triggers, macros, or something else, Zendesk ticket behaviour is defined by the rules that we set. These rules mostly reference ticket properties, such as ticket status, group, brand, channel and so on. With this in mind, our first step when we want to understand why a ticket behaved a certain way is to check what its ticket properties are.

And not only do we want to check what the ticket properties currently are, but also what they were each and every time the ticket was updated.

To do this, we need to do what’s called “view events”. Viewing events means that, rather than just seeing each public message and internal note on a ticket (known as Conversations), we can see each and every update to a ticket’s tags, status, assignee etc, as well as any triggers or automations that fired.

Finding this interface varies depending on the version of Zendesk you are using.

In some versions, you’ll be looking for the clock with an arrow icon, as per below. This will be located in the top-right corner of each ticket you open.

‍

‍

If you can’t see that icon, don’t worry! Instead, look for the button that says “Conversations” with an arrow pointing downwards next to it. This will be below your text input area, and above the first message, as below.

‍

‍

Click there, then click on “Events”

‍

‍

You’ll now see that, whereas before we had a very simple representation of the ticket history, we now have a lot more detail underneath each update.

‍

Understanding ticket events

Let’s take a look at these example ticket events, taken from an update to a real ticket.

‍

‍

Along the left, in bold, we can see the name of the event. In some cases, it’s a ticket property that has been updated. In other cases, it’s something that’s been applied to the ticket, such as a trigger or a macro.

The first one we see is ticket status. This line shows us that the status was previously Pending (hence it being crossed out), and that the new ticket status is On-hold.

‍

‍

Below that, we can see that the subject was changed. Again, Zendesk will always show the previous value with a line through it, and the new value as of that update to its left.

‍

‍

Below Subject, we can see that an email notification was sent. You might then find yourself asking, “well, what was sent, and why”? This is where viewing ticket events gets really useful. The line below Email notification tells us that the email was sent as a result of a trigger. Helpfully, Zendesk then tells us the name of the trigger and makes it clickable, so you can go straight in and view the conditions of the trigger.

‍

‍

This is arguably the most helpful stage, compared to viewing a ticket without ticket events shown. When we only look at the messages sent back and forth, it can be hard to understand why a ticket behaved a certain way. With this feature, we can click through to the trigger that fired and inspect its conditions and actions. If you weren’t expecting a trigger to fire at this point, this is an excellent way to see why it did, allowing you to address the issue by editing the trigger conditions. You do this by comparing the conditions that your trigger sets with the conditions of the ticket shown in the events view.

For example, you might have built the above trigger with the intention that it should only fire when the ticket status was Pending. By looking at the other ticket events, you can see that the ticket was changed from Pending to On-hold, and so you might need to update the conditions of your trigger to stop it firing when tickets are On-hold.

The final event shown is much simpler. It tells us that an agent applied a macro. Again, it helpfully tells us the name of the macro and enables you to click through to view and edit the macro if you need to.

‍

‍

It’s well worth your time to view the events of multiple tickets, in order to familiarise yourself with what it can offer.

Important: notice how Zendesk shows ticket events under each and every update to a ticket, meaning you can see which agent or automation did what to the ticket, and when. This is crucial for understanding the history of a ticket, and the path it took when trying to learn why it behaved as it did.

For example, you might be trying to understand how an important ticket missed its SLA. This event view could show you that it was bounced between agents, assigning it back and forth to each other without ever even writing a message. Equally, it might tell you that your escalation trigger isn’t set up to action when you thought it was.

Summary

We have covered what Zendesk ticket events are, how to access them, how to read them and, most importantly, how to make good use of them. With these skills and features now at your disposal, you’ll be able to make sense of the inner workings of Zendesk much more easily, as well as identify which processes have room for improvement. 

In Part 2, we’ll explore how to dig even deeper into potential ticket errors, as well as share the causes of, and solutions to, some of the most common Zendesk ticket errors.