email_newsletter — Email Newsletter

Field	Value
Type key	`email_newsletter`
Label	Email Newsletter
Agent queue	`email-writer`
Plan tier	Free+ (starter, growth, professional)
Credits/unit	2
Monthly range	1–4

What it produces

A full email newsletter: subject line (+ 1–2 A/B variants), preview text, HTML body (intro, main content sections, CTA button, footer), and a plain-text fallback. Output is stored in Activity.outputPayload.

Typical structure:


{
  "subjectLine": "5 spring garden tips your neighbours don't know",
  "subjectVariants": ["Spring is here — is your garden ready?"],
  "previewText": "Quick wins before the season starts",
  "htmlBody": "<html>...</html>",
  "plainText": "..."
}

Pipeline sequence


email-writer ──→ Activity: done
                       │
              [auto-approved — no review]
                       │
           Deliverable status: approved

No HITL gates. Email newsletters auto-approve on agent completion.

Status machine

Status tracked on the parent Activity record only.

Activity status	Meaning
`pending`	Scheduled, waiting
`queued`	Submitted to BullMQ
`in_progress`	Worker running
`done`	Newsletter written, outputPayload saved
`failed`	Worker error

The Deliverable moves from generating → approved automatically on done.

HITL gates

None. Email newsletters are not routed to the DM approvals queue or the client dashboard for approval. They auto-approve and can be exported by the client or agency for use in their ESP.

Dependencies

None. The email writer uses tenant context (business, tone, audience, services/offers) from the client context file and strategy. If blog posts are published this period, the writer may reference them as content hooks.

DB records created

Record	Created by	Notes
`DeliverableTemplate`	deliverable-planner	Monthly quota (e.g., “2 newsletters/month”)
`Activity`	activity-planner	One per newsletter; `type = email_newsletter`
`Deliverable`	email-writer worker	Auto-approved on completion

No dedicated content model. Newsletter content lives in Activity.outputPayload.

Key rules

2 credits per newsletter reflects the higher complexity vs. a single social post or GBP post.
No publishing integration — newsletters are delivered as copy for the agency/client to send through their own ESP (Mailchimp, Klaviyo, etc.).
Monthly volume (1–4) is determined by the deliverable planner based on the tenant’s strategy goals.