# Support in Connect

Support in Connect is not a second system. A case, an onboarding plan and a closed deal hang off the same person record that held the prospect research and the first reply, so the history that answers a question is already attached to the person asking it. This section covers cases, escalation, onboarding, the post-sale relationship, and the enquiries that arrive on JBRH's own website rather than in a workspace.

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

## One record, from research to complaint

The argument for keeping support here rather than beside here is simple to state and expensive to ignore. A prospect that was researched, contacted, quoted and closed becomes a client; a client with a problem opens a case. If those three lived in three systems, the person handling the case would begin by asking questions the business already had answers to, and the customer would notice.

Because a case is attached to the **Person**, everything the relationship already knows is one hop away: the identities they write from, the company they belong to, the deals, the calls, the follow-ups still owed them, and the timeline that puts the lot in order. That continuity is the whole point of one relationship record rather than a CRM, a helpdesk and a spreadsheet that agree with each other on a good day.

## What is in this section

| Page | Answers |
|---|---|
| [Support cases](/docs/support/cases/) | The record itself, what opens one, and the small vocabulary it moves through |
| [What a case carries](/docs/support/case-context/) | The history an answer is drawn from, assembled to a budget, and what is deliberately left out |
| [Resolving a case](/docs/support/resolving/) | What resolution records, what it changes on the relationship, and what it does not close |
| [Escalating a case](/docs/support/case-escalation/) | What reaches Needs You, and the decision the person is actually being asked for |
| [Onboarding a new customer](/docs/support/onboarding/) | The record, the steps, and what Connect does between them |
| [The relationship after the sale](/docs/support/post-sale/) | What continues unchanged, what changes, and what is deliberately different |
| [Website enquiries](/docs/support/website-enquiries/) | Why an enquiry from the public site belongs to the operator and not to a workspace |

Three end-to-end walkthroughs sit alongside them: [a support case](/docs/workflows/support-case/) from the first message to the memory it leaves, [onboarding](/docs/workflows/onboarding-workflow/) from first day to steady state, and [a website enquiry](/docs/workflows/website-enquiry/) from a public form to an answered person.

## Where the records live

**The relationship record** — Cases and onboarding are read and worked from the person, which is where the context already is.
**The Data grid** — `cases` and `onboarding` are two of the thirteen sheets, for the times a list beats a record. Every edit still goes through the service that owns the row, so the grid is not a second helpdesk.
**The Assistant** — `list_cases`, `create_case` and `resolve_case` are product tools, so a case can be opened or closed in conversation without leaving what you were doing.
**Needs You** — Where an escalated case waits for a decision, next to every other thing a person owes an answer to.

> **Note** One page in this section is deliberately not about your workspace. Website enquiries arrive on JBRH's own site and are held in a control-plane table outside every workspace. A customer looking for one in their own Connect and not finding it is watching isolation work, not a fault — that page explains why, and what does reach them.

## The two audiences

Cases and onboarding are answered by the same body of code for the operator and for a customer workspace, through two thin routers rather than two implementations. The words on the screen differ where the audience differs — a customer's *people* are the operator's *relationships* — but the record, the states and the rules are one thing. Where a capability is genuinely operator-only, it says so on its own page and it is a decision about running the platform, not a feature a customer is missing.

## Everything in this section

7 pages, each with its own status and the date it was last checked against the running system.

| Page | What it covers |
|---|---|
| [Escalating a case](/docs/support/case-escalation/) | What makes a case stop and wait for a person, what the person is actually being asked to decide, and what the customer sees while it waits. |
| [Onboarding a new customer](/docs/support/onboarding/) | The onboarding record after a deal is won: what it tracks, what Connect does between the steps, and why the plan is the workspace's rather than a template. |
| [Resolving a case](/docs/support/resolving/) | What closing a case actually records, what it changes on the relationship, and the four things it deliberately leaves exactly as they were. |
| [Support cases](/docs/support/cases/) | What a support case is in Connect, what opens one, the three verbs it moves through, and how it stays attached to the person it belongs to. |
| [The relationship after the sale](/docs/support/post-sale/) | What carries over when a prospect becomes a client: the record, the memory and the commitments that continue, and the four rules that change. |
| [Website enquiries](/docs/support/website-enquiries/) | Enquiries from the public JBRH website are held outside every workspace, on purpose. What that means, who works them, and why customers cannot see them. |
| [What a case carries](/docs/support/case-context/) | The history an open case is answered from: what is assembled, the budget it is assembled to, and the things deliberately left out of it. |

## Questions

### Is a support case a different record from a conversation?

Yes. A conversation is the exchange on a channel; a case is the issue that exchange is about, attached to the person rather than to the thread. One case can span an email thread, a call and a message, which is exactly why it is not stored as part of any of them.

### Do I need to move a client somewhere else once they buy?

No. The same person record carries the prospect research, the deal and then the cases. Lifecycle stage records where they have got to; nothing is copied into a second system, and nothing is left behind in the first.

### Why is there a support section at all if everything hangs off the person?

Because the rules differ. What resolution means, what escalation asks a human for, and what onboarding tracks are all specific enough to be worth writing down separately from the relationship record they attach to.

## Related

- [Support cases](https://connectbyjbrh.com/docs/support/cases/)
- [Onboarding a new customer](https://connectbyjbrh.com/docs/support/onboarding/)
- [The relationship after the sale](https://connectbyjbrh.com/docs/support/post-sale/)
- [Customer 360](https://connectbyjbrh.com/docs/relationships/customer-360/)
- [A support case, end to end](https://connectbyjbrh.com/docs/workflows/support-case/)
- [Closing a deal: won and lost](https://connectbyjbrh.com/docs/sales/won-and-lost/)

## What this page is based on

- `docs-source/sources/CHANNELS.md` §5 — `relationship_console`, cases and onboarding for both audiences
- `docs-source/sources/CHANNELS.md` §7 — website enquiries as control-plane records
- `docs-source/sources/GENERAL.md` §8 and §9 — the Assistant's case tools and the thirteen data sheets
- Connect capability registry (docs-source/facts.py) — `support_cases`, `onboarding`