Notion Office Hours: Managing Client Projects ⌨️
Based on Notion's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.
Use a master tasks database for internal planning, then maintain client-specific mirrored task views so each client portal shows only relevant work.
Briefing
A freelancer’s client-management setup in Notion turns weekly progress into a client-facing “portal” without giving clients access to sensitive internal work. The core move is a mirrored task system: a master tasks database powers the freelancer’s workflow, while each client gets a separate, public (unlisted) page that shows only that client’s completed and upcoming deliverables—updated daily by moving tasks into the right client-specific database.
The workflow starts with a weekly planner view that feels like a bullet journal, but is backed by databases. Instead of manually tracking tasks in separate tools, tasks live in a central database and appear through filtered views such as “this week’s tasks,” “next week’s stuff,” and “overdue tasks.” At the end of each day, a “power down” routine helps close open loops: completed items get archived or moved forward, call notes are logged, and tasks are reassigned so the client-facing view stays accurate.
When a new client is onboarded, the client record becomes the anchor for everything else: formulas track relationship length (e.g., “lifetime months” for retainer clients), and linked views pull in the projects and tasks relevant to that client. The client portal itself is the centerpiece. It’s a public Notion page with no login requirement, designed so clients can see “what’s upcoming,” “what’s been done,” and the links to deliverables—without needing to search email threads or ask for documents again. Because the portal is a copy/mirror of the task structure (but not the entire internal schema), the freelancer can hide internal projects and sensitive details (like personal home projects) while still showing progress clearly.
A key implementation detail addresses permissions and privacy. Notion permissions work at the page level, and sharing a filtered view of a database can still expose more than intended if clients can navigate “up” the hierarchy. The solution is to give clients their own task database (or a client-specific copy) that is unlinked from internal projects, so clients can’t traverse to other clients’ work. This also reduces clutter and keeps the portal fast and focused.
Beyond tasks, the setup expands into a broader client experience: inspiration “swipe files,” onboarding resources, templates for recurring work, and embedded case studies and recommended tools. The freelancer also automates weekly delivery of the portal link using ConvertKit, storing the Notion share link in a custom field so clients receive updates automatically before scheduled calls. For collaboration, some clients are invited as collaborators in their own Notion workspaces, while others receive only the public portal—depending on how much interaction they want.
The overall takeaway is that Notion becomes a single source of truth for projects, deliverables, and communication—reducing context switching and email hunting—while still protecting internal information through database mirroring, careful linking, and page-level permissions.
Cornell Notes
Client project management in Notion is built around a master task database plus client-specific “mirrors.” The freelancer maintains weekly planning and daily “power down” routines, then moves completed work into the correct client database so progress updates stay current. Each client gets a public (unlisted) portal page with no login, showing only that client’s tasks, deliverables, and links—so clients can check status without emailing for documents. Privacy is handled by avoiding permission pitfalls: clients shouldn’t be able to navigate from a shared/filtered view into other projects or other clients’ data. The system also scales into onboarding resources, swipe-file inspiration, and automated weekly email delivery via ConvertKit.
How does the setup keep client visibility high while protecting internal or unrelated work?
What does “power down” mean in practice, and why does it matter for client updates?
How are weekly tasks organized so they feel like a bullet journal but remain database-driven?
What’s the role of formulas and properties in client records?
How does automation reduce weekly admin work for client communication?
How does the system handle recurring work and ongoing maintenance versus one-off projects?
Review Questions
- What design choice prevents clients from navigating from their portal into other clients’ tasks or internal projects?
- How would you adapt the mirrored task approach if you wanted different clients to see different deliverable types (e.g., only invoices, not meeting notes)?
- Where in the workflow would you place daily task-moving so the client portal stays accurate without extra manual updates?
Key Points
- 1
Use a master tasks database for internal planning, then maintain client-specific mirrored task views so each client portal shows only relevant work.
- 2
Update client portals daily by moving completed tasks into the correct client database, supported by a consistent end-of-day “power down” routine.
- 3
Avoid permission pitfalls by not exposing the master task database in a way that lets clients navigate to other records; use page-level sharing and unlinked client task structures.
- 4
Build a weekly planner using filtered database views so the interface stays simple while the underlying data remains comprehensive.
- 5
Automate weekly client notifications by embedding the Notion share link into ConvertKit custom fields and sending it on a schedule.
- 6
Expand beyond tasks with client-facing resources—deliverables links, onboarding materials, swipe-file inspiration, and case studies—so the portal becomes a single source of truth.
- 7
Treat recurring work as repeatable project templates and re-create task sets each cycle when true recurring scheduling isn’t sufficient.