7 Zendesk configuration mistakes even smart teams make

Zendesk is immensely configurable. But all that configurability also means there are few guardrails. Sometimes, people build triggers or views that nobody else understands, or which break other Zendesk flows.

If messy Zendesk configurations remain untouched for too long, everyone builds around them. If everyone builds around them, that environment starts to feel fragile. People aren’t sure whether they can alter those triggers or tags because they don’t know what might misfire if they do. And then, because Zendesk doesn’t provide visibility into how settings are connected, people can’t decipher those configurations and that state becomes difficult to escape.

But things don’t have to be this way. In this guide, we identify seven configuration mistakes, the pain they cause, and how to roll them back before they become a feature of your Zendesk environment. 

‍

Mistake 1: Defining Zendesk views based on email address (or similar)

Why it’s a problem: If you create a view in Zendesk based on an email address or WhatsApp channel, agents can’t transfer that message to someone else’s view. It’s rigid. This makes it difficult for agents to help customers. 

When first starting out, most people set their Zendesk views based on an address or channel—for example, “info@company.com.” That can work for a time. But what happens when an agent working in the Info view decides a ticket actually belongs to the sales team, in the Sales view? With this configuration, they can’t move it. The “Received at info@company.com” attribute is unchangeable.

You could of course try creating a macro to add a “sales” tag and push it to the Sales view. But that won’t stop the ticket from appearing in the Info view, which again, is based on that original receiving email address.

‍

The fix: Create dynamic views with tags

To move tickets between views, you’ll need to use tags. Create one trigger for each inbound channel. Each trigger will add a tag that’s unique to that channel to each inbound ticket. You can then use these tags to build your views.

If we continue with our Info view example, you’d create two tags:

• Info_view

• Sales_view

Then, update each view so the criteria are:

• Info view = “Tags contain info_view”
• Sales view = “Tags contain sales-view.” 

‍

Warning: Use macros to prevent agents from editing tags

Your job isn’t done yet. If you allow agents to add those tags to tickets directly, it can wreck your data. It’ll be easy for them to create new tags, delete existing ones, and alter your tagging schema in ways that break your reporting.

Instead, create macros for agents to use. This serves two purposes. The macros add the correct tag and, at the same time, remove all others, so the ticket disappears from the incorrect view(s) and shows up in the correct one.

With those macros live, you’ve now fully solved the problem.

‍

‍

‍

‍

Learn more about dynamic views ->

‍

Document your Zendesk tags with Salto: Keep track of all your tags in case someone else edits or deletes them. You could use a spreadsheet or you can do it fast with Salto. 

‍

‍

Mistake 2: Setting and forgetting reminder emails

Why it’s a problem: Administrators rarely test their automated Zendesk reminder emails. If someone set them and never rechecked them, it’s possible agents and customers have learned to ignore them, which renders them useless. 

Most teams set their reminder emails based on a template and forget to check if they’re actually serving anyone. For all they know, those reminders are creating unnecessary work by assigning duplicate tasks to agents or have fallen out of sync with how the business actually functions. 

For example, if you used to give customers ten days to respond before you canceled their order, but recently changed it to six, and the auto-reminder is still set to go out on day seven, it now serves no purpose.

To investigate your automated reminders: 

• First look at the data—What is each reminder intended to do? Is it achieving it?
• Survey agents—Are reminders too frequent? Too infrequent? What would they change? 
• Consult customers—If reminders aren’t helping customers achieve a goal, what’s that goal, and why aren’t they reaching it? 

If you then want to craft reminders that improve the customer experience and save agents time, you can take the following six steps.

‍

Six steps to creating useful forwarded automated reminder emails

For this example, we’re creating a reminder email that references the prior email, so recipients have context. You can customize the follow-up times however you see fit.

1. Create a tick-box ticket field called 'enable reminder'

2. Create the first email reminder automation to send after 48 hours

3. Create the second email reminder automation to send after 96 hours

4. Create an automation that opens the ticket after 144 hours

5. Create three triggers that remove all tags when a customer replies

6. Create a view for follow-up tickets

‍

Learn more about reminder emails ->

‍

Mistake 3: Mixing up “ALL” and “ANY” on triggers

