How should I set up QA between newsletter writers and the final editor?

My editor shouldn't be the one catching broken links. That's the whole idea behind the QA step.

Why does QA take so much time?

Because there's so much to check. A local issue can have 50 to 75 links on top of all the content. Every link has to be the right link, in the right place, and every statement has to be right.

Local readers notice. We once said a new building was remodeled when it was built from scratch, and we got the email. People like to get mad when something's wrong. It's the Facebook thing.

In mid-2025 my editor was working 30-plus hours a week, and I'd guess 75% of that or more was QA. Work reached her about 80% good. The goal of a dedicated QA person was that by the time it got to her, she'd know it was 99% good.

What does the workflow look like?

1. Writers finish the newsletter.
2. An ops person QAs it for structural and factual errors: broken links, wrong locations, factual slips.
3. The final editor reads it for context and voice only.

"Her primary role is QA-checking newsletters from the writers before they reach the editor, catching structural and factual errors like broken links and wrong locations, so the editor's review stays focused on contextual issues."

The content itself is curation. We find the news and events that are already out there and rewrite them in our own words. We're not inventing news. That's why the checking matters: you're vouching for someone else's facts.

What do overseas writers miss?

The little things. They don't know what's going on in the local area, literally, so they miss details a local would catch. Quality control is the hard part of scaling with overseas help.

In practice, when I review a newsletter before it sends, each one usually has about three little things to fix, and that takes about 10 minutes. It's not a big deal. They aren't the best newsletters ever written, but in most of these towns the competition is close to nothing.

How does the QA person learn the work?

By doing it first. Our ops person wrote three to four newsletters before taking on QA, so she knew what a good one looks like and where mistakes hide.

How do I keep writers from relying on memory?

Every newsletter gets its own task with a linked Google Doc, a checklist and the source links. Status changes trigger notifications, so the next person knows it's their turn. When we set this up in May 2026 it lived in ClickUp. The structure matters more than the tool.

How do I handle daily recurring checks?

One parent task with subtasks, and the parent only completes when every subtask is checked. Our daily message check has four:

• Instagram comments
• Facebook comments
• The brand's email inbox
• Newsletter poll comments, Fridays only, since a weekly check the day after the send is enough

I built the whole system in one pilot brand first, then saved it as a template for every other brand.

What about automated emails?

They need QA too, and it's easy to forget because nobody looks at them every week. We found a three-email automation pitching a local agent's booking link where every link was broken. People were clicking, between 1% and 2.5%, which isn't bad for a pitch. The only thing they could actually click was the calendar invite.

• Check every link and button when you build it. Double and triple check.
• Have a plan to re-check after launch. Links change and platforms misbehave.
• When you change a link, find every place you used it.
• Confirm the audience is actually enrolled. We once finished an automation and nobody added subscribers to it.

With dozens of newsletters and several automations each, missing one item is easy. Write the steps down, ideally with a video of exactly how to set it up.

What if a client keeps changing the newsletter I write for them?

Set a rule. Running newsletters for real estate clients taught me this fast: why does it say that, can you change this, a restaurant was mad about a mention. The middle ground I'd move to: the draft lands in their drafts two days before it sends. They have full right to change it. If something goes out they didn't like, that's on them for not checking.

How much polish does each section need?

Less than you think, for some inputs. Ask what the reader would do differently if it were merely good. If instead of finding the absolute 10 best events we put in six pretty good ones we found quickly, what changes? Separate the things readers can compare and catch from the things they can't, and spend QA effort on the first group. More in how to cut newsletter production time and the pre-send checklist.