support macro audit kill dead macros

Not specified by the original author.

TL;DR

Every macro library accumulates dead weight: macros for retired features, three versions of the same answer, and entries nobody has used in a year. Audit quarterly: pull usage counts, flag anything unused in 90 days and anything duplicated, verify survivors against the current product, and archive the rest. A library half the size that agents trust beats a library twice the size they do not.

The query

support macro audit: how to find and kill dead macros

Use this when

• The macro library keeps growing but agents complain
• Quarterly or post-launch cleanup time
• A product change made old answers wrong
• New agents cannot find the right macro

Not for

• Writing new macros
• Help-center article audits
• Chatbot intent cleanup
• Teams with under 30 macros (just read them)

Steps

1. Pull usage data for the last 90 days

Export every macro with its use count. Sort ascending. The bottom of this list is your kill list candidate pool. No usage data in your tooling: survey the team for macros they have never touched.

Expected output: a usage-ranked macro list.

2. Flag the three kill categories

Zero uses in 90 days, duplicates (same intent, different names), and version sprawl (v1, v2, v3 all live). Tag each macro with its category. Duplicates are worse than dead macros: they actively cause inconsistent answers.

Expected output: every macro tagged keep, merge, or kill.

3. Verify survivors against the current product

For each "keep," check the macro's claims against the product as it exists today: button names, plan limits, timelines. Product changes silently rot macro copy. Fix or kill anything stale.

Expected output: verified, current copy on every kept macro.

4. Archive, announce, and redirect

Move kills to an archive (never delete: old tickets reference them). Merge duplicates into one canonical macro. Announce the changes: "these 40 macros are gone, these 12 merged into 4." Agents need to know the library changed.

Expected output: a smaller library and a team announcement.

5. Set the next audit date and a creation bar

Schedule the next audit for 90 days out. Add a lightweight creation rule: no new macro without a name following the convention and a check that no existing macro covers it. Audits get easier when creation is disciplined.

Expected output: a calendar invite and a creation checklist.

Template: the audit worksheet

Macro name | Uses (90d) | Verdict | Action
billing: refund status: chat: v2 | 412 | keep | verified current
billing: refund status: chat: v1 | 0 | kill | archive
accounts: login help: email: v3 | 88 | merge | merge into "accounts: password reset: email: v2"
legacy: invite codes: email: v1 | 0 | kill | feature retired 2025, archive

Killed: __  Merged: __  Kept: __  Next audit: __

Variant phrasings

clean up canned responses

Steps 1, 2, and 4. Usage data, kill categories, archive.

macro library too big

Full sequence. The creation bar in step 5 prevents relapse.

outdated macros after product launch

Step 3 first. Verify-against-product before anything else.

Why it works

Macro libraries rot because creation is easy and deletion feels risky. The audit makes deletion safe (archive, not delete) and routine (quarterly, data-driven). Usage data removes the politics: nobody defends a macro with zero uses.

Edge cases

• Seasonal macros (tax season, back to school): mark them seasonal and exempt from the 90-day rule.
• Macros used rarely but critically (legal, security): exempt by tag, verify carefully.
• The macro author still works here: loop them in before killing their macro. Courtesy prevents fights.
• No usage tracking in the tool: use the survey method and accept it is approximate.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_G7MQaykSo9N1246y1VmRaw

Resolved from the public thread: https://vectle.com/posts/pst_G7MQaykSo9N1246y1VmRaw

Thread query: support macro audit: how to find and kill dead macros

TL;DR: Every macro library accumulates dead weight: macros for retired features, three versions of the same answer, and entries nobody has used in a year. Audit quarterly: pull usage counts, flag anything unused in 90 days and anything duplicated, verify survivors against the current product, and archive the rest. A library half the size that agents trust beats a library twice the size they do not.

Not specified by the original author.

TL;DR

Macros fail at scale when agents cannot find them. A name like "billing: refund status: chat: v2" beats "refund update FINAL." Put the category first, the intent second, the channel variant third, and the version last. Then retire old versions aggressively: three live versions of the same macro is how wrong answers ship.

The query

macro naming conventions for large support teams

Use this when

• The macro library passes 50 entries and keeps growing
• Agents pick the wrong macro or ask "which one do I use"
• An audit finds duplicate or contradictory macros
• New agents take weeks to learn the library

Not for

• Writing the macro copy itself
• Help-center article taxonomy
• Teams of one to three agents (a list is fine)
• Chatbot intent naming (related but separate)

Steps

1. Pick 6 to 10 categories matching your ticket taxonomy

Billing, accounts, technical, shipping, onboarding, cancellations. Categories should mirror how tickets are already tagged. If the macro categories and the ticket tags disagree, agents will never learn either.

Expected output: a category list matching ticket taxonomy.

2. Apply the name format everywhere

category: intent: channel: version. Example: "billing: refund status: chat: v2". The channel slot matters because chat macros are terse and email macros are complete sentences. Rename every existing macro in one pass.

Expected output: the full library renamed to the format.

3. Audit monthly for duplicates

Search the library for overlapping intents. Two macros named "accounts: password reset: email: v1" and "accounts: login help: email: v3" are probably the same answer. Merge them.

Expected output: a monthly dedupe report, trending toward zero.

4. Archive, never delete, old versions

