Mass Reply Channel Behaviour
A mass reply sends the message out of Atender on two channels only: email and SMS. On web chat it writes the reply in-app, on the conversation. Every other channel — WhatsApp, Meta, voice, phone and the rest — is refused: the conversation gets no message and is counted as failed. Conversations currently handled by AI are refused too, along with the other cases listed below.
This is the single most common surprise with mass reply: the result notice reads Sent to N conversations, M failed, where N counts only the email, SMS and web chat conversations that got the message and M counts every conversation the batch refused.
Delivery per channel
- Email — Sent out as an email to the contact’s primary email address, with the conversation’s reply subject. A conversation whose contact has no email address is refused: “This contact has no email address, so nothing could be sent.”
- SMS — Sent as a new SMS to the conversation’s phone number, provided SMS is enabled and configured. The From number is the number the customer last texted, otherwise the workspace’s first available SMS number. If the conversation has no phone number, SMS is not configured, or there is no number to send from, the conversation is refused: “No number to send this text from. Check the SMS settings of the workspace.”
- 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 — Refused. No message is written to the conversation, nothing enters the WhatsApp thread, and the conversation counts as failed.
- Meta (Facebook / Instagram) — Refused. No message is written to the conversation, nothing enters the Messenger or Instagram thread, and the conversation counts as failed.
- Voice — Refused. No message row is created and nothing is delivered; the conversation counts as failed. Phone conversations are refused the same way.
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
The batch writes nothing to a conversation, sends nothing, and counts it in the failed total when:
- The AI is currently handling it. The error reads “Conversation is being handled by AI — take it over before replying”. Take the conversation over first, then reply.
- Its channel is not email, SMS or web chat. The error reads “A bulk reply cannot be delivered on the … channel. Reply to this conversation on its own.”
- It is an email conversation whose contact has no email address, or an SMS conversation with no number to send from (see the table above).
- The automatic translation fails. For a customer language other than English, the error reads “The automatic translation to … failed, so nothing was sent.”
The rest of the batch still goes out. The result notice shows only the failed count, so a refused conversation appears there rather than disappearing silently; the API result lists each refused conversation with its reason.
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. The status change applies only to conversations that got the message — a refused conversation, voice included, keeps its status. Marking Done also skips any conversation with an empty Required field: the reply still goes, the conversation stays open, and the notice reads Mass reply sent, N left open. The result notice reports how many were updated (
Status updated for N); a conversation whose status did not change is not counted as failed. - 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 result notice first: every WhatsApp, Meta and voice conversation, like any other refused conversation, got no message at all and is in the failed count (see Mass reply troubleshooting).