Backend · Automation · Communications
Designing email as part of the product, not an afterthought
Transactional email treated as business workflow across several products: triggered server-side, templated properly, and accountable when it fails.
Workflow design
Template architecture
Server-side triggering
Failure handling
Deliverability
Why this is a case study
Transactional email is usually the last thing specified and the first thing that quietly breaks. It is treated as a template, when in most products it is the only evidence a customer has that something happened.
This study is drawn across several engagements rather than one, because the pattern repeats: a registration that sends nothing, a payment confirmation that arrives after the customer has phoned to ask, an administrative notification nobody realised had stopped.
The approach
Email belongs in the workflow, not beside it. If an order is paid, the confirmation is part of the transition rather than a task attached afterwards, which means it is triggered server-side from the event itself rather than from a client that may have closed.
It also has to be accountable. Delivery fails for ordinary reasons, and a system that cannot tell you whether a message was sent leaves the operation guessing at precisely the moment a customer is asking.
What this covers
Custom HTML transactional email across registration and confirmation, booking confirmation, order and payment notification, form submissions, event and webinar registration, application workflows and administrative alerts—with dynamic template variables and multilingual variants where the product serves more than one language.
Implementation has run through SendGrid, Nodemailer and SMTP, triggered from Firebase Cloud Functions, Node.js services, PHP and WordPress, and alongside Shopify order workflows, with retry and error handling where the operation depends on the message arriving.
Outcome
Across these products, email does what the business needs rather than what a template library defaults to: the right message, triggered by the actual event, in the recipient's language, with a record that it was sent.
The distinction that matters is that email is treated as part of the business workflow. A confirmation that does not arrive is not a design problem; it is an operational failure that reaches the customer directly.
My contribution
- Designing email into the workflow rather than after it
- HTML template architecture and dynamic variables
- Server-side triggering from application events
- Multilingual template handling
- Retry and error handling
- Sender authentication and deliverability
Technology
- SendGrid
- Nodemailer
- SMTP
- Firebase Cloud Functions
- Node.js
- PHP
- WordPress
- Shopify
A clear next step
Start with the decision in front of you.
Get preliminary direction first, or book a focused session when the question is ready.