Atender — Every channel, one conversation.

The core idea

What the channels are

Six inbound consumer channels, plus an API channel for custom integrations. Each one is independently configured, individually toggleable, and surfaces conversations into the same unified inbox. A team that only does email and voice never sees web chat anywhere.

1The channels — the routes customers take to reach you

☷

Web Chat

A configurable widget you embed on your site

✉

Your domain, full DNS, Mailgun delivery

☼

API Channel

A REST endpoint that lets you push and pull messages programmatically. For custom integrations, proprietary platforms, or any messaging surface that doesn’t fit a standard channel. Same conversation shape, same Agent Stack hooks, same Sidekick — but the route is whatever your system uses.

Whichever channel a conversation comes in on, it lands in the same shape ↓

2Same shape, every channel — what stays identical once the conversation is open

Same reply editor

Rich text, snippets, formatting, attachments. The agent writes the same way whether the customer is on email, web chat, or SMS — the rendering is adapted to the destination automatically.

Same actions

Assign, tag, snooze, close, escalate. There is no “email-only action” or “chat-only action.” If it’s on one conversation, it’s on all of them.

Same lifecycle

Active, snoozed, done, archived — the same statuses run across every channel. The engagement state (pending vs. engaged) is computed identically too.

Same Sidekick

AI suggestions, knowledge base matches, handbook procedures — all surfaced the same way regardless of which channel the customer chose. A web chat agent and a phone agent see the same Sidekick panel.

Conversations move

Channel switching

A conversation isn’t locked to the channel it started on. The customer can choose to continue elsewhere, the widget can switch them automatically when they go idle, and the IVR can route a phone caller to a text. Through every switch, the conversation ID stays the same.

1How a switch is triggered — three different mechanisms, same effect

Manual customer’s choice

The customer asks to continue elsewhere

From the web chat widget, the customer can choose to keep the conversation going on email, SMS, WhatsApp, or Messenger. They tap the option, the conversation lands at their new address, and the next reply — from the agent or the Agent Stack — goes out through the new channel.

Automatic idle / dead connection

The widget switches them when they go quiet

If the customer goes idle — switched tabs, walked away, lost connection — the widget can move the conversation to a fallback channel before the thread is lost. The idle timeout (minimum 300 seconds), the target channel, and the message they receive are all configurable. Dead-connection detection catches the cases where the browser closes outright.

In-call IVR-driven

Voice can route mid-call

Inside the IVR flow builder, the Route to Channel node redirects a caller to another channel, and the Send SMS node texts them during or after the call. Together they let an IVR offer “press 2 and we’ll text you a link” without breaking the conversation.

A switch from web chat can land on any of these ↓

2Switch destinations — where a web-chat conversation can land

Four destination channels are wired

Email SMS WhatsApp Messenger

3What carries through the switch — and what changes

Carries: the conversation

The same conversation ID. The full message history. All tags, custom fields, and CRM context. The assigned agent (human or stack). The lifecycle status. The customer arrives at the new channel mid-thread, not on a brand-new ticket.

Changes: the route

The channel field. The icon next to the customer’s name in the inbox. Which delivery system handles the next outbound message. That’s it — everything else is the same record.

The most common reason customer service feels broken is repetition. Closing your browser and losing the thread. Switching from chat to email and starting the explanation over. Channel switching exists so that never happens — the agent picks up the same conversation, the customer just sees it land on a new device.

AI in front of every channel

Agent Stacks across channels

Every shipped channel can have an Agent Stack in front of it. The configuration is per channel, not global — because the right answer is rarely “all AI” or “all human.” Most teams pick AI for channels where customers expect immediacy, and humans for channels where the conversation is heavier.

1Per-channel binding — how a channel routes to AI vs. a human queue

Web Chat

Widget-level Agent Stack

The widget configuration carries the Agent Stack ID. Set it — new chat conversations route to the AI. Leave it empty — conversations go to a human team’s queue.

Per-channel routing

Messenger and Instagram each route independently from the same Facebook Business connection. You can put an Agent Stack on Messenger and route Instagram to humans, or vice versa.

Email channel-level binding

Each configured email channel has its own Agent Stack assignment. Useful when one address is heavy support and another is lighter, or when different brands need different behaviour.

SMS

Number-level binding

Each provisioned number can point at an Agent Stack independently. Useful when one number is order-status SMS and another is a marketing reply line.

Voice

Through the IVR’s Send to AI Agent node

Voice doesn’t bind an Agent Stack at the number; it binds it inside the IVR flow. The Send to AI Agent node drops a caller into an Agent Stack at any point in a flow, after any number of branches, IVR collections, or hours-of-operation checks.

Amazon

Vendor-account binding

Amazon buyer messages route per linked vendor account. The conversation is automatically associated with the relevant order, so the Agent Stack has order context from the first turn.

API

Caller declares the routing

The integrating system specifies the Agent Stack when it pushes a conversation in. Same plumbing as the other channels — just with the routing decision made by your code instead of an Atender setting.

Configurable, optional, mix-and-match. AI on web chat and Meta. Humans on phones. AI on Amazon, humans on email. Any combination is fine and reconfiguring is a single setting per channel — no rebuild, no reroute, no migration.

Once a stack is in place, the same handover model runs everywhere ↓

2Same escalation model, same handover — configured on the stack, not on the channel

The AI hands off the same way

When the Agent Stack decides it needs a human — low confidence, an off-policy intent, an account tier that demands a human — the conversation moves to a human queue. The handover rules live on the stack, so the same rules apply whether the channel is web chat, Meta, SMS, or voice.

The human picks up the same conversation

Not a new ticket. Not a forwarded summary. The same conversation, with the full transcript visible, the AI’s notes attached, and any tools the AI invoked already on the record. The customer experiences a single continuous thread.

And if the customer switches channels mid-conversation? The Agent Stack assigned to the new channel takes over. Same stack on both channels — nothing visibly changes. Different stacks — the new one inherits the conversation history. New channel routes to humans — the AI hands off mid-thread using the same handover mechanism. There’s no special path for “channel switched”; it’s the standard handover, applied at the moment the channel changes.