At first, “put it in Notion” feels like relief. A client brief lives next to the timeline, the meeting notes, the creative review checklist. Then the team grows, work speeds up, and someone duplicates the “Projects” database to “keep it clean.” Another person makes a new client page because they can’t find the old one. Nobody’s doing anything wrong—they’re trying to ship work.
The tell is the same question showing up in different forms: “Where’s the latest version?” You see it in Slack pings, in producers rebuilding a status view, in account leads keeping private trackers “just in case.” Notion isn’t failing. The setup is missing simple rules about what counts, who owns it, and what everyone should ignore.
Once that slide starts, adding more pages usually makes it worse. The fix is not more structure—it’s choosing the few places that are allowed to be true, and designing everything else to point back to them.
Lesson 1: If you can’t name the source of truth, you don’t have one
In a busy agency, the same “fact” starts living in three places: a client page, a project card, and someone’s weekly status note. Each one looks reasonable in the moment. Then a strategist updates the scope in the client page, a PM updates the due date in the project view, and the account lead screenshots the “latest” for a client email. Now your team isn’t arguing about work—they’re arguing about which version counts.
A source of truth is only real if you can answer, fast, “Where does this get updated?” For clients, that might be one Clients database record per client. For active work, it’s one Projects database record per project. Notes, dashboards, and doc pages can summarize, but they should never be the place someone edits core fields like status, owner, next milestone, or deliverables.
The friction is that a single source can feel slower at first, because it forces everyone through one door. Make it worth it: keep the record small, make the key fields obvious, and put edit links everywhere people already work.
Lesson 2: The database you duplicate today becomes the reporting nightmare you live with later
That “one door” is where duplication usually sneaks in. A PM needs a cleaner view for one big client, so they duplicate the Projects database “just for this account.” Someone else duplicates Deliverables to match a new process. A month later, leadership asks a simple question—what’s on track, what’s stuck, what’s at risk—and the answer depends on which database you look at.
Duplication feels fast because it avoids negotiation. It also breaks rollups, splits history, and forces you to reconcile statuses by hand. If Project A exists in two places, you will eventually update one and forget the other. Reporting becomes a weekly cleanup job instead of a byproduct of doing the work.
Keep one Projects database and one Deliverables database, then solve “clean view” with filtered views, saved views, and templates that pre-fill the right filters. If a client truly needs separation, accept the trade-off: you’re buying easier navigation at the cost of harder reporting.
Lesson 3: Templates don’t fix inconsistency—ownership and defaults do
After you stop duplicating databases, inconsistency usually shows up a different way: the “same” project launches with three different page layouts, different statuses, and a random mix of fields filled in. Someone says, “Let’s make better templates.” You do. A week later, half the team still starts from an old project, or they copy a page that “worked last time,” and the drift continues.
Templates help when people already agree on what “done right” looks like. They don’t create that agreement. Ownership does. Pick an owner for each core object (Clients, Projects, Deliverables) and make them responsible for the defaults: required properties, allowed statuses, naming rules, and what gets created when someone clicks “New.” If the owner can’t explain why a field exists, it shouldn’t be there.
The trade-off is real: tighter defaults can feel bossy, especially to seniors who have their own way of working. Make it practical. If a project can’t be created without an owner, a start date, and a next milestone, your dashboards stop being guesses—and your handoffs stop depending on memory.
Lesson 4: When permissions feel like friction, people route around the system
That “bossy” feeling gets louder when someone hits a permission wall mid-flight. An account lead can’t update a status, a producer can’t add a deliverable, or a freelancer can’t even see the brief. The work still has to move, so people do what works: they start a side doc, paste the “real” info into Slack, or keep a private tracker they control.
Most permission problems come from trying to protect everything instead of protecting the few fields that actually matter. Lock down the core databases and templates to a small ops/admin group, but make the day-to-day updates easy for the people doing the work. If someone owns a project, they should be able to change its status and next milestone without asking you.
The trade-off is exposure. More editors means more chances for messy data. Solve it with clear roles and “safe” properties (status, owner, due dates) rather than blocking edits entirely, because blocked edits don’t stop change—they just push it outside Notion.
Lesson 5: Your dashboards aren’t the product—your handoffs are
Once people can edit the fields they need, the next failure looks “clean” on the surface: beautiful dashboards, terrible follow-through. A PM builds an “At Risk” view, leads love it, and then a project still stalls because nobody knows what to do when a card shows up there. The dashboard wasn’t wrong. It just didn’t complete the last mile.
Dashboards are only useful if they trigger a handoff. If a deliverable flips to “Needs Review,” who gets pinged, where do they leave feedback, and what changes the status back? If a project goes “Blocked,” what’s the required next step—tag an owner, log the blocker, set a next check-in date? Put those actions inside the workflow: buttons, required fields, and a single “handoff” section in the template that people actually use.
The friction is that tighter handoffs can feel like extra steps. But that’s exactly where the work stops slipping through cracks—and where the last 20% of adoption gets decided.
Lesson 6: Adoption isn’t training; it’s removing the last 20% of excuses
That “extra steps” feeling is where adoption usually dies. You can run a solid training, share a clean Loom, and still watch people fall back to Slack threads and personal checklists the moment they’re under deadline. It’s not because they didn’t understand Notion. It’s because Notion asked for one more click, one more field, one more decision than their day could afford.
So hunt excuses, not knowledge gaps. If a producer has to remember which view to use, make one default “My Active Projects” view and pin it. If a project template asks for six fields up front, cut it to the three that make handoffs work, and let the rest fill in later. If people forget to update status, add a recurring “Friday 10-minute update” ritual with a single view link, and make it part of how you close the week.
The trade-off is that you’ll standardize around what’s easiest, not what’s most detailed. That’s fine—because once the system gets used every day, you can tighten it without people routing around it.
What a “maintainable” Notion setup looks like six months later
Six months later, the workspace feels boring in the best way: one Clients database, one Projects database, one Deliverables database—and most people live in a handful of saved views. New work starts from one current template, so names, statuses, and required fields land the same way without reminders. When someone asks “where’s the latest,” the answer is a link, not a debate.
The friction doesn’t disappear; it shows up as governance. Someone has to say “no” to new fields, new statuses, and “quick duplicate” requests, or reporting degrades again. The payoff is that handoffs run on defaults: review requests go to the right person, blocked work has an owner and next step, and leadership gets numbers without cleanup.
