Creative
A document,not a template.
What you write is a block tree with a published schema. What goes out is that document rendered for a target — e-mail, page, form, SMS, push or print. The two are separate on purpose, because the editor is replaceable and the rendering is not, and pretending otherwise is how a marketing tool ends up with six versions of the same message that no longer agree.
Six targets, one source.
Each target has constraints that are not a matter of taste, and the renderer knows them so you do not have to.
E-mail means tables and inlined CSS, no flex and no grid because Outlook still uses Word to lay out mail, a plain-text alternative generated for you, colours that survive a dark-mode client inverting things, and a size guard at about 102 KB where Gmail starts clipping.
Page means ordinary modern responsive HTML, published under a slug, on your own domain if you want one. Form is a page plus field bindings, validation, a honeypot and a rate limit — and it is the one route into your contacts that can legitimately produce a consent basis.
SMS counts segments as you type. Push is a title, a body, an icon, actions and a deep link. Letter is print CSS rendered to a PDF, addressed and posted.
The document itself is stored as a setup with a published schema, in the ecosystem's document service rather than hidden in a private table. Which means the day a better editor arrives, it edits the same documents and nothing upstream changes.
- 1emailTables, inlined CSS, text alternative, dark-mode safe, ~102 KB guard.
- 2pageResponsive HTML under a slug, on your domain.
- 3formPage plus bindings, validation, honeypot, rate limit.
- 4smsText with a live GSM-7 / UCS-2 segment counter.
- 5pushTitle, body, icon, actions, deep link.
- 6letterPrint CSS → PDF.
- iThe seamThe editor is replaceable; the targets are not. That is why the document has a published schema.
Rendered output cached per target
Merge variables
An unknown variable fails at publish,
not silently at send.
The default behaviour of every templating language for a missing key is to render nothing. In a mail that means "Hi ," going to forty thousand people, and nobody finds out until the replies start arriving. So a document is validated against the variable vocabulary before it can be published at all.
What you can interpolate
The contact's e-mail, name, phone and locale; attrs.*, which is open because the attributes are yours; your organisation's name and postal address; the unsubscribe and preferences links; and the message's own subject and preheader.
Deliberately a list rather than "anything on the record". A contact row also carries internal identifiers, and none of those belong in a message.
A fallback is not a missing variable
{{first_name | default:there}} is a known variable that this particular contact happens not to have — an imported list where half the rows had no name. That renders the fallback and is completely fine.
What is refused is {{frist_name}}: a variable that does not exist for anybody. At send time the two look identical. At publish time they could not be more different, which is why the check happens there.
The same vocabulary works across every target, so a phrase written for an e-mail renders in the SMS and on the landing page without being rewritten. And first_name is derived at render time from the whole name rather than stored — because a stored split is a wrong split waiting for the person whose name does not fit the assumption.
Write it once.
It arrives dressed for the channel.
Before it goes out
The checks that happen
while you can still fix things.
The Gmail clip
Above roughly 102 KB, Gmail truncates the message and hides the rest behind a link most people never press — including, at the very bottom, your unsubscribe. The renderer measures and warns at publish.
Image weight
A four-megabyte hero photograph blows the size budget and renders badly on a phone. Images are resized and converted on upload, which is a deliverability matter rather than a nicety.
Inbox preview
The message is rendered and photographed at desktop and mobile widths, so the list view shows what the thing actually looks like rather than its name. No paid preview service involved.
A real test send
Send it to yourself, through the same renderer and the same sending identity a real recipient would get. A preview that takes a different code path proves nothing about the message that ships.
Pasted HTML is sanitised
Content pasted in from elsewhere goes through a sanitiser before it is stored, because a marketing e-mail is not the place to find out what was in somebody's clipboard.
Markdown, if you prefer
Write in Markdown and have it rendered. Far more reliable than asking a model for e-mail HTML, and it is what makes an agent writing a message a workable idea rather than a demo.
Starting from your own website.
Paste a URL on your first run. ClickSomo reads the page for its logo, its icons, its manifest and its measured colours — not colours somebody guessed at — and builds a first e-mail that already looks like yours. It also detects the platform, which is usually enough to suggest a funnel worth having: a shop gets an abandoned basket, a publisher gets a newsletter welcome.
Every fetch of a URL you supply goes through a guarded fetcher: HTTP and HTTPS only, literal addresses checked directly, every DNS answer required to be public, and every redirect hop re-validated. Fetching arbitrary URLs on a customer's behalf is one of the easiest ways to build a hole in your own network, and it is not a thing to write twice.
The honest bit: a first template generated from your website is a good start, not a finished design. It gets the logo, the colours and the typeface roughly right so that your first send does not look like a demo — and then you edit it, which is a far better job than staring at an empty canvas.
Tell us what you send today,
and to how many.
We will show you what it looks like here — usually with the funnel drawn, because that is faster than a paragraph about it.
Open ClickSomo Talk to a person