What every lead lifecycle stage owes the next

You've seen the pattern. A lead enters at one end of your CRM. Six weeks later, a deal is either won, lost, or quietly forgotten.

In between, the lead has moved through marketing, an SDR, an AE, maybe a sales engineer, and (if it got that far) onboarding and customer success. Most teams call that "the lifecycle". In reality, it's seven different roles running seven different mini-workflows that occasionally talk to each other.

That's not a lifecycle. It's a relay race where each runner gets the baton incomplete.

The fix has a name: a lead lifecycle data contract. It is the defined set of facts each stage must hand the next, with a single owner and an audit trail at every transition. It is not a tool or a new pipeline. It exists because handoffs fail silently when no one writes down what each stage owes.

The lifecycle as one operating chain

When a lead lifecycle works, it's because every stage produces exactly what the next stage needs, and the system enforces it. When it breaks, it's almost never the people. It's the data contract between two stages no one ever wrote down.

A B2B lead lifecycle is one workflow, not seven. The reason it shows up as seven separate jobs is that, in most companies, marketing owns the front, sales owns the middle, and customer success owns the back. Each part has its own tooling, its own definition of "ready", its own way of recording what just happened.

That fragmentation is the design problem. The fix isn't to merge the teams or unify the tools. It's to define what each stage owes the next, in the same way you'd define a contract between two services. Each stage is a producer of facts about the lead. The next stage is the consumer. If the producer doesn't deliver the agreed shape, the consumer fails, sometimes loudly, more often silently. This is the same design-first stance behind building the Revenue OS before the stack: design the system, then choose the tools.

The trigger of the whole chain is a signal: a form submission, an outbound reply, a partner introduction, a hand-raise from a free trial. Everything downstream is a transformation of that initial signal into more committed states, with each transformation owing the next a specific set of facts. The chain ends only when the same lead exists as a paying client with delivery active and a clear owner, or when it's been formally disqualified with the reason recorded against the company.

That's the lifecycle in one line. The rest of this post unpacks the six transitions in between and the contract each one enforces.

From signal to assignment

The front of the funnel is where most lifecycles already lie. By the time a lead reaches a human, the system has either prepared a decision or shipped raw mess to a sales rep who's now expected to do the work that should have happened automatically.

Signal → Scored

Decision being made. Is this lead worth scoring at all? And if yes, how does it score against ICP?

Data that has to exist for the next step. Firmographics on the company (size, industry, region, segment), basic enrichment on the person (role, seniority), source attribution, and an ICP score that maps to a clear band: A, B, C, or out.

Failure mode if the stage is sloppy. The lead enters with the email address the prospect typed into the form and nothing else. The AE who eventually opens the record has to do the research themselves, and three days have passed before anyone makes a real decision.

Most teams treat enrichment as a nice-to-have: something that happens occasionally, or by hand, or only on leads someone vaguely thinks are interesting. That's already a leak. Signal → Scored is the cheapest stage to make rigorous: the data sources exist, the scoring logic is a few rules, and the automation pays for itself the first week.

What this stage owes the next is a record where the lead's name, company, role, ICP fit, and segment are all populated before a routing rule looks at it.

Scored → Assigned

Decision being made. Which human (or queue) takes this lead?

Data that has to exist for the next step. The routing rule output: a single named owner, a timestamp, an SLA for first touch, and the reasoning recorded against the record so it's auditable later.

Failure mode if the stage is sloppy. The lead gets round-robined to whoever's next up, ignoring segment, region, language, or current load. Or worse, two reps both think they own it, both reach out, and the prospect spends the first interaction confused about who they're talking to.

A good routing rule isn't a flowchart in someone's head. It's a single rule expressed against the data the previous stage produced: ICP band, segment, region, language. The owner field on the lead changes value. A first-touch SLA clock starts ticking. If the SLA is breached, the system raises it; it doesn't depend on a manager noticing.

What this stage owes the next is a record where there is exactly one owner, exactly one expected next step, and a clock that says when the next step is overdue.

