Verification for anonymous help center requests

Oh no no no! This is absolutely antithetical to how we do business. We do not want any additional steps for our users to submit a ticket. We don't need “protection”.  Most of our users are students – they have a hard enough time just logging into our system. Forcing them to also verify their email will significantly impact our ability to serve them. They will get frustrated and give up. They will wonder why we didn't respond. This is not acceptable. And with just a day's notice???  I can't be ready for this in a week, much less a day. This is a SIGNIFICANT impact on business that will require us to communicate with our partners about what to expect. Please bring this to a screeching halt until you can roll it out as an OPTION for those who want it, and not force it on everyone.

Many support teams operate in environments where customers only contact support once, usually when something goes wrong with a purchase, billing, or access issue. In those scenarios, requiring email verification before a ticket is accepted introduces unnecessary friction at the worst possible moment in the customer journey.
 

In our case, the majority of tickets come through the Help Center web form from customers who are not logged in and who don't have a Help Center account. These users are often reaching out because they are already frustrated or confused. Adding an additional verification step creates several risks:

1. Customers may not notice the verification email or may assume their request was already submitted successfully.
2. If they do not complete the verification step, their ticket remains suspended without any confirmation, which means they may believe support is ignoring them.
3. This can easily lead to escalations such as chargebacks, negative reviews, or duplicate requests when customers attempt to contact support again.

From an operational standpoint, this change also creates additional overhead for support teams. Legitimate customer requests may now accumulate in the Suspended view, requiring manual recovery and monitoring, especially for teams handling high ticket volumes like us.
 

While the intention of preventing abuse is understandable, this approach assumes that all support environments benefit from mandatory verification. For many companies, particularly those with one-time support interactions, the cost to customer experience may outweigh the benefits.
 

At the very least, it would be extremely helpful if Zendesk provided:

• The ability to opt out of this behavior
• More control over how verification is enforced
• Better tools to automatically recover legitimate tickets
• Clear indicators for tickets waiting on verification

Security safeguards are important, but they should be configurable so teams can balance abuse prevention with customer experience.

Just adding my voice to the choir - dumbfounded by this change.

This is an absolutely horrific change that affects our operations in a huge way (and by the looks of it, this applies to many of your customers).
You must understand that when submitting an inquiry to a customer contact point(form), the percentage of users that will go in and read the verification email that they get is probably less than 10%, even if we put a reminder in the form info. The volumes of legit tickets that will end up in spam is so big, that it will outnumber the spam tickets, and we will have to manually check every email in the spam folder continuously. I expect this to cost us a full FTE or more. 

Apart from the fact that this change is so out of touch with the reality of a good customer service experience, the way this change (or any other change), is communicated and forcefully implemented in such a short timeframe is highly unprofessional, and really makes one wonder if Zendesk is the right choice for the future.

We are generally supportive of cybersecurity best practices, but the announced changes for email verification to tackle the spam/mail-relay problems are not applicable in our use case.  On our web application, we only allow AUTHENTICATED users to create support tickets using Zendesk’s Web Widget (Classic) form.  To create a support ticket, users must first SIGN IN to our site (not Zendesk), and only then can they interact with (the widget), search FAQ’s, and possibly submit a request.  This is only available from pages “behind the login” of our web application.  

There is NO public access to generate support tickets (other than sending email directly to the support email address, which has already been established as secure).  As such, there is very little potential for attack, and our account experiences a small amount of spam.  For this reason, we’d encourage your team to think harder about the “edge cases” of your cybersecurity issues, and how it applies to authenticated environments like ours.  Our users are not “anonymous” in the sense you describe.

Since your concerns do not apply in our environment, we would request an option to toggle this feature ON or OFF, so that we can choose what works best for our customers. At the very least, an option to delay the implementation would give us time to evaluate alternative approaches offered by Zendesk.  Even the May 7 extended deadline is far too soon for us to juggle established development priorities and reasonably implement changes.  

