Smart Ticket Routing in Zendesk: Assign to Groups, Agents, or Both

Zendesk gives you real tools for this — triggers, omnichannel routing, skills, queues. They work, and you should use them. But every one of them routes on metadata: the support address a ticket came in on, a tag, a form field, the channel. None of them reads the actual sentence the customer wrote. That's the gap Macha fills. Macha is an AI agent layer that sits on top of the Zendesk you already run — it doesn't replace your helpdesk, it reads each incoming ticket, understands what it's about, and then calls Zendesk's own assignment APIs to route it.

This post is a deep-dive on the two tools that make that work: Assign Ticket and List Groups, both updated on May 2, 2026 so an agent can route to a group, a specific agent, or both at once. I'll show how they fit together, how to wire up the trigger, where this beats native trigger routing, and — honestly — where you should just use a Zendesk trigger instead.

How Zendesk routes tickets today (and where it stops)

It's worth being precise about the native options, because Macha is meant to complement them, not duplicate them. Per Zendesk's own routing and automation documentation:

• Triggers run on ticket create/update and can fire a Ticket > Group or Ticket > Assignee action — the classic "tickets to this support address go to that group."
• Omnichannel routing pushes tickets to available agents by capacity across email, messaging, and voice; it's on all Suite plans, but routing by skills, priority, SLA, and custom queues requires Professional or higher.
• Round robin distributes evenly through the agent pool — but, as Zendesk notes, it "does not consider ticket complexity or expertise."
• Skills-based routing matches tickets to agent attributes, the closest native thing to content-aware routing.

It also helps to be clear on push vs. pull, because the two native models behave differently. Triggers and views are a pull model: a trigger drops the ticket into a group queue, and agents pull the next one off a shared view. Omnichannel routing is a push model: Zendesk assigns the ticket directly to an available agent based on their capacity, status, and (on Professional and up) their skills. Skills-based routing is the closest native thing to content-aware routing — but a "skill" is still a tag you attach with a rule, so it inherits the same problem: something earlier in the pipeline has to have already understood the ticket well enough to label it. Push gets work onto a person fast; pull keeps a team in control of what they take. Neither one reads the ticket.

The common thread: every native decision is made from structured signals. A trigger condition can check a tag or a form field, but it can't tell that "I was charged twice and need this fixed before my flight" is an urgent billing issue. You'd have to first apply a tag — which means another trigger, another keyword list, and the brittleness that comes with it. As eesel's Zendesk routing guide puts it, native rule-based routing "struggles with nuance" and gets unwieldy as volume grows.

Here's the split laid out plainly:

So the honest framing is: use triggers for the routing you can express as a rule (this channel → this group), use omnichannel routing for workload balancing, and add an AI layer for the routing that depends on what the ticket says.

The two tools, and why "group, agent, or both" matters

Macha's Zendesk connector exposes the full ticket toolset — read tickets and custom fields, post replies and notes, update status/priority/tags — plus the two we care about here. (You can see the complete list on the Zendesk integration page.)

List Groups is a read tool. It returns every active group in your Zendesk — "Billing," "Tier 2 Support," "Logistics," "VIP" — with each group's ID. This exists because the AI thinks in names but Zendesk's API assigns by ID. List Groups is how an agent resolves "this is a billing ticket" into the numeric group ID the assignment call needs, without you hard-coding IDs that break the moment someone renames a team.

Assign Ticket is the write tool that does the routing. As of May 2 it accepts:

That third option is the one teams ask for most. In Zendesk's data model an assignee normally belongs to a group, so assigning a person and setting the group keeps reporting, SLAs, and views consistent — the ticket shows up in the group's queue and on the right agent's plate. Before this change you had to pick one; now a single Assign Ticket call does both. (Macha's Freshdesk and Gorgias connectors have the same group-routing capability, so the pattern carries across helpdesks.)

The split between a read tool and a write tool is deliberate. List Groups → reason → Assign Ticket is a clean, debuggable chain: you can see exactly which group the agent resolved to and why, instead of a black-box "it assigned it somewhere."

Building a routing agent, step by step

Here's the actual build. The goal: every new ticket gets read, classified by topic, and routed to the right group — with a specific owner where it's obvious.

1. Connect Zendesk and give the agent the routing tools

After connecting Zendesk, open (or create) the agent that will own routing and add its tools. In the tool picker you'll add List Groups and Assign Ticket at minimum; most routing agents also get Get Ticket (to read the full thread), Update Priority, and Add Internal Note so they can leave a one-line "routed here because…" audit trail.

Keep the toolset tight. An agent whose job is routing doesn't need Add Public Reply — giving it only the tools the task requires makes its behaviour predictable and keeps it from "helpfully" answering a ticket it was only supposed to triage.

2. Write the instructions

The system prompt is where you encode your routing policy in plain English — the part a trigger can't do. A workable shape:

You triage incoming tickets. First call List Groups to see the available queues. Read the ticket. Decide which group best fits the customer's actual issue — billing/refunds → Billing; shipping/delivery → Logistics; bugs/errors → Tier 2. If the ticket names a previous agent or is a clear VIP, assign that group and the right agent. Otherwise assign the group only. If you're genuinely unsure, assign the General queue and add an internal note explaining why. Never reply to the customer.

Two things matter here. List Groups runs first so the agent routes against the groups that exist today, not a list baked into the prompt. And the explicit "when unsure" fallback means ambiguous tickets degrade gracefully to a human-reviewed queue instead of being force-fit somewhere wrong.

