insights scan boundary

Revenue Leak Taxonomy: 10 diagnostic surfaces and the evidence each needs

Direct answer. A revenue leak is a failure, blind spot, handoff defect, or unverified loss mechanism inside a revenue system. The label identifies where value may degrade and what should be tested; it does not prove that money was lost. Verification requires evidence appropriate to the surface, from a bounded public observation through reproduced behavior, internal execution records, and—where available—a reconciled outcome.

related system · Revenue Systems Diagnostic · Revenue OS audience · Revenue, operations, marketing, CRM, sales, and systems leaders who need a shared language for investigating failure before choosing a repair.

How to use this taxonomy

Use the taxonomy to name the surface that owns a suspected failure, record what was actually observed, keep at least one competing explanation alive, and choose the smallest next test that could change the decision. A “leak” remains a hypothesis until the evidence supports a narrower finding.

The ten surfaces are horizontal: they apply to appointment-led, quote-driven, high-ticket, recurring, multi-location, and other operating models. The exact workflow differs by business, but the evidence discipline does not.

Revenue Leak Taxonomy map grouping ten diagnostic surfaces across demand, handoff, record, measurement, lifecycle, and control layers. — Ten diagnostic surfaces. The map locates the investigation; it does not establish frequency, financial impact, or a cause.

The public-vs-internal evidence boundary

Public evidence can establish a bounded visible fact: a path returned a status, a field was present, a CTA led somewhere, a permissioned synthetic action produced a visible state, or metadata carried a value. It cannot establish internal execution, population frequency, commercial qualification, financial impact, or causality. Those claims need the corresponding system records and a defined scope.

Absence of public evidence is not evidence that an internal process is absent. Equally, a clean dashboard is not proof that the underlying records, definitions, and exceptions reconcile. The safe question is not “is there a leak?” but “what does this evidence establish, what remains possible, and what would resolve the uncertainty?”

Evidence ladder E0–E4

Level	State	What it supports	What it still does not support
E0	Unverified statement	A question worth testing from a recollection, concern, or inventory.	A finding.
E1	Public observation	A bounded visible fact such as a path, field, status, confirmation, or metadata value.	Internal execution, frequency, or impact.
E2	Reproduced behavior	A repeatable result under recorded, permissioned conditions.	Population-wide rate or financial impact.
E3	Internal operational evidence	A configured or executed internal state such as a rule, workflow run, CRM history, task, or delivery record.	Downstream impact without reconciliation.
E4	Reconciled outcome evidence	A joined result across systems for a defined scope, including exceptions.	Causal certainty beyond the design and data.

Confidence scale C0–C4

Level	Meaning
C0 — Unknown	No usable evidence; the statement remains a question.
C1 — Tentative	One weak or indirect signal is recorded; alternatives remain broad.
C2 — Supported	Reproduced public behavior or one strong internal source supports the defined statement.
C3 — Corroborated	Two independent evidence types agree and at least one is operational or reconciled.
C4 — Verified	Input, rule, output, owner, timestamps, and exceptions are traced for the defined scope.

Evidence-to-finding flow from observation to hypothesis, reproduction, internal verification, and reconciled outcome. — Observation → hypothesis → reproduced behavior → internal evidence → reconciled outcome. Implementation should follow the evidence and confidence gates, not precede them.

The ten revenue-leak surfaces

Acquisition

Owns. The source, campaign, creative, destination, and capture identifiers that connect intended demand to the next controlled surface.

Observable signal: A campaign destination fails, campaign context disappears, or the promise in the source does not match the landing experience.
Competing explanations: A temporary edge or browser condition produced the failure.
The observed campaign is old, paused, or outside the active operating scope.
Public evidence can establish: The observed destination, response, visible message, and identifier state at a recorded time.
Public evidence cannot establish: Spend, audience quality, campaign volume, internal lead creation, incremental demand, or financial impact.
Internal evidence required: Source configuration, click and event records, destination mapping, capture records, campaign state, and exception logs.
Responsible owner: Demand generation or marketing operations, with a named owner for destination and identifier governance.
Smallest useful verification: Reproduce one permissioned source-to-destination path and reconcile its identifiers with the first internal capture record.
Possible implementation owner: Acquisition and source-capture infrastructure in Revenue OS, when verified work is justified.
Claim boundary: A broken or inconsistent public path is a bounded acquisition observation; it is not evidence of total affected demand or lost revenue.

