Transactional and triggered email delivery — order confirmations, password resets, welcome emails, receipts, shipping notifications, account alerts. Covers provider selection, template design, deliverability, API integration, SMTP relay, and monitoring across SendGrid, Postmark, Mailgun, Brevo, Braze, Iterable, Customer.io, Mailchimp/Mandrill, GetResponse (MAX only), and Amazon SES. Use when password resets or order confirmations aren't reaching customers, you're unsure which provider to pick, triggered emails are landing in spam or arriving late, or SMTP relay setup is failing. Do NOT use for marketing email campaigns (use /sales-email-marketing), cold outbound sequences (use /sales-cadence), cross-platform deliverability strategy (use /sales-deliverability), or SendPulse-specific questions (use /sales-sendpulse). For platform-specific help, use /sales-braze, /sales-iterable, /sales-sendgrid, /sales-postmark, /sales-mailgun, /sales-brevo, /sales-customerio, /sales-mailchimp, or /sales-getresponse.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
Instruções da origem · Visualização somente leitura
name
sales-transactional-email
description
Transactional and triggered email delivery — order confirmations, password resets, welcome emails, receipts, shipping notifications, account alerts. Covers provider selection, template design, deliverability, API integration, SMTP relay, and monitoring across SendGrid, Postmark, Mailgun, Brevo, Braze, Iterable, Customer.io, Mailchimp/Mandrill, GetResponse (MAX only), and Amazon SES. Use when password resets or order confirmations aren't reaching customers, you're unsure which provider to pick, triggered emails are landing in spam or arriving late, or SMTP relay setup is failing. Do NOT use for marketing email campaigns (use /sales-email-marketing), cold outbound sequences (use /sales-cadence), cross-platform deliverability strategy (use /sales-deliverability), or SendPulse-specific questions (use /sales-sendpulse). For platform-specific help, use /sales-braze, /sales-iterable, /sales-sendgrid, /sales-postmark, /sales-mailgun, /sales-brevo, /sales-customerio, /sales-mailchimp, or /sales-getresponse.
argument-hint
[describe your transactional email question or goal]
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:
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
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
60-day trial (100/day)
100/month
1K/month (trial)
300/day
None
3K/month for first 12 months
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
Keep it simple — transactional emails should be clear, not flashy
Include essential info above the fold — order number, tracking link, action button
Use dynamic parameters — never hardcode user-specific data
Test across clients — Outlook, Gmail, Apple Mail render differently
Include plain-text fallback — some recipients/clients need it
Brand consistently — logo, colors, footer, but don't over-design
Deliverability for transactional email
Dedicated sending domain — use mail.example.com or notify.example.com, not your main domain
Authenticate everything — SPF, DKIM, DMARC (p=quarantine or p=reject)
Dedicated IP — at 50K+/month volume, get a dedicated IP and warm it
Separate streams — keep transactional and marketing on different IPs/subdomains
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
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.
"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.
SMTP is not real-time — SMTP queues add latency. For time-sensitive emails (2FA codes, password resets), use the REST API for faster delivery.
Webhooks can fail silently — if your webhook endpoint is down, you'll miss delivery/bounce events. Implement webhook logging and alerting.
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.githubusercontent.com/sales-skills/sales/main/skills/sales-mailshake/SKILL.md.
For non-sales-* skills (third-party), look up {org}/{repo} in ~/.claude/skills/sales-do/references/skill-sources.md if installed and fetch the same skills/{skill-name}/SKILL.md path under that repo.
After reading, ground your recommendation in something concrete from the SKILL.md (its scope, a sub-flow, its argument-hint shape, or a "Do NOT use for..." negative trigger). Align any generated invocation with the platform skill's argument-hint. If the platform skill turns out not to fit the user's situation, swap to another or handle the question here directly rather than recommending a poor fit.
Related skills
/sales-iterable — Iterable platform help (triggered campaigns for transactional email, Studio journeys, cross-channel)
/sales-integration — Connect email tools with CRM and other systems
/sales-do — Not sure which skill to use? The router matches any sales objective to the right skill. Install: npx skills add sales-skills/sales --skill sales-do
Examples
Example 1: Choosing a transactional email provider
User says: "We're a SaaS startup sending about 5K transactional emails/day — order confirmations, password resets, and activity notifications. What provider should we use?"
Skill does: Evaluates volume (medium), use cases (standard transactional), and likely needs (reliability, good deliverability, reasonable cost). Recommends Postmark for best deliverability or SendGrid for more flexibility. Compares pricing at 150K/month volume.
Result: Clear recommendation with reasoning, cost comparison, and setup next steps
Example 2: Debugging delivery delays
User says: "Our password reset emails are taking 30+ seconds to arrive via SMTP through Mailgun"
Skill does: Identifies SMTP queuing as likely cause. Recommends switching to REST API for time-sensitive emails. Shows Mailgun API example for password reset. Suggests monitoring with webhooks.
Result: Root cause identified, API migration code provided, monitoring setup
Example 3: Setting up transactional email in Brevo
User says: "How do I send order confirmation emails through the Brevo API with dynamic order data?"
Skill does: Walks through creating a template in Brevo UI → calling POST /smtp/email with templateId and params → setting up delivery webhooks → error handling and retry logic
Result: Working transactional email flow with template, API integration, and monitoring
Troubleshooting
Transactional emails going to spam
Symptom: Order confirmations or account emails landing in spam
Cause: Usually domain authentication issues, shared IP reputation, or content triggers
Solution: 1) Verify SPF/DKIM/DMARC are properly configured. 2) Check if you're on a shared IP with bad reputation — consider dedicated IP. 3) Review email content for spam trigger words. 4) Ensure you're not mixing marketing content into transactional emails. See /sales-deliverability.
High bounce rates on transactional email
Symptom: Bounce rate exceeding 2% on transactional sends
Cause: Sending to invalid addresses — users entering fake emails at signup, typos, abandoned accounts
Solution: 1) Implement real-time email validation at signup (ZeroBounce, Kickbox, or provider's built-in). 2) Use double opt-in for account creation. 3) Suppress hard bounces immediately. 4) Clean your contact list quarterly.
Webhook events not arriving
Symptom: No webhook callbacks received after sending emails
Cause: Webhook endpoint misconfigured, firewall blocking provider IPs, or SSL certificate issues
Solution: 1) Verify webhook URL is publicly accessible (not localhost). 2) Check that your endpoint returns 200 within 5 seconds. 3) Whitelist provider IP ranges if behind a firewall. 4) Check provider's webhook logs for failed delivery attempts.
