A unified inbox sounds like a plumbing problem. Connect the channels, normalise the payloads, sort by date, done.
That part is real work but it is not the part that decides whether the inbox is any good. The part that decides it is whether the software knows that the WhatsApp number who wrote on Monday and the email address who wrote on Thursday are the same person.
Every channel gives you a different name for the same human
This is the root of it. Channels do not agree on what a customer is:
| Channel | What you get | What you do not get |
|---|---|---|
| A phone number | A name they chose, an email | |
| A scoped account id | A phone, an email, often a real name | |
| Web chat | A browser identifier | Anything, until they tell you |
| An address | A phone, any prior channel |
None of these is the person. They are four handles that happen to point at one, and no platform will tell you they are related, because no platform knows.
So the inbox has to decide. And deciding wrongly in either direction has a cost.
Merging wrongly is worse than not merging
The temptation is to be clever: fuzzy-match names, guess from a shared first name and city, merge anything that looks close.
Do not. If two records are merged and they were different people, one customer is now reading another customer's conversation history in your reply. That is not a bug report, it is a data protection incident, and it is one of the few software mistakes that can end a customer relationship in a single message.
The rule that holds up is to merge only on identifiers a person deliberately gave you, and to treat everything else as a suggestion for a human to confirm:
- A verified email or phone that matches an existing record is a strong signal. The customer typed it.
- A name that looks similar is not a signal. It is a coincidence with good manners.
- The same device or browser is a hint, and hints belong in a queue for review, not in an automatic merge.
The asymmetry matters. Failing to merge leaves you with two records and slightly worse context, which is annoying. Merging wrongly shows a stranger somebody else's conversation, which is not recoverable.
Context is only useful where the reply is written
The second half of the problem is delivery. Plenty of tools can technically produce a customer's history; far fewer put it where the person typing needs it.
If answering "has this customer bought before" takes two clicks and a new tab, then in practice the answer is not available, because at eleven in the morning with fourteen conversations open nobody makes those two clicks. The context has to arrive attached to the conversation: what they bought, what they last asked, which stage of the pipeline they are at, what was promised.
That is the whole design goal. Not "all your channels in one place", which is a screenshot. "The reply you are about to write knows what happened last time", which is a different product.
What to actually check when evaluating one
Four questions, all answerable in a trial:
- Write in from two channels as the same person. Does the tool notice? What does it do when it is not sure?
- Can you undo a merge? If two records were joined wrongly, separating them again should be possible and should not lose messages.
- What is visible next to the composer? Not what is available somewhere. What is on screen while you type.
- What happens when a channel goes down? A queued message that silently disappears is worse than an error, because nobody goes looking for it.
Summary
- The channels are the easy part. Identity is the product.
- Every channel gives a different identifier and none of them is the person.
- Merge on what the customer deliberately provided. Send weaker signals to a human.
- A wrong merge is a data incident, not an inconvenience. The asymmetry should shape the default.
- Context that is not next to the composer is context nobody uses.
