KoltrixPlain-Text vs Designed Emails for SaaS Lifecycle Mail
Plain text feels personal and renders everywhere. Designed HTML suits receipts and digests. Which lifecycle emails belong in which format, and why.
On this page(8 sections)
- What each format is good at
- Matching format to email
- The middle ground most teams end up in
- Rules that apply whatever you choose
- Always include a plain-text part
- Design for dark mode
- Make it accessible
- Keep images optional
- One primary action
- A worked example: the same email, two ways
- A quick test: would a person send this?
- What about tracking?
- Bottom line
There's a recurring argument in SaaS teams about whether lifecycle emails should look like a person typed them or like they came from a designed brand. Both camps are right, about different emails. The useful question isn't which format is better. It's which job each email is doing.
What each format is good at
Plain-text-style emails look like a message from a colleague: no header image, no buttons, maybe a signature. In practice, most are sent as simple HTML that looks like plain text, plus a real plain-text part.
They work well because:
- They read as personal, which invites replies.
- They render the same in every client, including dark mode and accessibility tools.
- They tend to land in the primary tab more often than heavily designed mail, because they resemble the person-to-person mail that tab is meant for. No format guarantees placement, though. Sender reputation matters more.
- They're fast to write and change.
Designed HTML emails have layout, brand colors, images and buttons. They work well when:
- The email presents structured information: line items, a table of usage, a list of updates.
- Visual hierarchy helps the reader scan.
- The brand impression genuinely matters, such as a major launch.
- The main action is a click, not a reply.
Matching format to email
| Recommended format | Why | |
|---|---|---|
| Welcome | Plain | Personal, invites replies, one link |
| Onboarding nudges | Plain | Feels like help from a person, not marketing |
| Trial ending | Plain, or lightly designed | Clarity and trust matter more than polish |
| Founder check-in | Plain, always | Design makes it obviously fake |
| Receipt or invoice | Designed | Structured data, scanned rather than read |
| Usage or weekly digest | Designed | Tables and charts need layout |
| Product update or changelog | Lightly designed | Headings and images help scanning |
| Dunning (failed payment) | Plain | Should feel like a direct, calm notice |
| Security alerts | Plain, minimal | Must look trustworthy and avoid resembling phishing |
| Major launch announcement | Designed | Brand moment, visual storytelling |
The pattern: the more an email depends on a relationship or a reply, the plainer it should be. The more it depends on structured information, the more design helps.
The middle ground most teams end up in
Many teams settle on a lightly designed template for almost everything: a white background, a small logo or none, one font, generous spacing, and at most one button. It reads nearly as personal as plain text while giving receipts and digests enough structure.
If you're starting from nothing, this is a sensible default. Build one simple, flexible template and save heavier design for the two or three emails that truly need it.
Rules that apply whatever you choose
Always include a plain-text part
Every HTML email should be sent with a plain-text alternative. Some recipients read in text-only clients, some accessibility setups prefer it, and some spam filters view HTML-only mail with suspicion. Generate the text version from the same source as the HTML rather than writing it separately, so the two never drift apart.
Design for dark mode
Many people read email in dark mode, and clients handle it differently. Some invert colors and some leave them alone. Practical defenses:
- Avoid text baked into images.
- Use logos with transparent backgrounds that work on dark and light.
- Don't rely on color alone to convey meaning.
- Test in at least one client that inverts colors.
Make it accessible
- Use real text, not images of text.
- Give images meaningful alt text, or empty alt text for decorative ones.
- Keep sufficient color contrast.
- Use a readable font size; small gray text is hard on everyone.
- Write link text that makes sense on its own. "View your invoice" beats "click here."
Keep images optional
Many clients block images until the reader allows them. If your email is unreadable without images, assume a meaningful share of recipients will see something broken. The core message and the main action should work with images off.
One primary action
Whatever the format, an email with five equally weighted buttons usually gets fewer clicks on the one that matters than an email with one. Decide what the email is for before you design it.
A worked example: the same email, two ways
Take a trial-ending email. The designed version has a logo header, a colored banner reading "Your trial ends in 3 days," a three-column grid of plan features, and a large button. The plain version reads:
Hi Jordan,
Your trial ends on Friday. After that, your workspace becomes read-only until you choose a plan. Nothing is deleted.
So far you've set up two projects and invited one teammate. If you want to keep going, plans are here: [link]
Questions? Just reply. I read these.
The designed version looks more polished in a screenshot. The plain version answers the reader's actual questions, namely when, what happens and what to do, in the first three lines, and it gives them a reason to reply. For an email whose job is to help someone make a decision calmly, the plain version usually does that job better.
A quick test: would a person send this?
Before sending a lifecycle email, imagine it arrived from a colleague at a company you like. Would it seem natural for them to send it like this? A founder's welcome note with a hero banner fails the test. A detailed invoice as a wall of plain text also fails it.
What about tracking?
Open tracking relies on a tiny image, so plain-text emails sent as true text can't track opens at all, and HTML emails track them unreliably because many mail clients now prefetch images for privacy reasons. If format decisions are being driven by wanting open data, reconsider. Measure what happens in your product after the email instead: did the user finish setup, update their card, or reply?
Bottom line
Use plain, personal-looking emails for anything that depends on trust or a reply: welcome, onboarding, founder notes, dunning and security. Use design for structured information: receipts, digests and genuine brand moments. Whatever you choose, include a plain-text part, test dark mode, keep images optional, and give each email one clear action.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
