Ai Role out strategy for email

Hi Brandon

I don’t have any answers for you, unfortunately, but I’m also curious about this. We just rolled it out on Messaging but Email seems like a lot higher risk so we would want to take a gradual approach like you. It seems hard to test this without fully launching it, which seems dangerous!

Hi Brandon and Fiona! I wonder if this article might help you? https://support.zendesk.com/hc/en-us/articles/8357751811610-Creating-a-test-email-in-Zendesk-Support-for-AI-agents

We made a change this week. Where we moved our Ai agent Ultimate trigger down a little bit. So that the ticket could have intents assigned to it first. Then if a specific intent is assigned to a ticket. The ultimate trigger would see that and the Ai workflow would start. This is our fix for now to test specific use cases and it seems to be working in live testing so far.

Hi, sharing what worked for us — we run a Zendesk email AI agent in production (the current unified AI agents workspace, with use cases and generative procedures) and had the same requirement: the agent should only handle selected use cases, everything else goes straight to human agents.

We didn't solve it inside the AI agent at all. We solved it in the Zendesk ticket trigger that forwards tickets to the agent (in our instance it's called "Ultimate.ai Email Channel Automation" — yours may be named differently, but there will be one trigger that hands tickets to the AI agent):

1. We added one exclusion condition to that trigger: Tags | Contains none of the following | no_ai. Any ticket carrying that tag never reaches the AI agent.

2. We use small upstream "marker" triggers that add the no_ai tag to every ticket stream the agent shouldn't touch. Important: those marker triggers have to sit above the AI agent's trigger in the trigger execution order, otherwise the tag isn't set yet when the AI trigger fires.

3. The marker conditions only work reliably with signals that exist at ticket creation — support address, ticket form, brand, subject patterns. We initially wanted to exclude by intent, but the ticket gets forwarded to the agent before intent classification completes, so intent-based gating didn't work for us.

For a phased rollout you can run the same mechanism in reverse: markers tag only the ticket streams you want the agent to handle, and the AI trigger requires that tag. Then you widen the markers phase by phase.

One warning from our rollout: watch your notification triggers. If you still have a standard "request received" auto-reply trigger active AND the AI agent sends its own messages (including its escalation message, "someone from our team will get back to you"), customers can end up with two or even three emails for one ticket — a receipt confirmation, plus the agent's reply or escalation note. We had to redesign this into a one-email logic: the receipt confirmation is suppressed for the agent-handled stream, and escalations happen silently — we emptied the text block of the escalation reply so the agent still runs its actions (tagging, handoff) but sends nothing, and the ticket lands quietly in the normal agent queue. Each customer gets exactly one first response: either the agent's full answer or one confirmation.

That combination (trigger gate + coordinated notifications + silent handoff) has been running reliably in production for weeks. Hope that helps!

Thank you so much for the great feedback!!!!!

I had the exact same question and feature request which is: the ability to toggle off a generative reply on a ticket AI Agent is active on.

The use-case is that I’d like to use AI Agent as the ticket confirmation with a generic acknowledgement without answers from the knowledge base attached as our default configuration. 

Then, only under certain conditions/criteria, we’d want it AI Agent to answer with knowledge-retrieved replies. But it seems this is not possible. So we have to resort to an upstream trigger that only sends certain tickets (based on intent) to AI Agent while all other tickets just use a standard trigger for email confirmation.

Not directly related, but I turned on the testing version and have found that the replies generated are incredibly long and detailed and I don’t see a way to adjust this in the settings. It also seems to ignore some of my instructions, which I copied over from the Messaging version and worked over there. Has anyone come across either of these issues and been able to resolve them?

I have the same problem and I’m curious how people get around this. The best result I got so far was to have an instruction to give concise answers (or 1-2 paragraphs) but it doesn’t always work. I also selected custom ‘Tone of voice’ to specify giving concise answers. I’d say I saw a 20% improvement with the two combined.

Hey Brandon,

I’d start by keeping the AI Agent scope very narrow and explicitly define what should happen when a request doesn’t match those use cases. Test one email that should be handled by AI and one that should go to a human. Also check the fallback settings, since generative replies may still respond outside your intended use cases.

Starting small and testing the ‘AI should not handle this’ scenario usually makes phased rollout much easier.