Why it’s a problem: This mixup can create “ghost in the machine” glitches and unsolved trigger mysteries. Those mysteries create technical debt, which piles up until people start to lose trust in your Zendesk implementation. 

It’s very common for someone to set a trigger, check that it works once, and not revisit it. It takes something very out of place for them to return and ensure it works under all conditions. But what if they configured it incorrectly? What if they mixed up the “ALL” and “ANY conditions, and don’t realize it’s firing for way more tickets than should qualify?

Let’s explore an example. Let’s say you want to create a trigger to identify any sales-related tickets. And over time, the company begins using a new Twitter handle for support requests and asks you to capture any sales-related tickets from both website chat and Twitter. Perhaps you add conditions to make your trigger configuration look like the one in Figure 3. Can you spot the issue?

To understand why this won’t function as expected, let’s revisit how trigger conditions work—and in particular, how the “ALL” and “ANY” sections relate. 

‍

‍

The  ALL and ANY conditions are connected by an “AND”

The interface in Zendesk lets you add both ALL and ANY triggers, but it doesn’t clarify how those two groupings relate. 

First off, you only need one condition to create a trigger—an ALL condition (you must have at least one). Which means all other conditions are nice to have but not necessary.

Second, those two groupings—ALL and ANY—are joined by an “AND” function, pictured. And this clarifies what’s wrong with the trigger settings in Figure 3.  This setup is telling Zendesk to activate the trigger whenever there is a new ticket, AND any one of those following conditions, but not necessarily all of them. This means that rather than firing for every new sales ticket from either of those two channels, it will fire for: 

1. Any new sales ticket, regardless of channel
2. Any new ticket from chat, sales-related or not
3. Any new ticket from Twitter, sales-related or not
4. Any new tickets where the comments include “sales,” sales-related or not
5. Any new tickets where the subject includes “sales,” sales-related or not

And given that, one can see that this filter is full of holes. It’s built incorrectly. The fix? Break it up into multiple triggers. You never want to get overly clever within each trigger, and it’s easier to maintain them if you divide them up anyway. 

Plus, as this example shows, you can’t chain “ALL” and “ANY” conditions selectively—they’re always joined by an AND.

‍

‍

Learn more about ANY and ALL functions ->

‍

Mistake 4: Ordering triggers by creation date, not lifecycle

Why it’s a problem: Messy trigger orderings only get worse with time as people forget why each trigger was placed where it was, and break those workflows. Unless you’re on the enterprise version of Zendesk, you can’t group them or see dependencies, and if someone does move them, you can’t see why.

Zendesk tickets fire in the order they’re listed, top to bottom. Many teams have hundreds of triggers and simply add new ones to the bottom of the list as they grow. Or, add triggers based on their presumed order of importance, dragging new ones higher on the list. This can lead to serious issues.

If you have multiple triggers that do things like tag tickets, and those tickets are useful for automations and flows, the order of operations can get mixed up. Let’s say that there’s a trigger that removes all tags, followed by one that adds an “Urgent” tag. If someone drags that “Urgent” tag above the other one, you now have a self-defeating system. Nothing will ever be marked urgent. And there’s no good way to visualize these mistakes in most versions of Zendesk. 

The simplest and best rule to follow is to order tickets by ticket lifecycle. Things that occur early in the ticket’s lifecycle should sit at the top, things that occur later, at the bottom. Zendesk Community Moderator Chandra Robrock recommends using the categories in Figure 5.

If your team is experiencing trigger bugs, this is a great way to begin paying down that debt: create Chandra’s categories in a spreadsheet, add your triggers, reorganize them in the spreadsheet, then reorganize them in Zendesk. 

‍

Pro tip: Use Salto to manage your triggers: Just looking at a list, it’s difficult to know what’ll happen if you reorder them. But if you use Salto, you'll have full visibility into your triggers.

‍

‍

‍

‍

Learn more about trigger order ->

‍

Mistake 5: Using automations instead of triggers or vice versa

Why this is a problem: Triggers and automations are both initiated when an event happens but there is a key difference between them. Mixing them up can lead to your processes breaking and can build a tangle of inefficient rules that are difficult to sort out later.

The simplest way to differentiate them is this: a trigger acts as soon as a ticket meets its conditions, an automation acts a set amount of time after a trigger meets its conditions.

