Couchbase · Use case
Customer 360: one live profile per customer, built from the systems you already run
A customer 360 is one current view of each customer, assembled from the CRM, billing, orders, the app, the website and the contact centre, and served to every channel that talks to that customer. This guide covers why it is hard, the options, a checklist, and how the pattern runs on Couchbase in Saudi Arabia, including where it does not fit.
Published 10 min read
In short, for executives
- The problem: each system knows part of the customer, under its own identifier, and none of them answers "who is this person and what is happening with them now" fast enough for a live channel.
- What a customer 360 is: one profile per customer, kept current from those systems and read by the app, the website, the contact centre and the campaigns.
- The real work: matching identities, deciding which system owns each field, and handling consent. The database is the easier half.
- Where Couchbase fits: as the operational store that holds the profile as a JSON document and serves it quickly at peak; not as the reporting warehouse or the CRM.
- In the Kingdom: the profile is personal data, so where it runs and who can reach it are decided first.
At a glance
| Question | Answer |
|---|---|
| What it holds | One profile per customer: identity, contact points, consents, products held, recent orders and interactions, open cases |
| Who reads it | Customer channels at the moment of contact: the app, the website, the contact centre, branches and campaign tools |
| Where the data comes from | The existing systems, which stay the owners of their records; the profile is a current, joined copy |
| How it stays current | Changes flow in as events or replication, not in a nightly batch only |
| How Couchbase holds it | A JSON document per customer, read by key, queried with SQL++ and found by name or phone through the Search Service |
| From Interkey | Data model, identity rules, ingestion, the cluster or Capella, and support from Riyadh |
What a customer 360 is, and why it is harder than it sounds
Ask a large organisation what one customer bought, what they complained about and whether they agreed to hear from you, and the answer usually sits in five places. The CRM has the account, billing has the invoices, the e-commerce platform has the orders, the app has the device and preferences, and the contact centre has the open case. Each uses its own identifier and spelling of the name.
Read more
A customer 360 joins those pieces into one profile that a channel can read in the moment. Three things make it hard:
- Identity. The same person appears as several records. Matching them needs rules: which identifiers are trusted, and what happens when two records disagree.
- Ownership. The profile copies data; it should not become a second master. Each field needs one system that owns it.
- Freshness. A profile refreshed overnight suits a report, not an agent taking a call about this morning's order.
Why a customer 360 matters for organisations in Saudi Arabia
Customers in the Kingdom move between channels within one journey: they browse on the app, ask on the phone and finish in a branch. Banks, telcos, retailers and service portals face the same expectation: each channel knows what happened in the others.
Read more
Three local points shape the design. Names are often recorded in Arabic in one system and in Latin letters in another, with several spellings, so matching cannot rely on the name alone. The profile is personal data under the Personal Data Protection Law overseen by the Saudi Data and Artificial Intelligence Authority (SDAIA), so consent and purpose belong in the data model, not in a later project. And many organisations keep classes of data inside the Kingdom under the controls of the National Cybersecurity Authority (NCA), which decides where the store, its replicas and its backups run. Your compliance owner confirms which rules apply.
RelatedSaudi Data and Artificial Intelligence Authority (SDAIA)National Cybersecurity Authority (NCA)
Customer 360 options and their trade-offs
There are five usual routes. Large estates often combine two: an analytical copy for reports and an operational copy for channels.
| Approach | Good at | Falls short when | Fits when |
|---|---|---|---|
| Extend the CRM as the hub | One familiar screen for sales and service | Channels outside the CRM need the data at high volume, or other systems own most fields | Most interactions already happen inside the CRM |
| Analytical warehouse or data lake | History, segmentation, reporting across all data | A live channel needs an answer in the moment; loads are usually batched | The main need is analysis and campaign lists |
| A packaged customer data platform | Marketing audiences and campaign activation | Service channels need full operational records, or data must stay in your own environment | Marketing owns the use case and the data scope |
| Query each system at request time | No copy to keep in step | Any source is slow or down; peak load lands on the source systems | Few sources, low volume, tolerant users |
| An operational profile store | Fast reads of the joined profile at peak, for every channel | Teams expect it to replace the warehouse or become the master of every field | Several channels need the same current profile at scale |
How a customer 360 on Couchbase works
In the operational profile pattern, Couchbase holds the joined profile; the source systems keep owning their records. A typical design, which we adapt to your systems, looks like this:
Read more
- One document per customer. The profile is a JSON document under a key such as
customer::{id}, with identity, contact points, consents and a summary of products and recent activity. Long histories, such as interactions, sit in linked documents so the profile stays small. - Changes flow in. Couchbase's Kafka connector writes events from a Kafka topic into Couchbase and iblync, Interkey's own product, loads and replicates data from other systems.
- Channels read and find. A channel that knows the customer reads the profile by key; the Sub-Document API changes one field without sending the whole document. An agent who has only a name or phone number uses the Search Service, which Couchbase documents with fuzzy matching and relevance scoring. Reports and segments use SQL++.
- Reactions. Couchbase Eventing runs JavaScript functions when a document is inserted, updated, deleted or expires, for example to flag a profile whose consent changed.
- Resilience. Replicas on other nodes, and Cross Data Center Replication (XDCR) to a recovery cluster, which can filter documents by key.
Relatediblync
Customer 360 checklist: questions to settle before choosing a platform
Answer these against your own systems before any product decision.
| Question | Why it matters | What a good answer looks like |
|---|---|---|
| Which identifiers link a customer across systems? | Without trusted keys, the profile merges strangers or splits one person | A ranked list of identifiers and written rules for conflicts |
| Which system owns each field? | Two masters for one field means arguments about which value is right | An ownership table, field by field, signed off by the business |
| How fresh must each channel's view be? | It decides events versus batch, and the cost | A stated delay per field group, such as minutes for orders and a day for segments |
| What does each channel need to read? | It shapes the document and the indexes | A short list of reads per channel, with the peak volume |
| How are consent and purpose recorded? | The profile is personal data, and channels must respect the customer's choices | Consent stored with the profile and checked before use |
| Where must the data reside, and who runs the platform? | It decides the deployment before any feature | A named region or data centre, and a named operator for the years ahead |
Customer 360 on NoSQL: where Couchbase fits, and where it does not
It fits when several channels need the same current profile at high volume, when the profile's fields change as new sources join, and when reads must stay fast at peak. In a document model, a new source adds fields, not a schema migration. Couchbase keeps the working set in memory, persists writes to disk, and lets a write that must not be lost, such as a consent change, require a majority of nodes before it is acknowledged; Couchbase notes such writes take longer. Our NoSQL database page explains the model.
Read more
It does not fit as the warehouse for years of history and heavy reporting, as a replacement for the CRM's sales and service workflows, or as the system that decides identity on its own: matching rules are a business decision, carried out in the pipeline. If one system already holds nearly everything and its load is fine, a customer 360 store may be unnecessary, and we will say so. The Couchbase page has the full fit table. The same platform often serves the neighbouring workloads too, such as a product catalogue or a session store.
Where a customer 360 database can run in the Kingdom
| Model | Who operates it | Residency | Billing |
|---|---|---|---|
| Couchbase Server, self-managed | Your team, or Interkey under a written scope | Your own data centre or a cloud region you choose, including inside the Kingdom | Subscription priced by production nodes, quoted on request |
| Couchbase Capella, managed | Couchbase operates the database; you manage data and access | As of November 2026 the published regions include Google Cloud's Dammam region (me-central2) | Billed per node per hour |
Our Capella or self-managed comparison sets out regions and billing. Check where backups and monitoring data go too.
How Interkey delivers a customer 360
-
Discovery.
The systems that hold the customer, the channels that need the profile, the identifiers, the freshness each channel needs, and where the data must reside.
-
Data model and rules.
The profile document, the linked documents, the ownership table and the matching rules, agreed with your business owners in Arabic or English.
-
Ingestion.
Events or replication from each source, with iblync where it fits, loaded in phases so production systems keep their capacity.
-
Build and test.
Couchbase Server or Capella, security, backup and monitoring, then a load test on your own data and a failover drill.
-
Channels go live one at a time.
One channel reads the profile first, compared against the old path, before the next one moves.
-
Support from Riyadh.
Our engineers support the cluster and the pipeline after go-live, and train your team.
Questions buyers ask about a customer 360
What is a customer 360, and how is it different from our CRM?
A customer 360 is one current profile per customer, joined from every system that knows them and read by every channel. A CRM is one of those systems: it runs sales and service work. The customer 360 sits beside it and replaces none of them.
Can our data warehouse serve as the customer 360 for live channels?
For reports and segments, often yes. For an app screen or an agent on a call, usually not: warehouses load in batches and suit large scans, not many small reads at peak. Most organisations keep the warehouse for analysis and add an operational profile store for channels.
Can a customer 360 database stay inside Saudi Arabia under the PDPL?
Yes. Self-managed Couchbase Server runs on infrastructure you operate in the Kingdom, and as of November 2026 Couchbase Capella's published regions include Google Cloud's Dammam region. The PDPL also bears on consent and purpose, so those go into the data model.
How long does a customer 360 take to build?
It depends on the number of source systems, how clean their identifiers are, the freshness each channel needs and your security review. Identity rules usually take longer than the database build. We estimate after discovery, and first channels can go live before every source is connected.
How is a Couchbase customer 360 priced?
Self-managed Couchbase Server Enterprise is a subscription priced by production nodes and quoted on request; Capella is billed per node per hour. Node count follows from the profile volume held in memory, the replicas, and the search and query load. Interkey's work is quoted on separate lines.
How does a customer 360 match a customer recorded differently in each system, in Arabic and English?
Through written matching rules: trusted identifiers first, such as a customer number, mobile number or email, and the name only as supporting evidence, because it is often spelled differently in Arabic and Latin letters. Uncertain matches go to a review queue rather than being merged.
Next
Read next
Next step
Plan your customer 360 data model with Interkey
Tell us which systems hold your customer data today, which channels need the profile, how fresh it must be and whether it must stay in the Kingdom. We will reply with a first data model.
Or directly
+966-11-2180999 [email protected]Tawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia