Notion is the best place to write your agency's playbook and the worst place to run client work through. The two jobs look similar; they aren't.
The honest version
I love Notion. The Gravixar team uses Notion. I will write your agency's playbook in Notion and tell you to keep using it for the team wiki. None of that is the question.
The question is whether Notion is the right tool for the part of your work your clients see, and the answer is almost always no, and the cost of pretending otherwise is real.
Where Notion is the right tool
Internal documentation. Playbooks. Knowledge base. Decision logs. Onboarding runbooks. Process diagrams. Project notes that don't need state-machine semantics. Notion is category-leading at all of this and a custom build can't catch up cheaply.
Cross-team referenceability. Notion's linking model is good and its search works. For team-internal knowledge work, the friction is genuinely low.
The team wiki. Just keep using Notion for the team wiki.
Where Notion breaks
Client-facing portals. The moment a client logs in, Notion's model fights you on three axes:
- Brand. Your client should feel like they're in your product, not someone else's wiki. Super and other Notion-as-website tools approximate this; the approximation is the giveaway. Pixel-perfect branded surfaces aren't where Notion is invested.
- State. Notion has tags and statuses, not state machines. A "status: approved" tag is a comment, not an enforcement. There's no audit row when it changes. There's no notification cascade. There's no scope-lock semantics. You can paper over this with Notion automations, and they break.
- Audit. Compliance retention, who-changed-what, safe-restore on critical fields. Notion has a version history. It does not have an audit log in any sense a finance or legal team would accept.
The "Notion plus a wiki of how to use Notion" pattern. The moment your team needs internal docs to explain the tool, your tool isn't the tool. It's a thing you've built, badly, in a tool that wasn't designed for it.
The seat-cost arithmetic at scale. Notion is cheap per seat, but Notion plus Super plus Zapier plus the Notion API integration to your accounting tool plus the maintenance time totals up. By month nine you've built a brittle stack on top of a doc tool.
What custom looks like alongside Notion
The agency portal I built for a 4-year client is the production version of this division. Notion is their team wiki; the portal is where client work runs. Different tools for different jobs.
bs-hub handles:
- The 12-state inquiry funnel with hard transitions (no implicit status)
- The review state machine on every deliverable, with audit rows on every transition
- AI intake (adaptive questions, brand brief generated from the client's website)
- The cancellation flow that keeps the row, deletes tasks, and issues a credit ledger entry rather than hard-deleting
- The daily security-watch cron sweeping for anomalies
- Two-tier audit retention (seven-year contract, one-year operational)
Notion handles:
- Team playbooks
- The brand book
- The "how we work" docs that get sent to new hires
- Long-form strategy notes that don't need to be enforced
- The team wiki
The split works because each tool is doing what it's actually good at.
How to decide
Run this in order:
- List the things in your Notion that have a status field. Anything with "Status: approved / pending / sent / etc." is a candidate for state-machine treatment elsewhere. Notion is the wrong tool for status-driven workflows.
- Check whether you have docs explaining your Notion setup. If you have any, your Notion has stopped being a tool and started being a system you've built. That's the line.
- Ask what your client sees. If a client logs into Notion (via Super or invite-share), you're past the right line. Notion-as-portal is a workaround, not a solution.
- Run the seat-cost-plus-time arithmetic. Notion plus Super plus Zapier plus maintenance hours per quarter. Total it. Compare against a custom retainer.
If you've outgrown Notion-as-portal but you don't want to lose Notion-as-wiki, book a call. The custom build I do is designed to live alongside Notion, not replace it.
FAQ
- Why isn't Notion enough for client portals?
- Notion is a document tool. Client portals need state machines (a deliverable in DRAFT is not the same as one in CLIENT_APPROVED, and the difference must be enforced not just typed), audit trails (who approved what when), and branded surfaces (clients shouldn't feel like they're inside someone else's wiki). Notion gives you none of these natively. Workarounds exist (Super, Notion API, embeds) but they're expensive in time and brittle in production.
- Can a custom portal replace Notion entirely?
- It shouldn't. Keep Notion for internal documentation and playbooks. Replace it only for the client-facing surfaces and the workflow that needs state-machine semantics. The two tools live alongside each other. Notion is the team wiki. The custom portal is the production system.
- What's the biggest mistake agencies make with Notion as a client portal?
- Building 30 Notion pages with custom statuses, then maintaining a Notion-ops doc explaining how the statuses work. The Notion-ops doc is the tell. The moment you need a doc to explain your tool, your tool isn't the tool.
- How does the custom portal handle review handoffs that Notion can't?
- Through an explicit state machine. A deliverable transitions DRAFT → SUBMITTED_FOR_INTERNAL → INTERNAL_APPROVED → SUBMITTED_FOR_CLIENT → CLIENT_APPROVED with a CLIENT_REVISION_REQUESTED branch back into the loop. Each transition is a single function with explicit pre-conditions and side-effects (notifications, emails, audit rows). No state is implicit. No admin can flip the status by editing a free-text field.
- Will Notion's AI features eventually solve this?
- No. Notion AI is good at what Notion is good at (summarizing pages, drafting copy in-doc) and it's the wrong category for what client portals need (state machines, audit, multi-step approval flows). The category mismatch isn't a feature gap, it's a tool-purpose gap.