How to Automate Newsletter Production From Scattered Sources
A newsletter reads like one thing and gets produced like twelve. The product update lives in Linear, the customer story is a Slack thread someone screenshotted, the blog post is in the CMS, the event date is in a calendar invite, and the "one link we have to include" is sitting in a marketer's browser tab. To automate newsletter production, you do not need a machine that writes in your voice. You need a machine that does the collecting, the formatting, and the assembling, then hands a nearly finished draft to a human who edits and presses send.
That distinction is the whole article. The scattered-sources problem is a data problem, not a writing problem, and data problems automate cleanly.
What manual newsletter production actually costs teams
Before you build anything, time one full cycle. Not the writing, the whole cycle, starting from the moment someone opens a doc titled "Newsletter, week of" and ending when the send button is pressed. Most of what you will find is not writing.
| Stage | What it actually involves | Why it resists batching |
|---|---|---|
| Source gathering | Checking the blog, the changelog, the CMS, Slack channels, the events calendar, partner emails | Every source lives in a different tool with a different owner |
| Chasing | Asking three people whether their thing is ready to announce | Blocking work that depends on someone else's inbox |
| Selection | Deciding which six of nineteen items are worth a slot | Genuinely requires judgment |
| Formatting | Rewriting titles to a consistent length, trimming excerpts, fixing links | Mechanical, repeated identically every issue |
| Assembly | Pasting into the email platform, rebuilding the layout, adding UTM parameters | Slow, error prone, and undone the moment one item changes |
| QA and send | Link checks, subject line, test send, final read | Should stay human |
The expensive part is not the paragraph that makes readers smile. It is the tab switching that happens before anyone writes that paragraph, plus the reassembly tax when a late item arrives and the layout has to be rebuilt.
Why scattered sources break most newsletter automation attempts
Teams usually try one of two things. The first is a template: a doc that lists the sections so nobody forgets one. Templates help with memory and do nothing about collection. The second is a fully generative approach: point a language model at the week and ask it to write the newsletter. That produces something that sounds like a newsletter and says nothing, because the model has no access to your changelog, your Slack, or your calendar.
The version that works sits in between. A workflow reaches into each source on a schedule, pulls the raw items, normalizes them into one shape, uses an AI step to draft the connective tissue, and creates a draft in your email platform. A person then does the part that actually needs a person: choosing what matters, cutting what does not, and writing the opener.
The workflow design
Here is the basic shape. It runs on a schedule a couple of days before send day, which gives your editor room to work and gives late items a chance to land.
Weekly newsletter assembly
Every Monday 07:00
Collect source items
Normalize fields
AI drafts sections
Create email draft
Notify editor
Four things are worth noticing about that shape.
The trigger is a schedule, not a person remembering. Skopx supports manual, schedule, and webhook triggers, and schedules run in an IANA timezone you choose, so "Monday 07:00" means Monday 07:00 where your editor lives rather than wherever a server sits.
Collection is several integration steps, not one. Each connected tool gets its own step: fetch recent posts, fetch shipped changelog entries, fetch upcoming calendar events, fetch messages from a nominated Slack channel. Skopx connects to nearly 1,000 business tools, so the constraint is usually which sources you want rather than whether they are reachable.
Normalization is a field transform step. Every source returns a different shape, and you want one: title, one line summary, URL, category. This is the step that makes the AI step good, because a model given clean input produces clean output.
The last step notifies a human. It does not send the newsletter.
What to automate and what stays human
Skopx has no human-approval step, and that is a design choice worth being explicit about. There is no node that pauses a run, waits for someone to click Approve, and then continues. So anything with real consequences, and hitting send to your entire list is real consequences, must be prepared by the workflow and executed by a person.
In practice that is exactly how good newsletter production works anyway.
| Task | Automate it | Keep it human | Why |
|---|---|---|---|
| Pulling items from every source | Yes | Mechanical, identical every week | |
| Deduplicating and normalizing fields | Yes | Rule based | |
| Drafting section summaries | Yes | AI step on your own key, from real source data | |
| Adding UTM parameters and formatting links | Yes | Pure string work, humans get it wrong | |
| Choosing the six items that make the issue | Yes | Editorial judgment about your audience | |
| Writing the opener and the subject line | Yes | This is the part readers remember | |
| Final QA and pressing send | Yes | Irreversible, goes to everyone |
The rule generalizes past newsletters. The same "prepare, then notify" pattern is how we describe automating lead nurture sequences without letting a machine improvise customer-facing replies. Preparation is where the hours are. Judgment is where the value is.
How to automate newsletter assembly in Skopx, step by step
There is no drag-and-drop canvas in Skopx. You describe the workflow in chat in plain English, and it gets built as inspectable steps you can then edit. So the build is mostly a matter of writing one clear paragraph.
First, connect the sources. Go to the tools you plan to read from and connect them: your CMS or blog RSS, your project tracker, your calendar, Slack, and your email platform. A workflow can only reach tools that are already connected on your account.
Second, describe the workflow. Open chat and say something close to this:
Every Monday at 07:00 in Europe/London, collect our newsletter source material: the blog posts published in the last seven days, the changelog entries marked Shipped in the last seven days, calendar events in the next fourteen days on the Marketing calendar, and messages in the #newsletter-tips Slack channel from the last seven days. Normalize everything into title, one sentence summary, URL, and category. Then use an AI step to write a two sentence summary for each item in our house voice and group them under the headings Product, Writing, and Coming Up. Create a draft campaign in our email platform with those sections, add utm_source=newsletter and utm_medium=email to every link, and post a message in #marketing-internal with the draft link and the number of items collected. Do not send anything.
Third, check the step list Skopx builds. You should see the schedule trigger, one integration step per source, a transform step, an AI step, an integration step that creates the draft, and an integration step that posts to Slack. Workflows are acyclic and capped at 20 steps, which is comfortable for four or five sources and tight if you try to add nine, so consolidate sources rather than adding a step per blog category.
Fourth, wire the data. Steps read each other's output with expressions. The AI step's prompt references the normalized collection with something like {{ steps.normalize.output.items }}, and the Slack message references the created draft with {{ steps.create_draft.output.url }}. Trigger data is available as {{ trigger.field }} when you use a webhook. If a value comes through empty, the run detail will show you exactly which step produced nothing.
Fifth, run it manually. Do not wait for Monday. Trigger the run by hand, open the run detail, and read each step's real output. Then fix the prompt, not the plumbing, because the plumbing almost always works and the voice almost never does on the first pass.
AI steps run on your own provider key with zero markup, so you will need a key connected before the drafting step does anything. Skopx plans start at $5 per month for Solo and $16 per seat per month for Team, and billing begins from day one.
Adding a branch: the version that handles a thin week
The basic workflow assumes there is always enough material. Some weeks there is not, and a newsletter with two thin items damages the list more than skipping a week does. So add a condition.
Newsletter with a thin-week branch
Every Monday 07:00
Collect source items
Normalize and dedupe
Enough items?
AI drafts sections
Create email draft
Notify editor to review
Alert: thin week
The condition step supports comparisons like equals, contains, greater_than, and is_empty, so "item count greater than 4" is a one line rule. On the short path, the workflow tells a human early on Monday that the issue needs a feature piece, which is far more useful than a draft nobody wants to open. Once this is running, the same normalized item list is a natural feed into content repurposing and social posting, because you already did the hard part of getting everything into one shape.
How to tell it is working
Every Skopx run is inspectable. Each step records its real output, how long it took, and the exact error if it failed, so verification is reading rather than guessing.
Check these four things after the first month:
Draft completeness. Open the generated draft before your editor touches it. Count how many items needed no change at all. If that number climbs issue over issue, your normalization and prompt are right.
Source coverage. Look at the collection steps in a few runs. A source that quietly returns zero items every week is either misconfigured or genuinely empty, and those need different fixes.
Editor time. The honest measure is how long the human spends between draft creation and send. If that shrinks and the newsletter quality holds, the workflow is earning its place.
Failed runs. Missed schedules beyond a two hour grace window are recorded as failed rather than fired late, on purpose, because a newsletter draft that appears at 3pm on Wednesday is worse than a visible failure at 7am Monday. Treat those as signal.
Common mistakes when you automate newsletter production
Letting the workflow send. The most tempting shortcut and the worst one. Prepare and notify. A person presses send.
Asking AI to invent the news. If your AI step is writing from a topic rather than from collected source items, you will get plausible filler. The step should summarize {{ steps.normalize.output.items }} and nothing else, with an explicit instruction not to add facts that are not in the input.
One step per source category. The 20 step cap arrives faster than you expect. Pull broadly in one step per tool and filter in a transform step.
Skipping the manual runs. Three or four hand-triggered runs before you let the schedule take over will surface almost every problem, and they cost you an afternoon rather than a public mistake.
Automating the subject line. You can generate candidates. Let a human choose. The subject line is the only part of the newsletter most of your list will ever read.
Building it and never revisiting. Sources change. A Slack channel gets renamed, a blog moves, a calendar gets replaced. Look at the run history once a month.
You can build this on the workflows page, and the first version is worth building narrow: two sources, one AI step, one draft, one Slack notification. Add sources once the narrow version has shipped two issues.
Frequently asked questions
Can Skopx write the whole newsletter for me?
It can draft every section from real collected source material, which is most of the body copy. It should not write your opener or your subject line, and it should not send. AI steps run on your own provider API key, so the drafting quality depends on which model you connect.
What if a source has nothing in it that week?
Nothing breaks. The collection step records an empty output, the run detail shows it plainly, and the normalization step simply has fewer items. Add the condition branch shown above if you want the workflow to warn you when the total falls below a threshold.
Can someone approve the draft inside the workflow before it continues?
No. Skopx has no human-approval step and no way to pause a run for a click. That is why the pattern is prepare and notify: the workflow builds the draft and posts a link, and a person takes it from there in the email platform. For a newsletter this is the correct design rather than a workaround.
Does it work if our sources are not standard SaaS tools?
Often yes. Skopx connects to nearly 1,000 business tools, and a webhook trigger with a unique URL and a per-workflow secret covers most of the rest, so an internal system can push items into the workflow directly. There are no custom code steps, so anything requiring genuine scripting has to happen upstream of Skopx.
How long does this take to build the first time?
Describing the workflow takes minutes. Connecting the tools and getting the AI step to sound like you is the real work, and that is usually an afternoon plus a couple of issues of tuning. Budget two cycles before you trust it unattended.
Skopx Team
The Skopx engineering and product team