Automating Zendesk: How to Design Processes That Scale
Every process is a series of decisions
Your entire support operation, every workflow, every routing rule, is built from the same basic unit. A customer comes in with a question. You need some information. A decision gets made. Something happens.
That’s it. Your larger support process is dozens of these strung together in a flow chart. The customer arrives through your web form, your chatbot, over the phone, and you work out what the question is, what information you need to answer it, and what the outcome should be.
So let’s take one of these decisions and build it out. The customer has got in touch, we’ve already worked out what their problem is, and they’re asking for a refund.
The decision: do we refund?
You can’t give out refunds all the time. You can’t refund someone who’s happily using the product. You can’t refund someone whose order is still in transit and will arrive Tuesday. There are things you need to know before a result is possible.
So there’s a decision to be made, and it has three possible outcomes: yes, no, or maybe. The maybe is your escalation path, where a senior person takes a closer look.
The information feeding that decision comes from your other systems. Is the account in good standing? Has the customer received the product? Is it in transit? Is payment completed? You need to check your logistics partner, your payment provider, your order management system.
This is the same pattern for every process. Refund requests, “where is my order” queries, cancellations, account changes. The specifics differ but the structure is always: what’s the question, what information do we need, what’s the decision, what happens next.
Mapping this to Zendesk objects
The fact that the customer wants a refund lives in a dropdown field on the ticket. Zendesk calls these taggers in the API, because they’re a preselected list of tags. You use a tagger rather than a free-text tag because a tagger says these options are mutually exclusive. This ticket is a refund query, not a “how do I use your product” query. One thing at a time.
So you have an inquiry type field set to “refund.” Then I’d have a conditional field that only appears when inquiry type is refund, asking: is this refund actionable? Three options: yes, no, escalation.
Why macros handle the decision and triggers handle the action
This is the key design principle, and it’s the reason the process scales later.
When you start out, a human person logs into wherever the information lives, checks the account, checks the delivery status, makes a decision. The way they record that decision on the ticket is with a macro.
A macro in Zendesk is a preselected batch of actions that are manually applied. But a macro can be modified before it’s submitted. When you click a macro it applies the changes and gives you a chance to review before you hit submit. So the macro doesn’t send the response or take the actual action. The macro just changes the tagger field to yes, no, or maybe.
The actual response to the customer, the thing that happens next, that’s in a trigger. The trigger fires when the field changes from no value to yes, no, or maybe.
Why separate them? Because when you improve the process later, you don’t need to rework everything. The trigger that sends the response doesn’t care whether the decision was made by a human clicking a macro or by another trigger evaluating field values. The action layer stays the same. You only change the decision layer.
From manual to automated
Once the basic process is running manually, the first improvement is getting that external information into Zendesk. Set up webhooks or middleware that pulls in delivery status, payment status, account standing. All of it needs to land in ticket fields, because you can only trigger on field values.
If you’re a Shopify retailer, you might pull fulfilment and delivery tracking data into the ticket. Payment status might come from Stripe or GoCardless. For a lot of businesses, something like Zapier handles the plumbing between these systems and Zendesk, and that’s a perfectly good approach for getting started. You can always replace it with custom webhooks later when the volume justifies it.
Now you replace the macro with a trigger. If inquiry type becomes “refund” and delivery status is not “in transit” and payment status is “completed,” then set the actionable field to yes. The human is out of the decision loop.
The trigger that sends the response to the customer still works exactly as before. It doesn’t know or care that the decision is now automated. That’s the payoff of separating decision from action.
Automating the action too
The yes trigger used to put the ticket into a view called “refunds to be actioned,” where someone would periodically work down the list processing refunds in Stripe or GoCardless or wherever.
Replace that with a webhook. The trigger fires, sends a webhook to your payment provider, and the refund is actioned automatically.
Then you need a mop-up automation. A few hours later, hit the webhook again and check that the refund has actually been processed. Payment providers can have latency. If it’s confirmed, send the customer a message: “Your refund has been processed, you’ll see it in your account within five working days.” If it hasn’t gone through, escalate to a senior agent who can log in and investigate.
The security benefit people don’t think about
Once the information is flowing into Zendesk automatically and the decisions are automated, your agents don’t need a second screen. They don’t need to be logged into Stripe or your payment provider. And frankly, they probably shouldn’t be. Having your agents en masse able to look at payment details is a security risk.
Bin off the agent needing a second screen. Bin off the agent making the decision, because humans introduce bias and mistakes. Automate both, and keep the escalation path for the cases that genuinely need a person.
Seeing the whole picture
The challenge with this approach is that as you build out more processes, your trigger list grows. You end up with dozens of triggers interacting in ways that aren’t obvious from looking at them individually. Which triggers fire on a refund ticket? What order do they run in? Does the automation that checks payment status conflict with the trigger that updates the customer?
This is exactly what Beacon is for. It maps your entire trigger chain so you can trace a ticket from creation through every trigger that fires, see what each one does, and spot conflicts before they cause problems. When you’re designing processes like this, being able to see the full picture in one place is the difference between confidence and guesswork.
This is one decision. Your support operation is dozens.
You do this for each process that comes up. Refunds, cancellations, order changes, “where is my order” fulfilment queries, account queries, technical support escalations. Each one follows the same pattern: map the decision, separate it from the action, start manual, bring the information in, automate the decision, automate the action, keep the escalation path.
You end up with a lean support team where agents handle the cases that genuinely need a human, and everything else runs without them.
This article is based on a Deltastring whiteboard session walking through process design for Zendesk automation.