# Your brand has one thread. Your customer has three problems.

Say you're a credit card issuer, and one of your cardholders has three things running with you at once. A disputed charge they're chasing. This month's statement, just issued. A replacement card in the post after a fraud flag. Three separate matters, generated by three different systems, all belonging to one person.

In an email inbox, this resolves itself. Three threads, three subjects, three permanent records, none of them interfering with the others.

On WhatsApp, RCS, Apple Messages for Business or SMS, all three land in the same chronological scroll. The statement notification arrives while an agent is mid-conversation about the disputed charge, the card despatch update drops in underneath, and separating the topics quietly becomes the customer's job.

That isn't a bug in any of those channels. It's a structural property of how they were designed, and it's the clearest thing email still does better than anything built since.

Worth stating plainly, because email tends to get discussed as the channel you keep rather than the channel you choose. The newer platforms get the roadmap attention; email gets maintained.

The usage numbers don't especially support that framing, around 4.48 billion email users worldwide, roughly 361.6 billion messages a day with volume projected to keep climbing through 2027, and 88% of people checking email daily ([Forbes Advisor](https://www.forbes.com/advisor/business/software/email-marketing-statistics/)), but scale on its own isn't an argument. *The more useful question is what email does structurally that the newer channels are still working out how to replicate.*

## Start with fit, not preference

Channels aren't good or bad in the abstract. They're suited to particular moments in a customer journey, and the requirements at each of those moments are genuinely different.

