The last time a client handed me keys to their WordPress install—buried under five security plugins, a custom admin theme, and something called “LiveBlog Pro?”—I open the editor and immediately see this gem: custom_post_type => 'pressrelease_duplicated_final_FIXED'. That’s when I remembered they had three different writers sharing credentials on a single author user. Not three roles—no. Literally all posting as “admin.”
Here’s what broke first: internal drafts overwritten without warning. Chrome extension autosave gadgets (I’m guilty) would clobber half-typed copy from someone writing in another tab. The kicker? There’s no version tracking outside of the public revision log—which no one looked at unless something exploded on the homepage.
If you’re still using emailed Google Docs and shared logins for blog management, Cloudflare is going to love you for it—your cookies are basically open season. SSO isn’t fancy; it’s foundational. Get everyone their own role. And the minute someone says “let’s put the editorial calendar in Excel,” take the day off instead.
Draft Management in Ghost Isn’t Actually Meant for Teams
So, Ghost. Beautiful for publishing, yes. Not great when you want more than one person touching a draft. Ghost uses the concept of ownership for posts. Only the original author (or an admin) can make meaningful edits. Collaboration exists, kind of, via shared access—but you’ll be playing content hot potato by copying/pasting between drafts with cryptic names like “Q2 editorial – FINAL for real – (editor edit)”.
One time, I pushed an edit live thinking I was in staging. Turns out the other editor had changed the slug back to the original, which had been published two weeks before. So yes: our updated Black Friday post went live in April, with last year’s referral codes. Ghost doesn’t guard against this unless you’re paying for the enterprise tier with staging nodes, which is overkill for 90% of us.
There’s no true collaborative mode either. Forget commenting inline. Most teams end up bolting on Google Docs or Notion just for back-and-forth drafts, then dumping final copy into Ghost. That’s fine if you’re disciplined—horrible if you’re juggling 17 drafts, two of which are half-mapped A/B tests wrapped in a launch blog timeline that no one wrote down.
When Notion Makes Writers Lazy—And Chaos Ensues
I love Notion. I also deeply resent what it does to editorial review when there are no rules.
Last summer I walked into a client project where their entire blog pipeline lived in one Notion board titled “Content Garden .” It had three dozen posts in “Ready to Review,” but zero defined process for who did what. The marketing lead claimed everyone knew the flow. I DM’d two writers and a designer—got three different answers on what “Schedule” meant.
Notion will let you put status fields, checklists, and ownership columns on anything. But it won’t enforce workflow. Without automation or at least a webhook into whatever CMS you’re using, it’s just a slightly nicer spreadsheet pretending to be a blog engine.
Define what “Ready for Review” really means (copy-edited? queued for publication?)
Use comments, not updates in the body copy, to suggest changes
Tag actual humans for each phase (draft, edit, upload, SEO, QA)
Add due dates linked to the publication date, not writing start
Store visual assets right in the card, not floating in a Google Drive abyss
The Notion API helps if you want to sync this to scheduling tools, but again, hack-job city unless you’re using third-party integrations or building a ton of scripts on top.
Figma for Banners: Death by Download
Okay this one hurts a little. I still have a folder on my desktop literally called “blog assets final-final.” There’s like fifteen versions of the same header graphic, each with a slightly different shade of purple or one changed icon because the PM decided people don’t click on green anymore.
The actual problem? Figma’s lack of integration with content publishing flows. There’s no simple pipeline from a design mockup to a media library that works across CMS platforms. Unless you’re on a pricey plan and using Figma Dev Mode (which feels like overkill for one .jpg), your designers are manually exporting JPEGs, then shuttling them across Slack or links, only for someone to reupload in WordPress manually. Labels are lost. Original sizes overwritten. Alt text? Nonexistent until someone yells accessibility.
To make this less dumb, I tried using Figma’s API once with a webhook to our image CDN to push hero banners into a flat structure by blog slug. Didn’t work. Turns out Figma access tokens expire faster than our editor’s patience. Didn’t realize until I saw this in my logs:
{
"message": "Token has expired",
"error": true
}
So now we’re back to dragging and dropping, but at least we bake filenames directly into the editorial board. Naming things solves 90% of sharing problems you didn’t know you had.
Asana vs Trello vs Jira for Blog Coordination: Pick One, Please
Why is every marketing team convinced their project tool is working great when it’s the third one they’ve used this year? I had one client post their actual blog deadlines in Jira tickets under the tech team’s backlog. Another time, a Trello board collapsed entirely when someone moved it to a “Done-done” status I couldn’t even see because of custom permissions.
If your writers are in Asana while your editors live in Trello, you’re syncing nothing. Blog launches get lost between integrations. Even the Slack notifications are useless once they come from five different bots.
Best result I ever had? Using Trello, but only after we forced these rules:
Only one card per draft—no duplicating for edits
Status labels in color, not text (saves brain time)
Google Drive folder IDs inside the card descriptions
Due date = live date, not review target
You move your own stuff—no one else touches your pipeline
One person with authority to archive anything
It takes a mild dictatorship to make a blog workflow operate. No shame in that.
Slack Makes Everything Immediate and Nothing Official
I once published a paragraph with the sentence “Update with correct launch link??” because that had been the message in Slack, and nobody ever followed up. Obviously, we fixed it later. But I had already tweeted the blog link, and the link appeared in newsletters. No one noticed for two days. It lives eternally in scrapers now.
Slack creates a false sense of approval. Someone giving you a “Looks good ” isn’t the same as signing off. Threads disappear. Old assets vanish behind expiring links. And don’t get me started on backscrolling 50 messages just to find whether a headline got A/B approval or not.
Your editor shouldn’t be chasing emoji reactions to confirm content edits. Use apps or threads, sure, but every actionable task—”ready to upload,” “image needed,” “waiting for legal”—needs to stick in an actual project tool, or it’ll vanish in the real-time fog.
OneDrive Sync Conflicts Are the Silent Killer of Final Copy
I know, I know. Your enterprise client wants to use Microsoft 365 for everything. Which means blog drafts live in Word docs, synced via OneDrive, probably versioned inside some “Teams Sharepoint” hybrid folder with three nested permissions. It’s fine until you experience your first real sync conflict.
I opened a doc once and saw both my version and the previous editor’s somehow blended into one paragraph with broken formatting and both timestamps showing “saved a few seconds ago.” OneDrive doesn’t warn you about silent merges when you’re working offline momentarily. It gamifies data loss.
You may notice random spacing issues, footnotes moved arbitrarily, or header stylings wiped entirely. And in late-stage blog review? Hard to notice. Often gets caught by accident, like when pushing the preview live and titles look like someone copy-pasted from Outlook.
If your process involves Word syncing, do this at minimum:
Avoid co-editing in the same file unless in-browser
Set final drafts to view-only once approved
Use export-to-PDF-before-upload as a sanity check
Keep a backup in Google Docs, untouched, just in case
And maybe stop pretending Word comments are collaborative. They’re barely legible on mobile anyway.
Publishing Automation: Zapier, Make, and Wrong Tags Syndrome
Once, I set up a very neat Make automation (used to be Integromat, RIP) to publish Medium blog posts directly from a Notion table. It pulled in title, body copy, thumbnail URL, and scheduled time. The tag field? Pulled from a single-select labeled “Category.” Everything worked until I noticed every article was using the same placeholder tag—”To-Update”—on Medium. For a month.
The automation didn’t break; it just never got re-tested after new categories were added. Turns out Medium silently ignores tags it doesn’t recognize in its API input and publishes the post anyway. No warning. So our SEO tagging vanished invisibly—and was never logged anywhere because Make said: “200 OK.”
This is a recurring problem when you bolt together tools with assumed field mapping. Even in Zapier, if you change a field name, the automation can continue running quietly while feeding junk data. Blog content may still go live—but it’s malformed, missing key metadata, or worse—assigned to the wrong author. I’ve had three posts accidentally published under our CTO’s name because of a field mismatch in a webhook.
Which is how you get posts live with no visibility unless someone manually checks the front-end tags afterward. And let me tell you—most won’t. They’re on to the next post already, assuming automation means no babysitting required.
