Asynchronous Service

The End of the Live Queue

Customer service has long assumed a single design pattern: the live, synchronous session. A customer calls, waits, connects, resolves — all in one continuous block of time, or the interaction is deemed to have failed. That assumption is now breaking down. Asynchronous service, built on persistent messaging channels, is replacing the live queue as the default model for customer support.

The mechanics are simple but the implications are not. A customer messages a business about a delayed order at 9am, closes the app, gets on with their day, and receives a resolution at 3pm in the same thread. No hold music, no queue position, no case number to quote, no repeating the issue from scratch. The channel remembers, even if the customer and the agent both step away. WhatsApp Business and Apple Messages for Business have made this ordinary rather than novel — the conversation is treated as a persistent object that both sides can return to, not a live call that must be completed or lost.

Why the Thread Beats the Call

The scale of adoption is no longer marginal. Meta reported in 2022 that more than 175 million people message a business account on WhatsApp every day — a figure that signals persistent-messaging service has moved well past pilot status and into default infrastructure for a large share of consumer-facing industries.

What's notable is not simply that customers are messaging businesses at volume, but that the queue itself is disappearing as a design concept. Apple Messages for Business and the WhatsApp Business API both default to threaded, persistent conversations rather than live queues — customers see a chat history, not a wait time. That single interface change quietly removes the psychological cost of waiting, because waiting is no longer visible or synchronous. There is nothing to stare at, no position to refresh.

The shift is not from slow service to fast service. It is from service that demands presence to service that persists without it.

Rebuilding the Back End Around Threads

Contact centre vendors — Zendesk, Salesforce, Twilio among them — have rebuilt core workflows around message threads that route to different agents over time, rather than single-session calls. This is a deeper architectural shift than it appears. A live call requires one agent, present, for the duration. A persistent thread can pass between agents, shifts, and even days, provided the context travels with it. That requires new infrastructure: shared history, visible prior exchanges, and routing logic that treats a conversation as an ongoing record rather than a closed event.

This is also why context persistence, not response speed, has become the real differentiator. Because the thread retains history, customers tolerate longer resolution windows — provided they never have to re-explain the issue from scratch. Speed still matters, but it has been demoted. What customers will not tolerate is being asked to restate a problem they already described, to a system that has apparently forgotten it existed.

What Changes for Customers and Operations

For customers, the benefit is straightforward: support now fits around their day instead of demanding they wait live for it. But this comes with a corresponding expectation — that the business, not the customer, carries the context forward. Async service only works as a trust exchange if the thread genuinely remembers; if it doesn't, the model collapses back into the exact repetition problem it was meant to solve.

For businesses, async threads reduce concurrent agent load and cut abandonment, since customers are no longer sitting in a live queue with an incentive to hang up. But this requires new staffing and SLA models built around resolution windows rather than talk time. A model designed for synchronous, single-session calls does not map cleanly onto conversations that may span hours or days and multiple agents.

For CX and operations teams specifically, this forces a metrics overhaul. Legacy measures like average handle time and time-to-first-response lose much of their meaning when the "call" no longer exists as a discrete unit. Operations must shift toward thread-level resolution tracking — measuring whether an issue was actually closed, and how long the full arc took, rather than how quickly someone picked up.

The Practical Path Forward

This pattern is already relevant across retail and e-commerce, telecommunications, banking and financial services, travel and hospitality, and logistics and delivery — anywhere high-volume, low-urgency service queries currently clog live channels unnecessarily. The sensible move is to adopt now: pilot persistent-messaging channels for exactly those lower-urgency, high-volume cases, and redesign SLAs around resolution windows rather than response time. The organisations that treat this as a channel swap will miss the point. The ones that treat it as a redesign of what "resolution" means will be the ones customers stop dreading to contact.