In my last two-part article, we covered what user fields are, how and why to use them, as well as how to update them en masse. In this article, I’m going to share three key use cases for user fields that will make your Zendesk more harmonious for agents and admins alike. 

‍

Challenge 1 - Views to give visibility of VIP customers

Let’s imagine you followed the instructions in my previous article, and now have all your customers designated according to their membership level. In our example, this was a user field called “Tier” with values of either “Standard” or “VIP”.

‍

‍

Great, but how do we make this useful? How do we ensure that our VIPS actually receive a VIP service?  It would be frustratingly slow if all VIP and Standard customer tickets appeared in the same view still, relying on agents to click through to the user each to check their Tier.

Their first simple step, then, is to create a separate View for VIP customers.

Start off by cloning your existing view that you’d like to split in two. That’s at Admin Centre > Workspaces > Views or YOURDOMAIN.zendesk.com/admin/workspaces/agent-workspace/views and then click the three dots on the relevant view and click “Clone”.

Let’s imagine we have very simple conditions at this stage, as below.

‍

‍

Do not worry if you have different conditions to this. The key is applying the same changes to whatever existing conditions you do have, at the next stage.

Let’s go ahead and rename the title to something that makes sense.

‍

‍

Now, all we need to do is to add a new condition to the View, in the All section, that tells Zendesk to only show us tickets from users assigned as VIPs.

Unfortunately, user fields are not accessible as conditions within views. Thankfully, we have a backup: tags! Every ticket requested by a user with the “VIP” option selected automatically has a VIP tag added to their ticket, so we can call on this instead.

‍

‍

Hit “Save” and you’re done setting up this view.

The final stage for our views is to do the opposite; exclude VIP tickets from our standard customer service view (otherwise they’ll appear in both).

Head over to the original view and click Edit. Then, we’re going to add the opposite condition to the above.

‍

‍

You’ll notice that, rather than setting the condition as [Tags: Contains at least one of the following: Standard], I’ve done it slightly differently. Whilst that would work, it’s less bullet proof. Imagine if, next week, a customer service manager adds a new customer level “Premium”, but forgets to update the views. You’d then have tickets from Premium customers appearing in neither your Standard view nor your VIP view.

‍

Our approach, then, is a more open one. We set the VIP view quite strictly (tickets must contain the VIP tag) but set the Standard view to show any ticket that doesn’t contain the VIP tag. This could mean it contains the Standard tag, or any other tag added in the future. It saves your tickets potentially disappearing down a “black hole”, where they sit invisible to agents.

‍

Challenge 2 - SLAs appropriate for each customer tier

Now we’ve got greater visibility of VIP tickets, what about ensuring they have an appropriate SLA?

The simplest solution is to ensure that your SLA makes use of the Priority field in Zendesk.  Navigate to Admin Centre > Business Rules > Service Level Agreements or YOURDOMAIN.zendesk.com/admin/objects-rules/rules/slas

For the sake of brevity, we’ll assume you already have an SLA policy set up. It might not look exactly like below, but will need to distinguish between two different levels of priority to work with the following steps.

‍

‍

With a standard setup like this, in which Standard Tier customers have a Normal Priority, giving our VIPs special treatment is as simple as creating a trigger that sets their tickets to High priority.

Head over to the triggers page at Admin Centre > Business Rules > Triggers or YOURDOMAIN.zendesk.com/admin/objects-rules/rules/triggers

You may well already have a trigger like the one below, that sets a “Normal” Priority for all new tickets, in order for your SLA to run. If you don’t already, create it now.

‍

‍

Without this trigger, none of your tickets will have an SLA applied to them. This is the most common answer to clients of mine wondering why their SLAs aren’t applying to their tickets!

As with the views earlier, all we need to do now is clone this trigger and tweak it slightly. 

‍

‍

‍

You’ll notice that unlike with Zendesk Views, Zendesk Triggers allow us to directly call on our custom user field, Tier. If we couldn’t we could still use tags, of course (this is just neater)!

Ensure you change the action for this trigger to [Priority = High]. This will ensure that all tickets received from customers marked as VIP will have a shorter SLA period, as per your SLA policy.

‍

Challenge 3 - Reduce mistakes and time spent with user fields in macros

Custom user fields can also be referenced using Zendesk’s placeholder function. For example, let’s imagine a common query from your customers is to know something about their account they hold with you, such as their membership end date.

Rather than relying on the agent to check this manually each time, this field can be updated in bulk every week using the process highlighted in my previous article (or via API), and then automatically pulled into a ticket comment using a dynamic macro. It’s simpler than it sounds!

Continuing the example, head over to Admin Centre > Configuration > User Fields or YOURDOMAIN.zendesk.com/admin/people/configuration/user_fields and open the user field that you’d like to reference in your macro. In our case, it’s the one below, Member Expiration Date.

‍

‍

Highlight and copy the Field key, we’ll need that shortly.

Now, let’s make our macro. Go to Admin Centre > Workspaces > Agent Tools > Macros or YOURDOMAIN.zendesk.com/admin/workspaces/agent-workspace/macros and create a new macro.

Name it as you want, and select the action as Comment/description. Write your canned response however you wish and, when you get to the part where you’d like to insert the user field, use the syntax {{ticket.requester.custom_fields.YOUR-FIELD-KEY}}.

‍

‍

To make it easier, you can copy and paste this: {{ticket.requester.custom_fields. then also paste your field key from your custom user field, and finish it off with }}.

Now, when an agent selects your new macro from the Support interface, the message populates like this:

‍

‍

So close, but not quite good enough! First of all, that date format isn’t very conversational. Secondly, we don’t need those hours and time zone adjustment added on - that will just take up more of your agents’ time deleting them.

Thankfully, Zendesk allows us to edit the date format using Ruby formatting. With this in mind, let’s try again:

‍

‍

This time, copy and paste {{ticket.requester.custom_fields. then paste in your field key, then immediately add | date: "%-d %B %Y" }} (including the vertical separator at the start) onto the end. The full stop at the end is part of the grammar of the sentence, it’s not part of the placeholder!

So the syntax is {{ticket.requester.custom_fields.YOUR-FIELD-KEY| date: "%-d %B %Y" }}

With that amended, let’s try again:

‍

‍

Now that is satisfying! With this setup, your agents no longer need to waste time checking an external database for a user’s data, then have to copy and paste it into Zendesk, only to probably need to reformat it anyway. They can respond to the entire customer query in just two clicks and two seconds!

Summary

Having previously covered how to set up custom user fields, we’ve now covered how to expose them to your Zendesk automations as well as your agents. This allows you to get the most out of your custom user fields, whether that be in crafting views and custom SLAs, or in saving time by allowing your agents to effortlessly call up customer data points into ticket responses.

While your specific use cases might vary, these methods and general approaches, as well as the specific tips we covered, should set you well on your way to making the most of your user data in Zendesk.