Tygart Media

Tag: Notion For Agencies

  • Notion for Multi-Client Content Operations: The Pipeline That Manages Dozens of WordPress Sites

    Running a content pipeline across twenty-plus WordPress sites from a single Notion workspace is not the obvious use case Notion was designed for. It’s a use case we built — deliberately, iteratively, over the course of operating a content agency where the volume of work made ad hoc management impossible.

    The result is a system where every piece of content, across every client site, moves through a defined sequence from brief to published inside one Notion database. Nothing publishes without a record. Nothing falls through the cracks between clients. The status of the entire operation is visible in a single filtered view.

    Here’s how that pipeline works.

    What is a Notion content pipeline for multi-site operations? A multi-site content pipeline in Notion is a single Content Pipeline database where every piece of content across every client site is tracked through a defined status sequence — Brief, Draft, Optimized, Review, Scheduled, Published — with each record tagged to its client, target site, and publication date. One database, filtered views per client, full operational visibility across all sites simultaneously.

    Why One Database for All Sites

    The instinct is to give each client their own content tracker. Separate pages, separate databases, separate calendars. This feels organized. In practice it means your Monday morning question — “what’s publishing this week?” — requires opening twenty separate databases and manually compiling the answer.

    One database with entity-level partitioning answers that question in a single filtered view sorted by publication date. Every client’s content in motion, every publication date, every status, visible simultaneously. Add a filter for one client and you have their isolated view. Remove the filter and you have the full operational picture.

    The cognitive shift required: stop thinking about the database as belonging to a client and start thinking about the client tag as a property of the record. The database belongs to the operation. The records belong to clients.

    The Status Sequence

    Every content record moves through the same six stages regardless of client or content type: Brief → Draft → Optimized → Review → Scheduled → Published. Each stage transition has a defined meaning and, for key transitions, a quality check.

    Brief: The content concept exists. Target keyword identified, angle defined, target site confirmed. Not yet written.

    Draft: Written. Not yet optimized. Word count and rough structure in place.

    Optimized: SEO pass complete. Title, meta description, slug, heading structure, internal links reviewed and adjusted. AEO and GEO passes applied if applicable. Schema injected.

    Review: Content quality gate passed. Ready for final check before scheduling. This is the stage where anything that shouldn’t publish gets caught.

    Scheduled: Publication date set. Post exists in WordPress as a draft or scheduled post. Date confirmed in the database record.

    Published: Live. URL confirmed. Post ID logged in the database record for future reference.

    The Quality Gate as a Pipeline Stage

    The transition from Optimized to Review is gated by a content quality check — a scan for unsourced statistical claims, fabricated specifics, and cross-client content contamination. The contamination check matters specifically for multi-site operations: content written for one client’s niche should never reference another client’s brand, geography, or specific context.

    Running this check as a formal pipeline stage rather than an informal pre-publish habit is what makes it reliable at scale. When publishing volume is high, informal checks get skipped. A formal stage in the status sequence means the check is either done or the content doesn’t advance. There’s no middle ground where it was probably fine.

    What Notion Tracks Per Record

    Each content pipeline record carries: the content title, the client entity tag, the target site URL, the target keyword, the content type, word count, the assigned writer if applicable, the publication date, the WordPress post ID once published, and the current status. Relation fields link the record to the client’s CRM entry and to the associated task in the Master Actions database.

    The WordPress post ID field is the detail most content trackers skip. With the post ID logged, finding the exact WordPress record for any piece of content is a direct lookup rather than a search. For a pipeline publishing hundreds of articles across dozens of sites, that lookup speed matters every week.

    The Weekly Content Review

    Every Monday, one database view answers the primary operational question for the week: a filter showing all records with a publication date in the next seven days, sorted by date, across all clients. This view drives the week’s content priorities — whatever needs to move from its current stage to Published by the end of the week gets the first attention.

    A second view shows all records stuck in the same status for more than five days. Stale records indicate a bottleneck — something that was supposed to move and didn’t. Finding and clearing those bottlenecks is the second priority of the weekly review.

    Both views take under a minute to read. The decisions they drive take longer. But the information is current, complete, and doesn’t require any compilation — it’s all in the database, updated as work happens.

    How Claude Plugs Into the Pipeline

    The content pipeline database is one of the primary interfaces between Notion and Claude in our operation. Claude reads the pipeline to understand what’s in progress, writes new records when content is created, updates status as work advances, and logs the WordPress post ID when publication is confirmed.

    This write-back capability — Claude updating the Notion database directly via MCP rather than requiring a manual logging step — is what keeps the pipeline current without adding overhead. The database is accurate because updating it is part of the work, not a separate step after the work is done.

    Want this pipeline built for your content operation?

    We build multi-site content pipelines in Notion — the database architecture, the quality gate process, and the Claude integration that keeps it current automatically.

    Tygart Media runs this pipeline live across a large portfolio of client sites. We know what the architecture requires at real operating scale.

    See what we build →

    Frequently Asked Questions

    How do you prevent content written for one client from appearing on another client’s site?

    Two mechanisms. First, every content record is tagged with the client entity at creation — the tag makes it explicit which client owns the content before a word is written. Second, a content quality gate scans every piece for cross-client contamination before it advances to the Review stage. Content referencing geography, brands, or context specific to another client gets flagged and held before it reaches WordPress.

    What happens when content is published — how does the pipeline stay accurate?

    When content publishes, the record status updates to Published and the WordPress post ID gets logged in the database record. In our operation, Claude handles this update directly via Notion MCP as part of the publishing workflow. For operations without that automation, a daily or weekly manual update pass keeps the pipeline accurate. The key is building the update into the publishing workflow rather than treating it as optional.

    Can Notion’s content pipeline replace a dedicated editorial calendar tool?

    For most content agencies, yes. Notion’s calendar view applied to the content pipeline database provides the same visual publication scheduling that dedicated editorial calendar tools offer, plus the full database functionality — filtering by client, sorting by status, tracking by keyword — that standalone calendar tools lack. The combination is more capable than purpose-built tools for agencies already running Notion as their operational backbone.

  • Best Notion Templates for Agencies (And Why We Don’t Use Any)

    The best Notion templates for agencies are the ones you don’t use. That’s not a paradox — it’s a description of how good templates actually work. A well-built template gives you a starting architecture and then gets out of the way. You customize it to your operation, build your workflows on top of it, and within a few weeks the template’s DNA is so thoroughly mixed with your own choices that you’d struggle to separate them.

    What doesn’t work: downloading a template, opening it, feeling briefly impressed by how organized it looks, and then abandoning it because it wasn’t built for how you actually work.

    Here’s an honest look at the Notion template landscape for agencies — what’s worth starting from, and why we ultimately stopped using templates entirely.

    What makes a Notion template good for agency use? A good agency Notion template provides a functional database architecture with relation properties already configured, views set up for common operational questions, and a structure that maps to real agency workflows — client management, content production, project tracking — rather than generic productivity advice. The best templates are opinionated enough to be useful and flexible enough to be adapted.

    What to Look For in an Agency Template

    Before evaluating any specific template, the criteria matter. For agency use, a template is only worth your time if it has: a relational database structure (not just pages and folders), views configured for operational questions you actually need to answer, and a client or project partitioning system that keeps work separated without requiring duplicate databases.

    Templates that fail these criteria — pretty page layouts with no relational structure, task lists without database properties, client folders instead of a filtered single database — will not survive contact with a real agency workflow. They look organized in screenshots and feel hollow in practice.

    The Template Categories Worth Knowing

    Agency OS templates. Comprehensive workspace setups that attempt to cover the full agency operation — clients, projects, tasks, content, invoicing. The good ones from the Notion template gallery and creators like Thomas Frank establish the right relational architecture. The risk: they’re built for a hypothetical agency, not yours. Plan to spend as much time customizing as you would have spent building from a good foundation.

    Content pipeline templates. Focused specifically on editorial and content workflows — brief to publish status sequences, content calendar views, keyword tracking. More focused than full agency OS templates and often more immediately useful for content-specific operations. The best ones have proper database properties and status sequences; the worst are glorified spreadsheets with a calendar view.

    CRM templates. Client and contact management systems. Useful as a starting point for the relationship management layer, though most underestimate how important the relation properties connecting contacts to deals and projects are. A CRM template without proper relations is a contact list with extra steps.

    Client portal templates. Starting points for client-facing portal pages. Most are structurally sound but generic — they need significant customization to reflect your specific deliverable types, communication style, and client relationship structure.

    Why We Stopped Using Templates

    We built the current architecture from scratch after two rounds of trying to adapt downloaded templates. The templates were fine — they established reasonable database structures and saved initial setup time. The problem was customizing them.

    Every template comes with someone else’s assumptions baked in: their property names, their status sequences, their view organization, their relationship structure. Adapting those assumptions to a different operation requires understanding them well enough to change them without breaking the relations that depend on them. By the time you understand the template well enough to modify it correctly, you understand databases well enough to have built it yourself.

    The more useful approach for an operator who’s going to run Notion seriously: learn the architecture principles — how relation properties work, how filtered views are built, how rollups pull data across databases — and build from those principles. The initial investment is higher. The system that results fits your operation because it was designed for your operation.

    When Templates Are Worth Using

    Templates are worth using in two specific situations. First, when you’re new to Notion’s database capabilities and need a working example to understand how relations and views are structured. Opening a well-built template and reverse-engineering why it’s built the way it is is a faster learning path than reading documentation. Second, when you need a specific narrow function quickly — a content calendar for a new client vertical, a project tracker for a new type of engagement — and don’t have time to build from scratch. A template as a starting point, customized heavily, beats a delay.

    Want a Notion system built for your actual operation?

    We build Notion architectures from scratch for agencies — designed around how your operation actually works, not adapted from a generic template.

    Tygart Media builds and runs a custom Notion architecture across a large client portfolio. We know the difference between a system that looks organized and one that actually runs an operation.

    See what we build →

    Frequently Asked Questions

    Are Notion templates worth paying for?

    Occasionally. Free templates from Notion’s own gallery and established creators cover most use cases adequately. Paid templates justify their cost only when they include genuinely sophisticated relational architecture that would take significant time to build independently, or when they come with documentation that teaches you how to adapt them correctly. Most paid templates in the five-to-fifty dollar range are not meaningfully better than good free options.

    Where do you find good Notion templates for agencies?

    Notion’s official template gallery is the most reliable starting point — the templates there have been reviewed and work correctly. Thomas Frank’s Notion resources are well-regarded for the quality of their database architecture. The Notion subreddit and creator communities surface good templates periodically. Be skeptical of templates sold primarily on aesthetic appeal — visual polish does not indicate functional quality.

    Can you build a Notion agency system without using templates at all?

    Yes, and it’s often the better path for operators who will run Notion seriously long-term. Building from first principles — starting with the six operational questions your agency needs to answer, then designing the databases that answer them — produces a system that fits your operation without the overhead of adapting someone else’s assumptions. It requires more upfront investment and some database knowledge, but results in a more durable system.

  • Notion Client Onboarding Template: What We Actually Use

    The client onboarding process is where most agencies lose time they never recover. A disorganized onboarding means scattered information, repeated questions, unclear expectations, and a client relationship that starts on a note of confusion rather than confidence.

    The right Notion onboarding template — one that’s actually used, not just admired — solves this before the relationship even begins. Here’s the structure we use and why each piece is there.

    What should a Notion client onboarding template contain? An effective Notion client onboarding template contains five elements: a structured intake form or checklist for collecting client information, a reference section for brand and content guidelines, a project scope and deliverables tracker, a communication log for key decisions, and a Next Steps section that always reflects the current state of the engagement. Templates that omit any of these create gaps that surface as problems later.

    What the Template Actually Needs to Do

    An onboarding template has two jobs. First, collect everything you need to start doing the work correctly — brand guidelines, target audience, keyword strategy, content constraints, access credentials, approval processes. Second, establish the shared expectations that govern the relationship — what gets delivered, when, how feedback works, what happens when something needs to change.

    Most onboarding templates do the first job reasonably well and ignore the second entirely. Then scope creep, unclear feedback loops, and misaligned expectations become recurring problems that the template could have prevented.

    The Five Sections

    Section 1: Client Information and Access. The factual foundation — company name, primary contacts, website URLs, platform credentials, billing details, and contract reference. This section is filled out once during onboarding and updated when anything changes. It should never require searching an email thread to answer “what’s their WordPress login?”

    Section 2: Brand and Content Guidelines. Everything that governs how the work is done: brand voice description, approved and avoided topics, competitor sensitivities, style preferences, target audience profiles, primary keywords and content pillars. This section is the reference document for every piece of work produced for this client. It should be specific enough to give a writer genuine direction, not vague enough to cover for not asking the right questions during onboarding.

    Section 3: Scope and Deliverables. What was agreed, in plain language. Number of articles per month, content types, target platforms, revision rounds included, turnaround times, and what’s explicitly out of scope. Written without ambiguity. This section is the answer to every scope question that arises during the engagement — if it’s not in here, it wasn’t agreed to.

    Section 4: Communication Log. A running record of significant decisions, feedback rounds, strategic pivots, and anything else that changes what the work looks like. Dated entries, brief and factual. Not a chat replacement — a decision record. This section prevents the “I thought we decided” conversation from becoming a dispute.

    Section 5: Next Steps. Three to five items, always current, showing what’s happening next. What we’re working on, what we need from the client, and when they can expect the next delivery. This is the most-read section of any client portal and the one that requires the most active maintenance. It should never be stale.

    What Makes This Different From a Template You Download

    The templates available online for Notion client onboarding are structurally fine. The problem is that they’re generic — built for a hypothetical agency, not for yours. The brand guidelines section in a downloaded template doesn’t know your specific questions. The scope section doesn’t reflect how you actually define deliverables.

    An effective onboarding template is built from your specific failure modes. What questions do you wish you had asked during onboarding for the client relationship that went sideways? What information did you need mid-engagement that you didn’t have? What expectation mismatch caused the most friction? The answers to those questions are what should be in your template, not a generic list of fields.

    Build the first version of your template, use it with two or three clients, and then revise it based on what you still didn’t know at the end of onboarding. Version two will be significantly better than version one, and version three better still.

    Making It Machine-Readable

    For operations running AI-assisted content production, the onboarding template does a third job beyond the two described above: it becomes the client reference document that Claude reads before starting any session for that client.

    This requires adding a metadata block at the top of the client reference page — a structured summary of the key constraints, the brand voice, the approved topics, and the things to avoid. With this block in place, Claude can orient itself to a client’s requirements in seconds at the start of a session, rather than requiring you to paste in the guidelines every time.

    The metadata block is five minutes of additional work during onboarding. It pays off every session for the duration of the engagement.

    Want this set up for your agency?

    We build client onboarding systems in Notion — the template structure, the intake process, and the reference architecture that makes every new client relationship start correctly.

    Tygart Media runs client onboarding across a large portfolio. We know what information you actually need and what gaps cause problems later.

    See what we build →

    Frequently Asked Questions

    Should client onboarding templates be the same for every client?

    The structure should be consistent; the content will differ. Using the same template structure for every client creates operational consistency — you always know where to find the brand guidelines, the scope definition, the communication log. The content within each section varies by client. Avoid the temptation to create different templates for different client types; the overhead of maintaining multiple templates outweighs the customization benefit for most agencies.

    How long should client onboarding take?

    The information collection phase — getting the brand guidelines, scope confirmation, and access credentials — should complete within the first week of the engagement. Rushing it creates gaps. Extending it past two weeks signals a disorganized client relationship that will be difficult throughout. The onboarding template makes the information collection systematic, which speeds it up without cutting corners.

    What’s the most important thing to document during client onboarding?

    Scope and constraints, in that order. Scope — exactly what was agreed and what’s out of scope — prevents the most common and costly agency problem: scope creep that erodes margins without anyone noticing until it’s significant. Constraints — what topics to avoid, what competitors are sensitive, what content has been tried and failed — prevent producing work that misses the mark for reasons you could have known going in.

  • Notion for Content Agencies: Managing 20+ Client Sites Without Losing Your Mind

    Managing twenty-plus client sites from one Notion workspace requires solving a specific problem: how do you keep clients separated while keeping your operation unified? Separate workspaces per client sounds clean until you’re switching between eight workspaces to get a picture of the week. One shared workspace sounds efficient until a client can see another client’s work.

    The answer is a single workspace with entity-level partitioning — one set of databases, one operating rhythm, one knowledge layer, with every record tagged to the entity it belongs to. Here’s how that works in practice for a content agency.

    What is entity-level partitioning in Notion? Entity-level partitioning is an architectural approach where all records across all clients live in shared databases, tagged with an entity or client property. Filtered views surface only the records relevant to a specific client or business line. The databases are unified; the views are isolated. It enables cross-client visibility for the operator while maintaining strict separation for any client-facing access.

    Why One Workspace Beats Many

    The operational case for a single workspace is straightforward: weekly planning requires seeing everything at once. If Monday morning means answering “what’s publishing this week across all clients?”, the answer should come from one view, not from opening eight workspaces and aggregating manually.

    A single workspace with entity tagging gives you that cross-client view. Filter by entity for client-specific work; remove the filter for the full operational picture. The same database serves both purposes.

    The Content Pipeline at Scale

    For a content agency, the Content Pipeline database is the operational core. Every article, audit, and deliverable across every client moves through the same status sequence — Brief, Draft, Optimized, Review, Scheduled, Published — in one database.

    Each record carries the client entity tag, the target site URL, the target keyword, word count, publication date, and a linked task in the Master Actions database for whoever is responsible for the next step. A filtered view scoped to one client shows that client’s complete pipeline. An unfiltered view shows the full operation across all clients simultaneously.

    The practical benefit: a Monday morning review of everything publishing in the next seven days across all clients is one database view, sorted by publication date. No aggregation, no manual compilation, no missing anything because it was in a different workspace.

    The Client-Specific Knowledge Layer

    Each client has unique constraints that govern the work: brand voice guidelines, keyword lists, approved topic areas, platform-specific rules, past decisions about what to avoid. This information needs to live somewhere accessible mid-session without requiring a search.

    In our system, each client’s reference documentation lives in the Knowledge Lab database, tagged with the client entity. A filtered view of the Knowledge Lab scoped to one client shows all the reference material for that client — brand guide, keyword strategy, approved personas, content rules — in one place.

    The critical piece: every client reference page carries the metadata block that makes it machine-readable mid-session. When working on a client’s content, Claude can fetch the client’s brand reference and style guide and read the key constraints from the metadata summary without reading the full document every time.

    Communication and Decision Logging

    At scale, the thing that creates the most operational problems is context loss between sessions: a decision made in a client call two weeks ago that wasn’t documented, a feedback note that lived in an email and never made it into the system, a constraint mentioned once and then forgotten.

    The communication log in each client’s portal and the session log in the Knowledge Lab together solve this. Any significant decision — a strategic pivot, a content constraint, a scope change — gets a one-paragraph log entry with a date. The next session starts by reading the most recent log entries, not by trying to remember what was decided.

    This is unglamorous work. It takes three minutes to write a decision log entry. Those three minutes prevent hours of re-work when the undocumented decision surfaces as a problem two months later.

    The Weekly Cross-Client Review

    The operational rhythm for a multi-client content agency requires one weekly moment of seeing the full picture: every client’s content queue, every stalled deliverable, every relationship that needs attention. This is the weekly review, and Notion’s filtered views make it tractable at scale.

    The weekly review covers four database views: all content scheduled for the coming week sorted by publication date; all tasks marked In Progress for more than two days across all clients; any Revenue Pipeline deals with no activity in the past seven days; any client CRM contacts who should have heard from you. Reading all four views and deciding what needs action takes twenty to thirty minutes. Everything else in the week flows from those decisions.

    Want this built for your content agency?

    We build multi-client Notion architectures for content agencies — the entity partitioning, content pipeline, knowledge layer, and operating rhythm that make managing twenty-plus clients tractable.

    Tygart Media manages a large portfolio of client sites from a single Notion workspace. We know what the architecture requires at that scale.

    See what we build →

    Frequently Asked Questions

    Should each client have their own Notion workspace?

    For most content agencies, no. Separate workspaces per client prevent the cross-client visibility that makes weekly planning tractable. A single workspace with entity-level partitioning gives you unified operations for the agency and isolated views for any client-facing access. Separate workspaces make sense only when clients need active collaborative access to the same workspace — a rare requirement for most content agency relationships.

    How do you prevent one client’s content from appearing in another client’s view?

    Every database record carries an entity or client tag. Every client-facing view is filtered to show only records with that client’s tag. As long as records are correctly tagged at creation — which becomes habitual quickly — the filtering is reliable. A brief weekly audit checking for untagged records catches any that slip through.

    What happens when a content agency grows beyond Notion’s capacity?

    Notion handles large workspaces well with proper architecture — the performance issues most people encounter come from databases with thousands of unarchived records, not from the number of clients. Regular archiving of completed records keeps databases performant. At genuinely large scale (hundreds of active clients), dedicated agency management software may be warranted, but most content agencies operating at twenty to fifty clients run well within Notion’s capabilities.

  • Notion Project Management for Small Agencies: The 6-Database Architecture

    The project management tools built for agencies assume you have a team. They’re priced per seat, designed for handoffs between people, and optimized for visibility across a group. If you’re running a small agency — two to five people, or solo with contractors — most of that architecture is overhead you don’t need and complexity that actively slows you down.

    Notion solves this differently. Instead of fitting your operation into a tool designed for someone else’s workflow, you build the system your operation actually requires. For a small agency managing multiple clients and business lines simultaneously, that system is a six-database architecture that keeps everything connected without the bloat of enterprise project management software.

    This is what that architecture looks like and why each piece exists.

    What is the 6-database Notion architecture? The 6-database architecture is a Notion workspace structure designed for small agencies and solo operators managing multiple clients or business lines. Six interconnected databases — tasks, content, revenue, CRM, knowledge, and a daily dashboard — cover every operational layer of the business, linked by shared properties so information flows between them without duplication.

    Why Six Databases and Not More

    The instinct when building a Notion system from scratch is to create a database for everything. A database for meetings. A database for ideas. A database for invoices. A database for each client. This is how Notion workspaces become unusable — too many places things could live, no clear answer for where they actually belong.

    Six databases is the right number for a small agency because it maps cleanly to the six operational questions you need to answer at any moment: What do I need to do? What content is in the pipeline? Where does revenue stand? Who are my contacts? What do I know? What matters today?

    Every piece of information in the operation belongs in one of those six categories. If something doesn’t fit, it either belongs in a sub-page of an existing database record or it doesn’t need to be documented at all.

    Database 1: Master Actions

    Every task across every client and business line lives in one database. Not separate task lists per client, not separate boards per project — one database, partitioned by entity tag.

    The key properties: Priority (P1 through P4), Status (Inbox, Next Up, In Progress, Blocked, Done), Entity (which business line or client), Due Date, and a relation field linking to whichever other database the task belongs to — a content piece, a deal, a contact.

    The priority logic is worth being explicit about. P1 means revenue or reputation suffers today if this doesn’t get done. P2 means this creates leverage — a system, an asset, something that compounds. P3 means operational work that needs to happen but doesn’t compound. P4 means it should be delegated or killed. If your P1 list has more than five items, something is mislabeled.

    The daily operating rule: never more than five tasks in Next Up at once. The system forces prioritization rather than enabling the comfortable illusion that everything is equally important.

    Database 2: Content Pipeline

    Every piece of content — articles, reports, audits, deliverables — moves through a defined status sequence before it reaches the client or goes live. Brief, Draft, Optimized, Review, Scheduled, Published.

    The Content Pipeline database tracks where every piece is in that sequence, which client it belongs to, the target keyword or topic, the target platform, word count, and publication date. The relation field links back to the Master Actions database so the task of writing a specific piece and the piece itself are connected.

    The hard rule: nothing publishes without a Content Pipeline record. This creates an audit trail that answers “what did we deliver in March?” in seconds rather than requiring a search through email threads or shared drives.

    Database 3: Revenue Pipeline

    Active deals, proposals, and retainer renewals tracked through defined stages: Lead, Qualified, Proposal Sent, Active, Renewal, Closed.

    Each record carries the deal value, the stage, the last activity date, and a relation to the Master CRM for the associated contacts. The weekly review checks whether any deal has sat in the same stage for more than seven days without activity — that stagnation is a signal that requires a decision, not more waiting.

    The Revenue Pipeline doesn’t replace an accounting system. It tracks the relationship status and deal momentum, not invoices or payments. Those live in dedicated accounting software. The pipeline answers “where are we in the conversation?” not “what was billed?”

    Database 4: Master CRM

    Every contact across every business line — clients, prospects, partners, vendors, network relationships — in one database, tagged by entity and relationship type.

    The CRM properties: Entity, Relationship Type (client, prospect, partner, vendor, network), Last Contact Date, and a relation field linking to any Revenue Pipeline deals associated with that contact.

    The weekly review includes a check for any contact who should have heard from you and didn’t. “Should have heard from you” is defined by relationship type — active clients warrant more frequent contact than cold prospects. The CRM makes that check systematic rather than dependent on memory.

    Database 5: Knowledge Lab

    SOPs, architecture decisions, reference documents, and session logs. This is the institutional knowledge layer — everything that would take significant time to reconstruct if the person who knows it left or forgot.

    Every Knowledge Lab record carries a Type (SOP, architecture decision, reference, session log), an Entity tag, a Status (evergreen, active, draft, deprecated), and a Last Verified date. The Last Verified date drives the maintenance cycle — any record older than 90 days gets flagged for a quick review.

    The Knowledge Lab is also the layer that makes the operation AI-readable. Every page carries a machine-readable metadata block at the top that allows Claude to orient itself to the content quickly during a live session. This is what transforms the Knowledge Lab from a static document library into an active operational asset.

    Database 6: Daily Dashboard (HQ)

    Not a database in the traditional sense — a command page that aggregates filtered views from the other five databases into a single daily interface. The goal is one page that answers “what needs attention right now?” without clicking through five separate databases.

    The HQ page contains: a filtered view of P1 and P2 tasks due today or overdue, the content queue for the next 48 hours, an inbox view of unprocessed items (tasks without a priority or status assigned), and a quick-access list of the most frequently used database views.

    The HQ page is where every working day starts. Everything else in the system is accessed from here or from the five source databases. It’s the navigation layer, not a database of its own.

    How the Databases Connect

    The architecture only works as a system if the databases talk to each other. The connection mechanism in Notion is relation properties — fields that link a record in one database to a record in another.

    The key relations: every Content Pipeline record links to a Master Actions task. Every Revenue Pipeline deal links to a Master CRM contact. Every Master Actions task can link to a Content Pipeline record, a Revenue Pipeline deal, or a Knowledge Lab SOP. These relations mean you can navigate from a task to the content piece it produces, from a deal to the contact it involves, from a procedure to the tasks that execute it — without leaving Notion or losing the thread.

    Rollup properties extend this further: a Content Pipeline view can show the priority of the associated task without opening the task record. A Revenue Pipeline view can show the last contact date from the CRM without opening the contact. The data stays connected visually, not just structurally.

    What This Architecture Replaces

    For a small agency, the 6-database architecture typically replaces: a project management tool (the tasks and content pipeline handle this), a CRM (the Master CRM handles this), a shared drive for SOPs (the Knowledge Lab handles this), and a deal tracker (the Revenue Pipeline handles this). It does not replace accounting software, calendar tools, or communication platforms — those remain separate because they do things Notion doesn’t.

    The consolidation matters not just for cost but for operational clarity. When every operational question has one answer and one place to look, the cognitive overhead of running the business drops significantly. The system becomes something you trust rather than something you maintain out of obligation.

    Want this built for your agency?

    We build the 6-database Notion architecture for small agencies — configured for your specific operation, with the relations, views, and daily operating rhythm set up and documented.

    Tygart Media runs this system live. We know what the build process looks like and what breaks without the right architecture from the start.

    See what we build →

    Frequently Asked Questions

    How is the 6-database Notion architecture different from using ClickUp or Asana?

    ClickUp and Asana are built around tasks and projects as the primary organizational unit. The 6-database architecture treats the business itself as the organizational unit — tasks, content, revenue, relationships, and knowledge are all connected layers of one system rather than separate tools or modules. The tradeoff is that Notion requires more upfront architecture work, but produces a system that fits your specific operation rather than a generic project management workflow.

    Can one person realistically maintain six databases?

    Yes — that’s what the architecture is designed for. The daily maintenance is five to fifteen minutes of triage and status updates. The weekly review is thirty minutes. Most of the database updating happens naturally as work progresses: publishing a piece updates the Content Pipeline, closing a deal updates the Revenue Pipeline. The system is designed for a solo operator or a very small team, not a department.

    What Notion plan do you need for the 6-database architecture?

    The Plus plan at around ten dollars per month per member is sufficient for everything described here — unlimited pages, unlimited blocks, and the relation and rollup properties that make the database connections work. The free plan limits relations and rollups in ways that would break the architecture. The Business plan adds features useful for larger teams but isn’t necessary for a small agency setup.

    How long does it take to build the 6-database architecture from scratch?

    Plan for twenty to forty hours to build, configure, and populate the initial system — creating the databases, setting up the properties and relations, building the filtered views, writing the first SOPs, and establishing the daily operating rhythm. Most operators who build it solo spend two to three months in iteration before it stabilizes. Starting from a pre-built architecture configured for your specific operation compresses that significantly.

    What’s the biggest mistake people make when building a Notion agency system?

    Creating too many databases. The instinct is to give everything its own database — one per client, one per project type, one for every category of information. This creates the same problem as a disorganized file system: too many places things could live, no clear answer for where they actually belong. Start with six. Add a seventh only when there’s a category of information that genuinely doesn’t fit in any of the six and that you need to query or filter regularly.

  • Notion Client Portal Setup for Agencies: How We Build Ours

    Most agency client portals are either too complicated to maintain or too bare to be useful. A shared Google Drive folder isn’t a portal. A ClickUp guest view requires the client to learn ClickUp. A custom-built portal requires a developer. Notion sits in the middle — flexible enough to build something professional, simple enough that clients can actually use it without training.

    This is how we build Notion client portals for our own operation. Not a template walkthrough — a description of the actual architecture, what we include, what we leave out, and why.

    What is a Notion client portal? A Notion client portal is a shared Notion page or workspace section that gives a client controlled visibility into their project — deliverables, timelines, assets, and communication — without exposing the rest of your internal operation. It functions as a lightweight client-facing dashboard built inside your existing Notion workspace.

    What a Notion Client Portal Actually Needs to Do

    Before building anything, it helps to be clear about what the portal is for. In our operation, a client portal has three jobs:

    Reduce inbound questions. If a client can see where their project stands without emailing, they will. A well-structured portal cuts “what’s the status?” messages significantly.

    Create a delivery record. Every deliverable — article, report, strategy doc — has a logged home. When a client asks what was delivered in March, the answer is one click away.

    Protect internal operations. The portal is a window, not a door. Clients see what’s relevant to them. They don’t see your internal task database, your pricing notes, your other clients, or your operational SOPs.

    The Core Portal Structure

    Every client portal we build follows the same structural template, customized by scope. The core components are:

    Project Status Dashboard

    A simple table or board view showing the current state of all active deliverables. Columns: deliverable name, status (In Progress / Review / Delivered), due date, and a link to the asset. Clients can see at a glance what’s moving and what’s done without needing to ask.

    This view is a filtered view of our internal Content Pipeline database — the client sees only their rows, not the full database. We use Notion’s filter-by-property feature to scope the view to their entity tag. They get a live view of their work without any access to the broader pipeline.

    Deliverables Library

    A running archive of everything completed and delivered. Articles, audits, reports, strategy documents — each as a linked page or embedded file. Organized by month. This solves the “can you resend that?” problem permanently and gives clients a sense of the body of work accumulating over a retainer.

    Communication Log

    A simple chronological page where significant decisions, feedback rounds, and strategic pivots get logged. Not a chat — a record. When a client says “I thought we decided X,” the communication log is the answer. This protects both parties and reduces scope creep from memory drift.

    Reference Documents

    Brand guidelines, target keyword lists, approved personas, style notes — anything the client has provided or that governs the work. Stored here so the answer to “do we have their brand guide?” is always yes.

    Next Steps

    A short, always-current list of what happens next. Three to five items max. What we’re working on, what we need from them, and when they can expect the next delivery. Clients check this more than anything else in the portal.

    How Access and Permissions Work

    Notion’s sharing model for client portals works at the page level, not the database level. This is the key architectural decision that determines how isolated the portal actually is.

    The correct approach: build the client portal as a standalone page that is not a child of your main Command Center. Share that page with the client via email invite at the “Can view” or “Can comment” level. The portal contains only filtered views and manually duplicated content — never direct database access.

    What to avoid: sharing a database directly with a client, even with filters applied. Notion’s permissions model allows determined users to remove filters from shared database views, exposing rows you didn’t intend to share. Always use a standalone page with embedded filtered views, not a raw database share.

    The Air-Gap Principle

    We call our approach to client portals “air-gapped” — the portal is architecturally separated from the internal operation even though it draws from the same underlying data.

    In practice, this means the portal page never has a back-link to the Command Center. The filtered views are set up so the client can see their data but cannot navigate to the parent database. Any document shared in the portal is either a shared Notion page with its own permissions or an exported file — never a raw internal page with full internal linking.

    The air gap matters because Notion’s page graph is navigable. If you share a page that contains a link to an internal page the client shouldn’t see, they can follow that link if it’s not properly permissioned. Build the portal as if it’s a separate product, even if it isn’t.

    What Not to Put in a Client Portal

    Equally important as what to include: what to leave out.

    Internal task notes. Your notes about why something is late, what went wrong, or what you think about the brief belong in your internal system, not in a client-visible page.

    Pricing and contract details. These live in your Revenue Pipeline and are shared via PDF or dedicated document — not embedded in an operational portal.

    Other clients’ work. Obvious, but worth stating explicitly given how easy it is to accidentally link across projects in a shared workspace.

    Unfinished deliverables. The portal is a delivery mechanism, not a work-in-progress view. Drafts go into the portal when they’re ready for client review, not before.

    Maintaining Portals at Scale

    The main friction with Notion client portals at scale is maintenance overhead. If you’re running ten or more active clients, keeping ten portals current manually is a real time cost.

    The solution is to minimize what requires manual updating. The Project Status Dashboard and Deliverables Library should pull from your internal pipeline database via filtered views — when you update the internal record, the portal updates automatically. The only things requiring manual attention are the Communication Log and Next Steps, which genuinely need a human decision about what to write.

    In our operation, portal maintenance takes roughly five minutes per client per week — the time it takes to update Next Steps and log any significant decisions from that week’s work. Everything else is live from the internal system.

    When Notion Portals Work Well and When They Don’t

    Notion client portals work well for content agencies, SEO operations, strategy consultants, and any service business where the deliverables are primarily documents. The portal model fits naturally when what you’re delivering is readable, linkable, and accumulates over time.

    They work less well for project-heavy engagements where the client needs to interact with tasks, leave comments on specific items, or participate in the workflow. For those cases, a purpose-built client portal tool — or a dedicated shared Notion workspace rather than a view-only portal — is a better fit. Notion can support collaborative client workspaces, but it requires a different architecture than the air-gapped portal model described here.

    Want this built for your agency?

    We set up Notion client portals and full Command Center architectures for agencies — configured for your operation, not a template to customize yourself.

    Tygart Media runs this system live across multiple active clients. We know what the build process looks like and what breaks without proper architecture.

    See what we build →

    Frequently Asked Questions

    Can clients edit content in a Notion client portal?

    Yes, if you give them “Can edit” or “Can comment” permissions. For most agency relationships, “Can comment” is the right level — clients can leave feedback directly on pages without being able to accidentally delete or restructure content. “Can view” works for portals that are purely informational delivery mechanisms.

    Is it safe to share a Notion database view with a client?

    With caution. Filtered database views can have their filters removed by users with edit access. For client-facing portals, use standalone pages with embedded filtered views set to view-only, rather than sharing the database itself. This is the air-gap approach — the client sees the data but cannot access the underlying database structure.

    How do you handle multiple clients in one Notion workspace?

    Each client gets their own portal page, shared individually. Internally, all client data lives in shared databases partitioned by an entity or client tag. Filtered views in each portal show only that client’s records. Clients never see each other’s portals or data because each portal is a separately permissioned page.

    What’s the difference between a Notion client portal and a shared Notion workspace?

    A client portal is a view-only or comment-only window into your operation — the client sees deliverables and status but doesn’t work inside Notion alongside you. A shared workspace is a collaborative environment where both agency and client actively use Notion together. Portals are simpler to maintain and better for most agency relationships. Shared workspaces make sense for longer-term, higher-touch engagements where the client is an active participant in the work.

    How long does it take to set up a Notion client portal?

    A well-structured portal takes two to four hours to build from scratch for the first client. Once you have a working template, duplicating and customizing it for additional clients takes thirty to sixty minutes. The time investment is in designing the architecture correctly the first time — portals built without a clear structure tend to get abandoned within a few months.

  • How I Run 27 Client Sites from One Notion Command Center

    I run 27 client WordPress sites from a single Notion workspace. No project management software, no agency platform, no dedicated CRM. Just Notion — architected deliberately across six interconnected databases — handling task triage, content pipelines, client relationships, revenue tracking, and the knowledge infrastructure that feeds an AI-native content operation.

    This is not a productivity tutorial. This is a description of a real system, built over two years, that runs across seven distinct business entities simultaneously. If you’re an agency owner, solo operator, or content business trying to figure out how to use Notion for something more serious than a to-do list, this is what the other end of that road looks like.

    What is a Notion Command Center? A Notion Command Center is a multi-database workspace architecture that functions as a single operating system for a business or portfolio of businesses. Rather than using Notion as a note-taking app, a Command Center connects tasks, clients, content, and knowledge into a unified system with defined workflows, priority rules, and daily operating rhythms.

    Why Notion Instead of Dedicated Agency Software

    The honest answer: I tried the alternatives. ClickUp has more native project management features. Asana handles task dependencies better out of the box. Monday.com is more polished for client-facing views.

    None of them let me build exactly the system my operation requires. And at the scale I’m running — 27 client sites, seven business entities, a live AI publishing pipeline — the ability to customize the architecture matters more than any individual feature.

    Notion also has a meaningful advantage that most people underestimate: it integrates with Claude natively. My entire operation runs on Claude as the AI layer, and a Notion workspace structured correctly becomes something Claude can read, reason about, and act on. That combination — Notion as the OS, Claude as the intelligence — is what makes this a genuinely AI-native operation rather than just an AI-assisted one.

    The 6-Database Architecture

    The Command Center runs on six core databases. Everything else in the workspace is either a view of these databases, a child page underneath them, or a standalone reference document. The six databases are:

    1. Master Actions

    Every task across all seven entities lives here. Priority levels run P1 (revenue or reputation at risk today) through P4 (delegate or kill). Each task carries an Entity tag, a Status, a Due Date, and a linked record in whichever other database it belongs to — a client, a content piece, a deal.

    The daily operating rule: never more than five tasks marked “Next Up” across the entire workspace at once. If your Next Up list has eight items, something is mislabeled. P1 means the thing doesn’t get done and real consequences follow today.

    2. Content Pipeline

    Every article across all 27 client sites flows through this database before it hits WordPress. Status stages run from Brief → Draft → Optimized → Scheduled → Published. The database links to the client entity, carries the target keyword, the target site URL, word count, and a publication date.

    Nothing publishes without a Notion record. This is a hard rule established after the alternative — articles written in sessions and pushed directly — created audit gaps that took hours to resolve. Notion first, WordPress second.

    3. Revenue Pipeline

    Client deals, proposals, and retainer renewals. Stage-based (Lead → Qualified → Proposal Sent → Active → Renewal). Links to the Master CRM for contact records. The weekly review checks whether any deal has sat in the same stage for more than seven days without activity — that’s a warning sign that gets flagged.

    4. Master CRM

    Every contact across all seven entities. Clients, prospects, golf league members, partners, vendors. Tagged by entity, relationship type, and last contact date. The weekly review catches anyone who should have heard from me and didn’t.

    5. Knowledge Lab

    SOPs, architecture decisions, session logs, and reference documents. This is where the institutional knowledge lives — the things that would take hours to reconstruct if I had to start from scratch. The Knowledge Lab uses a metadata standard (I call it claude_delta) that makes every page machine-readable, so Claude can fetch and reason about the content in a live session without losing context.

    6. William’s HQ

    The daily dashboard. A filtered view of P1 and P2 tasks due today or overdue, the content queue for the next 48 hours, and the inbox triage. This is the page that opens first every morning. Everything else in the system is accessed from here.

    The Seven Entity Structure

    The system manages seven distinct business entities, each with its own Focus Room — a sub-page containing that entity’s active projects, open tasks filtered by entity tag, and key reference documents. The entities are:

    • The parent agency — managing all client sites and retainer relationships
    • Personal brand — direct services, thought leadership, and new business
    • Client A — content operation for a contractor in a regional market
    • Client B — content operation for a service business in a metro market
    • Industry network — B2B community and event operation
    • Content property — topical authority site in a specific vertical
    • Personal — finances, health commitments, personal projects

    The entity structure means a task logged under “a regional client content operation” never bleeds into the the parent agency content queue. The databases are shared, but the entity tag acts as a partition. This matters operationally when you’re switching contexts fifteen times a day — the system tells you where you are and what belongs there.

    The Daily Operating Rhythm

    The Command Center only works if you use it on a rhythm. Mine runs on three loops:

    Morning Triage (10–15 minutes)

    Open William’s HQ. Zero the inbox — every untagged item gets a priority, a status, and an entity. Read the P1 and P2 list. Mentally commit to the top three. Check the content queue for anything publishing in the next 48 hours that isn’t scheduled. That’s a P1 fix before anything else happens.

    End-of-Day Close (5 minutes)

    Mark done tasks complete. Push anything untouched but intended — update the due date or reprioritize down. Check the content queue for tomorrow’s publications. If anything new was created during the day — a contact, a content piece, a deal — verify it’s logged in the right database with the right entity tag.

    Weekly Review (30 minutes, Sunday evening)

    Revenue: any deal stuck in the same stage as last week? Content: next week’s queue fully populated? Tasks: archive all Done tasks older than 14 days. Relationships: anyone who should have heard from me and didn’t? System health: any automation that failed silently?

    The weekly review is the repair mechanism. It catches the things the daily rhythm misses and resets the system before the next week compounds the drift.

    How Claude Plugs Into This

    The Knowledge Lab’s claude_delta metadata standard is what makes the Notion–Claude integration functional rather than theoretical. Every page in the Knowledge Lab carries a JSON metadata block at the top that tells Claude the page type, status, summary, key entities, and a resume instruction for picking up work in progress.

    In practice, this means I can start a session by telling Claude to read a specific Knowledge Lab page, and Claude has enough structured context to continue from exactly where the last session ended — without me re-explaining the project, the client, the constraints, or the decisions already made. The Notion workspace functions as persistent memory across Claude sessions.

    This is the part of the architecture that most people haven’t built yet. Notion as a note-taking app is one thing. Notion as a structured knowledge layer that an AI can navigate and act on is a meaningfully different proposition — and it’s the direction serious operators are moving.

    What This Architecture Costs to Build

    Honest answer: the architecture itself took about three months of active iteration to stabilize. The first version had too many databases, unclear relationships between them, and no real operating rhythm to enforce the discipline. The current version is the result of tearing down and rebuilding twice.

    The tooling cost is low. Notion’s Plus plan at $10/month per member handles everything described here. The BigQuery knowledge ledger that backs the AI memory layer runs on Google Cloud at effectively zero cost at this scale. Claude API usage for content operations runs roughly $50–150/month depending on session volume.

    What actually costs something is the setup time and the learning curve of building databases that relate to each other correctly. Most Notion setups fail not because the tool is limited but because the architecture wasn’t designed before the databases were created.

    Whether This Is Right for Your Agency

    The Command Center architecture works well for solo operators and small agencies managing multiple clients or business lines simultaneously. It works especially well when you’re running an AI-native content operation and need Notion to function as more than task management.

    It’s not the right choice if you need strong native time-tracking, Gantt charts, or client-facing portals that look polished without customization. Those cases have better-suited tools.

    But if you’re running a content agency, a multi-client SEO operation, or any business where the work is primarily knowledge work — briefs, articles, strategies, SOPs, client communications — and you want one system that sees all of it, the 6-database Command Center architecture is worth the build time.

    Want this built for your operation?

    We set up Notion Command Centers for agencies and operators — the full architecture, configured and documented, not a template to figure out yourself.

    Tygart Media has built and runs this system live across 27 client sites. We know what the setup process actually looks like.

    See what we build →

    Frequently Asked Questions

    How many databases does a Notion Command Center need?

    A functional Command Center for an agency or multi-client operation typically needs six core databases: a task database, a content pipeline, a revenue pipeline, a CRM, a knowledge base, and a daily dashboard. More than eight databases usually indicates an architecture problem — complexity that should be handled with views and filters, not additional databases.

    Can Notion handle 27 client sites without getting slow?

    Yes, with proper architecture. The key is using filtered views rather than separate databases for each client, and keeping database page counts manageable by archiving completed records regularly. Notion’s performance degrades when a single database exceeds a few thousand active records — archive aggressively and it stays fast.

    How does Notion integrate with Claude AI?

    Notion and Claude integrate through structured page formatting and the Notion API. By standardizing metadata at the top of key pages — page type, status, summary, key entities — Claude can fetch and interpret Notion content in a live session. More advanced setups use the Notion API to read and write records programmatically during Claude sessions, effectively making Notion the persistent memory layer for AI operations.

    What’s the difference between a Notion Command Center and a regular Notion workspace?

    A regular Notion workspace is typically organized around document types — pages, notes, tasks — without enforced relationships between them. A Command Center is organized around business operations — entities, pipelines, and workflows — with databases that relate to each other and a defined operating rhythm that governs how the system gets used each day.

    How long does it take to set up a Notion Command Center?

    Building the architecture from scratch takes 20–40 hours of focused setup time, including database design, relationship configuration, view creation, and SOP documentation. Most operators who attempt it solo take 2–3 months of iteration before the system stabilizes. Working from an existing architecture and having it configured for your specific operation compresses that significantly.

    Is Notion good for content agencies specifically?

    Notion is well-suited for content agencies because the core work — briefs, drafts, SOPs, client communication, publishing schedules — is document-centric. The Content Pipeline database, linked to a CRM and task system, gives visibility into every piece of content across every client at once, which is difficult to replicate in project management tools not built for document-heavy workflows.