Gabriel Espinheira
A marketing knowledge base should preserve the decisions that shape the next piece of work, not become another place to drop files.
A new writer opens your shared drive. They find a brand deck, three campaign folders, an old services page and several versions of the same presentation. Ten minutes later, a question comes up that you thought all that documentation had answered: who are we really selling to?
The files are present. The approved answer is not. That is why the founder gets pulled back into every brief, every new partner starts from zero, and the business slowly develops five versions of the truth. The fix is not a larger wiki. It is a smaller, decision-led system that tells someone what to do next and why.
TL;DR: A useful marketing knowledge base stores the current decision, why it was made, whether it is approved, who owns it, what changed and when to review it. Keep files as linked evidence. Then test the record on a live hand-off before you document more.
What a marketing knowledge base is really for
The job is to make the current approved answer easy to find and safe to use. Search alone cannot do that if five plausible answers sit behind the results.
Atlassian's State of Teams 2025, based on a survey of 12,000 knowledge workers and 200 executives, found that leaders and teams waste 25% of their time searching for answers. Its summary gets the tension right: “Teams have more information than ever, but they’ve never been less informed.”
For a small, owner-operated business, the cost shows up in ordinary work. A freelancer asks which audience matters most. A writer finds a claim on an old page but cannot tell whether it is still approved. An AI workflow pulls language from a proposal that was written for a different offer. The founder becomes the search engine because memory is the only place where the current decision and its context still live together.
In our experience working with founders across Europe, repeated questions rarely mean the team needs another folder. They usually mean the business has not made one answer authoritative.
A search result earns trust only when the reader can tell whether it is current, approved and meant for the job in front of them. A useful knowledge base lets the next person act without reopening a settled argument.
What every marketing decision record needs
A trustworthy record answers six operational questions before somebody uses it in public work. A small business does not need an encyclopedia about itself. It needs a clear trail from the current answer back to the judgement that produced it.
- What is the current answer? Write it as an instruction somebody can use. “Primary buyer: founder” is too thin. Name the buying situation, the problem they recognise, the alternatives they compare and the language they use.
- Why did we choose it? Link the customer interview, sales-call note, campaign result or operating constraint that supports the decision. A link is enough. Do not paste the source into another place that can drift.
- Is it safe to use? Use a visible state such as proposed, verified, approved or retired. This matters most for public claims. A plausible statement is not a publishable fact, and an old estimate should not become website copy because somebody found it first.
- Who owns the answer? One person must be responsible for resolving conflicts. Ownership does not mean they write every update. It means the next operator knows whose judgement closes the question.
- What changed? Keep a short note when the answer moves. “Narrowed the buyer after five sales calls” is more useful than a silent edit because it stops the old debate from returning six months later.
- When should we look again? Use a real trigger: a new offer, changed terms, completed customer research, a different lead pattern or a campaign that contradicts the assumption. A date can be a backstop, but it should not be the only reason to review the record.
Take a public claim such as customer ownership after cancellation. The record should state the approved wording, link to the contract or product behaviour that proves it, name the owner, show when it changed and flag the event that would require another review. A writer can now use the claim without guessing. A reviewer can see the evidence without hunting. The founder only enters the loop when the decision itself needs to change.
Build these records first for the decisions that block real work: buyer definition, offer promise, public proof and the current marketing priority. Add channel rules and measurement logic when the next brief needs them. The record structure stays the same even as the subject changes.
Files are evidence, not the knowledge base
The shared drive is not the enemy. It is simply doing a different job.
Logo files, raw research, interview recordings, campaign exports and creative belong in an asset library. They are evidence and production material. The marketing knowledge base should link to the useful source, state the decision drawn from it and show whether that decision is approved.
A campaign folder can prove what you said last year. Only a decision record tells the next operator what they may say tomorrow.
That distinction also keeps the system lean. You do not need to migrate every old presentation before the knowledge base becomes useful. Move or link the evidence when a live decision depends on it. Leave the rest alone until real work creates a reason to touch it.
In SharpOS, the shared marketing workspace, we separate those jobs. Pages can hold the decision in an organised tree. Properties can show its owner, status and review date. Media Center holds the underlying files. The value is not having three modules. It is keeping the instruction, its state and its evidence connected without pretending they are the same thing.
This does not make process documentation disposable. A checklist tells someone how to publish. The decision record tells them what is safe to publish and why. Keep both, but do not confuse them.
Comprehensive feels safe, but it creates a larger surface to maintain. A smaller knowledge base will omit interesting material. That is the trade. If it answers the next brief correctly, the omission is a feature.
How to keep a marketing knowledge base current
“We will review it every quarter” sounds responsible, but a calendar cannot tell you when the business has changed. Update the knowledge base when a material decision changes, when new evidence overturns an old assumption, or when a repeated question exposes a missing answer.
Practitioner discussions show both ways this goes wrong. In one Front community thread about knowledge base use, contributors described adding guidance only after a question made the gap visible. A ServiceNow community discussion about knowledge base structure described the opposite problem: too many department-led knowledge bases created duplicate categories and made answers harder to find. One system waits too long to capture the answer. The other organises answers around their authors instead of their readers.
Use five rules. The goal is boring but valuable: make the most common questions easy to find, with a clear signal that the answer can be trusted.
- Give every important decision one owner. The owner does not have to write every update, but they approve the current answer.
- Use clear states such as draft, approved and retired. Do not rely on a date to imply whether something is safe.
- Record why the decision changed. One sentence and a link to the evidence are usually enough.
- Add a review trigger. Examples include a new offer, a pricing change, a completed customer research round or a channel that starts producing a different kind of lead.
- Organise around the job the reader is doing, not your internal org chart. A freelancer should not have to know which person originally owned a claim before they can find it.
If nothing has changed, do not rewrite the page to make the system look active. Maintenance theatre creates noise. The goal is trusted information, not a busy revision history.
The 30-minute hand-off test
Give a new writer, freelancer or AI workflow one live brief and 30 minutes with the knowledge base. Do not give them the usual founder download first.
Ask them to find six answers:
- Who is the primary buyer for this brief?
- What problem and offer can they describe?
- Which proof can they publish, and with what caveat?
- Which voice or channel rules apply?
- What action should the reader take?
- Which result will decide whether the work stays or changes?
Then ask them to produce the first outline, page section or campaign concept. The output does not need to be final. You are testing whether the system transfers judgement well enough for someone to start in the right direction.
Watch where they stop. If they cannot tell which of two audience definitions is current, you need an approval state. If the proof exists but takes 20 minutes to find, link it from the claim. If they know the offer but not its boundary, add the disqualifier. Fix the first blockage before expanding the structure.
The test can fail for a reason no tool will fix. If the founder cannot choose the approved answer, the knowledge base is not the bottleneck. The business still has a decision to make. Documentation should expose that gap, not cover it with polished prose.
Build the smallest useful version this week
Start with three records that block the most work: buyer, offer and public proof. Give each one an owner and an approval state. Add only the evidence needed to support the current answer. Add voice, active priorities and measurement rules when a live brief exposes the need.
Then use the system on work that already needs to ship. Do not invent a documentation project beside the real business. Brief the next page, email, ad or content piece from it. When somebody asks a question, decide whether the answer belongs in the knowledge base. When they use an old answer, retire it visibly. When the brief works, keep moving.
The first version can be plain. What matters is whether one person can find the truth, understand its status and act without waiting for the founder. Structure, automation and deeper connections can come after that. If you want to see how the workspace fits the wider engagement, review current SharpHaw plans before the demo.
Plan. Build. Iterate.
Your marketing knowledge base should change when the business makes a decision, not whenever somebody remembers to tidy the wiki. Preserve the current answer and its decision trail, link the evidence and run the hand-off test on a real brief. That is enough to stop starting over.
Want to see the system in practice? Request a demo and see SharpOS in motion, or book a 30-min call to talk through the hand-off problem in your business.
