# Handing a won deal to onboarding

Nothing is copied. The same person and company records continue, with their identities, conversations, timeline and memory intact; winning changes the opportunity's state and the person's lifecycle stage. What is created is new work — onboarding actions and dated follow-ups — and a change in how Connect treats them afterwards, including stopping any prospecting aimed at them.

- **Status:** Available
- **Audience:** both
- **In the app:** #/pipeline, #/relationships, #/follow-ups
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/workflows/won-deal-handover/

## The chain, stage by stage

1. Trigger — an opportunity is moved to won, by a person on the pipeline or by the Assistant acting for one.
2. User event — the move is a human judgement. Nothing infers a win from a customer saying something encouraging.
3. Authentication and workspace resolution — the pipeline, the stage vocabulary and the onboarding actions all belong to one workspace and are read only after it is settled.
4. Request — the move is checked against the stage rules before it is applied, so a state nobody can act on is refused rather than recorded.
5. Canonical record — the opportunity keeps its value in minor units with its currency, its history and its attachments. It is closed, not deleted.
6. Reasoning — the next actions are drawn from what the deal was actually about, which is why the conversation history staying attached matters more here than anywhere else.
7. Knowledge, memory and rules — memory resolves narrowest-first across workspace, channel, endpoint and contact, so a direction given during the sale still governs the first week of the relationship.
8. Autonomy and approval — the channel's mode decides whether a welcome or a first onboarding message goes out by itself or waits for a person.
9. Action — anything sent goes through the same send boundary as every other outbound message; nothing about a won deal creates a second path.
10. Result — the pipeline shows the deal closed, and the person's lifecycle stage reflects that they are a customer rather than a prospect.
11. Relationship, timeline and memory — onboarding actions and follow-ups are created against the same person; the timeline runs straight through the win rather than starting again.
12. Audit, usage and Needs You — the move, its author and the rule it passed are recorded, and anything waiting for a person appears in Needs You.

## What carries over untouched

The handover is a change of state, not a migration, and that is the single most useful thing to understand about it. There is no separate customer object to be created and no history to be transferred, because the person who was a prospect and the person who is now a customer are the same row.

- **The person and the company**, with every identity attached to them — the address they enquired from is still the address support will answer.
- **The whole conversation history**, on every channel, in one timeline that does not restart at the win.
- **Memory**, at all four tiers. A note that this account is only ever to be phoned in the afternoon survives the transition without anyone re-entering it.
- **Follow-ups already dated**, including the `task` ones a person owes.
- **The opportunity itself**, closed and readable, with its value in minor units and its currency — the record of what was agreed, not a deleted stage.
- **Any support case or earlier onboarding**, which is also why merging two people preserves both sides of all of this.

## What is newly created

**A lifecycle stage change** — `stages()` is the vocabulary and `move_stage` is the transition. The stage is what most screens and rules read to tell a customer from a prospect.
**Onboarding actions** — `onboarding_action` records post-sale work against the relationship, so the first weeks are visible on the same record as the sale rather than in somebody's head.
**Follow-ups with reasons** — The commitments made during the sale — a check-in, a first invoice, a training session — become dated work. Without a reason they are dates nobody can act on confidently.
**A different prospecting answer** — Identity resolution is what stops an existing customer being discovered and prospected again. The stage change is what it reads; leaving the stage behind is how a customer ends up receiving cold outreach.

Support is not created here and should not be. A case is opened when there is something to resolve; opening one at handover to "track onboarding" puts post-sale work in a queue built for problems, and makes both queues harder to read.

## The two mistakes that split a customer in half

1. Before moving the deal, search the customer's address rather than their name and confirm there is only one record.
   - Result: If there are two, merge first. A win applied to one of a pair puts the stage, the onboarding and the follow-ups on one record while the conversation history sits on the other — and both look incomplete to whoever opens them next.
2. Check that the address the customer will use afterwards is attached as an identity of this person.
   - Result: Support very often arrives from a different mailbox to the one that bought. An unattached address opens a second record and starts the history again, which is the same fault arriving later.
3. Move the stage, not only the deal.
   - Result: A closed opportunity with the person still marked as a prospect is the state in which outreach can still reach them. The stage is what the rest of Connect reads.
4. Give every follow-up you create a reason in the customer's terms.
   - Result: "Confirm the second licence they asked about on the call" survives a handover between colleagues. "Check in" does not.

> **Careful** A merge is a human decision on purpose. Duplicates are proposed, never merged automatically, because joining two people who are genuinely two people is far harder to undo than leaving a duplicate for another day.

## Questions

### Does anything get copied into a new customer record?

No. The same person and company rows continue with everything attached to them; winning changes the opportunity's state and the lifecycle stage. That is why nothing has to be reconciled afterwards and why the timeline reads straight through the win.

### Why is my new customer still receiving prospecting messages?

Almost always because the deal was closed but the lifecycle stage was not moved, or because the outreach is aimed at a duplicate record that was never merged. Identity resolution reads the record it can see; two records means it can only protect one of them.

### Should onboarding be tracked as a support case?

No. Cases are for things to resolve, and onboarding actions exist precisely so post-sale work has its own place on the relationship. Mixing them makes the support queue read as though every new customer had a problem.

### Is the closed opportunity still readable later?

Yes. It is closed rather than removed, and it keeps its value in minor units with its currency, its attachments and its history. Six months on, it is the record of what was actually agreed.

## Related

- [Closing a deal, end to end](https://connectbyjbrh.com/docs/workflows/close-deal/)
- [Closing a deal: won and lost](https://connectbyjbrh.com/docs/sales/won-and-lost/)
- [Lifecycle stages](https://connectbyjbrh.com/docs/relationships/lifecycle-stages/)
- [Moving a relationship through its lifecycle](https://connectbyjbrh.com/docs/workflows/lifecycle-progression/)
- [Onboarding a new customer](https://connectbyjbrh.com/docs/support/onboarding/)
- [Onboarding, end to end](https://connectbyjbrh.com/docs/workflows/onboarding-workflow/)
- [Merging two records](https://connectbyjbrh.com/docs/relationships/merging/)
- [Handling a demo request, end to end](https://connectbyjbrh.com/docs/workflows/demo-request/)

## What this page is based on

- `docs-source/sources/CHANNELS.md` §5 — people, companies, identities, merge behaviour and the lifecycle vocabulary
- `docs-source/sources/CHANNELS.md` §6 — opportunities, stage rules and minor-unit values
- `docs-source/sources/CHANNELS.md` §4 — identity resolution keeping an existing customer out of prospecting
- `docs-source/sources/GENERAL.md` §6 — the four memory tiers and their narrowest-first resolution
