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.
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.
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.
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.
Leave a Reply