发布于 Fri May 08 2026 08:00:00 GMT+0800 (中国标准时间)

案例迁移SaaSChatwoot

案例 · 一家 B2B SaaS 从 Intercom 迁到 Chatwoot 的 6 周复盘

一家 2000 客户、$2M ARR 的 B2B SaaS 在 6 周内完成 Intercom → Chatwoot 迁移，关键时间线、人员投入、踩坑全公开。

背景#

业务：B2B 开发者工具 SaaS
客户：2,000+ 付费 + 6,000+ 免费
ARR：约 $2M
团队：35 人，其中 6 个客服 + 2 个工程师
原 SaaS：Intercom Pro 5 seats + Fin AI（$1,650/月）

触发迁移的关键事件#

2026 年 1 月，Intercom 调整 Fin 定价从「按解决会话」改为「按 AI seat + Resolution」混合，预估月费从 $1,650 涨到 $2,800（+70%）。CFO 拍板「评估替代方案」。

迁移团队配置#

角色	人	总投入
项目经理	1	6 周 × 50%
后端工程师	1	6 周 × 100%
客服主管	1	6 周 × 30%
客服坐席	6	第 5-6 周培训各 3 小时

总人力：约 12 人周。

6 周时间线#

Week 1：数据导出 + 环境搭建#

用 Intercom Export API 拉历史对话（28,000+ 会话）
4 节 VPS 在 Hetzner 起好：Chatwoot 主、Dify 主、Postgres、Redis（Managed）
自动化导入脚本写好（Python，约 200 行）
关键发现：Intercom 附件 URL 有时效——必须 7 天内全部下载到 S3

Week 2：自动化迁移#

凌晨批量导入 28k 会话（耗时 6 小时）
客户档案、自定义字段、Tags 迁移完成
Help Center 文章（80 篇）导入到 Dify 知识库
关键 macros（15 条）→ Chatwoot canned responses

Week 3：业务编排重建#

把 Intercom 里的 Triggers / Automations 重新设计：

Intercom 原有	新方案
「新工单 + priority=high → 分配给 Team Lead」	Chatwoot Automation Rule
「3 天未回应 → 升级」	n8n Cron + Chatwoot API
「客户加 trial 标签 → 给销售 Slack」	n8n Webhook
「Fin 答不上 → 创建 Salesforce Lead」	Dify Workflow 失败分支 + n8n

Week 4：Prompt + KB 调优#

把原 Fin 的「Personality」描述翻译成 Dify Prompt
知识库做 3 次「评估集 → 调分块 → 再评估」循环
从默认 MRR@5 0.71 调到 0.88

Week 5：内部试用 + 培训#

6 个客服坐席每人 3 小时培训
把 10% 真实流量切到 Chatwoot（其余仍走 Intercom）
每天 review 失败案例

Week 6：全量切流 + 收尾#

Day 1：50% / 50%
Day 3：80% / 20%
Day 5：100% Chatwoot，Intercom 转为只读
Day 7：Intercom 账户降级到最低档（备份留 6 个月）

成本对比#

项	Intercom（新版定价）	Chatwoot 自部署
平台 / Seats	$1,800	$0
AI seats + Resolution	$1,000	$0
LLM tokens	—	$80
VPS（4 节）	—	$120
邮件 / 域名	—	$30
月费	$2,800	$230
年节省	$30,840

ROI：12 人周 × $100/h × 40h = $48,000 投入。第 19 个月起开始净盈利（实际加上工程师维护成本约第 24 个月）。

业务指标 6 周对比#

指标	迁移前 4 周	迁移后 4 周
月新增工单	2,640	2,580（基本持平）
首响时间	4 分钟（含人工）	8 秒（AI 兜底）
AI 自助率	38%（Fin）	52%（Dify + KB 调优）
CSAT（AI 段）	4.0	4.2
投诉转工单数	3 / 月	5 / 月（轻微上升）

注意：投诉数轻微上升的原因是 AI 回复更具体了，遇到边界 case（如「定制企业版价格」）AI 卡住，客户更不耐烦。修复：把这类边界 case 明确写入 Prompt「直接转人工」白名单。

客户感知调研#

迁移后第 8 周做了 NPS 邮件：

「过去一个月客服体验有变化吗？」
80% 客户回复「没变化或更好」
12% 表示「答案有时更详细了」（正面）
8% 表示「有时感觉是机器」（负面，主要来自老客户）

应对：给老客户标签的会话自动跳过 AI，直接转人工。

工程团队的真实工作量#

按周记录工程师投入：

周	工程师投入	客服主管投入
Week 1	40h（搭建 + 脚本）	4h
Week 2	40h（导入 + Debug）	6h
Week 3	40h（n8n 编排）	8h
Week 4	30h（Prompt 调优）	20h
Week 5	20h（试运行 Bug Fix）	18h
Week 6	20h（切流 + 善后）	10h
总计	190h	66h

切流之后，长期维护工程师投入 ~5h/周，主要是 Prompt 调整、知识库更新。

5 个关键决策与原因#

没自建 RAG 服务，用 Dify：本来想用 LlamaIndex 自己写 RAG，估算后发现 Dify 已经能覆盖 90% 需求，省 3-4 周
用 n8n 而不是直接 Webhook：业务规则多变，n8n 可视化降低维护成本
平行 1 周再切：原本计划平行 3 天，但 Week 5 发现一些边界 case，多平行 4 天值得
保留 Intercom 只读 6 个月：合规备份 + 万一需要回滚
培训客服而不是「让 AI 全自动」：客服坐席仍是 SLA 担当，AI 是工具

没做但应该做的#

事后复盘有 3 个遗憾：

应该早 1 周做压测——切流第 2 天遇到 Sidekiq OOM
应该提前准备「客户告知邮件」——切流当天才发，部分老客户没看见
应该把搬运 KB 的步骤自动化——目前 docs 改了还要手动同步 Dify