Keyword triggers that actually match what customers type
Why your 'refund' rule misses half the refund requests, and the keyword lists that don't.
A keyword condition checks whether the customer's message contains any one of the phrases you list, and stops the flow if it contains none of them. Matching is case-insensitive, one phrase per line, and by default it looks for your phrase anywhere inside the message rather than requiring the whole message to equal it.
That default is right, and the failure mode is almost never the matching engine. It is the list. Merchants write the three words they would use and then discover customers use thirty others — often in a different script entirely.
Contains versus exact
| Mode | Keyword "return" | Matches | Use it for |
|---|---|---|---|
| Contains (default) | "return" | "I want to return this", "RETURN", "returning my order" | Almost everything |
| Exact | "return" | Only a message that is exactly "return" | Menu shortcuts, STOP-style commands |
Use exact sparingly. It is right for a one-word command you have told customers to send, and wrong for anything a human types naturally, because a single trailing full stop breaks it.
The substring trap
Because "contains" looks anywhere in the message, short keywords match things you did not intend. A three-letter keyword is almost always a bug waiting to happen.
| Keyword | Also matches | Fix |
|---|---|---|
| cod | "code", "codes", "discount code" | Use "cash on delivery" and "c.o.d" instead |
| ship | "relationship", "shipment" | Fine here, but check the false positives |
| size | "sizes", "sizing" — both wanted | Leave it |
| no | "now", "notes", "another" | Never use two-letter keywords in contains mode |
The rule of thumb: five characters or fewer, think twice. Read your keyword back as a fragment inside other words before you save it.
Write lists from real messages, not from imagination
The best source of keywords is your own inbox. Before writing a rule, search your existing conversations for the intent you are automating and copy the actual phrasings. Customers asking where an order is write, in roughly this order of frequency: "where is my order", "order status", "tracking", "has it shipped", "when will it arrive", "any update", "kb tak aayega".
That last one is not a typo, and it points at something most keyword lists ignore entirely.
Customers do not type in one language
In Pakistan, India, the Gulf and much of South-East Asia, customers routinely write in a Roman-script transliteration of their own language, or switch scripts mid-sentence. "bhai kitna price hai" is a price question. "delivery kab ayegi" is an order-status question. Neither contains a single English keyword you would have guessed.
Because matching is plain text, this is fixable — you simply need the transliterations in the list. But there is no spelling standard for transliterated text, which means one phrase is not enough.
| Intent | English | Roman Urdu / Hindi variants worth adding |
|---|---|---|
| Price | price, how much, cost, rate | kitna, kitne ka, qeemat, keemat, rate kya |
| Order status | where is my order, tracking, update | kab ayega, kab tak, order kahan, kidhar hai |
| Availability | in stock, available, do you have | available hai, stock hai, mil jayega |
| Cash on delivery | cash on delivery, c.o.d | cash on delivery, delivery pe cash |
Add both the common spelling and the obvious variants. "kitna" and "kitne" are different strings; both are common. This is unglamorous work and it is the single highest-return thing you can do to a keyword list in these markets — enough so that it has its own guide: when customers type Roman Urdu, Hinglish or mixed Arabic.
Where keywords stop being the right tool. If you find yourself maintaining a list of eighty phrases for one intent, you have outgrown keyword matching. That is the point to use Answer from Knowledge Base, which matches meaning rather than characters and does not care which script the customer typed in.
Ordering matters when several rules could match
More than one automation can match the same message. If you have a "returns" flow and a general "AI answers everything" flow, both will consider a message saying "I want to return this". Rule priority decides which runs first, and a flow can be set to stop the others from running after it.
The practical pattern is: specific rules first, catch-all last. Returns, wholesale and order-status rules should sit above a general AI responder, and the general responder should be the only one without a keyword condition.
Ten keyword lists worth stealing
- Order status: where is my order, order status, tracking, track my order, has it shipped, when will it arrive, delivery status, any update
- Returns: return, refund, exchange, send it back, wrong item, damaged, faulty, doesn't fit, does not fit, too small, too big
- Cancellation: cancel, cancel my order, don't want it, changed my mind
- Stock: in stock, out of stock, sold out, back in stock, restock, available, notify me
- Price: price, how much, cost, rate, discount, cheaper
- Wholesale: wholesale, bulk, reseller, distributor, trade price, trade account, large quantity
- Delivery speed: how long, same day, next day, urgent, dispatch, when will it arrive
- Payment: cash on delivery, c.o.d, payment failed, card declined, payment link, bank transfer
- Address change: change address, wrong address, update address, different address
- Human: agent, human, representative, talk to someone, speak to a person
Copy these in, then spend twenty minutes in your own inbox adding the phrasings your customers actually use. That second step is the one that matters.
How to tell whether a keyword rule is working
Each automation has an activity view showing every run and which conditions passed. A keyword rule that never fires shows no runs at all — which is the signal that your list is missing the real phrasings, not that the flow is broken.
Test with the simulator first, then with your own phone. Deliberately type the message the way a rushed customer would, misspellings included. Testing an automation safely covers the protocol.
One thing keywords cannot do
Keyword conditions read the customer's message text. They cannot read an image, a voice note or a PDF. If a customer sends a photo of a damaged item with no words, no keyword rule will match it. Use the If Customer Sent condition to detect the attachment type instead, and route those to a person — or to an AI Check step, which can look at an image.
And keywords never override Meta's rules. A matched keyword still cannot get you a free-text reply outside the 24-hour window, and the reply your flow sends is subject to the same pricing rules as any other. Matching is about intent, not permission.
Frequently asked questions
Is WhatsApp keyword matching case sensitive?
No. Matching is case-insensitive, so 'RETURN', 'Return' and 'return' all match the same keyword.
Why does my keyword rule catch the wrong messages?
Because 'contains' mode matches your phrase anywhere inside the message. Short keywords like 'cod' also match 'code' and 'discount code'. Keywords of five characters or fewer need checking as fragments.
Can a chatbot understand Roman Urdu or Hinglish?
Keyword matching is plain text, so it matches transliterated phrases if you add them to the list — and you need several spellings, since there is no standard. For meaning-based matching across scripts, use the knowledge base step instead.
Can a keyword rule match a photo or voice note?
No. Keyword conditions read message text only. Use the If Customer Sent condition to detect attachments by type, then route them to a person or an AI step.