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來執行影子模式試點。