我選擇將在線客服系統作為獨立開發的方向，並持之以恆地堅持了多年。偶爾會有人問我，為什麼選這個領域？明明這是一個競爭激烈的紅海市場，且市面上已有眾多產品可供選擇。針對這點，我想專門寫一篇部落格，詳細回答這個問題。

我會從「市場現況」與「技術路線」兩個維度來分析：為什麼這個紅海市場依然有值得切入的空間？以及它的技術門檻，可能比你想像中要高得多。

對於中小型團隊來說，在線客服系統真的有很多選擇嗎？其實不然。如果我們將市面上的在線客服系統進行橫向分類，大致可分為以下幾種：

1. 龍頭 SaaS 產品：以 SaaS 服務為主，訂閱費用偏高。如果用量較大、客服坐席數量較多，對中小團隊來說是一筆不小的支出。這類產品基本上不提供私有化部署，或是私有化部署的費用極其昂貴（通常以專案方式運作）。

2. 次龍頭（二線）產品：以 SaaS 形式為主，私有化部署僅是次要定位。訂閱價格高低不等，產品質量也良莠不齊。關於私有化部署，價格通常不公開，需要透過業務代表進行個別談判。根據我調查的幾家公司，導入費用約需 數萬美元至十幾萬美元 不等，且不存在「買斷」模式，每年仍需持續支付技術維護費。

3. 各種小作坊出品的玩具：這個等級的客服系統多如牛毛，主要特點是粗糙且廉價，甚至幾百美元就能提供原始碼，且絕大多數是純 Web 版本。這類產品在本機端用少數訪客測試時看似可行，但通常在正式上線一段時間後，就會暴露各種問題：漏訊、串訊、無法長時間掛機（隨機無回應或斷線）。

同時，以上各類客服產品還有一個共同點：「遮遮掩掩」。

你無法從他們的官網上找到詳細的技術文件，也不能直接下載私有化部署包，必須聯繫他們的業務人員。我曾嘗試聯繫過兩家，對方仔細詢問我的用途、規模，甚至要求電話溝通確認，讓我感覺被「看人下菜碟」了。而且他們不直接提供私有化部署包，必須由他們代為部署，還要求提供網域（Domain）供其驗證，這無非是想探知我的業務規模與付費能力，方便他們進行「客製化報價」。在經過一段時間的「溝通」後，我才拿到「套裝」價格，這種感覺非常糟糕。

綜上所述，如果你是一位中小團隊的負責人，希望能找到一款能 100% 私有化部署的客服系統，價格不能太貴，功能不必太複雜，但品質必須在線。你會發現：你根本沒得選。沒錯，在一個看似紅海的市場，你竟然沒得選。

而這就是我切入的方向：一款小而美、穩定可靠、具備大廠品質的客服系統。私有化部署價格親民，大大方方地提供免費的私有化版本讓有興趣的人直接下載，並提供詳細的技術文件供人直接參考、直接使用。

這就是我正在做的事情。

接著再談談技術層面的問題。我敢說 99% 的人會嚴重低估在線客服系統的技術實現難度。很多只會 CRUD（增刪查改）的工程師會說：不就是 WebSocket 收發訊息嗎？

這大概就像是一個文科生學會了用 Python 寫 Hello World，然後感嘆編程不過爾爾。

這種想法的膚淺之處在於，他們根本沒有軟體開發的概念。客服系統不論是服務端還是客服端，內部都需要維護許多極其複雜的「狀態機（State Machine）」，這與 CRUD 類的無狀態（Stateless）系統完全不是一回事。

首先是連線管理與穩定性的問題。你處理的不僅是幾個連線，而是成千上萬甚至更多的長連線。瀏覽器、行動端、弱網環境、斷網重連、代理伺服器、企業防火牆，各種邊緣案例（Edge Cases）。你必須設計心跳機制（Heartbeat）、斷線重連策略、工作階段恢復（Session Recovery）機制。一旦處理不好，就會發生訊息遺失或串訊的慘劇。

其次是訊息的可靠性與一致性。「訊息發出去了」並不等於「對方收到了」。你需要處理 ACK（確認機制）、重試、冪等性（Idempotency）以及順序保證。這中間涉及訊息路由、分發、持久化與回溯。你還得考慮：

• 是否允許亂序？
• 如何保證同一對話內的嚴格順序？
• 訊息儲存失敗時該怎麼辦？

小作坊的玩具產品走到這一步，通常就已經開始崩潰了。

客服系統的訊息收發必須追求「即時」，但即時意味著高頻通訊、低延遲以及持續的資源佔用：

• 每個連線佔用多少記憶體？
• 心跳間隔（Heartbeat Interval）該如何設定？
• 如何避免廣播訊息引發的「訊息風暴」？
• 資料庫寫入如何才不會成為效能瓶頸？

再者是複雜的業務狀態管理。很多沒深入了解過的開發人員，會把客服系統等同於「聊天室」來看待。但客服系統並非聊天室，它有非常複雜的業務流程：

• 對話分配（輪詢 / 權重 / 技能組）
• 轉接（需攜帶上下文且不能中斷）
• 排隊（優先級、逾時處理）
• AI 介入（人機協作切換）
• 離線訊息與訪客軌跡追蹤

這些狀態是動態變化的，而且彼此強耦合。在高併發場景中，若處理不當極容易造成混亂，導致漏訊、串訊、無回應，甚至直接斷線。

很多二線產品，走到這一步也開始「起肖」（抽風）不穩了。

再進一步：安全與濫用防護。許多用戶在使用客服系統時，是直接與真金白銀的訂單掛鉤的，該如何防止：

• WebSocket 濫用（連線洪水攻擊）
• 訊息注入 / XSS 攻擊
• 惡意刷訊息
• API 被爬蟲抓取或被流量打爆

限流（Rate Limiting）、鑑權、隔離機制該如何實現？

最後，關於私有化部署這一塊，雖然我現在可以隨時讓用戶在我的網站上下載私有化部署包，但前期也踩過不少坑，例如：

• 如何適配不同的網路環境（甚至是跨國環境）？
• 如何適配不同的作業系統（Linux、Windows、Docker）？
• 不同版本的伺服器，甚至同一個版本的 Ubuntu，在不同雲端廠商的鏡像（Image）中竟然有不同的裁減。
• 日誌、監控、診斷機制怎麼做？
• 一鍵安裝腳本怎麼寫？
• 版本升級該如何處理？

回顧以上這些問題，你還能說「不就是 WebSocket 收發訊息」嗎？

雖然解決上述種種問題需要投入大量的時間與精力，甚至連「發現」問題本身都極其耗時，特別是許多邊緣案例，如果沒有用戶願意協助反饋，你根本無從察覺。

但這些「門檻」，也正是我堅持開發在線客服系統的重要原因。在我堅持數年的迭代與累積之後，它們轉化成了我的護城河。作為一名獨立開發者，這讓我避開了大量的直接競爭（例如獨立開發常見的「三件套」：記帳、筆記、待辦清單）。

立即開始

如果您對此感興趣，歡迎進一步了解：

• 🌐 官方網站： https://shendesk.com
• 📘 技術文件： https://docs.shendesk.com

無論您偏好雲端託管方案，還是 私有化部署（Self-hosted），我們皆提供免費試用。非常歡迎您的回饋與建議。