From client to support, end to end

Winning a deal moves the relationship to *client*, a move Connect may propose and a person confirms. Onboarding follows, then ordinary support: a case is opened against the same person, answered from the same knowledge, and resolved. Nothing is handed over between systems, because the sale and the support were always the same record.

Status: Available What this means
Audience: both
Channels: emailwhatsappphone
In the app: #/pipeline, #/relationships, #/follow-ups
Last verified: 2026-09-10
Product version: 6.3.2

The chain#

TRIGGER — a deal is agreed. The relationship's move to client is a commercial commitment, so Connect may propose it and a person confirms.
USER / EXTERNAL EVENT — the customer writes or rings after the sale: a setup question, a fault, a change of details.
AUTH / WORKSPACE RESOLUTION — the mailbox, number or handle decides the workspace; the same isolation applies to a client as to a stranger.
INGEST / REQUEST — the message is fetched and bridged into canonical records. Continuity depends entirely on the address being an identity on the existing person.
CANONICAL RECORD — a support case is opened against that person with open_case, and post-sale steps run through onboarding_action. Both hang off the relationship, not off a thread.
CLASSIFICATION / RESEARCH / REASONING — triage decides what this is: an onboarding step, a question knowledge can answer, a fault, or a commercial question.
KNOWLEDGE + MEMORY + RULES — the answer is grounded in the workspace's knowledge and what is remembered at the contact tier. A price, an SLA or a warranty that knowledge does not support is refused and escalated rather than improvised.
AUTONOMY / APPROVAL — the channel's mode governs whether the reply leaves on its own. A commercial question goes to a person regardless, because the refusal is the correct behaviour rather than a gap.
ACTION / PROVIDER — a permitted reply leaves through the shared send boundary; a commitment made in it becomes a follow-up with a reason, on the channel it belongs to — or on task, which no drain ever sends because it is work for a person.
RESULT — the case is acted on and eventually resolved. Onboarding steps complete one at a time rather than as one event.
RELATIONSHIP / TIMELINE / MEMORY — the sale, the onboarding steps and the support all assemble onto one timeline in the order they happened, and what matters durably is remembered against the person.
AUDIT / USAGE / NEEDS YOU — decisions are recorded with the rule they were taken under, refusals included; unresolved work and escalations wait in Needs You, ranked rather than chronological.
NEXT — onboarding completes and the relationship moves to *active*: a customer who occasionally needs something, which is a different thing from one being set up.

What actually carries over#

Carried	Where it lives	Why it matters after the sale
Identities	`people.py`	The customer rings the number they always rang; without the identity, support starts as a stranger
The whole history	Assembled by `timeline.py`	What was promised during the sale is readable while answering a complaint about it
Memory at the contact tier	`connect_memory.py`	Preferences, forms of address and standing instructions survive the change of subject
Follow-ups	`followups.py`	A commitment made before the sale is still dated and still has its reason
Deals and demos	`sales.py`	What was bought, and what was shown, without asking the customer to repeat it
Position on the journey	`journey.py`	Client, onboarding and active are treated differently by the rest of the product

None of that is a migration. There is no handover job to run and nothing to re-key, because support reads the same person record sales was writing to.

Where continuity actually breaks#

A second record for the same human: The commonest failure by far. Support answers from half a history because the customer wrote from a different address. duplicates may propose the pair; a person merges it.
A promise nobody wrote down: A commitment made in a conversation and never turned into a follow-up is not carried by anything. A follow-up carries a reason precisely so the person who inherits it can act on it.
A commercial answer nobody can give: A question about terms that knowledge does not support is escalated, and it waits for a person. That is the intended behaviour; the failure is leaving it waiting.
A block set as prose: A do-not-contact instruction written into a note rather than tagged is not read by directives() and stops nothing.

Onboarding as its own phase#

Onboarding sits between *client* and *active* on purpose. A customer being set up needs different handling from one running steadily: more proactive contact, more unfinished steps, more questions that are ordinary rather than faults. Giving it a position on the journey means the rest of the product can behave accordingly rather than treating every customer identically.

Steps complete individually and are carried through a merge if one happens mid-flight, so a handover in progress is not restarted by a data repair.

Questions#

Does support see what was promised during the sale?

Yes, if it is on the record — the timeline assembles conversations, calls, demos and follow-ups for one person in the order they happened. A promise made in conversation and never written down is the exception, which is why commitments become follow-ups with reasons.

Can Connect answer a question about warranty terms?

Only where the workspace's knowledge supports the answer. Anything else is refused and escalated to a person rather than improvised — see safe sales. The refusal is recorded as a decision, because a refusal is one.

What moves the relationship from onboarding to active?

A stage move like any other, recorded with who moved it and why. Forward moves are the ordinary direction; a move backwards is refused unless it is asked for explicitly, so a stray signal does not undo progress.