Prevent "Thank you" replies from reopening tickets
Hi there! Do you have really kind customers who reply just to say "thanks"? This is great, but it creates more work / clicks for agents, and can impact reporting on agent handle times / time to resolution.
Here's a tip to address that. It's not a perfect solution (the ticket still reopens, then immediately re-solves), but hopefully it helps until the decade-old feature request is addressed natively. One day. I believe 🤞
Okay, here's the idea. If any of this sounds complicated because webhooks and API, don't worry! We'll break it down step by step, and please feel free to comment with any questions.
- When a Solved ticket is replied to from the requester, and their comment includes "thank", "thanks", "merci" or any translations/variants you want, we are going to trigger an action to notify the "Update Many" bulk tickets endpoint. No, we aren't bulk updating multiple tickets. This endpoint can be used for a single ticket. It's useful for its "additional_tags" property that the regular update tickets endpoint does not have.
- In our call to that endpoint, our JSON body includes some liquid markup. We are checking the last public comment on the ticket for its comment.value.size before adding a unique tag, and solving the reopened ticket.
Why do we care about comment size? This will ensure we only solve the brief "thank you" tickets. We will not solve paragraphs that happen to include "thanks in advance for your help". We will not solve any "thanks, but I still need help with xyz". No false positives.
Why are we adding a unique tag? This is to aid you in reporting. If you are counting # end-user public comments, for example, you can subtract 1 for tickets that have this unique tag. Or, you can subtract 1 from # reopens for tickets with this tag. It's also a good idea have a unique tag in case troubleshooting is required.
Shout out to for Ash for inspiration from a similar solution to tag tickets containing attachments. I am shamelessly copy-pasting from some of their steps.
Here we go!
1. Enable API access (see screenshot)
Password Access (item 3 on the screenshot above) - enable if you want to authenticate using your admin username and password for the webhook API calls.
Token Access (recommended) - To use an API token for the webhook, select item 4 on the screenshot, then "Add API token". Copy the token right away. It is only shown to you once. This will be used for basic auth in the next step.
2.Create webhook
Title : Update Many endpoint
URL: https://domain.zendesk.com/api/v2/tickets/update_many.json?ids={{ticket.id}}
Method: PUT
Content Type: JSON
Authentication: Basic auth
For basic auth with API token, your username will be email@address.com/token. Password is the API token created from step 1.
3. Create Trigger
Trigger Name: Close and Tag thank you replies
ALL Conditions:
- Status is Solved
- Comment is present
- Requester is current user
- Comment text contains the following words: thank, thanks, [insert translation or other variants]
Actions:
Notify active webhook: Update Many
JSON body:
{"ticket":
{% for comment in ticket.public_comments offset:0 limit:1 %}
{% if comment.value.size < 25 %}
{"status":"solved",
"additional_tags":["thankyou"]}
{% endif %}
{% endfor %}
}
There you have it! Make sure to test different scenarios (solved replies with short "thank you" and solved replies with longer "thanks, but I still need help with..."). You might want to play around with the exact character count if you find 25 is too short. "thanks for your help!" is 21 characters.
If you don't have a sandbox, a tip for testing is to add an extra trigger ALL condition to say something like "Subject text contains MYNAMETEST" so it only fires on your test tickets. You can remove this condition when testing is complete.
Thanks for reading!
-
Love this solution!
-
Agree with Amie. Amazing solution. Thanks for sharing Stephen!
-
If you take this portion and put it into a dynamic content block you can fix the error that will show up on the action telling you that your JSON is broken.
{% for comment in ticket.public_comments offset:0 limit:1 %}
{% if comment.value.size < 25 %}
{"status":"solved",
"additional_tags":["thankyou"]}
{% endif %}
{% endfor %}Your new output could look like:
{"ticket":
{{dc.thanks_solver}}
} -
I agree with Amie! Amazing solution. Thanks for sharing this Sphen!
-
Yeah, I know that problem. It is kind of annoying when those reopened messages start to pile up. You can use this app on Zendesk's marketplace: https://www.zendesk.com/marketplace/apps/support/470124/thank-you-gpt
-
Hey there, Dan Cooper - I'm needing more direction on how to bypass that JSON error. Can you show me exactly what's supposed to be copied/pasted into that block? I don't know what a dynamic content block is, and I'm not as savvy with this stuff as others are on the thread. Thanks for your guidance!
-
Also, Stephen Belleau - for step 2, basic authentication with an API token, will the user name be inputted as email@address.com/token, or will it be [my Zendesk authentication email]/token (as email@address.com was just a representative placeholder for those creating the webhook)?
-
Hi Sarah Seiwert - I haven't set this exact thing up but I've done similar. Here's how I'd answer your q's:
For the dynamic content -- You probably have this feature but according to the ZD pricing/feature table, if you're on the "Suite Team" plan you don't have access to the DC feature. Also, I think this will still work even when it's indicating a JSON error in the editor so this part, I believe, is optional. But here's how to do it. Navigate to the dynamic content by going to:
Workspaces > Dynamic Content > Add Item
And then create an item that looks like this:
Now you can reference this DC item as placeholder in the JSON body like this:
{"ticket":
{{dc.thanks_solver}}
}So everything you put into the dynamic content item will be inserted into the request body in place of where the {{dc.thanks_solver}} placeholder is referenced.
As for authentication, you need to use the actual email address of the Zendesk account. It's advisable to use a service account, rather than an account of an actual member of the team, for authenticating Zendesk webhooks and potentially other third party integrations. It's easier to tell that an integration user or service account has made the update when you can name the account making the update something like "Zendesk Integration User".
-
Sarah Seiwert it looks like Ronald was able to answer your question about how to use dynamic content. It's not a necessary step, but it helps clean up the errors and allows you to reuse the same dynamic content placeholder in multiple triggers that require the same logic.
-
Oof, still not successful. What's the problem on my end? Is it how I've defined the trigger against what the JSON is trying to read?
Here's the webhook with a basic authentication of my [email/token] (for now...) and API token for the password:
Followed by the trigger (first part). Originally selected "Comment is [Present, and request can see the comment], but that didn't quite match the description, so opted for "Comment is Public"
And second part:
With error:
And finally, the JSON for the dynamic content:
-
hey Sarah Seiwert,
You're just missing some extra "". Give the below a whirl! Tested on my side and doesn't error out. :)
{"ticket":
"{{dc.thanks_solver}}"
} -
Finally! It worked! Thanks, Amie Brennan!!
-
Stephen Belleau This sounds like an awesome solution but I'm having trouble implementing help, I'd love some guidance.
First, I added the code from your article directly to the Trigger and tested with a ticket. The Trigger fired but the tag wasn't added and the status wasn't changed. When viewing the activity for the webhook, I see a 422 error and it looks like the JSON that was sent was this:
{"ticket":
}So I then took Dan Cooper's advice and put the code into a Dynamic Contact and changed the JSON within the Trigger to:
{"ticket":
{{dc.thanks-solver}}
}But nothing happened and the webhook activity shows that the JSON being sent was the same as before, blank.
I even tried Amie Brennan's tip to add quotation marks but that didn't help.
So I then tried replying to the test ticket but removing the original email conversation from that reply, thinking that maybe Zendesk was detecting the original back-and-forth as part of the character count. It's still not solving the ticket or adding the tag but this time it looks like the JSON being sent does have content:
{"ticket": "\r\n\r\n{\"status\":\"solved\",\r\n\"additional_tags\":[\"thankyou\"]}\r\n\r\n" }So I guess I have two questions here:
- How do I fix the issue with sending the proper JSON?
- How do I resolve the character count confusion?
Would love any help/guidance I can get here!
-
Here is how it breaks down on the Thank You App for those interested. For 2 weeks in July 2023, we measured the number of characters in Thank You messages. Turns out more than 50% are longer than 25 characters:
-
Hello,
So I am trying to do something similar but the opposite. We calculate agent comments as a metric, but I want to identify how I can count how many of those comments are agents who simply respond thank you/thanks to a customer/vendor.
Does anyone know how to accomplish this?
Thank you
-
Hi Thomas,
Though Explore can count the number of ticket comments, unfortunately, it doesn't capture the content of ticket comments. So it cannot identify or isolate the "Thanks" or "Thank you" responses.
Thank you.
-
Just a quick addition to this:
I couldn't get this to work to begin with, but then I changed the trigger:
I changed Status is Solved to Status changed from Solved. -
Very cool solution. Is the email signature of the requester counted in the 25 characters? My gut says yes.
-
Spencer Hutton Yes it is.
Iniciar sesión para dejar un comentario.
19 Comentarios