Plan requirement
| Subscription | Any plan |
| Access | Admin |
It matches anywhere in the comment, including quoted text and signatures. That is why it fires more than expected.
What it looks at
The whole comment as text, not the meaning and not just the new part. Which operator you chose then decides what "contains" means: the word operators take words separated by spaces, while Contains this string matches a phrase as written.
The three surprises
Quoted text counts
An email reply includes the thread underneath. Your rule looking for "refund" matches a customer replying to your message that happened to mention refunds.
Signatures count
A footer, a job title, a legal disclaimer. All of it is comment text, and disclaimers contain a great many words.
The two operator families behave differently
A string condition looks for your text as it appears, so it also finds it inside longer words. A word condition takes a list separated by spaces. Picking the wrong one is why a rule catches too much or too little, and the fix is usually to switch family rather than to reword the term.
With string conditions, each phrase you want needs its own condition under Meet ANY of the following conditions.
Making it more reliable
- Match distinctive phrases rather than single words. Three words together rarely appear by accident.
- Add a channel condition, so it only applies where you expect.
- Add a current user condition, so agent replies do not trigger it.
- Test on a month of real tickets before you act on it. Build the rule to add a tag only, look at what it caught, then add the real action.
Where it is genuinely useful
Machine-generated content with fixed wording, and specific phrases that only appear in one situation. Not general intent detection, which is a different capability.
Comments
0 comments
Article is closed for comments.