All sensible work. But the more demanding question is this:

Can an agent establish why your offer is right for this customer, and help them actually receive the value you promise?

On August 19, we wrote about the Agent-in-the-Middle: the customer's AI increasingly standing between a brand's message and its intended audience. In September, The Customer Journey Without the Customer examined what happens when customers delegate the work itself.

Now businesses are establishing how those agents can identify themselves, access accounts, and act.

The customer's agent is at the door. Businesses are deciding how to answer.

Sierra and Meta announced Personal Agent Protocol on October 6 with partners including Genesys, Instinct, Rocket, Shopify, Stripe, and Walmart. Sierra's October 9 update included NiCE among the earlier participants and added 35 design partners. The draft protocol is known as Poppy (Sierra's announcement, draft and partner update).

The example Sierra showcased made the ambition tangible. At Sierra Summit, Rocket's Alex McGillis asked Meta's personal assistant, Muse, to obtain mortgage pre-approval. According to Sierra's account, Muse discovered Rocket's agent, requested permission to connect, and McGillis signed in to share the necessary information. The agents worked through financing details and produced a pre-approval letter. This was a demonstration reported by the company promoting the protocol, but the potential value is clear (Sierra's demonstration account).

A customer states a goal, grants permission, and agents handle the work across organizational boundaries.

There are two visible approaches to that future.

Sierra, Meta's Muse, Walmart, and the wider Poppy group are building controlled ways for agents to represent customers. Walmart's October 21 announcement adds concrete mechanisms: planned Agent Profiles, approval and spending controls, and an Agent Gateway beginning with a developer beta (Walmart's announcement).

Others are restricting access while those arrangements develop. Amazon blocked Muse in September, before Poppy's announcement, after Meta declined its request to remove the bot (Bloomberg's reporting). Axios reports restrictions at JPMorgan, Bank of America, and Citi, and blocking at Morgan Stanley (Axios's banking report).

Bank of America is also a Poppy design partner. That apparent contradiction is instructive. Supporting controlled delegation and restricting unapproved access can be entirely consistent.

The question is which agents may act, under whose authority, through which channels, and with what accountability.

But access only gets us partway.

Three experiments beyond the promise

We ran three experiments to examine the rest: shopping for hiking shoes for a trip to Yellowstone National Park in the United States using Muse and Tasks in Gemini, then evaluating a switch from Google Fi using Muse.

The shopping context was straightforward: the trip was next week. A useful recommendation needed to account for that timing. The mobile task was to find a worthwhile alternative to an existing service, considering actual usage and connected devices.

We wanted to understand what initiatives such as Poppy could enable, and what businesses and personal agents would still need to work out between them unless shared standards evolve to cover it. These were guided consumer exercises, not tests of Poppy integrations.

A clear price. An unresolved purchase.

Muse took the delivery requirement seriously. It insisted on the costlier Salomon option to preserve arrival timing, without first establishing whether express shipping could make the cheaper Columbia option a better purchase.

The Columbia shoes were listed at $129.99 against $175 for the Salomon alternative. That left a $45.01 product-price advantage that could potentially absorb an express-delivery charge. Whether it actually would remained unverified.

Muse also compared the displayed product prices only. It did not account for sign-up, promotional, or member offers shown on the retailer’s site, which a human shopper would typically weigh. Their eligibility and effect on the final price still needed checking.

The missed step was comparing the complete offers: exact shoes, delivery options, arrival dates, available offers, and the final cost.

For businesses opening up to personal agents, through Personal Agent Protocol, their own MCP servers, or commerce protocols, this means going beyond listing-level information. Product price, sign-up and promotional offers, express-delivery charges, destination-specific arrival estimates, and applicable member benefits need to be connected to the same offer, in a structured form, with their conditions explicit. That gives an agent a stronger basis for comparing what each business can actually deliver for this customer, and at what final cost.

Otherwise, an advantage the business has invested in may contribute nothing to the recommendation.

The promise has to hold from listing to checkout

Tasks in Gemini exposed a different weakness: the delivery promise changed at checkout.

A shopper on a website who sees a later date at checkout can go back and look for a pair that arrives sooner, often on the same site. An agent comparing several sellers may not. A changed delivery date creates a risk that it discards the offer rather than exploring alternatives with the same retailer. With agents, a business may not get a second chance to be chosen.

Delivery estimates can legitimately change with location, inventory, or order cutoff times. The point is not that estimates must never change. It is that an agent needs to know when they do.

For businesses, the information should stay consistent as the purchase progresses. Where an estimate changes, the business should make the change explicit and offer current alternatives that are easy for the agent to retrieve.

Ask first, recommend second

The Google Fi exercise exposed a weakness on the agent's side.

Muse recommended a lower-data Fi plan before it knew how much data was actually being used. Only after reviewing a bill screenshot did it correct its estimate from roughly 20 GB to about 37 GB, which ruled out its first recommendation. It also separated benefits already included in the current plan from premium features the customer didn't have.

Muse recovered well. It broadened the comparison and recommended US Mobile Unlimited Starter on an annual plan, using the AT&T network, after the remaining Fi promotional month. It proposed checking the Galaxy Watch and said it would not cancel Fi or port the number before final checkout approval.

But the order was backwards. There is little value in a long, detailed recommendation that ends by asking for usage, devices, and current benefits. Those questions belong at the start.

Businesses can help. An incumbent that gives an authorized agent a current view of the plan, benefits, and post-promotion pricing saves the customer from reconstructing it. But no business data fixes an agent that recommends before it asks.

Getting connected is only the beginning

Poppy's published 0.2 specification addresses discovery, identity, authorization, access to business interfaces, and conversations. It leaves those interfaces to define their domain-specific information. Recognizing an agent does not establish whether a shoe will arrive in time or a mobile plan supports a particular watch (Poppy specification).

Other standards already represent parts of the value proposition. Universal Commerce Protocol, developed by Google with industry partners including Shopify, documents fulfillment, discounts, and loyalty. Agentic Commerce Protocol, developed by OpenAI and Stripe, provides structured commerce interactions (Google on UCP, UCP Loyalty, ACP overview).

The gap is not an absence of fields. It is whether the benefits, conditions, evidence, and actions form a dependable offer for this customer.

For marketing, differentiation must be something an agent can substantiate. For product, the offer must survive checkout, with changes flagged before commitment. For contact centers, the promise and permissions must carry into recovery.

If the agent buys the wrong item, who can initiate the correction? If delivery misses an agreed requirement, what remedy applies? Can the authorized agent resolve it or reach a person without making the customer explain everything again?

Permissions to research, purchase, and cancel remain distinct. So do completing payment and delivering value.

Two purchases. Both need to earn their cost.

Things are changing fast. Sierra's mortgage example shows useful work being removed from the customer. Walmart is beginning to design explicitly for delegated shopping.

But early-adopter enthusiasm can obscure the distance between an impressive interaction and an experience worth using repeatedly.

The Fi exercise is a small example of that distance. The first answer was long and confident. The useful one arrived only after the customer supplied details the agent should have asked for at the start.

An ordinary customer makes two purchases: the personal-agent subscription and the purchases delegated to it. Both need to earn their cost.

Amazon provides an interesting counterpoint. It blocked Muse, while Subscribe & Save lets customers schedule recurring deliveries with discounts on eligible products, advance reminders, and options to adjust or skip. It handles a narrower job, but a useful one (Amazon's consumer explanation).

Personal agents promise to handle far more complicated jobs. To earn a place in a customer's routine, they have to remove more work than they create.

Until they do, the smartest shopping assistant in many homes may still be the one that never says a word: the automation quietly restocking the cupboard.

About the experiments: These were three individual, guided experiments, not a controlled comparison or protocol interoperability test. The account combines recoverable screenshots with the experimenter's observations. Historical prices and carrier claims are not current verified offers. Completed purchases, watch verification, and a carrier port were not established in the reviewed record.

In a market where ChatGPT has almost become shorthand for the AI-assistant category, Meta did not introduce Muse simply as another place to ask questions.

It gave it a clearer job: Get something done for me.

Book the travel. Fill out the form. Send the email. Negotiate the bill. Find the product. Make the purchase. Come back when you need my approval.

Meta's own positioning is unusually explicit. Muse “doesn't just answer questions, it actually does the work.” It can use a browser, fill out forms, negotiate on a user's behalf, send emails and book travel. For sensitive actions such as making a purchase, it comes back to the user for approval. Meta also says there is no technical experience required and that interacting with Muse works like messaging another person, either in the Muse app or through WhatsApp.

That last part may matter more for customer experience than another improvement in model intelligence. Personal AI agents are not new. What Muse may accelerate is their movement beyond the tech-savvy community. There is no protocol to learn. No agent framework to configure. No need to understand what computer use or MCP means. You tell someone what you want done.

The early consumer response suggests this deserves attention. Sensor Tower estimated that Muse had already reached more than 3.4 million downloads by September 25, barely over two weeks after launch. Estimates of app adoption this early inevitably vary, but the speed of adoption is difficult to ignore. (Ref: TechCrunch).

Whether Muse itself eventually wins this market is less interesting than the behaviour it is helping normalise. For years, CX has been built around understanding and improving the customer journey. Personal AI introduces a new possibility: the customer may increasingly delegate parts of that journey to an agent. Once consumers start delegating outcomes rather than navigating journeys themselves, the structure of customer engagement changes.

The customer may stop navigating the journey

For much of the last decade, one of the most repeated promises in customer-engagement technology has been:

Meet customers on the channels where they already are.

That logic helped push businesses toward WhatsApp, RCS, richer mobile messaging, web chat and increasingly sophisticated digital journeys.

Now consider a customer before a purchase:

Compare this product across these three retailers. Check my email for any discount coupons. Include delivery charges. Buy it from whichever one gives me the lowest final price.

The customer did not visit three websites.

They did not open three apps.

They did not search their inbox.

They did not consciously enter a retailer's acquisition or conversion journey.

They expressed an intent.

The agent worked out the execution.

The same model can extend across the rest of the customer lifecycle.

After the purchase:

Find out why my delivery is delayed and move it to tomorrow evening.

During an ongoing relationship:

Check whether I am overpaying for this mobile plan and find me a cheaper option.

During service:

Find out why my insurance claim was rejected. If they need the invoice, find it in my email and ask where it needs to be submitted.

From the consumer's perspective, all of these experiences can happen in the same place. Their personal agent.

The businesses involved may see something completely different.

A website visit.

A voice call.

A chat session.

An email.

An API invocation.

Or, increasingly, a direct interaction between the customer's agent and an enterprise agent.

The interface between intent and execution has moved somewhere else.

That changes the premise underneath marketing, in-life customer engagement and service alike.

The enterprise may see the transport. The customer sees the outcome.

This creates a strange measurement problem.

If a personal agent compares products by browsing your site, analytics sees web traffic. If it contacts you through a messaging channel, your communications platform sees a message. If it calls customer service, your service platform sees voice. If it eventually talks directly to an enterprise agent or invokes a capability through an API, parts of the traditional customer-engagement stack may not see the interaction at all. Yet none of those necessarily describes the experience the customer had.

The customer experienced: “I asked my agent to sort it out.”

A significant shift in consumer behaviour could therefore hide inside familiar metrics. Website traffic may increasingly include software navigating interfaces designed for people. A purchase attributed to search or a referral may have originated from a recommendation made inside an AI interface. Voice volumes may increasingly include personal agents acting on behalf of customers. The transport still tells the enterprise how an interaction arrived. It increasingly tells us less about how the customer experienced it.

That suggests CX teams need another dimension alongside channel:

Who is acting, for whom, and what are they trying to get done?

Much of today's agentic CX is solving a different problem

The CX technology market is moving quickly on AI. But it is worth being precise about which jobs vendors are actually solving.

On the marketing side, much of the innovation is focused on making the marketer dramatically more productive. Salesforce's Campaign Agent can create, run and optimise campaigns within marketer-defined goals and guardrails. Klaviyo's Composer can draft flows, segments and messages from natural-language instructions. BrazeAI Operator provides prompt-driven campaign creation, analysis and hands-on execution inside Braze.

In jobs-to-be-done terms, much of this addresses:

“I know the marketing outcome I want. Help my team create, personalise, execute and optimise it with far less manual work.”

That is useful.

But it is different from:

“My customer's AI is now helping decide which brands to consider, what information to trust and potentially what to buy. How does my brand participate in that experience?”

There is progress on this second problem too. Contentful's Palmata, for example, is designed to help brands understand and improve how AI answer engines such as ChatGPT and Gemini discover and represent them, including before the consumer ever visits the brand's website.

That starts to address:

“Make my brand discoverable and accurately represented inside an AI-mediated buying journey.”

But discovery is only one part of customer engagement. The harder problem starts when the consumer tells their agent to do something.

A similar distinction exists across communications and customer service. Platforms such as Twilio, Genesys and Five9 are investing heavily in company-controlled AI that can interact with customers, retain context, execute workflows, access enterprise systems and escalate when necessary.

Twilio's Agent Connect, for example, is generally available across Voice, SMS, WhatsApp, RCS and chat; Genesys' Agentic Virtual Agent is designed to move from understanding customer intent to executing multi-step actions; Five9 has both shipped enterprise Voice AI Agents and separately written about the emerging idea of “machine customers.”

Broadly, that solves another important job:

“Help my enterprise AI resolve more customer interactions, with access to the context, systems and people it needs.”

But the emerging problem in this article starts somewhere else:

The customer arrives with their own agent.

Those are not the same jobs.

There are early signs of what the other model could look like

NiCE Cognigy provides one useful example of the direction this could take. NiCE acquired Cognigy in 2025. Cognigy now supports A2A and MCP alongside conventional voice and digital channels.

More importantly for this discussion, an enterprise can publish machine-readable information such as an A2A Agent Card describing its agent's capabilities, authentication requirements and connection endpoint. A compatible personal agent can discover that information and move from navigating an interface designed for humans to engaging the enterprise agent directly.

NiCE has also demonstrated a Muse personal agent engaging a Cognigy enterprise agent.

The job here is materially different:

“Let my customer's agent discover what my business can do and interact with it through a machine-native path.”

That gets much closer to where customer engagement may be headed.

But connectivity alone does not solve the problem.

An agent knowing how to reach your enterprise is one thing. Knowing whom it represents, what the customer has authorised it to do, for how long, under which policies and with what audit trail is something else entirely. Those problems do not disappear because two agents can speak the same protocol.

What should CX professionals do now?

The answer is not to add Muse beside WhatsApp and RCS on next year's channel roadmap. The more important preparation sits underneath the channels.

1. Map the actor as well as the channel

Continue mapping web, app, email, voice, messaging and physical experiences. But add another dimension: who is actually acting? Is it the human customer, the customer's personal AI agent, your enterprise AI, or an employee? That distinction applies across the lifecycle, from product discovery and purchase through in-life engagement and service. Without it, AI-originated behaviour can simply disappear inside existing channel reporting.

2. Design around customer jobs, not only interfaces

If a customer wants to compare an offer, change an appointment, track an order, submit a document, dispute a fee or cancel a service, your enterprise already has some business capability that performs that action. Today those capabilities are usually wrapped in screens, forms, menus and conversational flows. Humans will continue to need good interfaces. Agents need something different: a governed way to execute the underlying job. The strategic question starts moving from “How do we make this interface easier to use?” toward “How do we make this customer job safely executable regardless of who or what initiates it?”

3. Put delegated authority on the roadmap

Authentication asks, Is this really the customer? Personal agents introduce another question: Has the customer authorised this agent to perform this particular action? Those are very different problems. My agent might be allowed to compare insurance products but not purchase one. Retrieve my electricity bill but require approval before paying it. Negotiate a claim but come back before accepting a settlement. Authority may need scope, expiry and revocation. It needs an audit trail. Higher-risk actions may require the customer to step back into the journey. This sits at the intersection of CX, identity, product, risk, security and legal. CX leaders should be involved now, rather than discovering the problem once personal-agent traffic becomes significant.

4. Design for agent portability, not agent-specific integration

Today it may be Muse, ChatGPT and Gemini. Tomorrow there will be more. The obvious temptation is for Marketing to integrate with one ecosystem, Commerce with another and Customer Service with a third. A few years later, the enterprise has recreated the same fragmented engagement architecture it spent the previous decade trying to simplify.

The more durable objective is: Expose customer-facing capabilities once, with consistent identity, authorization, policy and observability, and make them reachable by different agent ecosystems. How an enterprise achieves that should remain an architectural choice.

A CPaaS or CCaaS platform could provide part of the abstraction. An integration or API platform could. A sufficiently capable enterprise may decide to build and govern that layer itself. And in some cases, there may not need to be another intermediary at all. If an enterprise exposes a capability through an open agent protocol such as A2A, a compatible customer agent may be able to discover and engage it directly. CPaaS helped enterprises abstract carrier and channel fragmentation. Personal agents create a similar risk of ecosystem fragmentation, but the answer does not necessarily have to be another intermediary.

The important principle for CX leaders is to avoid asking only: “How do we integrate with Muse?” and instead ask: “How do we expose our customer capabilities so that today's and tomorrow's authorised agents can use them safely?”

That changes the questions CX leaders should be asking both their vendors and their own architecture teams.

• Can a customer-owned agent discover what the business allows it to do?

• Can the enterprise distinguish an AI acting for a customer from the customer acting directly?

• How is delegated authority represented?

• Can context survive between the customer's agent, the enterprise agent and an employee?

• Can the same business capability be reached through human and machine interfaces without recreating the business logic each time?

• And can analytics still identify that the journey originated with a personal agent even when it ultimately arrived over voice, web or messaging?

Answering those questions will increasingly require CX professionals to understand concepts such as A2A, MCP and related agent protocols. Not at the level of a protocol engineer, but well enough to understand what they make possible, what they do not solve, and what their enterprise architecture should support.

The customer journey is not disappearing. But more of it may happen without the customer personally navigating it. The interface between customer intent and execution has moved.

The immediate job for CX professionals is not to predict which personal agent will win. It is to make sure that when customers increasingly hand parts of the journey to personal AI, the enterprise does not become the part that cannot keep up.

Open any capability update from a major outbound platform — Twilio, Braze, Adobe, HubSpot — and the focus is consistent: machine learning to predict churn, generative AI to craft subject lines, predictive algorithms to optimize send times and improve voice connect rates. On the inbound side, contact centre platforms like Genesys, NICE, and Five9 are racing to deploy AI virtual agents that answer customer calls, resolve issues without a human, and shrink handle times. The entire ecosystem is pouring investment into using AI on the enterprise side of the conversation.

Almost nobody is talking about the other side: customers now have their own AI, and it's intercepting your messages before a human ever sees them.

Gmail's AI Inbox reads your email and decides whether it deserves a to-do, a topic cluster, or quiet burial. Apple Mail generates a summary from the body of your email and displays it instead of your carefully written preheader. Apple's Call Screening in iOS 26 has Siri answer phone calls and ask the caller to state their business, before the phone even rings. Samsung's automatic call screening shipped with One UI 8.5 in May 2026. Google Pixel has had Call Screen since 2018.

The new reality of outbound engagement looks like this:

Enterprise AI creates the message → Customer's AI intercepts it → We humans see whatever the AI decided to show us.

This is Intermediated CX. The era of the Agent-in-the-Middle.

Brands are no longer designing for human attention alone. Increasingly, they're communicating with a machine first, and that machine decides how much of the message gets through, in what form, and with what priority.

Two channels where this is already playing out deserve specific attention: email and voice.

The Inbox Gatekeeper

For two decades, email marketing has relied on the curiosity gap, crafting emotionally charged subject lines and preheaders designed to get a human to open the message. That model assumed the human saw the subject line and made a decision.

That assumption is breaking.

Gmail's AI Inbox, currently available to Google AI Plus, Pro, and Ultra subscribers in the US, reads the full body of incoming email and produces two things: a list of suggested to-dos extracted from action items, and topic clusters that group related emails by life context rather than by sender. Apple Mail, since iOS 18.1, generates its own summary of the email body and displays it in the inbox list, regardless of what the sender put in the preheader. Yahoo Mail does the same: an AI-generated one-line summary appears beneath each message in its Priority inbox tab.

None of these features are universal yet. Gmail's requires a paid Google AI subscription (starting at $7.99/month for Plus). Apple's requires an Apple Intelligence-capable device (iPhone 15 Pro or later). Yahoo's is free but desktop-only for now. But the direction is unambiguous, and Twilio's 2025 Email Deliverability Guide quietly acknowledges it: mailbox providers are now extracting data from emails to create summaries in the inbox. The infrastructure vendors are aware. The practical guidance for senders on how to adapt is still catching up.

What actually changes for senders

The shift isn't abstract. It has specific, structural consequences for how emails should be built.

The preheader is no longer guaranteed to show.

Apple Mail's AI replaces your preheader with its own summary, generated from the email body. If the first meaningful content in your HTML is a navigation bar, a logo, or boilerplate legal text, the AI summary will reflect that poorly. The preheader still matters for clients that display it, but it's no longer the only line competing for attention.

Emotional hooks get neutralized.

If a brand sends an email titled "You won't believe what we just unlocked," the consumer's AI may surface: "Promotional email offering 15% off winter boots." The gatekeeper reduces marketing language to literal facts. The curiosity gap doesn't disappear, subject lines still work for the humans who see them, but there's now a second audience reading the same email with no interest in being intrigued.

HTML structure becomes a strategic decision.

AI summaries are generated from the text layer of the email, not from images. Content embedded in hero banners or styled image buttons is invisible to the summarizer. And the AI tends to weight early text most heavily, so if the primary value proposition sits below three rows of header images and navigation links, the summary will be built from whatever text the AI encounters first, which may be boilerplate rather than your offer. Front-loading the key information in the first line of body text isn't a copywriting tip; it's a structural change to how templates are built.

Here's what that looks like in practice:

Before (typical promotional template):

The email opens with a brand logo, a navigation bar, and a hero image containing the offer: "20% off all orders over $100 this weekend." The live text beneath is a generic paragraph about the brand's summer collection. Because the offer exists only as image content, the AI can't see it. The summary might surface something like: "BrandCo summer collection update."

After (restructured for dual audience):

The email opens with a single line of live HTML text above the hero: "20% off orders over $100 this weekend: code SUMMER20." The hero image, navigation, and brand assets follow.

The AI now has a clear, specific text line to work with. The summary is far more likely to surface the actual offer.

Same email. Same creative. The only change is making the key line available as live text in the first position. The human still sees the full designed email. The AI gatekeeper now has something useful to work with.

This is what designing for a dual audience means in practice. You're still writing for the inbox. You're also now prompting the gatekeeper.

The Call Screener

If the email gatekeeper is quietly reshaping outbound marketing, the voice equivalent is doing something louder: it's creating operational deadlock.

Enterprise outbound calling has scaled massively on AI voice agents. Sales development, appointment reminders, collections, patient engagement - AI agents now handle millions of outbound calls daily at a fraction of the cost of human dialers. The technology for generating the call has never been better.

But the technology for answering the call has changed too.

Apple introduced Call Screening in iOS 26. When enabled for unknown numbers, Siri answers the call, asks the caller to identify themselves and state their purpose, transcribes the response, and shows it to the user — all before the phone rings. The user decides whether to pick up based on the transcript. Google Pixel has offered Call Screen since 2018, with the same pattern: the phone's AI answers, interrogates, and transcribes. Samsung shipped automatic call screening in One UI 8.5, replacing its earlier manual Bixby Text Call with an AI that answers, transcribes, and filters without the user touching the phone. Truecaller and Hiya add additional screening, scam detection, and AI-powered call summaries on top.

The consumer's phone is no longer a passive receiver. It's an active gatekeeper, and it's running its own AI.

Where the two AIs collide

Enterprise outbound platforms rely on Answering Machine Detection (AMD) logic that listens to the first few seconds of a call to determine whether a human or a voicemail system answered. Traditional AMD works by detecting a continuous greeting followed by a carrier network beep: the beep signals a voicemail box, and the system either leaves a message or disconnects.

Modern consumer AI screeners don't beep. They answer with a synthesized voice, ask a question, and wait for the caller to respond. There is no greeting-then-beep pattern. There is no carrier signal.

The enterprise bot waits for a beep that never comes. The consumer's screener waits for a voice that never speaks. The customer sees a blank transcript and a missed call. Neither AI accomplished anything.

This isn't a hypothetical edge case. Thoughtly, a voice AI platform, already documents how to make enterprise agents respond correctly to iOS call screening, Android Call Screen, Samsung Bixby Text Call, Truecaller, and Hiya. The collision is happening in production, and platforms that haven't adapted are seeing connect rates degrade with no obvious explanation because the calls are technically being "answered," just not by a human.

What this means architecturally

The immediate fix is tactical: enterprise voice agents need to detect AI screeners (no beep, synthesized greeting, interrogative pattern) and respond with a clear, structured identification of company name, reason for calling, and a request to connect to the human.

Thoughtly's guidance is essentially this: make your bot readable by the other bot.

But the longer-term question is more fundamental. When both sides of a voice call are running AI, the audio channel itself becomes the bottleneck. Two machines talking to each other through synthesized speech, over a lossy audio codec, is an extraordinarily inefficient way to exchange structured information.

The telecom industry has the building blocks for something better. SIP (Session Initiation Protocol), the standard that sets up voice calls, supports User-to-User Information (UUI) headers for metadata that can travel alongside the call setup without being part of the audio stream. In principle, an enterprise dialer could pass a structured payload including company identity, call purpose, and authentication context in the SIP header, and the consumer's device AI could read it, verify it, and present the user with a decision card rather than a transcript of two bots talking to each other.

Nobody may have built this end-to-end in production. It's an architectural direction, not an announced product. But the pieces exist: SIP UUI is a defined standard, Google's Agent-to-Agent (A2A) protocol provides a framework for structured agent coordination, and the consumer-side screeners are already sophisticated enough to act on metadata if it were available. The gap is integration and incentive, not capability.

CX leaders don't need to build for this today. But they should be aware that the current model - enterprise bot talks to consumer bot over audio - is a transitional state, not a destination.

What to do with this

Recognise the dual audience in email. Your email is now read by two entities: the human subscriber and their inbox AI. Template design needs to account for both. Restructure HTML to front-load the primary value proposition in the first line of live text. Keep writing subject lines for humans. Start structuring body content for machines.

Audit your outbound voice stack for screener compatibility. If your AMD logic assumes a beep, it will fail silently against Apple, Google, and Samsung screeners — and the failure will look like a connect rate decline, not an error. Test your voice agents against the major consumer screeners and adapt identification behaviour accordingly.

Track the adoption curve, not just the technology. Gmail AI Inbox requires a paid Google AI subscription (from $7.99/month on Plus). Apple Call Screening is opt-in. Samsung's auto-screens suspected spam by default. Google Pixel has had Call Screen since 2018. Three of the four major device ecosystems now have call screening shipped, and inbox AI summaries are available across Gmail, Apple Mail, and Yahoo Mail. Adoption isn't hypothetical — it's in progress. Planning for full penetration now is cheaper than reacting after it arrives.

Stop assuming the human is the first reader. The Agent-in-the-Middle is the defining shift in outbound CX for the next three years. Every message your brand sends — email, voice, push, SMS — will increasingly pass through a consumer AI before it reaches a person. The brands that design for machine readability alongside human emotion will outperform those that optimise only for the human who may never see the original message.

Earlier posts on this blog have covered WhatsApp's move to usernames and Business-Scoped User IDs, and how email's threading architecture compares to chat channels for multi-topic customer relationships.

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), 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.

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.

In email, that fragmentation is invisible to the customer and trivial to manage. Each system sends from its own address — marketing@brand.com, notifications@brand.com, 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) 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.

Talking of messaging, SMS is something everyone understands. It is more than a technology; it is a medium of communication. WhatsApp successfully piggybacked on this by positioning itself as "free SMS" in markets where text messages cost money, driving explosive global adoption. Over on iOS, iMessage seamlessly filled the rich messenger niche.

RCS did none of this.

Instead, it was introduced to the world as "Rich Communication Services". It is an acronym and a technical specification, offering absolutely nothing for a consumer to hold onto. If the industry had named it "SecureSMS," "Next-Gen SMS," or even positioned it as "SMS 2.0," we would have a simple, consumer-friendly upgrade narrative: "SMS is insecure. Ask your bank to send your one-time passwords via SecureSMS instead". That is a story people understand, much like moving from 4G to 5G.

Instead, the channel hides behind meaningless letters. Every downstream effort like branded messaging, rich cards, and carousels is fighting an uphill battle against a name that creates zero mental model. That is a fundamental positioning problem, and frankly, it cannot be fixed now.

The End-to-End Encryption Game Changer

History is history, and the name is locked in. The question for CX teams today isn't how to fix RCS's marketing problem, but whether the channel actually makes sense for their business right now.

After all, the infrastructure is no longer the bottleneck. The fact that Apple added native RCS support is old news. The real game-changer arrived alongside WWDC 2026 and the rollout of iOS 26.5, which finally brought end-to-end encryption (E2EE) to cross-platform RCS messaging. By adopting the RCS Universal Profile 3.0 in partnership with Google and the GSMA, the ecosystem effectively closed the long-standing security gap between iPhone and Android devices. Messages can no longer be intercepted in transit by intermediaries. The reach exists, and the baseline cross-platform security exists. By ensuring that conversation content remains inaccessible to network operators and intermediaries, this encryption provides brands with a powerful layer of trust, enabling them to handle sensitive customer data—from loyalty account details to private service inquiries—with significantly reduced risk of data exposure.

The real question is where it delivers tangible value.

The OTP Illusion: Why SMS Persists Despite the Danger

Let's look at authentication first. For organizations with a massive customer base, the sheer volume of SMS OTPs represents a substantial, ongoing operational cost. Beyond the financial burden, SMS is notoriously susceptible to severe security vulnerabilities, most notably SIM swap attacks. Because of these inherent flaws, brands are already actively trying to move away from SMS. The market is exploring and adopting far more robust security options, including app-based Push Notifications, dedicated Authentication Apps (like Google Authenticator and Duo), biometric-based logins, and passkeys.

RCS enters this shifting landscape with a mixed value proposition. On one hand, it can absolutely help safeguard against certain kinds of fraud. For example, a verified RCS sender profile makes it incredibly difficult for a fraudster to spoof an OTP message and falsely claim to be an established brand. However, RCS is not a silver bullet; it is not an answer for deeper device-level vulnerabilities such as SIM swap attacks.

In that backdrop, the lack of consumer awareness is a glaring missed opportunity. If consumers understood RCS as "SecureSMS" or "Next-Gen SMS," they might actively demand the channel for their own peace of mind. Instead, the confusing "RCS" positioning leaves the technology lingering in the background. Further complicating matters is the pricing model. Keeping RCS costs similar to, or even higher than, SMS does not help incentivize a mass migration. A quick view of publicly listed messaging pricing on major platforms like Twilio and Vonage indicates that, as of today, RCS pricing is generally higher than or similar to standard SMS rates.

This is not to say brands shouldn't consider moving their authentication traffic to RCS. They absolutely should, provided the costs can be negotiated to be more or less similar to their current SMS spend. The underlying reality is that the opportunity to upgrade authentication messaging is massive, but adoption has been sluggish precisely due to these cost and security considerations.

The Marketer's Dilemma: Massive ROI Potential vs. Abysmal Adoption

Marketing is a different story. RCS offers rich features that SMS simply cannot match, and when brands properly leverage carousels, rich cards, and interactive elements, the channel can drive serious engagement. Plus, RCS offers native read receipts. That is a massive, fundamental benefit over SMS, allowing you to measure the actual effectiveness of your campaigns at a much deeper level.

Yet, adoption lags behind potential. To put this in perspective, out of the 50+ brands I receive marketing messages from, less than 10%, including names like United Airlines, BestBuy, and Saks, utilize RCS messaging. The rest all continue to send standard SMS. Furthermore, amongst the ones who are using RCS messaging, less than fifty percent use any proprietary RCS features like suggested responses. Because sender branding is default, everyone uses that, but the interactive elements remain largely ignored. Too often, brands that do adopt RCS default to sending basic text and a link, entirely missing the point of the channel.

This reality gap exists because of three major hurdles:

1. Implementation Complexity: Setup requires brand verification, compliance checks, and carrier relationship management that take weeks. Add in asset optimization and template testing, and it becomes clear this is far from a self-service workflow.

2. Platform Fragmentation: A carousel that looks flawless on Android might render completely differently on iOS. This complicates A/B testing when platform behaviors diverge.

3. Vendor Maturity: While major CPaaS vendors offer RCS, their interfaces still demand technical knowledge. We aren't yet at a place where a marketing manager can effortlessly drag-and-drop a rich media carousel in minutes.

The Customer Service Disconnect: The "Discoverability" Problem

Customer service and support should theoretically be the killer use case for RCS. The ability to seamlessly share high-resolution media, like a photo of a broken product or a video of a blinking router light, directly within a native messaging app is an incredibly powerful tool for resolving complex issues. Yet, here again, the channel falls short.

The most established pattern in mobile communication is simple: you type a phone number, and you send a message. Going back to our earlier point about piggybacking on what consumers already understand, retaining basic constructs is of massive importance in UX and implementation. WhatsApp nailed this. Consumers know exactly how to text a business's support number. RCS missed this opportunity entirely. There is no universally frictionless option for a consumer to type a business's number or username and instantly initiate an RCS conversation. Instead, discoverability is broken. Brands are forced to use deflection tactics like "click this link" or "scan this QR code" to route a customer into an RCS chat.

This creates a strategic dilemma for consumer brands.

If an organization has to go through the effort of redirecting a frustrated customer from Channel A (like an IVR or a website) to Channel B, why would they choose a third-party messaging protocol? Channel B might as well be their own proprietary mobile app or authenticated web portal, where they completely control the experience and own the data.

If RCS had allowed for simple username or phone number initiation, it would have come in handy for driving massive adoption in support contexts. Instead, the friction of entry makes it a tough sell over owned properties.

The 2026 CX Playbook: What You Should Actually Do Now

For Marketing

If you are a marketing manager who has relied mostly on SMS, you must give serious consideration to RCS, even if you only start with simple upgrades to get the branding benefit. At the very least, you should explore rich messaging features like suggested responses. These are far less complicated to implement than full interactive carousels, avoiding many of the OS parity issues between Android and iOS. If you have the resources to support the channel in its full capacity, do it anyway.

The return on investment makes a compelling case. According to recent benchmark data from Sinch, RCS campaigns frequently see click-through rates three to seven times higher than standard SMS. Similarly, Infobip's market analysis reports that brands using RCS rich cards experience 60-70% higher conversion rates compared to traditional channels, resulting in a cost-per-click that is up to 14 times lower than SMS. Furthermore, Webex Connect's public case studies show staggering returns, with brands experiencing up to a 500% uplift in customer engagement compared to single-channel messaging, and a 25% response rate for RCS compared to just 1% for SMS. And as mentioned earlier, the native support for read receipts fundamentally changes the game, allowing you to measure the true engagement and effectiveness of your campaigns far more deeply than SMS ever could.

For Authentication (OTP)

When it comes to two-factor authentication, RCS is inherently more secure than SMS. If you plan to keep SMS in your 2FA mix as a universal fallback, you should actively work toward replacing your primary OTP traffic with RCS. While there might not be a massive overall cost advantage for a large B2C enterprise, RCS does eliminate the monthly rental fees associated with vanity shortcodes, providing some operational savings.

However, the key to a successful transition is consistency. You should strive to shift your entire OTP traffic across all departments, functions, and product lines to RCS. Upgrading to RCS for only half of your products under the guise of security, while leaving the rest on traditional shortcodes or 10DLC numbers, creates a fractured and confusing experience for consumers. While you obviously cannot execute a complete migration on day one, you need a strategic plan to get there within a reasonable timeframe.

For Customer Service and Support

If you are operating in the US within an industry where frequent media exchanges are critical, and standard SMS/MMS simply cannot handle your use cases, RCS is absolutely worth considering. However, if your customer service model is currently centered on web chat, email, and in-app messaging, and those channels serve your requirements well, the business case for RCS may not be strong enough, especially given the higher per-message costs.

Finally, your customer service implementation of RCS should never be disconnected from your outbound messaging strategy. It is incredibly jarring for a consumer to receive appointment reminders and order confirmations via basic SMS, only to be pushed into an RCS thread for customer support.

Unify the experience, or wait until you can.

The Executive Summary:

• The Identity Shift: WhatsApp is moving from a pure phone-number ecosystem to an account-based model driven by Business-Scoped User IDs (BSUIDs).

• The Commercial Risk: Failing to unify BSUIDs and phone numbers will create duplicate customer profiles, tank Click-to-WhatsApp (CTWA) ad attribution, and trigger Meta quality penalties.

• The Mandate: You cannot outsource this. Businesses must evolve their CRMs and workflows to a multi-identifier, person-centric model immediately.

Here is the business leader’s guide to understanding the commercial, marketing, and compliance impact of usernames and BSUIDs, and how to mobilize your organization to prepare.

Why the Phone-Number Shortcut Is Ending—and What It Costs

For years, many WhatsApp integrations have used the phone number as a massive shortcut. It acted as the routing key, the CRM lookup, the marketing identifier, and the consent anchor.

BSUIDs break that shortcut. A BSUID is a unique identifier scoped to your specific Business Portfolio. Because WhatsApp now allows customers to initiate chats without revealing their underlying phone number, your systems will suddenly start seeing "anonymous" BSUID handles mixed in with your known phone numbers.

If your WhatsApp integration hasn't already been mapped to a robust, person-centric data model, you run the risk of accidentally creating two versions of the exact same customer:

1. Their historical profile (anchored to their phone number).

2. Their new inbound profile (anchored to their BSUID).

This single point of friction cascades across your entire P&L.

The Marketing Cost of Getting It Wrong

For marketing and growth teams, failing to unify BSUIDs and phone numbers turns WhatsApp from a high-ROI channel into a leaky funnel.

Duplicate Sends and Burned Budgets

Imagine a customer who opted into your marketing a year ago via their phone number. Today, they message you using their new WhatsApp username. If your systems don't link those two identifiers, that person now exists on two different marketing lists. When you launch your next campaign, you pay Meta to send the message twice to the same human, landing in the exact same chat thread. Not only are you burning media budget, but you are actively degrading brand trust by spamming your own customers.

Broken CTWA Funnels and Lost ROAS

Click-to-WhatsApp (CTWA) ads are a massive growth engine. Consider the new user journey: a prospect clicks your ad on Instagram and lands in your WhatsApp chat. If they use a username and keep their number private, the API passes their BSUID to your system.

The pace at which this rollout is happening leaves limited time to react. If your marketing automation platform or sales bot drops leads that lack a phone number, you will lose those conversions overnight. You must audit these flows now to ensure your stack captures BSUID-only leads, otherwise, you will be paying Meta for ad clicks that evaporate, leaving you unable to retarget them and tanking your ROAS.

Throttled Campaigns and Quality Limits

Meta imposes strict messaging limits—the maximum number of unique users you can proactively message daily. These limits scale up or down based on your template quality rating, which is driven directly by user feedback (blocks and reports).

If you frustrate customers with duplicate messages, or if a customer opts out on their BSUID but you continue messaging their phone number profile, they will block you. Meta’s systems will detect this negative feedback, downgrade your quality rating, and slash your daily messaging limits. Poor identity hygiene will literally throttle your company's ability to operate on the channel.

The Compliance and Trust Reality

Meta’s business messaging policies are absolute: businesses are responsible for obtaining explicit opt-ins and honoring opt-outs. Usernames and BSUIDs do not relax these rules; they make them harder to execute.

From a regulatory and policy standpoint, a customer doesn't care about your internal database. If they tap "STOP" or use WhatsApp's native block controls on a message sent to their BSUID, they expect you to stop messaging them—period. If you subsequently send a promo to their phone number, you have violated their consent.

For Security and Compliance leaders, this means governance and auditability must evolve:

• Opt-outs must be global. If a user revokes consent on one identifier, your systems must suppress marketing across all known identifiers linked to that person.

• Identity checks must be deliberate. Because a phone number can be recycled and registered to a new user's device (which WhatsApp treats as a brand-new account), neither the phone number nor the BSUID is a bulletproof authenticator. High-risk actions (banking, healthcare) require explicit, multi-factor identity proofing within the chat flow.

• Auditable logs. You must be able to prove why a message was sent, which identifiers were active at the time, and exactly when and how consent was originally captured for that specific ID.

How to Mobilize Your Organization

As a product or CX leader, your job is to pull the right stakeholders into a room and shift their mindset from "API update" to "Identity Strategy." Here is how to assign accountability:

• Product & Engineering: Ensure your WhatsApp integrations map correctly to your person-based CRM. If any middleware still relies on flat, phone-number-keyed tables, it must be evolved so a single "Customer" entity holds multiple phone numbers and BSUIDs. They must also build conversational identity-linking steps—prompting username-first customers to verify an account seamlessly during the chat.

• Marketing & Growth: Enforce audience deduplication and attribution stitching. They must audit all CTWA ad flows, journey builders, and campaign segments to guarantee "one human, one message," regardless of how many IDs that human possesses.

• Customer Service & Support Ops: Own the agent experience and handle-time forecasting. Usernames are mutable (customers can change them). Support Ops must ensure the agent console anchors on the persistent BSUID to show past interaction history, preventing agents from treating returning customers like strangers just because their handle changed. They also need to forecast slight increases in Average Handle Time (AHT) as identity-proofing adds new steps to the chat.

• Risk & Compliance: Centralize consent unification and abuse detection. They need to ensure that opt-outs cascade across all identifiers automatically, and update fraud heuristics to rely on behavioral patterns and BSUIDs rather than simply blocklisting phone numbers.

The Shared Responsibility Model: Testing Your Vendors

Before the username rollout reaches critical mass, leaders should enforce this baseline audit:

• Audit the architecture: Identify every workflow, bot, and routing rule that still assumes a phone number will always be present in the first message.

• Evolve the CRM: Confirm your database can securely map multiple WhatsApp identifiers (phone numbers and BSUIDs) to a single person.

• Test attribution: Verify that Click-to-WhatsApp leads lacking a phone number are captured, attributed, and eventually linked to known profiles.

• Test opt-outs: Run a fire-drill to prove that an opt-out on a BSUID automatically suppresses marketing to that user’s phone number.

You cannot outsource your identity strategy. Meta provides the network, and your vendors (CPaaS providers, contact center and CX enablers, marketing automation platforms, AI bot builders) provide the tools. But when a customer gets spammed or a policy is breached, the liability—and the brand damage—falls on you.

Before this rollout hits critical mass, ask your respective technology vendors these questions to gauge if their platforms enable you to succeed:

1. How does your platform enable the unification of a BSUID and a phone number into a single customer profile? (If they don't cleanly expose both fields for your CRM to map, you have an infrastructure gap.)

2. How does your system empower us to capture opt-outs and enable an opt-out on a BSUID to be cascaded to suppress campaigns targeting that user's phone number?

3. What tools or webhook updates are you providing to help us capture and attribute Click-to-WhatsApp leads that only expose a BSUID?

The Bottom Line

WhatsApp usernames and BSUIDs represent a massive leap forward for consumer privacy. For businesses, they act as a strategic forcing function.

Companies that treat this as a minor technical hurdle will suffer from fragmented customer data, wasted marketing spend, and compliance headaches. But companies that act now to ensure their integrations respect a multi-identifier data model will end up with deeper customer trust, highly accurate attribution, and a massive competitive advantage on the world's most important messaging channel.

Against this backdrop, WhatsApp’s upcoming username feature and the introduction of Business‑Scoped User IDs (BSUIDs) are not minor API tweaks. They are structural changes in how identity works over one of the world’s primary customer channels. This article looks at why that matters, what actually changes for customers, and how it will impact the workflows and applications businesses have already built on top of WhatsApp.

What exactly is the technical change?

Until now, WhatsApp has been fundamentally phone‑number‑centric. To talk to a business, customers needed its number or a deep link; that same number showed up in webhook payloads, CRMs, and routing logic from the very first message.

WhatsApp is now moving toward a handle‑driven, privacy‑preserving model built on two pillars:

• Usernames for people and businesses - Starting later this year, customers will be able to find and contact businesses via usernames (for example, @yourbrand), instead of relying on phone numbers. This makes discovery more intuitive and gives customers a way to interact without exposing their number up front.

• Business‑Scoped User IDs (BSUIDs) - Under the hood, WhatsApp will issue a unique identifier for each user–business pair, known as a BSUID. The same person will have different BSUIDs for different businesses, and the ID is only meaningful within the scope of that business. Technically, the BSUID shows up in API payloads in a format like: whatsapp:CC.BSUID. CC represents a two-letter ISO country code, while the BSUID is an opaque identifier string. The inclusion of the country code in the BSUID can be beneficial in workflows where it serves as a decision-making factor.

When a customer messages your business via username and chooses not to share their phone number, your integration will typically see only this BSUID as the user identifier, not their underlying number.

How will this change affect the customer experience?

From a customer’s perspective, usernames and BSUIDs unlock three important shifts in how it feels to talk to a business on WhatsApp.

1. Safer, lower‑commitment first contact - Customers will be able to initiate a chat or even a call with a business using its username without immediately giving away their phone number. That matters in categories where sharing contact details has historically felt like a big step—banking, healthcare, financial advice, or personal services. Instead of “message this number and hope it’s really the brand,” the pattern becomes “tap this verified username and start a chat,” with the number staying hidden until the customer chooses otherwise.

2. Stronger, more consistent brand identity - Usernames let businesses present a clean, cross‑channel identity: the same or similar handle across WhatsApp, social, and the website, rather than a bare phone number that customers have to save in contacts. Combined with official business profiles and verification, this makes it easier for customers to recognize the real brand, which in turn helps combat impersonation and low‑grade fraud that thrives on look‑alike numbers.

3. Privacy by default, not by exception - With BSUIDs, the business only sees a scoped ID unless and until the customer chooses to share their number or other identifiers. This matches what users already expect from many digital services: they sign in with a phone or email, but external services see pseudonymous IDs rather than raw contact details.

What remains unchanged at a high level?

Even as identity shifts from phone‑centred to username‑plus‑BSUID, the fundamental expectations around consent and outbound messaging remain the same:

• Businesses must still obtain a clear, affirmative opt‑in before sending marketing or other proactive messages over WhatsApp.

• Users must be able to opt out easily, and those choices must be honored promptly.

• Meta continues to track quality and complaint signals, and can restrict templates or accounts that misuse the channel (Ref: Meta Business Policy).

The deeper consent mechanics—how to unify permissions across phone numbers and BSUIDs, and how to avoid accidentally double‑sending campaigns—will be covered separately in Blog 2. For now, it is enough to say: usernames and BSUIDs do not loosen the consent rules; they just change what your systems see when a customer talks to you.

Preparing for these changes as a Customer Experience and Messaging Professional

Most current WhatsApp implementations rely on a quiet assumption: the inbound WhatsApp ID is the customer’s phone number. That single assumption drives a lot of behavior:

• The first message triggers an instant CRM lookup keyed by phone number.

• Routing engines can immediately detect whether this is a known customer and apply segmentation or priority rules.

• Bots can start personalized flows from the very first turn of the conversation.

Usernames and BSUIDs break that assumption in important ways:

• If a customer initiates via username and keeps their number hidden, the webhook your system receives may contain only a BSUID, with no phone number field populated.

• Any code that expects from or wa_id to be a valid E.164 number will either fail validation or quietly store an opaque string in fields that were designed for numbers.

• CRM lookups that depend solely on phone numbers will return nothing, even if the customer has transacted with you before under the same real‑world identity.

That pushes identity resolution out of the transport layer and into the conversation design. Instead of inferring who the customer is from a number you never asked them for, you now have to decide where and how you will explicitly establish identity inside the flow.

Self‑Service vs High‑Trust Flows in a BSUID‑First World

A practical way to think about BSUID‑first sessions is to separate inbound journeys into two broad categories.

1. Low‑risk, anonymous‑friendly experiences

These are flows you can safely run using BSUID as nothing more than a session key:

• FAQs and knowledge‑base lookups.

• Store finders, location queries, and general product discovery.

• Early‑funnel qualification where you ask about needs and interests but do not expose account data.

In these contexts, it does not matter that you cannot immediately map the BSUID to a long‑term profile. The goal is to be helpful, set expectations, and decide whether there is a fit—without touching sensitive data.

2. High‑risk, identity‑dependent experiences

These are use cases where you cannot take action without knowing who you are dealing with:

• Banking and financial services: balance checks, card controls, loan status updates, account‑linked offers.

• Insurance: policy changes, claims progress, coverage details.

• Healthcare: appointments tied to medical records, test results, personal health information.

In these flows, BSUID is not an identity; it is just a way to keep the chat tied to the right person once you have verified them. You will need an explicit identity step—often some combination of:

• Asking for a phone number or account ID and verifying it.

• Handing off to a secure web or app login and then confirming the link back into WhatsApp.

• Using one‑time codes shown in a logged‑in experience that the user must echo in the chat.

For high‑trust sectors, the design challenge is to make these checks feel like safety features, not friction. Clear messaging (“we’re asking this to protect your account”) and tight flows are key.

How Existing Applications and Workflows Will Need to Change

Beyond the conceptual shifts, usernames and BSUIDs will force very concrete changes in the applications and workflows that sit on top of WhatsApp.

1. Evolving the identity model

• Anywhere your systems currently store “WhatsApp ID” as a phone number, you will need to introduce BSUID as a first‑class identifier.

• Many implementations will end up with a model where a single customer record can hold multiple WhatsApp identifiers: one or more phone numbers and one or more BSUIDs.

• Internal services and routing rules should stop validating WhatsApp IDs as purely numeric; they must accept opaque strings like whatsapp:US.xxxxx.

2. Updating CRM and self‑service flows

• Flows that depend on automatic CRM enrichment via phone number will need explicit identity collection steps when the number is not available in the first webhook.

• “VIP” or “high‑value customer” routing that currently runs before any dialogue may need to move after you have either mapped the BSUID to a known profile or collected a trusted identifier.

• For trust‑critical sectors, expect to add small but important steps to confirm identity before exposing personalized data or performing account actions.

3. Rethinking inbound abuse and spam controls

• If you currently maintain blocklists of phone numbers associated with abuse, those lists will not catch bad actors who approach you on username‑only BSUIDs.

• You will need to extend suppression and deprioritization logic to BSUIDs while acknowledging that usernames—and in some scenarios, the BSUIDs associated with them—can change over time.

• The more robust strategy is to combine identifier‑based lists with behavioral signals (message velocity, complaint rate, abuse patterns) and to lean on WhatsApp’s native reporting and blocking features as your first line of defense.

4. Making journeys geo‑aware by default

• Use the BSUID country prefix to start in the right language, show relevant disclosures, or quickly inform customers if you cannot legally or practically support them in their region.

• For multi‑region brands, coordinate this with your legal and compliance teams so that default messages and flows reflect actual obligations and entitlements in each market.

Overall, this is more than a “just add a field” change. It touches data models, routing, self‑service design, spam controls, and geo handling across your stack.

Handled thoughtfully, usernames and BSUIDs will let you offer more privacy, clearer branding, and better‑designed journeys on WhatsApp. Treated as a background protocol change, they will quietly erode personalization, introduce routing gaps, and leave both customers and risk teams uneasy.