Short answer: Build client portals from a template with a fixed structure — status summary, deliverables, timeline, shared documents, and contacts — generated per client from a database. Share individual pages, never the parent workspace, and audit permissions on a schedule. The maintenance burden, not the build, is what determines whether portals survive.
What a client portal is actually for
Two jobs: reducing the number of times a client has to ask where things are, and creating a single agreed record of what was decided. If it doesn't do both, it's a shared folder with extra steps.
That framing determines the content. A portal should answer the questions clients actually ask — what's the status, what do you need from me, where's that document, when is the next thing — rather than showcasing project management.
The structure that works
One page per client, generated from a template, containing in order:
- Status at a glance. Current phase, next milestone, anything awaiting the client. Top of page, three lines, updated weekly.
- Waiting on you. An explicit list of outstanding client actions with dates. This section alone eliminates most chase emails.
- Deliverables. What's been produced, with links and dates. The permanent record.
- Timeline. Key dates, past and upcoming.
- Decisions log. What was agreed, when, and by whom. Dull to maintain, invaluable when a scope disagreement surfaces in month four.
- Documents. Contract, brief, specifications — linked, not duplicated.
- Contacts. Who to ask about what, on both sides.
Permissions: the part that carries risk
Notion sharing is inherited, so a mistake here exposes more than the page in question. The rules:
- Client portals live in their own top-level area, not nested inside an internal workspace.
- Share the specific client page with that client's guests. Never share a parent containing all clients.
- Prefer guest access over public links for anything commercially sensitive. Public links are unlisted, not secure.
- Watch linked databases. A linked view of an internal database may expose more records than intended. Test by viewing as a guest before sharing.
- Audit quarterly. Remove guests from finished engagements. This is the step everyone skips.
Client portals typically contain personal data, so they belong in your record of processing activities, with retention decided in advance rather than by accident.
Keeping them maintainable
Portals die of staleness. A portal showing last month's status is worse than none, because it teaches the client not to look. Three defences:
- Generate from a database so structure is consistent and you can see, in one view, when each was last updated.
- Automate what can be automated — status, dates and deliverable lists pulled from your operational system rather than typed.
- Make updating part of the weekly rhythm, owned by a named person. Fifteen minutes a week across a portfolio.
When Notion isn't the right tool
If clients need to interact with structured data — submitting records, filtering large datasets, uploading in volume — an Airtable interface or a purpose-built portal fits better. Notion excels at readable, document-shaped client communication and is mediocre at client data entry.
Frequently asked questions
Do clients need a Notion account?
Guests need a free account. Public links avoid that but remove access control, which is rarely the right trade for client work.
How many portals can one person maintain?
With generation and automation in place, twenty to thirty. Fully manual, about five before they start going stale.
What about white-labelling?
Notion's branding options are limited on standard plans. If brand presentation matters commercially, look at a dedicated portal tool.
We build client-facing systems that stay current without becoming a job. See examples.
