Sending newsletters should be fun. You hand pick the content that resonates with your audience, hit send, then keep refreshing the dashboard to see how it performed.
But sometimes there are too many clicks between picking the content and refreshing that dashboard. If you’re managing newsletters, you already know how it happens. A process that works for one newsletter gets repeated as more are added. Eventually, people are spending time doing work the system could be doing for them.
Judgment vs. assembly
Building a good newsletter involves plenty of judgment. Someone has to decide which stories belong, where they should go, how they should be presented and what will actually resonate with the audience.
But wrapped around those decisions is a lot of assembly work. Pulling in stories, resizing images, checking formatting, inserting ads, testing the email and fixing things that broke. All of that work needs to happen. It just doesn’t mean someone has to do every step manually.
The goal is to automate the parts that don’t need to be done by hand while keeping the decisions with the people who should be making them.
What happens as the operation grows
A newsletter portfolio can grow in a lot of different ways. You might be adding newsletters, publications, local markets, more content, or more ways to tailor the newsletter to different audiences.
The question is where are the levers to facilitate efficiency as growth comes along. That’s where the way the newsletter is built and how content selection is made starts to matter.
Here are a few examples.
More newsletters pulling from the same data.
Someone pulls yesterday’s analytics from GA, Parse.ly or Chartbeat, grabs the top articles, goes to the website, pulls the images, resizes them for the email, and drops the headline and description in. That process will have scaling issues.
That work can be automated. We’ve built integrations in PostUp that can use performance data from Google Analytics, Parse.ly or Chartbeat to determine which articles populate the newsletter. The finished email can still go through the same review or approval process before it sends.
More markets and publications.
We worked with a media company that had newsletters being produced across hundreds of local markets. Historically, each market had more responsibility for its own email production. That meant a lot of people across the company spent time being email marketers just to get their newsletter with direct-sold ads out. At that scale, you also have the training and support that comes with it. Not ideal.
They moved to a more centralized model. A central team managed article selection and the master newsletter template, while the local markets retained control over their own advertising. The newsletter could still be local where it needed to be, but every market no longer needed its own email production operation.
Faster newsletter curation.
Not every newsletter should be automatically assembled. An editor may want to look through the available stories and decide exactly what belongs in that day’s email and where.
Some publishers have created custom CMS workflows for this. An editor can tag an article for a newsletter, change the email headline or description, and even specify where it should appear. That can work, but it also means making your final curation decisions in the CMS rather than in the email itself.
Another approach is to bring the CMS content into the email platform. PostUp, for example, lets editors browse available stories and drag them directly into the newsletter template. The editor still decides which stories make the cut and where they go, but the headline, description, image and URL come with the story. They can arrange and rearrange the newsletter while looking at the email they’re actually going to send.
More audience variations.
Rules based content can work when the logic is simple, such as using a subscriber’s interest to populate a block from the corresponding content feed. But this can quickly become a headache to maintain as rules need modification. AI based recommendations can take that further by selecting from a larger pool of available content for each reader. Either approach lets the newsletter vary by audience without requiring the team to build each version separately.
What do you do with the time you get back?
Getting production time back is useful on its own. But for a lot of teams, there’s already a list of things they want to do with it: launch another newsletter, work on list growth, test a new monetization partner, build a new subscriber journey, or spend more time figuring out what content is actually working.
That’s where newsletter efficiency starts to become a growth question. If your team has ideas for growing the email program but spends most of its available time producing what already exists, the constraint may not be a lack of ideas. It may just be the way the operation is built.