Client Portal

A branded Notion page the client opens with one link. Shows only their engagement: deliverables, current sprint, decisions, and an embedded loom for the last status update. Updates the moment the team logs work internally. The client stops asking "what is happening this week" because the answer is always on the page.

Separate client portals drift from internal workspaces. Teams copy-paste status updates into a client-facing doc, and by month two the two versions disagree. This template keeps the portal and the internal workspace as the same database with different permissions. One source, one update, two readers. The client sees a filtered view. The team sees everything.

No new database. Four views on your existing project and task databases, filtered to the client's engagement. Views: This sprint, Shipped this month, Decisions log, Upcoming milestones. Plus one shared landing page per client with brand colours, a Loom embed, and the four views in sequence.

The account lead logs work in the internal database as normal. The client opens one share link, lands on their portal page, sees the four filtered views. Every Friday, a one-minute Loom gets pasted into the Status block on the portal page. The client watches it on Monday morning.

The first failure is share links that silently expire. The client opens the portal three months in, gets a 404, emails a complaint. Fix: every portal carries a freshness monitor. A weekly flow pings each share link. Any 404 or expired auth pings the account manager in Slack.

The second failure is portals that show too much. Internal notes, team Slack pulls, half-written drafts. Fix: the portal is a filtered view with a strict allow-list. New properties default to hidden. Exposing a new column is a conscious step, not a default.