The people who most want to build emails (brand, lifecycle, campaign and regional marketers) are usually the people who aren’t allowed in the ESP. That’s not bureaucracy for its own sake. It’s a sensible response to what an ESP is. The fix isn’t to loosen ESP permissions; it’s to give creation its own home and keep sending where it already lives.
Why don’t marketers have ESP access in the first place?
Because an ESP is a send-to-millions system. The same account that holds your templates also holds your audiences, journeys, triggers, suppression lists and sending reputation. A mistake in the wrong screen doesn’t produce an ugly draft; it can email the wrong segment, break a live journey, or expose customer data.
So most enterprise teams restrict the ESP to a small CRM or marketing-ops group. That’s a reasonable policy, and this guide doesn’t argue against it. ESPs such as Braze, Iterable and Salesforce Marketing Cloud are the right place to send. The question is where the creating should happen.
What does keeping marketers out of the ESP cost?
The creative work doesn’t go away; it turns into a queue. A marketer writes a brief, files a ticket, and waits for design, copy, development and QA to take their turns. In most enterprise teams a single campaign takes 8 to 14 working days from brief to send, according to our analysis of the enterprise email process.
The hidden costs are just as real:
- Marketers become traffic cops. They coordinate other people’s work instead of doing their own.
- Testing gets cut. When every version is another ticket, the test plan shrinks to what the queue can absorb.
- Ops becomes the bottleneck. The people trusted with the ESP spend their time on production instead of on segmentation, journeys and deliverability.
What are your options?
There are five common ways teams handle this. Each is right for someone.
| Approach | Marketer autonomy | Risk to sending | Brand and code control | Works best when |
|---|---|---|---|---|
| Limited ESP roles for marketers | Medium | Medium: they’re still inside the sending system | Depends on discipline in the ESP editor | Few requesters, well-trained, ESP has granular roles |
| Ticket queue to the CRM/ESP team | Low | Low | High | Low email volume, few versions |
| Design in Figma, hand off to developers | Low (design only) | Low | High, but slow | Big, bespoke campaigns |
| Agency or offshore production | Low | Low | Varies by vendor | Overflow and one-off projects |
| Separate creative layer that exports to the ESP | High | Low: nothing is sent from the creative tool | High: builds only inside locked templates | Many requesters, lots of versions, a modular template system |
If you only have a handful of trusted requesters and your ESP supports tight roles, the first option may be all you need. The fifth option earns its keep when demand for emails outgrows the people allowed to build them.
How does “create here, send there” work?
The model splits responsibilities along the line that already exists in most organizations: marketers own the message, ops owns the send.
- Ops loads the code once. Your existing modular templates and code libraries go into the creative tool as they are, including your ESP syntax. In Denada, template code is referenced but never altered.
- Brand loads the rules once. Guidelines, voice rules, product facts and legal lines live as reference documents (Smart Docs) and standing instructions (the Master File), so every draft starts from them.
- The marketer builds. They brief the agent (typed, pasted or uploaded) and it builds a fully coded, on-brand first draft (layout, copy, images and HTML) inside those templates. Then they refine it with the agent or edit it directly.
- Review happens in one place. Threaded comments anchored to blocks (or to the subject line and preheader), @mentions, statuses from Draft to In review to Approved, and full version history. See comments and collaboration.
- A person exports. Export is always an explicit human action, and the email lands in the ESP as a template, content asset or draft. It is never sent.
- Ops sends as usual. The CRM team attaches the audience, checks the journey and schedules the send in the ESP they already control.
What guardrails should be in place before marketers build?
Whatever tool you use, check it against this list before you widen access.
| Guardrail | What it prevents | How Denada handles it |
|---|---|---|
| Template code is locked | Broken rendering, off-brand colors and fonts | Your code is stored and referenced, never rewritten. Requests that would change the template are declined |
| Written brand and voice rules | Tone drift, banned phrases, wrong claims | Smart Docs and the Master File apply to every draft |
| Approval status | Unreviewed work reaching the ESP | Draft / In review / Approved statuses, with comments and @mentions |
| Human-only export | Automation pushing work to the ESP | Export is always started by a person |
| Export creates a draft, not a send | Accidental sends to real customers | Lands as a template, asset or draft campaign; nothing is sent from Denada |
| Version history | Lost changes, “who edited this?” | Full version history on every email |
| Identity and security | Shared logins, data exposure | SAML SSO, SOC 2, and closed LLMs that don’t train on your data (AI security) |
What does each ESP receive on export?
The handoff only works if the email lands somewhere your ops team already knows how to use. Here’s what Denada creates in each of the nine ESPs it exports to directly:
| ESP | What the export creates |
|---|---|
| Braze | An email template (name, subject, HTML), plus optional Content Blocks |
| Iterable | An email template, with a name-conflict check before overwriting |
| Salesforce Marketing Cloud | A Content Builder HTML email asset, in the folder you pick |
| Klaviyo | A code template, updated or created new |
| HubSpot | A coded Design Manager template and a marketing email that uses it |
| Zeta | A content template, with a link to edit it in Zeta |
| Acoustic | A shared mailing template |
| Cheetah Digital (Marigold) | A content block with auto-generated plain text |
| Campaign Monitor | A draft campaign (never sent) |
Merge tags are written in your library’s own language (Liquid, Handlebars, AMPscript and so on), so personalization arrives intact. For any other ESP that accepts HTML, export the email as HTML or a ZIP.
Who owns what once marketers can build?
Spelling this out avoids the “so who’s responsible now?” conversation after launch.
| Role | Owns | No longer does |
|---|---|---|
| Marketer / campaign manager | The brief, the draft, versions, getting approval | Waiting in a ticket queue |
| Brand / creative | The template system, brand rules, final creative sign-off | Resizing, re-coding and minor copy changes |
| CRM / marketing ops | ESP access, audiences, journeys, scheduling, deliverability | Hand-building every email |
| Developers | Template code and new modules | One-off email builds |
This matches what we’ve seen across installs: developers move to template management, copywriters to leadership, and marketing managers become the new creators. More in 3 years of agentic workflow data.
How do you roll it out without disrupting the ESP team?
- Start with one email type. Pick a high-volume, low-risk format (a newsletter or promo) and one ESP folder for exports.
- Load your real templates. Don’t design new ones for the pilot. The point is to prove your existing system works in marketers’ hands.
- Decide who approves. Agree which status unlocks export, and who is allowed to set it.
- Measure before and after. Track working days from brief to “ready in ESP” for the pilot versus your current average.
- Widen access in phases. Three to five phases works best, one team or region at a time.