Conversion

Owns. The public path by which a visitor understands the offer, supplies permitted information, and reaches a truthful completion or recovery state.

Observable signal: A CTA is broken, a required field is unclear, mobile layout blocks completion, or a success state lacks a next step.
Competing explanations: The issue is isolated to one viewport, browser, or transient deployment.
The path is intentionally unavailable for a disclosed operating reason.
Public evidence can establish: Visible content, route behavior, validation, accessibility state, and the result of a permissioned synthetic journey.
Public evidence cannot establish: Internal record delivery, conversion rate, lead quality, follow-up, or commercial loss.
Internal evidence required: Request and response state, form record, delivery receipt, accessibility result, downstream record, and exception disposition.
Responsible owner: Web or product owner together with the operating team that receives the captured action.
Smallest useful verification: Run one synthetic journey under recorded desktop and mobile conditions, then trace the resulting internal record only when authorized.
Possible implementation owner: Conversion-path and lead-capture infrastructure; the Sample Scan shows the bounded finding shape.
Claim boundary: Visible friction supports a conversion-path finding only for the recorded conditions; it does not establish population frequency or outcome.

Routing

Owns. Normalization, matching, assignment, fallback, acceptance, escalation, and exception handling after capture.

Observable signal: A public confirmation gives no ownership or recovery context, or a permissioned synthetic handoff reaches an unexpected state.
Competing explanations: The record was intentionally routed to a queue not visible from the public path.
Identity matching updated an existing record instead of creating a new one.
Public evidence can establish: Only the public or synthetic handoff state that was directly observed.
Public evidence cannot establish: CRM assignment, notification delivery, queue state, staff action, or response performance.
Internal evidence required: CRM record history, routing-rule version, workflow run, queue state, ownership changes, timers, and exception disposition.
Responsible owner: Revenue operations or CRM operations, with a fallback owner for unmatched records.
Smallest useful verification: Trace one approved record from normalized input through matched or unmatched routing and document the fallback result.
Possible implementation owner: CRM and pipeline automation, routing rules, monitored fallbacks, and exception queues.
Claim boundary: A public handoff cannot prove an internal routing failure; routing becomes a finding only when execution evidence supports the defined scope.

Booking

Owns. Meeting-type eligibility, calendar routing, timezone behavior, availability, confirmation, rescheduling, cancellation, and recovery.

Observable signal: The intended calendar is unavailable, attribution drops, timezone behavior is unclear, or a confirmation path fails.
Competing explanations: The meeting type is intentionally restricted or temporarily unavailable.
A provider or network condition affected only the observed session.
Public evidence can establish: The visible scheduler state and a permissioned synthetic path up to—but not including—an unauthorized real booking.
Public evidence cannot establish: Attendance, sales quality, qualification, close probability, or revenue.
Internal evidence required: Scheduler configuration, event record, routing result, confirmation state, attribution fields, and cancellation or exception log.
Responsible owner: Sales operations, customer-facing operations, or the team accountable for calendar and meeting-type configuration.
Smallest useful verification: Inspect configuration and use an approved synthetic booking contract that creates no real appointment unless the test owner authorizes it.
Possible implementation owner: Booking and conversion paths, calendar routing, confirmation, reminders, and recovery workflows.
Claim boundary: A visible booking blocker does not prove how often qualified buyers encounter it or what any missed appointment was worth.

CRM ownership

Owns. The system of record, lifecycle contract, accountable record owner, stage meaning, identity rules, tasks, and exceptions.

Observable signal: The public path does not disclose an owner or response state, or teams report unowned, duplicated, or ambiguous records.
Competing explanations: Ownership exists internally but is intentionally not public.
A team uses a valid queue or pooled-ownership model rather than individual assignment.
Public evidence can establish: Little beyond the visible handoff language; ownership is primarily an internal-state question.
Public evidence cannot establish: Record existence, lifecycle stage, assigned owner, deduplication behavior, task state, or governance.
Internal evidence required: CRM schema, record and owner history, stage rules, deduplication logic, task state, role definitions, and a reconciled sample.
Responsible owner: Revenue operations or the accountable CRM product owner, with business owners for stage and follow-up definitions.
Smallest useful verification: Select a bounded approved sample and trace identity, owner, stage, task, timestamps, and exceptions against the current rule version.
Possible implementation owner: CRM and pipeline operating layer, including ownership, lifecycle, task, and exception contracts.
Claim boundary: No public scan can verify CRM ownership. Internal records are required before the issue can be called a CRM finding.

