Customer 360, assembled
from what already happened
Conversations from every channel, phone numbers caught mid-thread, and live data from your own systems resolve into a single customer record — one your team reads and your agents answer from.
How the record builds itself
No data-entry project. The profile is derived from conversations you are already having.
Connect your channels
Every conversation the inbox handles builds the record: who wrote, from where, about what. Nothing extra to fill in — the profile exists because the conversations do.
Add your own data
Attach an enrichment endpoint, import a spreadsheet, or sync from an internal API. Choose whether each source shows inline, in a panel, or stays hidden from the operator view.
Work from the whole picture
Your team answers with the history in front of them, and your agents answer with the same context — including the parts that live in your systems rather than ours.
Connect your channels
Every conversation the inbox handles builds the record: who wrote, from where, about what. Nothing extra to fill in — the profile exists because the conversations do.
Add your own data
Attach an enrichment endpoint, import a spreadsheet, or sync from an internal API. Choose whether each source shows inline, in a panel, or stays hidden from the operator view.
Work from the whole picture
Your team answers with the history in front of them, and your agents answer with the same context — including the parts that live in your systems rather than ours.
A profile that is current because it is derived
Not a form someone has to remember to update.
One person, every channel
The Facebook comment, the Messenger thread and the Zalo message resolve to one customer with one timeline. Where a match is genuinely ambiguous they stay apart until someone merges them, rather than being guessed together.
Contact details you did not type
Phone numbers customers write mid-conversation are detected, deduplicated against what you already hold, and attached to the record — with the staff numbers and forwarded quotes curated out instead of counted.
Your systems, in the panel
Point it at an endpoint you control. We send the identifiers we hold; you answer with orders, loyalty tier, open tickets — shown beside the conversation without being copied into our database.
Context your agent can use
Switch external context on for a source and the agent replying reads it from cache — so it can answer about the order without your internal API being on the critical path of every message.
Bring the customers you have
Import from a spreadsheet with a column mapping it remembers, or sync from an HTTP source on a cursor so each run resumes where the last one stopped. Imported records match into the customers your conversations already created.
Gated at the database, not just the API
Customer records are governed by the workspace permission system and enforced at the database level, so a member without the permission cannot reach the rows by any route — including a direct query.
What a customer record holds
What arrives on its own, what you bring, and who is allowed to see it.
What is on the record
- Conversations from every connected channel
- Detected phone numbers, curated
- Email, name and profile details
- Tags, labels and custom attributes
- Conversation summaries
Enrichment from your systems
- An HTTP endpoint you control, GET or POST
- Identifiers sent: conversation, channel, external id, phones, email, name, attributes
- Display inline, in a panel, or hidden
- Restrict a source to direct or group conversations
- Auth header encrypted at rest, never returned to the browser
Getting customers in
- Spreadsheet import with a remembered column mapping
- HTTP sources in connect or sync mode
- Cursor-based sync that resumes where it stopped
- Sync history with counts and errors
- Upsert on your external id, so re-imports update
For agents
- External context opt-in per source
- Served from cache, off the reply critical path
- Memory the agent keeps about the customer
- Tools that can act on the record
For your team
- Customer list with search and filters
- A detail page per customer
- Jump from a conversation to the record and back
- Merge two records when a match was missed
Control
- Permission-gated, enforced at the database
- Channel-level access limits which customers a team sees
- External data fetched, not silently copied
- Account deletion removes the workspace record
What your team stops piecing together
The manual reconstruction that disappears when the record assembles itself.
A customer who wrote on three channels is three strangers to your team
One record, one timeline, whichever channel they used last
Phone numbers copied out of chat threads into a spreadsheet by hand
Numbers detected, deduplicated and attached automatically
Order history in the ERP, conversation in the inbox, and an agent that knows neither
Your own systems rendered beside the conversation, and readable by the agent
A CRM import that creates a parallel list nobody reconciles
Imports that match into the customers your conversations already created
Everyone with an account can read every customer
Permission-gated records, enforced at the database as well as the API
Questions about Customer 360
What teams ask before they connect an internal system to it.
The record is assembled rather than typed in. Conversations from every connected channel, phone numbers detected in those conversations, tags and custom attributes your team sets, and data pulled live from your own systems all resolve to one customer — so the profile is current because it is derived, not because someone remembered to update it.
Yes. You point it at an HTTP endpoint you control. We send the identifiers we hold — conversation, channel, external id, phone numbers, email, name, custom attributes — and your endpoint answers with whatever it recognises: orders, loyalty tier, open tickets. Nothing is copied into our database by default; it is fetched and displayed.
Only if you switch it on for that source. External context is opt-in per source, and when enabled the agent reads it from cache rather than making your endpoint answer on every message. That keeps a slow or rate-limited internal API from becoming the thing that delays a customer reply.
Yes — from a spreadsheet with a column mapping you set once and it remembers, or from an HTTP source that syncs on a cursor so each run picks up where the last one stopped. Imported records match into the same customers your conversations already created rather than sitting in a parallel list.
Customer data is gated by the workspace permission system, and the gate is enforced at the database as well as the API — a member without the permission cannot read the rows by any route. Channel-level access applies on top, so a team that only works one Page only sees the customers from it.
They are matched into one customer, with both threads on one timeline. Where a match is ambiguous the platform keeps them separate rather than guessing, and your team can merge them explicitly.
See your customers as one person
Connect a channel and the records start building on their own. Free to start, no credit card.