How do you keep one conversation across channels?
Every email, text and call from a contact needs to write to the same underlying record, not a separate log per channel. Otherwise the same person becomes three unconnected histories.
The short answer
- A contact who emails, then texts, then calls should read as one continuous history, not three disconnected interactions. Every channel has to write its activity against the same contact record rather than its own private log.
- The most common failure is tool sprawl. A separate app per channel, each with its own copy of who this contact is and what has happened, with no shared identity linking the copies.
- Matching contacts across channels by phone number and email is the usual starting mechanism. People use more than one of each, so some duplicates and manual merging are a normal part of keeping this clean, not a sign the system is broken.
- The payoff is not cosmetic. A rep or an agent deciding what to do next needs the full picture. A decision made from the email history alone, missing a recent text exchange, is a decision made on incomplete information.
Why 'connected inbox' undersells the actual requirement
A shared inbox that shows email and text side by side looks like it solves this. The real requirement sits one layer deeper. Every channel needs to resolve to the same contact identity, not only appear in the same screen. Two tools can display messages next to each other and still track two separate notions of who the contact is. That shows up the moment someone tries to see the full history and gets two partial pictures instead of one.
This becomes a real problem the moment a cadence or an agent needs to make a decision. If a contact replied by text but the email sequence has no way to see that reply, because the two tools do not share a record, the email sequence keeps running as if nothing happened. The failure is not visual. It is structural. The systems do not agree on who the contact is or what has already happened to them.
Separate tools vs. one shared contact record
| Separate tool per channel | One shared contact record | |
|---|---|---|
| A reply on one channel is visible to the others | No, unless manually synced | Yes, automatically |
| Duplicate contact risk | High, each tool tracks its own copy | Lower, one identity across channels |
| What a rep sees when opening the contact | Partial history, channel by channel | Full history in one place |
| Cadence logic can react to any channel's activity | No | Yes |
What to check in your own setup
Pick a contact who has interacted through more than one channel and try to rebuild their full history. If that requires opening two or three tools and piecing together the timeline yourself, the channels are not unified, however the individual tools look. Check whether a reply or an action on one channel changes behavior on another. That is the real test of whether the systems share an identity or only sit next to each other.
Disclosure: SalesCrew is our product. Email, LinkedIn, inbound and calls already write to one contact record and timeline today. SMS as a further channel in that same record is on our roadmap and not shipped yet. The design goal described here, one identity whatever the channel, is the standard we are building every channel against.
A shared screen is not the same as a shared record
Questions
- Does this require one single inbox UI for everything?
- Not necessarily one screen. What matters is that every channel's activity is tied to the same underlying contact record. Anyone looking at that contact sees the full picture, whether that view is one unified inbox or several views pulling from the same record.
- What is the most common way this breaks?
- Separate tools per channel. An email tool, a texting app, a call log spreadsheet, each keeping its own copy of contact history with no shared identity linking them. The same person shows up as three unconnected records.
- Does matching by phone number and email reliably link a contact?
- It is the common starting point. People use more than one email or number, so a system that matches only on exact string equality will still create duplicates. Some manual reconciliation is usually still needed.