How Do You Route Zendesk Tickets to Departments Without Agent Replies Triggering Keywords?

To stop keyword routing triggers from firing on agent replies in Zendesk, add the condition Current user | Is | (end user) to each routing trigger, or Ticket | Is | Created if you only want tickets routed once. For departments with their own email addresses, route on Received at instead of keywords, and for customer segments use the organization's Group field, which assigns every new ticket from that organization's users to one group with no trigger at all.

Why do keyword triggers move tickets when agents reply?

Say you run separate support addresses for each department, [email protected], [email protected] and [email protected], with a group for each and triggers that look for keywords to route tickets.

It works until an agent in Support replies to a customer and writes the word "billing." A trigger that checks Comment text for "billing" doesn't care who wrote the comment, so it fires and moves the ticket to the Billing group. Now tickets ping-pong between departments, customers get replies from three teams, and agents stop trusting the routing.

The core issue: Zendesk evaluates every trigger each time a ticket is created or updated, and an agent's reply is an update. Unless a condition says otherwise, a trigger reads agent comments exactly as it reads customer messages.

How do you stop a trigger firing on agent replies?

Add a condition that only lets the trigger fire when a customer made the update.

Condition: Current user | Is | (end user)

Zendesk's trigger reference defines "Current user" as the type of user who last updated the ticket, with the values (agent), (end user) or a specific agent's name. An end user is a registered user who is not an agent or admin. Set it up like this:

1. Go to Admin Center > Objects and rules > Business rules > Triggers.
2. Create or edit your routing trigger.
3. Under "Meet ALL of the following conditions," add:
   • Current user | Is | (end user)
   • Your keyword or routing conditions
4. Set the action to assign the ticket to the right group.

With this in place, a customer's follow-up can still re-route a ticket, but an agent's reply can't.

Why does this fit most department setups?

As one Zendesk community member put it: "Often this kind of ticket routing is only desired once when the ticket is created and only manual hand-offs between departments afterwards which is what you'll get with this condition."

How do you route a ticket only once, at creation?

If you never want an automatic re-route after the first assignment, add:

Condition: Ticket | Is | Created

Zendesk's reference says "Created will fire only when a new ticket is created," while "Updated" fires only when an existing ticket is modified and submitted. One wrinkle worth knowing: for a ticket an AI agent handled first, "Created" fires when the ticket is escalated to a human agent.

When should you use Created instead of Current user?

• You want tickets routed once, at creation
• You'd rather agents transfer tickets manually between departments afterward
• Your routing depends on the first message, not the ongoing conversation

The trade-off: a customer who opens with a sales question and follows up about an invoice stays with Sales. With Current user is (end user), that follow-up could re-route.

How do you route by support email address instead of keywords?

If each department has its own support address, route on where the email arrived rather than what it says.

1. Add a support address for each department (sales@, billing@, support@).
2. Create one trigger per department:
   • Condition: Ticket | Received at | Is | [email protected]
   • Action: Ticket | Group | Sales Team

This beats keyword matching because the address a customer wrote to doesn't change when an agent replies. Zendesk's reference says the condition checks "the email address from which the ticket was received and the email address from which the ticket was originally received," so a reply on the thread still matches the original address.

What about forwarded email?

If you forward mail from an external mailbox (say, [email protected] in Google Workspace) into your Zendesk address, make sure that external address is added as a support address in Zendesk and pick it in the condition. Otherwise tickets may register as received at the Zendesk address, and every forwarded department lands in the same bucket.

Can organizations route tickets without triggers?

Yes. For customer segments or client companies, organizations are more reliable than keywords.

1. Create organizations for each company or customer type.
2. Add domain mapping so users are added to an organization automatically based on their email domain.
3. Set the organization's Group field. Zendesk's documentation says that "if there is a group selected in the Group field, all new tickets submitted by users who are part of the organization are automatically assigned to this specific group."

What does an organization-based trigger look like?

If you'd rather keep the logic in triggers, Zendesk's own auto-assignment workflow uses these conditions:

• Ticket | Is | Created
• Ticket > Assignee | Is | -
• Organization | Is | Enterprise

Set the action to your Enterprise Support group. Combine this with user or organization tags and you can route on customer attributes rather than message content.

When should you move to omnichannel routing with custom queues?