From assignment to deal creation

This is the most expensive transition to get wrong. The handoff from "assigned to someone" to "a real deal in the sales pipeline" is where most lifecycles quietly leak, and where the forecast starts to lie.

Assigned → Qualified

Decision being made. Does the evidence support pursuing this as a deal?

Data that has to exist for the next step. Confirmed ICP fit on the company record, a verified business problem the company is willing to solve, named stakeholders and their roles in the buying process, a capacity signal that proves the company can pay, and the qualification decision and its reasoning, recorded against the company.

Failure mode if the stage is sloppy. The lead gets marked "qualified" because the call went well, but no evidence is captured. Two weeks later, the AE can't remember what made this lead promising. The "qualified" label means nothing the system can rely on.

I went deep on this transition in a recent newsletter (the 60 seconds that decide whether a lead becomes a deal), broken down stage by stage. The short version: qualification isn't the discovery call. It's the 60-second workflow that fires the moment the call ends, where the decision, the evidence, the ownership, and the routing all have to land (automatically, manually, or some mix) but consistently every time.

What this stage owes the next is a record where every fact the deal needs to exist already lives on the lead and the company.

Qualified → Opportunity

Decision being made. Create the deal or close the lead?

Data that has to exist for the next step. A new deal record in the sales pipeline, with the company already attached, the verified problem carried over, the named stakeholders linked as deal contacts, and a single owner. The lead either gets archived with a reason or stays open in a holding state with a real re-evaluation date. There is no third option.

Failure mode if the stage is sloppy. A deal gets created on the basis of "the call went well", missing half the qualification facts. The AE spends the first week of the deal redoing the qualification work that was supposed to be done before the deal even existed. By the time the deal reaches Proposal, the forecast already includes something it shouldn't.

This is the transition that separates the lead pipeline from the sales pipeline. In a healthy lifecycle, they're two different objects, with a hard rule about how one becomes the other: every fact required to leave Qualified must already be populated, or the deal cannot be created. If the workflow can't enforce that automatically, you're going to lose data in the handoff, and the deal will inherit the holes.

What this stage owes the next is a deal record where every input the sales pipeline needs is already populated, so Scoping doesn't have to redo qualification, it acts on it.

From deal to delivery

Once a deal exists, the lifecycle's job is to keep it honest until it either closes or dies, and then to hand off cleanly into delivery. Both halves are full of failure modes most teams discover only when delivery starts asking "who is this client?".

Opportunity → Won

Decision being made. Has the deal cleared the criteria for "won"?

Data that has to exist for the next step. Signed contract or order form attached to the deal, agreed scope and timelines recorded, commercial terms (price, billing schedule, term length) populated, the buyer's procurement contact and signatory linked as deal contacts, and any deal-specific commitments (custom features, special SLAs, side letters) captured as structured fields, not buried in a Slack thread.

Failure mode if the stage is sloppy. The deal is marked Won the moment the contract is signed, but the structured data lags by days or weeks. Onboarding asks for the scope and the AE digs through email. Finance asks for the billing schedule and discovers the deal terms don't match what the proposal said. Customer success inherits the account with no idea what was promised.

The Won transition isn't the celebration. It's the moment the deal data has to harden into a record delivery can act on without asking a single follow-up question. If the AE has to be in the room for delivery to know what was sold, the stage isn't done.

What this stage owes the next is a closed deal record where every promise made to the buyer is captured in a structured form delivery can read without context.

Won → CS Handoff

Decision being made. Is delivery ready to take ownership of this client?

Data that has to exist for the next step. The project (or implementation) record is created with the deal scope inherited, the new primary owner on the CS or delivery side is assigned, the onboarding workflow is triggered, and the AE's role on the account is explicitly demoted from primary to supporting.

Failure mode if the stage is sloppy. The AE stays the de facto primary contact because no one made the handoff a system event. CS pings sales for context. Sales pings the AE for context. The client starts the relationship hearing different things from different people.