Follow-up

Owns. Trigger conditions, timing, channel, sequence state, delivery, reply handling, stop rules, escalation, and accountable human action.

Observable signal: A public confirmation provides no next-step expectation, or a permissioned test reveals duplicated, late, or disconnected messages.
Competing explanations: The visible copy is incomplete while internal follow-up is healthy.
A message was intentionally suppressed by consent, deliverability, or lifecycle rules.
Public evidence can establish: The visible confirmation and, only with permission, the messages received by the synthetic test identity.
Public evidence cannot establish: Population coverage, staff behavior, workflow state, reply handling, qualification, or downstream outcome.
Internal evidence required: Trigger record, workflow or sequence run, delivery state, task history, reply state, stop-rule evidence, suppression state, and owner review.
Responsible owner: Sales or service operations together with marketing or CRM operations for automated sequences.
Smallest useful verification: Trace one approved record from trigger through each expected state, including reply, suppression, failure, and human fallback.
Possible implementation owner: Follow-up automation, speed-to-lead timers, missed-call recovery, escalation, and human-review paths.
Claim boundary: One missing or duplicated message supports only the recorded path; it does not establish intent, overall coverage, or revenue impact.

Attribution

Owns. The definitions and keys that connect source, touch, cost, identity, CRM state, opportunity, and outcome records.

Observable signal: Campaign context disappears, visible events conflict, or different reporting surfaces assign different sources.
Competing explanations: The systems use different but documented attribution models or windows.
Privacy, consent, identity resolution, or offline behavior limits the visible join.
Public evidence can establish: Visible parameter preservation, browser-emitted requests, public metadata, and behavior of a permissioned synthetic path.
Public evidence cannot establish: The full source-to-outcome join, incrementality, causal credit, model correctness, or commercial impact.
Internal evidence required: Data dictionary, raw events, transformation rules, identity keys, consent state, CRM and outcome records, cost data, and reconciled exceptions.
Responsible owner: Marketing operations, analytics, or revenue operations with an agreed data-definition owner.
Smallest useful verification: Select one bounded journey and reconcile its source keys through raw event, transformation, CRM, and outcome records with exceptions visible.
Possible implementation owner: Tracking and attribution systems, offline outcome joins, data contracts, and reconciliation controls.
Claim boundary: Attribution is a defined model, not causal certainty ^{[ga4_attribution]}. A visible parameter gap does not quantify misattributed revenue.

Reporting

Owns. Metric definitions, source lineage, transformations, refresh state, filters, access, versioning, exceptions, and decision context.

Observable signal: Two visible totals conflict, a report is stale, a filter is hidden, or a displayed stage definition differs from the operating language.
Competing explanations: The reports intentionally use different scopes, timezones, windows, or models.
A refresh or access delay affected the observed state without changing source records.
Public evidence can establish: Only the visible label, value, filter, timestamp, and state that was directly observed.
Public evidence cannot establish: Calculation correctness, data lineage, operational cause, completeness, or financial impact.
Internal evidence required: Metric and query definitions, lineage, transformation and refresh logs, filter state, version history, a reconciled sample, and an exception register.
Responsible owner: Analytics, finance, or revenue operations, with one accountable definition owner per decision metric.
Smallest useful verification: Trace one decision-critical value back to source records and reconcile the defined scope, calculation, refresh, and exceptions.
Possible implementation owner: Reporting and intelligence systems, metric contracts, lineage, reconciliation, and exception visibility.
Claim boundary: A dashboard is a presentation surface. It is not evidence of correctness or operational cause until its records and logic are traced.

Reactivation

Owns. Eligibility, lawful and policy-aligned contact state, suppression, cohort construction, workflow execution, reply handling, and final disposition.

