Mass Reply Channel Behaviour
A mass reply always creates a message on every selected conversation, but it only sends that message out of Atender on two channels: email and SMS. Every other channel — web chat, WhatsApp, Meta, voice — gets the message stored on the conversation and nothing more. Conversations currently handled by AI are refused outright and reported back as failures.
This is the single most common surprise with mass reply: the batch reports a high Sent to N conversations count even when most of those conversations had no outbound delivery path.
Delivery per channel
- Email — Sent out as an email to the contact’s primary email address, with the conversation’s reply subject. A contact with no email address gets the stored message only.
- SMS — Sent as a new SMS to the conversation’s phone number, provided the workspace has Vonage enabled and configured. The From number is the number the customer last texted, otherwise the workspace’s first Vonage number. If neither exists, the message is stored but not sent.
- Web chat — No outbound send. The message is stored on the conversation, and a widget the visitor still has open picks it up on its next refresh. A visitor who has closed the window sees it only if they return — mass reply does not fall back to email the way a single agent reply does.
- WhatsApp — No outbound send. The message is stored on the conversation only; it does not enter the WhatsApp thread.
- Meta (Facebook / Instagram) — No outbound send. The message is stored on the conversation only; it does not enter the Messenger or Instagram thread.
- Voice — No outbound send. A voice conversation is not excluded from the batch — a message row is still created and counted as sent — but nothing is delivered to the customer.
If you need to reach web chat, WhatsApp, Meta or voice customers, reply on each conversation individually; the single-conversation reply path resolves a real delivery channel and can redirect a stale web chat reply to email.
Conversations the batch refuses
A conversation that the AI is currently handling is not sent to. The batch returns a per-conversation error — “Conversation is being handled by AI — take it over before replying” — and counts it in the failed total, so it appears in the result toast rather than disappearing silently. Take the conversation over first, then reply.
Attachments
Mass reply carries no attachments. The bulk-reply request accepts only the message text, its HTML, and an optional status change — there is no attachment field on the API at all. Send anything that needs a file on the individual conversations.
What else the batch does
- Variables are personalised per recipient.
{{contact.name}}and the agent variables are substituted for each conversation before the message is stored. Snippets work in the editor with!!. - Outbound text is translated. When a conversation has a customer language other than English, the delivered text is machine-translated into it. The mass-reply body is authored in English regardless of your own compose preference.
- The status change is a separate permission. Sending needs reply permission; using After sending: to mark conversations Done, Snoozed or Archived additionally needs the close/reopen permission, or the whole request is refused with 403.
- Snooze needs an uncapped workspace. Mass reply sends no wake time, so a workspace with any snooze cap refuses
Snooze— the option is hidden in the dialog and rejected by the server.
If some recipients report not receiving the message, check the individual conversation first: on web chat, WhatsApp, Meta and voice there was never an outbound send to fail (see Mass reply troubleshooting).