Mastering Zendesk: Master the art of providing effective IT services to your customers by leveraging Zendesk

Triggers and automations are part of the Zendesk business rules. While triggers take action when a ticket has been updated or created, automations take action after a specified amount of time. Out of the box, there are seven active triggers and one active automation.

Serving as examples, they also cover the most basic business rules for a functioning setup:

Views are a pool of tickets, filtered by a list of set criteria. They are a crucial part when it comes to managing your ticket workflow. For example, if you offer different levels of support, views can be used to divide your tickets in Tier 1 and Tier 2 support.

A macro is a templated response for agents, that can be used to answer customers. Mainly used to ensure the same level of support by providing macros for your agents, macros are more than just text modules. Creating macros, you can choose specific ticket properties that you would like to change upon use. Good examples are, adding a predefined tag, changing the status of a ticket, and setting custom fields whenever an agent uses a macro.

A Service Level Agreement (SLA) can be seen as a contract between you as a service provider and your customers, outlining the level of service that can be expected in a certain time frame. This feature is also helpful when using reports to review your team's performance.

Groups can come very handy when defining and implementing workflows. For instance, a trigger could check a ticket for the keyword "lawyer". If the keyword is found, the ticket is pushed to the group "supervisors". Now, only agents in that group can access that specific ticket.

Each user (including end users) can be assigned to an organization. This can be useful in a handful of different scenarios such as restricting certain content in your help center to only one organization. Like a lot of Zendesk's options, you may come up with your own purpose of use.

Zendesk categorizes all the preceding elements under the Ticketing Workflows and Efficiency heading:

While customers should have different options when trying to contact support, in many cases companies decide to limit the options dramatically in order to reduce the number of support tickets.

In our case, ExampleComp wants to give their potential customers the freedom to contact support anytime during their customer journey and decides to open the following channels:

Having decided on the desired channels, we can now decide where to place those channels on our customer's journey and add some more describing details.

Now that we have established the channels ExampleComp would like to use, we can start shifting our attention toward each ticket's individual journey.

First of all, we need to remember that not all channels should be treated equally. Meaning that different channels will require different SLA rules. It is a common practice, for instance, that support requests created via Facebook are being escalated quicker than tickets created via the e-mail channel. The reason for that seems to lay with the customer's expectation of service depending on the channel used.

Keeping that in mind, we can quickly sort our channels list by their supposed priority into the following groups:

Knowing that group 1 and group 2 have to be handled differently when it comes to escalation rules, we can take note that both groups have to be marked differently when the ticket is being created. Let's name each group. In this case, since we only have two different groups, we do not have to be too descriptive when naming them:

Next, we need to remember our VIP customers, whom ExampleComp promised special treatment when it comes to support requests. We could simply adjust our business rules to escalate those tickets even quicker than our normal tickets, by creating a third group. In this case however, we will simply funnel them into a separate view. That way we can assign special agents to only serve our VIP customers. We also allow those agents to get accustomed to our most valued customers.

But how do we tell normal customers apart from VIP customers?

At this stage, we will not worry about the actual implementation, but note that VIP users need to be marked as such. We should make a habit out of collecting these kind of questions as we will revisit them later throughout the process.

So our current ticket flow would look a little like that in the following figure:

First, each ticket is assigned an escalation type depending on the channel. After the tickets have been marked accordingly, the system should then commence marking those tickets that were created by a VIP customer.

While this seems to be a very rough concept only scratching at the surface of our final setup, this is the level of detail we want to focus on right now.

Ticket views

Next, we can move on to our ticket views, which we will need in order to divide and pool certain tickets together. In this case, it was decided to not separate the views by languages. While ExampleComp offers support in two languages, it currently only hires bilingual agents.

That is why we only split our support into three main categories:

• Tier 1 Support

• Tier 2 Support

• VIP Support

We should keep in mind that ExampleComp will offer support in more languages later on. It should be made fairly easy to divide tickets depending on the requester's language settings in the future.

Our updated ticket flow would look a little like the following figure:

While VIP tickets will land directly in the corresponding VIP Support view, all non-VIP tickets will initially land in the Tier 1 view. Agents can then decide to push them into the Tier 2 view if the customer needs more technical help.

Sorting all our tickets by priority within their corresponding views, we can leave the actual sorting process to our business rules.

Agent workflow

Having created a rough sketch of our initial ticket flow from the moment where a ticket is created up to the point where it can be picked up by agents, we can now move on to a rough outline of the agents' workflow. That also entails planning what happens to the ticket once one of the agents replied to it.

Let's start by creating a quick numbered list of what a typical workflow for a Tier 1 agent would look like:

1. Opening the assigned view.

2. Picking the first ticket with the highest priority.

3. Answering the ticket or pushing it to Tier 2 support.

4. Moving on to the next ticket.

Looks easy enough. But what happens if a customer replies? There are many ways to handle customer replies. Let's review the two most common ways to do so:

• The ticket can simply be reopened and made available in its initial view, allowing any agent to pick it up in order to commence support.

• The ticket can still be assigned to the same agent, who will then commence helping that customer if possible. The agent can receive an e-mail notifying them about the customer's reply. But what if our agent stopped working already? Well, a business rule can remove the assignee (assigned agent) after a specific amount of time since the last ticket update. Doing that would force the ticket back into its initial view where another agent can then take care of the customer.

For the sake of adding a bit more complexity, we will go for the second option.

Let's take a look at our updated ticket flow, shown in the following figure:

Having added a little more complexity, we should break down the process into a few steps:

