The 360° customer history: every channel on one card

Tuesday, 9:40 a.m. A support rep opens the inbox and reads the message at the top, sent from WhatsApp: "Where are we on this? You said you'd get back to me today, like we discussed yesterday." The screen shows that sentence and a phone number. Nothing else. To find out what "yesterday" refers to, the rep checks three places: the email archive, searching by number, no result; the social inbox, where a similar handle appears but cannot be confirmed; and finally the team chat, asking "does anyone recognise this number?" The answer arrives fourteen minutes later. The customer wrote in by email two days ago, was called the following morning, and was promised a reply today. Fourteen minutes spent working out which story a single sentence belonged to.

This article is about the structure that reduces those fourteen minutes to zero: every conversation a customer has had, on every channel, gathered onto one card. We start with why one person splits into several records; then we draw the boundary of what a 360° history should hold, look at the identity keys that merge records and who gets to approve a merge, decide what belongs on the first screen of the card, how much history to show, how internal notes stay separate from customer-facing replies, how context survives a channel switch, what should never be written on a card at all, and in what order to build the whole thing.

Why does one customer split into several records?

The split comes from how channels define identity, not from carelessness. WhatsApp knows a phone number. Email knows an address. Instagram knows a handle, a web form knows a session id, and a call log knows a number again, possibly written in a different format. None of these identifiers recognises the others. Unless you tell it otherwise, the system has no way of knowing that a mobile number and a Gmail address belong to the same person. One customer ends up living as four or six separate rows.

The second cause is tool sprawl. When support tickets sit in one place, sales conversations in another and invoices in a third, records cannot merge technically, so a human merges them by hand, every single time. The third cause is simply time. Someone wrote in two years ago from a number they no longer use. The old record is not deleted, a new one is created, and the two sit side by side for years.

The visible cost is the minutes an agent loses. The invisible cost is the customer telling the same story a third time. For them this is not slow service, it is a break in the experience itself: they notice the company does not remember them, and they start to doubt that anything they say is being written down anywhere.

What belongs in a 360° history, and what does not?

Five things belong. First, conversations from every channel: WhatsApp, email, Instagram, Messenger, Telegram, SMS, web chat and voice on a single timeline. Second, team notes explaining what was decided and why. Third, tags and segment membership. Fourth, commercial context: open opportunities, quotes sent, appointments booked, tickets still open. Fifth, the events that changed the relationship: a cancellation, a refund, a delayed shipment, an upcoming renewal date.

What does not belong is "everything". Once every page view, every email open and every click lands on the card, the card stops being information and becomes noise. A 360° history is a decision screen, not a data warehouse. The test is blunt: if a fact would not change the agent's next sentence, it does not belong on the first screen. If it might be asked about later, it lives in the searchable archive instead.

The most practical way to decide which touchpoints make the cut is to map the journey on paper first. On that map you mark the moments where the customer actually said something or decided something; the first screen of the card is exactly that list of moments. The rest is valuable for measurement, but it is valuable on a different screen.

Which key do you merge records on?

Merging starts by choosing a matching key, and keys differ sharply in how much they can be trusted. Phone number and email address are strong: it is rare for either to belong to two people at once. A person's name is weak. Hundreds of people share one, and used on its own it will glue two strangers onto the same card. The threshold table below summarises which key deserves which decision.

Matching key	Reliability	Risk of a false merge	Recommended decision
Phone number (one canonical international format)	High	Low, apart from shared switchboard numbers	Merge automatically
Email address	High	Low, apart from shared boxes such as info@	Merge automatically
Social handle	Medium	Medium	Flag as a candidate, let an agent confirm
Company domain	Medium	High for individual contacts	Use only to link accounts, not people
First and last name	Low	High	Never use on its own

In practice this means every inbound message is looked up on the key first, attached to an existing card if a match exists, and given a new card if it does not. The contact directory in the unified inbox does this without caring which channel a message came from: the same person's WhatsApp and email threads collapse into one record, with number, channel, tags and last conversation on the same line. The agent never has to ask who a number belongs to, because the number is already attached to a name.

