AI prompts for writing support macros that reduce reply volume
A macro that answers only the question asked generates a second ticket. These five prompts write support macros that resolve the issue behind it.
Support macros that answer the literal question and nothing else are a machine for generating second tickets. The customer asks how to change their billing date, gets a correct four-step answer, and writes back forty minutes later asking whether this affects the invoice already issued — which is what they were really worried about.
Good support macros close the issue rather than the message. That means answering the question, the obvious follow-up, and the thing the customer was actually anxious about, in one reply. These five prompts do it: a core macro writer, a variant for outages and bad news, a variant for refusals, a review prompt that predicts follow-ups, and a batch prompt for rebuilding a whole macro library.
Why do support macros generate more tickets?
Because they are written to be correct rather than to be complete. Correctness is measured against the question; completeness is measured against the customer’s situation, and the two come apart constantly.
The second reason is that macros are usually written by whoever knows the product best, and expertise hides the gaps. A step that reads as obvious to the author — “then confirm in settings” — is a dead end for someone who cannot find settings on mobile.
Third, macros tend to be written in a register that discourages replies rather than one that resolves them. A message that ends “let us know if you need anything else” while leaving an obvious question unanswered is inviting the follow-up it should have prevented.
The measurable consequence is replies per resolution — the metric support teams track instead of first-response time for exactly this reason. A macro library optimised for first-reply speed and not for that number will look efficient and cost more.
What should support macros actually contain?
The direct answer first, in one sentence, before any steps. Customers scan for confirmation that you understood; making them read three paragraphs to find out is where frustration starts.
Then the steps, if there are steps, written for the least confident person who will receive this macro and specifying where things are rather than assuming they can be found.
Then the follow-up question, answered before it is asked. Then the boundary — what this does not do, or what will still happen — because unmet assumptions are the largest source of second tickets. And a single specific next step if it did not work, not a generic invitation to reply.
The core prompt for support macros
Click any highlighted blank to fill it in before you copy.
You are writing a support macro. The goal is to close the
issue in one reply, not to answer the message.
Product and context: {{what it does}}
The question as customers actually write it: {{paste three
real examples, unedited}}
The correct answer: {{the resolution}}
Steps, if any: {{numbered, with exact locations of each
control on both web and mobile}}
What the customer is usually actually worried about: {{the
underlying anxiety — billing, data loss, being charged,
losing access, having broken something}}
The most common follow-up question: {{paste}}
What this does NOT do: {{boundaries and side effects}}
When it does not work: {{the usual reason, and the one
specific next step}}
Tone reference: {{paste two approved replies}}
Who receives this: {{customer type, technical level}}The macro rules
Write the macro in this order:
1. THE ANSWER — one sentence, first line, before anything
else. Yes, no, or the direct resolution.
2. THE STEPS — numbered, if there are any. Each step says
where the control is, not just what to click.
3. THE FOLLOW-UP — answer the most common follow-up question
without being asked. Do not phrase it as a question.
4. THE BOUNDARY — what this does not change, or what will
still happen. Especially anything involving money, data or
access.
5. IF IT DOES NOT WORK — one specific action, not a general
invitation.
Rules:
- Maximum 120 words.
- Address the underlying anxiety explicitly in the first two
sentences if it involves money, data or access.
- No apology unless we did something wrong. "Sorry for the
confusion" when the customer was not confused reads as
condescending.
- No "as mentioned", "as per", "kindly", "please be advised",
"unfortunately" unless genuinely delivering bad news.
- Never say "simply", "just" or "all you need to do".
- Steps must work on mobile and desktop, or say which is
which.
- End on the resolution, not on a pleasantry.
Then output:
- The three most likely follow-up questions this macro still
leaves open.
- A one-line version for chat.A worked example
The brief
Question as asked: "how do I change my billing date"
Correct answer: change it in Billing > Payment schedule,
takes effect next cycle
Steps: Account menu (top right avatar) > Billing > Payment
schedule > Change date. On mobile: hamburger > Account >
Billing.
Actually worried about: being charged twice, or being charged
early, this month
Common follow-up: "will I be charged twice this month?"
Does NOT do: does not change the current cycle; the invoice
already issued stands
When it fails: annual plans cannot change date mid-term —
they must wait for renewalThe result
You can change your billing date yourself, and you will not be charged twice for doing it.
1. Click your avatar (top right) → Billing → Payment schedule → Change date. On mobile, that is the menu icon → Account → Billing.
2. Pick the new date and save.
The change takes effect from your next cycle. This month’s invoice has already been issued and is unaffected — you will not see an extra charge.
If you are on an annual plan, the date cannot be changed mid-term; it will move at renewal.
Eighty-one words. The double-charge anxiety is resolved in the first sentence, before the steps, because that is what the customer was writing in to find out. The follow-up is answered without being asked, and the annual-plan exception is stated rather than left to become a second ticket.
The prompt for outages and bad news
Click any highlighted blank to fill it in before you copy.
You are writing a macro for an incident or a genuine failure on
our side. Customers can tell the difference between an
explanation and an excuse.
What happened: {{plainly, without jargon}}
Who is affected: {{scope, precisely}}
What we know and do not know: {{separated}}
Current status: {{fixed / mitigated / ongoing}}
What the customer should do now: {{action or "nothing"}}
Whether data was lost or exposed: {{honest answer}}
Compensation or credit position: {{what is being offered, if
anything, and who qualifies}}
Next update: {{when, specifically}}
Write under 130 words.
Rules:
- Lead with what happened and whether it affects them. Not
with an apology.
- Apologise once, specifically, for the actual impact. Not
"for any inconvenience".
- Separate confirmed facts from what is still being
investigated. Never present a hypothesis as a cause.
- If data was lost or exposed, say so in the first three
sentences. Never bury it.
- Give a specific next-update time, and only one the team
will actually meet.
- Do not thank them for their patience.
- No passive voice for our own actions. "We deployed a change
that caused this", not "an issue was introduced".The prompt for refusals
Saying no badly is the most expensive thing a support team does. A refusal that reads as arbitrary produces escalation, a public review, and often a churn.
Click any highlighted blank to fill it in before you copy.
You are writing a macro that declines a request.
What is being asked for: {{request}}
Why we cannot: {{the real reason — policy, technical
constraint, commercial, legal}}
Is the reason something we could change: {{yes/no, honestly}}
What we CAN do: {{the nearest available alternative}}
Who can escalate this and on what grounds: {{if anyone}}
How often this is asked: {{frequency}}
Write under 110 words.
Rules:
- Say no in the first sentence. Never bury it after a
paragraph of context — customers read that as evasion.
- Give the actual reason. "It is our policy" is not a reason,
it is a restatement.
- Never blame an unnamed system or department.
- Offer the nearest alternative concretely, or say plainly
that there is not one. A vague alternative is worse than
none.
- Do not express regret more than once.
- If escalation is genuinely available, say so and say on
what grounds. If it is not, do not imply it might be.
- Do not invite them to "let us know if you have questions"
after a refusal. It reads as an invitation to argue.The review prompt: predicting the follow-up
Click any highlighted blank to fill it in before you copy.
You are a customer who has just received the support macro
below. You are mildly stressed and not reading carefully.
Output:
1. WHAT I WOULD ASK NEXT — the three questions this reply
leaves open, in order of likelihood.
2. WHERE I WOULD GET STUCK — any step whose location I could
not find, or that assumes a screen I might not see.
3. WHAT I WOULD ASSUME — anything I would incorrectly infer,
particularly about money, data, timing or access.
4. WHERE I WOULD FEEL PATRONISED — any "simply", "just",
"as mentioned", or apology for confusion I did not have.
5. WHAT IS BURIED — anything important below the third
sentence that should be in the first.
6. UNANSWERED ANXIETY — the thing I was actually worried about
when I wrote in, and whether this reply addresses it.
Then rate: would this close the ticket, or generate a reply?
CUSTOMER'S ORIGINAL MESSAGE: {{paste}}
MACRO: {{paste}}Point six is the one that changes macros most. Run it against real inbound messages rather than an idealised version of the question, because the gap between what customers ask and what they want to know is where the follow-ups live.
Rebuilding a macro library
Click any highlighted blank to fill it in before you copy.
You are rewriting {{n}} support macros as a consistent set.
Product: {{context}}
Voice reference: {{paste two approved replies}}
Ticket data: {{table — macro name, current text, monthly use,
replies-per-resolution, common follow-up}}
Known product changes since these were written: {{list}}
For each macro, rewrite it in the established format.
Rules for the batch:
- Prioritise by monthly use multiplied by replies per
resolution. Fix the expensive ones first and say what the
order is.
- Flag any macro describing a flow that has changed:
STALE: {{macro}} — {{what changed}}.
- Flag overlapping macros where an agent would not know which
to pick.
- Identify gaps: any common follow-up question with no macro
of its own.
- Keep terminology identical across the set. List every term
where the current macros disagree with each other.
- Output: macro | new text | word count | predicted
follow-ups | priority.Common mistakes with support macros
Writing from the documented flow rather than the real one. Documentation drifts; the interface changes; a macro citing a menu that was renamed last quarter destroys trust in the first line.
Optimising for length alone. A 40-word macro that omits the boundary is not more efficient than a 100-word one that includes it — it just moves the cost into a second ticket and a longer resolution time.
Leaving the anxiety field blank because it feels unquantifiable. It is the field that determines whether the first sentence lands. “Will I be charged twice” is the whole ticket; the billing-date steps are incidental.
Never re-reading macros against real tickets. A macro library is a snapshot of the product at the moment it was written, and it rots silently.
What to check before support macros go live
Walk every step yourself on both mobile and desktop, in the account type the customer has. Steps written from an admin account are wrong in ways nobody notices until a customer is stuck.
Check that anything touching money, data or access is stated explicitly rather than implied, and that it appears in the first three sentences.
Measure replies per resolution for four weeks after a rewrite, not first-response time. It is the only number that tells you whether the macro closed the issue or just answered the message.
Finally, have someone outside support read the refusal macros. Those are the ones that generate escalations, and the person who wrote the policy is the worst judge of whether the refusal reads as reasonable.
Frequently asked
Questions this article answers
Why do support macros generate more tickets?
Because they are written to be correct rather than to be complete. Correctness is measured against the question; completeness is measured against the customer's situation, and the two come apart constantly. The second reason is that macros are usually written by whoever knows the product best, and expertise hides the gaps. A step that reads as obvious to the author — "then confirm in settings" — is a dead end…
What should support macros actually contain?
The direct answer first, in one sentence, before any steps. Customers scan for confirmation that you understood; making them read three paragraphs to find out is where frustration starts. Then the steps, if there are steps, written for the least confident person who will receive this macro and specifying where things are rather than assuming they can be found. Then the follow-up question, answered before it is asked. Then the…
What to check before support macros go live?
Walk every step yourself on both mobile and desktop, in the account type the customer has. Steps written from an admin account are wrong in ways nobody notices until a customer is stuck. Check that anything touching money, data or access is stated explicitly rather than implied, and that it appears in the first three sentences. Measure replies per resolution for four weeks after a rewrite, not first-response time. It…