![CX Tech Blog - Customer Journey and Channel Fit - Framework](https://cdn.hashnode.com/uploads/covers/6955f455d07e45e17f91c345/74cde148-aea0-4383-a40c-e3831b079300.png align="center")

**Before and during a purchase**, something is usually blocking the customer: a question about sizing, a payment that won't process, a policy they don't understand. What they **need is immediacy**. Voice remains the most synchronous channel available, and nothing matches it when a problem is urgent or emotionally loaded. In a digital purchase flow, live chat comes closest, particularly with co-browsing, where an agent can see and guide the customer's screen. Messaging embedded where the customer already is, whether that's in-app chat or Apple Messages for Business surfaced from a Maps listing, works for the same reason: no context switch, no waiting. Email is a poor fit here, and obviously so. A customer stuck at checkout isn't going to send an email and wait for a reply.

**After the purchase, the requirements invert.** The customer has transacted, and what they need now is confirmation, status, a record, or notice of something that doesn't demand an immediate response. These communications are asynchronous by nature, and many of them need to be retrievable months later — an expense receipt, an insurance document, a cancellation confirmation, a chat transcript. This is where email earns its place, for structural reasons rather than habit.

*There are exceptions in both directions, of course*. One-time passwords are perfectly deliverable by email, but the expectation of instant arrival makes SMS the practical default. A delivery driver ten minutes away belongs on push or SMS. The framework is a lens rather than a rule.

## The quiet email advantage: every conversation gets its own container

Here's the part that's easy to take for granted, because it has worked invisibly for four decades.

*An email subject line isn't a label — it's a thread initiator.* Sender address plus subject creates what is, in practice, a unique and addressable container, and every new subject opens another one. Which means a brand can hold any number of simultaneous, unrelated conversations with the same customer without any of them interfering with each other.

Go back to the cardholder. The disputed charge, the statement and the replacement card each get a container of their own.

Each has its own subject, each is independently searchable, and each is a permanent record that can be forwarded, filed or produced in a dispute months later. The customer doesn't have to hold any of it in their head, and neither does the agent picking up the case.

Chat channels have no equivalent mechanism. WhatsApp, RCS, Apple Messages for Business and SMS all assign a single chronological timeline per brand-customer relationship, with no way to open a second one for a second topic. Further, adding a promotional message into that same scroll only makes it worse. This isn't a design failure so much as the consequence of a medium built for personal, single-focus conversation being asked to carry multi-topic, long-running brand relationships. The seams show under load.

## Where UX becomes an operations problem

The threading constraint matters more than it first appears, largely because of how enterprise communications are actually organised.

Very few brands run everything through a single system. A typical mid-to-large enterprise has a marketing platform such as Adobe Campaign, Attentive, or Salesforce Marketing Cloud handling campaigns and lifecycle messaging, a CPaaS provider such as Twilio or Vonage handling operational and transactional notifications, and a service platform like Pega, Genesys or NICE handling support and case management.

*Three vendors, three distinct jobs, and one customer who experiences all of it as a single relationship with the brand.*

![CXTech-Blog-3-Vendors-One-Channel-Email-Wins](https://cdn.hashnode.com/uploads/covers/6955f455d07e45e17f91c345/97b07375-1d4b-44b1-8b36-201a3b463c3b.png align="center")

In email, that fragmentation is invisible to the customer and trivial to manage. Each system sends from its own address — [*marketing@brand.com*](mailto:marketing@brand.com)*,* [*notifications@brand.com*](mailto:notifications@brand.com)*,* [*support@brand.com*](mailto:support@brand.com) — so the domain carries brand identity while the prefix carries function. The inbox does the sorting, and no coordination between vendors is required for any of it to work.

SMS handles the same problem more bluntly, with separate short codes or long codes per use case. Plenty of brands run this way today and it works, but it's a trade-off rather than a solution: the numbers carry no brand recognition, so a customer receiving messages from two different numbers has no reliable way of knowing they came from the same company. You get separation at the cost of identity.

**The real difficulty arrives with WhatsApp, RCS and Apple Messages for Business.** These channels were built around a single verified, persistent brand identity per customer, which is genuinely better for consumer trust and precisely what makes multi-vendor operations awkward. Nothing stops a brand from registering multiple WhatsApp numbers, but doing so works against the premise the channel was designed on and gives up the identity advantage that justified moving there in the first place.

## The three flawed workarounds

There are three things brands do about this today. None of them is good.

1.  *Custom orchestration*. Logic that force-closes one conversation before another can start. If a support case is open and a marketing message needs to send, something has to give: either the promotional message is suppressed, or the support session is terminated to clear the thread. This keeps the customer's view coherent, but at the cost of building and maintaining routing logic the channel doesn't provide — and at the cost of occasionally cutting a customer off mid-conversation.
    
2.  *Multiplying identifiers*. The SMS approach applied to newer channels — register separate numbers per function. For many brands this is the pragmatic choice today, and it does work. But it fragments the brand identity these channels were supposed to consolidate, and it multiplies registration, verification and compliance overhead in every market you operate in.
    
3.  *The native app retreat*. Not a workaround so much as a retreat: route anything multi-topic back into your own app. In-app messaging handles threading as cleanly as email does, because the brand controls the interface and can build a proper case list with separate histories. The catch is that it only reaches customers who have installed the app and granted notification permission — and the entire argument for WhatsApp, RCS and SMS was reach, meeting customers where they already are. Solving the threading problem by pulling everyone back into your app gives up the thing that made those channels attractive in the first place.
    

None of these is what anyone would design from scratch. All three are what you do when the platform doesn't give you threading.

## WhatsApp's answer, and where it currently stands

WhatsApp has acknowledged the problem. [**Multi-Solution Conversations (MSC)**](https://developers.facebook.com/documentation/business-messaging/whatsapp/solution-providers/multi-solution-conversations) is their approach: allow several partners — a marketing platform, a CPaaS provider, a contact centre vendor — to operate on the same business phone number, each with their own WhatsApp Business Account, message templates and billing. The brand keeps a single identity while different vendors handle different functions.

That addresses the multi-vendor problem directly, and it's a meaningful improvement over choosing one platform per number. *What it doesn't resolve is the underlying threading question, since two concurrent support cases still land in the same conversation. The unique-thread-per-topic property that email gets from sender plus subject has no equivalent here.*

As for where it actually stands: MSC is still in closed beta. The documentation targeted general availability for mid-2026 — that window is now, and there's been no GA announcement. There's also a coordination gap worth understanding before planning around it. In the current implementation every partner sharing the number receives all inbound webhooks, and WhatsApp's own documentation states that businesses must work with their partners to manage response handling — meaning the routing layer that decides which vendor owns an incoming message is still something the brand builds. Worth factoring in too that WhatsApp is midway through a larger identity transition, the move to usernames and **Business-Scoped User IDs**, which carries its own regulatory questions in several markets and will reasonably compete for roadmap attention.

RCS, as far as published specifications go, has no comparable capability. A brand running separate marketing and support agents on RCS appears to the consumer as two unrelated senders, with no shared brand identity linking them. If something equivalent is in development, it hasn't been documented publicly.

## What to do with this

1.  **Map your concurrent conversations before committing to a channel.** The question isn't whether WhatsApp or RCS can carry your messages, because they can. It's whether your customer relationships routinely involve more than one thing happening at once. If a support case can be open while transactional messages fire and a campaign lands, you'll hit the threading constraint — and you'll be building the orchestration yourself.
    
2.  **Be honest about which workaround you're choosing.** Force-closing threads and multiplying identifiers are both real options in use today, and neither is free. Choose deliberately rather than discovering the trade-off in production.
    
3.  **Keep email in the architecture for what it's structurally good at:** auditable records, multi-topic history, and anything a customer may need to retrieve months later. Sending chat transcripts to email after a live session costs almost nothing and preserves the record somewhere it can actually be found.
    

**Watch MSC, but don't plan on it yet.** It's the most serious attempt any of these channels has made at the multi-vendor problem, and it's also still in closed beta with the routing layer unresolved.

*Earlier posts on this blog have looked at WhatsApp's move to usernames and Business-Scoped User IDs, and what that change means for marketing and consent.*