Zendesk Procedures
Every support team has procedures. Most live in one senior agent's head, and the rest in a document last edited eleven months ago. Zendesk procedures should live in the ticket.
Put Zendesk procedures where the work is
The single biggest predictor of whether a procedure gets followed is how far the agent has to travel to read it. A wiki in another tool loses to a macro every time, not because agents are lazy but because they're handling a queue.
So the hierarchy is simple. If the procedure can be a macro, make it a macro. If it needs branching, make it a guided workflow. If it is genuinely reference material, put it in an internal help centre article and link it from the macro. A document in a shared drive is the last resort, and it should contain only the things that are not about handling tickets at all.
One test tells you whether a procedure is in the right place. Ask an agent handling a live ticket to find it. If they have to leave the ticket, switch tool and search, the procedure is in the wrong place and it will be followed about half the time.
Macros are procedures, whether you meant that or not
A macro that sets the status, adds the right tags, assigns the right group and inserts the right wording is a documented procedure that executes itself. That's a much better artefact than a paragraph describing what an agent ought to do.
Write them that way deliberately. Name them for the situation, not the outcome, so an agent scanning a list finds "Refund requested, under 30 days" rather than "Refund macro 2". Include the field updates even when they feel like paperwork, because those fields are what your reporting later depends on.
The macros guide covers organisation and naming. The thing to add here is ownership: every macro needs a named owner, and a macro whose owner has left the company is a procedure nobody is maintaining. Review the top twenty by usage each quarter, because those are the ones customers actually read.
When the procedure has branches
Some processes are decision trees. Verify identity, check the account state, choose one of four paths, escalate if none of them apply. A macro can't express that, and a paragraph explaining it will be read once.
Two Zendesk mechanisms help. Ticket forms with conditional fields make the branch structural: the agent or the customer answers a question, and the next field appears based on the answer. And guided mode constrains how agents work through views, which suits high-volume, low-discretion queues where consistency matters more than autonomy.
Be honest about which of your processes really branch. Most teams discover they have three genuine decision trees and forty tasks that were only ever complicated by being written down badly.
The internal knowledge base
Everything that will not fit in a macro belongs in an internal help centre, visible to agents and nobody else. Escalation contacts, the shape of a good bug report, how to handle a legal request, what to say when the status page is red.
Two rules make it work. Every article has an owner and a review date, and an article past its review date is flagged rather than quietly trusted. And every article is written as instructions, in the second person, with the steps numbered. Background prose isn't a procedure.
The internal knowledge base guide covers permissions and structure. Keep it small. A hundred internal articles nobody has read is worse than fifteen everyone has.
Keeping them current, which is the hard part
Documentation rots. The only thing that reliably stops it is attaching maintenance to something that already happens.
None of that is exciting. All of it's the difference between a documented team and a team with documents.
Frequently asked questions
Where should standard operating procedures live?
Where the work happens. Zendesk standard operating procedures kept in an internal article and linked from a macro get followed; the same Zendesk SOP in a wiki does not. Zendesk process documentation is only as good as its distance from the reply box.
Where should support procedures live in Zendesk?
As close to the ticket as possible. Macros first, guided workflows for branching processes, internal help centre articles for reference, and a shared drive only for things that are not about tickets.
Is a macro really a procedure?
Yes, and a better one than prose. It sets status, tags, assignee and wording in a single action, so the procedure executes rather than relying on memory.
How do we stop procedures going stale?
Give each one a named owner and a review date, and make the person who changes a policy update the macro the same day. Backlogged documentation work never happens.
How many internal articles should we have?
Fewer than you think. Fifteen articles everyone has read beats a hundred nobody trusts. Retire anything unused for a year rather than leaving it to mislead someone.
Can Zendesk enforce a procedure?
Partly. Conditional ticket fields make branches structural and guided mode constrains how agents work a view, but nothing stops an agent typing freehand if they want to.
One procedure worth automating
Checking whether this ticket already exists is a step nobody does consistently. Ticket Merger does it on every ticket.
Start free trial14-day free trial. No credit card required.