Systems & Processes Archives - Page 4 of 29

SetUpAPageEvenIfItFeelsTooEarly

I’ve tried at least four different ways to onboard writers into Notion, and every time I thought I nailed it — something new broke. One of the most subtle issues was not having a main page ready before I invited them. It doesn’t seem like a big deal at first. You think, Okay, I’ll just bring them into the workspace and then drop in their tasks. But then you watch them click around aimlessly, land in the wrong view, or worse, edit something they have no context for :/

The fix was dumb-simple but absolutely crucial: create a dedicated onboarding page before you even think about inviting someone. Not later. Not once they DM you. Make the page, give it a name like “Start Here,” and link to it from your welcome message. It hit me after realizing one writer had spent twenty minutes clicking around our Projects database trying to find their assignment. “I didn’t know where I was supposed to begin,” she said. Exactly.

So now, I’re using a page with just four core callouts:
– How to communicate
– What to write first
– Where to find assignments
– Tools we use (like Grammarly, Hemingway, etc.)

And at the top, a dumb-looking but very effective big bold line: **Welcome to the blog team. Read this page first.**

This one change genuinely cut our new writer DM traffic in half — because they weren’t confused anymore 🙂

CreateATemplateTheyCanDuplicateSafely

One crazy thing about Notion templates is they are way too easy to break if you’re new. I had one template that was a beautiful layout: checkboxes, example tasks, inline databases organized by status — the whole thing. But someone duplicated it into our main article tracker database instead of their own draft space. Result: they wiped the views for everyone. Nothing got deleted, but the filters were reset, and people saw sixty raw entries in the wrong sorting order. Cue mild panic.

So instead of giving people editing access to the full template from day one, I changed tactics. I made a duplicated version of the writing template inside their personal page. Each new writer gets their own mini workspace, with just this:

– Assigned drafts (a linked database view that’s filtered to show only their stuff)
– A private draft template they can freely duplicate
– A notes section and a place to paste screenshots or inspirations

Crucially: this main template exists in a safe place and is only editable by admins. They can only duplicate it. We call it the “base draft shell.” Geeky, but it works.

Also: don’t forget to instruct them *where* to paste the duplicate. I literally had someone stuck saying, “I duplicated it but I don’t know where I am anymore.” Yep. That’s Notion mood 101 ¯\_(ツ)_/¯

AddInlineNotesNotJustSeparateDocs

One huge mistake I made early was dumping a Notion doc called “Writing Guidelines” into our workspace and thinking that would be enough. It was like seven pages long and covered literally everything. But it turns out most people won’t read something that looks like a college syllabus.

Now, I sprinkle important editorial notes inside the actual templates, like:

“`markdown
Callout block: Remember, headlines should be 70 characters max for SEO.
“`

or:

“`markdown
Comment: Add examples from real products if possible.
“`

The weird psychology here is that people *do* read guidance when it’s baked into the thing they’re actually editing. It feels like part of the process, not homework. Also, color-coded callouts help — blue for SEO stuff, yellow for tone, and red for absolute musts like “don’t publish without approval.”

I think of each template now as not just a mold, but a mini-coach inside the page. That changed everything. Even the newer writers who’ve never blogged before are absorbing the style pretty fast because the help isn’t hidden.

UseCommentThreadsForMicroMidProcessCoaching

There’s that moment when a writer turns in a first draft, and you’re like, uh, did they even read the prompt? Before, I handled this with DMs or long messages outside Notion. But then the context is gone. That’s why comment threads have been a game-changer — especially as inline coaching.

Let’s say a new writer uses very generic phrasing like “maximize engagement.” I’ll highlight that sentence and drop a comment:

> Mind flipping this into a real user action? Like what should someone click or do?

It keeps things constructive without derailing the document. I can also resolve threads as things are fixed, which makes progress clear. Sometimes, I’ll leave a friendly note like “Can you share what tools you used here?” or even “This line made me laugh — keep tone like this!”

The newer folks have actually told me they learn more from these in-context comments than from any style doc. Also: it teaches them how we think *mid-process*. Less guessing = faster revisions.

Don’t forget to turn on notifications for comments though. I missed an entire edit cycle once because I forgot there wasn’t an email ping when someone quietly replied. Oops 😛

AddASandboxPageToReduceWriterAnxiety

When you’re starting out, writing for a new blog can be weirdly intimidating. One writer actually told me, “I felt like I’d break something if I edited the wrong block.” That made me realize most of Notion feels way too collaborative at first. So I made a “sandbox” page.

It’s just an empty draft page where writers can mess around, test the formatting, practice using callouts and headers, even accidentally drag a block into the void — all without consequence. They can paste nonsense, delete whatever, try quotes and code blocks. No one else sees it.

I linked to it clearly in the onboarding doc: “Use this sandbox to learn the Notion editor before you write your first draft.”

Fun side effect: they ask *way* fewer how-do-I-make questions. Also, you can pop into their sandbox once in a while to see where they’re tripping up. If their entire sandbox is just text in one big paragraph… yeah, time to nudge them on headers.

MakeAnFAQThatOnlyAnswersWhatTheyActuallyAsk

So I had this big idea for an onboarding FAQ. I made it look official. It had sections like “Formatting,” “Publishing Pipeline,” and even “Style and Voice.” I felt smart. Then three people messaged me with the same question that wasn’t even on the doc: “How do I know when I’m done editing?”

That’s when I threw out half the FAQ and started over. The new one is now called “Stuff Writers Actually Ask” and it’s got literal questions with casual answers. Here’s a snapshot:

Now people *actually read it*. Moral of the story: don’t make the doc you think sounds professional. Make the doc that saves you the most repeated DMs.

SendADirectionlessDMThenMakeItIntoProcess

Every once in a while, something goes wrong and you end up sending a ping like:

> Hey, can you rename the SEO title? Our CMS cuts it off on mobile.

Then you realize — huh, that’s not in any of our onboarding. You’ve discovered a new invisible rule. Congrats. Now paste it into your shared process or coding template.

I do this by having a “Process Draft” page open in a pinned tab all week. It’s not for publishing — it’s just where I dump stuff like:

> – New rule: headers must be capitalized (Title Case)
> – Clarify meta description needs punchy first sentence
> – Add line to template: call out tools used in article

Once this page fills up with 5–6 rules, I roll them into the base writing template or writer onboarding doc. This method has saved me from feeling like I’m rewriting the same feedback every Thursday.

Also: writers feel way more confident when your systems improve *while* they’re onboard. It shows you’re paying attention.

IfYouChangeADatabaseFieldTellEveryoneImmediately

I wish I could end without saying this, but here we are. The biggest workflow blow-up came from renaming a field in our main Articles database — literally just changed “Outline Status” to “Draft Progress” because it sounded more accurate.

I thought, no big deal. Same field, right? Except auto-filters broke in three linked databases. The dropdown options disappeared from templates. Writers stopped seeing their expected fields entirely. One writer messaged me, “Something’s missing — I don’t have a progress bar anymore.” Yep. It was all based on that original name.

Solution? Never rename critical fields unless you check:
– Templates that link to that property still work
– Filters using that field haven’t broken silently
– Writers’ filtered databases still load properly

Now I use a big red callout at the top of our Admin Page that says:

> If you rename a core database field, ping the team **before** saving. Things can and will randomly break with no warning.

And unfortunately, that warning is pinned for life 🙃