> ## Documentation Index
> Fetch the complete documentation index at: https://docs.beaconrevenue.io/llms.txt
> Use this file to discover all available pages before exploring further.

# How a customer moves through Beacon

> The two stage rails Beacon runs — six pipeline stages before the sale closes, eight customer stages after — and the single point where one hands over to the other.

Beacon runs two stage rails, not one. A deal moves through the first. The account that deal becomes moves through the second. They meet at exactly one point — the day the deal closes won — and everything Beacon publishes about progress reads from one rail or the other.

<Note>
  This page describes a designed model, not shipped behaviour. The stage sets are fixed; no surface serves them from your data yet.
</Note>

## The two rails

| Rail | Runs from | Stages | The value |
| - | - | - | - |
| Pipeline | An opportunity is created | Six, plus won and lost | [`deal_stage`](/definitions/deal-stage) |
| Customer | The contract is signed | Eight | [`lifecycle_stage`](/definitions/lifecycle-stage) |

## Before the sale closes

Six stages, in order: **New** (created, qualification incomplete) · **Discovery** (qualification active) · **Demo** (solution shown, technical fit checked) · **Proposal** (commercial proposal delivered, evaluation underway) · **Negotiation** (terms in active discussion) · **Verbal or closing** (verbal commitment, contracting in flight).

A deal then ends in one of two states, won or lost. Won is the handover; lost closes the record.

## After the sale closes

Eight stages, each with a stated condition for leaving it:

| # | Stage | Leaves when |
| - | - | - |
| 1 | Onboarding | Half or more of the activation milestones typical for the segment are done |
| 2 | Activation | 80% of those milestones are done and a first quantified value statement is recorded |
| 3 | Value realisation | Cost to serve settles in the segment's usual band and usage holds steady for 60 days |
| 4 | Steady state | The renewal date comes within six months |
| 5 | Renewal approach | A renewal decision is recorded |
| 6 | Renewal decision | A renewal contract is signed, or non-renewal is recorded |
| 7 | Post-renewal re-engagement | A stable post-renewal pattern emerges |
| 8 | Long-term maturity | A later renewal cycle returns the account to stage 5, or it churns |

## What is true of both rails

**One stage at a time.** A record sits in exactly one stage, set by its most recent recorded transition rather than by anyone's judgement.

**Everything else reads the stage.** No other Beacon figure works out its own version of where a record has reached. Deal probability, deal health, health score and the rest all read the stage published here.

**The stage sets are the same for every company; the pace is not.** How long a stage typically lasts is calibrated per segment — an enterprise onboarding runs months where an SMB one runs weeks — but no company gets a seventh pipeline stage or a ninth customer stage. Both sets are locked, and changing one is an owner-level change with a recorded rationale, not configuration.

**Your own stage fields stay yours.** Where your CRM's stage disagrees with the stage published here, yours is an input and this one is what every other Beacon figure reads.

## Related

<Columns cols={3}>
  <Card title="Where a deal becomes a customer" href="/lifecycles/from-deal-to-customer">
    What happens at the one point the rails meet.
  </Card>

  <Card title="What changes when a stage changes" href="/lifecycles/what-changes-when-a-stage-changes">
    The figures that move the moment a record advances.
  </Card>

  <Card title="The lifecycles you define" href="/lifecycles/defining-your-own">
    Building a stage rail of your own.
  </Card>
</Columns>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.