The announcement and implementation of this feature feels rushed. We feel the new process would degrade the service we provide our customers and makes it more confusing to contact support.  We are hesitant to allow any vendor to make us less competitive, and would likely need to evaluate other solutions if there is no alternative to the new email verification process.

We display help sections and articles from our Zendesk Help Centre on a support page within our web app. This means that the content is synchronised. Will this synchronisation still work if we enable required sign-in?

Advocating for this feature to be optional. This update will impact 25% of annual ticket volume negatively. This update would resolve some spam concerns that we see, where we get bot spam that is not malicious, just clutter. This update would not positively reduce the malicious spam and imposters which are most commonly reaching out via Email, not Webform.

This update only negatively impacts our account, team, and customers.

This side effect of this change, in particular, is make or break for us: “If you’re using autoreplies to recommend articles (legacy) or AI agents to create replies based on help center content, it will no longer show for anonymous requests." I reached out to Zendesk Support to confirm what the poorly phrased "it" refers to here; they confirmed that AI agents will no longer provide automated replies based on help centre content to customers who aren't logged in.

We are a small B2C business. Our customers don't sign in to Zendesk to contact us and we don't expect them to. We have managed to keep our human team size small by relying on Zendesk's chatbot, which then changed to an AI agent last year (communicated as though this were an exciting update to the existing chatbot tool), which we then found out we had to pay extra for (thousands of GBP per year to just about meet our footfall). 

Removing the AI agent responses for customers who aren't signed in to Zendesk significantly impacts our business. In my opinion, this is an overkill response to trying to prevent spam emails reaching the ticketing system – I personally can't understand the correlation. To note, we are perfectly happy removing the few spam tickets we receive ourselves. Given that this change affects our pod from 24th March, this doesn't give us much notice to enact changes to our processes. Additionally, our annual Zendesk bill is due on 17th March – 7 days after we received this announcement. So should we go ahead with the annual charge for AI automated responses given that we may not be able to utilise them at all in a couple of weeks?

If this is how Zendesk plans to move forward, we will need to look at alternative platforms. We are hugely disappointed by this decision.

We have been using Zendesk for years, and I must say, we were pretty unsatisfied with how this was handled. 

This is a horrendous rollout that is going to cause so many issues for my clients and internal agent team. Having to sift through suspended tickets all day is just adding work to everyone's plate. We will likely need to look at a new solution for ticketing going forward.

@max30 Can you verify that my company's application for deferred rollout has be received? I submitted a request over 24 hours ago and have received zero communication that the request was submitted successfully – much less processed so our users aren't impacted by this this week.?

This decision and lack of community engagement is making us have serious conversations about the long-term viability of Zendesk as our Support System.

Has anyone received confirmation that their request was received or approved?

I wholeheartedly agree. 100% of our use case for ZD is anonymous submissions through our Help Center. Ease of use is essential. If guests cannot easily submit their feedback, they will lose confidence in our business. And then we have automated forwarding to our field partners for immediate resolution. This will significantly delay communications to our field partners and to our guests. This is forcing us off of ZD. 

This side effect of this change, in particular, is make or break for us: “If you’re using autoreplies to recommend articles (legacy) or AI agents to create replies based on help center content, it will no longer show for anonymous requests." I reached out to Zendesk Support to confirm what "it" refers to here; they confirmed that AI agents will no longer provide automated replies based on help centre content to customers who aren't logged in.

We are a small B2C business. Our customers don't sign in to Zendesk to contact us, and we don't expect them to. We have managed to keep our human team size small by relying on Zendesk's chatbot, which then changed to an AI agent last year (communicated as though this were an exciting update to the existing chatbot tool), which we then found out we had to pay extra for (thousands of GBP per year to just about meet our footfall).