Use triggers if something must occur immediately, like an agent marking a ticket as urgent, and automations for things you want to fire on a delay.

‍

‍

If you use an automation in place of a trigger, your tasks will be delayed

All automations contain a time-based delay. Using an automation when you need an instant action is going to slow you down. If you want tickets marked as urgent to be treated as urgent, don’t use an automation. 

‍

If you use a trigger in place of an automation, things can get messy

Automations are great for bulk actions, whereas triggers are not. You can use them to move any ticket that is close to breaching its SLA to a special view or to follow up with customers two days after you last emailed them. Trying to achieve these goals with triggers is going to require your agent more intervention time than necessary.

Note, there are some things triggers can do that automations cannot, and vice versa. But you aren’t stuck using one or the other. You can use both. If you want to create an automation that can read the text of a ticket, create a trigger that adds a tag when that phrase is found, and then set an automation to run when that tag is added.
‍

‍Learn more about triggers and automations ->

‍

Mistake 6: Allowing Zendesk to block form submissions as spam

Why this is a problem: If you haven’t allow-listed forwarding email addresses from your website form providers, valid contact form submissions are likely being forwarded to spam. This creates a poor customer experience.  

Do your tickets sometimes behave mysteriously? Do some tickets logged as going to the info@company.com email get routed to unexpected places? Do your macros occasionally mis-tag tickets and otherwise behave anomalously? 

The issue often lies in the fact that when you’ve set your Zendesk up to turn all inbound messages across channels into tickets, it hides some of that inbound information from you. For example, consider the “info@company.com” email address from the above example. Is that the final email address that message was sent to? Or was it first forwarded from another one of your company’s email addresses? If there was forwarding involved, Zendesk is applying its rules based on that first, hidden email. 

‍

If there was forwarding involved, Zendesk is applying its rules based on that first hidden email.

‍

You can go check this for yourself now. Navigate to the ticket and click the three-dot menu in Figure 6 to view the original email. This is the first step in debugging these issues.

‍

‍

‍

‍

What if many of these tickets are going to spam?

Zendesk tickets are sometimes caught in your spam filters because the spam filters are based on the original, forwarded, hidden email address. In this case, let’s say those emails come from “form@host.com.” 

The tickets in Zendesk may say a different email, but if you go back to view the original email, and it’s form@host.com, that’s what’s happening. Zendesk is seeing hundreds of emails coming in from form@host.com and thinks they’re spam. 

This one’s easy to fix: 

• Within the Zendesk admin interface, view “Suspended tickets” 
• Look for valid tickets being blocked because of emails like form@host.com
• Navigate to: Admin Center > People > Configuration > End users > Settings (tab) > Allowlist
• Add the email address info@host.com, or the entire domain, host.com

Learn more about troubleshooting ticket errors ->

‍

Mistake 7: Not asking to be paid what you’re worth

Why it’s a problem: For individuals, you need to be paid for the great work that you do. But for managers, paying below market creates serious risks: if your people are underpaid and get poached, all that valuable, undocumented Zendesk wisdom goes with them.

The average Zendesk administrator salary range is $70-90,000 at the time of writing. That’s based on a number of different figures. And while the exacts vary based on experience and location, here are three things you can do to increase your salary: 

‍

Specialize in problem-solving with Zendesk

Don’t grow so specialized in Zendesk that you become irreplaceable. Irreplaceable people are also difficult to promote. A better strategy is to think of yourself not as a pure Zendesk administrator, but a champion of customer service—an agent whisperer, a customer experience (CX) magician, and a solver of company problems whose tool of choice just happens to be Zendesk.

Aim to create good experiences for your agents and customers. Practice making rigid views flexible. Be the trigger wizard. Learn to troubleshoot ticket errors quickly and completely. Be known for testing and creating genuinely useful automated alerts. This lens makes your skills transferable.

Get certified

As a baseline, get certified as a Zendesk Support Administrator (read our guide to passing that certification on the first try). There are 10 administrator certifications in total at the time of writing.

If you’re really savvy, you’ll secure an agreement from your manager that passing certifications will help with your promotion before you take them. 

‍

Learn how Zendesk salaries vary ->