Observable signal: Dormant demand appears to have no visible re-entry path, or a permissioned test shows an inconsistent lifecycle or suppression state.
Competing explanations: The business intentionally excludes the cohort because consent or value is unclear.
Reactivation occurs through a channel or workflow not visible on the public surface.
Public evidence can establish: A visible re-entry option or public lifecycle path, but little about internal eligibility or contact governance.
Public evidence cannot establish: Eligibility, consent, suppression, contact appropriateness, workflow coverage, incrementality, or profitability.
Internal evidence required: Eligibility definition, consent and suppression state, cohort query, workflow run, delivery and reply state, owner decision, and disposition.
Responsible owner: Lifecycle marketing or customer operations with privacy, legal, and data owners where applicable.
Smallest useful verification: Define a small approved cohort and reconcile eligibility, consent, suppression, delivery, reply, and disposition before scaling.
Possible implementation owner: Governed lifecycle and reactivation workflows, with suppression, stop rules, ownership, and observability.
Claim boundary: Dormancy does not make contact appropriate, and a reactivation workflow does not prove incremental or profitable demand.

Observability

Owns. State transitions, correlation, logs, alerts, exception queues, retry policy, runbooks, rollback, recovery, and final disposition across every surface.

Observable signal: A visible failure offers no recovery, a system state cannot be correlated, or operators cannot identify who owns an exception.
Competing explanations: Internal monitoring exists but is not visible or accessible to the observer.
The observed path is intentionally low-risk and uses a different recovery contract.
Public evidence can establish: The visible error, fallback, status, and recovery instruction on the public path.
Public evidence cannot establish: Internal alert delivery, log completeness, retry execution, queue health, runbook use, or recovered outcome.
Internal evidence required: State-transition events, correlation IDs, traces and logs, alert receipt, exception queue, retry record, runbook, rollback evidence, and final disposition.
Responsible owner: The technical or operational service owner, with a named human owner for exceptions and recovery.
Smallest useful verification: Induce one safe synthetic failure and trace detection, ownership, retry or fallback, recovery, and final state without contacting a real customer.
Possible implementation owner: Cross-module observability, failure handling, exception queues, runbooks, and accountable operating ownership.
Claim boundary: The absence of a public alert does not prove absent monitoring; the presence of monitoring does not prove that failures were prevented or resolved.

The compact finding-record model

A useful diagnostic does not stop at a label. It leaves a record another operator can challenge, reproduce, and close. Keep the “what is not established” field beside the observation so the limitation cannot be separated from the claim.

Field	Required content
Finding ID	Stable identifier for the bounded record.
Surface	One primary taxonomy surface; note secondary surfaces separately.
Observation	The smallest factual statement supported by the current evidence.
Evidence source and level	Reference, collection method, timestamp, access class, and E0–E4.
Confidence	C0–C4 with a short rationale.
Competing hypotheses	At least one plausible alternative explanation.
Scope	Path, record set, time window, system version, and exclusions.
What is not established	Frequency, internal state, outcome, causality, or other unsupported claims.
Owner	Person or team accountable for verification and disposition.
Next verification step	The smallest safe test that could change the decision.
Repair candidate	Possible change, explicitly conditional on verification.
Retest condition	Input, expected state, exception path, and evidence needed to close the record.

Compact revenue-system finding record template showing evidence, confidence, hypotheses, scope, limitation, owner, next verification, repair, and retest fields. — A finding record keeps evidence, limitation, ownership, and the next decision in one reviewable unit.

Prioritize without inventing financial impact

Prioritization is a decision about verification and sequencing, not a license to fabricate value. Start with evidence strength and operational consequence, then adjust for reversibility, verification cost, implementation dependency, and whether an accountable owner can run the test.

Evidence / consequence	Low operational consequence	High operational consequence
Weak evidence	Record the question, avoid building, and seek a cheap discriminating test.	Contain only if the failure mode is unsafe; otherwise verify quickly before committing to a repair.
Strong evidence	Schedule the smallest reversible repair and define its retest.	Assign an owner, preserve rollback, resolve dependencies, repair, and reconcile the outcome for the defined scope.

Fictional worked example: Northstar Advisory

Fictional example — synthetic facts only. Northstar Advisory is a made-up quote-driven service business. A permissioned synthetic journey preserves campaign context on the landing page, but the visible booking handoff drops it and the confirmation gives no recovery instruction. That is an E2 conversion and booking observation at C2; it does not establish CRM delivery, lead quality, frequency, or financial impact.

