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 work with a media company producing newsletters across hundreds of local markets. At that scale, how do you make newsletter production more efficient without taking control away from the people who actually know what matters most each morning?
Their approach was to centralize the infrastructure without centralizing all of the editorial judgement.
Stories from across their local publications flowed into a central content feed. Algorithms helped determine which stories were most relevant for each market and populated those stories into a master newsletter template.
That meant local teams had a recommend newsletter to start with each day.
If an editor had the time to curate the newsletter, they could. They could review the suggested stories, change the order, remove something or select a different story they believed was critical to their market. If they didn’t have time or reviewed a daily proof, the newsletter could deploy with the recommended content.
A master newsletter template was also critical to making the model work. Brand specific elements could be inserted dynamically, so each local newsletter could carry the correct address, links and other information without maintaining a separate template for every market. That matters for compliance, CAN-SPAM requires a valid physical postal address but it also makes the operation much easier to manage. Local social media links can change without creating new template versions, and a company wide redesign can be made once rather than repeated across dozens or hundreds of templates. The newsletters can remain local where they need to be while the underlying brand and template stay centrally managed.
Advertising remained local, too. Each market retained control over the direct sold advertising appearing in its newsletter. The production framework could be standardized across the organization without taking away the local advertising decisions and relationships that were important to the business.
The result was an operation that could support hundreds of local markets without requiring hundreds of identical email production operations. Some markets could operate in a hybrid automated model while others fully automate, seeing daily email proofs. The technology handled more of the assembly, while local teams retained control over the editorial and advertising decisions that benefited from local knowledge.
Faster newsletter curation.
Automation doesn’t eliminate the need for hands-on curation. Sometimes an editor knows exactly which stories should lead that day’s newsletter, regardless of what the data or an algorithm recommends.
The opportunity is to make that editorial decision without making the editor do all of the assembly work that comes with it.
Some publishers handle this through custom CMS workflows. An editor can tag an article for a newsletter, modify the email headline or description, and even specify where it should appear. The newsletter is then assembled based on those decisions.
Another approach is to bring the available CMS content directly into the email production workflow. Editors can browse available stories and select the ones they want without manually copying over the headline, description, image and URL. Those elements come with the story, leaving the editor to focus on which stories make the cut and where they should appear.
The difference is where the final editorial decision happens. In one model, the newsletter is curated from the CMS. In the other, the editor curates 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.