DEV Community

Dingdang CS
Dingdang CS

Posted on

Keyword Triggers That Don't Misfire: Match Rules for WeChat Auto-Reply Tables

Every WeChat auto-reply setup starts the same way: a list of keywords, each wired to a canned response. And most setups start misfiring within weeks, because the match rules were never designed — they just accumulated. A customer asking "when will my refund arrive" gets the shipping-policy reply; a customer typing "退货" gets nothing because the table only has "退款". The table isn't the problem. The match rules are.

This article walks through the design decisions that keep a keyword table predictable: match types, priority, negative keywords, and the audit loop that catches silent failures.

Match types: choose deliberately, not by default

Most tools offer three match modes, and each has a distinct failure profile:

  • Exact match only fires on the precise string. Safe, but brittle — "退货" won't catch "怎么退货". Use it for codes and short commands ("查订单", account numbers).
  • Contains match fires when the message includes the keyword anywhere. Broad, but collision-prone — "退" as a keyword will fire on "退化", "退休", and any sentence containing the character.
  • Regex (where supported) is the right tool for structured patterns: order numbers, tracking IDs, date ranges. It is the wrong tool for free-text intent, because customers do not write in patterns.

A workable rule of thumb: exact match for commands, contains match for nouns that rarely collide, regex for IDs. If a keyword's match type needs a paragraph to explain, it is too clever and will misfire eventually.

Priority and conflict: the table needs an arbiter

When two keywords both match, most systems pick by table order — which means the reply a customer gets depends on which row someone edited last. Fix this with explicit tiers:

  1. Tier 1 — transactional keywords (order status, refund, exchange): highest priority, because a wrong answer here costs a customer.
  2. Tier 2 — policy keywords (shipping, hours, sizing): safe to answer from a template.
  3. Tier 3 — greeting and filler ("在吗", "hello"): lowest, and often better answered by the fallback message than a dedicated row.

Within a tier, longer keywords win over shorter ones — "退货流程" should outrank "退货". Document the arbitration rule in the table itself (a column, a naming convention), not in someone's head.

Negative keywords: the cheapest accuracy upgrade

A negative list is a set of terms that suppress the reply even when a keyword matched. Two entries cover a large share of real-world misfires:

  • Complaint markers ("投诉", "举报", "315"): any message containing these should reach a human, not a template. A canned reply to an active complaint escalates it.
  • Negation ("不用", "别", "算了"): "不用退了" contains "退" and must not trigger the return-policy reply.

This one rule — complaints and negations suppress auto-reply — prevents the two replies customers screenshot and post about.

The fallback is part of the table

Every keyword table needs a defined miss behavior, and "no reply" is the worst option, because silence reads as indifference. A good fallback states what the system understood, offers the top three likely intents as choices, and names the path to a human. When the fallback covers the miss well, you can keep the keyword table small — and small tables stay auditable.

Weike AI Assistant treats the fallback and keyword table as one configuration surface for this reason: match rules decide what the bot says when it knows, the fallback decides what it says when it doesn't, and the two need to agree on tone.

Audit loop: the table rots without one

Keyword tables decay as products, policies, and slang change. A monthly 30-minute audit keeps them honest:

  • Export messages that triggered no keyword (the misses). The top recurring misses are your next keywords.
  • Export replies that led to a human handoff within two messages (the wrong answers). Each one is either a keyword to retire, a negative keyword to add, or a template to rewrite.
  • Check collision counts: keywords that fired on fewer than a handful of messages a month are either dead rows or over-narrow matches.

The audit matters more than the initial build. A table designed once and never audited converges toward the exact state you were trying to avoid: confident wrong answers at scale.

Related reading

Top comments (0)