Writing rules that behave

A rule runs on every ticket its event brings in, around the clock, with nobody checking its work. These habits keep that from going wrong.

Name rules by what they do#

Start each name with the kind of job, then the subject: "Tag: refund requests", "Route: wholesale to the Wholesale team", "Close: payment notifications", "Reply: acknowledge new emails". The list then reads as a plan, and anyone can see at a glance which rules could close or answer a ticket. Use Description for why the rule exists and who asked for it.

Order them: tag, then route, then close or reply#

Rules run from the top of the list down, and each one sees the changes the rules above it made. A sensible order is:

1. Tag rules, which describe the ticket.

2. Route rules, which set the team, agent and priority, often from those tags.

3. Close and Reply rules, which act on everything above.

Two consequences follow from how the engine works:

• Rules do not set each other off. A tag added by one rule only helps a later rule in the same run, so a routing rule that looks for that tag must sit below the tagging rule and share its event.

• If two rules set the same thing, such as the priority, the lower one wins. Avoid pairs that pull in opposite directions, or merge them into one rule with Otherwise.

Keep conditions tight#

• On A message is added to a ticket, add Sent by an agent is No. Without it, the rule also runs on your team's replies and notes.

• Keyword lists match parts of words in any capitals: "return" matches "returned" and "returning", and also "return address". Before switching a rule on, search your tickets for each word and read what comes back. See Search tickets and customers.

• Prefer phrases over single words for anything that closes or replies: "where is my order" is safer than "order".

• Use Channel is Email on reply rules unless you mean to answer chat and forms too.

Test before you trust it#

1. Build the rule with only an Add tags action, such as test-refund, and save it.

2. Let it run for a day, then open a view filtered by that tag (see Views and sections) and read what it caught.

3. Adjust the keywords, then add the real actions and remove the test tag.

On any ticket, Show events above the conversation lists each rule that ran and what it changed, which answers "why did this ticket get tagged?" in one click.

Tagging rules#

Tags are the cheapest action and the easiest to undo, so most rules should start as tagging rules. Good first ones: refund requests, damaged items, address changes, discount code problems, wholesale enquiries. Use the same tag names your macros and views use, and create the tags first in Tags so everyone picks from one list. If you later rename or merge a tag, update the rules that name it: they keep the old name and would create it again.

A rule can also fill in a ticket field with Set a ticket field, for example setting Contact reason to "Damaged item" when the message mentions breakage. That keeps your reports by contact reason complete without agents choosing it every time.

Routing and urgent tickets#

• Route by tag or by the customer's email domain: Customer email ends with "@yourwholesalepartner.com", then Assign to team Wholesale.

• For customers who sound ready to cancel or dispute a charge, match phrases such as "chargeback", "cancel my order" or "speak to a manager", then Set priority High and add a tag. Pair it with a view of open high-priority tickets so somebody looks at them first.

• The helpdesk's own triage also raises priority for chargeback and legal wording; see Urgency settings. A rule is for wording specific to your store.

Closing rules#

• Close only what nobody needs to read: automatic replies, notifications from your own tools, messages from addresses you have decided to ignore.

• Always tag before you close, so the tickets are easy to find if a rule catches something it should not.

• Add Skip the satisfaction survey to a rule that closes tickets, or the sender may be asked to rate a conversation that never happened.

Reply rules#

• Reply on A ticket is created, not on every message, or customers get the same automatic answer each time they write.

• Say what happens next and when; do not pretend to be a person. The reply shows as sent by Automation inside the helpdesk.

• Variables work in rule replies, except the agent ones. A reply that uses order details should allow for a customer with no order, for example with default("…"). See Variables in macros.

• Rules never reply to out-of-office notices, bounces or bulk mail, so two auto-responders cannot answer each other forever.

Follow up when a snooze ends#

There is no event for "snooze ended", but a ticket waking from a snooze counts as an update. To send a follow-up when a customer has gone quiet, use a tag and two rules:

1. Have agents tag the ticket awaiting-reply and snooze it, for example with a macro that does both.

2. Rule one, "Tag: customer replied": on A message is added to a ticket, if Sent by an agent is No and Tags includes any of awaiting-reply, then Remove tags awaiting-reply.

3. Rule two, "Reply: follow up after snooze": on A ticket is updated, if Tags includes any of awaiting-reply, Snoozed until is empty, Status is Open, and Last message from the customer is more than 3 days ago (match your snooze length), then Send a reply with the follow-up and Remove tags awaiting-reply, so it goes out once.

A customer who writes back during the snooze ends it early and loses the tag, so they get no follow-up.