No email platform imports a sequence

My campaign tool generates email sequences: five or six messages with subject lines, preview text, body copy, and a day number saying when each should go out. For a long time the generated sequence sat in the product with no way to get it anywhere useful. The obvious next step was an export.

I assumed that export was a file — some structured format you upload to your email platform, which reads it and builds the sequence. That assumption is wrong, and it is wrong in a way that changes the entire shape of the feature.

What the documentation actually says

Mailchimp and Klaviyo both import one HTML template at a time. The automation that strings messages together — the delays, the ordering, the branching — is built by hand in their interface. There is no format that carries a sequence.

Three consequences fall straight out of that table, and none of them are matters of taste:

There is no vendor-neutral file. Both platforms require an unsubscribe tag, and the syntax differs. A single HTML file cannot satisfy both. Ship the wrong tag and the import is rejected — or worse, accepted and then unable to send.

The timing has nowhere to live. No HTML import carries a day number. If the export is only templates, the sequencing — the part the system actually reasoned about — is silently discarded at the boundary.

"Zip the sequence" is wrong before you write it. Mailchimp's zip holds exactly one HTML file. Five emails is five files or five zips, never one bundle.

What I built instead

A folder. One .html per email, ready to import. A SEQUENCE.txt carrying the schedule. A README. And a plain-text copy of every message.

The schedule file is the piece I would have missed. It does not just list day numbers — it states the wait between sends:

  Day 1 — Eco vs. Potency: A False Trade?
      file:    01-day-1-eco-vs-potency-a-false-trade.html

      ↓ wait 3 days

  Day 4 — The objection you are already thinking

A wait is literally the number you type into a delay step. Printing only the absolute day makes the person do arithmetic at the exact moment they are clicking through an unfamiliar automation builder, which is where sequences get mis-built.

Two details that only appear in real data

I ran the exporter over forty real stored emails. Two things surfaced that no amount of unit testing would have.

Two emails can share a day. The sheet rendered "wait 0 days," which is not an instruction anyone can follow — it reads as a defect in the sequence you are handing a client. It now says "same day, send later in the day."

The markdown is narrower than you would build for. Measured across those forty bodies: bold in eight, italic in five, links in five, and zero headings, zero bullet lists, zero raw HTML. I had been sizing up a full markdown dependency for syntax that never appears. Forty lines of conversion covers the actual distribution.

The part I refuse to automate

The export deliberately emits no personalization merge tags. Not *|FNAME|*, not anything. The system does not know which fields the recipient's list carries, and a merge tag against a list that lacks it sends "Hi ," to a real human being.

That is the same discipline as refusing to fabricate a citation. When you do not know something, the correct output is the honest gap, not a plausible filler that fails in front of someone else's customer.

The general lesson

I spent real design effort on a format that could not exist. Ten minutes with the vendor's own documentation, before the design rather than during the build, would have saved all of it.

When a feature's job is to hand output to somebody else's system, the constraint that decides the design lives in that system's documentation — not in your data model, and not in what would be elegant. Go read it first. And read the vendor's own pages, not a summary: the summaries were confident and several were wrong about the plan gate.