# Onboarding a new customer

Onboarding is a record on the same person and company that carried the deal, listing the steps this business puts a new customer through and what has happened against each. Connect does the work between the steps — chasing what is owed, answering from Knowledge, recording what happened, stopping where a person must decide. The steps themselves are the workspace's; no template is imposed.

- **Status:** Available
- **Audience:** both
- **In the app:** #/relationships, #/data
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/support/onboarding/

## Where onboarding starts

It starts on a record that already exists. The person was researched as a prospect, contacted, quoted and closed; onboarding attaches to that same relationship rather than opening a new one somewhere else. The practical effect is that the first onboarding message can refer to what was agreed in the deal, because the deal is on the same timeline.

Nothing is copied at handover. A won deal and an onboarding record coexist on one relationship, which is why [handing a won deal to onboarding](/docs/workflows/won-deal-handover/) is a change of emphasis rather than a migration between systems.

## What the record holds

**The customer** — The person and their company, with every identity that already resolves to them.
**The steps** — What this workspace does with a new customer, in its own words and its own order.
**The state of each step** — What has happened, when, and by whom or by what.
**The commitments** — Follow-ups scheduled against the steps, each with a reason, on whichever channel suits.
**The history** — Read from the relationship rather than duplicated, so it stays current while onboarding runs.

`onboarding` is also one of the thirteen sheets in the Data grid, which is the right surface when the question is about the set rather than one customer — everyone stuck on the same step, everything started this month. Edits there go through the service that owns the record, so the grid never becomes a second version of the plan.

## What Connect does between the steps

| Moment | What Connect does | What it will not do |
|---|---|---|
| A step is waiting on the customer | Schedules a follow-up with a reason and chases it on the agreed channel | Chase past the point where lateness makes the contact worse |
| The customer asks a question | Answers from Knowledge and the relationship's own history | Improvise a commercial term Knowledge does not support |
| Something happens on a call or in a thread | Records it against the relationship, where the next step can see it | Silently mark a step complete because a message sounded positive |
| A decision is needed | Stops and asks in Needs You, with the material to decide | Choose on the workspace's behalf |

> **Note** The third row is the same principle as cases: state changes are actions somebody takes, not inferences drawn from tone. An onboarding board that advances itself optimistically is worse than no board, because people stop checking it.

## Why there is no built-in template

What a new customer needs differs so completely between businesses that a supplied checklist would be wrong for nearly everyone and would still be followed, because it was there. Connect holds the record, the steps and the chasing; the content of the plan comes from the workspace that knows what its customers need.

That also means onboarding quality is mostly a Knowledge question. A workspace whose Knowledge answers the twenty questions new customers actually ask gets an onboarding that runs itself between decisions; a workspace whose Knowledge is thin gets an onboarding that escalates a lot. Both are working correctly — one of them just has more to work with.

## Edge cases

- Two records for the same new customer: merge them. A merge preserves identities, stages, follow-ups, deals, demos, cases and onboarding from both sides, so nothing in the plan is lost.
- A customer who has a problem mid-onboarding: open a case. The two records coexist on the person, and each reads the other's history as context.
- An onboarding that stalls: the chases are follow-ups, so they obey the same limits — including a very late phone chase being closed as missed rather than made.
- A customer who bought twice: the relationship is one person, and a second onboarding does not fork them into two records.

## Questions

### Does Connect come with a standard onboarding checklist?

No, and that is deliberate. The steps belong to the workspace, because what a new customer needs is specific to the business. Connect supplies the record, the chasing between steps and the history the answers come from.

### Is the onboarding record separate from the customer record?

It attaches to the same Person and Company that held the prospect research and the deal. That is what lets an onboarding message refer to what was agreed without anybody re-entering it.

### Will a step complete itself if the customer replies positively?

No. Completing a step is an action a person or an instruction takes. Inferring progress from tone would make the board optimistic and therefore useless.

## Related

- [Support in Connect](https://connectbyjbrh.com/docs/support/)
- [The relationship after the sale](https://connectbyjbrh.com/docs/support/post-sale/)
- [Onboarding, end to end](https://connectbyjbrh.com/docs/workflows/onboarding-workflow/)
- [Handing a won deal to onboarding](https://connectbyjbrh.com/docs/workflows/won-deal-handover/)
- [Lifecycle stages](https://connectbyjbrh.com/docs/relationships/lifecycle-stages/)
- [Knowledge in Connect](https://connectbyjbrh.com/docs/knowledge/)

## What this page is based on

- `docs-source/sources/CHANNELS.md` §5 — `onboarding_action` on the relationship console and `merge_people`
- `docs-source/sources/GENERAL.md` §9 — the `onboarding` sheet and edits through the owning service
- `docs-source/sources/GENERAL.md` §7 — follow-up channels, reasons and the late-chase rule
- Connect capability registry (docs-source/facts.py) — `onboarding`, `followups`