AI 支持的 Intercom 替代方案——不收取按解决次数的费用

用于 AI 支持的开源 Intercom 替代方案 应针对 Fin 的自动化层，而不是假装替代整个客服系统。它可以去除供应商按结果计费的计量方式，但不会消除成本，也不会复现 Fin 的 Apex 模型、渠道、分析、升级 UX 和支持运营。风险最低的路径是保留现有客服系统，用 Eigent 建立一个范围明确的检索和起草工作流，要求人工批准，并在扩大前比较每个成功结果的总成本。

首先：Intercom 和 Fin 的名称更新

原名 Intercom 的公司于 2026 年 5 月 12 日更名为 Fin，而客服系统产品保留 Intercom 名称（Fin 公告）。“Intercom Fin 替代方案”仍是有用的搜索说法，但公司当前的身份是 Fin。

Salesforce 于 2026 年 6 月 15 日签署最终协议，以约 36 亿美元收购 Fin，尚需调整并满足交割条件（Salesforce 新闻稿）。截至研究日期，准确表述是“同意收购”，不是“拥有”。已宣布的交易会带来正当的路线图和采购问题，但不能证明定价或产品会变化。

Fin 在大规模使用时的成本

Fin 当前的聊天和电子邮件方案对一次解决、已配置的 Procedure 转交或取消资格收取 $0.99，对销售资格判定收取 $9.99。语音、大用量和专门安排由销售主导（Fin 结果文档）。买方可配置提醒和硬性限制。

这些是算术示例，不是报价。它们假定列出的每项都按 $0.99 计费，并排除席位、可选渠道、实施和协商的大用量条款。

Intercom 按年付费的客服系统价格目前为：Essential 每个完整席位每月 $29、Advanced 为 $85、Expert 为 $132（Intercom 定价）。20 个 Advanced 席位在结果和可选渠道之外，每月增加 $1,700、每年 $20,400。Fin 也可以在另一套客服系统上运行而不收 Fin 席位费，但须满足最低结果承诺（Intercom 定价）。

什么算作 Fin 结果？

$0.99 的标价需要结合其计费定义理解。

• 一次解决可以被明确确认，或在用户离开且未请求更多帮助时被假定成立。
• 如果用户回到同一对话并需要更多协助，结果会被扣回。
• 被放弃的澄清问题不计费。
• 已配置的 Procedure 转交可能计费。
• 默认升级不计费。

这些规则来自 Fin 当前的结果文档（Fin 帮助）。在接受年度预测前，采购应回放真实对话并审计假定解决、重新打开窗口、已配置转交、重复项、重试和渠道转移。

Fin 称其 Apex 模型处理几乎所有英文聊天和电子邮件对话、每周解决近两百万个问题，并在 2026 年 3 月前增长到近 1 亿美元经常性收入（Fin Apex 公告）。这些是第一方的产品和业务声明，不是独立基准。

为什么团队寻找 Intercom 或 Fin 替代方案

结果成本随成功自动化增长

在高用量下，每个可计费结果的固定价格会成为重要的运营成本。2026 年 3 月的一场讨论中，一位与竞争者 My AskAI 有关的评论者称，5,000 次解决会形成约 $5,000 的每月 AI 层成本，并质疑假定解决是否总等于客户成功（Reddit 讨论）。该关联性和轶事性质很重要；Fin 自己的计费定义是更有力的来源。

源码和部署控制

Fin 是专有的托管平台。需要检查编排层、在本地运行、选择模型，或将索引和工具凭证保留在其环境内的团队，可能偏好开放技术栈。

所有权变更

更名和待完成的 Salesforce 收购案使可移植性值得测试。导出提示、政策、知识、转录稿、操作模式和评估案例，无论该交易是否改变产品，都能降低依赖。

Intercom 和 Fin 与 Eigent 技术栈的比较

Eigent 最强的作用是充当受控的编排层。它可获取工单、检索已批准文档、通过范围受限的 API 读取 CRM 或订单上下文、起草回复、分类风险、等待人工批准，并将证据和处置写回。

它不提供 Fin 的客服系统、专有支持模型、封装的全渠道连接器、分析、支持专用评估系统、成熟的升级界面、合同支持或所报告的规模。

安全的参考工作流

1. 接收一种低风险工单类别。 从内部 FAQ 或状态问题开始，不从退款、身份变更或受监管建议开始。
2. 分类意图和风险。 将敏感、模糊、愤怒或会变更账户的请求直接路由给人工。
3. 检索已批准来源。 使用版本化的政策和知识内容；将引用附到草稿。
4. 以最小权限读取账户上下文。 优先使用窄范围 API，而非通用浏览器会话。
5. 起草，不发送。 代理应分别提出答案和任何操作。
6. 要求批准。 支持负责人审核来源准确性、语气、账户数据和操作。
7. 写回客服系统。 保留回复、来源、处置、工具调用和审核者决定。
8. 评估重新打开和修正。 导致二次联系的低价答案不是成功结果。

客户支持领域工作流是相关的起点，但试点期间，现有客服系统应继续作为记录系统。

如何建模总成本

将 Fin 的结果和席位账单与开放技术栈的完整运营成本比较：

• 模型 API 或本地 GPU 成本；
• 客服系统和连接器费用；
• 检索／索引基础设施；
• 工程和集成时间；
• 评估数据维护；
• 安全审查和事件响应；
• 人工审核时间；
• 支持和可用性保障。

使用每个 成功结果 的成本，其定义是遵守政策、没有可避免的重新打开、操作正确、延迟可接受，并且客户满意或得到恰当升级。不要只为封闭率优化。

不替换客服系统的迁移路径

影子模式

让开放工作流针对历史或实时复制的工单运行，但不发送回复。将其草稿与人工解决结果比较。

人工批准的草稿

允许代理在现有队列中准备答案。要求代表审核并发送每条消息。

有界操作

添加一种可逆、低风险的操作，例如检索订单状态。退款、取消、身份变更和财务调整仍由人工控制。

受控自动化

只自动化持续达到质量阈值的工单类别。保留事件级日志、支出限制、回滚和通向人工支持的路径。

如需更广泛的类别选择，参见 /blog/open-source-ai-customer-support-agents。

Intercom 替代方案的开放构件

Chatwoot 的 Community 代码采用 MIT 许可，而其 enterprise/ 目录另有许可；付费自托管计划包含额外支持和 AI 功能（Chatwoot 许可、Chatwoot 定价）。Zammad 是采用 AGPL-3.0 的可自托管客服系统（Zammad 代码库）。旧版 Rasa framework 代码库采用 Apache-2.0，而当前的 Rasa Pro/CALM 是许可证密钥软件（Rasa 代码库、Rasa 许可）。

这些组件覆盖不同层级。客服系统不是 AI 代理，对话引擎不是工单系统，编排工作区也不是联络中心。

何时应保留 Fin？

当支持专用模型、全渠道产品、托管评估、分析、实施和企业服务足以证明结果定价合理时，应保留 Fin。当源代码和部署控制是强制要求、工作流范围狭窄，并且团队能够运营缺少的客服系统、连接器、安全、评估和支持层时，再考虑开放技术栈。

谨慎移除计量器

Eigent 移除了按每次解决计费的应用程序费用；它并未消除可靠支持自动化的成本或责任。通过客户支持解决方案从一个获批工作流开始，保留客服系统，并衡量重新打开和修正。 下载 Eigent来运行影子模式试点。