Preventing e-mail loops with non-Zendesk Support Systems | Community
Skip to main content

Preventing e-mail loops with non-Zendesk Support Systems

  • January 15, 2024
  • 2 replies
  • 0 views
P

Hi everyone! 

I was hoping that this wonderful Zendesk community might be able to help with a problem that we're encountering at the moment. Full disclosure - we are not yet live on Zendesk, we are in the process of migrating over, however from previous experience I am worried the same problem will occur when we go live.

First, some background: We operate in a B2B2C type environment, and only sell our products to IT Re-sellers. Responsibility for First Line Support lives with the re-seller, and they will escalate to us if they are unable to solve. This often means that a whole bunch of troubleshooting information needs to be sent to us at the point where our customer wants to raise a ticket. Once a ticket is raised with us, we liaise with the reseller, not the end customer.

What we're finding is that, because our Customers are using their own Support Ticketing system with commentary we need, they use their own Ticketing platform to contact us. This creates a significant problem with e-mail loops. For our customers that use Zendesk for ticketing, this isn't a problem - Zendesk handles that really well. But we're finding that if a different system is used (e.g. Salesforce) then we end up in an infinite mail loop and get blocked by the customer's own Ticketing system. Which then results in our customer never receiving our reply, because other messages have been stuck in a loop.

Has anybody else encountered this particular problem? I really do not want to tell our customers not to contact us via a Ticketing system if there is a viable solution anywhere.

Thanks in advance for any thoughts and guidance :)

Paul.

    2 replies

    Jacob20
    • Jacob20
    • January 16, 2024

    Hi  @paul50,

    This is common in B2B setups, especially other help desk systems as you mention. My understanding is that these help desks send emails without the proper headings that should let the receiver know that it is a system sender, not an email client.

    I have given up on persuading the owners of such systems to change their practice, so here are a few suggestions on what you could do.

    First, this loop happens when a request is sent to your support address, your "request received" trigger sends back a confirmation email to the sender, the sender sends back its own "request received" and now the loop is on. Zendesk will temporarily suspend the requester after about 20 iterations, giving you and your agents a break to merge or delete these tickets.

    We do one of two things, once a requester has been identified as a troublemaker, we make sure this particular trigger no longer fires on their ticket creations:

    1. You could add a tag condition to the trigger e.g. no_email as a "does not include" in the ALL section. Agents (or you) could then add this tag to the requester and prevent the trigger from firing (requester tags are inherited by new ticket creations, so the trigger will not act on future tickets).
    2. Alternatively, you could add a Comment does not include "INSERT STRING FROM SENDER HERE" 👈 This could be "your ticket has been received". 

    The second option may throw a wider net since a lot of these help desk messages are common, however, it may also catch some false positives.

    I hope this helps you out.

    Peter11
    • Peter11
    • January 16, 2024

    Hi @paul50 and @jacob20

    In general, it is required to get a grasp on when to send messages.
    Using the standard Zendesk Triggers will not work well in the long run.

    We devised a system where we do send mails only if some tags tell us to.

    These tags are added or removed by various triggers. let me share our trigger groups list:

    As you see, we have 3 groups at the end that contain all notification triggers.

    What is missing here is the ability to clean out the notification tags at the end - Zendesk does not offer anything like the "finally" clause in this trigger list which would contain at least one trigger that is executed last. Therefore, we persist the notification tags, and clean them upon the next trigger run through the ticket at the very beginning of the list: "Initial Actions and Notification Cleanup".
    It's not nice, but it works.
    The tags we use for triggering notifications are:

    • notify_requester --> notified_requester
    • notify_assignee --> notified_assignee
    • notify_assignee_not_needed
    • notify_group --> notified_group

    If you are the assignee, and you work on the ticket, no need to notify yourself about the ticket.

    The others start out in the notify_ form and are set to the notified_ form by the trigger sending the notification.

    Hope this serves as food for thought...

     

    Terms & ConditionsCookie settingsAccessibility statement