Salto for
Zendesk
Articles
SHARE
Jude Kriwald
May 16, 2023
6
min read
In Part 1, we covered what Zendesk ticket events are, how to access them and how to read them. Armed with this knowledge, we now have the platform to dig deeper into Zendesk problems and troubleshoot complex ticket errors of various causes. In this article, I will share with you some of the best ways to troubleshoot these errors and show you how to fix the most common Zendesk problems. This skill will elevate you from a fair-weather Zendesk administrator to the Zendesk guru your team can count on when things go wrong, no one knows why, and everyone is relying on you for urgent help.
As a Zendesk administrator, you’ll often encounter tickets that don’t behave as you’d expect or hope them to. Some might appear in the wrong view, whilst other emails sent into Zendesk might not create tickets at all. This can lead to confusion among agents, missed deadlines and unhappy customers. Our challenge, then, is to build on our knowledge of viewing ticket attributes to ensure we know every nook and cranny that we should look in to find the source of these errors.
Every email, call, text, Whatsapp message, etc. that comes into Zendesk is turned into a ticket. Having all contacts standardised into this one format helps us in numerous ways that I won’t go into now. Despite its benefits, it can also have its downsides.
What if, for example, we want to view a ticket in its original email format, as it looked before Zendesk turned it into a ticket? This can be incredibly useful to learn more information about why Zendesk is treating it a certain way that we might not want it to.
I’ll give you a use case of this in a moment but, first, here is how to view the original email that was used to create a ticket.
In the top-right corner of every email received within a ticket, look for the three dots next to the timestamp. Don’t get this confused with the three dots immediately above and to the right of here, which contains additional actions for the whole ticket, as opposed to additional actions specifically for this one message.
Click the three dots, then click “View original email”.
A new window will pop up (check that your browser doesn’t prohibit the pop-up). This window will contain the email in its original email format, without any of Zendesk’s bells and whistles.
Apart from being able to view the email in HTML, plain text or source code, there is one reason in particular that this view is incredibly useful, and that’s to see the exact email addresses that the email was sent to and/or from.
To try and keep things simple when displaying a ticket, Zenesk will only show the final email address that the email was received at. It won’t, however, display the first email address it was received at if the email was then forwarded on. This doesn’t sound like a problem, except for the fact that Zendesk will often do its “decision making” (i.e. choosing which triggers to apply to your ticket) based on this initial email address which isn’t shown in the ticket view.
So having visibility of this “To:” email address can be the missing piece of your puzzle when trying to understand why a ticket isn’t ending up in the view that it should, despite it looking like it was sent to the correct email address.
In the real example below, we have received numerous emails from customers who have filled out a contact form embedded on my client’s website.
We can see that, despite all coming from the same form, Zendesk appears to recognise them as being sent from unique email addresses, hence the Requesters are all unique to each sender.
When we click through onto one of these tickets, we see the same - the requester is unique to the customer, so it seems that Zendesk doesn’t have a problem distinguishing these customers from each other, based on the email addresses they entered in the contact form.
A very common complaint I hear from clients who have an external contact form setup like this is that some form submissions are not getting through to Zendesk. Read on to see how we can identify and fix this.
This is where using the “View original email” feature becomes incredibly handy.
Continuing with our real-world example, when we view the original email, we see some very enlightening new information. Unsurprisingly all of the emails we are receiving from this contact form are coming from the same email address, noreply@jotform.com. Despite this, Zendesk is clever enough to recognise that the reply-to address is unique to each customer, and to create a unique requester from the reply-to address. Thus any messages we send on this ticket will be sent to the customer’s email address, not the generic form email address.
Whilst on the one hand, Zendesk is able to see that all of these emails should count as being from unique customers, there is another part of Zendesk which fails to make this distinction: spam protection.
Given that we might receive over a hundred emails a day via this contact form, all coming from the same noreply@jotform.com email address, Zendesk’s spam filters are extremely likely to interpret that as spam-like behaviour and suspend all or some tickets from this email address.
You can see all of your suspended tickets in the penultimate view in the agent interface
Upon looking in the Suspended tickets view, if you do see that there are multiple emails being suspended from an email address that you do not want Zendesk to block, the solution is simple.
Head over to Admin Centre > People > Configuration > End users > Settings (tab) > Allowlist or https://YOURDOMAIN.zendesk.com/admin/people/configuration/settings and add in the email address that your contact form sends from, for which you’d like Zendesk to no longer suspend tickets.
You can either enter specific email addresses, such as our example of noreply@jotform.com or you can whitelist an entire domain, e.g. jotform.com, if you want to ensure that every email address sent from an email ending with @jotform.com is not suspended.
With this setup, all emails from your contact form provider will be allowed into Zendesk without being suspended, despite the fact that they all come from the same email address.
Whether you use an external contact form or not, this process of identifying the original sending email address and whitelisting it is incredibly useful for a whole host of applications. Many companies receive shipping updates via email for example, with hundreds a day coming into Zendesk from the same email address. With this new skill, you can ensure they all reach your agents right on time.
In conclusion, we have learned how to dig deeper into the original attributes that Zendesk uses to form email-based tickets. We have seen that Zendesk is incredibly smart in how it uses this information, but that different features within Zendesk apply different rules to the same data.
Finally, we saw how to mitigate these occasional inconsistencies by ensuring that genuine tickets are not erroneously suspended, allowing your team to get back to customers uninhibited.
Salto for
Zendesk
Zendesk
SHARE
Jude Kriwald
May 16, 2023
6
min read
In Part 1, we covered what Zendesk ticket events are, how to access them and how to read them. Armed with this knowledge, we now have the platform to dig deeper into Zendesk problems and troubleshoot complex ticket errors of various causes. In this article, I will share with you some of the best ways to troubleshoot these errors and show you how to fix the most common Zendesk problems. This skill will elevate you from a fair-weather Zendesk administrator to the Zendesk guru your team can count on when things go wrong, no one knows why, and everyone is relying on you for urgent help.
As a Zendesk administrator, you’ll often encounter tickets that don’t behave as you’d expect or hope them to. Some might appear in the wrong view, whilst other emails sent into Zendesk might not create tickets at all. This can lead to confusion among agents, missed deadlines and unhappy customers. Our challenge, then, is to build on our knowledge of viewing ticket attributes to ensure we know every nook and cranny that we should look in to find the source of these errors.
Every email, call, text, Whatsapp message, etc. that comes into Zendesk is turned into a ticket. Having all contacts standardised into this one format helps us in numerous ways that I won’t go into now. Despite its benefits, it can also have its downsides.
What if, for example, we want to view a ticket in its original email format, as it looked before Zendesk turned it into a ticket? This can be incredibly useful to learn more information about why Zendesk is treating it a certain way that we might not want it to.
I’ll give you a use case of this in a moment but, first, here is how to view the original email that was used to create a ticket.
In the top-right corner of every email received within a ticket, look for the three dots next to the timestamp. Don’t get this confused with the three dots immediately above and to the right of here, which contains additional actions for the whole ticket, as opposed to additional actions specifically for this one message.
Click the three dots, then click “View original email”.
A new window will pop up (check that your browser doesn’t prohibit the pop-up). This window will contain the email in its original email format, without any of Zendesk’s bells and whistles.
Apart from being able to view the email in HTML, plain text or source code, there is one reason in particular that this view is incredibly useful, and that’s to see the exact email addresses that the email was sent to and/or from.
To try and keep things simple when displaying a ticket, Zenesk will only show the final email address that the email was received at. It won’t, however, display the first email address it was received at if the email was then forwarded on. This doesn’t sound like a problem, except for the fact that Zendesk will often do its “decision making” (i.e. choosing which triggers to apply to your ticket) based on this initial email address which isn’t shown in the ticket view.
So having visibility of this “To:” email address can be the missing piece of your puzzle when trying to understand why a ticket isn’t ending up in the view that it should, despite it looking like it was sent to the correct email address.
In the real example below, we have received numerous emails from customers who have filled out a contact form embedded on my client’s website.
We can see that, despite all coming from the same form, Zendesk appears to recognise them as being sent from unique email addresses, hence the Requesters are all unique to each sender.
When we click through onto one of these tickets, we see the same - the requester is unique to the customer, so it seems that Zendesk doesn’t have a problem distinguishing these customers from each other, based on the email addresses they entered in the contact form.
A very common complaint I hear from clients who have an external contact form setup like this is that some form submissions are not getting through to Zendesk. Read on to see how we can identify and fix this.
This is where using the “View original email” feature becomes incredibly handy.
Continuing with our real-world example, when we view the original email, we see some very enlightening new information. Unsurprisingly all of the emails we are receiving from this contact form are coming from the same email address, noreply@jotform.com. Despite this, Zendesk is clever enough to recognise that the reply-to address is unique to each customer, and to create a unique requester from the reply-to address. Thus any messages we send on this ticket will be sent to the customer’s email address, not the generic form email address.
Whilst on the one hand, Zendesk is able to see that all of these emails should count as being from unique customers, there is another part of Zendesk which fails to make this distinction: spam protection.
Given that we might receive over a hundred emails a day via this contact form, all coming from the same noreply@jotform.com email address, Zendesk’s spam filters are extremely likely to interpret that as spam-like behaviour and suspend all or some tickets from this email address.
You can see all of your suspended tickets in the penultimate view in the agent interface
Upon looking in the Suspended tickets view, if you do see that there are multiple emails being suspended from an email address that you do not want Zendesk to block, the solution is simple.
Head over to Admin Centre > People > Configuration > End users > Settings (tab) > Allowlist or https://YOURDOMAIN.zendesk.com/admin/people/configuration/settings and add in the email address that your contact form sends from, for which you’d like Zendesk to no longer suspend tickets.
You can either enter specific email addresses, such as our example of noreply@jotform.com or you can whitelist an entire domain, e.g. jotform.com, if you want to ensure that every email address sent from an email ending with @jotform.com is not suspended.
With this setup, all emails from your contact form provider will be allowed into Zendesk without being suspended, despite the fact that they all come from the same email address.
Whether you use an external contact form or not, this process of identifying the original sending email address and whitelisting it is incredibly useful for a whole host of applications. Many companies receive shipping updates via email for example, with hundreds a day coming into Zendesk from the same email address. With this new skill, you can ensure they all reach your agents right on time.
In conclusion, we have learned how to dig deeper into the original attributes that Zendesk uses to form email-based tickets. We have seen that Zendesk is incredibly smart in how it uses this information, but that different features within Zendesk apply different rules to the same data.
Finally, we saw how to mitigate these occasional inconsistencies by ensuring that genuine tickets are not erroneously suspended, allowing your team to get back to customers uninhibited.