A single customer view sounds like a database project and usually fails as one. The hard parts are deciding which system is allowed to be right, who may correct a record, and who is permitted to see the whole picture.
This guide covers those decisions in the order they have to be made, and explains how to prove the idea with one service team before committing to anything larger.
Key takeaways
- Agreements before storage: A single customer view is a set of decisions about identity and authority; the database comes afterwards.
- Count false matches, not misses: Merging two customers shows one person another's history and is much harder to undo than leaving them apart.
- Start with one service desk: A view built for everybody becomes a data programme; a view built for one team ships in a quarter.
- Retire the old claims: Copying four systems without ending any of their authority adds a fifth place for the data to disagree.
Start with the business outcome
Success here looks like a person on a call seeing who they are dealing with, without asking the customer to repeat anything. Write down which teams need that and for which customers, because a view built for everybody becomes a data project and a view built for one service desk ships in a quarter.
Trace one customer who has contacted you three times this year and find every record of them. The duplicates, the near-matches and the system nobody mentioned are the scope, and that trace will be more accurate than any inventory of databases.
Four areas to define before choosing features
1. Identity
Write the rule that decides two records are the same person, then run it over a sample by hand. Count the false matches rather than the misses, because merging two customers shows one person another person's history and is considerably harder to undo.
2. Activity
Decide which events are worth keeping and for how long they stay useful. A view that stores everything becomes slow and hard to read, and the service team usually needs the last six interactions rather than six years of them.
3. Service History
Work out what somebody on a call actually needs in front of them. Open cases, the last conversation and the current entitlement generally cover it, and anything beyond that is a reporting requirement rather than a service one.
4. Permissions
Set out who may see a full record, who sees a reduced version, and how that is logged. Getting this wrong is the risk that turns a useful customer view into a problem, and it is easier to design in now than to retrofit after the first complaint.
Decide what to measure
Choose a small set of measures tied to an operating decision. A metric deserves space in the product only when someone owns it, understands its definition, and can take a clear action when it changes.
Manage the most likely risks
| Decision area | Risk to make visible | Practical safeguard |
|---|---|---|
| Identity | Two customers get merged | Run the matching rule over a sample by hand and count the false matches before anything is automated. |
| Activity | Everything is kept forever | Decide how long each event type stays useful and delete on that schedule. |
| Service History | The view holds more than service needs | Start with what somebody on a call must see, and add nothing else in the first release. |
| Permissions | Access is wider than intended | Define who sees a full record and who sees a reduced one, and log reads from day one. |
Build a roadmap around evidence
1. Find the duplicates
Take ten known customers, search every system, and count the versions you find.
2. Agree the matching rule
Write it down, test it by hand, and decide who may merge and who may undo a merge.
3. Give one team a read-only view
Pick the service desk with the most repeat contacts and connect identity, activity and history for their customers only.
4. Measure the repetition
Count how often customers are still asked for information you already hold, and widen only when that number falls.
For the wider case this record usually supports, see Digitalization in Business: Benefits and Roadmap.
Plan adoption and operating ownership
Launch readiness here is mostly about trust. Service staff will keep their own notes until the joined view is right more often than their notes are, so plan for a period where both run, and give people an easy way to flag a record that looks wrong. The flags are your correction backlog and your quality measure at the same time.
Create a service blueprint for both sides of the screen
For a single customer view, draw the user journey across the top and the staff workflow underneath it. Connect each customer action to the visible response, backstage action, source system, and evidence of completion. Use Identity, Activity, Service History, and Permissions as checkpoints rather than isolated modules.
Use the blueprint to decide what belongs in the mobile or web experience, what belongs in the back office, and what belongs in shared backend services. This makes the goal to connect identity, activity, service history, and permissions without creating another disconnected database visible as one service rather than several disconnected deliverables.
A 30-day validation plan: Single customer view
Days 1 to 5: count the same customer twice. Take ten customers you know well and look for them in every system that holds customer records. Count how many versions exist, note what differs between them, and record which system your staff actually believe. That belief, rather than the architecture diagram, tells you where the source of truth already is. Include the spreadsheets kept on individual machines, because those hold the corrections people made when the official record was wrong.
Days 6 to 15: write the matching rule and test it. Draft the rule that decides two records are the same person and run it over a sample by hand. Count the false matches, which are worse than the misses, because merging two customers is harder to undo than leaving them apart. Decide now who is allowed to merge, and what the route back looks like when a merge was wrong. Run the rule past whoever handles complaints, as they will recognise the cases where a wrong match caused a customer to see somebody else's history.
Days 16 to 30: connect one system, not four. Pick the service team with the most repeat contacts and give them a read-only view that joins identity, activity and service history for their customers only. Measure whether they stop asking customers to repeat themselves. If one connected view does not change that, a larger platform will not either, and you have spent a month rather than a year finding out. Keep the view read-only for the first month, so the question stays whether a joined record helps rather than who is now allowed to edit it.
A practical worksheet: Single customer view
A single customer view becomes another silo when it is scoped as a database instead of as a set of agreements. Fill these rows with the agreements first, and let the storage decision follow them.
| Decision area | What to record |
|---|---|
| Identity | The rule that decides two records are the same person, who may merge them, and what happens to a merge that turns out to be wrong |
| Activity | Which events are worth keeping, how long they stay useful, and which systems are allowed to write them |
| Service History | The conversations and cases a person on a call needs in front of them, and the ones that only matter in aggregate |
| Permissions | Who may see a full customer record, who sees a reduced version, and how that is logged |
| Measurement | The share of enquiries resolved without asking the customer to repeat information they have already given |
Write down which existing system stays the source of truth for each row. A single customer view that copies four systems without retiring any of their claims to authority has added a fifth place for the data to disagree.
Related guides
- The groundwork for this is set out in Digital Transformation Roadmap: A 7-Step Business Guide.
- A useful companion to this one is Paperless Workflow: How to Digitize Paper-Based Processes.
When the priorities in How to Plan a Single Customer View Without Creating Another Silo need sequencing against a real budget, Discuss Your Digital Roadmap.
Ali Boran Gazel