Marketing operations documentation: what to write down and where the change log fits

What is marketing operations documentation?

Marketing operations documentation is everything a new teammate would need to run your marketing without asking you: how the stack is wired, how recurring work is done, which rules apply, and what changed and when. It is less about long manuals and more about short, findable pages that stay current.

Most teams already have pieces of it scattered across a wiki, a shared drive, platform settings and people's heads. The problem shows up at three moments: when someone new joins, when an account changes hands, and when a client or a boss asks why results moved. Forrester's advice on marketing and sales technology puts the first one bluntly: the last thing a new associate should be doing is clicking around in a marketing automation platform to learn how it works.

Think of it as four layers: reference (what exists), procedure (how to do recurring work), rules (what everyone must follow) and history (what changed). Teams usually write the first three and forget the fourth, which is the one you need when a metric drops.

What should a marketing ops team document?

Document what is hard to rebuild from memory and what breaks results when it is done differently by two people. The table below is a practical starting set; each row should have a named owner and a clear trigger for updating it.

Forrester's list overlaps with this: it names lead scoring, nurturing and assignment programs, reporting processes and roles as the things to keep written outside the platforms. Naming rules deserve their own page because a silent rename can split a report in two; see our post on UTM naming conventions for a template.

How do I write a marketing runbook people actually use?

Write a runbook for one recurring task, in the order someone would do it, with the checks that prove it worked. If a step depends on judgement, say who decides. Keep it to one screen when you can.

1. Name the task and the owner
2. List the steps in order
3. Add the check after each step
4. Say what to log when done

A good runbook for a budget increase, for example, would say where to change the budget, the maximum step size your team agrees on, what to check the next morning, and that the change goes in the change log with the reason. The last step is the one that turns a procedure into history you can read later.

Atlassian's incident handbook describes playbooks that bundle runbooks, checklists and templates so a team responds the same way every time. The same idea works for marketing: one folder per process, short pages, and a link to where the result is recorded. Runbooks also make handovers faster; our agency handover checklist lists what to pass on when an account changes hands.

Where does the change log fit in your documentation?

The change log is the history layer: it records what actually happened, while runbooks and rules describe what should happen. Without it, your documentation can tell a new hire how to launch a campaign but not why conversions fell last March.

Each platform keeps part of that history. Google Ads Change history shows changes from the past 2 years, with the user's email for edits made in the interface and entries such as "Google Ads system" for automated ones. Google Tag Manager keeps a publish history of who published each version and lets you add a version name and description. GA4 lets Analysts and above add annotations (60-character title, 150-character description, up to 1,000 per property). None of them sees the others, or your landing page, CRM or pricing edits.

So the change log sits across all of them: one entry per change, with date, platform, owner, reason and expected effect. Our marketing change log guide explains the format, and the change log template gives you the columns to start with.

Example: a client asks on Wednesday why leads dropped on Tuesday. The runbooks show that launches follow the checklist, so the team opens the change log instead. It lists a Google Ads target CPA cut on Friday, a new form on the landing page on Saturday and a GTM version published on Monday. The form had lost its thank-you page redirect, so the lead event stopped firing. Leads in the CRM were flat; only the tracked count fell.

How do I isolate which change caused a drop using your documentation?

Use the documentation in a fixed order: confirm tracking against the tracking plan, then list every change from the days before the drop, then test one hypothesis at a time. The stack map tells you where to look; the change log tells you what moved.

1. Rule out tracking first. Compare the platform number with the source of truth named in your tracking plan (CRM, orders, form submissions). If only one side fell, it is a measurement problem.
2. Pull every change from the window. Take the 7 to 14 days before the shift from the change log, then fill gaps from Google Ads Change history and the GTM version list.
3. Check against the runbooks. A change made outside the documented procedure (no check the next morning, no reason logged) is a prime suspect.
4. Test one hypothesis at a time. Revert or segment by the one change you suspect most and watch the metric, instead of undoing everything at once.

With every change on one timeline, the example above takes minutes: the GTM version sits one day before the drop, right after a form change, and that is where you look first. Changeline keeps that timeline per client project: Google Ads changes can be imported automatically through a read-only connection, and the team logs the rest (site, tracking, CRM, pricing) with owner and reason. For the full method, see the guide on how to explain a conversion drop to a client.

How do you keep marketing ops documentation up to date?

Tie each document to the event that makes it stale, and make updating it part of finishing the work. Documentation goes out of date when it lives apart from the work; it stays current when the last step of a task is to update it.

Three habits do most of the work. First, a named owner for each page, so "someone should update this" has an answer. Second, a short review on a fixed rhythm, monthly for the change log and tracking plan, quarterly for runbooks and roles. Third, a rule that no change goes live without an entry: the person who changes the budget, the tag or the form writes one line with the reason.

If you already run a review process, our post on marketing change management shows how to add approvals without slowing launches, and the campaign post mortem post shows how to turn a bad week into better runbooks.