1. A customer creates a ticket via one of our open channels.

2. Depending on the channel, tickets are assigned to one of the two escalation types.

3. If our customer is a VIP, we mark the ticket accordingly.

4. The ticket is now either in the Tier 1 or our VIP view.

5. An agent opens the ticket and decides whether to answer or push the ticket to the Tier 2 view for more complex support requests.

6. The customer receives a reply.

7. If the customer replies, the ticket shows up in the agent's own view. The agent receives an e-mail notification.

8. If the agent does not update the ticket with a given time frame, the ticket is moved back to its initial view.

9. Another agent can now pick up the ticket.

Obviously, we are still looking at a very rough outline of our support's workflow. We are only describing what should happen to our tickets on the surface. However, creating such a simplified version has a lot of advantages. The ticket flow can be understood without a deeper knowledge of Zendesk. Other departments can weigh in at this point and the process can be reworked as many times as necessary until we know what the overall desired outcome should look like.

For instance, we remember that ExampleComp offers their own hardware devices. Those products are being manufactured by a third-party company. That third-party company has to use ExampleComp's software on a regular basis. This practice regularly results in support requests by that third-party company. What if, in a meeting, it is decided that those requests should not be handled the same way as other customers' requests? As we are still in the process of planning our overall workflows, we can now easily add that suggestion to our overall concept and communicate the revised plans to the management. In this case, we can simply add another step where we check if the ticket was sent by our third-party company. If so, the ticket would be marked accordingly and show up in a dedicated view. Everyone involved understands the new plan right away and we can move on to finalizing the concept.

At this point, I would like to suggest that you create a new version of the flowchart by adding the new option discussed earlier.

Before we can create our final list of tasks as well as our road map, we should review our work so far. While some implementation tasks might become quite obvious, such as setting up the right views, looking at our plan we might wonder how we can achieve certain objectives. For now, we will only focus on those parts. Obviously, this is just an example. When planning your own Zendesk setup, you might already know all the answers, but the questions might be different altogether.

In order to come up with the right questions, let's start by going through our flowchart while keeping the overall process in mind:

The initial questions that come to mind are:

How can we actually know if a ticket requester is a VIP? How can we know anything about our customers when they contact us?

Clearly, it is not possible to get customer information in every scenario. In many cases, requesters might not even be customers yet. Therefore, we should focus on those cases where we can get the information and choose the right solution for us. In our case, there are two different types of information that come to mind:

While we do need to know if a user is in fact a VIP while the ticket is being created, it would be totally fine to receive information such as "products bought by the customer" when first opening the ticket. We already know, at this point, it will not be possible to get this information via a ticket created through Facebook, Twitter, or the standard Zendesk widget.

We could, however, allow the VIP information to be transferred to our Zendesk environment when a customer is using our support form. As we have the option to program on our own or change the existing support form, we can easily achieve this. Another way of achieving this would be using the Single Sign-On (SSO) technology for our end-users, which would allow us to set user tags. There are many ways that would lead us to the same outcome, some of which we will cover later in this book.

If we want to know more about our customers while answering their requests, it would be helpful to create our own little Zendesk app to help us out. Most companies have a unique identifier for each customer. In our case, we could use the customer's e-mail address. We could either display a generated link, that would open the companies backend, displaying the necessary information or we could go one step further and query those information from our servers and then display them within our ticket view itself. We will cover both options later in this book.

As a result of our two preceding questions, we can record the following:

Information that will help us classify the ticket. In our case, is the user a VIP?

Information that will help us solve the ticket, such as what software did the user buy?

Our next questions would be:

How can we classify tickets as either EscalationTypeA or EscalationTypeB? How could we escalate these tickets differently depending on those two types?

In order to do that, we could simply create two Zendesk triggers and a custom ticket field. The first trigger would check whether the ticket was created via a social media channel. If so, it would set the custom ticket field to EscalationTypeA. The second trigger would check whether the ticket was created via any of the other listed channels. In that case, it would set the custom ticket field to EscalationTypeB. Both triggers could also assign the initial priority.

In order for the tickets to be escalated depending on the type, we can make use of automations. By setting up a few automations for both cases, we can easily check the type of the ticket and escalate the ticket after a certain amount of time. Here is an example automation:

Name: Escalation Rule - EscalationTypeA - Ticket age > 1 hour -> Escalation Level: High

Knowing how we would like to integrate our business rules for the purpose of ticket escalation, we can now decide on the exact rules and create a list of triggers and automations we will need to create.

Before we do that, however, let's take a look at our complete flowchart again in order to come up with the next questions:

Looking at our flowchart, the next question that comes to mind is:

How can we allow agents to push tickets to the Tier 2 view?

Right off the bat, I can come up with three different ways to achieve that. All of which will need a ticket field that either says tier1 or tier2. In any case, we will need to create a trigger that sets the ticket field to tier1 as soon as a ticket has been created.

Now we can allow the agent to do three different things:

While I prefer the third option because of speed, we might want to start with option 2 and integrate option 3 later on.

Having found all the answers to our questions, either by online research or having used this book as a guide, we can move on and create a quick list of tasks. We can do this using our flowchart, the answers to our questions, and the overview of a basic Zendesk setup. So let's start listing our main tasks without any details and without worrying about a specific order.

We need to set up the following:

Looking at each element on our list, we should already be able to envision all the subtasks and how everything snaps together as a whole. If not, it is probably best to review the flowchart and go through all the steps of the initial planning phase again as well as to review all the elements of a basic Zendesk setup.