> ## Documentation Index
> Fetch the complete documentation index at: https://docs.famulor.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Cross-channel customer memory

> Carry consented customer context across voice, email, support, and connected messaging channels

Customer memory connects exact, verified identities to one [Audience contact](/audience/contacts) and maintains a compact conversation summary. A customer can therefore continue in another channel without repeating known preferences, agreements, or open items.

Memory is available for supported voice, SMS, messaging, email, and helpdesk channels. Anonymous browser visitors and unverified contact details cannot read or update customer memory.

## Identity safety

* Verified phone numbers, email addresses, and channel identities are matched only within the current workspace.
* Display names and transcript content are never used to merge contacts.
* Conflicting identities are never merged automatically.
* Business sender identities are not treated as the customer's identity.
* Email memory requires authenticated sender verification; the visible sender text or message body alone is not enough.
* Anonymous browser calls and chats do not participate in cross-channel memory.

## Configure the workspace

Open **Workspace Settings → Data → Memory** to enable memory, select allowed channels, require consent, and choose a rolling retention period. An assistant can narrow the workspace policy under **Assistant → Settings → Privacy → Caller memory** by selecting read channels, write channels, categories, and a scope.

Retention and staleness are separate, independently configured settings. **Retention** decides how long a memory record exists at all — every successful update renews the rolling window, or you can choose to keep records until manually deleted; once retention lapses, the record is deleted. **Staleness** is optional and off by default: enable it and choose a number of days, and a profile with no call in that many days simply stops being injected into conversations, while the underlying record is kept — a later call refreshes it, so it doesn't have to start over unless retention has also lapsed.

```mermaid theme={null}
stateDiagram-v2
  [*] --> Active: memory record created
  Active --> Active: new interaction (renews the rolling retention window)
  Active --> Stale: staleness enabled and no call for the chosen number of days
  Stale --> Active: a later call refreshes the profile (injected again)
  Active --> [*]: retention lapses (record deleted)
  Stale --> [*]: retention lapses (record deleted)
```

| Scope       | Behavior                                                |
| ----------- | ------------------------------------------------------- |
| `workspace` | One shared memory across all assistants                 |
| `assistant` | Memory isolated to this assistant                       |
| `both`      | Shared customer context plus assistant-specific context |

Every read, write, consent change, skip, and deletion is audited. **Audience → Memory** lets workspace admins grant or withdraw consent and erase all shared and assistant-scoped memories for a contact.

## API and MCP

* `GET/PATCH /api/v1/settings/memory` manages the workspace's allowed channels, consent policy, and retention period.
* `GET /api/v1/contacts/memory` lists customer memories.
* `GET/PATCH/DELETE /api/v1/contacts/{id}/memory` reads, updates, or erases a contact's memory. An update must provide the current revision; a stale revision returns `409`.
* Assistant updates can define the memory scope, read and write channels, and allowed categories.

Equivalent MCP operations follow the same permissions and return the same customer-facing data as the REST API.

<Note>
  Only retain customer context with a lawful basis. Explicitly denied consent always prevents memory reads and writes. Unknown consent also blocks when the workspace requires consent.
</Note>