3. Add the trigger so it runs by itself

Routing only helps if it happens before an agent touches the ticket. In the agent's Triggers tab, add New Ticket — it fires on the first customer message, before any human reply — so classification happens at the front door.

If you want surgical control over which tickets invoke the agent — say, only tickets on certain brands or forms — use the Custom Webhook trigger instead. It generates a webhook URL you attach to a native Zendesk trigger, so Zendesk's own conditions decide what fires the agent. That's the clean division of labour: Zendesk filters on metadata, Macha decides on content.

That's the whole loop: ticket arrives → trigger fires → agent reads it → List Groups → Assign Ticket. For most teams this is a five-minute build. Before you let it run unattended, open the agent's configuration and use Test run to fire it once against a real ticket — you'll see every step (the List Groups call, the reasoning, the Assign Ticket call) execute exactly as it would in production, then read the same trail in the History tab.

If you'd rather start from a worked template, the triage-and-route use case wires up exactly this pattern.

A worked example

Say three tickets land in the same minute:

1. "I was double-charged for my June subscription and need a refund." → Agent calls List Groups, maps this to Billing, calls Assign Ticket with the Billing group. No obvious owner, so group only.
2. "Where's my order? Tracking hasn't moved in 6 days — Sarah was helping me last week." → Maps to Logistics, and because the customer named a prior agent, Assign Ticket sets Logistics group + Sarah so continuity is preserved.
3. "The dashboard throws a 500 every time I export." → Maps to Tier 2 Support, sets Update Priority to High (a 500 error is a real bug), assigns the group, and drops an internal note: "Routed to Tier 2 — reproducible export error, flagged High."

Three tickets, three different routing shapes — group-only, group-plus-agent, and group-plus-priority-plus-note — all decided from the words in the ticket, with no tags or keyword lists to maintain. That's the practical difference between content-aware routing and rule-based routing.

Watch-outs: when NOT to reach for this

Content-aware routing is the right tool for content-dependent decisions. It is not always the right tool, and a deep-dive that pretends otherwise isn't worth much.

• If a Zendesk trigger already does it, keep the trigger. "Everything from [email protected] goes to the EU group" is a one-line native trigger that runs instantly and costs nothing. Don't spend an AI action to reproduce deterministic rules — layer Macha on for the routing rules can't express.
• It costs credits. Each routing decision is an AI action (Macha bills per action — roughly 0.5–9 credits depending on the model, with the default GPT-5.4 Mini at 1). On very high, low-value volume, a native trigger may simply be cheaper. See the pricing page for the maths.
• Workload balancing is still Zendesk's job. Assign Ticket routes by fit, not by who's least busy. If you need even distribution within a queue, route to the group with Macha and let Zendesk's round-robin or omnichannel routing pick the individual agent. The two layers compose well — don't make the AI do load balancing.
• Garbage groups in, garbage routing out. The agent routes to the groups List Groups returns. If your Zendesk has twelve overlapping half-dead groups, tidy them first; clear, distinct queues make for clear routing.
• Watch it before you trust it. Run the agent in suggest/observe mode on real tickets and read the run history for a few days. Routing is high-leverage precisely because it's early in the lifecycle, which also means a confidently-wrong rule does damage at scale. Verify, then let it run autonomously.

Where this fits in your stack

The mental model: Zendesk owns the queues, the SLAs, and the workload mechanics; Macha owns the read-the-ticket-and-decide step that used to need a human. You're not ripping anything out. Triggers, views, omnichannel routing, and skills all keep doing their jobs — Macha just makes the first decision smarter, then hands the ticket back into Zendesk's machinery via the same APIs your agents use. If you want the broader picture of how the agent layer sits on Zendesk, the Macha on Zendesk page walks through it, and the Zendesk integration page lists every ticket tool — including Assign Ticket and List Groups — an agent can call.

FAQ

Can a Macha agent assign a ticket to both a group and an agent at once? Yes — since May 2, 2026 the Assign Ticket tool accepts a group, a specific agent, or both in one call. Setting both files the ticket under the group's queue and assigns the named person, keeping views and SLAs consistent.

Why is there a separate List Groups tool? Zendesk assigns by group ID, not name. List Groups returns every active group with its ID so the agent can resolve "Billing" to the right number at runtime — no hard-coded IDs that break when a team is renamed.

Does this replace Zendesk's native routing? No. Macha is an AI layer on top of Zendesk. Keep your triggers and omnichannel routing for rule-based and workload-based decisions; add Macha for routing that depends on what the ticket actually says. They run together.

What triggers the routing agent? Usually the New Ticket trigger, which fires on the first customer message before any agent replies. For tighter control, the Custom Webhook trigger lets a native Zendesk trigger decide exactly which tickets invoke the agent.

How much does AI routing cost? Each routing decision is one AI action, billed in credits by the model you choose (default GPT-5.4 Mini = 1 credit; range roughly 0.5–9). There are no per-ticket licence fees — see pricing for current plans.

Try it

If your routing today is a wall of keyword triggers you're afraid to touch, this is the upgrade: route by what the ticket means, not by tags you have to maintain. Start a 7-day free trial, no credit card required, connect Zendesk, give an agent the List Groups and Assign Ticket tools, and point the New Ticket trigger at it. The Zendesk integration docs have the full setup.

Written by Abbas (Customer Support & AI, Macha) · Reviewed by Ankeet Guha (Co-founder & CTO) · Published 2026-06-24 · Last updated 2026-06-24.