1. Ticket routing
Ticket routing is an important feature of any user support service. Zendesk definitely offers robust functionality in this area. It’s able to handle almost any kind of routing you could hope to accommodate. Unfortunately, we found it a bit confusing to set up.
In Zendesk, there are multiple ways to route tickets, but no single screen that lists all of your routings. To review or configure how tickets are routed, re-routed, or tagged, you have to look at three separate settings screens:
- Triggers. Use this screen to create a series of automated processes that execute when a ticket is created or updated.
- Automations. Use this screen to create a series of automated processes that execute a certain amount of time after a ticket is created or updated.
- Skills. Use this screen to manage tickets based on the skills or qualifications an agent needs to have in order to address the request.
Triggers and automations can be set up to directly assign a ticket to an agent or group. Skills, however, do not directly assign a ticket to any agent. Instead, agents use a customized view to see all the tickets that match their skills. With three different screens and two ways of matching tickets to agents, it definitely took us some work to organize our requirements based on Zendesk functionality.
It’s likely that you’ll need a combination of triggers, automations, and skills, so having a document that visually maps your ticket routing can be very useful. We like that these tools let you color-code the steps so that you can easily see which ones need to be configured on creation or update (triggers), after a certain amount of time (automations), or “routed” using skills. A document like this also helps you remember how all the pieces fit together.
2. Triggers & automations
There were other places we struggled with configuring triggers and automations, too — such as which one to use for a particular use case, whether to use an “all” or “any” condition, which unit of measure was being used, and how to set up bump-bump-solve automations.
Some use cases require triggers, other require automations
While setting up a configuration to escalate a ticket to a manager, we had to go back and forth between both the trigger and automation settings to understand the functionality. For example, we wanted to create different automated processes to mark a ticket as needing a manager when:
- A customer demonstrates negative behavior or mentions wanting to cancel their subscription.
- A ticket is about to breach an SLA.
- A ticket is marked “urgent” priority.
Each of these use cases requires a different configuration. We needed to create individual triggers for negative behavior and urgent priority (because we wanted them to execute immediately after a ticket is created or updated), whereas we needed to configure an automation for an SLA warning, so that Zendesk would perform an hourly check for any tickets nearing a breach.
Do you need “all” conditions or “any”?
When we were setting up triggers and automations, we were also uncertain about how to configure the conditions. We could specify whether we needed “all” conditions to be met or “any” of the conditions to be met, but there were different options depending on which we selected. For example if we wanted to add a condition based on “Hours since” or “Hours until” an event, that condition had to be within an “all” conditions met section.
What unit of measure is that?
Something else we found confusing was that for some fields the unit of measure wasn’t specified. For example, when we were creating a trigger based on a custom date field and had to enter an integer, we weren't sure which unit was being applied (we discovered that it’s Days in the example below).
Setting up bump-bump-solve automations
Since implementing bump-bump-solve emails is a common industry standard, we expected it to be a built-in feature in Zendesk. Instead, we had to manually implement bump-bump-solve using these instructions.
Note that if you’re setting up a configuration like this, even a small typo can completely break your flow, so be sure to triple check everything.
For complicated configurations, we recommend googling for examples, looking at support forums, and playing around a few times before you build your intended setup, so you know what each feature does and what the limitations are.
This is one of many instances when TestBox truly shines. It provides a sandbox environment so you can test features and make sure they work as you expect. Once you’ve built the configuration you want in TestBox, we’ll make sure you can take that setup with you to jumpstart going live with your production environment.
3. Salesforce integration
If you’re a Salesforce user, the Salesforce integration is arguably one of the best reasons to choose Zendesk. Once it’s set up properly, you have a two-way sync between your CRM and customer support tool.
This allows everyone on your team to have access to in-depth context about all your customer accounts — in Zendesk, you can see all the information about a given customer and their company, while in Salesforce, you can see all the tickets that a given customer has submitted.
That said, we didn’t find the integration to be straightforward.
Backfilling data wasn’t as simple as we expected
The first issue we ran into when connecting Zendesk and Salesforce was the lack of a backfill option — the ability to load data into Zendesk that already exists in Salesforce. At first, we assumed that we hadn’t integrated the two tools successfully. However, after doing some research, we discovered this is how the integration is actually designed.
Numerous articles online suggest different ways to backfill your data into Zendesk. For example you can create custom fields in both Zendesk and Salesforce, map the fields, and then modify the field in Salesforce to get the backfill to load into Zendesk.
We found this a very tedious way to complete the task. Even after we deleted the custom fields, the accounts still showed a label in the Zendesk company list that said “Sync” (the name of the custom field we used for import). While that might be an insignificant inconvenience for some, it clutters up an area that could otherwise be used to store helpful contextual information.
Depending on the number of records you need to backfill, you might want to load your data into Zendesk directly using a Salesforce report. Or use a third-party service to handle adding data to Zendesk.
Not every update in Salesforce syncs with Zendesk
Something else that surprised us was that not every update in Salesforce syncs to Zendesk. Zendesk is only updated when you modify Salesforce fields that are mapped to Zendesk fields. And even then, changes only trigger an update if the change was made in Salesforce a certain way.
For example, when we used the Salesforce UI to manually change a single Zendesk-mapped field, the change was reflected in Zendesk. However, when we used the Salesforce Data Import Wizard to modify Zendesk-mapped fields, the changes were not reflected in Zendesk. That’s because the Salesforce Data Import Wizard uses the bulk API, which does not trigger a sync. This is definitely something to be aware of.
Giving Salesforce users access to Zendesk ticket information
A final observation is that if you want your Salesforce users to be able to access ticket information from Zendesk, you need to set this up manually — it’s not part of the initial integration. You need to follow the directions here to add the Zendesk view to your intended Salesforce views.
The good news is that the more familiar we became with Zendesk, the fewer hurdles we faced. Although we haven’t found Zendesk the easiest customer support tool to learn or configure, that’s probably because it’s incredibly comprehensive and feature-rich. If you have a large customer support team and need to be able to customize it to meet your needs, it’s very likely Zendesk can accommodate you.
If you haven’t tried Zendesk yet, we highly recommend you sign up for a free TestBox account and take it for a spin.