For larger teams, custom omnichannel routing queues replace a pile of group-assignment triggers. Omnichannel routing itself is available on every Suite plan (Team, Growth, Professional, Enterprise and Enterprise Plus). Custom queues need Suite Professional or above, or Support Professional or Enterprise, and the Agent Workspace.

As one Zendesk expert noted: "If you have access to Omnichannel Routing and the Custom Queues feature I would recommend getting familiar with that feature over going down this trigger-based sooner rather than later."

What do custom queues add?

1. Primary and secondary groups: up to 20 of each per queue. Omnichannel routing tries the primary groups first and falls back to the secondary groups when no primary agent is available.
2. Many queues: up to 199 custom queues on top of the standard queue.
3. Priority and skills: on Professional and above, tickets can also be routed by priority and by the skills an agent has.
4. Capacity awareness: work goes to agents who are online and have room, not just to a group.

Who gets the most out of custom queues?

• Teams on several channels (email, chat, phone)
• Teams that need overflow when a primary group is at capacity
• Teams that want routing to follow agent availability
• Teams whose routing rules change often

How do you make keyword routing more accurate?

If you keep keyword routing, these habits cut the false positives.

1. Pick keywords agents rarely type

Skip broad words like "question" or "help." Use product names, plan names or error codes that customers write and agents seldom mention in passing.

2. Require more than one keyword

Put two keyword conditions under "Meet ALL of the following conditions":

• Ticket | Comment text | Contains at least one of the following words | refund
• AND Ticket | Comment text | Contains at least one of the following words | payment

3. Exclude known senders

One community member suggested: "Depending on your situation, have you considered using organisations? For example, if you have a supplier that always raises queries for a certain group to handle, have those end users setup in an Org, and exclude these from the buzzword routing."

4. Choose between word and string operators

• "Contains at least one of the following words" matches any of the space-separated words you list
• "Contains the following string" matches the exact phrase you type

Pick the operator deliberately, then test it with real ticket text.

Keywords are a guess at intent. When routing keeps breaking, the fix many teams reach for is classification by meaning: an AI agent reads the whole message, sets a category field or group, and leaves an internal note explaining why. Macha runs agents like that on Zendesk, Freshdesk, Gorgias, Front, HubSpot or Intercom, and a routing agent is a common first build because it's easy to check against what your team would have done.

How should you order routing triggers?

1. Order matters

Triggers run from top to bottom, so put them in stages:

• First: categorization triggers (tags, fields, spam detection)
• Second: routing triggers (group assignment)
• Third: notification triggers (emails to customers and agents)

As Internal Note's trigger guide puts it: "I work my way from categorisation, towards assignment, and then notifications. Or to put it differently, if the end goal of a ticket is that it's being resolved by the right person, we need to make sure we first define what the ticket is about, then route the ticket to the right team or person."

2. Add a fallback trigger

Put a final trigger at the bottom that catches anything the others missed:

• Condition: Ticket | Group | Is | -
• Action: Ticket | Group | Default Support
• Add a tag like "routing_fallback" so you can find and fix gaps in the routing rules

3. Keep each trigger simple

Zendesk's documentation advises: "It is recommended to keep your trigger statements simple. The more complicated a trigger is, the harder it will be to troubleshoot and maintain."

How do you test department routing before rollout?

1. Create test tickets for each scenario:
   • New customer inquiries
   • Agent replies containing routing keywords
   • Tickets from different organizations
   • Tickets through different channels
2. Open the ticket's events to see which triggers fired on each update.
3. Watch the fallback tag to catch tickets slipping through.
4. Ask agents whether tickets are landing in the right place.

What routing mistakes should you avoid?

1. Forgetting agent comments

Add Current user is (end user) or Ticket is Created to every keyword routing trigger unless you really want agent updates to re-route.

2. Testing with made-up text

Keywords that look unique on a whiteboard turn up in agent replies more than you'd expect. Test with real ticket content.

3. Leaning on keywords too long

If routing breaks every week, move to Received at, the organization Group field, or custom queues.

4. Forgetting that updates fire triggers

Every update re-runs every trigger. Use Ticket is Created when routing should happen once. The quickest fix for most setups is still the first one on this page: add Current user is (end user) to each keyword trigger, then test with a real agent reply before you touch anything else.