One Chatbot, Every Channel: Web, WhatsApp, Slack, and Microsoft Teams
Updated 1 September 2026
An omnichannel chatbot is one assistant that appears on your website, in WhatsApp, in Slack and in Microsoft Teams, sharing a single retrieval layer and a single set of grounding rules, while behaving differently on each surface. What most organisations actually deploy is four separate bots with four content sets that drift apart within a year and give three different answers to the same question about refunds.
One brain, several faces
The separation that makes this work: content, retrieval, permissions and grounding rules are shared; tone, message length, formatting, available actions and escalation path are per channel.
| Channel | Audience | Behaviour | Escalates to |
|---|---|---|---|
| Website | Prospects and customers | Longer answers, links out, can qualify | Sales or support chat |
| Customers, field staff | Short, no markdown, template rules apply | Support queue or callback | |
| Slack or Teams | Employees | Threaded, sees internal content, terse | Named channel or ticket |
| Helpdesk portal | Employees raising a request | Answers inside the ticket form | Creates the ticket with context |
Note the permission difference across rows. The Slack assistant may retrieve internal documents; the WhatsApp assistant serving customers must not. That is not four indexes – it is one index with identity-aware retrieval scopes, which is why identity has to be the first integration.
What breaks when you skip this
- Answer drift. A policy changes, one bot’s content is updated, three are not. Nobody notices until a customer quotes the wrong one back at you.
- Four sets of metrics. Nobody can say what the assistant is achieving overall, so nobody can defend the budget.
- Four permission models. Which means, in practice, that at least one of them is wrong.
- Quadrupled maintenance. Every content fix has to be made four times, so eventually it is made once.
Channel-specific constraints worth knowing
WhatsApp has the strictest rules: business-initiated messages outside the customer service window require approved templates, and formatting is limited. Long, link-heavy answers do not work. Design for two or three sentences plus an optional follow-up. See the WhatsApp guide.
Slack and Teams reward threading and brevity, and punish walls of text. They are also where employees already are, which is why internal adoption is far higher there than on any intranet portal.
The helpdesk portal is the highest-intent surface of all, because the user is already typing their problem into a form. An assistant that offers a cited answer before submission deflects more than any chat bubble.
Identity across channels
The hardest part of a genuinely omnichannel deployment is not deployment – it is knowing who you are talking to on each surface, and mapping that back to one identity.
In Slack or Teams the user is authenticated by definition, so retrieval scope follows their directory groups automatically. On the website, an anonymous visitor gets the public scope and a logged-in customer can get an account scope, provided your session identity is passed to the assistant. On WhatsApp the identity is a phone number, which is weak evidence: it identifies a device, not a person, and it should never by itself unlock account-specific data. Anything sensitive on that channel needs a step-up verification, exactly as it would in a phone call.
Design the scopes explicitly – public, authenticated customer, employee, and privileged employee – and map each channel to the scopes it may use. Written down, this takes an afternoon. Left implicit, it becomes the incident.
Measuring across channels
Report per channel and in aggregate, and keep the same definitions in both. The metrics that transfer cleanly are answer rate, citation rate, honest refusal rate, escalation quality and repeat usage. What does not transfer is session length, which means something different in a threaded Slack conversation than in a WhatsApp exchange, and which is not a quality signal in either.
One consolidated content gap list across every channel is the real prize. A question asked twice on the website, once on WhatsApp and eleven times in Teams is one documentation gap, and only a shared retrieval layer will show you that. The instrumentation is covered in monitoring internal AI assistants.
A rollout order
- Pick the channel with the highest concentration of your target users and launch there alone.
- Stabilise: get answer rate, citation rate and refusal behaviour where you want them on that one surface.
- Add the second channel using the same index, changing only tone, length and escalation path.
- Confirm the two channels give identical answers to the same question before adding a third.
- Only then consider transactional actions, one channel at a time.
What changes channel by channel
The retrieval layer stays the same. Everything around it – identity, formatting, message limits and what the user expects – does not.
| Channel | Identity you get | Formatting | The catch |
|---|---|---|---|
| Web widget (logged in) | Session identity, strongest signal | Rich: cards, tables, citations | Only reaches people already in your app |
| Web widget (anonymous) | None | Rich | Cannot answer anything account-specific without a step-up |
| Slack | Workspace user, needs mapping to source systems | Blocks and threads; markdown is limited | Threading discipline, or answers get lost in channels |
| Microsoft Teams | Entra ID, usually the cleanest enterprise mapping | Adaptive cards | App approval and tenant policy add lead time |
| Phone number only | Plain text, template rules outbound | Session windows and approved templates constrain design | |
| Address, spoofable | Long form, no interaction | No clarifying turn, so the first answer has to be complete |
The pattern worth internalising: the weaker the identity a channel provides, the smaller the set of questions it can safely answer. That is a design constraint, not a limitation to engineer around.
Handover, without losing the thread
Two handovers matter and they are different problems. Bot-to-human, where an agent takes over mid-conversation, needs the transcript, the retrieved sources and the user’s verified identity to arrive with the ticket – not a link to a console the agent has to open. Channel-to-channel, where someone starts in WhatsApp and continues in the portal, needs a conversation identifier tied to the person rather than the surface.
Get the second one wrong and users repeat themselves, which is the single most reliable way to lose the adoption you spent a quarter building. The instrumentation that makes both visible is covered in monitoring internal AI assistants.
Frequently asked questions
What is an omnichannel chatbot?
One assistant deployed across several surfaces – website, WhatsApp, Slack, Microsoft Teams, helpdesk portal – sharing a single retrieval layer, content set and grounding rules, while varying tone, length, available actions and escalation path per channel.
Should each channel have its own content?
No. Separate content per channel is the main cause of contradictory answers and quadrupled maintenance. Use one index with identity-aware retrieval scopes, so the internal channels can reach internal content and the customer-facing ones cannot.
Which channel should we launch first?
For internal assistants, wherever employees already work – usually Slack or Microsoft Teams – plus the helpdesk portal, which is the highest-intent surface. For customer-facing assistants, the website, placed near pricing and inside the contact form rather than as a universal corner bubble.
Why does WhatsApp need different handling?
Business-initiated messages outside the customer service window require pre-approved templates, and formatting options are limited. Answers must be short and self-contained rather than long and link-heavy, so the same retrieved content needs a different generation style for that channel.
Do we need a separate bot for each channel?
No, and building one is the mistake this article exists to prevent. One retrieval layer, one content set, one set of guardrails, with a thin presentation adapter per channel. Separate bots drift apart within weeks: a policy gets updated in one place, and the same question starts returning two different answers depending on where it was asked.
How do we keep answers consistent across channels?
Test it directly. Add the same ten questions to your evaluation set for every channel and compare the answers, not just the accuracy scores. Differences should come only from formatting and from what the channel’s identity allows. Any difference in substance means content or configuration has forked somewhere.
Next step
Before you add a second channel, check whether your platform shares one index and one permission model across surfaces. If it does not, you are about to create the drift problem. IntelloWork runs one retrieval layer behind every channel by design.