Live Chat in Your Shared Inbox: Why the Chat Should Not Be a Second Tool

Most small teams add live chat the same way: they sign up for a chat tool, paste its widget on the website, and install one more app on everyone's phone. A month later, support lives in two places. Email in the shared inbox, chat in the chat tool, and a customer who wrote in both gets two half-answers.

There is a simpler model. The chat on your website is just another way for a customer to start a thread in the inbox you already use. This guide explains how that works, when it is the right choice, and how to set it up.

The problem with chat as a separate tool

A separate chat tool is built around the chat. That makes sense for large teams with dedicated chat agents, but it creates friction for everyone else:

Two places to watch. Someone has to keep the chat dashboard open, and someone else watches email. On a small team, that is the same person switching tabs all day.
Split history. A customer who chatted on Monday and emailed on Tuesday appears as two strangers. Context lives in whichever tool you happened to open.
Rules written twice. Your routing rules, assignments and tags exist in the inbox. The chat tool needs its own copy, which drifts.
Missed messages. When nobody is online, the visitor leaves. If the chat tool emails a transcript at all, the reply lands in a personal mailbox rather than the team's.
Per-seat pricing, again. Most chat tools charge per agent. You pay for the same people twice.

How a chat in the shared inbox works

With a chat connected to the shared inbox, the flow is short:

The visitor writes on your site. A small widget asks for their email and the first message.
The message becomes a thread. It goes through the same pipeline as an incoming email: routing rules, groups, AI triage and contacts all apply. Your team sees a new thread, marked as a live chat.
You reply from the inbox. The answer appears in the visitor's chat window within a second. While you type, they see that you are typing. While they type, you see it too, along with the page they are on.
If they leave, email takes over. A reply to a visitor who has left the page is also sent to their email. When they answer that email, it lands in the same thread and shows up in the chat if they come back.

Nothing about the conversation is special. You can assign it, add internal notes, move it to another group, and resolve it. Resolving the thread closes the chat in the widget; if the visitor writes again, it reopens.

Answering from Discord

Many small teams already live in Discord. If your inbox posts new threads to a Discord channel, a live chat can work the same way: each conversation gets a ticket card and a thread, every visitor message is posted in that thread, and a teammate replies by simply typing in it. The visitor sees the reply in the chat on your website.

Two details make this safe for a real support channel:

Only linked, authorized teammates can answer. A Discord account has to be linked to a Smailor account that has access to the ticket's group. Anyone else's message is refused, with a short explanation.
Internal talk stays internal. A message starting with // is saved as a note on the thread and never reaches the visitor. Visitor messages are posted with mentions disabled, so nobody can ping your server from your website.

When this model fits, and when it does not

A chat in the shared inbox is a good fit when:

the same few people handle email and chat;
most chats are real questions that deserve a human answer;
you want one history per customer, and one set of rules;
you are not always online, and want chats to turn into email rather than disappear.

It is not the right tool when you need chatbots that answer on their own, proactive messages that pop up for every visitor, or a help-article widget that searches a knowledge base. Dedicated chat platforms do those things well. Smailor's chat does not try to: it is a direct line from your website to your team.

Setting it up in Smailor

The live chat is included on every paid Smailor plan, with no per-seat or per-conversation fee.

Open Settings > Widgets > Live chat and create a chat. Pick the address the conversations land in.
Set the title, greeting, colors and away message. A live preview shows the result before you save.
Paste the line it gives you before the closing </body> tag of your site:

That is the whole installation. The key in that tag is publishable: it can only deliver messages into the one address you chose, and you can restrict it to your own domains.

Making it yours

The settings in Smailor are defaults. Each page can override the look and every built-in text, which is how one widget can speak French on your French pages:

If your site has signed-in users, you can pass their identity so they are not asked for an email, and sign it on your server so nobody can chat in someone else's name. You can also pass context such as their plan or user id, which your team sees next to the conversation.

Building your own interface

Under the widget sits a public HTTP API with live updates over Server-Sent Events. If the ready-made widget does not fit your product, you can build your own chat in React, Vue or a mobile app, on the same inbox. The widgets guide documents every endpoint, and the AI-ready reference is written so a coding assistant can generate the integration for you.

The short version

If your team answers email in a shared inbox, your website chat should land there too. One place to look, one history per customer, one set of rules, and no chat that dies when nobody is online. See how Smailor's live chat works.