Customer support macro checklist

01 / BEFORE DRAFTING

Build the source pack before the reply library.

Collect only current, buyer-authorized material that defines what the business actually does. A compact source pack is easier to review than a folder of exports and reduces the chance that an expired rule quietly enters a response.

1. List the recurring question patterns.

   Write one generalized question per row: “Can I change the delivery address after dispatch?” rather than a customer’s message. Merge duplicates, but do not merge questions whose policy answers differ.

2. Assign a source ID.

   Give every accepted policy or fact source a stable ID, effective date, current-status note, and precise locator. A locator can be a page and heading, document section, worksheet and row, or another reference a reviewer can find quickly.

3. Separate policy from preference.

   Policy governs what the business may promise. Tone, greeting, sign-off, reading level, and preferred phrases govern how the approved answer sounds. Keep these in separate fields.

4. Name owner roles.

   Escalation should go to a role—such as shipping lead or account owner—not a named person. Define what triggers the handoff and what minimized information the agent may pass along.

02 / MACRO ANATOMY

Give every macro a source, a trigger, and a stop sign.

A response-only document is hard to audit. Use the following fields even if the final system hides some of them from the agent interface.

Macro ID

A stable internal reference such as MAC-001. Do not use a customer, ticket, or order identifier.

Internal title

A plain description of the situation, such as “delivery window — clarification needed.”

Use when

The anonymous question pattern and conditions that make the reply appropriate.

Customer-facing response

The ready-to-paste text, using only current policy and product or service facts.

Approved placeholders

Only the fields an agent must replace, written visibly as tokens such as {{order_date}}.

Source map

The policy ID and precise section, heading, page, or row supporting each factual clause.

Issue tags

A short, understandable set of operational labels—not a substitute for reading the question.

Escalation rule

The trigger, owner role, handoff text, and information that may safely accompany the handoff.

Do not use when

The edge cases that require clarification, escalation, or a different approved response.

INTERNAL TITLE:
USE WHEN:

READY-TO-PASTE RESPONSE:
[Acknowledgement grounded in the question]
[Approved policy answer]
[One clear next step]

APPROVED PLACEHOLDERS:
SOURCE MAP:
ISSUE TAGS:
ESCALATE WHEN / OWNER ROLE:
DO NOT USE WHEN:

Keep placeholders conspicuous. A token such as {{approved_date}} is safer than a subtle blank because the unfinished state is visible. Never use a placeholder to invite sensitive data into an ordinary reply.

03 / DRAFTING WORKFLOW

Draft from the cited clause outward.

1. 1
   Read the exact policy passage.

   Do not draft from memory, a ticket summary, or an older macro.

2. 2
   Write the narrow answer first.

   State only what the accepted source supports. Preserve conditions, exceptions, dates, geography, channel, and eligibility boundaries.

3. 3
   Add a neutral acknowledgement.

   Recognize the question without admitting fault, promising an outcome, or claiming an emotion you cannot know.

4. 4
   Add one next step.

   Use an approved route and request only information needed by the policy. Avoid unnecessary identity or order details.

5. 5
   Define misuse conditions.

   Name the cases where the answer is unsafe: conflicting dates, high-value exceptions, threats, legal demands, payment disputes, safety reports, or any regulated judgment.

6. 6
   Read it as the recipient.

   Remove internal jargon, defensive phrasing, blame, fake warmth, pressure, and vague “soon” language not defined by policy.

04 / DECISION RULE

Use, clarify, or escalate—never quietly improvise.

05 / BLOCKING QA

Do not release a macro that fails any of these checks.

• Every factual clause maps to a current accepted source and precise locator.
• The response does not broaden a refund, warranty, shipping, return, cancellation, timing, eligibility, or service promise.
• The trigger and “do not use” conditions cannot both be true.
• Every placeholder is approved, visible, necessary, and described.
• No live case, customer identity, private message, order data, payment data, credential, health data, or other sensitive information appears.
• The response names one understandable next step and does not hide a material term.
• Tags describe the issue plainly; escalation names a role, trigger, and safe handoff.
• A human reviewer has compared the final text—not only the outline—to the cited source.

When the library changes, record the macro ID, source version, change reason, reviewer, and date. Retire the old version rather than leaving two “current” answers available.

06 / LIMITS

What this first pass does not establish.

This guide does not draft policy, verify facts outside the sources you provide, provide legal or compliance review, configure a helpdesk, train a chatbot, automate replies, handle live cases, or determine what a business should promise. It does not guarantee faster replies, fewer escalations, customer satisfaction, retention, refunds, sales, revenue, or any other operational or customer outcome.

Before using any macro, the business remains responsible for the policy, the factual accuracy of the reply, the handling of personal data, the agent’s judgment, and the destination platform’s current requirements.