Macro & saved-reply starter set

What this is

Twelve saved replies covering the situations that come up in almost every support queue. They're starting points, not finished copy. The goal is to save your team the keystrokes on the boring 40% of a message so they can spend their attention on the part that's actually specific to the customer.

Two rules before you paste anything in:

1. A macro is a skeleton, not the whole reply. Every one below has a [placeholder] where a human has to add the specific detail — the actual answer, the real timeline, the thing the customer asked. If a macro can be sent with zero edits, it's usually too generic to be worth sending.
2. Read it out loud. If it sounds like a form letter when you say it, the customer will read it that way too. Cut the corporate throat-clearing ("We sincerely apologize for any inconvenience this may have caused") and say the real thing.

How placeholders work

---

The 12 replies

1. Greeting / first response

Use when you pick up a ticket and need a beat before the full answer, or to acknowledge you're on it.

Hi [first_name], thanks for reaching out — I've got your message and I'm looking into it now.

[specific_detail: one line naming what they asked about, so they know you actually read it.]

I'll follow up [timeframe]. If anything changes on your end in the meantime, just reply here.

— [agent_name]

Note: Naming their actual issue in line two is what stops this from feeling like an auto-reply. Skip it and you might as well not send it.

2. Acknowledgement of a frustrated customer

Use when someone's clearly annoyed and you need to lower the temperature before solving anything.

Hi [first_name], I hear you — [specific_detail: name the frustration in plain terms, e.g. "having this fail right before your billing run is the worst possible timing"]. That's a fair thing to be annoyed about.

Here's what I'm going to do: [specific_detail: the concrete next step]. I'll have an update for you [timeframe].

Note: No "we apologize for the inconvenience." Name the specific problem instead — it proves you understood it. Then move straight to action.

3. Need more info

Use when you genuinely can't proceed without something from them.

Hi [first_name], happy to dig into this. To get you the right answer the first time, could you send me:

• [detail_1, e.g. the account email or order number]
• [detail_2, e.g. a screenshot of the error, or what you clicked right before it]
• [detail_3, e.g. roughly when it started]

