Most marketing process documentation has the same problem.
It gets written during a quiet moment — usually after a campaign went wrong, or during a new hire's first week, or in response to a client asking "how do you actually do this?" It is accurate. It is thorough. It takes a few hours to put together.
And then nobody uses it.
Not because it is bad. Because it was written to describe a process rather than to run one. Those are different things, and they require different approaches.
Why most documentation fails
A document is a record. It captures what was true at the moment of writing. It is useful for reference — for understanding how something works in principle, or for reminding yourself of something you already know.
What a document cannot do is respond to what is actually happening. It cannot say: given that the client has pushed the timeline back by two weeks and the paid campaign has already started, here is the specific sequence of decisions and handoffs you need to make in the next 48 hours.
That is what a process needs to do. And that is why most marketing documentation fails the people who are supposed to use it.
The specific ways it fails are predictable:
It is too linear. The document describes a campaign as if it always unfolds the same way from start to finish. Real campaigns branch. They hit unexpected moments where the right next step depends on what just happened. Documentation that cannot account for this forces the reader to improvise at exactly the moment when they most need structure.
It is written for the person who already knows. The author understands all the context behind every step — why this comes before that, what the common failure modes are, what the right call is when a particular thing goes wrong. Almost none of that context makes it into the document. The result is instructions that make sense to someone who does not need them and are opaque to someone who does.
It describes the ideal case. Most process documentation is written in the form of "here is how a campaign should run." It does not address what to do when the brief changes mid-flight, or when a key team member is unavailable, or when the first test produces no signal. The document assumes success. Real processes have to handle failure.
It is not maintained. The moment something changes — a new tool, a new client requirement, a better way of doing something — the document goes stale. Because updating documentation is invisible work with no immediate payoff, it gets deferred indefinitely. Six months later, the document describes a process nobody actually runs anymore.
The difference between describing and running
A document describes. A process runs.
This distinction sounds simple but it has significant practical implications for how you build your documentation.
A description answers the question: what does this process look like? A runnable process answers the question: what do I do next, given where I am and what just happened?
To build something runnable, you need to think about your process from the perspective of someone who is in the middle of it — not someone who is reading about it before they start.
That perspective shift changes almost everything about how you document.
Instead of writing "step 4: develop the campaign brief," you write: "at this point, you have confirmed the goal and defined the audience. If the client has provided existing brand guidelines, take them to the brief template in section 4a. If they have not, use the brand discovery questions in section 4b before touching the brief."
The first version describes. The second version runs. The difference is a single branch — but that branch is where most briefing processes fall apart in practice, and most documentation pretends it does not exist.
How to build documentation that works
Start by watching, not writing.
The best source for accurate process documentation is observation. Watch the most experienced person on your team run the process from start to finish. Do not ask them to describe it — watch them do it. The description and the reality are almost always different, and it is the reality you want to document.
While you watch, note every decision they make that is not in the existing documentation. Note every moment where they pause and evaluate before acting. Note every place where they do something different from what the written process says. Those gaps are where your documentation needs to be rebuilt.
Map the branches before you write the steps.
Before writing a single step, map every point in the process where the path forks. Where does the right next action depend on what just happened? Where does the process differ based on client type, timeline, budget, or campaign objective?
These branches are the skeleton of a real process. Once you have them mapped, the steps fill in around them naturally. If you write the steps first, the branches never get documented — they end up as tribal knowledge that only the experienced person holds.
Write for the moment of use, not the moment of reading.
Most process documentation is written to be read before a campaign starts — a reference document someone absorbs in advance. The problem is that the moment when documentation is most valuable is not before the campaign. It is during it, when something unexpected has happened and someone needs to know exactly what to do next.
Write your documentation to be useful at that moment. Short sections. Clear decision language. Explicit about what to do when things go wrong. The person reading it is probably stressed, probably short on time, and needs to find the right section fast.
Make decisions explicit.
Every decision point in your process should be documented as a decision — not as a step. The difference:
Step: "Review the campaign brief with the client."
Decision: "Has the client approved the brief? If yes, proceed to asset briefing. If no, schedule a revision call within 48 hours and log the specific objections before the call."
The step tells you what to do. The decision tells you what to do and what to do next depending on the outcome. Every decision point in your process deserves this treatment.
Keep it short enough to use.
The longer the documentation, the less likely it is to be used at the moment it matters. Every section should be as short as it can be while still containing everything someone needs to act.
If a section is getting long, ask whether it is trying to do two things at once. Split it. If it is long because it is trying to account for too many edge cases, ask which edge cases actually happen often enough to warrant documentation. Document those. Leave the rest.
Build in a maintenance trigger.
Documentation that is not maintained becomes misleading faster than no documentation at all. Every process document should have a clear trigger for review — a specific event (new tool, new client type, campaign failure) or a regular interval (quarterly, after every fifth campaign of this type) that prompts someone to check whether the documented process still matches the actual one.
The format question
The format of your documentation matters less than the structure. A well-structured Notion page is more useful than a poorly structured purpose-built tool. A clear Word document with explicit branches beats a complex process diagram that requires translation to use.
That said, some formats make it significantly easier to build documentation that runs rather than describes.
Linear documents — pages, docs, slides — are difficult to use for processes with significant branching. The reader has to hold the branches in their head while reading a linear sequence, which is exactly the cognitive load you are trying to reduce.
Decision trees and flowcharts make branches visible but can become difficult to maintain at any real level of complexity. They also tend to flatten nuance — the specific guidance about what to do in a particular branch — into a box with two words in it.
The most useful format is one that combines a clear step sequence with explicit, easily navigable branches — where each decision point is clearly marked and the specific guidance for each path is immediately accessible without having to leave the main flow.
This is the structural problem Ekaav is built to solve — a format for marketing processes that handles steps, decisions, and branches in a way that is actually usable when a campaign is mid-flight and someone needs to know exactly what to do next.
The test of good process documentation
There is one reliable test for whether your documentation actually works.
Give it to someone who has never run this type of campaign before. Do not brief them. Do not explain anything. Ask them to run a campaign using only the documentation.
Watch where they get stuck. Watch where they make assumptions you did not anticipate. Watch where the documentation fails to tell them what to do when something goes slightly differently from the documented path.
Every place they get stuck is a gap in your documentation. Fix those gaps. Run the test again.
When someone can run the process correctly from the documentation alone — without asking you a single question — the documentation works.
That is the standard worth building toward.
Ekaav is a marketing playbook builder for individuals and teams. Build processes with steps, decisions, and branches — then share them with your team or clients so the work runs the same way every time.