A clean Won-to-CS handoff is the single hardest stage to make automatic, because it crosses a tool boundary in most stacks: the CRM holds the deal, the work management system holds the project, the support tool holds the customer. But the contract is the same as every other stage: the next stage cannot start without the data the previous stage was supposed to produce. The handoff isn't done when the AE sends an internal "welcome" email; it's done when the project record exists, the new owner has accepted the account, and the first delivery action is queued.

What this stage owes the next is a delivery record where everything CS needs to run the account is already there (scope, owner, key contacts, commitments), and where the AE's role is supporting, not central.

The lead lifecycle data contract that runs the whole chain

Read the six transitions back to back and the pattern is the same: each stage produces a defined set of facts; the next stage consumes them and produces its own. None of it requires AI, a migration, or a reorg. It requires the discipline you'd bring to a contract between two services: name the inputs, name the owner, and fail loud the moment a fact is missing.

The data contract is the spine of the lifecycle. Without it, every stage is doing some of the previous stage's work and skipping some of its own. With it, each stage has a narrow, clear job, and the system catches its breakage at the boundary, not three weeks later. Designing and enforcing that contract across your CRM and pipeline is the heart of a Revenue Engine.

Three things make the contract real.

Required fields at every transition. A stage can't be marked complete if the facts it owes the next stage aren't populated. "Owner empty" doesn't let you move from Scored to Assigned. "Qualification reasoning empty" doesn't let you move from Qualified to Opportunity. "Scope blank" doesn't let you move from Won to CS Handoff. The system enforces what the team agreed.

Ownership at every transition. Exactly one owner at all times. Co-ownership is what every leaky lifecycle has in common. When a lead moves stages, the owner field changes; if the new owner doesn't exist yet, the move can't happen.

A traceable record of the transition itself. When a lead moves between stages, the change is logged: who moved it, when, on what basis. Six weeks later, when someone asks "why is this in Proposal?", you can read the record instead of relying on memory.

If those three things are in place, the rest of the lifecycle work is small. If any of them is missing, every other improvement you make will silently leak through the gap.

How to test your own lifecycle

You don't need to redesign the whole lifecycle to know whether it's broken. Five quick tests.

1. Pull the last twenty leads marked Qualified. For how many can you reconstruct, from the CRM alone, what made them qualified, without asking the rep? If it's less than fifteen out of twenty, the Assigned → Qualified contract is unwritten.
2. Pull the last ten deals marked Won. For how many can you read the agreed scope and commercial terms from structured fields on the record? If you're hunting through email or Slack for half of them, the Opportunity → Won contract is unwritten.
3. Open the current pipeline. Count the deals where the owner is the same person who owned the lead during qualification. If a deal changed owners and nothing else marked the change, the handoff isn't a system event. It's a vibe.
4. Pull the leads that have been in any stage for more than four weeks. How many of them are owned by someone who still works there, with a current next step queued, and a real reason to be in that stage? Anything that fails any of those three is dead routing.
5. Take one client delivery that's now running. Can the CSM tell you what was sold without talking to the AE? If no, the Won → CS Handoff contract is unwritten.

These aren't dashboards. They're forensic tests. They tell you not whether the lifecycle is fast, but whether the contract between stages exists. If any of the five comes back rough, that's where to start, not at the front of the funnel, but at the first transition where the data stops being trustworthy. For a worked example, see how Lemonet replaced disconnected funnels with one enforced lifecycle on Attio.

The lifecycle isn't seven jobs that have to coordinate. It's one operating chain where each stage has exactly one promise to the next. The teams may be separate. The tooling may be separate. The contract has to be one piece, or you don't have a lifecycle, you have a relay race where the baton occasionally arrives. Once you read each transition as a producer–consumer contract instead of an internal handoff, the whole chain becomes diagnosable. Which contract is unwritten? Which one is written but unenforced? Which one is enforced but on the wrong fact? That's the work.