Customer 360
Customer 360 is one person's history across every channel, assembled on demand from the services that own each part rather than stored as a document. It is what relationship_console.detail answers for a screen and what the Assistant's customer_360 tool answers for a question — the same assembly, two consumers, so the two cannot drift apart.
What is gathered, and from where#
| Part | Owned by | Why it is there |
|---|---|---|
| Identities | people.py | Which addresses reach this human |
| Conversations and calls | The canonical threads, messages and calls | What was actually said |
| Lifecycle stage | journey.py | Where the relationship has got to |
| Opportunities and demos | sales.py | What is being sold, and what is booked |
| Support cases and onboarding | crm.py | What is unresolved after the sale |
| Follow-ups | followups.py | Dated commitments, each with a reason |
| Memory at the contact tier | connect_memory.py | What Connect has been told about this human |
| The written summary | relationship_console.story | The relationship in prose, names scrubbed |
Nothing in that table is a copy. Each row is read from the service that owns it at the moment you ask, which is why a case resolved thirty seconds ago is resolved here too, and why there is no rebuild step to go wrong.
Assembled, not stored#
The alternative design — a materialised profile document updated by every service that touches the person — fails in a specific way: it goes stale silently, and the staleness is invisible because the document still renders perfectly. Assembly on demand trades a little query cost for the guarantee that what you are reading is current.
That query cost is the thing to keep honest, and it has a measured history here. Reading a page of rows and then fetching each row's detail one at a time cost 83 and 89 statements for 40 rows on the triage strip and the workspace console, and grew with the page. One workspace_console.page_context — a windowed last-message query and a contacts-by-id query — made it 5 and 11, flat. A 360 view is the same shape of problem for one person rather than forty.
The same answer through the Assistant#
customer_360 is one of the Assistant's read-only tools, alongside next_best_action, list_followups, list_cases and list_opportunities. Asking the Assistant about a person runs the same assembly the screen runs, so an answer in chat and an answer on the screen agree by construction rather than by discipline.
The screen context the model is given is checked against the database before it is trusted, which is the safeguard against a stale or spoofed view being narrated back as fact. The Assistant's writing rights stay narrower than a person's throughout — see the Connect Assistant.
What it will not show you#
- Another workspace's history of the same human. Isolation is enforced three times, and a person is a record inside one workspace.
- Website enquiries addressed to JBRH.
connect_inquiriesis a control-plane table outside every workspace; a customer not seeing one is isolation working. - Provider-shaped rows. The view reads the canonical records, never the
tenant_*tables the adapter wrote. - A merged organisation view. The assembly is per person; a company gives you its people rather than one blended history.
Questions#
How current is a 360 view?
As current as the request. Every part is read when you ask, so there is no refresh interval to tune and no rebuild to fail. The trade is query cost, which is why the assembly is set-based rather than a loop over rows.
Why is a deal missing from someone's 360?
Most often the deal is attached to a different person record for the same human — the case duplicate detection exists for. Merging brings deals, demos, cases, follow-ups, stages and identities from both sides onto one record.
Can I export it?
The underlying records are exportable from the Data grid's thirteen sheets, with CSV export neutralising formulas. The assembled view itself is a reading of those records rather than a document with its own storage.