Support Macros

Macros let support answer common questions quickly and consistently, but a bad macro makes a team sound robotic and answers questions nobody asked. You build a small library that covers the questions that really recur, written so each one is a strong starting point that still gets a personal touch. The standard: every macro is accurate today, covers the full question, has a named owner and a review date, and is edited before every send.

When to use

• "We keep answering the same questions; write macros."
• "Clean up our saved replies."
• "Create macros for the new pricing."
• "Our replies sound like a robot; fix the templates."
• After a product or policy change that makes existing macros wrong.

What you need

• Ticket data for the last 90 days: subject, tags, first message, resolution, satisfaction score if any. From the helpdesk as a connected app (Intercom, Zendesk, Front) or an export; if support runs from a shared mailbox, export from Gmail or Outlook.
• The existing macro library (an export, or screenshots via the browser).
• Sources of truth: the help centre, policies, and the product itself (to verify steps).
• The owner's voice and sign-off from memory.
• The helpdesk's placeholder syntax. Check its documentation with web_search; every tool differs.

Method

1. Find the top contact reasons. With execute_code:
   • group tickets by tag;
   • where tags are missing or messy, cluster first messages by keywords and read samples to name each cluster;
   • rank by monthly volume. Usually 15 to 25 reasons cover most volume. Start with the top 10, and stop adding when a reason appears fewer than about 5 times a month (the owner can set the cut-off).
2. Read real tickets for each reason, at least 10 per reason:
   • how customers phrase it;
   • what else they ask in the same message;
   • what information agents usually need back;
   • what the best-rated replies said. This is where good macros come from.
3. Audit existing macros. For each one: usage count in 90 days, last edited date, accuracy against the current product and policy, overlap with others. Mark it keep, rewrite, merge or retire. Zero uses in 90 days and not seasonal: retire it (archive; do not delete the history).
4. Write each macro with the template in references/macro-template.md:
   • Name: Category - Topic - Variant (for example Billing - Change card - Logged in), so agents find it by typing.
   • When to use, and when not to: one line each, internal only.
   • Opening: the first-name placeholder with a fallback ("Hi there") in the helpdesk's syntax, then a slot marked [PERSONAL LINE: refer to their specific situation] that must be replaced before sending.
   • Body: the answer, or numbered steps with exact button names, the expected result, and a link to the help article.
   • Next step: what to do if this does not work.
   • Internal actions: tags to add, status to set, any field to update. Keep it short. If the answer needs more than about 150 words, the detail belongs in a help article and the macro links to it.
5. Write variants only when the answer truly differs (plan type, platform, region). Two near-identical macros confuse agents.
6. Verify every step in the product via the browser, and every policy statement against the written policy. Record the date verified.
7. Assign ownership. Each macro gets an owner (the person who knows the topic) and a review date: quarterly by default, and immediately after any change to the product area or policy it describes.
8. Get approval. Macros speak for the company. Put new and rewritten macros on a show_card or in a doc for the owner. Publish into the helpdesk only after approval, through the connected app or the owner's browser.
9. Teach the rule. Brief the support team (brief_team) that macros are starting points:
   • fill the personal line;
   • check every question in the ticket is covered;
   • delete anything that does not apply.
10. Measure and maintain. Monthly, with execute_code:
    • usage per macro;
    • satisfaction and reopen rate on tickets where it was used;
    • whether tickets for that reason are trending up or down. A macro with a high reopen rate is unclear or wrong; rewrite it. A frequent reason with no macro needs one. Use cronjob for the monthly review and for review-date reminders.

Decision rules

Situation	Do
Reason appears 5 or more times a month and the answer is stable	Write a macro
Answer needs more than about 150 words or screenshots	Write a help article; the macro links to it
Answer depends on the customer's account details	Macro with clear slots for the details, plus a check step
Answer involves money, exceptions or promises	No macro; route to the owner
Macro unused for 90 days and not seasonal	Retire (archive)
Reopen rate on a macro clearly above the team's average	Rewrite and re-verify

Output

• The macro library (doc or sheet): name, when to use, body, internal actions, owner, verified date, review date, status (live, draft, retired).
• A change summary: added, rewritten, merged, retired, with reasons.
• A coverage view: top contact reasons and the share of volume covered by a macro.

Checks before you finish

• Every macro was verified against the product and policy, with a date.
• Every macro has a personal-line slot, a fallback for the name placeholder, an owner and a review date.
• Placeholder syntax matches the owner's helpdesk, tested on one test ticket.
• No macro promises refunds, credits, dates or exceptions; those stay with the owner.
• The owner approved the library before it went live.

Pitfalls

• Writing from imagination. Build macros from real tickets and real wording, not from what you think customers ask.
• One macro for everything. A reply that tries to cover five scenarios answers none well.
• No personal line. Customers notice copy-paste. Force a personal touch.
• Stale macros. A macro describing last year's screens is worse than none. Review dates are not optional.
• Macro as policy. A macro cannot create a policy. If the answer needs a decision, the owner makes it first.

See also: support-ticket-reply, help-centre-article, support-inbox-triage.