It always begins harmless enough. One team requests an exception for a custom notification. Then other teams pile on. Suddenly, everyone is being notified of everything via email and it seems like your staff is spending more time reviewing notifications than communicating with customers.

As much as we system administrators exist to assist our users, we’re also here to define and defend the process behind our work. It’s our job to help stakeholders understand the impact of requests so nobody creates a trigger to solve an issue that only creates three new problems.

Zendesk is powerful, but it’s also powerfully reliant on knowing what you’re doing. I come at it from the perspective of a user. I started in digital sales, where one of my many “other duties” was to monitor an Outlook inbox. When that became untenable, my company launched Zendesk and had me learn it. Over time, I helped grow it from 10 users in one office to an enterprise-wide implementation covering more than 150 brands across six global offices. That’s when I got certified, and I’ve been consulting on Zendesk ever since.

Now, having worked on more than 100 instances, I’d love to share five tips that I believe are the secrets to success.

1. Do not accept every request

Admins often feel duty-bound to act on requests from the agents and leaders who spend their days in the system. I would challenge every admin to take more ownership over the outcome of their configuration to ensure everyone understands the impact of what they’re asking. Sometimes that means saying, politely, “No, and here’s why.”

Most of the simplest errors I see are the result of good intentions: someone trying to solve a problem only to end up creating three more. Things within Zendesk are highly interconnected. You think you’re addressing one explicit use case, but because you don’t know all that’s implemented—and at a certain size, one person can’t know it all—you don’t put guardrails around it. There are unintended consequences and collateral damage that affects other teams and processes.

The best prevention here is to take a “measure twice, cut once” approach. We call ourselves software “architects” for a reason. Just like with real architecture, the people making requests don’t always know how to read a blueprint. It’s our job to reinterpret requests to build a stable structure.

And of course, you can go too far to the other extreme. I’ve seen Zendesk administrators lock things down so much that everyone’s forced into one process, and that can be bad too. There’s a happy medium. Your job is to find the balance.

‍My recommendation: Push all internal Zendesk requests through a (Zendesk) form where they’re added to a queue and evaluated in relation to other requests.

2. Check again to see if your triggers are out of order

I joke that one of a Zendesk administrator’s jobs is to talk to themselves all day. I like to create an end-user account and then email into the support inbox to see what that experience is like because it’s rare for end users to report little quirks. People never go back to the Zendesk administrator and say, “Hey this is broken.” Instead, they say, "Oh yeah, I always get rogue notifications from Zendesk, I just ignore them because it's not my problem or job to fix it.” Where it does tend to show up, however, is in negative customer satisfaction ratings.

To iron that out, take another look at your triggers.

People never go back to the Zendesk administrator and say, “hey, this is broken."

While Trigger Categories has been a nice step forward, you still have to audit your triggers. I see this become an issue for companies with multi-country support. Sometimes they’ll place the notification trigger above the trigger that sets the group, so the notification fires for the wrong group, then it reassigns to the correct group without sending a notification. It’s a real blind spot.

The acronym I’ve created for arranging your triggers, top to bottom, is SANE. That's Settings, Assignments, Notifications, and Exceptions. If things fire in that order, it eliminates many issues.

‍My recommendation: Audit your triggers. Pull them into Excel via the API or at worst, copy-paste. In that format, it’s easier to review them critically and ask, “What does this trigger do? Why do we need this? Where does this belong in the order?” You can safely deactivate ones that were for one-off use cases, or haven’t fired for 30 days, and begin to group them together. Through this process, you’ll discover broken groups that don’t exist anymore or triggers that say they work, but aren’t actually doing anything.
‍

3. Drive customers to forms, not email

As a general rule, customers tend to use unexpected words to describe a problem. There are way too many variations to build guardrails that anticipate every possible scenario.

Just take a refund, for example. If you have a user who wants a refund and they’re emailing, and you want that to be a high-priority item, that’s tough to capture. If the phrase they use is “money back,” your “refund” trigger will bypass the ticket.

Instead of playing this unwinnable guessing game, I recommend driving everyone to a form in your Zendesk help center. This has three benefits. First, it gives you an opportunity to deflect the ticket into self-service with help articles, which will show up in predictive search as they type. Second, that extra little friction helps validate this is indeed a real problem. And finally, it structures that data and ensures the ticket is tagged and routed appropriately, which is, ultimately, a better user experience.

The point here isn’t to abandon triggering based on keywords in emails—it’s to not let that be the default. The Pareto principle is still at play and no matter how much you push forms, there’ll always be 20% of people who need something different. Let them email. Ask everyone else to use the form.

‍My recommendation: Update your contact page so the most prominent help feature is a contact form or web widget that leads to one. In your brand’s email signature, add a link that says “For faster answers, consult our help center.”
‍

4. Rebuild your process around Zendesk, rather than mimic your old platform

Many teams rip out their legacy system and replace it with Zendesk, but then continue to treat it like the legacy system. Zendesk is very flexible, and when they approach it with that mindset, they tend to build themselves into a corner. Zendesk is so much more powerful than whatever they were using in terms of routing and automation, it’s important to take a step back and reevaluate their support systems from the Zendesk perspective.

One of the best examples of this is when teams transitioning from Outlook want to assign all tickets to themselves and have Zendesk act like a personal inbox (sending an email for every ticket). But what happens if they take a day off? It’s the same with views. People want to be able to see everything they have ever worked on. But it’s your job as administrator to challenge their old beliefs and show them they can trust the system. Teach them that if they want something, they can search for it.

‍My recommendation: Think like an end user and democratize access to things so one person being out doesn’t mean the system stops working for users.

5. Ask for help

With more than 170,000 customers worldwide, there are countless answers to the question of “How do I do that with Zendesk?”  To their credit, Zendesk not only documents everything in a dynamic and constantly refreshed support center, but they also eat their own ice cream in providing support to Zendesk customers using … Zendesk!  

Leveraging the help tools and messaging features within the product can not only help admins find answers to frequently asked configuration questions quickly, but can also provide a great real-world example of how Zendesk thinks about the customer journey. And, if you’re truly stuck, there’s even a Community of Zendesk employees and power users (present company included) where users can ask questions, get advice, and even provide feedback on the tool.

‍My recommendation: Don’t be afraid to cry uncle. Between the advocates, webinars, and forums, there’s always resources available to help you connect the dots and keep your workflows working.
‍

Zendesk: powerful, flexible, and an opportunity to reinvent

Your most important job as a Zendesk architect is to help your users get what they need, if not necessarily what they asked for. Your company purchased or expanded Zendesk because it wanted to automate, to improve, and to create wonderful customer experiences. It’s up to you to share with everyone in the business how that happens, and a great way to start is to follow these five tips:

#1. Do not accept every request

#2. Check again to see if your triggers are out of order (Remember: SANE)

#3. Drive customers to forms, not email

#4. Rebuild your program around Zendesk

#5. Ask for help

‍