In our last article, we discussed best practices when designing Zendesk views. Now that you’ve designed your ideal views layout, it’s time to build it.

As with many functions of Zendesk, there are multiple ways to achieve seemingly the same outcome. Some approaches may be easier to set up but harder to maintain and evolve, whilst other approaches take more time to create but then leave you, the administrator, with an easy job as your stakeholders put in more demanding requests down the line.

Bearing this in mind, let’s take a look at the best approach that balances both these considerations.

A Simple Mistake to Avoid

Let’s imagine our business has four different ways for customers to contact the customer service team. First of all, three email addresses: Info@Company.com, Sales@Company.com and Support@Company.com, as well as a WhatsApp channel.

A very rigid way to set up these views would be to define each view simply based on where the ticket was received.

‍

‍

We’ll come on to the second condition there (regarding Status category) much more later. Status category is synonymous with Status. Status Category is just a new feature that builds on Statuses.

We would repeat this process for the three other respective views.

This works fine initially, and is appealing for its simplicity. But what if a ticket is received at Info@Company.com but the agent decides it’s best suited for the Sales team who manages the Sales view? With the above setup, we wouldn’t be able to send the ticket from the Info view to the Sales view, as the attribute Received at is Info@Company.com will always remain true.

We could create a macro, of course, to add a tag identifying the ticket as a Sales ticket, but that won’t stop the ticket from appearing in the Info view, since the address it was received at is still Info@Company.com.

‍

From Rigid to Flexible

Whilst we do want to achieve a setup as simple as the one above, if we want it to be more dynamic then we’ll need to add a preliminary step before we build our views. As mentioned earlier, there are, of course, other methods of achieving a similar outcome, but this is the one I recommend most for its ultimate simplicity, flexibility and very low chance of enabling a ticket to get lost and not appear in any view.

In the above example, we were using the Received at is Info@Company.com as an indicator that a ticket is intended for the Info team. Given that we can never change the email address a ticket was received at, but we may want to change the team responsible for answering the ticket, we need to find another way to designate the team a ticket is intended for, but this time it needs to be editable.

‍

A Necessary First Step

To do this, we can use triggers to add a tag to all inbound tickets. We will add one tag per Channel/email address, and use this tag as the signifier of the intended team.

‍

The key here is that any ticket received at Info@Company.com will now have the “info_view” tag. 

We’ll use this tag to build our Info view.

Before we do that, a quick note on the order of triggers.

‍

The Order of Triggers Matters

Each time a ticket is created or updated, Zendesk will run it past the conditions of every trigger that you’ve set to active, to see if any are met. The order that these triggers fire can make a big difference (and make your triggers behave not as expected). Although the detailed reasoning behind this is beyond the scope of this article, we still need to make sure we get this right.

On the main triggers page, click “Edit order” in the top right.

‍

Drag and drop the trigger you just made so that these triggers are right at the start of your list of triggers, ensuring they fire first, or at least before any other triggers that don’t use the ticket is created condition. 

‍

‍

Constructing the View

Now, we make the view exactly as before, simply replacing with Received at is Info@Company.com with Tags Contains at least one of the following: info_view

‍

‍

Given that, thanks to our new trigger we just made, every ticket received at Info@Company.com is tagged with the info_view tag, we know that all of those requests to Info@Company.com will initially show in this view.

In short, what we have just done is created a views structure that is based on tags. Tags are extremely flexible as they can be added or removed by triggers, automations, macros and even agents directly.

‍

Allowing Agents to Move Tickets Between Views

Having gone to the effort of ensuring our views are flexible with the tickets they contain, we now need to give agents the ability to easily and quickly move a ticket between views.

Given that the views are based on tags, it’s the tags we’ll want to edit.

Let’s imagine an agent wants to move a ticket from the Info view to the Sales view. We could simply tell the agents to click the X on the info_view tag, displayed on the left of the ticket, and then add the “sales_view” tag in its place, but this is fraught with problems.

‍

First of all, there’s no guarantee that the agent will correctly type in the new tag. Secondly, typing is slower than the alternative we’ll set up. Thirdly, Zendesk admins often heavily rely on tags for all sorts of automations and reporting, and instructing agents to directly tinker with this area is a recipe for disaster (they might unintentionally remove the wrong tag, for example). Finally, what if you want to change your views architecture in the future, in a way that uses tags differently or not at all? You’d have to retrain the agents on the new process which is a waste of time, given it’s easily avoided.

The best practice for ensuring a simple agent process that is consistent for them but that you can tweak behind the scenes when you want to is to use macros. This way, the instruction for agents can always be “to send a ticket to the Sales view, use the ‘Send to Sales’ macro”, even if you change how the macro achieves that outcome in the future.

‍

A Simple Yet Powerful Macro

Given that we’ve now built our views on tags, all we need to create now is a macro which removes the undesirable tag and adds the appropriate one. From an agent’s perspective, it can be as simple as the macros below.

‍

‍

So, we want a ticket to display in the Sales view, and not any other view. We know that the requirement for it to display in the Sales view is to have the sales_view tag. And we also know that the requirement for it not to display in any other view is simply to not have any other view tags.

Thus we can make the macro as below:

‍

‍

Whilst adding the sales_view tag to make the ticket appear in the Sales view is an obvious one, the other action is one we must consider for a second longer.

To ensure the ticket doesn’t appear in any other view, we need to tell this macro to remove any other view tags that we know of. If we only tell it to remove the info_view tag, for example, then the macro will not work for tickets in the Support view, as that tag wouldn’t be removed.

Historically Zendesk admins were stuck with copying all of the tags that they create into a spreadsheet in order to help tasks like this, as missing one would cause all sorts of agent confusion. Today, admins can see which views are reliant on which tags with the touch of a button in Salto’s free version that makes tasks like this much simpler and foolproof.

With this macro setup, agents can move tickets from one view to another, regardless of where the ticket was initially sent. Congratulations, you’ve just created an easy to use, robust Zendesk views setup!

‍

Pending Tickets

As you saw in our view setups, there was one extra condition that is well worthwhile including in most standard views.

Zendesk’s ticket statuses are largely used to inform whether it is the agent or the requester who is required to reply next. New and Open mean that the requester is waiting on a response. Pending, however, means that the agent has responded to the requester and has done all they can without a further requester response. If the requester doesn’t respond, it’s typical to create an automation that will automatically solve Pending tickets after a few days. This helps keep the agent’s views clear of tickets they don’t need to be concerned with.

Further to this point, most customer service managers will want these Pending tickets hidden from agents' normal workflow. This is because the fact they are marked as Pending means the agent doesn’t need to take any action.

To this extent, we add that second condition into all of our primary views: Ticket status less than Pending (less than Pending means New or Open).

‍

‍

This keeps agents’ views nice and clear of distractions.

But what if an agent or manager does need to easily find a Pending ticket? The answer is to simply create a view with only one condition: Status Is Pending. Given how rarely used this view is, it’s typically not worth splitting it out by channel, all Pending tickets can simply be shown in one view.

‍

Summary

Using tags in place of rigid conditions, we have seen how our views can be truly flexible. Using macros also allows us to keep the agent experience incredibly simple, whilst the use of triggers with tags keeps the door open for more advanced requirements that may crop up in the future.