Published Tue Mar 10 2026 08:00:00 GMT+0800 (中国标准时间)
deep-diveChatwoot
Chatwoot deep review — 6 months in production, the unvarnished take
We ran Chatwoot 4.x in production for 6 months — 40k+ tickets, 12 agents, full debrief on Inbox, Captain, API and gotchas.
What we tried first#
- Intercom: great UX, monthly bill breached $2000 — out
- Crisp: nice UX, weak AI, shallow API
- Zendesk: overdesigned ticketing for SMB
- Help Scout: email king, real-time and mobile weak
- Papercups: Elixir ops overhead
Picked Chatwoot for MIT license, one-click Docker, active community and good-enough Captain.
Six months in numbers#
| Metric | Value |
|---|---|
| Tickets | 41,283 |
| Active agents | 12 |
| Primary channels | Web widget, email, WhatsApp, Discord |
| Avg ticket duration | 2m 14s with AI involvement |
| Downtime | 47 minutes total (one bad upgrade + three OOMs) |
Inbox system#
Chatwoot abstracts every channel as an Inbox. Each can:
- Auto-assign (round-robin, skill, customer label)
- Enable Captain or Agent Bot
- Set business hours, away replies
- Bind to teams and SLAs
Gotcha: deleting an inbox is irreversible — historical conversations lose their channel link. Back up first.
Captain in practice#
Captain is Chatwoot’s built-in AI helper. We use it as a second-line catch.
Wins#
- Live in 5 minutes
- KB supports URL crawl, Markdown upload, auto-sync
- Workflow handles simple intents like “look up my order”
Misses#
- Far fewer workflow nodes than Dify (no code, no concurrency)
- KB chunking not customizable
- Single LLM config (no per-inbox model)
Our trade-off#
Captain handles public FAQ. Complex business goes to Dify. Switching is just an Inbox config (Captain vs Agent Bot).
API + webhooks — most underrated#
| Use case | How |
|---|---|
| Ticket → Notion | Webhook → n8n → Notion DB |
| High priority → Lark/Slack | Webhook → Lark Bot |
| Monthly CSAT report | Cron → API → Metabase |
| Sensitive keyword → escalate | Pre-submit hook → keyword dict |
Deployment notes#
Recommended sizing#
| Scale | Spec |
|---|---|
| < 5 agents, < 1k tickets/mo | 2C / 4 GB VPS |
| 10 agents, 5k tickets/mo | 4C / 8 GB VPS |
| 30 agents, 30k tickets/mo | Two 8C/16 GB + external Postgres |
Three production scars#
- OOM: Sidekiq dies under multi-channel concurrency. Fix: split Sidekiq process, cap Redis memory
- Email loops: misconfigured Reply-to means infinite ping-pong. Fix: dedicated sender address per email inbox
- Postgres slow query: missing composite index. Fix: add
conversations(account_id, status)index
Fits / doesn’t fit#
| Fits | Doesn’t |
|---|---|
| SMB replacing Intercom | Enterprise with rigid ticket flows |
| Multi-channel intake | Email-only (FreeScout is lighter) |
| Data sovereignty | Zero ops capacity |
| Comfortable with light customization | Pure SaaS lovers |
Overall#
| Axis | Score |
|---|---|
| Feature coverage | 8 |
| Deploy difficulty | 6 |
| Community health | 9 |
| AI capability | 6 |
| Hackability | 8 |
| Overall | 7.4 |
Best combo after 6 months: Chatwoot as inbox, Dify as brain, n8n as orchestration — that’s the default we now recommend.