A company blog with one writer has no process. The same person writes, rereads and hits publish, and nobody notices that three different jobs just happened.
The second writer is where it breaks. Drafts sit in a shared doc waiting for the founder... or someone publishes without a second read and a customer spots the wrong price before anyone on the team does.
I think the fix is smaller than most teams make it. One named person per job, one login per person, and one review pass that ends in a clear yes or a written list of changes.
Three jobs, not three people
Writer. Drafts the post, adds images, and says when it's ready. Usually a marketer, a founder, or whoever is closest to the subject, like a support lead writing up a question customers keep asking.
Reviewer. Reads the draft before anyone outside the company does. The job is catching what the writer can't see: a claim that isn't true any more, a customer named without permission, a paragraph that only makes sense to the person who wrote it. The reviewer approves or sends it back with a comment.
Publisher. Owns the public details and the timing: URL, search title and description, featured image, tags, publish date. On a small team the reviewer usually does this too. It still helps to keep it separate in your head, because "approved" and "live" are different moments.
The one rule that holds it together: the writer shouldn't be the only person who reads a post before it's public. Two people can cover all three jobs as long as that holds.
How small teams usually split it
| Team | Writes | Reviews | Publishes |
|---|---|---|---|
| Founder and one marketer | Marketer | Founder | Marketer, after approval |
| Marketer plus subject experts (engineering, support, sales) | Experts draft, marketer edits | Marketer, plus the expert for accuracy on technical posts | Marketer |
| Agency or freelancer writing for the company | Agency | Someone at the company | Someone at the company |
| Founder writes, team member checks | Founder | Whoever knows the topic best | Founder |
The agency row is the one to get right first. If an outside writer can publish directly, there's no checkpoint between a contractor's draft and your own domain. Give them access to write and submit, and keep approval and publishing inside the company.
One post, start to finish
1. Draft where it will be published. A draft written in a separate doc has to be pasted in later, and that's where formatting breaks, images go missing and the live version drifts from the approved one. Most blog platforms keep drafts private until publish, so there's no risk in starting there.
2. Submit with a note. "Pricing figures checked against the pricing page on Tuesday" or "not sure about the second section" tells the reviewer where to spend their time. It takes ten seconds and saves a full reread.
3. Approve, or request changes in writing. No "let's discuss". If the reviewer wants changes, they write them down next to the post. The writer gets a list instead of a meeting, and the reasons stay recorded. The writer edits and submits again.
4. Check the public details, then publish or schedule. Approval clears the words. Before it goes out, whoever publishes checks what readers and search engines see first:
- Slug. Short and permanent. Changing it after publishing means a redirect.
- SEO title and description. The description is what shows under the link in search results and chat previews.
- Featured image. It becomes the preview when the post is shared.
- Tags or categories. Use ones that already exist. A new tag for one post is a dead end for readers.
If the writer and publisher are in different time zones, check which zone the scheduler uses. "Tuesday 9 AM" is not the same moment for both of them.
Edits to live posts go through review too
A price goes up, a feature gets renamed, a screenshot goes stale. Treat these edits like drafts. A "quick fix" on a live post is exactly how an unreviewed rewrite ends up on the company domain. If your platform keeps revision history, you also get a record of what changed and when.
What the reviewer actually checks
A review that tries to check everything turns into a rewrite, and the writer stops submitting. These are the things a second reader catches that the writer usually can't:
- Facts that change. Prices, plan limits, feature names, dates, anything phrased as "currently". These are the claims that cost you a support ticket when they're wrong.
- Names and permissions. Any customer, partner or employee named or quoted, and whether they agreed to it.
- Promises. Anything that reads as a commitment: delivery times, guarantees, "coming soon".
- The reader's next step. Whether someone who reaches the end knows where to go next, and whether that link works.
- Clarity for an outsider. Internal shorthand, project codenames, steps the writer skipped because they know them by heart.
Tone, word choice and structure are the writer's call unless something is actually wrong. "I would have written it differently" isn't a reason to send it back.
Separate logins, not a shared one
Every person who writes or reviews should have their own account on the blog. With one shared login you can't tell who changed a live post, and removing one person means changing the password for everyone. It also lets you match permissions to the table above: writers draft and submit, approval and publishing stay with the people who answer for what appears on the domain.
The same applies if you draft with an AI assistant connected to the blog. Connect it with a writer's permissions, not an admin's, so it can draft and submit but can't approve its own work.
When you don't need any of this
If one person writes and publishes everything, the review step is that person rereading the post the next morning. If a colleague only reads a post now and then, pasting it into a shared doc for comments is fine. The setup above starts paying off when a second person needs to draft or publish on their own, or when you stop being sure who changed a live post.
Keeping the queue moving
The most common failure isn't a bad review. It's a draft waiting for review with nobody looking at it.
- Agree on a turnaround the reviewer can actually keep, like two working days, and say it out loud. A writer who knows when they'll hear back keeps writing.
- Review in batches, publish on a schedule. Approve three posts in one sitting, then schedule them a week apart. Writing, review and publishing run on their own calendars, and the blog keeps publishing through a launch or a holiday.
I run JustBlogged, a blog platform, and this is the flow we built its team reviews around. It works the same on any platform that gives each person their own login
Top comments (0)