sales-transactional-email

What this skill does

# Transactional Email Delivery

Help the user with transactional/triggered email — from provider selection and template design through API integration, SMTP relay, deliverability, and monitoring. This skill is tool-agnostic but includes platform-specific guidance for SendGrid, Postmark, Mailgun, Brevo, Customer.io, Mailchimp/Mandrill, and Amazon SES.

## Step 1 — Gather context


If `references/learnings.md` exists, read it first for accumulated knowledge.

Ask the user:

1. **What type of transactional email do you need help with?**
   - A) Order confirmations / receipts / shipping notifications
   - B) Password resets / account verification / 2FA
   - C) Welcome emails / onboarding sequences triggered by signup
   - D) Billing / invoice / subscription notifications
   - E) Alert / notification emails (activity, mentions, reminders)
   - F) Provider selection — choosing the right transactional email service
   - G) Delivery issues — emails not arriving, going to spam, delayed
   - H) API/SMTP integration — connecting your app to a provider
   - I) Template design — building reusable transactional templates
   - J) Monitoring & analytics — tracking delivery, opens, bounces
   - K) Something else — describe it

2. **What's your current setup?**
   - A) No provider yet — starting from scratch
   - B) Using SendGrid
   - C) Using Postmark
   - D) Using Mailgun
   - E) Using Brevo (Sendinblue)
   - F) Using Customer.io
   - G) Using Mailchimp / Mandrill
   - H) Using Amazon SES
   - I) Using another provider
   - J) Using my own SMTP server

3. **What's your volume?**
   - A) Low (< 1K emails/day)
   - B) Medium (1K-50K/day)
   - C) High (50K-500K/day)
   - D) Very high (500K+/day)

**If the user's request already provides most of this context, skip directly to the relevant step.** Lead with your best-effort answer using reasonable assumptions (stated explicitly), then ask only the most critical 1-2 clarifying questions at the end.

## Step 2 — Strategy and approach

### Transactional vs marketing email

**Transactional emails** are triggered by a user action or system event — they're expected and usually 1:1. They don't require marketing consent (CAN-SPAM exemption) but must be genuinely transactional.

| Transactional | Marketing |
|---|---|
| Order confirmation | Promotional campaign |
| Password reset | Newsletter |
| Shipping notification | Product announcement |
| Account verification | Re-engagement campaign |
| Invoice / receipt | Discount / sale notification |

**Key principle**: Keep transactional and marketing email on separate sending infrastructure (different IPs/domains) so marketing reputation issues don't affect transactional delivery.

### Provider selection framework

| Factor | SendGrid | Postmark | Mailgun | Brevo | Customer.io | SES |
|---|---|---|---|---|---|---|
| **Best for** | Scale + marketing combo | Deliverability-first | Developer flexibility | All-in-one + marketing | Behavior-triggered | Raw volume + cost |
| **Deliverability** | Good | Excellent (98.7%) | Good | Good | Good | Good (self-managed) |
| **Pricing model** | Per email | Per email | Per email | Volume tiers | Per profile | Per email (cheapest) |
| **Free tier** | 100/day | 100/month | 1K/month (trial) | 300/day | None | 62K/month (from EC2) |
| **SMTP relay** | Yes | Yes | Yes | Yes | No | Yes |
| **REST API** | Yes | Yes | Yes | Yes | Yes | Yes |
| **Templates** | Dynamic (Handlebars) | Handlebars | Handlebars | UI builder + API | Liquid | Basic |
| **Inbound parsing** | Yes | Yes | Yes | Yes | No | Yes |
| **Webhooks** | Yes (Event Webhook) | Yes (7 types) | Yes (8 events) | Yes | Yes | SNS notifications |

### Template best practices

1. **Keep it simple** — transactional emails should be clear, not flashy
2. **Include essential info above the fold** — order number, tracking link, action button
3. **Use dynamic parameters** — never hardcode user-specific data
4. **Test across clients** — Outlook, Gmail, Apple Mail render differently
5. **Include plain-text fallback** — some recipients/clients need it
6. **Brand consistently** — logo, colors, footer, but don't over-design

### Deliverability for transactional email

1. **Dedicated sending domain** — use `mail.example.com` or `notify.example.com`, not your main domain
2. **Authenticate everything** — SPF, DKIM, DMARC (p=quarantine or p=reject)
3. **Dedicated IP** — at 50K+/month volume, get a dedicated IP and warm it
4. **Separate streams** — keep transactional and marketing on different IPs/subdomains
5. **Monitor bounces** — suppress hard bounces immediately, track soft bounce patterns
6. **Watch complaint rates** — transactional should be near 0% complaints

## Step 3 — Platform-specific guidance

**Read `references/platform-guide.md`** for detailed provider comparisons, API references, integration checklist, and key metrics.

### In MailerLite
MailerLite supports transactional email as a separate feature from marketing campaigns:
- **API-triggered**: Transactional emails are sent via the MailerLite API, not through the campaign builder. Use for order confirmations, password resets, shipping notifications.
- **Separate infrastructure**: Transactional sends don't count against marketing email limits and use separate delivery infrastructure.
- **Templates**: Create reusable templates in the MailerLite dashboard, reference them by ID in API calls.
- **Limitations**: MailerLite's transactional email is basic compared to SendGrid, Postmark, or Mailgun. No inbound parsing, no advanced analytics, no dedicated IP for transactional (Enterprise only). Best for MailerLite users who want to keep everything in one platform. For high-volume or latency-sensitive transactional email, use a dedicated provider.
- **API**: `POST /api/subscribers` for contact management, webhooks for delivery tracking. See `/sales-mailerlite` for full API reference.

*You no longer need the platform guide details — focus on the user's specific situation.*

## Step 4 — Actionable guidance

Based on the user's specific question, provide targeted recommendations drawing on the strategy framework in Step 2 and provider details in the reference guide.

## Gotchas

1. **Don't mix transactional and marketing on the same IP/domain** — marketing reputation problems will tank transactional delivery. Use separate subdomains and ideally separate IPs.
2. **"Transactional" has a legal definition** — CAN-SPAM exempts transactional emails from opt-out requirements, but the email must be primarily transactional. An order confirmation with a 50% coupon at the top is marketing, not transactional.
3. **SMTP is not real-time** — SMTP queues add latency. For time-sensitive emails (2FA codes, password resets), use the REST API for faster delivery.
4. **Webhooks can fail silently** — if your webhook endpoint is down, you'll miss delivery/bounce events. Implement webhook logging and alerting.
5. **Template rendering varies by client** — Outlook uses Word's rendering engine. Always test templates in Litmus or Email on Acid, especially for layout-heavy designs.

- **Self-improving**: If you discover something not covered here, append it to `references/learnings.md` with today's date.

## Before recommending a specific platform skill

This skill covers a strategy domain across many platforms. **Before pointing the user to any specific platform skill** (any `/sales-{platform}` listed in `## Related skills`, e.g., `/sales-mailshake`, `/sales-klaviyo`, `/sales-apollo`), read that platform skill's actual `SKILL.md` first. The 1-line description in `## Related skills` is enough to *identify* a candidate — it's not enough to *commit* to it or to write a prompt that invokes it well.

**How to read it:**
- If `~/.claude/skills/{skill-name}/SKILL.md` exists locally, `Read` it.
- For `sales-*` skills, `WebFetch` directly from this repo: `https://raw.githubusercontent.com/sales-skills/sales/main/skills/{skill-name}/SKILL.md` — e.g., for `sales-mailshake`: `https://raw.githubusercon