A founder gets off a 45-minute call with us. That call produced six usable things: a number he'd never published, a story about a 3PL renegotiation, an analogy that made one of his own team finally understand pricing, an objection he'd heard three times that month, a claim he half-remembered from a newsletter, and a pattern he'd noticed across two years of Q4s.
Six weeks later, one of them had made it into a post. The other five were in the transcript, which nobody reopened.
This is not a capture problem. He had the banks. We built them with him. It's a routing problem — and it's the single most common reason a founder's content system stalls after the systems are already in place.
We spent a year building banks and never built the router
If you've been following this series, you have a shelf of them by now. A proof bank for your own numbers. A story bank for moments. A question log for what buyers ask. An objection ledger for why they walk. A disagreement file for takes you refute. A source ledger for external numbers. An explanation bank for the analogies that landed.
Every one of those posts tells you what goes in that bank. Not one of them tells you how to decide.
That's fine when you have two banks. It falls apart at six, because raw material does not arrive pre-sorted. It arrives as a founder talking. A single ninety-second stretch of speech routinely contains a number, a story, a mechanism, and a complaint — braided together, because that's how people actually explain things.
So the founder hits the moment where the system is supposed to help and instead has to run a filing decision. And filing decisions at 11pm have exactly two outcomes: the wrong bank, or no bank.
The three failure modes we see
The freeze. The entry qualifies for three banks, so it goes in none. This is the most common one and the most invisible, because nothing happens. There's no half-written entry to find later. The material just doesn't exist.
The default bank. Everything goes wherever the founder opened first, usually the proof bank because numbers feel like the important part. Six months in, the proof bank has 40 entries and the objection ledger has two — not because the business generates no objections, but because objections kept getting filed as proof.
The orphan. The entry gets filed correctly and never gets found, because it was filed under what it is rather than what it's for. A note that says "3PL rate increase, March" is accurate and useless. Nobody searching for material about supplier leverage will ever open it.
All three produce the same symptom, and it's a symptom founders misread: "the system isn't giving me anything back." It is. You're just not putting things where you'll find them.
The routing rule: file by job, not by type
Here's the fix, and it's one sentence.
Route on what the material would do for a reader, not on what kind of thing it is.
A number is not automatically proof. A number is proof if its job is to establish that something happened at a specific scale. If its job is to make a mechanism visible, it's an explanation. If its job is to answer a thing buyers keep asking, it's a question-log entry with a number attached.
The same "$18K a year" figure has three different homes depending on what you'd use it for. Type tells you nothing. Job tells you everything.
This inverts how most people file, and it's why generic note-taking systems don't work for content. A tagging system organised by topic is a library. A capture system organised by job is a supply chain.
The four questions, in order
Run these on any piece of raw material. It takes about ten seconds once you've done it twenty times.
1. Is this mine, or someone else's? If it's an external number, a study, a stat from a newsletter — it goes to the source ledger, full stop, and it goes there unverified, with the link. This is the only question with a hard stop, because it's the only one where a wrong answer gets you publicly caught. Your own numbers proceed to question two.
2. Does it prove something, or explain something? Proof establishes that a thing happened: a rate, an outcome, a before-and-after. Explanation makes a mechanism visible: the analogy, the reframe, the smallest concrete case. If you couldn't defend the exact figure in a DM, it was never proof — it was an explanation wearing a number.
3. Did it come from a buyer's mouth? Then it's question log or objection ledger, and the split is simple: a question is someone trying to buy. An objection is someone deciding not to. They read similarly in a transcript and they do completely different work in a post. Questions produce content that helps. Objections produce content that converts.
4. Is it a moment, or a pattern? A moment is a story bank entry — it has a date, a scene, a thing that changed. A pattern is a judgment claim built on volume, and it belongs in whatever bank holds your durable material. Patterns are the material with the longest shelf life and the fewest entries in most founders' systems, because they don't feel like anything while you're saying them.
If a piece of material still qualifies for two banks after all four questions, it's usually because it's genuinely two entries. Split it.
The pointer rule: one home, several doors
The obvious workaround for a multi-bank entry is to copy it into both. Don't.
Duplicated entries drift. You update the number in one place, the stale version survives in the other, and eight months later you publish the wrong one — which is exactly the failure the source ledger exists to prevent, reintroduced by your own filing.
Instead: one primary entry, pointers from everywhere else. The full material lives in one bank. Other banks get a one-line reference with a link. If your tooling supports links between notes, this is free. If you're in a spreadsheet, it's an ID column.
The primary bank is the one that answers question two or three — proof, explanation, question, or objection. Story bank and source ledger are almost always pointers rather than primaries, because a story is usually the delivery vehicle for a proof or an explanation, not the payload.
Where the router actually runs
Not at your desk. The router has to run at the point of capture, which for most ecommerce founders is: on a call, right after a call, in a Slack thread, or in the car.
Three placements that work:
- A single inbox, then a weekly sort. Everything lands in one note or one channel with zero decisions. Once a week, ten minutes, you run the four questions and file. This is the version that survives a bad week, which is why we recommend it most.
- Voice note with the routing said out loud. "This is a proof — 22% to 14%, Q2, cabinet hardware line." Eleven extra words at capture time, and the sort is already done.
- The writer routes it. If you're working with someone, the honest answer is that routing is our job and we should be doing it off the transcript. The founder's job is to talk. But you still want the router documented, because the day the engagement pauses, the banks need to be usable by someone who wasn't on the calls.
What good looks like after a quarter
A working router produces a lopsided system, and the lopsidedness is the signal.
You should end up with a fat question log and objection ledger if you're customer-facing, a fat explanation bank if you spend a lot of time on sales calls, and a thin proof bank — because genuinely publishable proof is rare and most of what founders file as proof is either an explanation or a number they can't source.
If every bank has roughly the same number of entries after three months, the router isn't running. That's what an evenly-distributed system looks like: someone filing by type, spreading material around because it feels tidy.
The other tell is retrieval time. Sitting down to write and finding usable material in under two minutes is the entire return on this. If it still takes fifteen, the entries are filed by what they are.
FAQ
Do I need all six banks to bother with a router? No. Below three banks the routing decision is trivial and a router is overhead. The pain starts at four and becomes the bottleneck at six. If you're just starting, build two banks and the routing habit at the same time — retrofitting a router onto 200 badly-filed entries is a weekend nobody enjoys.
What if I file something in the wrong bank? Almost nothing. A misfiled entry is recoverable; an unfiled one isn't. Route fast and wrong rather than slowly and right — the four questions are a speed tool, not an accuracy tool. The only routing error that genuinely costs you is putting an external number anywhere other than the source ledger, because that's the one that gets published as though it were yours.
Should I use AI to sort the transcript? For a first pass, yes, and it's decent at it. But it will file by type, not by job, because it doesn't know what you'd use the material for. Treat its output as a pre-sort you correct in five minutes, not as the router.
My banks are already a mess. Where do I start? Don't re-file the archive. Start routing new material correctly from this week and let the old material stay where it is. You'll find that the last 90 days of well-routed entries do more work than three years of badly-routed ones, and the archive quietly stops mattering.
The banks were never the hard part. Capture is a habit and most founders can build it in a month. Routing is a decision, and decisions are what systems are supposed to remove.
If you've got the shelf built and nothing coming off it, the missing piece isn't discipline. It's a rule you can run in ten seconds while you're still in the car.
We build these systems with ecommerce founders as part of every ghostwriting engagement — the banks, the router, and the documentation that makes them usable by someone who wasn't in the room. If your raw material keeps evaporating between the call and the draft, that's the conversation to have.