In the previous article, I discussed Shared Inbox and bringing LINE, Facebook, and website conversations into a shared workspace. Once those conversations become visible together, another question follows: which customer does each one belong to, and where is the rest of that customer’s story? Seeing every message is not the same as understanding the relationship.
This is why Customer 360° matters to the way I am developing HostDrift. The goal is not to put the largest possible amount of information on one screen. It is to help the team understand whom they are serving, what has already been agreed, and what matters before the next interaction—without rebuilding the story from separate systems each time.
A Connected View, Not a Claim to Know Everything
In this article, Customer 360° means a structured view of relevant information associated with the same customer, including profile details and linked history. The foundation is matching and deduplicating records, not simply displaying several tables beside one another. Microsoft’s data-unification documentation similarly separates source selection, deduplication, matching, and the creation of a unified profile into distinct steps. [1]
I do not use “360°” to promise visibility into every customer activity or instant updates from every source. A useful view should also make the source, freshness, and gaps understandable. For me, an honest “not yet known” is more useful than an apparently complete screen that encourages the team to assume it knows everything.
One Returning Customer, Several Separate Stories
Imagine a bicycle retailer that also provides after-sales service. In this hypothetical scenario, a customer buys a bicycle in-store, later asks about accessories through LINE, and books a service appointment through a website form. If those records remain unrelated, the person answering LINE may not know which bicycle the customer owns, while the colleague handling the appointment may miss an earlier discussion.
After establishing that the records relate to the same customer, I would want staff to see the relevant purchase, questions, and open appointment together. The next conversation could continue from the earlier one instead of starting from scratch. This illustrates a workflow I would want to design; it is not a claim that every HostDrift system already automates that sequence.
The value is not just fewer screens. It is continuity. Someone taking over should understand the situation, and the customer should receive an answer consistent with what the business actually agreed—not an answer that changes according to the channel they use.
Profile, History, and Next Action Belong in the Same Story
I find it useful to think in three parts: the profile identifies the customer and contact options, the history explains what happened, and the next action shows what remains to be done. That last part includes an owner, an open request, or an upcoming appointment. Putting these elements together should support a decision, not merely fill the screen.
History also needs to preserve a sequence rather than collapse into a single “last contacted” field. Microsoft Customer Insights, for example, treats customer activities separately from profile information and can display associated activities on a timeline. [2] What I take from that approach is the ability to follow a sequence—an enquiry, a changed requirement, and a follow-up appointment—while retaining access to the underlying details.
I would want the first view to prioritize what the employee needs now, with deeper history available when necessary. An unresolved service request may deserve more prominence than an old campaign interaction. Relevance matters more than displaying everything the system contains.
Recognizing the Same Person Requires More Than a Similar Name
The important boundary is between “these records may be related” and “these records belong to the same person.” I would not want display names or profile photographs alone to determine a permanent merge. Two people can have the same name; family members can also share contact details. Combining those histories would create confidence without creating accuracy.
Account linking therefore needs suitable rules and verification. LINE provides a dedicated process for linking a LINE account to a service account, involving authentication with the service and checks on the account link, rather than matching the name shown in a chat. [3] That addresses control of the relevant accounts, which is different from judging whether two records look similar.
For HostDrift, I want uncertain matches to remain reviewable, incorrect links to be correctable, and the reason for a link to remain traceable. I would rather keep some records separate temporarily than combine them prematurely and mix different customers’ histories.
The Same Company Does Not Mean the Same Person
Business-to-business relationships make this distinction particularly clear. A salesperson might speak to a purchasing contact while an accounts colleague handles the paperwork. Both people may use a shared office number or mailbox, but they still have different responsibilities and conversations. I would model their relationship to the same organization rather than merge them into one person.
Likewise, one individual may interact with a business personally and on behalf of a company. The work, ownership, and permitted access may differ between those contexts. My objective for Customer 360° is therefore not the smallest possible number of profiles. It is a representation that reflects the real relationships accurately.
Conflicting Information Needs Rules, Not Blind Overwriting
Multiple sources introduce a practical question: which value should a combined view use when they disagree? Microsoft Customer Insights supports approaches such as prioritizing sources or using recency when choosing between values. [4] The principle I take from this is that unification needs an explicit decision rule; the system that sends its data last is not necessarily the most trustworthy source.
Imagine a customer confirms a new phone number today, but an older spreadsheet is imported tomorrow. If import time is treated as the only measure of freshness, the old number could replace the confirmed one. I want the design to distinguish confirmation time from ingestion time and retain the source for review. I would also keep current contact information distinct from information recorded on a previous document, rather than silently rewriting historical records.
Shared Context Does Not Mean Unrestricted Visibility
I want sales, service, and marketing to refer to the same customer without requiring identical screens or permissions. Service staff may need open issues and delivery details, while a campaign operator needs the appropriate contact channel and communication choices. Information irrelevant to the role should not become visible simply because it appears in a Customer 360° view.
Another boundary is between a confirmed fact and an inference. Repeated product-page visits might be a signal worth examining, but I would not present them as proof that someone is ready to buy. Similarly, a successful account link should not be treated as permission for every possible use of the data. I want identity verification, access permissions, and communication preferences to remain distinct considerations.
How This Fits the Direction of HostDrift
In the HostDrift CRM development update published on August 11, 2026, I described Customer 360° as a view bringing together profile details, customer source, conversation history, deals, follow-up tasks, and points. [5] The additional point I want to emphasize here is that a consolidated screen is useful only when its information relates to the right customer and the team understands where that information came from.
I see CRM as the place where customer context supports everyday action, and CDP as a part of organizing profiles and events from connected sources. Their collaboration depends on the data and integrations actually available. Having both products does not make every profile match correct automatically, nor does this article mean every design principle described here is already implemented in every workspace.
Start with a View That Improves One Piece of Work
My starting point would be a specific task that genuinely needs shared information, such as helping a service colleague take over a customer request. I would define the required data, how the relationship is established, and who may access it, then examine both normal examples and cases that look similar but concern different people.
I would assess more than the number of successful merges. Incorrect matches requiring correction, time spent finding context, and repeated requests for information are also worth tracking. Those are measures to collect through actual use—not performance percentages I am claiming HostDrift has already achieved.
To me, a good Customer 360° is not about knowing everything about a customer. It is about connecting trustworthy information so the same customer can receive continuous care. When the team can distinguish what happened, what remains uncertain, and what needs to happen next, the customer view becomes more than a summary page. It helps preserve the relationship as channels and responsibilities change.
