MarketingOps

WHAT IT IS MarketingOps is the function that makes marketing execute: building and running campaigns, administering the marketing technology stack, managing the lead lifecycle and its scoring, producing attribution reporting, and operating consent and preference management as the legal obligation it is. **Not this:** MarketingOps is not RevOps: it owns the execution machinery of marketing — campaigns, martech, lead lifecycle, attribution and consent — not the revenue process that spans marketing, sales and customer success. WHY IT EXISTS Marketing accumulates tools faster than any other function, and each one holds a partial copy of the same people. The result is duplicated records, campaigns that contact the same person three times, and reporting that cannot be reconciled. Consent raises the stakes: sending to someone who opted out is not an operational embarrassment but a regulatory one, and the mechanism that prevents it is boring integration work nobody volunteers for. WHEN TO USE IT Adopt it when campaign launches depend on one person, when the same contact exists in several systems under different identities, or when nobody can explain how attribution numbers are produced. The consent trigger is immediate: if you cannot demonstrate what someone consented to and when, that gap needs closing before anything else on this page. WHO OWNS IT A MarketingOps function owns the stack, campaign execution and the data model. Marketing leadership owns strategy and budget. Legal and privacy own consent requirements, and MarketingOps owns implementing them faithfully — a dependency that must be a real working relationship, not an annual review. Where records cross into sales systems, the shared model belongs with /revops. WHAT GOOD LOOKS LIKE A person is one record, and the systems agree on which one. Consent and preferences are captured with a timestamp and a source, honoured across every sending system, and demonstrable on request. Campaign execution is repeatable, with templates, a QA step and a defined approval, so launching does not depend on a single person's memory. Lead scoring and lifecycle stages are documented and reviewed against whether they predict anything. Attribution is produced by a stated methodology whose limitations are acknowledged rather than hidden behind a single number. HOW TO IMPLEMENT Start with consent and suppression, because it is the item with legal consequences and it is usually the least owned; verify that a suppression in one system is honoured in all of them. Then deduplicate and agree the identity model. Templatise campaign execution with a QA checklist, which removes both errors and the single-person dependency. Document lead scoring and test whether its output actually correlates with outcomes — most scoring models have never been validated. Write down the attribution methodology and its limits. The privacy obligations are the same ones described in /privacyops. HOW TO ASSESS YOURSELF Unsubscribe a test address in one system and check whether every other system honours it. Count how many systems hold contact records and how they reconcile. Ask how your attribution number is calculated and what it cannot see. Take the scored self-assessment at /assess and sequence with /roadmaps.