Asynchronous Communication in Customer Service
Asynchronous communication is any customer interaction that doesn't require both parties engaged at the same time. The customer sends a message when it suits them; the agent responds when they're available. Email, messaging, social media and help desk tickets all run on this model. It's the fastest-growing mode in Australian customer service — and the mode where service failures most often hide in plain sight.
Why it matters
Async channels offer flexibility, higher concurrency and extended service windows at lower cost per interaction. Done well they are the workhorse of modern customer service. Done badly they are where customer experience quietly collapses — because async failures don't show up the way sync failures do.
What makes this mode tricky
Modern messaging platforms are designed to feel live. Typing indicators, delivery receipts, "agent is connecting" messages — all set customer expectations of sync-grade response times, while the operating model behind them is ticket-queue async. The gap is where most complaints originate.
What this guide covers
A clear definition, the async channels in use today, when to deploy async well, the real failure mode behind most async complaints, the staffing and KPI model async requires, and how to design async channels that don't quietly destroy customer experience.
What is Asynchronous Communication?
Asynchronous communication doesn't require both parties to be engaged simultaneously. Messages are sent, received and responded to on each party's own schedule. The response time is typically measurable in hours or days rather than seconds — and critically, neither side is live-waiting on the other.
Plain-English Definition
Asynchronous means "not at the same time." The customer sends their question when it suits them. The agent answers when they're available. Neither is waiting on the other in real time — and, crucially, neither should expect the other to be.
✓ What asynchronous communication IS
- Delayed-response, non-simultaneous exchange
- Participants engage on their own schedule
- Responses can be composed thoughtfully
- Customer expectation: "they'll get back to me within the stated window"
✕ What asynchronous communication is NOT
- The same as "slow" — well-run async can be very fast
- Appropriate for every interaction — urgent issues fail here
- Lower-risk than synchronous — the failures just hide longer
- Defined by the channel alone — defined by customer expectation of response time
The counterpart
Asynchronous and synchronous communication are paired modes. Where async means engagement on each party's own schedule, synchronous means real-time presence. Both are legitimate; the question is which interaction belongs in which mode — and whether the customer knows which one they're in.
Asynchronous Channels in Customer Service
Asynchronous and synchronous channels sit alongside each other in every modern contact operation — but they behave very differently. The diagram below shows both modes side by side, with the asynchronous channels highlighted. The messaging apps category sits at the boundary between them, which is where async channels most often fail — often looking live while behaving as ticket queues.
Asynchronous channels at a glance, with the synchronous counterpart shown alongside. Messaging apps sit at the boundary — the category where customer expectations and operating models most often diverge, and where async channels most often fail quietly.
Four asynchronous channels dominate customer service in Australia today. They share the async operating model but differ sharply in customer expectation, staffing requirement and brand exposure.
The benchmark async channel. Messages queue in the agent's inbox, responses are composed at a considered pace, SLAs are measured in hours or days. Customer expectations are well-established and typically realistic.
Messaging Apps
WhatsApp Business, iMessage, Facebook Messenger, SMS, in-app chat widgets. Async by operating model but often sync in customer perception — the fastest-growing and highest-risk async channel.
Social Media
Public comments, direct messages and replies on X, LinkedIn, Facebook and Instagram. Async by design but with public-facing stakes — a slow reply is visible to every other customer watching.
Help Desk Tickets
Customer submits an issue via web form, portal or email. Ticket is routed, prioritised and resolved within a documented SLA. Response time expectations are set explicitly at the point of entry — which is why this channel tends to fail least.
Asynchronous vs Synchronous — When Each Wins
Neither mode is universally better. The question is never "async or sync" — it's "what is this specific interaction asking for?"
When asynchronous wins
Documentation-heavy requests (claims with attachments, policy changes). Non-urgent general enquiries. After-hours contact. Customers who want a written record. Interactions where the customer benefits from time to think.
When synchronous wins
Complex issues requiring live clarification. Emotionally charged interactions. Sales conversations where objection-handling matters. Outages and emergencies. Any scenario where tone and empathy materially change the outcome.
When it's a judgement call
Routine account enquiries, status updates, simple changes. These work either way — the right answer is usually whichever mode costs less to serve at the quality level the customer expects.
The principle behind the choice
Choose asynchronous when the cost of live capacity exceeds the benefit of immediacy, AND the customer can genuinely wait the stated response time. Choose synchronous when the cost of delay or miscommunication is high. Most centres get this wrong by defaulting to async for cost reasons alone — which pushes urgent interactions into a channel that can't serve them well.
The Failure Mode Hiding in Plain Sight
The single most damaging pattern in Australian contact centre customer experience right now is asynchronous channels dressed up as synchronous ones — interfaces that look live, operating models that aren't, and customers left with expectations the business cannot meet.
Modern messaging platforms are designed to feel live. They show typing indicators, delivery receipts, green status dots and "agent is connecting" messages. A customer arriving via a messaging widget often cannot tell whether they're in a live queue or a ticket queue. The business treats it as async; the customer treats it as sync. When the reply takes three days, the customer doesn't calmly accept it as "an email response" — they experience it as a three-day-ignored live chat.
Example of Poor Asynchronous CX
Real chat interaction with a major Australian health insurer — dates and identifying details redacted
for a response
Sorry we couldn't catch that. We'll put you through to an agent for assistance.
Implies a connection to a live agent
Before I transfer you to an agent, I'll need some of your details.
Is your query related to an existing policy?
To start, may I please get your full name?
Customer had already been authenticated to access the chat — re-validation is wasted effort
[redacted — full name provided]
What is your date of birth in DD/MM/YYYY format?
Why is this necessary? I was logged in when I made this enquiry.
Please note, your date of birth needs to be written as DD/MM/YYYY
Rigid input format. No grace, no acknowledgement of the customer's frustration
[redacted — DOB provided in exact format]
And finally, what is your membership number? (Type 'skip' if you don't have)
[redacted — membership number provided]
Thank you, adding you to the queue now. If you have notifications enabled on your device, there's no need to wait as you'll be notified the moment we respond.
"Adding you to the queue now" — reinforces the live-agent expectation a second time
Welcome to [redacted] messaging! My name is [redacted] and I'll be happy to lend a hand today.
You can take your time and come back to this conversation on your device at anytime. Any future messages will be here waiting for you.
To get started, please let me know your enquiry.
No acknowledgement of the three-day delay. No apology. Treats the interaction as fresh — starting over after 72 hours
You're joking right? 3 days to answer a live chat enquiry?
Our messaging service is a little different to live chat — it's like texting. We might not reply straight away, but we haven't forgotten you!
May I know how can I assist you? 😊
The expectation reset that should have been the FIRST message — disclosed three days too late, after the customer has already been told twice they're "being connected to an agent" and "added to the queue"
If you texted anyone and they didn't reply for 3 days I'd be questioning the relationship...
What went wrong
- The interface implied live, the operating model was async. Language like "put you through to an agent" and "adding you to the queue" sets a sync expectation.
- The expectation-setting disclosure arrived three days too late. "Our messaging service is a little different to live chat" is the correct disclosure — but it's useless after the customer has already waited 72 hours.
- The response, when it came, didn't acknowledge the delay. No apology, no empathy, starting the interaction as if fresh.
- Authentication was duplicated unnecessarily. Already logged in, still asked to re-verify identity with rigid format requirements.
A real-world example
In the interaction above — with a major Australian health insurance provider — the customer was told they were "being connected to an agent." Three days passed before the first reply. The channel behaved like live chat; the operating model behind it was email-grade. Adding to the damage: the customer was required to re-validate themselves (despite already being authenticated via the app), the system wouldn't accept their date of birth in anything but one exact format, and the eventual reply contained no acknowledgement of the delay.
This is not a rare edge case. It's the predictable outcome of deploying an async channel in a sync-looking interface without aligning the operating model, the staffing and the expectation-setting to match.
Why this failure mode hides
Async failures are measured differently. In synchronous channels you see the failure as it happens — service level drops, abandonment spikes, calls pile up in queue. In asynchronous channels the customer just... doesn't come back. They don't complain through the same channel. They try somewhere else, or they churn. The dashboard looks fine; the customer is gone.
This is why the 3% apparent async abandonment rate is misleading. It's not that async customers are more patient. It's that the business never sees the customers who gave up.
Channel Performance — What the Data Says About Async
The 2024 Australian Contact Centre Best Practice Report measured abandonment rate across channels. Asynchronous channels show dramatically lower apparent abandonment than synchronous — a figure that needs careful interpretation.
Abandonment Rate by Channel Type — Australian Contact Centres
Source: 2024 Australian Contact Centre Industry Best Practice Report.
Why this chart misleads most people
The surface reading is that async channels are more than twice as good at retaining customers as sync channels. That's not what the data actually shows. The more accurate read is that async channels don't measure abandonment the same way. Customers don't "abandon" an inbox — they just never reply to your reply. They try somewhere else. They churn. The 3% figure counts the few who explicitly disengage; the silent churn never makes it into the dashboard.
This matters because the 3% number is routinely used to justify pushing customers from sync to async to reduce abandonment. That's not solving the problem — it's hiding it. The customers who would have abandoned a phone queue now quietly drift away from an email thread instead, and nobody registers it as a failure.
For the full framework on reading abandonment data honestly, see the Abandonment Rate glossary term.
Key Components of Async Done Well
Running asynchronous channels well is not "email plus messaging plus chatbots." It requires four components working together — none of which are technology-led.
Explicit Response-Time SLAs
Every async channel needs a documented, visible response-time commitment at the point of entry. "We typically reply within 4 hours during business hours." Customers who know the SLA wait patiently. Customers who don't infer one — usually much faster than the business can meet.
Queue-Based Capacity Planning
Async channels don't use Erlang — they use workload-based capacity modelling. How many tickets arrive per period, what's the target SLA, how many can one agent clear per hour, what concurrency can you sustain? Planning async channels to sync rules (or worse, no rules) is where the SLAs start slipping.
Escalation Path to Sync
Some async interactions reveal themselves as complex, urgent or emotionally charged mid-thread. They need to escalate to voice or live chat — and the infrastructure has to support that without forcing the customer to start over. No escalation path means async channels trap interactions that should have moved on.
Written Communication Craft
Async agents need excellent written communication — tone without vocal cues, clarity without interruption, empathy in text. Generic customer service training doesn't cover this. Async capability is its own discipline.
How to Deploy Async Well
Six practices separate well-run async operations from the ones producing quiet customer churn. None are novel — but most centres miss at least three of them.
Match the interface to the operating model
If your channel looks like live chat, staff it as live chat. If you can't staff it live, redesign the interface so it no longer looks live — remove typing indicators, remove "agent is connecting," add explicit response-time windows at the entry point.
Publish your SLAs — and hit them
Every async channel should state its response time commitment visibly at the point of entry, not buried in a help article. And the commitment has to be one the operating model can actually meet — underpromising is better than overpromising.
Measure with async KPIs, not sync ones
First-response time, case cycle time, resolution rate and SLA adherence are the metrics that tell you whether async is working. Service level and abandonment rate are sync metrics — applying them to async either flatters the channel or punishes it unfairly.
Don't blend sync and async agents without specialisation
A universal agent pool handling both looks efficient on paper. In practice, live demand always wins, async SLAs quietly miss, and both channels produce mediocre outcomes. Specialise the skilling even if the subject matter overlaps.
Build an escalation path to sync
When an async interaction is clearly heading for complexity — customer frustration, high claim value, emotional content — agents need to be able to offer an immediate move to voice or live chat. Without this, async traps interactions that should have gone sync.
Train for written communication specifically
Writing customer-facing messages is a craft. Tone, warmth, clarity, structure, appropriate empathy — all different from voice-mode handling. Invest in async-specific agent training, not generic "customer service skills."
Benefits of Well-Run Asynchronous Channels
24/7 Service Without 24/7 Staffing
Customers can contact you at 2am and know a reply is coming within the stated SLA. Async extends the service window without the cost of overnight live capacity — provided expectations are set right.
Higher Concurrency
Async agents handle dozens of interactions per shift, not one. The per-interaction cost is materially lower — making async the right channel for high-volume, lower-complexity workloads.
Considered Responses
Agents have time to research complex issues, consult colleagues, and draft accurate replies. For documentation-heavy interactions, async produces better outcomes than rushed sync handling.
Natural Written Record
Every interaction leaves an audit trail — useful for complex cases, complaints, regulated industries, and any transaction where "what was agreed" matters. Easy to attach documents, reference previous exchanges, or forward for specialist input.
Lower Customer Effort for the Right Interactions
Customers who don't need or want a live conversation can deal with you on their own schedule — during a meeting break, on the commute, at midnight. For the right interaction types, async is less friction, not more.
Geographic Flexibility
Async channels handle time zone differences naturally. For centres with international customers or distributed teams, async removes the "we're not open yet" problem entirely.
Common Pitfalls in Asynchronous Operations
Sync-looking interfaces on async operating models
The single most damaging pattern in modern customer service. Typing indicators, "agent is connecting" messages, and live-chat visual language create expectations the async backend can't meet. If you can't staff it live, don't make it look live.
Treating low async abandonment as success
The 3% async abandonment figure is largely a measurement artefact — customers don't abandon an inbox, they just drift away. Celebrating the low number while your async-channel complaint volume rises means you're measuring the wrong thing.
No published SLA at the entry point
Customers will infer an expected response time from the interface if you don't state one. That inference is almost always faster than what you intend. The gap between inferred and actual is the source of most async-channel complaints.
Using async as cost-cutting cover for sync failure
Pushing customers from voice to messaging is often framed as "customer-led channel preference." In practice it's frequently capacity-led — the centre can't meet voice demand, so it defers the interaction to a channel where the failure is less visible. Customers notice.
Blended agents without async-specific training
Written communication is a craft. Tone, warmth, clarity and structure in text are genuinely different skills from voice handling. Cross-skilling without specialised async training produces generic replies that feel templated — and customers can tell.
No escalation path when async gets complex
Async is the wrong mode for urgent, emotionally charged, or complex interactions. Without a way to pivot to sync mid-thread, those interactions get stuck — resolution takes days instead of hours, and customer frustration compounds.
Measuring async with sync KPIs
Service level and abandonment don't translate to async. First-response time, case cycle time and resolution rate do. Using the wrong metric set either flatters the channel (hiding the real problem) or punishes it unfairly (destroying the model that works).
Frequently Asked Questions
What's the simplest way to remember asynchronous versus synchronous?
Asynchronous = "not at the same time." The customer sends, the agent replies later — email, messaging, social, tickets. Synchronous = "at the same time." Both parties present and engaged live — phone, live chat, video. The difference is the expected response time, not the channel itself.
How do I actually plan staffing for an async channel?
Async staffing is a workload problem, not a queue problem. You need four numbers: expected interactions per period, average handling time, target response-time SLA, and realistic shrinkage. Multiply volume × AHT to get total workload hours, then work out how many FTE you need to clear that workload within your SLA — accounting for shrinkage and sustainable occupancy. For chat specifically, add a concurrency multiplier.
Is live chat asynchronous or synchronous?
Technically synchronous — but in practice many modern chat widgets are async dressed up as sync. If the message sits in a ticket queue with a one-hour SLA, it's async regardless of the interface. The test is whether a human is actively waiting to respond, or whether it joins a queue for later. If it's the latter, it's asynchronous — and it should look like it.
Why is my asynchronous channel's abandonment rate so low if complaints are high?
Because async channels don't measure abandonment the same way as sync. Customers who give up on an email or message don't "abandon" — they just stop replying. The business never registers it as a failure. That's why rising complaint volume alongside falling abandonment is a classic async warning sign — you're losing customers the dashboard can't see.
Should I move customers from voice to messaging to reduce costs?
Only if you can genuinely match customer expectation to the operating model. A customer who wanted a two-minute phone call and instead gets a three-day messaging resolution is a lost customer, not a cheaper one. The channel shift only works when the interaction type genuinely fits asynchronous handling — and when the interface makes the async nature clear.
What's the biggest operational risk with messaging platforms?
Customer expectation drift. Because modern messaging platforms look and feel live, customers assume live-speed response even when the business is staffing it as a ticket queue. The gap between expectation and reality is where complaints originate — and it gets worse every time a customer has a good experience with a truly live competitor.
How do I know if my async channel is set up properly?
Three tests. First, the entry point explicitly tells the customer the expected response time. Second, the channel is staffed against an SLA-based queue model, not live-capacity scheduling. Third, the reported metrics are async metrics (first-response time, case cycle time, resolution rate) — not sync metrics (service level, abandonment, speed of answer). Miss any of the three and the channel is misconfigured.
Can AI and chatbots replace asynchronous human agents?
For narrow, well-defined tasks — yes, and the economics are compelling. For complex, emotionally charged, or novel interactions — no, and deploying AI there damages the brand. The question is whether the interaction rewards a live human response. Where the answer is yes, automation-first is the wrong choice.
What training do asynchronous agents need?
Written communication craft specifically — tone and warmth in text, clarity without the ability to interrupt, structured response patterns, and appropriate empathy without vocal cues. Also context-gathering (since the customer isn't there to clarify immediately) and accurate case triage. Very different skills from voice handling, even when the subject matter is identical.
Where to Next
- About the Author
- Latest Articles
ACXPA is an independent, practitioner-led organisation helping raise the standard of customer service and experience worldwide.
Founded in Australia. Built by practitioners. Focused on what works in the real world.