This is not only about agent comfort. Segmentation based on how recently and how often someone buys produces the wrong answer when it runs on duplicated records: a customer split across three cards looks low-frequency on each one, and drops out of the valuable segment entirely. Identity merging is a revenue decision wearing the costume of a data cleanup.

Are these two records the same person, and who decides?

The limit on automatic merging is whether the mistake can be undone. If a strong key matches exactly, the system can decide by itself. If the match is partial — same name, similar number, same city — a human should decide. The correct behaviour there is not to merge but to show the records side by side with a "possible duplicate" flag. The agent will confirm it in conversation anyway: "I think you've also written to us by email before, is that right?"

The second rule is that every merge must be reversible. Gluing two strangers onto one card is far more expensive than leaving two records apart, because one person's messages then appear inside another person's history, and that is a privacy incident rather than a tidiness problem. So every merge needs an audit trail: who did it, when, and on what evidence. Without the trail, fixing the mistake leaves you with guesswork.

The third rule is to stop treating deduplication as a project with an end date. Every new channel you connect creates new duplicates. Reviewing a short "same name, different channel" list once a month is cheaper and more accurate than running a large cleanup twice a year.

What should an agent see in the first ten seconds?

The first screen has to answer four questions. Who is this? What have they asked for before? What happened most recently? Who owns it right now? If those four answers are missing, the agent starts scrolling, and scrolling is time. A layout that works: name, account and tags at the top; a one-line summary of the last three interactions immediately below; open opportunities and open tickets on the right; the owner and any outstanding promise at the bottom.

The 360° customer history in the unified inbox keeps that panel next to the reply box: history, notes, opportunities and tags sit to the right of the conversation, so nobody switches tabs while writing an answer. The difference looks small and changes behaviour. When context lives one click away, most agents do not take that click; they answer without it.

Opening the right card in front of the right person is a separate job, and the card cannot solve it. Without sending each message to the right agent in the first place, a rich customer card is just a good summary read by the wrong person. Assignment rules and response-time targets are the layer that decides who reads the card at all.

Do you show the whole history or a summary?

Both, but not in the same place. Three layers work well. The first is a summary: who the customer is, which segment they sit in, what is open. The second is the last five interactions: date, channel, one line of subject. The third is the full archive — searchable, but collapsed. Most agents stay in the first two layers; the third is opened for disputes, refunds and audits.

The real benefit of layering is that old decisions stop disappearing. The summary band at the top keeps promises made during the customer's first weeks on the product visible months later: which integration was committed to, which limit was raised as an exception. Buried among a thousand archived messages, that information is effectively gone.

How the summary gets written is a separate choice. A hand-typed "current status" field is the most accurate and the least maintained; nobody remembers to update it. The sturdier approach is to derive most of the summary from events the system already records — last closed ticket, last won deal, next appointment — and leave humans only the free-text note.

How do internal notes stay separate from customer replies?

This separation is as much cultural as technical. The technical half is easy: two streams that look nothing alike on screen. Different background, different alignment, an explicit "internal only" marker. Most wrong-box accidents come from two boxes that look the same. In the unified inbox, internal team chat lives on the same screen as the conversation but is visible only inside your organisation, so the discussion never reaches the customer while the decision stays attached to the thread.

The cultural half is what the note is for. A good internal note records a decision: "Pushed the invoice date back by a month, finance approved." A bad one records a verdict: "Difficult customer, gets angry." The first helps whoever picks this up next; the second sends them into the conversation already prejudiced. The whole rule fits in one sentence: write notes you would not be embarrassed to have the customer read.

Handover is the moment that tests the separation. When an account moves from support to sales, or from sales to the team that owns renewals, the card is the only thing the receiving person reads. If the card holds decisions, the handover is a handover. If it holds only files and threads, it is a transfer of paperwork.

How is context kept when the customer switches channel?

