> ## 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.

# The whole journey, end to end

> The five parts of a customer journey and the four handovers between them — which are running today, which are not, and what a whole-journey view will and will not show you.

[How a customer moves through Beacon](/lifecycles/overview) describes two stage rails. The full journey is longer than both — it runs from first marketing contact to the revenue that eventually lands, and the two rails are its middle.

<Note>
  A designed model. Two of the four handovers are running; two are not. This page says which, rather than describing all four as though they were.
</Note>

## Four handovers

| Handover | Happens when | Running |
| - | - | - |
| Marketing to sales | A lead is accepted as qualified | Yes |
| Sales to customer | The deal closes won | Yes |
| Customer to product | Not yet active | No |
| Product to finance | Not yet active | No |

The first two are the seams Beacon runs on today. **Stages are published for the sales and customer parts only** — the marketing handover is defined as the point where authority over a deal passes, but no marketing stages are published. The last two activate when the product and finance connections do.

## What the journey record actually holds

Order, handovers, and the moment authority passed at each one. Nothing else.

No figure is born here. A journey view points at each part's own stage and each part's own numbers; it does not recalculate them, hold a copy, or produce a total that none of them published. That is what makes it safe to read across parts — there is no second version of anything on it.

## A part that is not running does not guess

Where a handover is inactive, the journey shows the parts that are available and says so. It does not estimate the missing stretch, carry the last known state forward, or shorten the journey to hide the gap.

## You see the parts you have access to

A whole-journey view is not a wider door. It resolves across the parts you already hold access to, and its sensitivity is that of the most restricted part you cross — reading several parts you are entitled to never adds one you are not. If a stretch is beyond your access it stays unresolved, and the view says so rather than quietly omitting it.

## Disagreements are raised, not settled

Where two parts describe the same record differently, the journey flags it and routes it to both owners. See [When two systems disagree about a stage](/two-systems-disagree).

## Related

<Columns cols={3}>
  <Card title="How a customer moves through Beacon" href="/lifecycles/overview">
    The two rails in the middle of the journey.
  </Card>

  <Card title="How your lifecycles connect" href="/lifecycles/how-they-connect">
    Connections beyond this one path.
  </Card>

  <Card title="Access and grants" href="/access-and-grants">
    What a reader may see.
  </Card>
</Columns>


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