Support

Omnichannel inbox: a shared mailbox, routing and per-customer history

Bring conversations from several channels (chat, email, SMS/WhatsApp and tickets) together in one shared inbox, with assignment and queue-based routing (sales/support) and an omnichannel timeline per customer.

The Omnichannel inbox is a SHARED inbox that gathers, in one place, the conversations that today arrive through separate channels: the live chat on your website, the emails logged on your contacts, SMS/WhatsApp messages (Twilio) and helpdesk tickets. You keep replying on each channel as always; the Inbox only UNIFIES the view, the triage and the assignment.

Each row in the Inbox is a "thread", a pointer to the original conversation on its channel. The content is not duplicated: when you open a thread, the CRM pulls the history straight from the channel (the chat messages, the contact's emails, the SMS/WhatsApp messages or the ticket).

Queues: sales and support

Every thread belongs to a QUEUE. By default, routing puts email in the Sales queue and chat, SMS, WhatsApp and tickets in the Support queue. Use the filters at the top to see a single queue, a single status (open, pending, closed), a single channel, or only what is assigned to you or unassigned.

Assignment and routing

Open the Inbox from the side menu and select a conversation in the list.
In the right-hand panel, choose the person in the "Assignee" picker to assign the thread to an agent (or leave it "Unassigned" for the queue's pool).
Change the status (Open / Pending / Closed) as you work the conversation.
Click "Auto-route" to have the CRM apply the channel's queue rule and, if there is still no assignee, distribute it by fair round-robin (whoever has the fewest open conversations gets the next one).

💡 Round-robin assignment picks the member with the LOWEST load (fewest open threads), spreading the work predictably. The rule is deterministic: on a tie, the first in the list.

Replying (and attaching files)

The reply goes out through the source channel: on an email or SMS/WhatsApp thread, write in the composer and click Send reply (or Cmd/Ctrl+Enter). The message goes out on the channel and stays logged in the conversation's history. On email, use Attach file to include documents in the reply: they travel with the email (with a sensible per-file limit). Channels that cannot be replied to from the inbox (live chat, ticket, social) show the history for reading and triage, and the Open contact link takes you to the record.

Smart Inbox filters

Beyond queue, status, channel and assignee, you can filter by Reply (Replied = the team answered last; Not replied = the conversation is waiting on you), by Unread (only what has just arrived and has not been opened) and by Archived (shows the conversations you took out of the inbox). In the list, a blue dot and a bold name mark the unread ones.

Priority and tags

Each conversation has a triage Priority (Low, Normal, High, Urgent) that you set at the top of the conversation and use to filter the inbox by what is hottest. On top of that, you can stick free-form Tags on it (#vip, #churn-risk, #duplicate-invoice and so on) to organize and route. Click the × to remove a tag, or type a new one and press Enter. The tag filter shows only the conversations carrying that tag.

Pinning, archiving and marking unread

Pin: keeps the conversation at the top of the inbox (handy for what you are watching closely). Unpin returns it to normal.
Archive: takes the conversation out of your day-to-day inbox. It disappears from the default list and comes back only with the Archived filter; unarchiving brings it back.
Mark unread: returns the conversation to the pending-to-read state, so you can pick it up later. Opening a conversation marks it read automatically.

Internal notes

Inside the conversation there is an Internal notes block that only your team sees (it never reaches the customer). Use it to record context, agree on the next step or hand off to a colleague. Notes stay attached to the conversation and can be removed by their author.

Which campaign the conversation came from

When the contact is in an active cadence or campaign, the conversation shows at the top which campaign it came from, with the enrollment status (Active, Paused, Replied) and a direct link to open the campaign. That way you handle the conversation already knowing the prospecting context.

Omnichannel history per customer

On a Contact (or Lead) record, the "Omnichannel history" section shows the unified timeline of ALL of that customer's interactions across every channel (chat, SMS/WhatsApp, email and tickets), newest to oldest, each item marked with its channel and direction.

Privacy and isolation

The Inbox respects isolation per organization (no conversation from another company ever appears) and your visibility scope: if your role only sees your own team's records, you see the threads assigned to your team and the ones sitting in the pool with no owner, not those of other teams.

How to test it

Generate an interaction on some channel (for example, send an SMS to a contact, or take a conversation on the website chat).
Open the Inbox and the thread appears in the matching queue with the contact's name and the channel.
Assign it to yourself, change the status and click "Auto-route" to watch the distribution happen.
Open the contact and check the "Omnichannel history" section for that same interaction on the timeline.

Turn a conversation into a case

A WhatsApp, SMS, chat or social conversation can now become a support case with one click. The inbox is triage; the case is where the work happens, and only the case has the SLA clock in business minutes, the protocol number, the macros and the metrics. Promoting copies the conversation into the case thread, keeps the contact and the company already linked, and is safe to repeat: the same conversation always lands on the same case, and a second promotion only copies what is new.

Acting on one message

Long-press a message (or right-click it, or use the chevron that appears when you hover) and you get the same menu you already know from your phone: reply quoting it, forward it to another conversation, copy the text, see the delivery details, star it, react to it, or delete it.

Two of these behave differently from what the gesture suggests, and the menu says so on the spot rather than letting you find out afterwards.

**A reaction is internal.** The emoji you put on a message is a mark your team leaves for your team. The customer never sees it. The official WhatsApp API does carry reactions, but we do not send them yet, so the bar carries a permanent badge saying it stays here. The day we can send it, the badge goes away on its own.
**Deleting removes the message from this inbox, not from the customer's phone.** No channel we support lets us take back a message that was already delivered: email and SMS never could, and the official WhatsApp API does not expose it (the gesture exists in the app, not in the API). So the menu offers "delete for me", it says why "delete for everyone" is unavailable, and it does not pretend.

Replying with a quote works where the inbox can actually send: email, SMS and WhatsApp. On a chat, a social message or a ticket the option appears explained instead of hidden, because knowing that you have to answer somewhere else is more useful than a menu that is silently one line shorter.

💡 Forwarding carries the text, not the file. A message with an image or a document is refused, with the reason on screen, instead of landing mysteriously empty in the other conversation.

Routing by skill

A queue can demand knowledge, and not only availability. You keep a catalog of skills (a language, a product, a system), you say who has each one and at what level, and you say what each queue requires as a minimum. From then on, distribution only considers the people who qualify.

**The level goes from 1 to 5**, where 1 means the person knows it and 5 means the person is the reference. Whoever administers assigns the level; it is not self declared, because then level 5 would become the way to catch the good items, or to escape them.
**A queue can require more than one skill**, each one with its own minimum level.
**The skill filters, it does not choose.** Round robin, least load and reassignment keep on choosing, only now among the people who qualify. Two engines deciding the same thing would end up disagreeing in silence.
**With nobody qualified, the item is not assigned.** It stays in the queue, visible as unassigned and with the reason recorded, instead of going to someone who cannot solve it and sitting there with an owner who is stuck.
**The overflow is opt in.** Whoever prefers coverage over precision turns it on in the requirement itself: the item goes to the usual rotation, and the log says it was an overflow.
**A routing rule can require skills too**, under Settings, Routing, on the actions that pick among people (round robin, least load, reassign). Requiring a skill on an action that already points at one person is refused, because it would be ignored. When rule and queue require the same skill, the higher level wins: a rule never loosens what a queue protects. There you also choose what happens when nobody qualifies, which is where the overflow is turned on.

Availability is the same rule as everywhere else: active, in the rotation, and below the cap of open items. Turning a skill off stops requiring it and stops crediting it at the same moment, so turning it off never becomes a silent way of blocking everyone. Each person can read their own skills without administering anything, because not knowing what the system thinks you know is the fastest way to distrust the distribution.

Channels · what each one can do

The inbox, the composer and the first-reply SLA no longer guess what a channel can do: they ask the channel's declared **capability**. Does it reply, and from where (the inbox, the chat desk, the case console, or nowhere)? Does it have a session window? Does it require an approved template outside it? Does it send and receive files, and up to what size? What delivery receipt comes back (sent, delivered, read, or none)? The same channel can answer differently depending on the provider that delivered the message: WhatsApp through the official API receives and sends files and reports read receipts; through a telephony provider inbound files are not read; through the WhatsApp Web companion it only listens.

The composer reads this per conversation and says it **before you type**: how long free text is still allowed, that more than 24 hours have passed since the customer last wrote and only an approved template can go out, that no sender is connected for the channel, or that this channel is answered somewhere else. The reading refreshes every 30 seconds. To send the template, use the WhatsApp **New conversation** composer, which detects the window by phone number and switches to template mode on its own.

Where it lives: **Settings → Integrations**, in the **Digital channels** card. Each channel shows its pace (real time, near real time, asynchronous, case), whether it receives, whether it replies from the inbox, and a row of chips: receives files, sends files, receipt level, templates, session window, typing indicator, open tracking and the default first-reply target.
A chip that does not apply shows struck through instead of disappearing. The absence is information: knowing that SMS carries no files is what stops you from promising a photo.
Each platform has a status: **Connected · sends and receives** (WhatsApp, SMS, email); **Connected · inbound only** (Messenger and Instagram Direct, because replying requires an app review with the platform; the custom bring-your-own channel, because nothing declares how to answer); receives but replying from the inbox is not wired yet (Telegram: the sender exists, the inbox does not call it); and **Not available yet** (Apple Messages for Business, LINE and RCS), always with the reason.
Website chat is live but answered from the chat desk, not the inbox; cases are handled in the case console. The card says so instead of showing a composer that would fail.
The WhatsApp Web companion is listed as its own platform, inbound only. On its own it never makes WhatsApp replyable: a workspace with only the companion connected sees the truth, not a reply button that fails.
An integration that is registered but switched off is not an available channel: its webhook is refused, and the card shows it as not connected.
First-reply SLA by channel: the default target follows the channel's pace (5 minutes for chat, 15 for WhatsApp and SMS, 60 for social, 4 hours for email, 8 hours for cases) and appears on each card; your SLA policies can override it. The by-channel summary (awaiting, at risk, overdue, longest wait) reuses the same query and the same visibility scope as the SLA overview, and today it is exposed through the API rather than a panel of its own.

💡 The window is measured from the last message the **customer** sent, never from your last reply: answering does not reopen it, and it can close while the composer is open, which is why the hint refreshes on its own. And a closed window has two different endings. When the provider accepts templates, the hint says only an approved template can go out; when it does not, it says to wait for the customer to write again, because there is nothing you can send.

💡 A skill that some queue requires cannot be deleted, only deactivated. Deleting it would make the queue accept anyone again, with nobody asking for that and no error showing up.

Open this article inside the system →