Question
I received a bad satisfaction survey response. When I followed up with the customer they said they never even opened the survey email or did not click a bad response. Why do we get false bad ratings?
Answer
Your customers likely have link expanders installed on their computers or running on their mail servers. These programs open links in the email to verify they aren't malicious. Since customer satisfaction (CSAT) ratings store the last rating link clicked, a script that clicks every link will register as a bad satisfaction response.
Enabling DKIM and SPF records helps ensure that links are not scanned. These email authentication protocols decrease the likelihood that the link expanders will flag emails from your Zendesk account for inspection.
If you have set up SPF and DKIM and are still seeing issues, there are two workflow options to resolve the issue.
Modify your survey automation
Create your own survey
Modify your survey automation to not include direct response links
By default, the Request customer satisfaction rating (system automation) includes a block with both the good and bad response links. Switch this out for a placeholder that contains a link to a separate page with these options instead.
To modify your survey
- In Admin Center, navigate to the Automations page.
- Locate the Request customer satisfaction rating automation, and click on the automation to edit.
- Scroll down to Perform these actions to locate the Email body section.
- Locate the
{{satisfaction.rating_section}}placeholder and replace it with{{satisfaction.rating_url}}.
For more information on placeholders available in Zendesk Support, see the article: Zendesk Support placeholders reference.
Create your own satisfaction survey and use the Satisfaction Rating Endpoint
If you are comfortable with writing custom code, you can make your own survey and use the Satisfaction Rating endpoint to feed the results into your Zendesk. This will ensure that you can still use Zendesk reporting on the CSAT survey. With a custom survey, you can add a verification step to thwart the link expanders.
81 Comments
We've also seen a sudden influx of these in the past few weeks. When we reach out to clients on what we could do better, they have all said they didn't select the bad feedback. Looking at the Zendesk Events, all of them have come in on the hour or at half past - so seems like some kind of scheduled automation is doing this? I'll raise a ticket with Zendesk support, but sounds like we're not the only Zendesk customer having this issue.
Scott Patterson I'm one of the Product team here at Zendesk. I just wanted to respond and clarify that it's not a scheduled automation causing this. There is a scheduled automation running to send CSAT surveys out once an hour, but what's happening is some portion of these are likely being scanned by anti-virus software running on the recipient's mail server. The guidance in this article should be followed as to how you mitigate or prevent this from happening completely.
Scott Allison, maybe a naive question - but if a anti-virus software scanning is causing the trigger - doesn't it leave evidence in the http request header, like a specific user-agent, or other parameter that is not found in a human-generated traffic?
If so, can't you use these hints to filter out this activity?
Changing CSAT from good and bad to a link will solve the problem, but it will decrease the number of responses.
It is not an ideal solution.
I would select good in a survey but not click on a survey link where the survey could be from one to many questions...
Isn't there any option to add a hidden void button before the survey options so an antivirus would not check any of the options?
Tal Admon We did look at various pieces of meta data including the ones you mentioned but this wasn't a magic bullet. There was only one such piece of software that was actually identifying themselves with a unique user agent, others were just appearing like any other browser.
Hi all,
I am excited to share the news that Zendesk has recently rolled out the solution to the false negative CSAT rating. Check our announcement Announcing a spam prevention tool in CSAT.
Yay, thanks!!
While this soultion has greatly reduced the number of False Negatives, we are still seeing some. I would be happy to provide samples to the Zendesk team if it would help eliminate these altogether.
Hello Scott Allison - I mended the CSAT placeholder Survey from this {{satisfaction.rating_section}} to this {{satisfaction.rating_url}} but is this really the expected behaviour on how it will look like from the customer's end?
This lengthy URL?
Hi Zendesk Admin,
Yes, the placeholder {{satisfaction.rating_url}} is expected to show as a full-length URL.
Hope this helps.
I recommend reaching out to our Customer Care team using the instructions mentioned in this article: Contacting Zendesk Customer Support
With a couple examples they should be able to help determine why this is happening on your end.
Hope this helps!
Hi Zendesk Admin,
You can update the automation and make it a little more professional looking by using some basic HTML, such as the following:
<p><span style="font-size:16px;"><a href="{{satisfaction.rating_url}}" style="background-color: #012B30; padding: 10px 20px; color: white; text-decoration:none;font-size:14px; font-family:Roboto,sans-serif;border-radius:5px" target="_blank">Share your feedback</a></span></p>
Which gives a button effect rather than the rather clunky URL link:
Hope it helps.
We are experiencing the same issue, but Zendesk's response is not satisfactory. The rating cannot depend on whether the user has a special DKIM configured.
The rating should not depend on the email click, but alternatively, could you take the user to a page and collect the click there? This way there would be no dependencies.
We are being harmed because of this situation. Zendesk must provide a solution to remove all repeated negative ratings from the same customer. Please advise.
Beatriz Oliveira
The original post does provide the exact solution you seek - to bring users to a page where they provide the rating click. I'd propose that instead of replacing the "section" with ONLY the "url" you also provide more context - a line asking people to provide a rating by "clicking here" (with the satisfaction URL) -- like in the screenshot shared in the original post.
To modify your survey
{{satisfaction.rating_section}}placeholder and replace it with{{satisfaction.rating_url}}.This is actually quite easy to solve, we do it for similar links on our application. However, it requires Zendesk to run a bot check on the URL, we use a simple rule on CloudFlare, when the AV attempts to scan the URL CloudFlare checks the request and identifies it's not human and therefore does not pass the request to the application, and hence no false positives.
Works for us, but since Zendesk controls this URL, they need to implement this simple solution.
David Launen Yes, this is what we do: https://support.zendesk.com/hc/en-us/articles/4408831380122/comments/5796435691290
Interesting, has this completely rolled out? Were still seeing the bad results being triggered without user intervention as of just yesterday.
David Launen for us, when the change was first rolled out it made a big difference. But then about a month ago we started getting lots of false negatives again. The theory we have is that one of the mail providers (likely Microsoft) has improved its bots so Cloudflare aren't detecting them as often.
Hi David Launen,
May I ask you what score you use to show CAPTCHA?
@Tetiana Gron (I can't figure out how to reference a user from this UI), for our use case, we configured CloudFlare to use a managed challenge for all requests for a specific action URL, for you it could be something like:
https://*.zendesk.com/requests//satisfaction/new/*
IMO, since you only really want humans to access this URL, avoid using the bot score and just have CloudFlare run it's challenge on all requests, which is typically a non intrusive JavaScript challenge where user just needs to wait a couple of seconds.
We ran into this exact issue when sending one time use URLs to certain users for initiating password resets, after we applied this method, we have never had a report again.
I use this approach on areas within our applications where you want only humans to access, i.e. initiating a password reset, etc.
Thank you David Launen for the explanation! We will try this approach in the following days.
Please sign in to leave a comment.