Intercom lets support teams apply macros while creating tickets

What Intercom changed

Intercom said on September 16 that operators can now apply a macro while creating a ticket instead of creating the ticket, reopening it and applying the macro as a second step. The ticket-creation screen now includes the full composer with Reply and Note panes. A saved macro can insert message content and stage its associated actions before the ticket is submitted.

Intercom's help documentation says the submitted ticket can use the macro message as the first reply while the macro actions run automatically. The documentation also says macros can include common actions such as tagging, assigning, snoozing or closing, and that macro use depends on the relevant workspace permissions. Those are product capabilities described by Intercom; they do not by themselves establish that a particular macro is appropriate for a customer case.

Sources: Intercom changelog, September 16, 2026 · Intercom help: using macros in the Inbox

Ticket creation now carries more execution state

Operationally, the important change is that a new ticket can arrive with customer-facing content and workflow actions already attached. That is faster for repetitive support work, but it also reduces the distance between selecting a customer and changing the operating state of the case. A mistaken customer, outdated macro or overly broad action can now be committed in the same step that creates the record.

Support Ops should therefore document which ticket types are allowed to use macros at creation, which macros are approved for those types and which actions require another check. A macro that only adds an internal note is different from one that assigns ownership, sends a reply and closes the ticket. The review rule should follow the consequence of the actions, not the convenience of the shortcut.

Sources: Intercom macro workflow documentation

Validate customer identity before the macro runs

Intercom notes that macro content is personalized against the customer selected on the ticket. That makes customer selection part of the preflight. A test set should include customers with similar names, merged identities, multiple organizations, restricted records and recently changed ownership. The operator should be able to see enough identifying context to know which customer will receive the message before submission.

If the macro stages assignment or closure, verify that those actions still make sense for the selected ticket type and customer state. A fast path should not erase exceptions such as a high-severity escalation, an account-specific routing rule or a case that must remain open until another team responds. Where the required context is missing, the workflow should fall back to manual creation rather than infer the missing state.

Treat macro edits like workflow releases

Shared macros can affect many operators at once, so changes to message content or actions deserve a small release record. Keep the macro name, owner, intended ticket types, message purpose, action list, last review date and a sample ticket used for validation. If a macro can close or reroute work, include a rollback or disable path and identify who can make that change during an incident.

After editing a macro, test both a normal ticket and an exception case. Confirm the first reply or note is correct, the intended tags and assignment appear, no duplicate action is created and the ticket remains in the expected state. The purpose is not to make every macro bureaucratic; it is to make the shortcuts that change customer or queue state inspectable.

What to measure after rollout

Do not evaluate the feature only by creation speed. Sample tickets created with macros and compare the selected customer, ticket type, first message, assignment, tags and final state with the team's policy. Track corrections and reopened tickets that are directly attributable to the creation workflow, while keeping broader resolution or satisfaction metrics separate unless the causal path is actually known.

A useful first-week review is small: ten to twenty macro-created tickets across common and exceptional cases, one permission check for each operator role and one deliberate macro change followed by rollback. If the resulting records are easy to reconstruct from customer selection through final actions, the workflow is becoming faster without making the support operation less explainable.

Keep the shortcut observable

A macro-created ticket should remain easy to distinguish from a manually composed ticket when the team investigates an exception. Preserve the operator identity, macro name or identifier, ticket type, selected customer, actions that were staged and the resulting assignment or state in a durable record where possible. If a macro changes later, keep enough version context to know which configuration applied to older tickets. That evidence helps a support lead separate a poor macro rule from an individual handling error instead of relying on memory or the final ticket state alone.

The same record can support routine governance. Review the macros that create the most tickets, the ones that perform the most consequential actions and any that frequently require correction after creation. Retire duplicates and outdated shortcuts rather than accumulating near-identical macros. A smaller controlled set makes the creation flow faster to navigate and reduces the chance that an operator chooses a familiar name whose actions no longer match the current support policy.