Most advice about documenting a marketing ops system falls into one of two buckets. The first is “use Notion.” The second is “write SOPs.” Neither is wrong, but neither is enough. If you have ever sat down to actually document a system you inherited, you know that the hard part isn’t picking a tool or writing a procedure. The hard part is figuring out what to write down, in what order, for whom.
The framework I use now has three layers. I didn’t invent it. It shows up in mature MOps teams, in RevOps frameworks like Winning by Design’s, and in data engineering disciplines that have been thinking about this longer than marketing has. What I did is adopt it deliberately, after watching the typical approach (a single long document that tries to be everything) fail at exactly the moment it was needed.
Here is what the three layers do, and why each one exists.
Layer 1 is architecture. The why.
This is your reference layer. It changes infrequently, quarterly to annually. It contains the things that don’t fit in a database or a checklist: the system map, the data flow, the lifecycle and funnel definitions, the attribution model, the sync architecture, the lead scoring model, the governance principles. It explains what the system is trying to do and how the pieces relate.
This is the layer a new hire reads first. It’s also the layer that gets argued about in cross-functional meetings, because the definitions in it are what align marketing, sales, and leadership on what an MQL actually is, what attribution model the company has chosen, and who owns which fields. If you don’t have a written architecture layer, every conversation about strategy starts from scratch.
Layer 2 is component reference. The what.
This is your encyclopedia. It’s updated continuously as the system evolves. It contains the inventory of every part of the system: every custom property, every active workflow, every list, every form, every integration, with their purpose, their owner, and their dependencies. One row per thing.
This is the layer that does not work as a long document. A document with 491 workflows in it is unsearchable, unfilterable, and unmaintainable. This layer needs to be structured data. Notion databases, a wiki with tables, a spreadsheet that someone maintains, anything that lets you sort by owner, filter by status, and link related items together. The point isn’t the tool. The point is that you can answer the question “what is this field used for” in ten seconds instead of an afternoon.
Layer 3 is operational SOPs. The how.
This is your playbook. It’s updated when processes change. It contains the procedures someone follows to do recurring work: how to set up a webinar campaign, how to upload an event list, how to clone a form for a new gated asset, how to import contacts safely, how to add a new property. One page per process.
This is the layer most people start with, because it feels the most tangible and the most “documentation-like.” But starting here is a mistake. SOPs without an architecture layer above them produce a procedure for doing the wrong thing correctly. SOPs without a component reference next to them produce a procedure that references fields the writer remembers but the reader can’t find. Layer 3 only works when Layers 1 and 2 are in place.
The reason this matters is that each layer answers a different question for a different audience, and conflating them produces documentation that nobody reads. A new hire needs Layer 1 to orient. A teammate diagnosing a problem needs Layer 2 to investigate. A person doing recurring work needs Layer 3 to execute. If you’ve ever written a 60-page operations document that nobody opened, the reason is that it was trying to be all three layers in one place, and each reader had to wade through the other two to find what they needed.
The other reason it matters is sequencing. When you inherit a system, you cannot write all three layers at once. You write Layer 1 first, because you can’t document components or processes coherently without knowing what the system is supposed to be doing. You write Layer 2 next, because you can’t write SOPs that reference fields and workflows you haven’t catalogued. You write Layer 3 last, because it depends on the other two. Teams that try to start with SOPs end up rewriting them when the architecture clarifies, which is most of the cost of documentation done in the wrong order.
If you’re staring at an undocumented system and don’t know where to start, this is the order. Architecture, then components, then procedures. Write the why before the what before the how, and the documentation becomes something people actually use.