On this page12
- What is a story bank, and why does a startup need one?
- The story bank template: columns that earn their place
- How do you get stories out of your team?
- The ready score: which stories can you use this week?
- Where each story should go
- How do KOL briefs and press pitches use the bank?
- When a story bank isn't worth it
- FAQ
- Should the story bank be visible to the whole company?
- How many stories should a story bank have?
- How do I get permission to use a user's story?
- When should a story be retired from the bank?
A story bank is a shared spreadsheet or database where your team logs real moments as they happen (a user's comment, a bug that taught you something, a partner's surprising use case, a number that moved) so that PR, content and KOL briefs never start from a blank page. A useful story bank template has about ten columns: the story in one line, the source, the proof, permission status, the narrative theme it supports, a ready score, and where it's been used. The hard part isn't the template. It's the weekly habit of filling it.
What is a story bank, and why does a startup need one?
Most teams have plenty of stories. They're just scattered across Telegram chats, call notes, Discord threads and the founder's memory, and they disappear within a week.
Then a reporter asks for an example of a real user, or a KOL needs a hook, or the founder has to write a post on Thursday, and everyone says the same thing: "We had a great one a few months ago, but I can't remember the details."
A story bank fixes that. It's a single place where raw material goes the moment it appears, with enough context that someone else can use it later. It's the supply side of every narrative you're trying to build. If you've chosen what your company stands for, the bank is where the evidence for it lives.
It also matters more now than it did a few years ago.
now brands need folks that could write old-school original content without using AI Shilika Jain on X, 19 Jun 2026
AI can produce a decent paragraph about almost anything. It can't produce the thing your user said on a call last Tuesday. Original, first-hand stories are what separate your content from everyone else's, and a story bank is how you keep a stock of them.
The story bank template: columns that earn their place
I keep this in a spreadsheet for most teams. Notion or Airtable works too, but a sheet is what people actually open. I've been a fan of simple trackers for a long time:
structured one pager/briefs for external sharing - google sheet trackers Shilika Jain on X, 20 May 2024
These are the columns, and why each one exists.
| Column | What goes in it | Why it matters |
|---|---|---|
| Date logged | When it was added | Freshness: old stories need re-checking |
| The story in one line | "A DAO treasurer moved funds off an exchange after trying our recovery flow" | Scannable; if you can't write one line, it's not a story yet |
| Source type | Team, user, partner, data, market | Shows if you're over-relying on one source |
| Who to ask | Name of the person who knows the detail | So anyone can follow up |
| Proof | Link, screenshot, on-chain tx, call recording, metric | Reporters and KOLs need evidence, not anecdotes |
| Permission | Public, ask first, internal only | Stops someone posting a user story without consent |
| Theme | Which narrative pillar it supports | Keeps the bank tied to your story, not random |
| Ready score | 0 to 8 (see below) | Tells you what can be used this week |
| Best route | Press, founder post, KOL brief, website, sales | Speeds up the hand-off |
| Used in | Links to where it's been published | Prevents the same story being overused |
Ten columns. If you add more, people stop filling it in. If you drop permission or proof, sooner or later something embarrassing goes out.
How do you get stories out of your team?
Asking "does anyone have a good story?" in a group chat gets silence. Specific prompts get answers. I give each source its own prompts, phrased as asks, and run them weekly.
Team (engineering, product, support)
- Tell me what broke this week and what fixing it taught you.
- Share a user question that surprised you.
- Name something you decided not to build, and the reason.
Users and community
- Paste one thing someone said in Discord or Telegram that the founder should see.
- Flag anyone who used the product in a way we didn't expect.
Partners
- Note what their users are doing with the integration that we didn't plan for.
- Capture anything a partner's team said on a call that explains why they chose us.
Data
- Pick the number that moved this week and say whether we know why.
- Spot any pattern in on-chain activity that tells a story by itself.
Market
- List the news this week we have a real opinion on.
- Write down one thing the category gets wrong that we see every day.
The single best habit I've found is a 20-minute "story harvest" at the end of each week. One person runs it, asks the prompts, and logs anything with a pulse. Rough is fine. Someone can tidy it later.
The ready score: which stories can you use this week?
Not every entry is ready to go out. I score each story on four checks, 0 to 2 each, for a total out of 8.
- Proof (0 to 2). 0 is "someone remembers it". 1 is a screenshot or internal note. 2 is a public link, on-chain record or a number you can source.
- Permission (0 to 2). 0 is unknown. 1 is "probably fine, ask first". 2 is written approval or fully public.
- Freshness (0 to 2). 0 is older than six months. 1 is one to six months. 2 is this month.
- Fit (0 to 2). 0 is interesting but off-message. 1 supports a theme loosely. 2 is direct evidence for one of your core themes.
A score of 7 or 8 can go into a pitch or a KOL brief now. A 4 to 6 needs one fix, usually permission or proof, so assign that fix to someone. Under 4, keep it in the bank as background, but don't build anything on it yet.
The score stops the most common mistake I see: a founder telling a great user story to a reporter, the reporter asking to speak to the user, and nobody having asked the user first.
Where each story should go
The routing column turns a pile of stories into a content plan. Different kinds of stories suit different channels.
| Story type | Best first route | Second life |
|---|---|---|
| A number with a clear cause | Press pitch or data post | Founder post on X, website proof point |
| A user's own words | Website, sales deck, founder post | Case study once permission is signed |
| A partner's unexpected use case | Joint content with the partner | Pitch angle for trade media |
| A team decision or failure | Founder post or behind-the-scenes content | Podcast talking point |
| An opinion on a news event | Reactive commentary to reporters | Op-ed if it holds up |
| A regional or local angle | Regional media pitch | Localised KOL brief |
For opinions on breaking news, speed matters, so these should sit at the top of the bank with an owner who can respond the same day. My reactive commentary guide covers how that works in practice. For team decisions and process, the Glass Wall Sort in my behind-the-scenes content post helps decide what's safe to share.
Stories don't need a bank to exist, but having them ready changes how fast you can move. When the global Microsoft outage hit in 2024, Fluence had a clear argument about why decentralised compute matters, and that turned into an e27 piece tying the outage to the need for DePIN. Commissioned research did something similar for Elastos: a finding that 67% of Nigerians trust Bitcoin for life savings over traditional methods earned its own Cryptonews headline. A number, a place and a clear angle. Those are exactly the entries a story bank should be full of.
How do KOL briefs and press pitches use the bank?
This is where the bank pays for itself.
A KOL brief built from the bank has real hooks: a user quote, a number with context, a decision the team made. Creators can work with that. A brief built from the website copy gives every creator the same three sentences, and every post sounds the same. My KOL brief template has a slot for exactly this kind of story.
A press pitch built from the bank can answer the reporter's follow-up questions before they ask: who the user is, whether they'll talk, where the number comes from. If those are already in the proof and permission columns, you reply in minutes instead of days.
I treat the media side the same way. Years ago I set out to build my own publications database:
gonna build a massive database of publications covering topics related to web3, blockchain, and crypto Shilika Jain on X, 10 Jul 2023
A media database tells you where a story could go. A story bank tells you what you have to send. You need both, and most teams only have half of one.
It also keeps your channels telling one story. If everyone pulls from the same bank, the founder, the website and the KOLs are citing the same evidence. The sibling post on narrative consistency across channels goes further on that.
When a story bank isn't worth it
Be honest about whether you'll maintain it.
- Teams of two or three. If everyone sits in the same calls, a shared notes doc might be enough. Move to a proper bank once stories start getting lost.
- No one owns it. A bank without an owner becomes a graveyard of half-entries within a month. If you can't name the owner, don't start.
- No narrative yet. If you haven't decided what you stand for, the Theme column will be empty and the bank becomes a random collection. Pick your themes first.
- Highly confidential products. Some enterprise or security work can't be discussed at all. The bank can still hold market opinions and team stories, but expect it to be thinner.
The ongoing cost is about half an hour a week for the harvest, plus whoever tidies the entries. In return, every piece of content starts with real material.
Setting up the template and running the first few harvests with a team is part of my content writing work, until it runs without me.
FAQ
Should the story bank be visible to the whole company?
Yes, read access for everyone and edit access for a few. People contribute more when they can see their stories being used. Keep a separate private tab for anything marked internal only, like sensitive user conversations or unannounced partner details.
How many stories should a story bank have?
There's no target number, but a healthy bank gets a handful of new entries each week and has several stories scoring 7 or 8 at any time. If you go a fortnight without a new entry, the harvest has stopped, not the stories.
How do I get permission to use a user's story?
Ask them directly, explain where it will appear, and get the answer in writing, even if it's just a message. Offer to anonymise it if they're hesitant. For press, check whether they're willing to speak to a reporter, which is a separate and bigger ask.
When should a story be retired from the bank?
When the proof goes stale (the number has changed), when the person involved has left or withdrawn permission, or when it's been used so often your audience will recognise it. Move retired stories to an archive tab rather than deleting them; they're still useful background.
Sitting on stories your team never writes down? Grab 30 minutes with me and we'll set up your story bank and the first harvest together.
