# Lead magnet selection matrix: worked fictional example

This example uses a fictional company, **Northstar Relay**. It contains no customer result, conversion claim or live offer.

## 1. Buyer job

| Field | Answer | State (`supplied`, `derived`, `unknown`) |
| --- | --- | --- |
| Buyer problem | A RevOps lead has dozens of lifecycle events but no agreed first set for a reporting pilot. | supplied |
| Buyer decision | Choose exactly three lifecycle events for the first reporting model and assign an evidence owner to each. | supplied |
| Completion state | A three-event data contract with inclusion reasons, definitions, owners and known gaps. | supplied |
| Available source material | The team's event dictionary, CRM field list and data-owner roster; all fictional for this example. | supplied |
| Delivery constraints | Must work in Markdown or a document; no proprietary software or calculation engine. | supplied |
| Update burden | Event definitions can change when CRM stages or product instrumentation change. | supplied |
| Maintenance owner | Revenue Operations Manager. | supplied |

## 2. Candidate mechanisms

| Mechanism | Completes buyer job? | Inputs exist? | Output can be inspected? | Proof boundary is clear? | Owner can maintain it? | Candidate state | Rejection or hold reason |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Structured decision worksheet | yes | yes | yes | yes | yes | viable | Selected because the task ends in a bounded decision and an owned record. |
| Visual model | no | yes | yes | yes | yes | reject | Relationships are secondary; the buyer needs a sequential selection rule. |
| Calculator | no | no | yes | no | no | reject | No validated equation or benchmark exists. Scoring aids discussion but must not pretend to predict revenue. |
| Reference guide | no | yes | yes | yes | yes | reject | Definitions alone would not force a three-event decision. |
| Research report | no | no | yes | yes | no | reject | No sample or research question is needed for this internal decision. |
| Technical framework | yes | yes | yes | yes | no | reject | It would add more maintenance and scope than this first decision needs. |

## 3. Selection

- **Selected mechanism:** structured decision worksheet
- **Mechanism reason:** The buyer must compare supplied events, choose three and assign owners. A worksheet makes the decision, exclusions and gaps visible without requiring a forecast model.
- **Minimum complete version:** Instructions, a four-test event screen, a completed three-event contract, a blank adaptation table and a review checklist.
- **Rejected alternatives:** Calculator → no validated equation; visual model → no relationship map is needed; reference guide → does not finish the selection; research report → no research task; technical framework → excessive scope and maintenance.
- **Unresolved candidates:** None.
- **External questions:** Before a real launch, the owner must verify the final CRM field names and data permissions.
- **First action:** Revenue Operations Manager exports the current event dictionary and marks each event's system owner; complete when every candidate has an owner or an explicit Unknown.

## 4. Proof and maintenance

| Item | Source or owner | State | Allowed use | Missing-input action |
| --- | --- | --- | --- | --- |
| Problem → evidence → unknowns → deliverable sequence | Atlassian Project Poster, https://www.atlassian.com/software/confluence/templates/project-poster | supported | Structural inspiration with attribution; no outcome claim | None |
| Separate a combined measure when operating parts need different diagnosis | Intercom customer-service metrics guide, https://www.intercom.com/blog/customer-service-metrics/ | supported | Editorial reference for separating events and owners; no performance claim | None |
| Northstar Relay event names, owners and systems | Fictional fixture in the completed asset | supported | Worked example only | Replace every fixture value before real use |
| The selected events will improve revenue | No source | excluded | Do not publish | Keep the claim out; measure actual use after launch |

## 5. Readiness

- **Draft decision:** ready
- **Draft hold reasons:** None for the fictional worked version.
- **Draft next action:** Content producer builds the worksheet from the supplied fixture and preserves the source labels.
- **Launch decision:** hold
- **Launch hold reasons:** No final destination, delivery verification or owner approval exists; the example is fictional.
- **Launch next action:** Publisher assigns a final URL, verifies the downloaded bytes and records owner approval before any public launch.