Trigger / Filter Question
My organization has an issue with scammers emailing support with just a single word. Like just saying the word "Refund" with no additional context. Trying to set up a trigger, it doesn't look like I can filter these based on an exact match, I can only do "at least" a word or string, as seen below:
Of course, I can't filter out that string or word as real users would definitely use it. I also tried filtering out other 'strings' of characters where I just tried filtering out the use of any other letters but that didn't seem to do anything:
Does anyone have a suggestion on how I could filter these?
Also, I have tried looking at many other ways of filtering but there is no common domain or location etc. these tickets seem to be coming from. Captcha also doesn't work for our situation.
Thanks for any help here
Hi Brian Hlister, that sounds like a bad headache. You're absolutely correct regarding the risk of having too many false positives by detecting sole keywords.
So if I understand correctly, they also use different email providers (many or just a few?).
Are there any repeat offenders, or does each spam ticket originate from a new email address every time?
Hi Pedro, thanks for reaching out!
It's a different email address every time. No patterns there either, always a mishmash of letters, words, and numbers. They're being pretty crafty.
I thought I had something by trying to filter out the single letters which wouldn't be included but I'm guessing there's some kind of restriction or something happening within the backend structure of Triggers preventing it.
Ah, I understand - thanks for the clarifications. Would you be comfortable sharing a list with a few of those usernames and/or domains, please? A screenshot will do, if possible!
(Note: I'm not doubting your word, I'd just like to see real examples to confirm a hypothetical solution)
I can't share the real ones so these aren't the exact emails but I kept the spirit of the email addresses if that makes sense. The domains are the same.
So like, if an email was 'email@example.com" I might change it to "firstname.lastname@example.org"
That being said, the usernames (requester names?) seem to always be the same as the email addresses, aside from the domain. Everything before the "@" symbol.
Hi Brian, many thanks for those. My hypothesis was along the lines of a simple web service that would perform some REGEX-like validation, but we can scratch that one, given the examples.
- Do the spammers write to the same email address, or use the same form? Are they using different channels or is the channel always the same?
- If the channel is email, is there any way to set up any kind of spam filtering on your email server side?
Yeah, it's tricky.
All emails are sent through the same channel, through multiple forms. There's no consistency as they'll jump around from form to form asking for refunds. There might be something on the email server side we could do? I'm not sure how much we can control that with Zendesk.
One of the issues is we don't require someone logs in to send an email (we can't require this). So they could just input anything they want in our custom email address field on the submission form.
"There might be something on the email server side we could do?" That would be very much worth checking out.
Another thing that occurred to me: I'm assuming you have a proper form and ticket field to submit a proper refund question, right? If that's the case and they always mention a refund regardless of the form, maybe you could create a trigger to tag all suspicious requests, in order to set up a "spam triage" view? Example trigger below:
- Ticket Is Created
- Current user Is end-user
- Channel Is Web form
- Form Is not [your proper form to submit a refund question]
- [custom field containing the refund option] Is not [request a refund] option
- Subject text Contains at least one of the following words: refund
- Comment text Contains at least one of the following words: refund
- Add tags: eg. zd_spamcheck (specific tag that you'd then use to create a triage view) plus a secondary metrics_zd_spamcheck tag (in case you want to report on these cases).
Afterwards you can exclude the first tag from your main support view(s). Additionally, create a "Spam - false positive" macro to remove the tag and submit the ticket as Open (i.e. false positive and move ticket to main views); etc.
Of course, they can later change their spam requests to something else ("register account" instead of "refund"), so you'd have to adapt that workflow by creating additional triggers or updating the existing, if possible.
You probably have thought of this already, but that's the only remedy (native to Zendesk) that I can think of for the moment.
Pedro - I really appreciate the help here!
I was finally able to get something to work. I made a Trigger that was set up to have it look for the word "Refund", then use "Contains none of the following words" and type out the 100 most common words used in English. After some testing, there were a couple that slipped through but I was able to also update the Trigger for those kinds of instances. I'll keep monitoring and updating the trigger as needed but this approach is showing promise.
That's an awesome workaround, Brian! Nice one :-)
Hi Brian Hlister, do you have some print screen of your solution into the trigger?
Trigger / Filter Issue
My company needs help needs help with fraudsters contacting assistance with a single phrase. It's like uttering the words "Refund" without any context. When I try to set up a trigger, it doesn't seem that I can filter these based on an exact match; instead, I can only do "at least" a word or string, as seen below:
Of course, I can't exclude that string or word because real users would undoubtedly use it. I also tried filtering out other strings of characters by just excluding the usage of any other letters, but it didn't appear to help:
Do you have any suggestions for me? Could you filter these?
Additionally,I've looked at various filtering options, but there is no common domain or region from which these tickets are coming. Captcha could be more effective in this circumstance.
Thank you for your assistance.
Por favor, entrar para comentar.