A runbook documents how to operate or recover a recurring marketing process. It should help a trained teammate complete the work safely without becoming a long document that nobody updates.
Write for a concrete operational task
Choose a repeatable task such as launching a campaign, refreshing a feed, validating a form, or handling a failed integration. State when the runbook applies and which role owns the outcome.
List prerequisites, access needs, source files, dependencies, and expected result. Link to systems and related policy documents rather than copying details that change elsewhere.
Document checks and failure paths
Show the order of steps and the checks that confirm each one worked. Include common failure symptoms, likely causes, safe recovery steps, and when to escalate.
Explain which changes require approval and what should never be done during routine recovery. A runbook should reduce risk, not enable unrestricted edits.
Make the runbook usable during work
Use short sections, screenshots only where they clarify a step, and clear labels for warnings or irreversible actions. Test the instructions with someone who did not write them.
Keep sensitive credentials out of the document. Reference the approved access process and store secrets in the designated system.
Assign an owner and review trigger
Set a last-reviewed date, responsible owner, and events that trigger an update, such as a platform change or incident. Retire runbooks for processes that no longer exist.
Our campaign calendar guide explains how recurring work and dependencies can be made visible.
Related reading: campaign calendar.
Practical checklist
- Name an owner, an expected result, and the evidence that confirms success.
- Test ordinary, failure, and exception paths before changing live operations.
- Record what changed and review the process when its dependencies change.
How did this article land?
Choose one reaction. You can change it anytime.