Zendesk Messaging
Messaging is not chat with a new name. The difference is whether the conversation survives the customer closing the tab.
What Zendesk messaging actually is
Zendesk messaging is a persistent, asynchronous conversation channel. The thread belongs to the customer rather than to the session: they can write, walk away, come back tomorrow on their phone, and the whole history is still there.
Live chat is the opposite. It is synchronous and session-bound. The customer is on your site now, waiting for a human, and if the tab closes the conversation is effectively over.
That one difference cascades into everything else. Staffing, expectations, bot design, reporting and the shape of your queue all change depending on which model you pick.
Where it runs
All of them land in the same agent workspace as email and voice, which is the operational argument for using the native channel rather than a separate messaging tool bolted on.
The staffing implications
Messaging is far more forgiving than live chat, and that is the main reason to prefer it. Nobody is staring at a spinner. A twenty minute reply on a messaging thread is normal; on live chat it's an abandoned conversation and a bad review.
But forgiving isn't free, and messaging brings its own problems.
Conversations never really end. A chat session closes. A messaging thread stays open until somebody decides it's done, and a customer can revive a two-week-old thread with a single "hi, one more thing". You need a rule for when a conversation is closed and a way to handle the resurrection, or your open count climbs forever.
Concurrency is squishier. A live chat agent handles two or three at once and knows it. A messaging agent might have thirty threads in some state of waiting, most of which need nothing right now, and a handful that need a reply in the next ten minutes. Capacity planning gets harder, not easier.
Handoff has to be clean. Because threads span days, they span shifts. The customer coming back on Wednesday is not talking to the person from Monday, and if the internal notes are thin they will have to explain everything again. That is the number one complaint about async support and it is entirely self-inflicted.
When live chat is still right
Two cases, and they are narrower than people expect.
High-intent sales moments. Someone with a card in hand asking whether the enterprise plan includes SSO wants an answer in thirty seconds, not in an hour. Every hour of delay is measurable revenue.
And situations where you genuinely have staffed live coverage during defined hours, and you turn the thing off outside them. A chat widget with nobody behind it does more damage than no widget at all, because the customer has now been ignored in real time.
For everything else, messaging is the better default. It matches how people already talk to each other, and it lets a small team look responsive without anyone chained to a screen.
Bots, briefly
Messaging suits automation better than live chat does, because a bot answering in an async thread feels normal and a bot stalling a live chat feels like being fobbed off.
Two rules that hold up. First, the bot should collect information rather than pretend to resolve: what product, what version, what order number, so the agent starts with context. Second, escalation to a human must be one obvious step away at all times. A bot with no visible exit is the fastest way to turn one conversation into a complaint on another channel.
The migration nobody plans for
Switching from Chat to messaging isn't a toggle. Trigger logic differs, reporting differs, the widget behaves differently, and any workflow built around chat sessions needs rethinking around persistent conversations.
Run both briefly if you can, and read your own transcripts for a week afterwards. The thing you'll find is customers reopening old threads for entirely new problems, which is a reporting headache and an argument for a clear closing message on every resolved conversation.
Frequently asked questions
Is Zendesk async messaging the same as the web widget?
The Zendesk web widget messaging mode is where async messaging shows up on your site. Underneath, Zendesk Sunshine Conversations carries the conversation across channels, which is what lets it persist rather than ending when the tab closes.
What is the difference between Zendesk messaging and Zendesk Chat?
Messaging is asynchronous and persistent across sessions and devices. Chat is synchronous and session-based, so the conversation ends when the session does.
Which should we use?
Messaging for most teams, because it is far easier to staff. Live chat where you have genuine live coverage and high-intent conversations to catch.
Does messaging create tickets?
Yes, conversations appear in the agent workspace alongside email and voice, which is the point of using the native channel.
How do we stop messaging threads staying open forever?
Agree a rule for when a conversation is finished, close it explicitly with a clear final message, and handle reopened threads as new requests.
One problem, two channels
Customers who wait on a message and then email produce two tickets that read nothing alike. Ticket Merger matches across channels and merges them.
Start free trial14-day free trial. No credit card required.