When does Rocket.Chat Omnichannel belong in your customer messaging stack?
Rocket.Chat Omnichannel is the customer-facing part of Rocket.Chat. It routes conversations from a website live chat widget, WhatsApp, SMS through Twilio and Telegram into agent queues that staff work from the same workspace they use internally. It fits teams that already answer customers across several channels and want those conversations processed and stored on servers they run, whether in their own cloud accounts, data centers or air-gapped networks. Consider it if customer messages sit in separate vendor consoles, if data residency or contract terms prevent sending chat transcripts to a hosted third-party service, or if your support and internal collaboration already run on Rocket.Chat.
Omnichannel changes the scope of the deployment. It is not a chat widget you paste onto a web page. Each inbound channel needs its own connection, credentials and webhook path. Agents need roles and departments that decide who sees which queue. Customer data flows through external messaging providers that you must document. For example, an SMS route through Twilio adds a carrier-facing dependency and its own account and phone number management, while a website widget adds an inbound endpoint on your public domain. Settle these decisions before the build starts, because each one affects access control, logging and where personal data is kept.
Version choice matters as much as channel choice. Rocket.Chat standard releases are supported for 6 months and LTS releases for 12 months. After end of life, a version gets no security or bug fixes, and some cloud services, including Omnichannel integrations, stop working. Rocket.Chat 8 also removed features that some Omnichannel setups relied on, so compare your current configuration with the vendor's list of removed features before you choose a target version. Confirm which Omnichannel capabilities your plan includes, because plan tiers differ and air-gapped deployment is a paid-plan capability.
This page answers four questions: which channels justify the first release, how agent routing and departments should be designed, what hosting and data-flow requirements follow from the channels you pick, and what changes when you move to Rocket.Chat 8.x. If you are still deciding whether Omnichannel fits at all, read the sections in order. If the decision is already made, go straight to the channel and routing sections.
Which Omnichannel configuration fits which team
This table compares five Omnichannel configurations, from a website chat widget to a multi-instance design, and shows when each one fits a team. Read the scale column first, because the reference architecture points to one instance with a MongoDB replica set up to 500 concurrent users, and multi-instance designs require a paid plan. Confirm your channel, plan and version needs with Rocket.Chat before you choose.
| Configuration | When it fits | What it changes in the deployment | Scale and plan |
|---|---|---|---|
| Website Livechat only | A support or sales team that talks to visitors on one website | Livechat widget, agent routing and one set of departments, with no external channel accounts to manage | Single instance, within the 500 concurrent user guidance |
| Livechat plus one messaging channel | A team adding WhatsApp, SMS or Telegram to website chat | Adds a channel integration with its own provider account, credentials and message handling to test | Single instance, within the 500 concurrent user guidance; confirm channel requirements with your provider |
| Multiple channels with departments | Several teams sharing customer queues across more than one channel | Requires department setup, routing rules, agent roles and per-channel testing, with more admin work to keep routing current | Single instance while concurrency stays within 500 users; review plan needs |
| Single instance with MongoDB replica set | One support site with concurrent users up to 500 | One Rocket.Chat instance on MongoDB 8.0 or later as a replica set, with three members strongly recommended for high availability | Matches the reference architecture up to 500 concurrent users |
| Multi-instance behind a load balancer | Concurrent users above 500 or an availability target that needs more than one application node | Several instances linked by NATS, a load balancer and shared MongoDB, with more components to upgrade and monitor | Requires a paid plan; agree the design in writing before build |
How agent routing and departments shape the Omnichannel build
Departments, agent roles and routing decisions determine which agent sees which customer conversation, and they set how work waits when agents are busy. In Rocket.Chat Omnichannel, a department groups agents who handle a common kind of request, such as sales, support or billing. Incoming conversations from the website widget, WhatsApp, SMS or Telegram are then assigned to agents according to the routing method, the agents' availability and their department membership. Agent and manager roles decide what each person can see and change. Before you configure anything, confirm which routing methods, queue behaviors and visibility settings your Rocket.Chat version offers, because the menus and options differ between releases.
The first design questions are structural. Decide how many departments you need and what each one owns. Every department adds a separate queue, so a large number of small departments can leave some agents idle while others are overloaded. Too few departments can hide specialist skills behind generalist queues. Map each channel to the departments that will receive it, and decide whether a visitor chooses a department from the widget or whether the routing logic chooses one for them. Write these answers down with named owners, since each one shapes the agent lists and the queues that the rest of the build depends on.
Next, decide how agents are grouped and who is allowed to change routing. Agents can belong to more than one department, which helps with cover but makes it harder to tell who owns a conversation at a given time. Limit who can edit departments, agent membership, business hours and routing behavior. Most teams keep these rights with a small operations group rather than with every administrator. Confirm in your version which built-in roles can manage Omnichannel settings, whether those roles can be narrowed, and whether changes to departments and agent assignments are recorded in a way your audit process can review.
Escalation defines what happens when the normal route cannot serve a customer. Plan for conversations that wait too long, for periods when no agent is online, and for transfers between departments. Decide who receives a conversation that has been waiting, whether a supervisor is notified, and what the visitor sees when the team is closed. Check which transfer and queue-timeout options your version provides and whether they can be configured per department. Also plan for upgrades. Standard Rocket.Chat releases are supported for 6 months and LTS releases for 12 months, and routing behavior can change between versions, so retest escalation paths after each upgrade.
These decisions are much easier to change before agents and customers are live. Once conversations are open, moving them between departments or renaming queues disrupts work in progress and can confuse both agents and visitors. Test the design with a small group of pilot agents and a set of scripted conversations across every channel, including out-of-hours cases. The Rocket.Chat reference architectures suggest one instance with a MongoDB replica set for up to 500 concurrent users, so queue behavior under peak load also depends on the deployment size you choose. Confirm the expected peak volume with the business owners before the routing design is finalized.
How to set up Omnichannel in a test workspace before production
This sequence builds a non-production Omnichannel workspace one layer at a time, from platform prerequisites to tested customer conversations. Each step ends with a check, so the team knows what works before any channel reaches real customers.
Confirm version and database prerequisites
The platform engineer confirms which Rocket.Chat version the test workspace will run and checks that it is within its support window, using the version durability documentation. For 8.x releases, confirm that MongoDB 8.0 or later is running as a replica set and that the container or Helm packaging matches the release notes. Keep the test workspace on the same version line planned for production. Done when the version, MongoDB version and replica set status are recorded and an administrator can sign in.
Enable Omnichannel and Livechat in test
A workspace administrator turns on Omnichannel and Livechat in the test workspace's administration settings and leaves the production workspace unchanged. Confirm the exact setting names and their location in the current Rocket.Chat documentation, because menus change between releases. Open a staging web page with the Livechat widget, send a message as a test visitor, and check that the conversation appears in the agent queue. Done when a logged-in test agent sees the visitor's message.
Configure departments and test agents
The Omnichannel administrator creates the departments that will receive conversations and adds test agents to each one. Assign a backup agent to every department so a single absence does not stop routing. Set agent status and any routing or queue behavior to match the intended operating model, and confirm the setting names in the current documentation. Done when a visitor message sent to each department appears only in that department's queue and only its agents can see it.
Connect the website Livechat channel
The integration owner connects the website Livechat channel first because it needs no external provider account, which keeps problems easy to isolate. Embed the widget on a non-production page that matches the production site's domain settings where possible. Confirm the widget loads, the visitor can start a conversation, and the department routing from the previous step applies. Done when a conversation started on the staging page reaches the correct department and an agent can reply from the Rocket.Chat interface.
Add external channels one at a time
Connect each external channel separately, such as WhatsApp, SMS through Twilio or Telegram, starting with the provider's test or sandbox mode where one exists. For each channel, create the provider account, configure its webhooks and credentials as the Rocket.Chat documentation and provider documentation describe, and map it to a department. Do not start the next channel until the current one passes its checks. Done when a message sent from the provider's test number or account arrives in the correct department and a reply returns to the sender.
Run end-to-end test conversations
The QA lead runs written test scripts that cover each channel and each department, including a first contact, a transfer to another department, file sharing, an agent handover, and closing the conversation. Include scenarios for offline hours and for an agent who goes away mid-conversation, as those often expose routing gaps. Check the transcripts, conversation history and any reporting data that your team relies on. Done when every scripted scenario produces the expected result and any defects are logged with an owner.
Record results and decide on production
The project lead reviews the test log with the platform, security and customer operations owners and decides which defects must be fixed before launch. Retest each fix in the test workspace and repeat the affected scenarios from the previous step. Ask your DeployOpen or internal team to document the final configuration so production is built from the same settings. Done when the approvers have signed off the test results and the production configuration matches the tested one.
Security and data handling for customer conversations
Customer conversations contain personal data that moves through agents, the Rocket.Chat server and, for some channels, third-party carriers. The cards below cover each control point, the check to run before go-live, and the team that owns the decision.
Agent and administrator sign-in
Agents and administrators sign in through the identity source you choose. Rocket.Chat's free Starter plan includes LDAP and Active Directory authentication, single sign-on and multi-factor authentication, so these controls do not depend on a paid tier. Confirm which of them your agents need, how access is removed when someone leaves the support team, and whether administrator accounts use separate credentials. The identity team owns this decision.
Department and conversation access
Routing sends each conversation to a department, but routing alone does not restrict who can read a transcript. Decide which roles can view conversations outside their own department, who may take over an active chat, and who can export visitor history. Document these rules before go-live, then test them with a non-administrator account. The support operations lead owns the access model, and DeployOpen can configure and verify it.
Third-party message carriers
WhatsApp, SMS through Twilio and Telegram messages pass through providers outside your Rocket.Chat server. Each provider receives message content and sender identifiers to deliver messages, so its contract, data processing terms, hosting regions and log retention become part of your data map. Request each provider's current data handling documentation and confirm what it stores after delivery. Procurement and legal own these agreements, and the decision to enable each channel should follow their review.
Retention for visitor and agent data
Retention settings decide how long messages, files and visitor records stay in the workspace. Retention is included in Rocket.Chat's Starter plan, but the period must match your records schedule. Set retention for conversations separately from files, and check whether deleting a conversation in Rocket.Chat also removes copies held by carrier providers. The records manager or data protection officer sets the period, and the platform team applies and tests it.
Audit trail of conversations
Rocket.Chat's paid plans list tamper-evident audit trails of messages, files and sessions. Confirm with Rocket.Chat whether this covers Omnichannel conversations on your specific plan, and whether it records agent transfers, closed chats and visitor sessions. If it does not, plan a separate export process before go-live. The compliance lead owns the audit requirement and should define the evidence an assessor will request before the plan is chosen.
Encryption for channel conversations
End-to-end encryption is a separate feature from Omnichannel routing, and conversations from WhatsApp, SMS or Telegram reach Rocket.Chat after a provider has relayed them. Confirm whether end-to-end encryption can apply to these conversations at all, and which parties can read message content at each hop. Record the answer in your data flow diagram before you publish a channel. The security architect owns this decision and should review it with the end-to-end encryption design.
What Rocket.Chat 8 changes for Omnichannel deployments
Rocket.Chat 8.x requires MongoDB 8.0 or later running as a replica set, so a standalone MongoDB instance is not a supported foundation for this version. Rocket.Chat strongly recommends a three-member replica set for high availability. For Omnichannel, this matters because a customer conversation that is interrupted by a database failover is a visible service incident, not just an internal one. Before you commit to a version, confirm the current requirement on the Rocket.Chat system requirements page, check the MongoDB version you run today, and ask your team who owns replica set operations, backups and failover testing after go-live.
Rocket.Chat 8 removed some features from earlier versions. Before you choose 8.x, compare the removal list against every Omnichannel capability you plan to use: the website Livechat widget, WhatsApp, SMS through Twilio, Telegram, agent routing and departments. Map each planned channel and routing rule to a specific feature and mark any that depends on something removed. If a removal affects a channel you need, you have three options: keep the current line for now, change the channel design, or accept a replacement workflow and test it. Make that decision with the removal list in hand, not after the upgrade is scheduled.
Rocket.Chat supports standard releases for 6 months and LTS releases for 12 months. A version past its end of life receives no security or bug fixes, and cloud services such as the push notification gateway, Marketplace and Omnichannel integrations stop working. For a customer channel, that failure is quiet: the widget may still load while messages from WhatsApp, SMS or Telegram no longer arrive. Record the end-of-life date for the line you deploy, and plan each upgrade window before that date. Ask the Rocket.Chat team to confirm the current support dates for the line you choose, because release schedules change.
Build a pre-upgrade checklist for the Omnichannel scope before you choose a version. Confirm the MongoDB version and replica set health, cross-check the removal list against your channel and routing design, and stand up a test instance with every Omnichannel integration connected. Verify that each channel sends and receives messages, that routing still reaches the right departments, and that agents can use the clients they rely on. Also confirm your plan covers the architecture you need: the Rocket.Chat reference architectures state that multi-instance and microservice designs require a paid plan. Once these checks are complete, the upgrade decision becomes a scheduled task rather than an emergency.
What to confirm before you commit to Omnichannel
Five questions decide whether Rocket.Chat Omnichannel fits your customer messaging. Answer them with Rocket.Chat in writing or test them in your own environment, because each one changes the plan, the architecture or the upgrade path.
Omnichannel features by plan
Confirm which Omnichannel features and channel integrations each plan includes before you design around them. Rocket.Chat's free Starter plan allows up to 50 users and includes LDAP and Active Directory authentication, single sign-on, multi-factor authentication, end-to-end encryption, retention and read receipts. Check the plans documentation for whether Livechat on your website, WhatsApp, SMS and Telegram routing are available at your tier, and ask for the feature list in writing with the quote.
Features removed in Rocket.Chat 8
List every Omnichannel capability your agents use today and check each one against the Rocket.Chat 8 release notes before you plan the upgrade. Removed features can break department routing, agent workflows or reporting that staff rely on daily, so each one needs a replacement, a workaround or a documented decision to drop it. Rocket.Chat 8.9.0 was published on October 5, 2026, so confirm the removal list for the exact version you intend to deploy.
Channel provider terms and accounts
WhatsApp, SMS through Twilio and Telegram each bring their own terms, account types and approval steps, and those decide whether your use case is allowed at all. Check which business or developer account type each provider requires, who in your organization can accept its terms, and whether your message volumes, sender registrations and opt-in records match your customer flows. These obligations sit with your organization and the provider, so involve legal and account owners early.
Concurrency against a single instance
Rocket.Chat's reference architectures suggest one instance backed by a MongoDB replica set for up to 500 concurrent users. Compare your expected peak of concurrent customer and agent sessions with that figure, and ask Rocket.Chat how it counts concurrency for your traffic pattern. Above that level, multiple load-balanced instances linked by NATS are the documented pattern, and those designs require a paid plan, so confirm the plan and infrastructure cost before you size the deployment.
Plan fit for team size and network
Starter allows up to 50 users, so a support team of that size or larger points to a paid plan. Air-gapped deployment is not available on Starter and is a paid-plan capability, so if your customer messaging must run in an isolated network, confirm the tier before design begins. Paid plans are priced by quote, so request a written quote tied to your user count, deployment model and required Omnichannel features.
What does Omnichannel cost and how long does setup take?
How much does Rocket.Chat Omnichannel cost to run?
Rocket.Chat's paid plans (Commercial, Government and Defense) are priced by quote, so there is no list price to start from. Cost has several separate parts. The Rocket.Chat license is one. Channel provider accounts and their fees, such as WhatsApp, SMS through Twilio and Telegram, are billed by those providers and sit outside the Rocket.Chat license. Hosting in your cloud account, data center or air-gapped network is another recurring cost. DeployOpen's implementation work is fixed-scope and quoted from a written scope, and ongoing support or upgrades can be added as a retainer. Ask every vendor for a written quote that lists each line, who bills it, and whether it recurs.
How long does setup take before a pilot works?
No duration applies to every project, because time to a working pilot depends on the scope you agree. The main drivers are how many channels you connect, how complex your routing is, and whether you are installing fresh or upgrading an existing Rocket.Chat deployment. A website Livechat widget with one department is a much smaller job than WhatsApp, SMS and Telegram routed to several departments with fallback rules. Provider account approval runs on the provider's schedule, so start it early and treat it as a dependency. Ask for a timeline in the written quote tied to milestones, and ask which provider approvals are assumed to be complete before the clock starts.
What does our team need to provide for an Omnichannel project?
Four groups of people usually decide how smoothly a pilot runs. Name one person for each role before work starts.
- Platform owners grant access to servers, the MongoDB database, DNS, and the Rocket.Chat administration console.
- Channel account holders sign in to the WhatsApp, Twilio and Telegram accounts, complete provider verification, and approve business details.
- Agents and supervisors test departments, routing, transfers, canned responses and after-hours handling.
- A test plan owner writes the acceptance scenarios, such as message history after a handoff, and signs off on them.
If any of these roles is unfilled, the work waits, and the delay usually shows up in the timeline rather than in the invoice.
Can our own team set up Rocket.Chat Omnichannel without a partner?
Yes, if your team has the skills in-house. Rocket.Chat is open source, so the software itself is available to you. The work is larger than installing the application. It includes hosting Rocket.Chat with MongoDB as a replica set (Rocket.Chat 8.x requires MongoDB 8.0 or later), configuring each channel and its webhooks, designing departments and routing, integrating identity, setting up backups, and planning upgrades. Upgrade status matters: unsupported versions stop receiving security fixes, and cloud services such as Omnichannel integrations stop working. In-house teams usually need one person who owns the upgrade calendar and one who owns the provider accounts. A partner is most useful when the channel count is high or the schedule is fixed.
What makes Omnichannel setup cost more or take longer?
Four factors move both cost and duration the most.
- Channel count: each channel adds provider setup, webhook configuration, and testing.
- Routing complexity: departments, skills-based routing, transfers and fallback rules each need design and test cases.
- Upgrade status: an installation on an older line may need an upgrade before new work, and the upgrade path has its own prerequisites.
- Scale and data: Rocket.Chat's reference architectures suggest a single instance with a MongoDB replica set up to 500 concurrent users, with multi-instance and microservice designs above that, and those designs require a paid plan. Importing history from another tool, such as a Slack export or a Mattermost conversion, also adds work.
Compliance requirements, such as audit trails or retention, add review time as well.
What should a written quote for Omnichannel include?
A useful quote states what is included and what is not. Ask for the following:
- Scope: the exact channels, departments, routing rules and integrations covered.
- Deliverables: what you receive at each milestone, such as documentation, configuration and test results.
- Assumptions: who creates and pays for each provider account, and which approvals are expected before work begins.
- Environment: where Rocket.Chat is hosted and who maintains it.
- Acceptance: the test plan and the sign-off process.
- Exclusions and change control: what happens when requirements change.
- Ongoing support: whether upgrades and support are included, and how a retainer is priced.
Request the Rocket.Chat license as a separate line from the services fee.
Which Rocket.Chat plan covers Omnichannel in our deployment?
Confirm the plan with Rocket.Chat before you commit, because plan entitlements change and Omnichannel is a feature you should verify directly. As a starting point, the free Starter plan allows up to 50 users and includes single sign-on, multi-factor authentication and LDAP or Active Directory authentication. The free Community workspace allows up to 100 concurrent users with core messaging. Paid plans are priced by quote, air-gapped deployment is available only on paid plans, and multi-instance and microservice designs require a paid plan. Ask Rocket.Chat to confirm in writing which plan includes the Omnichannel features and integrations you need, and whether those features are available in your hosting model.
How DeployOpen scopes and delivers Omnichannel work
DeployOpen plans, implements, customizes, integrates, hardens and supports Rocket.Chat Omnichannel inside your own cloud accounts, data centers or air-gapped networks. Each engagement starts with a written scope that names the channels, departments, routing rules and integrations in use. Most engagements are fixed-scope, and ongoing support is available as a retainer once the deployment is live.
How we scope
- The written scope lists each channel, such as website Livechat, WhatsApp, SMS through Twilio or Telegram.
- Agent routing, departments and queue rules are documented with the people who will own them after go-live.
- Scope also covers the hosting model, MongoDB 8.0 replica set, identity source and every system the conversations must reach.
How we build
- Build starts with a Rocket.Chat instance sized to the reference architecture that matches your expected concurrent users.
- Omnichannel configuration covers departments, agent roles, queues, routing and the Livechat widget on your website.
- Channel integrations for WhatsApp, Twilio SMS and Telegram are built and tested against your own provider accounts.
How we hand over
- Handover includes configuration documentation, runbooks for routing changes and a list of every integration secret's owner.
- Agents and supervisors receive a walkthrough of queues, transfers and the conversation history your team will use daily.
- Test results for each channel and routing rule are delivered in writing alongside the environment.
How we support
- Version planning covers standard releases, supported for 6 months, and LTS releases, supported for 12 months.
- Upgrades are scheduled before end of life, since unsupported versions can lose Omnichannel integrations and mobile client connections.
- Ongoing support, upgrades and continuous testing are available under a retainer after the deployment goes live.
