Zendesk Best Practices

Not the generic list. These are the six Zendesk best practices that are actually missing from most accounts after two years, and what to do about each.

Zendesk best practices: you have too many views

Views multiply because they're easy to create and nobody deletes anything. Then the sidebar has forty entries, agents scroll past the important ones, and two views overlap so the same ticket looks unclaimed in one and handled in another.

The fix is unfashionable: delete most of them. An agent needs their own queue, their group queue, and something showing what is breaching. Everything else is a search, and Zendesk search is good enough that a saved view is rarely the right container.

Order matters as much as count. The view an agent should work from must be first, because whatever is at the top is what gets worked. The views guide covers shared views and the ordering rules.

Your macros have no owner

Every account accumulates macros. Someone builds one for a campaign, the campaign ends, the macro stays. Two years later there are one hundred and forty, twenty are in daily use, and eleven contain wording that's no longer true.

Give every macro a named owner and a review date. Then look at usage: Zendesk can show you which macros are actually being applied, and the long tail of never-used macros should simply go. Agents can't find the good ones through the bad ones.

While you're there, check that macros set fields and not just text. A macro that inserts a reply but leaves the tags blank is quietly damaging your reporting.

Your tags are a landfill

Tag sprawl is the most common data problem in Zendesk and the least visible, because nothing breaks. You just slowly lose the ability to answer questions.

Free-typed tags. Agents can create a tag by typing it, so you end up with billing, Billing, billing_issue and bill all meaning one thing.
No convention. Decide on a shape, lowercase with underscores, prefix by category, and write it down. topic_billing and action_refunded beat a flat vocabulary.
Tags doing a field job. If you need to report on it, filter on it and guarantee it is set, it should be a custom field with a fixed list, not a tag.
No cleanup. Merge synonyms in bulk, retire the dead ones, then set macros so the right tags get applied without anybody typing.

The tags guide goes through the cleanup. Do it once a year and it takes an afternoon. Leave it five years and it's a project.

Nobody knows what your triggers do

Open the trigger list in an account that is a few years old. You'll find names like "Notify" and "Copy of Notify 2", ordering that matters and is undocumented, and at least one rule everyone is afraid to switch off.

Three practices fix this permanently. Name triggers for what they do and who they affect, so the list reads as a sentence. Use the description field, which exists and which almost nobody fills in. And when you deactivate one, deactivate it for a month before deleting, because the thing that breaks will break within a billing cycle.

Also: exclude your integration accounts from every notification trigger. A sync job updating five thousand tickets should not send five thousand emails, and the day it does is a bad day. The automation overview sets out which tool should own which behaviour in the first place.

Your reporting is measuring the wrong tickets

Two specific distortions turn up in nearly every account.

First, administrative closures counted as work. Tickets closed by merge, spam, and tickets an agent opened to test something all inflate volume and flatter solved-per-agent. Exclude them from the denominators and the numbers move, sometimes a lot.

Second, first response time measured against a business clock nobody configured. If your schedule doesn't match when your team is actually working, every SLA metric you report is fiction. Check the schedule before you argue about the number.

And pick fewer metrics. A team tracking four numbers well beats one tracking fourteen badly, because with fourteen nobody can tell you which one moved and why.

You never write anything down

The last one is the one that makes the other five recoverable. Keep a change log for the account: what changed, when, by whom and why. A shared document is fine.

Zendesk has an audit log, and it will tell you what changed. It can't tell you why. Six months later, when a trigger is causing a problem, the difference between an afternoon and ten minutes is a single line somebody wrote. Pair it with documented procedures so the operational side is written down too.

FAQ

Frequently asked questions

What are the Zendesk admin best practices that matter most?

Fewer views, owned macros, disciplined tags and written change notes. Zendesk setup best practices are mostly about restraint, and the Zendesk tips that survive a year are the ones that delete things.

How many Zendesk views should a team have?

Far fewer than most have. An agent queue, a group queue and a breach view covers most needs. Anything else is usually better served by search.

Should we use tags or custom fields?

If you need to report on it reliably, use a custom field with a fixed list. Tags are free text in practice, and free text becomes four spellings of the same word.

How often do Zendesk best practices say to audit triggers and macros?

Once a quarter for triggers, once or twice a year for macros. Both take an afternoon if you keep up and a fortnight if you do not.

What's the most common Zendesk reporting mistake?

Counting administrative closures as solved work. Merged, spam and test tickets in the denominator make every per-agent number look better than it is.

Is it safe to delete an old trigger?

Deactivate it first and leave it for a month. Anything depending on it will surface inside one billing cycle, and reactivating is easier than rebuilding.

The practice nobody keeps up

Checking for an existing ticket before you answer. Ticket Merger does it on every ticket, automatically, forever.

Start free trial

14-day free trial. No credit card required.