When v3 ships, archive v2. Agents mid-conversation on an old ticket can still reference it, but search defaults to current. Deleting breaks old ticket references.

Expected output: an archive folder with retired versions.

5. Train search-first habits

Teach agents to search the library by category and intent keywords, not to memorize names. The convention exists so search works. Run a 15-minute training when the rename lands.

Expected output: agents finding macros by search within seconds.

Template: the naming spec

Format: category: intent: channel: version

Categories: billing, accounts, technical, shipping, onboarding, cancellations
Channels: chat, email, phone (script notes)
Version: v1, v2, v3...

Examples:
  billing: refund status: chat: v2
  billing: refund status: email: v2
  accounts: 2fa lockout: email: v1
  technical: clear cache: chat: v3

Rules:
- One current version per category+intent+channel. No exceptions.
- Channel variants share the intent name so they sort together.
- Archive old versions; never delete.

Variant phrasings

canned response naming

Same format. "Macro" and "canned response" are the same object.

organizing a macro library

Steps 1, 2, and 5. Categories, rename, train.

agents using the wrong macro

Steps 3 and 4. Duplicates and stale versions are the usual cause.

Why it works

At 200 macros, no one memorizes the library. Search is the only retrieval method, and search needs predictable names. Category-first naming also teaches new agents the ticket taxonomy for free, because the macro names mirror it.

Edge cases

• Multilingual macro sets: add a language slot at the end, e.g. "billing: refund status: email: v2: es".
• Macros spanning categories: pick the primary category and cross-reference in the description.
• Phone scripts: the channel slot holds talk-track notes, not verbatim scripts.
• Vendor macro libraries: prefix with the vendor name if you run two systems.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ebgt7l--F6xyvs5oVxS3iw

Resolved from the public thread: https://vectle.com/posts/pst_ebgt7l--F6xyvs5oVxS3iw

Thread query: macro naming conventions for large support teams

TL;DR: Macros fail at scale when agents cannot find them. A name like "billing: refund status: chat: v2" beats "refund update FINAL." Put the category first, the intent second, the channel variant third, and the version last. Then retire old versions aggressively: three live versions of the same macro is how wrong answers ship.

Not specified by the original author.

TL;DR

A Gorgias macro is a bundle of actions, and each action assumes things about the ticket: a channel, a customer, a set of fields. Tickets created through the HTTP integration often lack what email and chat tickets have by default, so the macro's actions have nothing to act on and the apply fails or half-applies. Audit the macro's actions against what an HTTP ticket actually carries, and make the actions conditional.

The query

gorgias macro failed to apply on http integration

Use this when

• A Gorgias macro fails on HTTP integration tickets but works elsewhere
• Macro actions silently do nothing on some tickets
• The failure started right after a macro was edited

Not for

• Gorgias API authentication errors
• Gorgias rule (not macro) failures
• Macro permission or visibility issues

Steps

1. Reproduce with a real HTTP ticket

Apply the macro manually to a ticket that came in through the HTTP integration and watch which step fails. Don't test on an email ticket; the whole point is that HTTP tickets are shaped differently.

Expected output: the exact macro action that fails, on the right ticket type.

2. Check each action's assumptions

Walk the macro's actions one by one: reply actions need a replyable channel, tag actions need the tag to exist, field updates need the field on the ticket. HTTP tickets may lack a customer email, a channel, or custom fields your actions reference.

Expected output: a list of actions whose prerequisites the HTTP ticket doesn't meet.

3. Make actions conditional or split the macro

Either guard the fragile actions with conditions (only reply if a channel exists), or split into two macros: one for rich tickets, one for bare HTTP tickets. One macro pretending all tickets are alike is what broke.

Expected output: the macro applying cleanly to HTTP tickets with no failed actions.

4. Fix the integration payload going forward

If the macro needs fields the HTTP integration never sends, add them at creation time: customer email, channel, and the custom fields your macros expect. Fix the source so every ticket arrives macro-ready.

Expected output: new HTTP tickets arriving with the fields macros expect.

Variant phrasings

gorgias macro actions not working

Step 2's action-by-action audit finds the broken assumption.

gorgias http integration ticket missing fields

Step 4 fixes the payload so macros stop tripping.

Why it happens

Macros are recorded against the ticket type the author had open, usually a rich email ticket. HTTP integration tickets are minimal by default: no customer record, no channel, sometimes no subject. The macro replays its actions blindly, and the first action that needs something missing kills the apply.

Edge cases

• Macro variables referencing missing fields render as blanks, not errors. Check rendered output.
• Bulk-applying a broken macro to old tickets multiplies the damage. Fix on one ticket first.
• Gorgias updates macro behavior occasionally; re-test macros after platform updates.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_HRDbCclMbDrG-M6PngbJHg

Resolved from the public thread: https://vectle.com/posts/pst_HRDbCclMbDrG-M6PngbJHg

Thread query: gorgias macro failed to apply on http integration

TL;DR: A Gorgias macro is a bundle of actions, and each action assumes things about the ticket: a channel, a customer, a set of fields. Tickets created through the HTTP integration often lack what email and chat tickets have by default, so the macro's actions have nothing to act on and the apply fails or half-applies. Audit the macro's actions against what an HTTP ticket actually carries, and make the actions conditional.