The rule is simple: same identity, same card; the conversations themselves may stay separate. If someone emails in the morning and asks the same question on WhatsApp in the afternoon, you get two threads, and both attach to one card. Forcing them into a single thread creates confusion. Seeing them side by side on the card is enough — the agent registers at a glance that this was already raised by email.

The second issue is expectation. Response-time expectations move with the channel: minutes on messaging apps, hours on email. Having both threads open on one card makes it obvious which side is running late. Tags and saved views earn their keep here: a filter such as "no reply and has written from two channels" pushes the most stuck customers to the top of the list.

The third point is that some of this context can be opened to the customer. Keeping frequently asked topics in a written knowledge base reduces the number of times the same question arrives on four channels, and leaves the card holding conversations that genuinely needed a person.

The further step is showing part of the history to the customer directly. A portal where they can see their own orders, invoices and open requests keeps a large share of "any update?" messages out of the inbox entirely, so the card fills up with real conversations instead of status checks.

What should never go on the card?

The card is the most widely viewed screen inside the company. Everything you put on it is, in practice, published to the whole team. Payment card details, identity document numbers, health details and one-time verification codes do not belong there; they belong somewhere with restricted access, if they need to be kept at all. The same applies to free-text notes: if a customer pastes a card number into a chat, leaving that message permanently on the card is a standing risk.

The second boundary is personal judgement. Words like "unreliable", "cheap" or "always complaining" sit on a card for years and shape the first impression of an agent who has never met the person. Record events instead of verdicts: "Payment arrived roughly ten days late on the last three invoices." The same information travels without the prejudice attached.

The third boundary is scope of sharing. When legal, finance or an auditor asks for records, you rarely need to hand over everything. Channel-based export exists for exactly this: pull only email, or only the channels you choose, for a defined date range, and leave the rest in place. You decide the scope of what leaves the system.

In what order do you build a 360° history?

Order matters, because a project started in the wrong order multiplies dirty data as it goes. Connect the channels first and confirm that messages really do land in one place. Then choose the matching key and normalise number formats — the same mobile written with and without a country code will split one person in two. Third, clean the duplicates you already have. Fourth, fix the fields that appear on the first screen and keep that list short. Fifth, write down the note-taking rule. Sixth, start measuring.

Three numbers are enough for measurement: time to first reply, the number of handovers that begin with "who is this?", and the number of open cards belonging to the same customer. Look at all three weekly. If they improve, the card is genuinely being read. If none of them move, the card has been filled in but is not being used.

Once the card is read, a different kind of work becomes possible. The agent stops merely answering what arrived and starts noticing what is about to go wrong. Reaching the customer before the problem grows only works when that context exists; a team without it can react and nothing more.

The long-term return sits in the same place. A team that can see a full history spots renewal risk early and turns keeping customers from a quarterly campaign into part of daily work. The card is both the memory of that work and the place where it is tested.

If you want to pull your own channels into one inbox and test the customer card against real conversations, open a free account and start with two channels.

FAQ

How do I unmerge two records I combined by mistake?

Unmerging is clean when the merge recorded which record each message came from: threads are redistributed by their original channel identity. Without that trail, part of the split has to be done by hand, and some notes end up impossible to assign to the right person. This is the reason to confirm your audit trail works before you let anything merge automatically.

What do I do if a customer asks me to delete their history?

A deletion request covers personal data, not the entire card; commercial and invoicing records are assessed under separate obligations. The practical route is to log the request in writing, decide which fields are removed, and leave a trace of who performed the deletion. Keeping the remainder in anonymised form usually satisfies both the request and the obligation.

How many channels should I connect — all of them?

Connect the channels your customers actually use; opening an unused one only adds maintenance. A good starting set is whichever channels carried ninety per cent of the last three months of messages. Add the rest as demand appears. Since every channel shares the same card structure, adding later costs very little.

Is a 360° card too heavy for a small team?

It is usually most valuable in a small team, because there everyone talks to every customer and nobody holds the full record in their head. For a team of three, the first screen might be five fields. Weight comes from fields nobody fills in, not from the number of fields.