Whether you work for a small startup with a few dozen tickets per day or a large corporation with monthly tickets in the millions, configuration naming conventions is one of those Zendesk best practices that never fails to produce good results and save time. Let’s see a few examples of how you can become even more organized in Zendesk Support.

Naming business rules

Especially when cleaning up large accounts, it’s common to bump into triggers/automations named “New accounts email” or “Pending tickets 24 hours”, for example. Can we guess what they might be doing? Sure. Can we be certain of what they’re doing exactly, however? Not really. That’s why we need naming conventions.

For both triggers and automations, we start by agreeing on a separator. I’ve used Zendesk’s drop-down level separator “::” in the past, nowadays I’ve simplified to a simple “•” bullet (using the shortcut keys Alt + Num 7). It’s one character less and it looks neat.

Then we add the trigger title sections: who it applies to, how it is applied to tickets, context (environment, medium, group, etc), and a short, objective description of its goal.

Example: ALL • C • Social – Private • Facebook + Twitter • Notify user during off-hours

Just by reading its title, we could deduce that this trigger:

  • Applies to all brands (as opposed to ‘B1’ for Brand 1) = ALL
  • Only runs when a ticket is created (I use ‘U’ for when it runs on updates, ‘CU’ when both) = C
  • Only runs for private social channels = Social – Private
  • Only runs for Facebook and Twitter = Facebook + Twitter
  • Notifies the requester during off-hours, which means that it probably contains schedule-based conditions.

🧐 Side-note: to see what this specific trigger does and how to set it up, see Automatically add comments to tickets.

These trigger names might appear long but – from personal experience – people easily learn to interpret them over time. In any case, admins and whoever usually troubleshoots workflows are the main stakeholders, so make sure they are all onboard regarding these naming conventions.

Of course, there’s no perfect way to do this! There aren’t ideal naming conventions for anything. Just do what works best for you.

Tags: meaning and readability

First things first. Unless you enjoy chaos, make sure to disable auto-tagging. In general, we don’t need Zendesk deciding what three keywords are the most important. AI-based features that interpret sentiment and context are around the corner, so we should refrain from cluttering our tag bucket with unnecessary tags.

How are ticket tags a part of Zendesk best practices? Well, it’s always a good idea to establish tag prefixes. We use these two/three-character long expressions to help identify the origin of the tag or what it’s about.

Tags starting with admin_, for example, are used as core tags that are constant (i.e. they will not be removed from the ticket). We use this prefix quite often for unchangeable, administrative-level [custom] drop-down fields that are hidden from agents but whose tags are visible nonetheless. And because they start with “admin”, everyone knows they shouldn’t touch them!

Another prefix we use is zd_, for workflow/operational tags that may be removed from the ticket at some point, that is, they can be temporary during a specific process or workflow. For example, we have triggers that add a zd_lastrep_ tag corresponding to who commented last (requester or agent).

I also make sure that drop-down, multi-select and checkbox values have coherent tags that allow us to identify the field they belong to. So if we have a drop-down for “Topic”, for example, its values will likely be tagged as topic_. If it’s only applicable to Brand A1, for example, the tag is prefixed a1_topic_.

For user field values, you can decide to always add user_, for example. For organizations, org_. You get the picture!

Again, you may want to use another structure of prefixes, obviously. Instead of the admin_ prefix, cf-dd_topic_ can also work! This prefix would tell us that it’s a custom field and a drop-down, while cf-ms_ would indicate a multi-select. As an admin, work with the team if you feel their input is relevant for these details.

Tags and reporting

Sometimes you need to report on tags that you might not keep on the ticket, so we use a prefix like ‘metrics_’, for example.

Example: let’s say we add a ‘zd_pending_6h’ tag when tickets are pending for 6 hours. If the requester replies, we remove it. So how can we later report on tickets where this happened?

The solution is simple: we also add a ‘metrics_zd_pending_6h’ which we’ll never, ever remove from the ticket!

OK…“, you think, “but don’t follow-up tickets inherit the initial ticket’s tags?” You’re absolutely right! Please read on 👇

Tags and follow-up tickets

One of the most essential triggers we usually create in Zendesk client accounts is placed at the top of the trigger list. Its only goal is to clean up tags on follow-up tickets. This is only necessary if you need to preserve some of the initial ticket’s tags (there may be Zendesk accounts where we want to reset the whole thing).

Using a previous example, if a follow-up ticket is created containing the tags ‘zd_pending_6h’ and ‘metrics_zd_pending_6h’, we’ll need to remove them.

Yes, this means that for every new zd_ prefixed tag that we create, I’ll edit this trigger to contemplate its removal. Welcome to Zendesk maintenance 101! 🧹

Documentation is essential

Just one more thing… A useful piece of advice: whether or not you decide these things on your own, make sure you create an accessible page/document/etc with a glossary and explanation of the tag structure, so that anyone on the team can be aware and learn about your tag organization and naming conventions.

That’s a wrap! Separators, title sections, tag prefixes… these are just a few examples of how we can keep our data tidy and organized. Consistency is key, though, so give it some thought before implementing things that can’t be changed later, especially because it isn’t possible to edit closed tickets.

How about your own naming conventions? Feel free to share in the comments below, and thanks for reading!

article Written by

Pedro Rodrigues, Zendesk and CX consultant

Pedro Rodrigues

Senior Zendesk system administrator and customer-centric project manager dedicated to CX who also contributes as a Zendesk Community Moderator. Experienced in content management & SEO, reporting and analysis. Special skill: an eagle-eye for detail.