Removing the AI agent responses for customers who aren't signed in to Zendesk significantly impacts our business. In my opinion, this is an overkill response to trying to prevent spam emails reaching the ticketing system – I personally can't understand the correlation. Given that this change affects our pod from 24th March, this doesn't give us much notice to enact changes to our processes. Additionally, our annual Zendesk bill is due on 17th March – 7 days after we received this announcement. So should we go ahead with the annual charge for AI automated responses given that we may not be able to utilise them at all in a couple of weeks?

If this is how Zendesk plans to move forward, we will need to look at alternative platforms. We are hugely disappointed by this decision.

Is it true that the AI Chatbot essentially will not work anymore for anonymous users? If so, what's the point? That's the greatest benefit of having this solution is to allow the AI chatbot answer questions to take load off of our staff, especially during closed hours. I just don't understand why Zendesk is taking an axe to their customers to solve this issue, that quite frankly is not new and everyone knows about. Organizations take their own measures against bad actors, we don't pay Zendesk to do this for us!

There are now too many comments and embedded responses to review. 
Please provide an updated announcement on the current plans.  

I agree with the crowd that this mandated change adds unnecessary friction to our users and mostly likely will negatively affect the customer experience and our ability to receive much needed user feedback.   Please provide an option to disable. 
Zendesk should be helping us improving engagement with our users not inhibit it. 

If the ticket goes to the suspended queue, will the verification emails be suspended until they are unsuspended

Adding my voice that this security needs to be optional because on my customers' behavior, we are going to lose a fair amount of tickets because the individual is not going to respond to the verification email.  Also, there is a big risk of the verifiction email being flagged by ISP/email providers that t is SPAM.

We are extremely disappointed in this update. Not only does this completely uproot how we operate, but we're expected to figure out how to restructure our workflows in a matter of days. This is completely unacceptable. We are sick of Zendesk's neglectful updates that are rolled out with zero customer input in mind.

A major potential new customer reaching out to inquire about our product via the help center should not have to go through an authentication process just to ask a question. That added friction will delay their needs and push them away — costing us real business.

Furthermore, we use this form to gather secure documents from both new and existing users. We have done our due diligence to ensure that our form and all incoming tickets are secure. Just because Zendesk hasn't done theirs doesn't mean every customer should be held accountable for their shortcomings. We should have the ability to disable features that don't apply to our use case.

As a financial services company, we cannot afford the possibility of losing tickets. A single lost submission could result in a regulatory complaint. This isn't a minor inconvenience — it's a compliance risk.

Please reconsider this decision. We are at our wits' end, and this update will have the potential to influence our decision to switch CRM providers once our contract is up.

Many organizations intentionally allow anonymous ticket submissions for legitimate reasons — such as embedded webviews, lightweight support forms, or systems where user identity is already handled outside of Zendesk.
 

With this upcoming change, those workflows may be forced to redesign their entire support flow, even though they are currently working without issue.
 

What makes this even more confusing is that Zendesk already allows administrators to control whether anonymous users can access the Help Center at all. If admins can decide that, why are we not allowed to decide whether anonymous request verification should be required?
 

Right now this feels like a forced security policy with no flexibility and no clear migration path for organizations relying on anonymous submissions.
 

If this feature is intended to improve security, it should be implemented as a configurable option in Admin Center, not a mandatory requirement.
 

Please allow administrators to enable or disable Anonymous Requester Verification based on their own workflow and security requirements.

We have submitted the form to request a delay of this rollout for our instances and still have not received any written confirmation that this has been approved. Should we be planning to deal with this increased operational cost in the next 2 weeks or not? I see other comments echoing the same concern. 

The lack of substantive response to such overwhelming critical feedback on the impact to the end user experience and concerns about costly operational changes, combined with a lack of timely follow through on the extension form, is extremely disappointing. 

Hi, Everyone — Thank you for continuing to share your concerns.  We heard you and are taking action. We are going to allow all customers to opt out of this feature, and we’re adjusting the rollout to achieve the best balance between security and the need for openness and flexibility. 

