LedgerWorks first names who may create Sales work and which records hold the current rules. This chapter turns that authority into a responsibility record that every later chapter can use.
Marketing Operations requires explicit rules for demand records, handoffs, data quality, and attribution. The method does not address campaign strategy, channel tactics, creative development, or sales methodology.
Decision-bearing demand is a recorded interaction whose admitted evidence is sufficient to support a published demand-state or work-creation decision.
Recorded activity is not yet a decision. Software can capture visits, clicks, downloads, form submissions, campaign membership, and many other events. More captured activity does not by itself make a demand record fit for a business decision. Information-quality research distinguishes accuracy from contextual fitness, representation, and accessibility; a technically correct event can still be irrelevant or unusable for the decision at hand (Wang & Strong, 1996).
Demand becomes operationally useful when the business gives those events stable meaning before Sales is asked to act. Publish the permitted state changes, qualification evidence, routing rules, and attribution policy with named owners. Otherwise sellers must invent screening rules while handling the work.
Variant — local field service. This variant shows how the same decision chain works when service area and job type matter more than company size. A local commercial-services firm captures a pricing-page visit, a newsletter signup, and a request for an estimate. The first two events remain engagement signals. The estimate request becomes sales-ready only after the record meets the firm's service-area and job-type rules. The demand record preserves all three events; the routing workflow assigns only the record whose evidence satisfies the published gate.
Demand Does Not Carry Its Own Meaning
A recurring error is treating behavior as self-explanatory. The same event—an ebook download, webinar registration, or pricing-page visit—can accompany curiosity, research, vendor comparison, or purchase intent. The event count alone cannot distinguish those situations.
Wu, Andreev, and Benyoucef's systematic review examines 44 lead-scoring studies and identifies 14 ways researchers have measured effects on sales performance. The review supports lead scoring as a classification practice while also showing that model choice depends on the integrity and type of available data (Wu, Andreev, & Benyoucef, 2024).
The operating implication used in this book is narrower: qualification criteria must state which evidence represents fit, which represents intent, and what data quality is required before either can be evaluated.
Qualification Changes Cross-Functional Behavior.
Research on the sales–marketing interface reports an association between cross-functional collaboration and business performance (Le Meunier-FitzHugh & Piercy, 2007). That evidence does not establish one universal handoff design. It does establish that the interface is consequential rather than merely administrative.
This method makes the interface inspectable through a shared sales-ready rule and a recorded Sales acceptance event. When Marketing and Sales apply different boundaries, each function can act reasonably and still produce conflicting records.
Response Time Requires a Defined Handoff. Response time is only measurable after the business defines a start event, an end event, and the records to which the expectation applies. "Respond quickly" is not an operating rule. "For inbound demo requests that pass the fit gate, measure from successful routing to the first logged sales action" is.
This book does not prescribe a universal response-time target. The owner sets the target from buyer expectations and available sales capacity, then Marketing Operations instruments the two timestamps and reports exceptions. Faster follow-up cannot repair weak qualification; it only processes weak qualification sooner.
Attribution Rules Change What Gets Credit.
Attribution disputes are frequently presented as tooling problems. The more basic issue is rule choice: different methods assign credit differently, and those assignments change the incentives attached to reported performance.
Berman's model of online advertising shows that last-touch attribution can over-incentivize exposures and produce different profit and allocation effects from a Shapley-value approach (Berman, 2018). The study does not identify one model for every business. It demonstrates that attribution rules are not neutral.
The attribution owner publishes the outcome, eligible touchpoints, time window, credit rule, exclusions, and effective version. The dashboard is only a view of that policy’s output.
Name the Decision Owners
The research supports three bounded propositions: classification depends on data quality, the sales–marketing interface matters, and attribution rules affect incentives. The operating model is prescriptive. It gives the owner a way to turn those propositions into inspectable rules without claiming that every business needs the same lifecycle, platform, or department structure.
Record one mandate: Marketing Operations maintains the definitions, rule implementations, and evidence that turn captured interaction into sales-ready demand. For each consequential gate, name the commercial approver, domain contributors, operator, Sales acceptance owner, and record that holds the current rule. One person may fill several roles; each decision right still needs a name.
Use one decision chain to keep responsibilities distinct:
| Decision | Evidence retained | Owner of the decision |
|---|---|---|
| Admit the interaction | Identity, Account association, context, eligibility, consent, suppression, and policy version. | Audience-policy owner. |
| Treat a signal as evidence | Event, subject, source, time, admissibility, recency, and rule version. | Signal or qualification owner. |
| Mark the instance sales-ready | Separate fit, intent, and data-quality results. | Commercial approver; Marketing Operations implements. |
| Assign sales work | Rules evaluated, winning route, owner, time, fallback, and capacity state. | Sales coverage owner. |
| Accept or reject the handoff | Seller decision, reason, actor, and time. | Sales acceptance owner. |
| Create an Opportunity | Published entry evidence and Sales owner. | Sales or Sales Operations owner. |
| Assign reporting credit | Outcome, eligible touchpoints, window, allocation rule, and version. | Attribution owner. |
LedgerWorks uses the same chain for a guide download, former-customer reply, and assessment request. All three interactions remain visible; only the evidence admitted by the current rules creates seller work.
The work exists even when no employee has the title. Someone decides which interactions become demand, which facts justify sales work, who receives that work, and which definitions reports use. When those decisions stay in private judgment, operators can act reasonably and still produce incompatible records.
Marketing Operations owns the preparation layer between approved commercial inputs and sales execution. It does not choose the offer, target market, sales capacity, privacy policy, territory model, or commercial terms. It converts those decisions into rules that can be applied, tested, and changed visibly.
Inputs, Decisions, and Owners
Marketing Operations responsibility matrix
| Work | Required input | Maintained output | Decision owner | Primary acceptance test |
|---|---|---|---|---|
| Lifecycle and qualification | Approved buyer, offer, sales-ready boundary, and sales capacity. | States, entry and exit evidence, fit-and-intent gate, non-pass and re-entry rules. | Commercial approver owns the boundary; Marketing Operations maintains it. | Two reviewers reach the same state from the same retained evidence. |
| Platform and automation | Published rule, authoritative fields, access, and rollback authority. | Fields, workflows, queues, validation, test cases, monitoring, and change record. | Domain owner approves meaning; platform owner implements. | Ordinary, boundary, exception, and rollback cases behave as specified. |
| Data and attribution | Object model, source policy, outcome, and reporting question. | Source dictionary, attribution rule, timestamps, quality tests, and reconciled views. | Reporting or attribution owner approves; data steward maintains. | A reviewer can reproduce the value from named records and rules. |
| Routing and handoff | Eligible population, coverage and territory inputs, capacity, and response expectations. | Precedence, ownership, fallback, clocks, acceptance, rejection, recycling, and exception handling. | Sales and commercial owners approve work creation; Marketing Operations operates the route. | No eligible record becomes ownerless, and no ineligible record silently creates sales work. |
Centralized, federated, and domain-owned arrangements can all satisfy this matrix. The required feature is explicit decision rights, not one reporting line.
Where Responsibility Ends.
Responsibility for a Demand Instance transfers when Sales accepts the handoff under the published rule. Discovery, negotiation, opportunity management, and closing then belong to Sales and Sales Operations. Marketing Operations may correct an upstream data or routing defect after handoff, but it should not rewrite the sales outcome to make the earlier rule appear successful.
When an upstream decision is vague, the operator records the ambiguity and routes it to the accountable owner. A target-customer statement becomes actionable only when it produces evaluable inclusion and exclusion rules. A capacity limit becomes actionable only when routing can show overload. Exposing an unresolved input is useful work; privately inventing the missing policy is not.
Minimum Viable and Scaled Operation
In a small business, one founder may own campaigns, the CRM platform, sales follow-up, and reporting. The minimum viable operation is a written admission rule, a small lifecycle, a single queue or named owner, controlled reasons, and a weekly review of underlying records. Hiring a specialist changes who performs the work, not the decisions that exist.
At higher volume, separate policy approval from platform administration, use tested releases and rollback, assign data stewardship, and monitor entry paths and integrations. Add process only when an observed exception, risk, or coordination cost justifies it.
Maintain six linked records even when they live in one workbook:
| Record | What it decides | Update trigger |
|---|---|---|
| Object and lifecycle map | What each commercial object and state means and which transitions are permitted. | New object, state, Opportunity boundary, or historical-meaning change. |
| Demand Context and admission policy | Which entry facts are retained and which records may enter processing. | Offer, serviceable buyer, consent, capacity, source, or suppression change. |
| Signal catalog and capture map | Which events and fields exist, what they mean, and which decisions may use them. | New capture surface, mapping, privacy decision, event meaning, or source precedence. |
| Qualification and routing contract | Which evidence creates sales work and which owner receives it. | Gate, coverage, queue, clock, acceptance, or specialist change. |
| Feedback and correction log | What Sales observed and which rule or implementation decision followed. | Acceptance, rejection, recycle, missing outcome, exception, or new version. |
| Measurement and attribution dictionary | How rates, time, source, outcome credit, exclusions, and missing records are calculated. | Event, population, window, model, amount basis, or reporting-use change. |
Each record points to its current owner, approver, effective date, prior version, consumers, and test evidence. The records can be simple; undocumented private judgment cannot serve as their substitute.
Use a Small Operating Cadence
Run three kinds of review:
| Review | Question | Minimum record |
|---|---|---|
| Weekly exception review | Which admitted, routed, rejected, missing, duplicate, or late records require an owner now? | Underlying records, rule versions, assigned actions, and due dates. |
| Release review | Does a proposed field, workflow, integration, gate, route, or report change behave correctly and have a rollback? | Change request, dependency map, scenario results, approver, effective time, and rollback. |
| Policy review | Do commercial inputs, capacity, acceptance behavior, and evidence still support the current admission and handoff rules? | Cohort counts, uncertainty, exceptions, alternatives, and signed keep or revise decision. |
The frequency is a local choice. High-risk or high-volume changes may require more frequent review; stable low-volume operation may need less. Do not create a standing meeting without a decision, records, and an owner.
A change request states the business problem, current rule, proposed rule, affected objects and consumers, evidence, specialist decisions, test cohort, expected trade-off, effective date, and rollback. Marketing Operations may recommend the change, but the named domain owner approves the meaning.
LedgerWorks Responsibility Record.
LedgerWorks names its Marketing Operations manager as lifecycle, platform-rule, and source-dictionary maintainer. The sales leader approves any rule that creates seller work and owns acceptance policy. The privacy owner approves communication and consent treatment. The founder approves changes to the serviceable-buyer definition. One responsibility record stores those decisions, effective dates, and the field or document that holds each rule.
Conclusion
The responsibility record now distinguishes captured interaction, decision-bearing demand, and accepted Sales work, assigns each decision to an owner, and records the cadence and change path for the working rules.
Chapter glossary
- Decision-bearing demand: A recorded interaction whose admitted evidence is sufficient to support a published demand-state or work-creation decision.
- Response time: Elapsed time between a defined handoff start event and a defined permitted response event for an eligible record.
- Demand decision chain: The ordered decisions that admit an interaction, treat signals as evidence, qualify demand, assign work, accept the handoff, create an Opportunity, and allocate reporting credit.
- Marketing Operations decision rights: The explicit boundary between rules Marketing Operations may implement or maintain and meanings another commercial, Sales, privacy, Finance, or platform owner must approve.
- Operating records: The linked, versioned records for objects and lifecycle, context and admission, signals and capture, qualification and routing, feedback and correction, and measurement and attribution.
- Exception review: A review of admitted, routed, rejected, missing, duplicate, or late records that require an owner and action now.
- Release review: A pre-release decision on whether a proposed field, workflow, integration, gate, route, or report behaves correctly and can be rolled back.
- Policy review: A decision on whether commercial inputs, capacity, acceptance behavior, and evidence still support the current admission and handoff rules.
- Change request: The record of the current and proposed rule, affected objects and consumers, evidence, specialist decisions, test cohort, trade-off, effective date, and rollback.
- Responsibility record: The record that assigns each material rule, approval, effective date, and implementation location to a named owner.