Changing what triggers fire on tickets created by Chat Channel | Community
Skip to main content

Changing what triggers fire on tickets created by Chat Channel

  • June 16, 2021
  • 3 replies
  • 0 views
Chad16

Hi All

Searched high and low but couldn't find an answer.

Assumptions:

  • Zendesk Support and Chat on Agent workspace (ie: chats are handled in Zendesk Support through a ticket)
  • Customer email address is captured during or via the pre-chat form and is the requester of the ticket
  • Ticket Channel is Chat (and will always be Chat) - ie: Ticket can't be created as Chat, then the conversation moves to another channel (eg: email). The ticket channel can not be changed to the new channel (eg: email)

Scenario:

Customer chats, agent serves chat. All goes well and the chat ends.

Desired Outcome 1:

  • When a chat has ended, we don't want any email notification triggers firing and sending an email to the customer - essentially reminding them of what they just chatted with us about.

Desired Outcome 2:

  • When a chat has ended, if the ticket needs follow-up (via email) we DO want email notification triggers firing and sending an email to the customer

I can't seem to think of the best way to accomplish this. I can't use a condition based on 'Channel', because Chat will always be the ticket channel in the above scenario. So if I filter by 'Channel is Chat', then it will stop both sets of triggers firing.

The only thing I can think of is that the agent will need to add a tag (via a field, macro, manual etc) which we can look for to send email notifications but suppress any other notifications if the tag doesn't exist and the channel is Chat.

However, this is very problematic as the agents MUST remember to add the tag to ensure the email notifications are sent for follow-up. Obviously this is very risky. If the agent forgets to add the tag, updates the ticket and thinks the notification has been sent...but it hasn't.....big trouble.

So I'm wondering if anybody else has solved this and in what way did they solve it?

Any help hugely appreciated (hope this makes sense BTW :)

      3 replies

      Darenne
      • Darenne
      • June 28, 2021

      Hi Chad,

      The closest way to achieve what you want to happen is to create a trigger to add a tag to the ticket if the ticket is created via chat channel then you can use that condition on your existing triggers to not send a notification via email.

      For example, we have the default trigger "Notify requester and CCs of received request". You can add the condition Tags> Contains none of the following> Enter tag to detect a trigger with such a tag that will not send a notification to the user. On the other hand, if you want to create a trigger to sends a notification to those, then use Contains and at least one of the following.

        Tim14
        • Tim14
        • November 15, 2021

        We face exactly the same problem. I have considered an automation that deletes a tag, so we are able to first add a tag via a trigger to make sure the email trigger does not fire when a chat is ended, but when doing a follow-up after a chat it does.

        Unfortunately, you can only select 1 hour as the shortest amount of time, which might be too long when you are just looking up some information to send to a customer.

        It surprises me that this question has not collected more contributions, since I can imagine a lot more Zendesk users have run into this issue.

          Chad16
          • Chad16
          • Author
          • November 16, 2021

          Hi @tim14

          Yeah it's a thorn in the side for sure. No way around it really although I have one idea that recently came to mind but I need to test. If I do and it works, I'll post something here.

          For now I just use a tag and educate the agents about how it works.

          Certainly not ideal but it works.

          I have also thought about creating some convoluted workflow using targets and the API to do something when the ticket is updated etc but not enough time to get around to testing it :)

           

            Terms & ConditionsCookie settingsAccessibility statement