Once I have those I can [specific_detail: what you'll be able to do]. Thanks for bearing with me.

Note: Explain why you need each thing ("to get you the right answer the first time"). People give better info when the ask doesn't feel like a runaround. Never ask for something you can look up yourself.

4. Known issue — fix in progress

Use when they've hit a bug your team already knows about and is working on.

Hi [first_name], thanks for flagging this — and good news, it's not just you. We've confirmed [specific_detail: what's broken] and our team is on it.

Where things stand: [specific_detail: current status — investigating / fix identified / rolling out]. Expected fix: [timeframe, or "we don't have a firm ETA yet, but I'll update you the moment I do"]. In the meantime: [specific_detail: workaround, or "there's no workaround yet — you don't need to do anything, we'll come to you"].

I've added you to the list to be notified when it's resolved.

Note: "It's not just you" is reassuring and honest. Only promise a notification if your tooling actually lets you follow through — a broken promise here is worse than no promise.

5. Known issue — won't-fix / expected behaviour

Use when the thing they hit is working as designed, even if that's not what they hoped.

Hi [first_name], I looked into this and it's actually working the way it's meant to — [specific_detail: plain explanation of why it behaves this way]. I know that may not be the answer you were after.

If it's getting in your way, here's the closest workaround: [specific_detail, or "here's how to get the outcome you're after a different way"].

I've also passed your use case to our product team as feedback — that's genuinely how these things change.

Note: Don't pretend a limitation is a feature. Acknowledge the gap, give them the best available path, and only mention product feedback if you'll actually log it.

6. Refund / return

Use when you're approving a refund or return.

Hi [first_name], done — I've [specific_detail: refunded $X to your original payment method / started the return for order #].

What to expect: the amount should land back with you in [timeframe, e.g. 5–10 business days depending on your bank]. [specific_detail: any return-shipping step, e.g. "a prepaid label is attached — drop it at any [carrier] location."]

You'll get a separate confirmation email once it's processed. Anything else I can sort out while I'm here?

Note: Always give the realistic refund window (name the bank-side delay so you're not blamed for it), and confirm the exact amount and destination. Vague refund replies generate a second "where's my money" ticket every time.

7. Refund / return — declined

Use when you can't approve the request. Hardest reply to keep human; worth the care.

Hi [first_name], I looked into this carefully, and I'm not able to [specific_detail: refund / accept the return] in this case — [specific_detail: the actual reason, stated plainly, e.g. "it's outside our 30-day return window, which closed on [date]"].

I know that's not what you were hoping to hear. What I can do is [specific_detail: the real alternative — store credit, a repair, a partial, or an exception you're allowed to make]. Would that work for you?

Note: Give the reason once, clearly, without hiding behind "policy." Then offer a real alternative if you have one. If you don't, say so honestly rather than dressing up a no.

8. Escalation handoff — telling the customer

Use when you're passing the ticket to another team or a specialist.

Hi [first_name], I want to get you the best answer on this, so I'm looping in [specific_detail: team/person, e.g. "our billing specialists"] who handle [specific_detail: this area] directly.

I've passed them the full history so you won't have to repeat yourself. You'll hear from [specific_detail: name, or "someone on that team"] by [timeframe]. I'll keep an eye on it from my side too.

Note: "You won't have to repeat yourself" only works if it's true — see the internal handoff note below. Repeating themselves is the number-one thing customers hate about escalations.

9. Escalation handoff — internal note to the next rep

Use as an internal comment when you hand a ticket off. This one is for your teammate, not the customer.

Handoff — [date] Customer wants: [specific_detail: the actual goal, in one line] What I've tried: [specific_detail: steps taken + result] Blocked on: [specific_detail: why I'm passing it — permissions, expertise, access] Watch out for: [specific_detail: e.g. "customer is frustrated after two prior tickets" or "already promised a callback by Fri"] Account / order: [specific_detail]

Note: A good internal handoff is the difference between a smooth escalation and a customer starting from zero. Fill in every line — "see above" is not a handoff.

10. Proactive follow-up ("are you still stuck?")

Use when you fixed something and want to confirm it stuck, or you're waiting on the customer.

Hi [first_name], circling back on [specific_detail: the issue]. [specific_detail: "Did the fix I sent do the trick?" / "Just checking whether you had a chance to try the steps above."]

No rush — reply whenever you get a minute and I'll pick it right back up. If it's all sorted, even a quick "all good" lets me close this out for you.

Note: Follow-ups should feel like a helpful nudge, not a collections notice. "No rush" and giving them an easy out ("all good") gets you far more replies than a formal check-in.

11. Follow-up before auto-close

Use as the last touch before a ticket auto-closes for inactivity.

Hi [first_name], I haven't heard back on [specific_detail], so I'm going to close this out for now to keep your queue tidy — but nothing's really closed. Just reply any time (even weeks from now) and it reopens right where we left off.

Hope [specific_detail: the thing] is working for you.

Note: Make reopening feel effortless and pressure-free. The point is to close inactive tickets without making the customer feel abandoned or rushed.

12. Closing / resolution

Use when the issue is genuinely resolved.

Hi [first_name], glad we got that sorted — [specific_detail: one-line recap of what was fixed, so it's on the record].

If it acts up again or anything new comes up, just reply here and it'll come straight back to me [or "the team"]. Thanks for your patience while we worked through it.

— [agent_name]

Note: The one-line recap matters: it gives the customer (and the next rep) a clear record of what happened. Avoid "Is there anything else?" as a closer if you've already solved it — it can sound like you're rushing them off.

---

Keeping macros from rotting

Macros decay quietly. A link 404s, a policy changes, a product feature gets renamed — and reps keep sending the stale version for months because nothing errors out. Stale macros are worse than no macro: they teach customers your team isn't paying attention. Treat the library like code that needs maintenance.

The rules that keep a library healthy

• Every macro has an owner. One named person is responsible for each one being correct. Un-owned macros are how rot starts.
• Every macro has a last-reviewed date. Put it in the macro title or an internal tag. If you can't see when it was last checked, you can't trust it.
• Retire aggressively. A library of 25 macros people actually use beats 120 nobody can find. If a macro hasn't been used in 90 days, it's a candidate for deletion.
• Name them so people find them. refund-approved-standard beats Macro 14. Reps who can't find the right macro will either write from scratch (slow) or grab the wrong one (worse).
• Never bury a link inside a macro without tracking it. When a URL changes, you need to know every macro that pointed at it.

Quarterly macro review checklist

Run this once a quarter (block 60 minutes; it's faster than it looks):

• Every link opens and lands on the right, current page — no 404s, no redirects to renamed features
• Every price, timeframe, and policy detail still matches reality
• Product/feature names match what's in the app today
• Nothing references a person who's left, a team that's been renamed, or a tool you no longer use
• Pull the usage report: flag anything unused in 90 days for retirement
• Pull the usage report: flag any macro used far more than the rest — is it too generic? Should it be split?
• Read the top 10 most-used macros out loud — do they still sound human, or has the tone drifted robotic?
• Check for near-duplicates and merge them (three slightly different "refund" macros confuse everyone)
• Confirm each active macro still has an owner and an up-to-date last-reviewed date
• Ask two frontline reps: "Which macro do you hate using, and why?" — then fix or kill it

Signals a macro needs attention right now (don't wait for the quarter)

• Reps are editing the same macro heavily every time they use it → it's wrong or too generic; fix the base copy
• Reps are copy-pasting from a personal doc instead of the shared library → the library is missing something they need
• A customer quotes your macro back to you to point out it's outdated → drop everything and fix it
• A link inside a macro changed → search the whole library for that URL the same day