Let Marketing Ship Emails Without Breaking Them: Build Blocks, Not Templates

Short answer: if several people across several markets send campaigns, nobody should be editing finished email HTML. Have developers build a library of solid blocks, let marketing fill in named fields, and make market rules and publishing part of the tool. If you're one team in one market, buy an email platform instead.

Once campaigns go out from more than one team, in more than one language, the email itself becomes the risky part of the process. Here's the setup that holds up, and when you shouldn't build one at all.

1. Email HTML is expert work. Do it once

Email is not the web. Layouts are still built from nested tables and inline styles, and Outlook on Windows renders messages with Word's engine rather than a browser's. One deleted tag can leave an email looking fine in the editor and broken in someone's inbox.

That makes it a bad thing to redo for every campaign, and a worse thing to hand to people whose job is the offer and the message. Copying last month's file and editing around the code works until the day it doesn't, usually just before a send.

2. Build blocks, not templates

A template is a whole email, so every new layout means another whole email to build and keep correct. A block is one piece: a header, a hero image, an offer, a footer. Developers build each block once, and a campaign is simply an ordered list of them that marketing can drag into shape.

The library stays small while the number of possible emails grows. Fix a block once and every new campaign gets the fix.

3. Give marketing fields, not code

Each block declares what can change, and nothing else is editable. A field has a type (image, short text, link, rich text), a note explaining what belongs there, and a default value, so a freshly added block already looks finished and the person editing it never sees a table tag.

The field type does more than it seems to. It decides which input appears, so an image gets an upload and a link gets a link box. A raw HTML field is useful for the rare case nothing else fits, but keep it for developers: every use is a small hole in the guarantee the blocks give you.

4. Put the market rules in the tool, not in people's heads

Anything people must remember will eventually be forgotten by someone in a hurry, so the rules belong in the software:

• Styling per market. Each market's styles are applied when the email is built, so nobody restyles a campaign by hand.
• Tracking on every link. Each campaign category has its own link suffix, added automatically to every URL in the email. A missed link can't quietly disappear from your reports.
• Access by market. People only see templates for the markets they work in, and each role has separate read, write, edit and delete rights. One country's team can't overwrite another's campaign.

5. Make publishing the last step of the tool

An editor that ends in "export the HTML and paste it into the mailer" keeps the riskiest step manual. Publish the finished template straight to the sending system over its API, and only offer the sender accounts that belong to the user's market. Pushing to the wrong country's account stops being a possible mistake. Keep a plain download for the unusual case.

Should you build one? Five questions

1. Do several teams or markets send campaigns, with different languages or brands? (If not, buy.)
2. Do those teams need to be kept out of each other's work? (Check what your platform's permissions really do.)
3. Are you keeping a sending system that existing builders don't connect to? (That favours building.)
4. Would locked blocks in an off-the-shelf platform cover it? (Many offer them. Try this first.)
5. Will someone own the block library after launch? (If nobody will, it decays like any other code.)

Most companies should stop at question one or four. The same reasoning applies well beyond email, as we cover in build vs. buy: custom software pays off where your process really differs, and rarely anywhere else.