How to design a lead lifecycle for multi-touch sales

Every sales organization has a lead lifecycle. Most never wrote it down. The lifecycle lives in the manager's head, in the CRM's stage picklist, in a slide from two years ago. Different people use different definitions of "qualified." Reports based on those definitions disagree.

A well-designed lead lifecycle is a state machine with explicit transitions and an explicit definition of what progresses each state. Here is how to design one that holds.

Step 1: Use the six canonical states

The lifecycle does not need to be original. Six states cover almost every B2B sales motion:

• NEW. The lead exists. Nobody has done anything with it.
• CONTACTED. Someone has attempted outbound. The attempt is documented.
• QUALIFIED. The prospect is a real candidate. Budget, authority, need, timeline (or equivalent) confirmed.
• PROPOSAL. A formal proposal has been sent.
• NEGOTIATION. Active back-and-forth on terms.
• WON. Deal closed.

This is a directed acyclic graph: most transitions go forward. NEW becomes CONTACTED. CONTACTED becomes QUALIFIED. QUALIFIED becomes PROPOSAL. And so on.

If your motion has more than six states, you are probably encoding things in stages that belong elsewhere (a stage for "demo scheduled" might be better as a task attached to a CONTACTED lead). Simpler is more durable.

Step 2: Add the orthogonal states

Beyond the linear progression, four states represent outcomes that can occur at any time:

• UNQUALIFIED. Determined not to be a real candidate. From CONTACTED or later.
• LOST. Lost to a competitor or to no decision. From QUALIFIED or later.
• ON_HOLD. Active but waiting on the prospect. The SLA pauses.
• DUPLICATE_OF. This lead is a duplicate of another, merged. Hidden from default views.
• ARCHIVED. Cleared from active queues but preserved for historical analysis.

Each of these is an explicit state, not a checkbox on the lead. Reports filter by state. Routing rules can include or exclude based on state.

Step 3: Define valid transitions

A state machine needs an explicit list of valid transitions. Some examples:

• NEW can transition to: CONTACTED, UNQUALIFIED, DUPLICATE_OF.
• CONTACTED can transition to: QUALIFIED, UNQUALIFIED, ON_HOLD.
• QUALIFIED can transition to: PROPOSAL, LOST, ON_HOLD, UNQUALIFIED.

Invalid transitions are rejected at the API level. A rep cannot move a NEW lead directly to WON. The platform refuses and logs the attempt.

This sounds bureaucratic. It catches data-entry errors and forces honest progression. Without it, anyone can move any lead to any state, and the data degrades.

Step 4: Define what progresses each state

This is the property that makes the lifecycle honest.

For each state, define explicitly: what action progresses out of this state? Examples:

• NEW progresses on the first documented outbound attempt by the owner. A logged call, sent email, or completed task that represents real outreach. Clicking on the lead does not count.
• CONTACTED progresses on a documented qualifier conversation. The conversation might be recorded as a logged meeting, an email exchange, or a structured questionnaire response. The qualification criteria are documented.
• QUALIFIED progresses when a proposal is sent. A documented proposal artifact attached to the lead.

Without these definitions, the lifecycle is theater. Reps move leads to QUALIFIED to look good. With the definitions, the lifecycle reflects work that actually happened.

Step 5: Layer SLAs on each state

Every state has a target window: how long should a lead stay in this state before it has to progress or transition? The SLA is the answer.

Default SLAs:

• NEW to CONTACTED: 1 to 24 hours, depending on source.
• CONTACTED to QUALIFIED or UNQUALIFIED: 24 to 48 hours.
• QUALIFIED to PROPOSAL: 5 business days.
• PROPOSAL to NEGOTIATION or LOST: 10 business days.

ON_HOLD pauses the timer for the underlying state. WON, LOST, UNQUALIFIED, DUPLICATE_OF, ARCHIVED have no SLA (terminal states).

The SLA targets are part of the lifecycle definition, not a separate document. When you change a target, the change is to the lifecycle.

Step 6: Make the lifecycle admin-configurable, but rarely change it

The lifecycle should live in admin configuration, not in code. Changes are possible without engineering involvement.

But: change the lifecycle infrequently. The lifecycle is a contract between operations and the rest of the org. Adding a state or changing a transition disrupts everyone's mental model and breaks reports.

Reserve flexibility for the rules that operate on the lifecycle: SLAs, routing, escalations. Those tune frequently. The lifecycle itself is stable. The right cadence for lifecycle changes is once a year, at strategic review.

Step 7: Audit every transition

Every state transition fires an audit entry. Actor, lead, from state, to state, timestamp, the action that progressed it (the logged call, the proposal artifact, etc).

Six months later, when someone asks "why did this lead get marked QUALIFIED on May 15," the audit answers. Disputes about who progressed a lead and when are resolved by reading the trail.

Step 8: Build the lifecycle into the UI

The lifecycle is not just a database column. It shows up in the UI:

• The lead detail page shows the current state prominently.
• The state-transition buttons are explicit. Move to CONTACTED, move to QUALIFIED, mark UNQUALIFIED.
• Invalid transitions are not shown. A NEW lead does not have a "move to WON" button.
• State history is visible inline: the trail of when each state was entered, by whom.

This makes the lifecycle real to the reps using it, not just to the operations admin who configured it.

Common pitfalls

Three patterns to avoid:

Too many states. A 12-stage lifecycle with stages like "Sent first email", "Got reply", "Scheduled demo" encodes too much detail in the state machine. These belong as tasks or activities on the lead, not as states.

Soft progression rules. "Move to QUALIFIED when the rep feels confident." This is theater. Define the criterion concretely or do not include the state.

Changing the lifecycle constantly. Every change disrupts reports, retraining, and the team's mental model. Stable for at least a year.

What this gives you

A lead lifecycle designed this way produces:

• Honest reports. The funnel chart reflects real work.
• Honest SLAs. The breach numbers are accurate.
• Honest disputes. Ownership questions get answered by the audit trail.
• Stable operations. The team's mental model holds because the lifecycle holds.

The cost is one initial design exercise. The benefit is years of operational discipline.

For how MegatronLead expresses the lifecycle and what gets logged at each transition, see the platform overview. For the SLAs that operate against the lifecycle, see SLA and escalation.