On March 19th, we will be adding a setting to your accounts which will allow you to turn this feature off. This setting will be available before the change goes into effect, allowing you to turn it off ahead of time, so that when the change rolls out to your account you will not be affected. If you do not opt out ahead of this rollout, it will be turned on for you, with the option to turn it off. You will see warnings in the product about the increased potential for spam. Our rollout schedule for the changes will be slightly altered:

• We will postpone the rollout on Tuesday, March 17th:
  • Pod 15 will be added to the March 24th rollout
  • Pods 25 and 30 will be added to the March 31st rollout (this change happened earlier this week)
• The rest of the rollout schedule will remain as is

We will continue to improve the ways we protect you, your customers and employees, and anyone else on the internet from spam attacks. We will do this by improving rate limiting, bot detection, and other limits. Your feedback here has been critical to our discussions, and we thank you for sharing the very real, complex interactions this change would have on some of your workflows. We are introducing this change to strengthen Zendesk’s security by design and provide the strongest possible protections, but we also recognize the need to balance this with flexibility to meet the diverse needs of our customers. As a result you will be able to opt out of this change.

We also hear you loud and clear on the updates you'd like to see in the suspended tickets experience. We are prioritizing that work to ensure that those who do use this feature have easier management of suspended tickets. More on that soon. 

Thank you again for your thoughtful feedback. These decisions are never easy, but I’m glad we could find a path that meets more of your needs.

Hi Team, appreciate the ability to turn this off for now. That's good news. 

Sorry if i've overlooked this, but is there a way to report on tickets created by users through the web form that are authenticated vs anonymous please? We don't use knowledge articles or anything like that, but we do have some cases where people use the web form to submit tickets. We'd like to be able to quantify the impact, and potentially look to make changes to our flow based on the numbers.

Will there be the possibility to opt-out of the opt-out later on? I guess, a feature option in Zendesk makes sense.

We do not let our confirmation mail send out spam content, when someone opens a ticket with spam for another email address. So, we are good. But just in case, I wanted to know…

I agree with the other comments — ease of use is essential. This feature breaks integrations and validation logic we currently rely on, and it’s surprising that it cannot be tested beforehand in a sandbox environment.

We already support anonymous web form submission and have processes in place to handle those submissions. In our product, time to resolution and the initial message sent to the user are critical metrics.

The end-user experience described under “What is the end-user experience like for the web form?” is far from optimal. After submitting the form, the user is shown a popup notifying them that the request has not yet been submitted and that they must verify their email — at which point many users will simply close the tab and move on. A much more reliable approach would be to keep the user on the same page and ask them to enter a one-time passcode (OTP) sent to their email, rather than requiring them to leave the form context entirely to click a link. As currently implemented, this flow introduces unnecessary drop-off and will not provide robust verification.

On the article / release announcement, I see the info regarding what an anonymous user will encounter when they submit a form. What will be the outcome if an anonymous user emails their ticket as we have some ticket forms where emailing a specific internal address is also a created ticket. Will they receive an email reply with the same message that requires action before the ticket is created? 

Rachel P — 
I'm very sorry for the slow acknowledgement. We never planned to send anything specific out about the original deferral requests, but we have now sent those out (earlier this week). The opt out option will appear tomorrow (March 19th) and your account is confirmed to be on the deferral, so you have until May 7th to turn the feature off before verification would start happening.

Tim Grimshaw  — 
“is there a way to report on tickets created by users through the web form that are authenticated vs anonymous"
Not at this time. We are exploring this, but we don't actually record this data on the ticket today. This has been a concern in a few cases, and does need to be captured. 

Sebastian — 
“Will there be the possibility to opt-out of the opt-out later on? I guess, a feature option in Zendesk makes sense.”

The switch to turn this feature on and off will continue to be available. You can try the feature out in your primary account or in a sandbox at your leisure. 

Adrian Martin — 
I appreciate your feedback here. We have heard this loud and clear. The feature can now be disabled in Admin Center.