Something changed in Zendesk. Tickets that used to arrive in your queue are now going somewhere else — and nothing in your dashboard tells you.
Zendesk's forced anonymous verification rollout means that tickets submitted by unverified users no longer land in your regular queue. They go to the suspended queue instead. And in the suspended queue, almost nothing works the way you'd expect.
No automations fire. No SLA clock starts. No AI agent responds. No notification reaches your team.
The tickets are technically in Zendesk. They just aren't in the system anyone is actually watching.
What the suspended queue is — and why it's different
The suspended queue in Zendesk was built for spam and failed delivery — emails that bounce, messages flagged by filters, content that can't be processed. It is not a triage queue. It has no SLA. It has no automation triggers. It is a holding area that requires manual human review to action.
Until recently, most support ops teams could safely ignore it. Low volume. Mostly junk. Check it once a week.
The anonymous verification change altered that calculus.
If your product allows unauthenticated users to submit support tickets — through a contact form, a help widget, or a direct email — those users are now unverified by default. Zendesk routes their tickets to the suspended queue automatically. Not as an opt-in. Not as a configurable setting teams were warned about. As a platform default, rolled out across accounts.
For teams with low anonymous ticket volume, the impact is small. For teams with any meaningful anonymous volume — consumer apps, e-commerce, freemium products, anyone whose customers contact support before logging in — the impact can be significant and invisible at the same time.
Why nothing triggers in the suspended queue
This is the part that makes the problem worse than a simple routing error.
When a ticket lands in your regular queue, your helpdesk does work. Automations run — applying tags, setting priorities, routing to the right group. SLA policies attach — starting the clock on first reply time and resolution time. Notification rules fire — alerting agents or posting to Slack. AI agents or bots respond with an acknowledgement.
None of this happens in the suspended queue.
A ticket sitting there has no SLA clock running. It is not in any agent's view. It is not counted in any of your SLA compliance metrics. It does not appear in your open ticket reports unless you specifically navigate to the suspended queue and look. It will sit there indefinitely until someone manually releases or deletes it — and for most teams, that manual review happens infrequently, if at all.
From your customer's perspective, they submitted a ticket and heard nothing. No confirmation. No acknowledgement. No reply.
Who this affects most
The teams most exposed are the ones with the highest anonymous submission volume:
- Consumer-facing products where users contact support from a public help page before they've created an account
- E-commerce where customers email about orders without being authenticated
- Freemium or trial products where the support surface is open to anyone
- Any team with a contact form that doesn't require login to submit
If your helpdesk sits behind authentication — customers must log in before submitting — you're largely insulated. If any part of your intake is open, you need to check the suspended queue.
How to find out if this is happening to you
The check is straightforward, but you have to do it manually.
In Zendesk, navigate to the suspended tickets view. Filter by date — look at the last 30 days. Look specifically for tickets that are not obviously spam: real email addresses, coherent subject lines, actual customer language.
If you see tickets there that should have been routed to your queue, you have a problem. The question is how many, and how long it's been happening.
Some teams running this check have found dozens of legitimate customer tickets sitting in suspension — some days or weeks old, all without any response, none of them counted in any metric the ops team was reviewing.
What this looks like from inside your reporting
Here is what makes the suspended queue problem difficult to catch without specifically looking for it: everything else looks normal.
Your SLA compliance numbers are unaffected — the suspended tickets aren't counted in SLA reporting. Your open ticket volume looks reasonable — they're not in the queue. Your CSAT scores are clean — no responses means no survey triggers. Your agent workload looks manageable — nobody was assigned to tickets that don't appear in any view.
The only signal is what's missing: a customer who submitted a ticket and then emailed again to ask why nobody replied. Or escalated. Or churned.
The pattern is identical to every other silent-failure mode in support operations. No alert fires because no system knows the tickets are there.
The fix — and what to do while you're implementing it
The routing fix requires a Zendesk configuration change: ensure your legitimate intake paths are explicitly allowlisted so tickets from known or expected sources don't get caught by the anonymous verification filter. Your Zendesk admin or a Zendesk support ticket can walk through the specifics for your account setup.
While that's being sorted, check the suspended queue manually. Release any legitimate customer tickets you find there. Those customers have been waiting.
After you've cleared the backlog, the longer-term question is the one every support ops team faces after a surprise like this: how do you know when something else goes quiet?
A daily audit of your open tickets won't catch tickets that are outside the queue entirely — suspended, lost in an unmonitored inbox, or dropped by a routing rule. But it catches everything inside your queue that's aging without action, before a customer escalates.