Revenue Leak Repair Plan

Loop Step

Repair

Purpose

Turn a prioritized leak into an accountable, verifiable repair. One plan entry per leak: the link it sits in, the evidence, the baseline, the estimated economic impact, the root-cause hypothesis, the selected repair and the resource/playbook that carries it, the owner (and backup), the dates, the single KPI and target that will prove or disprove closure, the QA requirement, the verification date, the measured result, the status, and the next action. The plan is the bridge between installing a repair and verifying it.

Governing Rule

Installing a workflow completes implementation, NOT closure. A plan entry is not 'closed' until its verification metric is re-measured (RLR-42) and passes the Closure test (RLR-45 / Manual Step K). The status vocabulary enforces this distinction: a repair can be IN PROGRESS or even QA-passed and still not be CLOSED.

Works Across All Six Links

Note

Validated Phase 2H. One plan entry can describe a leak in any of the six links; the link field and the resource/playbook field carry the routing. The plan does not assume a link-specific schema.

Entry Status Vocabulary

Reopen Handling

Policy

If re-measurement fails the Closure test or a MONITORING entry regresses, the entry is REOPENED — returned to VALIDATING/PLANNED via the Priority Matrix (RLR-06). Reopened entries are never silently deleted, and their prior result is retained for the audit trail.

Reopened From

verifying; monitoring; closed

Legacy Status Mapping

Note

The prior 1.0.0-draft four-state vocabulary maps forward so earlier references remain valid.

Planned

planned

Implemented unverified pre QA

in_progress

Implemented unverified post QA

verifying

Verified closed

closed

Reopened

handled by reopenHandling (returns to validating/planned)

Entry Schema

Note

One row per leak. Every column is required unless marked optional; blanks are recorded as UNKNOWN, never guessed.

Rules

• One leak, one repair, one measurable metric per entry. Do not batch unrelated repairs into a single entry or change window, or you cannot attribute the result.
• The verification KPI MUST equal the baseline metric measured by the same method (per RLR-35) over a comparable window.
• Estimated economic impact is a modeled figure (from the Calculator, RLR-05) and is labeled an estimate — it is never recorded as measured recovered revenue.
• An entry cannot move to CLOSED unless its QA requirement passed (RLR-41) AND the re-measurement passed the Closure test (RLR-45).
• Recovered contribution is recorded on the Recovered Revenue Tracker (RLR-44) only for entries at CLOSED.
• Insufficient evidence stays at VALIDATING with a measurement plan; it is never forced to PLANNED or CLOSED.
• Reopened entries return to the Priority Matrix; they are never silently deleted.

Entries

Note

Blank instrument. No fabricated repairs, dates, owners, or recovered figures are pre-filled; the user creates one entry per prioritized leak.

Linked Instruments

Prioritize From

RLR-06 Revenue Leak Priority Matrix

Quantify With

RLR-05 Revenue Leak Calculator (estimated economic impact only)

Define Metrics With

RLR-35 Revenue Chain KPI Dictionary

Implement With

RLR-40 Workflow Implementation Checklist

Qa With

RLR-41 Revenue Chain QA Test Script

Re Measure With

RLR-42 14/30-Day Revenue Leak Re-Diagnostic

Compare With

RLR-43 Before/After Revenue Chain Scorecard

Record Recovery With

RLR-44 Recovered Revenue Tracker

Close With

RLR-45 Revenue Leak Closure Checklist

Compliance Guardrail

The plan stores only the operational and outcome data a repair requires, under the business's approved privacy, retention, and consent policy. It does not instruct any action that bypasses opt-out, suppression, provider, or consent controls; jurisdiction- and industry-specific rules are applied by the operator.