Whose turn is it?
A Reel for Hone is one row with a status. Andrew moves it, Gaby edits it, the status moves again. Eighteen days later it ships — and the row cannot tell you who had it on July 16th, how long it actually took, or what anyone owes anyone else. Nothing here is broken. The status is just doing three jobs at once: describing the work, handing it over, and approving it. Split those three and the rest falls into place.
One row, two people, nine moves
This is Reel 1 of the Hone campaign, exactly as it is tracked today: a single row in Deliverables & Content Assets. Watch the status carry the whole conversation.
changes
elapsed
involved
work
The row said Draft. Draft means Andrew is cutting — and it also means Gaby sent it back. Same status, opposite meanings, and the only way to tell them apart is to open the page and read the comments. Multiply that by every deliverable in every partnership: the tracker is honest about things, and silent about work.
What the two databases are made of
Not an opinion — a read of the schema as it stands today. Green is doing its job. Amber is text where a person or a date belongs. Red is a status carrying a handoff.
Current Owner is text. Waiting On is text. Main Signer is text. Lead is a select with four brand names in it. Which means Notion cannot notify anyone, cannot build a "my work" view, cannot count anyone's load, and cannot tell you who is late — because as far as the database is concerned, nobody works here. Everything else on this page follows from fixing that one thing.
Also worth naming: four self-relations on the same database (Sub-items, Sub-item, Parent, Parent item) are the open door to a subtask inside a subtask inside a subtask. The proposal below closes it: two levels, Project → Task, and nothing under a Task.
Four questions today's setup cannot answer
Every one of these is a question somebody asked in the last month. None of them is answerable from a view — each requires opening a page and reading comments.
The status says Draft. Draft is both "Andrew is cutting" and "Gaby sent it back". The row cannot distinguish them.
Two people share one row, so the elapsed time is Andrew's work plus Gaby's work plus every day it sat in between. That number is not an estimate of anything.
Three Reels became four; $250K became $300K. The row was edited in place, so the earlier terms exist only in someone's inbox.
Gaby reviews everything, and her queue is "whatever is sitting in In Review (KV) across two databases" — a filter she has to remember to run.
The whole proposal, in one sentence
Today one field is asked to do both, so the status ladder grows a rung every time a new kind of handoff appears — that's how you get to ten stages on a deal and seven on a Reel. Give the work an owner, a reviewer and an estimate, and the status can go back to being short and honest.
Four levels, and nothing below a task
Same shape Linear uses, and the same shape crescō runs on. Each level answers one question, and a level never does the job of the one above it.
- One row per company, forever
- Phone, contact, CRM link
- Never edited by a deal change
- One row per signed version
- The legal audit trail lives here
- Expires — everything under it inherits the date
- Has an owner and a date range
- % complete is computed, not typed
- This is what the timeline shows
- One assignee, always
- Blocked by / blocks another task
- Platform, publish date and asset link ride along as fields
Call it Customer. "Partnerships & Agreements Tracker" is a name people have to memorize; put that in the database description, where it belongs. Anyone who joins next quarter should be able to read the sidebar and know where things are without being told.
Where one task ends and the next begins
This is the decision that makes or breaks the whole model, and it is the one thing to get right before anybody touches Notion. Cut the work in the wrong place and you get back exactly what you have today: a row that bounces.
Not per step.
- Does the work change hands here? If it stays with the same person, it is the same task.
- Can the next person not start until this is finished? Then it is a dependency, not a checklist item.
- Would you ever want to know how long this part took, on its own? If yes, it deserves its own row.
Read the boxes again: the task boundary falls exactly where the avatar changes. That is the entire rule, and it is why "Stories 1–4" could never be one row — the row would have to be Andrew's and Gaby's and Daniela's at the same time, which is what a status ends up pretending to do.
A big deliverable, opened up
GP Content Production is too big to be one project — so it holds sub-projects, and holding sub-projects is what makes it an initiative. Not a new database, not a new word to memorize: a project with children, and a view that filters for them.
A sub-project cannot have sub-projects, and a task cannot have subtasks. One formula on Projects makes the rule enforce itself instead of relying on everyone remembering it:
if(empty(prop("Parent project")), "ok", if(empty(prop("Parent project").map(current.prop("Parent project"))), "ok", "⚠ too deep — flatten this"))
A fifth level would mean a fifth place to look and a fifth word to teach. Parent project gives you the same hierarchy inside the database you already have — and it is optional, so small deliverables stay flat instead of being wrapped in ceremony they don't need.
The same kind this page complained about in section 02. The difference is the dose: one self-relation, on Projects only, capped at one level, with a formula that flags violations. Today's setup has four of them on the piece-level database with no cap at all — that is the door to a subtask inside a subtask inside a subtask.
Task done → sub-project % → initiative % weighted by task count → agreement % → customer health. Mark Schedule + swipe-up done and every number above it moves, including the one on the Hone page.
The chain: done → Slack → next
Dependencies are what replace the bouncing. A task that is blocked says so; when its blocker closes, Notion posts to the project's Slack channel, @-mentions whoever is next, and flips their task to To do. And when the reviewer sends something back, the rework becomes a task with hours — not a sigh in a comment thread. Play it through.
The channel fills itself as the chain moves.
Being precise about what Notion does by itself: the trigger (status becomes Done), the Slack post and the status change on the next task are native database automations — no code, no Zapier. What I would not promise without testing it in your workspace is dates moving on their own when a blocker slips; that is a timeline setting to decide during the pilot, not something to sell in a slide.
Where everything you have today ends up
Nothing is thrown away except the four self-relations and the fields that duplicate a relation. Read this as the migration checklist.
Twenty-six status options become fourteen
And no object carries more than one ladder at a time. Today a single deal row holds three statuses at once — 10 × 4 × 5 is two hundred possible combinations, of which maybe a dozen are real.
Where the nuance went, honestly: "In Redlines", "Near Signing" and "Scope Drafting" were real information. They become tasks with an assignee and a due date — richer, but you now read them one click deeper instead of at a glance on the board. That is the trade, stated plainly.
One partnership, end to end
The whole Hone deal drawn through the four databases, record by record. Every blue chip is a relation you click to travel down. Every violet chip is a rollup that computes itself on the way back up.
Tasks done → the project's % complete · project %, weighted by task count → the agreement's % complete · delivered vs contracted → the customer's health. Nobody types a number: mark a task done and it travels all the way up to the customer page.
Who has it right now? → Reel 1, Assignee Andrew, Status In review, Reviewer Gaby. · How long will it take? → 2d estimated, 6h of rework already logged. · What did the deal say before? → the 2025 pilot row, untouched, linked as Supersedes. · What do I review today? → the Reviewer field, filtered. Same records, no extra work.
Review is a person, not a status
Every task has an Assignee — the one person doing it — and, when it needs approval, a Reviewer. To Review is one filter (Reviewer = me · Status = In review) laid out as a feed, so Gaby reads the work instead of hunting for it. Open a card to see the actual piece, then approve it, send it back, or log the rework it cost.
The agreement, on a timeline
Once projects have dates, the whole Hone contract is one picture: what ships when, what overlaps, and what has not started with the clock running. Click any bar to open the project.
Project % = done tasks / all tasks
Agreement % = sum(project % × its task count) / all tasks
Weighting the agreement by task count instead of averaging the projects means a five-task project doesn't count the same as a thirty-task one. Nobody types a percentage anywhere.
A rollup can only count children that exist. Today a Reel has no tasks under it — its progress is a person's impression, typed into a field or read off a status. Once the pieces are tasks with an owner and a done state, the number computes itself and stops being a matter of opinion.
The numbers you have never been able to see
Every figure below is a rollup over the same 29 tasks — nothing is entered by hand, nothing is estimated after the fact. This is the report the current setup cannot produce at any price, because the data it would need (an owner, an estimate, a review round, an hour of rework) does not exist yet.
Only 19% of a deliverable's life is production. The other 81% is waiting — and 14 of those hours were paid for twice, mostly because the copy direction arrived after the edit instead of before it. The fix is not "work faster": it is approve the caption at brief stage, which this data lets you argue for with a number instead of a feeling. Run it monthly and the same chart tells you whether the fix worked.
What it costs, not just what it gives
If this is going to be proposed to the team, it should be proposed with the bill attached.
- Real estimates. One person owns a task and says how long it takes. Two days means two days — not two days plus half of Gaby plus four days of waiting.
- A queue per person. "My work" and "To review" are filters, not habits. Nobody has to remember to check anything.
- Contract history survives. Renegotiate and the old agreement stays intact, signed and dated. Lars gets his audit trail for free.
- A timeline of the whole deal. Projects have dates, so the year is a picture instead of a spreadsheet.
- Progress computes itself. The rollups finally have children to count.
- The contract can be read by a skill. Fixed fields mean Claude can turn a signed PDF into projects and tasks — which is the experiment you already ran.
- Migration is manual. Every existing deal has to be re-keyed into four databases. Budget two focused sessions per active partnership, or run the contract-reading skill and correct what it gets wrong.
- More rows per deal. Hone goes from 1 row to roughly 1 customer + 1 agreement + 6 projects + ~25 tasks. Creating work takes more clicks than typing into a cell.
- It requires discipline. One assignee per task only works if people actually split shared work and fill in estimates. The model can't enforce it.
- You lose glanceability. "In Redlines" was visible on the board; now it's a task one click deeper.
- Permissions get real. A single Tasks database means everyone sees everything. If partnership legal work has to stay private, that's a separate database or a locked view — decide before, not after.
- Views have to be rebuilt. Pipeline, Exclusivity, Financial, Legal and GP Solo all point at the old tracker. They come back, but they come back by hand.
How to test it without betting the workspace
Nothing here requires turning anything off. Build the four databases beside the current ones and run one agreement through them.
Four databases with the properties above, and the three views that matter: My work, To review, Timeline. Nothing migrated yet.
One customer, one agreement, six projects, the tasks for the next four weeks. The current tracker keeps running untouched.
Andrew works out of Tasks, Gaby reviews out of To review. Nobody is asked to abandon anything yet.
Who has it? How long did it take? What did the deal say before? What do I review today? If the new setup answers them and the old one doesn't, migrate the rest.
The live test already worked halfway: pointed at the Hone contract with no context, Claude proposed GP Content Production and Campaign Launch as projects — both right — and also proposed Partnership Spend, which is a number, not a project. It missed because it had no schema to aim at. Give it these four databases and their fields, and the next signed PDF arrives as a customer, an agreement, its projects and their tasks — with dates, owners and reviewers already filled in. That's the payoff of doing the structure first.