Repeatable B2B Client Pipeline Checklist

Use this gate before adding another outbound sequence, paid campaign, partner source, or content channel. Mark every item yes, partial, no, or not applicable. A partial item needs an owner and date; it is not implicit approval.

1. Define the expansion decision

• [ ] The team can state why another channel is being considered.
• [ ] The desired repeatable outcome is named: conversation, accepted lead, opportunity, or revenue.
• [ ] The target segment, offer, market, and cohort window are recorded.
• [ ] Repair, bounded test, and hold are considered alongside expansion.
• [ ] A stop rule exists if the evidence path breaks.

2. Freeze the pipeline record contract

• [ ] Source, entry date, account or segment, owner, and first response are required.
• [ ] Qualification criteria and rejection reasons are written.
• [ ] Stage changes, next step, and outcome dates are captured.
• [ ] Unknown, not applicable, and missing are distinct states.
• [ ] One owner can explain how a record moves between stages.

The Salesforce lead implementation guide is a useful reference for separating capture, qualification, conversion, and handoff. Use the actual client process rather than importing a vendor’s stages unchanged.

3. Check cohort maturity and comparability

• [ ] The chosen cohort has had enough time to reach the decision stage being measured.
• [ ] The comparison cohort uses the same definitions and filters.
• [ ] Offer, market, segment, sales owner, price, and timing changes are annotated.
• [ ] Counts are inspected alongside the underlying records.
• [ ] Small samples are labelled as directional, not as a benchmark.

Do not compare a fresh campaign with a mature cohort and call the difference channel performance. Record the expected commercial lag first.

4. Separate source, influence, and outcome

• [ ] Entry source is stored separately from later touches.
• [ ] Direct evidence and attribution assumptions are visible.
• [ ] Analytics events are reconciled with CRM acceptance and sales outcomes.
• [ ] Multi-touch influence is not presented as incremental causality.
• [ ] The owner of attribution definitions is named.

Google’s GA4 event documentation describes event and parameter structure. It does not make an event a qualified lead or a sale.

If links or forms carry campaign information, Google’s campaign URL guidance can help keep naming consistent. Record the tagging owner and treat missing or changed parameters as a data-quality hold, not as evidence that a channel failed.

5. Test operational capacity

• [ ] Response-time distribution is reviewed, not just the average.
• [ ] Routing, enrichment, follow-up, and exception work have owners.
• [ ] Sales and delivery can absorb the proposed test volume.
• [ ] Manual correction time is recorded.
• [ ] A failure seam has a cheapest discriminating test.

If the current system depends on founder rescue or spreadsheet repair, treat that as a capacity constraint before buying more traffic.

6. Replay a finished cohort

• [ ] The cohort has reached the decision stage being evaluated.
• [ ] Each record can be followed from entry to outcome or an explicit open state.
• [ ] The first missing or contradictory field is recorded.
• [ ] Rejection, no-response, and no-decision reasons are distinct.
• [ ] The replay uses the same field definitions as the comparison cohort.

Replay is a control against dashboard storytelling. A rate can be mathematically correct and still hide a broken handoff, an incomplete sample, or a definition that changed mid-period.

7. Check data quality and lag

• [ ] Duplicate records and missing owners are counted.
• [ ] Stage-age and next-step dates are visible.
• [ ] Immature cohorts are excluded from a final verdict.
• [ ] Calendar lag and working-time lag are distinguished where relevant.
• [ ] The denominator for every stage transition is documented.
• [ ] Event, form, and CRM records can be reconciled for a sample.

The owner should be able to say whether a weak result means low demand, poor fit, slow response, broken routing, sales capacity, fulfilment, or missing data. If not, the next action is diagnosis or instrumentation rather than channel expansion.

Keep the language consistent across the dashboard, CRM, brief, and sales meeting. If one team calls a record “engaged” and another calls it “qualified,” the expansion gate is measuring vocabulary rather than a pipeline. Add a short definition note to the record before comparing cohorts.

8. Set the bounded test

• [ ] The first failure seam has one stated hypothesis.
• [ ] The cheapest discriminating intervention is chosen.
• [ ] Test owner, window, evidence location, and stop rule are named.
• [ ] The test budget and capacity are safe for the current operation.
• [ ] A next decision is scheduled before launch.

9. Preserve the decision record

• [ ] The baseline export, definitions, cohort selection, and filters are stored.
• [ ] The test hypothesis and alternative explanations are versioned.
• [ ] The result is recorded against the same contract used before launch.
• [ ] A failed or inconclusive test has an explicit next step.
• [ ] The team can explain what will not be scaled and why.

10. Set the expansion gate

| Gate | Minimum condition | Action | | — | — | — | | expand | definitions, mature cohort, known seam, capacity, and owner | run bounded test | | repair | evidence path is useful but one stage is broken | fix first | | discovery | decision is clear but baseline or cohort is incomplete | instrument and observe | | hold | qualification, attribution, access, or capacity is unsafe | do not add volume |

Write the test budget, duration, success and failure signals, evidence owner, and next decision before launch. Keep the baseline and replay the cohort after the window closes. A checklist is complete when it makes “more channels” an evidence-based choice rather than the default reaction to a small pipeline.

Store the signed gate with the cohort record so a later reviewer can reproduce the decision.

Keep unresolved holds visible after the test.