# Customer 360

**Customer 360** is one [person's](/docs/glossary/person/) whole history in one view: every email, call, WhatsApp message, deal, case, follow-up and remembered fact, gathered across channels rather than presented per channel. It is assembled from the records that already exist each time it is asked for, so it cannot be out of date with them.

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

## What it gathers

- Every [conversation](/docs/glossary/conversation/) the person appears in, whichever channel carried it, and the calls alongside the messages.
- Their [company](/docs/glossary/company/), their [lifecycle stage](/docs/glossary/lifecycle-stage/) and how the stage got there.
- Open [opportunities](/docs/glossary/opportunity/), open [support cases](/docs/glossary/support-case/) and outstanding [follow-ups](/docs/glossary/follow-up/).
- What Connect [remembers](/docs/glossary/memory/) about them at the contact tier, including any block set against them.

The Connect Assistant can produce the same view by request, which is usually faster than navigating to it: asking about a person before ringing them returns the assembled picture rather than a screen you then have to read.

## Why it is assembled rather than stored

The tempting design is a summary table kept up to date by everything that writes. It fails in a specific way: the summary and the records drift, usually in the direction that matters, because the paths that write infrequently are the ones nobody remembers to update. A workspace then has two answers to *when did we last speak to them* and no way to tell which is right.

So the view is derived on demand from the records themselves. The cost of that decision is query work, and it is the reason the assembly is written as a small number of scoped queries rather than one per related record — the shape that grows with the size of the business is the shape that quietly stops working on the accounts you care about most.

> **Note** Being derived also means it inherits [workspace](/docs/glossary/workspace/) isolation rather than re-implementing it. There is no separate 360 store that could be scoped differently from the records it summarises.

## Four neighbours, and the question each one answers

| View | Answers | Bounded by |
|---|---|---|
| Customer 360 | Everything about this human | One person |
| A [conversation](/docs/glossary/conversation/) | What was said in this exchange | One thread or call |
| The timeline | What happened, in order | One person, chronologically |
| [Memory](/docs/glossary/memory/) | What Connect knows and will act on | Four tiers, only one of which is this person |

The one worth being careful with is memory. Customer 360 shows what happened; memory holds what Connect has been told to treat as true. A fact visible in the history is not necessarily something the engine will use, and something in memory may have no visible event behind it because a person typed it. Reading the first as the second is how a workspace concludes that Connect *should have known* something nobody ever recorded.

## Questions

### Does Customer 360 include people I have only researched?

It assembles a person's history, so a [prospect](/docs/glossary/prospect/) with no contact yet has very little to show. The research evidence lives on the prospect record until the relationship exists.

### Can a colleague see the same view?

Anyone in the workspace who can see the person can see it. It is not scoped per user — it is scoped per workspace, like every record it draws on.

### Is it exportable?

The underlying records are, through the sheets in [Data](/docs/files-data/). The assembled view is a way of reading them rather than a document, so what you export is the records themselves.

## Related

- [Person](https://connectbyjbrh.com/docs/glossary/person/)
- [Relationship](https://connectbyjbrh.com/docs/glossary/relationship/)
- [Customer 360](https://connectbyjbrh.com/docs/relationships/customer-360/)
- [The customer timeline](https://connectbyjbrh.com/docs/relationships/timeline/)
- [Why the machine proposes a merge and a person disposes](https://connectbyjbrh.com/research/one-person-many-channels/)

## What this page is based on

- docs-source/sources/GENERAL.md §4 — relationship_console answers one relationship for either audience
- docs-source/sources/GENERAL.md §11 — measured query-cost reductions on assembled views
- `docs-source/facts.py` — CANONICAL_TERMS Customer 360, CAPABILITY_STATUS customer_360