Introduction

A Zendesk tag is a word or phrase associated with a ticket, user or organisation in Zendesk. Most commonly, they are added to tickets as an attribute to be read by the other parts of Zendesk. In this article, we’ll focus on ticket tags rather than user or organisation tags.

Tags can be added to mark a ticket as: being urgent; related to a particular product; designated for a certain view or to be actioned by a particular trigger. Tags are the backbone of many functions within Zendesk, as they can be added to, or acted upon by, macros, ticket fields, triggers, automations, reports and much more.

Challenge

Tags are visible on just about every ticket within Zendesk, and they play a crucial role in many of the automations that Zendesk offers us. Given this, it can at times be confusing to consider what role they truly play and how we should utilise them best. In this article, I’ll explain exactly what their functions are and how to get the most out of them.

‍

Ticket tags - the basics

Below is a screenshot of the left-hand side of a typical simple Zendesk ticket, showing its ticket fields.

‍

‍

Towards the bottom, we can see the Tags field. This is where all tags currently associated with a ticket are displayed. This ticket seems to contain a tag which is set up to ensure that it shows up in the Sales team’s view. See my previous article, How to construct bullet-proof Zendesk views to learn how to do this.

You can directly edit tags from within this field, either by deleting the existing tag(s), or by typing or pasting in new ones.

Whilst directly editing tags is possible, it’s no longer best practice in most cases. We’ll come on to why later in the article.

Importantly, a tag must have no spaces. If you add a space, it’ll create two separate tags. Hence you’ll often see underscores used in tags to keep phrases together in one tag, as above.

Just like any other edits you make to a ticket, changes you make to tags won’t be saved to the ticket until you click Submit in the bottom-right corner of the page.

Below is an example of the tags present on an enterprise-level account. As you can see, it can look complicated. All of these tags are there for a reason and are informing other parts of Zendesk how to treat this ticket.

‍

‍

‍

Why tags are so useful

As we saw above, tags can be added manually. On top of this, they can be added by macros, ticket fields, user fields, automations and triggers, all of which can do so automatically based on how you set them up.

Conversely, tags can be read (i.e. processed, acted upon) by views, triggers, automations, SLA policies, CSAT surveys and reporting. A trigger or automation could be set up to look for a tag as a prerequisite for firing. SLA policies and CSAT surveys can also be set up so that they only apply to tickets with a particular tag.

Given that many features can be set up to add tags, and a similar number of features can be set up to look for and act upon tags, we can say that tags are the crucial communication channel that enables various parts of Zendesk to talk to each other about a given ticket. 

So a macro can add a tag which then fires a trigger.

Or, perhaps, a time-based automation adds a tag to a ticket that’s about to breach its SLA. This new tag then makes the ticket visible in a view for urgent agent attention.

Alternatively, you can set up each of your macros to add their own unique tag to every ticket they are used on, so you can create an Explore report that shows which macros are receiving the best and worst CSAT scores.

The possibilities really are endless here.

Think twice before manually editing tags

Given that tags have the powerful read/write abilities we discussed above, they effectively become the backbone of many automated processes in Zendesk. Thus it’s particularly important to think carefully before manually adding or removing tags directly in a ticket.

If there’s a tag that you’re about to manually remove from a ticket, ask yourself if you know which automation, trigger, macro or ticket field put it there, why it did so (what was the intended outcome), and what will happen as a result of your removing the tag. For example, whenever you update a drop-down ticket field, Zendesk will automatically add a corresponding tag. If you were to edit this tag, the ticket field may well change too. This could have knock-on effects, such as which views that ticket then appears in.

I like to think of it this way: I improve my client’s Zendesk performance by creating bespoke macros, triggers, reports, ticket fields, views and so on. When I edit one of these features, I program them so that they communicate to each other using tags.

When I then go onto a ticket and see that there are several tags associated with it, I think of this as like viewing the code behind the ticket that is going to make all these helpful processes tick. I can edit that code (i.e. change the tags) but this is like editing the source code of a programme, rather than making changes through the nice and simple UI editor.

If you’re in a rush and know what you’re doing, and it’s a one-off, go ahead and delete a tag that you no longer need. Best practice, however, would of course be to look into which macro, trigger, automation, ticket field or other process is adding tags where you don’t want them, as the ticket you have before you is unlikely to be the only one!

Have a practice by creating a macro that adds a tag, then creating a trigger that fires when that tag is present. This demonstrates the quintessential power of a Zendesk tag; its ability to link together Zendesk’s powerful time-saving features.