Use when receipts, resets and notifications were written by developers and nobody has read them since.
transactional-copy-tune-up.md
You are a customer communications editor reviewing transactional mail. You are not adding marketing to it.
The messages, each with its trigger, subject and full body: {{TRANSACTIONAL_MESSAGES}}
Product, and what the customer has just done: {{PRODUCT_CONTEXT}}
Support route and hours: {{SUPPORT_ROUTE_AND_HOURS}}
Rules or legal constraints on promotional content in these sends: {{PROMOTIONAL_POLICY}}
Output a table, one row per message: Message | Trigger | What the reader needs from the preview pane | Rewritten subject | Rewritten body | Facts or fields still missing | Support line drawn from {{SUPPORT_ROUTE_AND_HOURS}}.
Then a section headed "Questions this message still generates", giving for each message the support ticket it invites and the one sentence that would prevent it.
Rules:
- The first line says what happened and whether the reader must act. Everything else comes after.
- Keep every reference, amount, date and identifier present in {{TRANSACTIONAL_MESSAGES}}. If one is absent, name the field rather than writing around the gap.
- Add promotional content only where {{PROMOTIONAL_POLICY}} allows it, and name the messages that should carry none at all.
- Do not describe system behaviour that is not evidenced in {{TRANSACTIONAL_MESSAGES}} or {{PRODUCT_CONTEXT}}.
- No em dashes, no apology padding, no closing summary line.
Replace each placeholder with your own detail. The more specific you are, the less the model invents.
When should I touch messages that are already working?
When receipts, resets and notifications generate support tickets, or when nobody has read them since a developer wrote them. These are opened more than anything else you send, so a bad line here costs more than a bad campaign. The usual trigger is a repeated question support can name.
What do I need to collect before the rewrite?
Each message with its trigger, subject and full body, what the customer has just done, your support route and hours, and any rules on promotional content in these sends. Trigger the real messages to yourself rather than pasting templates, because merge fields fail in ways the template never shows.
What does the tune-up return per message?
What the reader needs from the preview pane, a rewritten subject and body, the facts or fields still missing, and a support line, then a section naming the ticket each message invites and the one sentence that would prevent it. That section is what reduces support volume.
What turns a transactional email into a compliance problem?
Adding an offer. In several jurisdictions promotional content can reclassify the send as marketing, bringing consent and unsubscribe obligations with it, and the boundary is not always clear. Check before softening that line, and let the output name the messages that should carry none at all.