Keep alternatives open. The scheduler may intentionally discard unsupported fields; a separate server-side join may exist; or the observed session may not represent the current production configuration.
Request internal evidence. With authorization, the owner inspects the scheduler configuration, one synthetic event record, the corresponding CRM history, the source-field mapping, and any exception log.
Narrow the findings. The event record shows a completed booking but no source value; the CRM record is assigned correctly; an observability check shows no alert for the dropped field. The attribution gap is E3/C3 for the defined test, while routing is disproved for that record.
Repair conditionally. Preserve the allowlisted source fields at the scheduler boundary, add a test for unsupported and private parameters, and alert on mapping failure. Retest the same synthetic path and reconcile the source value into the approved internal record.
Respect the ceiling. Even after the field is reconciled, the test establishes correct propagation for the defined path—not incremental demand, causal credit, or financial recovery.

Map verified findings to implementation ownership

A verified finding should map to the smallest system owner capable of repairing and observing it. The mapping below is a routing aid, not a claim that every finding needs OmniLabs, every business needs Revenue OS, or every observed symptom needs a build.

Taxonomy surface	Possible implementation owner
Acquisition · Conversion	Source capture, landing experience, lead capture, and conversion-path infrastructure.
Routing · CRM ownership	CRM and pipeline operating layer, assignment, fallback, lifecycle, and exception contracts.
Booking · Follow-up	Scheduling, speed-to-lead, reminders, recovery, replies, escalation, and human review.
Attribution · Reporting	Tracking, data definitions, joins, lineage, reconciliation, and decision-ready reporting.
Reactivation	Eligibility, suppression, lifecycle, delivery, reply, and disposition workflows.
Observability	Cross-module events, traces, alerts, exception queues, runbooks, rollback, and accountable ownership.

Map from the ten Revenue Leak Taxonomy surfaces to possible Revenue OS implementation ownership, with verification as the gate. — The diagnostic surface identifies the owner to investigate. Verification determines whether implementation work is justified.

Operator checklist

Name one primary surface and record the exact observation without interpretation.
Assign E0–E4 and C0–C4; explain both in plain language.
Write at least one plausible competing hypothesis.
State the scope and what is explicitly not established.
Identify the internal evidence and accountable owner needed to narrow the claim.
Choose the smallest permissioned verification that could change the decision.
Separate containment from permanent repair when consequence is high but evidence is weak.
Make the repair reversible where possible and define the failure path before launch.
Retest the input, rule, output, owner, timestamps, and exceptions.
Close, revise, or disprove the finding; do not leave the original hypothesis presented as fact.

Limitations and claim boundaries

“Leak” is a diagnostic classification, not a verified financial loss.
A public observation supports only the bounded visible fact.
A reproduced synthetic path does not establish population frequency.
Internal execution evidence does not establish downstream outcome without reconciliation.
A reconciled outcome supports the defined relationship, not causal certainty beyond the design and data.
Absence of evidence is not evidence of absence.
No public scan can prove internal behavior, commercial qualification, financial impact, or the value of a repair.

Continue from taxonomy to diagnosis

Use the Revenue Systems Diagnostic Methodology for the complete workflow, evidence policy, confidence model, and prioritization rules. The Sample Scan shows how a fictional bounded finding reads. Revenue OS describes possible implementation ownership after verification. A completed scan is not required to book a Diagnostic Review, and the current asynchronous Revenue Scan intake remains intentionally dormant.

Source and evidence notes

ove_master_positioning OmniLabs Systems studio master positioning (first-party). Supports horizontal systems scope and the Revenue OS ownership language. Limitation: First-party positioning only; not external proof of outcomes, rankings, citations, traffic, leads, or revenue.
ove_site_live_verification Site entity/canonical live verification (first-party). Supports that the methodology, Sample Scan, Revenue OS, and Diagnostic Review surfaces are current Site owners. Limitation: Technical/entity verification only; not proof of scan efficacy, lead, or revenue impact.
ga4_attribution Google Analytics, "Get started with attribution." Context that attribution is a documented model-based concept and a measurement boundary. Limitation: Platform documentation; no performance claim or client measurement evidence.
hubspot_lifecycle_stages HubSpot, "Use lifecycle stages." Context that lifecycle stages are a documented way to structure CRM follow-up. Limitation: Vendor documentation; not a universal model or outcome proof.
google_tag_manager_server_side Google Tag Platform, "Server-side tagging." Context for deliberate event collection architecture. Limitation: Technical documentation; no proof of better attribution or revenue.

Related entities

[CLAIM BOUNDARY] “Leak” is a diagnostic classification, not a verified financial loss. Public observations establish only bounded visible facts; internal-state, frequency, outcome, and causal claims require corresponding internal and reconciled evidence.

Book Diagnostic Review Back to insights