Macro

The support tickets arriving at a help desk come in fewer varieties than anyone expects. Send me the receipt again, I can't change my password, I want to invite more teammates — a handful of questions like these account for most of the volume. Yet the answers were written fresh every time. An agent who got the same question twelve times in a day typed the same sentences twelve times, and wrote them a little differently each time.

Two things broke as a result. One is speed: when a three-minute answer takes eight minutes to write, the number of tickets one person closes in a day drops by nearly half. The other is consistency. If one agent answers a refund question with "three business days" and another says "about a week," a customer who sees both answers stops believing either.

Pagedeck held this together with personal notes for a while. Each agent kept their own collection of frequently used sentences in a scratch file and pasted from it. During a week when Sofia was on vacation, whoever covered for her had no access to her notes, rewrote the refund explanation from scratch, and sent out a different deadline than the one customers had been given before. A macro is the mechanism that moves those sentences out of one person's file and into the team's.

A knowledge base — the collection of articles customers search on their own — solves the same repetition from the other end. It works before a ticket is ever filed, while a macro attaches to a ticket that already arrived, so the two sit in sequence rather than replacing each other.

A macro is not just a block of text. Registering one in a support tool means filling in five things.

1. Name and category — what the agent searches for in the reply window. Label it "refund1" and nobody but the author will ever find it, so the name should describe the situation: "Billing / refund timeline after cancellation."
2. Subject — the subject line used when the reply goes out as email. Teams that only handle live chat leave it empty.
3. Body — the sentences that actually get sent. Structured as greeting, answer, next step, and closing, the template leaves the agent editing only the middle.
4. Placeholders — fields filled in automatically the moment the macro loads: customer name, ticket number, plan name. Writing "Hi there" instead is easier, but the difference a customer feels between a reply with their name in it and one without is larger than it looks.
5. Attached actions — beyond inserting text, a macro can set the ticket to pending, apply a category tag, or reassign it to second-line support. This is where the data for counting how many tickets of each kind arrived quietly accumulates.

Length is the recurring problem in the body. Cram every case into one macro and the customer reads paragraphs that don't apply to them. If monthly and annual plans calculate refunds differently, split it into two macros instead of covering both. The five seconds an agent spends choosing costs less than the minute a customer spends reading.

Macros get drafted by the agent who has handled the most tickets. At Pagedeck that's Sofia. She doesn't invent new sentences — she pulls replies that customers accepted without a follow-up question and cleans them up, because a sentence that already worked is the best possible draft. Anything with consequences if it's wrong, like a refund deadline or a reading of the terms of service, gets a check from Grace before it goes into the library.

Three groups read them.

1. Support agents pull them into replies. What they need is less a beautifully written sentence than a findable name and a structure that makes the edit points obvious at a glance.
2. New agents use the macro list as training material. It lays out, in sentences, which questions this company receives and what tone each one gets, so reading through the library in week one maps the shape of the job.
3. Customers are the final readers. They don't know the reply came from a template. A macro that opens with "Thank you for reaching out" and ends without telling anyone anything is worse than no macro at all — what the reader does next has to be somewhere in the text.

"Let's make this a macro. Thirty tickets asked it this week alone."

The repetition is confirmed, so the answer should become a template.

"That macro has the old policy in it. The refund deadline change never got applied."

A saved reply is going out contradicting what the company actually does now.

"Insert the macro, then rewrite the second paragraph for this customer's situation."

Don't send the template as-is — reflect the individual case.

When Pagedeck opened its enterprise plan and ticket volume doubled in a month, the first thing Sofia did was build a macro library. Sorting three months of tickets showed that the top eight questions covered 60 percent of the volume, so those eight came first. The next month's first response time — the gap between a ticket arriving and a human answering it — fell from four hours on average to ninety minutes.

She also put a quarterly review of the library on the calendar. When the product changes, the explanations go stale with it, and because nobody reopens a macro once it's registered, a wrong one can keep going out for six months. In the month a screen got renamed, Sofia searched the library for the old word and corrected every match at once.

The most common worry is that using a macro looks lazy. The sense that a sentence written by hand carries more care is a natural one. But what a customer registers as care is whether the answer fits their situation, not whether it was typed fresh. Writing from scratch every time actually causes items to be dropped under pressure, and a well-built template with one paragraph adapted reads as more helpful. The failure isn't using a template — it's sending one without editing the parts that needed editing.

Assuming more macros are better is the other frequent mistake. Building one for every kind of question looks like full coverage. But in a library of 200, agents can't find what they want and end up writing by hand anyway. Worse, the least-used macros are the most out of date, so on the rare occasion one gets pulled it carries wrong information outward. Twenty macros covering half of all tickets beat a hundred scattered ones, and any macro that hasn't been used in three months should be deleted.