Upcoming changes to email behavior

Have more questions? Submit a request

82 Comments

  • rsmck
    Comment actions Permalink

    This feels like a considerably negative change. Our Zendesk was briefly used for spamming in this manner but via the unauthenticated API (which is very different from using the eMail channel directly)

    Pretty much every ticket system I interact with sends a copy of the original request, and it's valuable for the customer's audit trail.

    It feels there are many better ways the same goal (reducing mail relay spam) could be achieved without the need to fundamentally change the functionality that your customers (and customers' customers) are accustomed to e.g.;

    • Content analysis - if the same or broadly similar content is being sent to 100s then it's most likely spam.

    • Enabling it for any registered user rather than just agent. That way someone's first contact with the Zendesk may be affected, but generally those with an established relationship would still benefit from the content.

    • Rate limiting (or other such metrics) based on the source of the request

    A company such as Zendesk should be able to find a better way of doing this, without breaking many customers' workflows or changing the customer experience.

    4
  • Bianca Duma
    Comment actions Permalink

    Hi,

     

    If we are ok with the change and don't have a template to edit, do we still need to remove the text {{ticket.comments_formatted}} from the trigger, or if we leave it as is it will just automatically be suppressed?

     

    Cheers,

    0
  • Ievgeniia Rudkovska
    Comment actions Permalink

    this is a very strange decision to make. for us {{ticket.comments_formatted}} is the only way to notify our customers about the fact that we received their request. And now I can't use this anymore. I'm sorry, but there should be some alternative. Creating links and other content in the email is not for us, we are not using Zendesk as a typical ticketing system, so for customers to login and create tickets is not an option. Sorry but this has to be changed. I agree with AimeeS who wrote above, she has the same situation as we have in our company. There should be alternative for users like us.

    3
  • Jaïs Pingouroux
    Comment actions Permalink

    I join the voice of others to say that this is a bad idea. We use Gmail connector, so we're not impacting ZD reputation. Our customers mostly use emails to create tickets, if the first confirmation email they receive do not contain a summary of their issue, this is confusing for them.

    Moreover, there is a case that may actually require to notify all the users from a given organization about the creation of a new ticket in their organization. Your change nullify this case.

    You enforced a global policy to everyone instead of simply warning people and letting them the possibility to choose. Bad bad bad...

     

    0
  • Max McCal
    Comment actions Permalink

    rsmck - I appreciate your feedback and we are indeed approaching many of those other options. Rate limiting has not been successful for us, but we are working on a major content scanning solution that may one day allow us to provide more flexibility about this change, but the work required there is much larger, and this solution will close a vulnerability we cannot leave open at this time.

    Bianca Duma - You will not need to change anything about your triggers. The only case we wanted to call attention to is if your trigger message includes text such as "See below for a transcript", which we would recommend removing in this case. We can help you analyze your triggers if you need it.

    Ievgeniia Rudkovska - In case it's unclear, you will still be able to notify your customers of their request being received. The only change is that the notification will not contain their original message. It's possible you already understand that, but your phrasing wasn't clear to me, so I wanted to be sure.

    @jaïs - This change should not affect the organization subscription notifications you reference, but I will do some double checking on that. Because it is not controlled by triggers, but a separate type of notification, it is not included in this. Once I verify that, I will update the documentation.

    4
  • Ben Silkstone
    Comment actions Permalink

    Max McCal Just wanting to confirm that after the initial email these placeholders will function as normal i.e. end user creates ticket, we send ack, we send update on request with {{latestcomments.formatted}} the latest comments will display to the end user?

    0
  • Max McCal
    Comment actions Permalink

    Hi, Ben, yes. Allow me to quote from above and hopefully make our announcement somewhat clearer:

    The placeholder will not work if all three of the following are true:

    1. The recipient is an end-user
    2. The creator of the message is an end-user
    3. The trigger fires upon ticket creation

    Because of condition 3, the placeholder will expand as normal when additional comments are added, including the new comment from the agent and the original message from the end user. 

    2
  • Marko Lukač
    Comment actions Permalink

    Max McCal First of all, thank you for the patience in answering the questions and clarifying how this change will affect us. I'm a firm believer in a product-based approach, so as long as you guys made an informed decision regarding your product, I'm cool with it.

    One think that I am interested in is confirming whether this will affect the Organization Subscription Notifications? So once you've checked that, I would appreciate if you could let us all know.

    Keep up the good work!

    4
  • Laura
    Comment actions Permalink

    Hello Max McCal,

    We are thinking of implementing the answer bot as a widget on the page but also in the automatic email confirmations. Does the upcoming change have any impact on that feature?

    Thanks!

    0
  • Max McCal
    Comment actions Permalink

    Marko Lukač - Appreciate the vote of confidence. Yes, organization subscriptions will continue to function as expected. We don't consider them a major vector for spam. I confirmed this last night and will be adding a note to the article shortly.

    @laura - The Answer Bot functionality won't be affected, but if the trigger you use to send an Answer Bot response contains one of the placeholders, that placeholder will be suppressed, and the article suggestions will not.

    0
  • Ignacio De la Llave Lorenzo
    Comment actions Permalink

    Hi,

     

    I know the relation between this change and API has already been discussed but I wanted to check this use case as I don't think it's fully covered:

    We are creating tickets from our own site using API. The triggers are acting on tickets with the following characteristics:

    - Submitter: end-user

    - Recipient: end-user

    - Upon ticket creation

    - User creating the message: agent (as we are using the tickets end point)

     

    I would like to know if the placeholder would still work under this circumstances. So my question is: When you say "The creator of the message is an end-user" are you referring to the submitter (end-user in this case)? Or current user (agent)?

    Thanks!

    0
  • Jaïs Pingouroux
    Comment actions Permalink

    Thanks for your reply.

    Here is another use case which will be impacted by the proposed modification.

    In case of an outage of our service, we proactively create a ticket on behalf of our partners to let them know about the outage, so they may, in turn, ask questions or follow up on the ticket.

    The upcoming changes will make that the partners will simply not see the content of the ticket describing the outage, and will have to connect to the helpcenter to learn more about it, which incurs a higher risk of dissatisfaction compared to the fact of being simply "informed" by email.

     

    0
  • Max McCal
    Comment actions Permalink

    Ignacio De la Llave Lorenzo - We are working on making a change so that any submission through the /tickets endpoint is exempted from suppression. Because these requests must be made with an agent's credentials or an API token, they are not vulnerable to spam attacks under normal circumstances.

    @Jais Pingouroux - How are you creating the ticket? If the agent is creating it, then it's not affected by this change. The use case you're describing is definitely not affected by this change.

    0
  • Jaïs Pingouroux
    Comment actions Permalink

    Max McCal the agent is creating the ticket on behalf of one of the partner account, so that the ticket appears as created by the partner via the agent.

    1
  • Max McCal
    Comment actions Permalink

    If the agent is creating it through the UI of our Support product, it will work as expected. If the agent is creating it through the API, they should use the /tickets API (not /requests) and everything will work as expected.

    1
  • Ievgeniia Rudkovska
    Comment actions Permalink

    Hello,

    Could you please advise, when we make a follow-up on closed ticket, it creates a new ticket. And in this case we need customer too see our public comments to the ticket, otherwise we have to write two times. My question is: in the abovementioned case also the first reply in case it has placeholders mentioned previously will also not be seen to the customer? This is very important to us. thank you!

     

    0
  • Jaïs Pingouroux
    Comment actions Permalink

    "If the agent is creating it through the UI of our Support product, it will work as expected. If the agent is creating it through the API, they should use the /tickets API (not /requests) and everything will work as expected."

    Max McCal please correct me if I'm wrong, but using the tickets API doesn't allow to create a ticket on behalf on a customer based on his email address (I believe a ZD ID must be provided). We do have a case for which our customer can request assistance from our webapp by clicking a button. The only info we have is the email address of the customer. Therefore, we can't use the tickets API directly. Does that mean that instead of one request to the Requests API we first have to use the Users API to search for the ID of the user? And what if the user has no account in ZD yet?

    0
  • Ryan W
    Comment actions Permalink

    Hi Ievgenii,

    The agent will always be able to see the comment, it will never be removed from the UI or agent notifications themselves, so you should always see the comments, regardless of placeholder behavior.

    As for the enduser -- I believe on the initial follow up from the end user, it will be suppressed (but let me double check -- I will write back if this is not the case) to the end user -- on your replies, they should be able to see their original comment and yours, no issue.

    0
  • Kalle Windefalk
    Comment actions Permalink

    +1 for Matt Faircloth comment
    "My account also only allows authenticated users to create tickets in our Help Center. We would also vote to apply certain logic where this doesnt apply if an end user is authenticated. Thanks!"

    Same here.

    0
  • Max McCal
    Comment actions Permalink

    Jaïs - We will not suppress placeholders for any ticket created through the /tickets API endpoint. This endpoint requires Agent credentials, and therefor we consider it safe. If you're using /tickets, you'll be fine regardless of whether you know the user's ID. 

    Kalle Windefalk - We are not able to restrict this feature in this way. We've explored it and it's not possible at this time. If your account requires registration, or you do not allow the "anyone can submit tickets" option, suppression will be disabled for your account. What option are you using to prevent unauthenticated users from creating tickets? There may be other options.

    0
  • Dan Cooper
    Comment actions Permalink

    Max McCal - If I'm reading your comments correctly, placeholders will still work if the following are true: 

    • The ticket is created through the /tickets API endpoint
    • The account requires registration, or you do not allow the "anyone can submit tickets" option
    • The message is sent via a Target
    • The message is being sent via an Organization Subscription

    Is this correct?  If so, could these be added to the main article to avoid having to dive into the comments to see the full list of scenarios where placeholders aren't impacted?

    0
  • Max McCal
    Comment actions Permalink

    Hi, Dan - 

    I've added the last two. The other two are enhancements we're still implementing. Once they're confirmed, I will document them.

    0
  • Andrew Soderberg
    Comment actions Permalink

    Finally, I think this explains a lot! Thank goodness for this fix finally getting done.

    I expect that the exploit that this change is going to close, is the reason why so many email spam/malware scanning apps (e.g. MessageLabs, etc.) are targeting Zendesk emails.

    So much so, that many Zendesk customers CSAT survey results are polluted with false negative and false positive responses due to these systems checking the links to each domain in the emails (which causes a unsatisfied response -or a double response good/bad) that the requestor of ticket who received the CSAT survey email never responded to.

    Zendesk's emails have not been 'trusted' by these spam/malware scanning apps because of this exploit (or customers have removed them from any previous whitelist) due to the spam they were getting because of this exploit. This problem has been plaguing Zendesk for at least 2 years, maybe a lot more.

    https://support.zendesk.com/hc/en-us/articles/115012836948-Why-am-I-receiving-unexpected-bad-satisfaction-ratings-

    We've had to change our CSAT survey to remove the direct vote links in the email and go with just the link to the page where customers can vote. This of course increases response 'friction' thus reducing the response rate, but at least the responses are accurate.

    We've had to audit our CSATs to remove these 'zombie responses' from our reporting. We follow-up with every customer who replies 'unsatisfied', and when we find from customer confirmations that they did not reply to the survey email, we filter that ticket out of the reporting in Explore.

    As much as I would like to have an opt out option on this fix (we are B2B support behind a required login), getting Zendesk's emails trusted again is more important to us. We want to be able to use the instant CSAT voting in emails, but can't.

    5
  • Boyan Parshorov
    Comment actions Permalink

    Hello, we have 2 questions regarding the above changes:

    1 - Is there a way for you to Enable this in STG, this way we can test it?

    2 - Can Zendesk system check if an End User is already added, because this means it is trusted?

    Thank you.

    0
  • Max McCal
    Comment actions Permalink

    Hi, Boyan - 

    1. We aren't yet able to enable this as there is still some development going on. Once we are ready we can offer early access. Will post here when that is an option.
    2. This isn't possible given the constraints we have in place.
    0
  • Yann
    Comment actions Permalink

    Oh my god ! It makes ticket creation functionnality totally nonsense !

    We use it a lot

    Please fight against fraud in different manner than removing usefull fucntionnality !

     

    UPDATE :

    Fianly it' should be ok with those explanations below. I' am sceptical regarding the third condition

    The placeholder will not work if ALL three of the following are true:

    1. The recipient is an end user
    2. The creator of the message is an end user
    3. The trigger fires upon ticket creation
    -1
  • Max McCal
    Comment actions Permalink

    Yann - It looks like you're saying the changes are okay for you in your update. Can you explain what makes you skeptical about the third condition?

    0
  • Yann
    Comment actions Permalink

    Max> indeed, if an agent can create a ticket with its first comment sent by mail well displayed to the final user, then it is OK.

    We have often the case where clients contact us by phone, and then we create the ticket ourself in the system.

    If the comment had to be hiddent it would have been a big issue to manange (create then send ticket twice etc..)

    So could you confirm that this case won't occur when an agent create a ticket himself ?

    0
  • Max McCal
    Comment actions Permalink

    Yann - I can confirm, yes. As is stated in the article -- "Placeholders will still work if ANY of the following is true (...) The creator of the message is an agent." I am assuming that when you say "and then we create the ticket ourself in the system", you mean that an agent creates it.

    0
  • Yann
    Comment actions Permalink

    Max, yes this is exactly that, so it is OK.

    So perhaps that your communication was not enough clear at the begining because i (and some other i guess) had a big stress reading the title and the first explanations.

    0

Please sign in to leave a comment.

Powered by Zendesk