Zendesk vs Chatwoot: when each option fits a Zendesk customer's support operation
Chatwoot fits a Zendesk customer whose support is mostly live chat, email, WhatsApp and social messaging, and who can run a Rails and PostgreSQL service in-house. It is the closer match to Zendesk messaging than a ticket-first system. Its inbox brings the website chat widget, email, Facebook, Instagram, Twitter, WhatsApp, Telegram, Line and SMS into one view, and the README also lists a Help Center portal, auto-assignment, business hours, automation, canned responses, private notes and CSAT and agent reports. Map each channel you use today against that list before assuming parity, and confirm with the Chatwoot project how each channel is connected and what each one needs from Meta or your SMS provider.
The decision turns on four points. First, SAML SSO and SLA policies sit only in the paid Enterprise Edition, which Chatwoot's self-hosted plans page lists at $99 per agent per month. Premium Support, at $19 per agent per month, adds Captain AI, voice calls, custom branding and roles, but not SAML SSO. If your identity team requires SSO or your contracts depend on SLA timers, price that edition into the comparison from the start. Second, count the operating capacity you have: Chatwoot requires Ruby 3.2 or later, PostgreSQL and Redis 7.0 or higher, and officially supports only Ubuntu 20.04 as a Linux distribution, so confirm your patching and upgrade skills before committing.
Third, check data location rules. Self-hosting keeps conversations and contact data in your own infrastructure, but the channel integrations still send messages through Meta, WhatsApp and SMS carriers, so map those flows with your privacy team. Fourth, review the migration path. Chatwoot does not offer a Zendesk importer comparable to Zammad's, so plan how historical tickets will be exported and archived, starting with the export options described in the Zendesk help center. If your support is mainly ticket-based email with formal queues, a ticket system may be the better fit.
Which option fits which support scenario
This table maps common support scenarios to the platform that usually fits better, with a short reason for each. Read it against your own channel mix, compliance requirements and operations staffing, since the right answer depends on which constraint is hardest for your team.
| Scenario | Better fit | Why |
|---|---|---|
| Multichannel website chat, WhatsApp and social messaging | Chatwoot | Chatwoot puts website live chat, email, Facebook, Instagram, WhatsApp, Telegram, Line and SMS in one inbox on your own servers. |
| Email-heavy ticketing with formal ticket states and queues | Zendesk, or Zammad for self-hosting | Chatwoot is built around conversations; teams that depend on mature ticket workflows should compare Zammad's ticket model before deciding. |
| SAML SSO required on a self-hosted install | Zendesk, or Chatwoot Enterprise Edition | SAML SSO sits in Chatwoot's paid Enterprise Edition, not the free Community Edition; confirm the current edition terms with Chatwoot. |
| SLA policies for response and resolution targets | Zendesk, or Chatwoot Enterprise Edition | Chatwoot lists SLA policies only in the Enterprise Edition, so the Community Edition cannot enforce them. |
| Strict data residency with full control of storage locations | Chatwoot self-hosted | All conversations, attachments and contact data stay in your chosen cloud account or data center rather than Zendesk's regions. |
| Team with no platform operations staff | Zendesk, or a managed Chatwoot partner | Chatwoot needs Ruby, PostgreSQL, Redis and Sidekiq maintained; without that skill, Zendesk's hosted service removes the operations load. |
| Large, mature help desk with broad app marketplace needs | Zendesk | Zendesk's partner ecosystem and long-running integrations are wider than Chatwoot's listed integrations; confirm the ones you need. |
How Chatwoot's single inbox handles channels and routing
Chatwoot places website live chat, email, Facebook, Instagram, Twitter, WhatsApp, Telegram, Line and SMS into one inbox, so every conversation lands in the same queue with the same assignment, labels and private notes. For a support lead, the first question is not whether each channel exists but whether each one your Zendesk setup uses has a working equivalent. Map every Zendesk channel, trigger and routing rule to a Chatwoot inbox, team or automation before you plan a switch. Confirm the exact channel connection steps for each provider (WhatsApp, for example, depends on the provider you connect) in the current Chatwoot documentation and in your own test account, because connection requirements change with provider policies.
Routing in Chatwoot is built from several parts that interact. Auto-assignment by agent availability distributes new conversations, teams group agents by queue or language, labels tag conversations for filtering and reporting, and private notes let agents hand off context without exposing it to the customer. Business hours and auto-responders control what customers see outside staffed periods. Test these together in a pilot: send a conversation through each channel, confirm it reaches the right team, check that an unavailable agent is skipped, and confirm that a private note does not appear to the customer. Record any Zendesk trigger that cannot be reproduced and decide whether a manual step or a different workflow covers it.
Bot and routing behavior needs validation before go-live, because automated replies and assignment logic often differ between platforms even when the settings look similar. Captain, Chatwoot's AI agent, is available in the paid tiers and is not part of the Community Edition, so any bot your team relies on today needs a separate decision. Run a scripted set of common customer questions through the pilot, compare the answers and hand-offs with what Zendesk produced, and agree on acceptance criteria with the team leads who own those queues. Ask your Chatwoot account contact or review the current plans page to confirm which automation features each edition includes.
Where the data lives and who operates the platform
Zendesk runs the service in its own cloud, while Chatwoot runs wherever you install it. The cards below cover where data sits, how Chatwoot is deployed, which features need the paid edition, what evidence you must assemble, and where the MIT license stops.
Data location and control
Zendesk hosts tickets, conversations and attachments in its cloud, so data location depends on the plan and add-ons you buy. With Chatwoot, conversations, contacts, attachments and the PostgreSQL and Redis stores sit in the servers and cloud accounts you choose. Check where your backups, mail relays and channel integrations send data, because WhatsApp, Facebook and SMS providers receive messages through their own platforms regardless of where Chatwoot runs.
Hosting models and install paths
Chatwoot documents a Linux VM installation script, Docker, and Kubernetes with a Helm chart for larger high-availability deployments, plus guides for AWS, Azure, DigitalOcean, Google Cloud and Heroku. Your team picks the path, then owns upgrades, PostgreSQL backups and Redis operations. A single VM suits a small inbox, while a Helm deployment needs a platform team that can run Kubernetes. Confirm which path your operations team can support before choosing the install method.
SAML SSO sits in Enterprise
Chatwoot's Community Edition has no SAML single sign-on. SSO with SAML is part of the Enterprise Edition on the self-hosted plans page, so teams that require federated login from Zendesk's identity setup must budget for that edition or keep local accounts with strict password and access controls. Zendesk users who already sign in through an identity provider should confirm how their agents will authenticate before cutover, including how departing agents lose access.
Audit evidence that DeployOpen prepares
A self-hosted inbox moves the audit scope onto your environment. DeployOpen can prepare configuration baselines, access reviews, backup and restore records, and change logs for the Chatwoot deployment, but auditors and certification bodies issue any report or attestation. Ask your assessor early which evidence they need for customer data handled in the inbox, and which Zendesk compliance reports you will stop receiving once tickets move to your own servers.
MIT license scope and exclusions
Chatwoot's code is MIT licensed except content in the enterprise directory, which uses the separate license in that folder. Third-party components keep their own licenses. Before you build internal modifications, read the LICENSE file and the enterprise license text to see which features you can fork, and confirm with counsel how Captain, voice calls and custom branding, which appear in the paid tiers, are licensed for your use.
What the free Community Edition leaves out
The MIT Expat license covers Chatwoot's code outside the enterprise/ directory, so the core inbox, live chat widget, channel connectors, Help Center and reports can be run and modified without a license fee. The enterprise/ directory is licensed separately under its own file, and third-party components keep their own licenses. Before budgeting, have legal review both license texts, since a Community deployment that touches enterprise-only features may need a different license position than the rest of the codebase.
Chatwoot's self-hosted plans page places several capabilities outside the Community Edition. Premium Support at $19 per agent per month adds Captain AI, voice calls, custom branding, agent capacity, roles and permissions, and priority support. The Enterprise Edition at $99 per agent per month adds SSO with SAML and SLA policies. If your support team depends on role-based access for agents, SAML sign-in through your identity provider, or contractual response targets, these are the items that change the total cost, and they recur per agent every month. Ask Chatwoot for a written quote that names each feature and the agent count, because the cost scales with headcount rather than with servers.
Plan contents change between releases, so confirm the current feature split on the Chatwoot self-hosted plans page before you commit to a budget or a Community deployment. Check each feature you need (Captain, voice, branding, roles, SAML, SLA policies) against the page, and record the date you checked. Then test the Community Edition with your own agent roles and identity provider in a non-production instance, so you learn early whether any workaround is needed for access control or response-time reporting.
Operating effort for a self-hosted Chatwoot deployment
A platform team that already runs PostgreSQL and Redis can absorb Chatwoot with the least new learning. The stack is Ruby on Rails with Vue.js, so the team needs Ruby 3.2 or later and Node.js 20.x on the build and runtime hosts, plus PostgreSQL as the only supported database and Redis 7.0 or higher for queues and caching. Your team owns upgrades, backups, monitoring and capacity planning, and the sizing guidance matters here: the requirements page recommends at least 4 CPU cores and 4 GB of RAM for up to 10,000 conversations a day, and 8 cores and 8 GB for up to 20,000, plus at least 1 GB of swap.
- Language runtimes: Pin Ruby 3.2 or later and Node.js 20.x in your image or configuration management, and track them as separate upgrade items.
- Database ownership: PostgreSQL is the only supported option, so reuse your existing HA pattern rather than adding a second engine.
- Queue memory: Sidekiq can use more than 1 GB on a very active server, so size workers and watch memory before it becomes an incident.
- Helm for scale: Kubernetes with the Helm chart fits teams that already operate clusters for larger high-availability deployments.
- Upgrade cadence: Plan around the release cadence in the GitHub releases, where v4.18.0 followed v4.17.1 and v4.17.0 in 2026.
Confirm your own load profile against the 10,000 and 20,000 conversation-per-day bands before you buy hardware, and ask whether your sizing includes Sidekiq headroom.
A small IT team without deep database or queue experience usually starts with the Linux VM installation script. The Chatwoot documentation lists it as one of the self-hosting routes alongside Docker, so the installer carries much of the setup, but the team still owns the host and everything the installer does not do for them. The officially supported Linux distribution is Ubuntu 20.04, which is the only one listed, so a different distribution means you carry the support risk yourself.
- Supported OS: Ubuntu 20.04 is the only officially supported distribution, so confirm your standard image before choosing this route.
- Host sizing: Start from the recommended minimums and add at least 1 GB of swap as the requirements page advises.
- Day-two tasks: Your staff handles patching, certificate renewal, database backups and restore tests.
- Mail and channels: Email and social channel connectors need credentials, webhooks and DNS changes that the installer will not manage for you.
- Single admin risk: Document the installation and keep at least two people who can restart services and roll back a failed upgrade.
Before committing, ask a reference-level question of yourself: who answers the phone when the inbox stops at 9 a.m. on a Monday, and does that person know how to read the Sidekiq and PostgreSQL logs?
Some organizations want the control of self-hosting without taking on the operating load. In that model, the organization keeps the data inside its own cloud account, data center or private network, and an implementation partner plans, installs, hardens, backs up, upgrades and supports the stack under a written scope. DeployOpen works this way for self-hosted open-source platforms, and most engagements are fixed-scope, with ongoing support and upgrades available as retainers. The organization still pays for the infrastructure it owns, and it should ask for a quote that separates the one-time build from the recurring operations.
- One-time work: Architecture, sizing against the conversation bands, installation, channel setup and migration of existing conversations.
- Recurring work: Upgrades, monitoring, backup testing, security patching and on-call response, which are the items most often underpriced.
- Cost drivers: The number of channels, the volume of conversations, integration count and the availability target all raise the price.
- Edition decisions: Ask whether SAML SSO or SLA policies are needed, because those features sit in the paid Enterprise Edition.
- Exit terms: Confirm who holds the backups, configuration and runbooks if the engagement ends.
DeployOpen does not publish a price list, so ask for a written scope that names the environment, the channels and the support hours before comparing offers.
Cost components on each side
This table lists who is paid for each cost component when you stay on Zendesk and when you run Chatwoot on your own servers, and whether each item is one-time or recurring. Read the Zendesk column as items on your own invoice and the Chatwoot column as items your team or a partner pays for, then check the plan and edition rows against the Chatwoot plans page before you budget. The main takeaway is that Chatwoot's software fee is zero only on Community Edition, and SSO and SLA policies sit in the paid Enterprise Edition.
| Cost component | Zendesk (cloud subscription) | Self-hosted Chatwoot | What drives it up or down |
|---|---|---|---|
| Software license | Recurring per-agent subscription and add-ons billed to you by Zendesk; confirm current rates on your order form | Community Edition is free to download and run under the MIT license outside the enterprise directory (recurring fee: none) | Choosing Community versus paid editions; the number of agents who need paid features |
| Paid Chatwoot editions | Not applicable | Premium Support at $19 per agent per month; Enterprise Edition at $99 per agent per month, both listed on the Chatwoot self-hosted plans page (recurring) | Agent count, and whether you need Captain AI, custom branding, roles, SAML SSO or SLA policies |
| SSO and SLA policy access | Included in the subscription tier you buy; confirm which tier includes SSO and SLA features | SAML SSO and SLA policies require the Enterprise Edition (recurring, per agent); Community Edition does not include them | Whether your identity provider requires SAML, and whether SLA tracking is a hard requirement |
| Hosting infrastructure | Not applicable | Virtual machines or Kubernetes nodes in your cloud or data center, sized for conversation volume (recurring) | Daily conversation volume; Chatwoot recommends 4 cores and 4 GB RAM up to 10,000 conversations a day and 8 cores and 8 GB up to 20,000 |
| PostgreSQL and Redis operations | Not applicable | Managed or self-run PostgreSQL and Redis 7.0 or higher, plus backups and failover (recurring) | Managed service versus self-run; high-availability design; Sidekiq memory use on busy servers |
| Upgrades and patching | Included in the subscription; Zendesk applies platform changes | Internal or partner time to apply Chatwoot releases, Ruby and Node.js updates and OS patches (recurring) | Release cadence, number of environments, and whether you run Ubuntu 20.04 as the only officially supported Linux distribution |
| Backups and data exports | Export features depend on plan; JSON, CSV and XML exports are not on Team plans and must be enabled by Zendesk support | Your own backup schedule and storage for PostgreSQL and attachments (recurring) | Retention period, attachment volume, and restore testing frequency |
| Migration effort | Not applicable for the current platform; exit requires exporting data from Zendesk | One-time setup, configuration of channels such as WhatsApp and email, and data import if you move history (one-time) | Number of channels connected, custom automations to rebuild, and volume of history to carry over |
| Support contract and internal admin time | Included in your Zendesk plan tier; higher tiers add support options | Chatwoot Premium Support or Enterprise support is optional; internal admin time is otherwise required (recurring) | Whether your team has in-house Rails and infrastructure skills, and how fast you need incident response |
What a move from Zendesk to Chatwoot involves
The sequence below takes a Zendesk support operation onto a self-hosted Chatwoot instance with its channels, data and team structure intact, and ends with a cutover you can verify. No supplied fact covers a Zendesk-to-Chatwoot importer, so confirm import options with Chatwoot before you plan the data moves.
Inventory channels, automations and edition needs
Start by listing every channel Zendesk handles today, such as website chat, email, WhatsApp, Facebook, Instagram, Telegram, Line and SMS, along with every trigger, automation, macro and SLA target. Note which of these depend on features that sit in Chatwoot's paid tiers. The Community Edition is free but leaves out SAML SSO and SLA policies, which sit in the Enterprise Edition, and Premium Support adds Captain AI, voice calls, custom branding and roles and permissions. Owners of this step are the support lead and the identity team. It is done when each Zendesk feature is marked as covered by the Community Edition, covered by a paid edition, or dropped, and the edition decision is signed off.
Provision the self-hosted Chatwoot stack
Choose a deployment path that fits your infrastructure: the Linux VM installation script, Docker, or Kubernetes with the Helm chart for larger high-availability setups. Chatwoot requires Ruby 3.2 or later, recommends Node.js 20.x, supports only PostgreSQL as its database, and recommends Redis 7.0 or higher. Ubuntu 20.04 is the only officially supported Linux distribution, so confirm that your host image is covered. Size the servers against Chatwoot's guidance of at least 4 CPU cores and 4 GB of RAM for up to 10,000 conversations a day, and 8 cores and 8 GB for up to 20,000, with at least 1 GB of swap. The step is done when the instance loads, sends a test email and accepts a test chat message from the widget.
Configure inboxes and channel connections
Create one inbox per channel or per support queue in Chatwoot, then connect each one to its provider. Website live chat uses the widget snippet, email needs your mail routing configured, and WhatsApp, Facebook, Instagram, Telegram, Line and SMS each require their own provider credentials and webhook setup. Confirm the current connection steps for each channel in Chatwoot's documentation, since provider requirements change. Set business hours, auto-assignment and auto-responders per inbox so routing matches what Zendesk did. The step is done when a test message on every channel arrives in the correct inbox and a reply goes back out through the same channel.
Export Zendesk data and confirm what it contains
The account owner must ask Zendesk support to enable data exports, because they are not on by default and are not available on Team plans. Once enabled, exports come as JSON, CSV or XML, depending on plan. Zendesk's CSV export omits ticket comments and descriptions, XML is capped at 500 MB and unavailable above 200,000 tickets, and JSON is recommended for accounts above 200,000 tickets. Keep the exports as a read-only archive regardless of what moves into Chatwoot. Confirm with Chatwoot whether any importer accepts these files, since no supplied fact covers one. The step is done when the export files are stored in a secured location and you have checked row counts against Zendesk's reports.
Map agents, teams and canned responses
Recreate each Zendesk agent in Chatwoot with the role that matches their permissions, then build teams that mirror your current queues. Move canned responses and labels so agents keep familiar replies, and recreate automation rules, business hours and contact segments. Keep a mapping sheet that lists each Zendesk group and macro beside its Chatwoot team or response, with a named owner for any item that has no direct equivalent. Roles and permissions beyond the basics are part of the paid Premium Support edition, so check that against your mapping. The step is done when every active agent can sign in, sees the right inboxes, and the mapping sheet has no unassigned items.
Run a parallel period and test routing
Keep Zendesk live while Chatwoot handles a limited set of real or test conversations, so that agents can check routing, assignment, reporting and CSAT before anyone relies on the new system. Compare the conversation, agent and inbox reports in Chatwoot with the figures your team already tracks, and confirm that private notes, labels and handoffs behave as expected. Log issues in a shared list with an owner for each. The step is done when the open issue list contains only accepted gaps and each team lead has signed off on routing for their queues.
Cut over and retain the Zendesk archive
Point each channel to Chatwoot in a planned order, update website widget and email routing, and tell customers and agents which channel now answers. Turn off new Zendesk intake only after the last channel is confirmed on Chatwoot. Keep the export archive and the Zendesk account in its agreed read-only state for as long as your retention policy requires, and confirm the contract end date with Zendesk before you cancel. The step is done when every channel answers from Chatwoot, the archive is verified and retained, and the cutover record is filed with the support lead and the identity team.
Questions buyers ask before switching from Zendesk to Chatwoot
How much does it cost to switch from Zendesk to Chatwoot?
The software cost depends on the edition you choose, and the switch cost depends mostly on work you pay for separately. Chatwoot's Community Edition has no license fee, while its self-hosted plans page lists Premium Support at $19 per agent per month and the Enterprise Edition at $99 per agent per month. Your costs fall into four groups: the server and PostgreSQL and Redis hosting, the migration and configuration work, any Chatwoot support contract, and the internal admin time to run it. Hosting and migration are largely one-time or set up once, while hosting, backups and support recur. Ask any implementation partner for a fixed-scope quote that lists each component separately.
How long does a Chatwoot pilot and cutover take?
No duration is fixed for this, and the length depends on the scope you set. The main drivers are how many channels you connect (website widget, email, WhatsApp, SMS and social inboxes), how many automations, teams and canned responses you rebuild, how much history you carry over, and how many agents need training. Channel approvals with Meta or an SMS provider can take time that you do not control, so start those early. A pilot with one team and one channel usually shortens the cutover. Ask for a written timeline tied to a defined scope before work starts.
What does the work need from our own staff?
Your staff must make decisions and provide access, and they will need time for testing. Expect to name a business owner who signs off on routing rules, business hours, auto-assignment and CSAT questions. Your IT or platform team needs to approve the hosting environment, DNS, email routing, SSL certificates and access to the Meta, SMS or other channel accounts. Support leads should review the canned responses and help center content before cutover, and agents need hands-on time in the new inbox. Ask the provider to list these roles in the scope so you can plan staff time before the project starts.
Can an internal team run a Chatwoot switch alone?
Yes, if your team has Ruby on Rails, Linux and PostgreSQL operations experience and enough time to run the project. Chatwoot documents installation through a Linux VM script, Docker and a Kubernetes Helm chart for larger high-availability deployments. The Chatwoot deployment requirements list Ruby 3.2 or later, Node.js 20.x, PostgreSQL only and Redis 7.0 or higher, and Ubuntu 20.04 is the only officially supported Linux distribution. Before deciding, confirm that your operating system and hosting plan match those requirements. Teams without this experience often bring in an implementation partner for the install, hardening, backups and upgrade plan.
Does SAML SSO require Chatwoot's Enterprise Edition?
Yes. Chatwoot's self-hosted plans page places SSO with SAML in the Enterprise Edition at $99 per agent per month, and the Community Edition does not include it. The Premium Support tier at $19 per agent per month adds Captain AI, voice calls, custom branding, agent capacity, roles and permissions and priority support, but the page lists SAML under Enterprise. Because plan contents can change, confirm the current SAML and SLA policy coverage on the Chatwoot pricing page before you sign anything. Also confirm how your identity provider handles user provisioning, since login support alone may not cover your offboarding process.
How does Chatwoot compare for WhatsApp and SMS coverage?
Chatwoot's README lists WhatsApp and SMS among the channels in one inbox, alongside the website live chat widget, email, Facebook, Instagram, Twitter, Telegram and Line. That covers the channels most support teams use, but it does not show the depth of each one. Confirm the WhatsApp Business API and SMS provider setup you need, including template messages, sender registration and per-message fees charged by those providers, which are separate from Chatwoot. Zendesk's own messaging features and plan limits should be checked against your current contract, so compare them side by side with your actual message volumes.
What happens to our Zendesk ticket history and data?
Your history moves only if you export it and import it, and that work is a separate task from installing Chatwoot. Zendesk offers JSON, CSV and XML exports on Suite Growth and higher and Support Professional and higher, not on Team plans, and the account owner must ask Zendesk support to enable them. The CSV export omits ticket comments and descriptions, so plan for JSON if you need full conversation history. Decide early whether to migrate closed conversations, contacts and attachments, or to keep Zendesk read-only for a defined period. Ask any provider how they will map contacts and conversations into Chatwoot.
What remains your responsibility after go-live
Once Chatwoot is live, the backups of the PostgreSQL database and the uploaded attachments are your responsibility. Chatwoot supports only PostgreSQL, so the database dump or snapshot schedule belongs to your team or your DeployOpen retainer, along with a restore test on a separate host. Attachments such as files sent through conversations need their own copy, and their storage location should be confirmed against your deployment guide before you set the retention window. Agree a recovery point and recovery time with the business owners of the support queue, because a backup that has never been restored is an assumption, not a control.
Plan Chatwoot version upgrades as a recurring task. Releases are published on a regular cadence, with v4.17.0 on August 20, 2026, v4.17.1 on August 27, 2026 and v4.18.0 on September 18, 2026, so an upgrade calendar should exist before go-live. Each upgrade needs a staging rehearsal, a database migration check, and a review of the Ruby, Node.js and Redis requirements in the release notes, since the requirements page sets minimums that can change between lines. Patching the Ubuntu host and its packages, and the Ruby and JavaScript dependencies, is a separate stream that also needs a schedule. Operating system support should be confirmed with Chatwoot before you upgrade the host.
Monitoring and incident response close the loop. Watch CPU, memory, swap, Sidekiq queue depth and Redis health, because Sidekiq can use more than 1 GB of memory on a very active server and sizing drifts as conversation volume grows. Define who receives alerts, who can restart services, and how a suspected data exposure in the inbox is escalated to your security and privacy teams. Ask yourself who holds the admin role and who can reach the server outside business hours. DeployOpen can run backups, patching, monitoring and incident response under a retainer, or your own team can run them if it has the capacity. Either way, confirm ownership in writing before go-live.
How DeployOpen helps evaluate, implement and migrate
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up and supports self-hosted open-source platforms inside your own infrastructure. For Zendesk vs Chatwoot, we start with the channels and edition features your team actually depends on, then build and document the deployment you choose.
How we scope
- Inventory which channels your team runs today: website chat, email, WhatsApp, social and SMS.
- Confirm whether SAML SSO or SLA policies require Chatwoot's paid Enterprise Edition.
- Agree deliverables, timelines and responsibilities in writing before any work starts.
- Engagements are fixed-scope, with the written scope setting the quote.
How we build
- Deploy Chatwoot in your cloud account, data center or air-gapped network using your chosen method.
- Provision PostgreSQL and Redis, and size servers against your expected daily conversation volume.
- Configure inboxes, auto-assignment, business hours, canned responses and the Help Center portal.
- Test each channel end to end, including webhook and email routing, before go-live.
How we hand over
- Document architecture, configuration, backup procedures and the operating runbook for your admins.
- Provide a migration plan for exporting Zendesk conversations and contacts, with gaps listed.
- Walk your administrators through agent roles, reports and routing rules in working sessions.
- Record which features rely on Community Edition and which need a paid Chatwoot license.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer.
- Plan Chatwoot version upgrades around the release cadence and your change windows.
- Keep backups and restore tests current as channels and conversation volume grow.
- Ask us to scope a retainer alongside the initial fixed-scope implementation.
