Macros that listen.

Bad macros are usually a search problem wearing a writing problem's clothes. When your library is one long alphabetical list, agents can't find the right reply under pressure — so each macro grows to cover more cases, because a macro that covers everything is easier to find than five that each cover one thing. Length is a symptom of bad retrieval.

The other failure is staleness. Macros get written once, during onboarding or a busy week, and never revisited. Six months later the refund window in the macro doesn't match the refund window in the product, and the canned reply is now confidently wrong.

There's a third, quieter failure: macros written in a voice nobody on the team actually has. Support prose drifts formal under pressure — "we apologize for any inconvenience this may have caused" — because formality feels safe to commit to a library. But customers hear the gear change mid-conversation, the moment a warm human reply turns into legal weather. A macro should sound like your team on a good day, not like your team's lawyer.

InboxBarn takes a position here: macros are classified by the same routing categories as conversations — general, VIP, billing, sales. When you open a billing thread, the inbox suggests the billing macros. Not the whole library; the four or five replies that plausibly belong in this conversation.

That single design choice unwinds the length spiral. Because retrieval is contextual, each macro can afford to be small and specific. You stop writing the omnibus "Billing FAQ" macro and start writing "refund issued — what happens next" and "card declined — how to retry," trusting the right one to surface on the right thread. The macro listens to the conversation's category before it ever reaches the agent's hands.

A macro should be a head start on a sentence you were already going to write.

The strongest pattern we know: a macro should carry the part of the reply that's genuinely the same every time — the facts, the steps, the policy — and nothing else. Leave the first sentence and the last sentence to the human. The greeting is where you prove you read their message; the close is where you sound like yourself.

• Carry facts, not feelings. "Refunds land in 5–10 business days, and the seat stays active until the period ends" belongs in a macro. "We totally understand your frustration!" never does.
• One macro, one job. If you're tempted to add "and if instead you meant X…", that's a second macro.
• Name them like answers, not like topics. "refund timeline" beats "Billing #3" when an agent is scanning suggestions mid-reply.
• Date-stamp anything that can rot. Pricing, limits, version numbers — if the product can change it, schedule a recheck.

Here's the shape in practice. The wall version: "Thank you for contacting support! We understand billing issues can be frustrating. Our refund policy allows refunds within 30 days of purchase. Refunds are processed within 5–10 business days. If you have any other questions, don't hesitate to reach out!" The middle version: "Refund's issued — it'll land in 5–10 business days, and your seats stay active until the period ends." The first answers a category of person. The second answers a person, in one breath, with the macro doing only the factual lifting.

One more constraint, peculiar to multi-channel support: the same macro will be delivered as an email one day and a Discord message the next, because replies always land on the customer's original channel. A macro that depends on email furniture — "see the attached PDF," "as per my previous email" — reads absurd in a chat widget.

So write channel-neutral middles: short paragraphs, plain links, no formatting that only one platform understands. The pleasant side effect is that channel-neutral prose is just better prose — it's what writing sounds like when it can't lean on letterhead.

For the same reason, keep sign-offs out of macro bodies. The signature belongs to the person and the channel, not to the canned middle — bake one into the macro and every email goes out wearing two name tags, while every chat reply drags formal furniture into an informal room.

Aim for a library you can read end-to-end in ten minutes — fifteen to twenty-five macros for most small teams. Growth should be evidence-based: when you notice yourself typing the same middle for the third time in a week, that's a macro asking to exist. Deletion should be just as routine; a weekly triage pass is a fine place to prune the ones nobody used.

Ownership helps here. Let anyone propose a macro, but give the library a gardener — one person who merges duplicates, retires the stale, and keeps the names answer-shaped. It's a twenty-minute job per month at this size, and it's the difference between a toolkit and a junk drawer.

The test for the whole system is simple. If a customer could read your macro library and feel respected by it — accurate, specific, unpadded — you've built macros that listen. If they'd feel processed, keep cutting.