Unthread
在 Slack 裡開工單的 AI 服務台，會自己把解掉的問題寫進知識庫
Unthread 是 AI 原生的服務台平台，最大的特色是「對話即工單」：團隊在 Slack 或 Microsoft Teams 裡的求助對話直接變成可追蹤的工單，不用叫人跳去另一個系統填表。官網自稱 AI-native，代理式 AI 負責自動解決請求，某個案例研究顯示自動解決率約 40%。
服務對象包含 IT、HR、客服、員工支援與 RevOps 團隊，客戶名單有 Intuit、SpaceX、Lemonade、Sisense。功能包含自學型知識庫（會從已解決工單自動更新）、跨 100 多個工具的流程自動化、ITIL 就緒能力（CMDB、變更管理、CAB 審批、SLA）、全渠道進線（email、入口網站、線上聊天、API）以及分析與待命輪值。官網明說不提供自助註冊，必須預約示範。法人名稱為 Get Turnout, Inc.。
功能特色與適用場景：自學型知識庫是這個產品最實用的設計。服務台的老問題是知識庫永遠過期——工程師解掉一個問題，順手在 Slack 回覆完就結案，沒人有力氣回頭寫文件。Unthread 把已解決的工單自動整理進知識庫，等於把「寫文件」這件事從人的意志力問題變成系統行為。40% 的自動解決率聽起來不如同業宣稱的七成，但這個數字反而比較像真話。ITIL 就緒那塊值得留意：有 CMDB 與變更管理，說明它不只是聊天機器人，能撐得住有稽核需求的正式 IT 流程。適合以 Slack 或 Teams 為主要溝通工具的公司，尤其是工程團隊比例高的組織。台灣的新創與科技公司若已重度使用 Slack，這種原生體驗的摩擦最小。
TheAI學院 編輯建議
編輯實測後的真心話服務台工具最大的敵人是「使用者懶得填表」，所以 Unthread 直接在 Slack 裡收工單這招我覺得很聰明——降低摩擦比增加功能有效。自學型知識庫也打到真痛點，但務必設好人工核可，不然錯誤解法會被系統很勤勞地擴散。它不給自助註冊這點對評估者不太友善。
主要功能
- Slack 與 Microsoft Teams 內的對話式工單
- 代理式 AI 自動解決請求
- 自學型知識庫，從已解決工單自動更新
- ITIL 就緒：CMDB、變更管理、CAB 審批、SLA
- 全渠道進線：email、入口網站、線上聊天、API
- 跨 100+ 工具的流程自動化
- 分析報表與待命輪值排班
適用場景
- Slack 內的 IT 與 HR 求助轉工單
- 工程團隊的內部支援請求追蹤
- 已解決問題自動累積成知識庫
- SLA 與待命輪值管理
- 跨工具的服務流程自動化
Unthread 的優點與缺點
優點
- 對話即工單，使用者不用離開 Slack，採用率的摩擦最小
- 自學型知識庫把寫文件從意志力問題變成系統行為
- 有 ITIL 完整能力，撐得住正式 IT 治理流程
- 客戶名單含 SpaceX、Intuit，工程導向組織的實證
缺點
- 不提供自助註冊也不公開定價，評估門檻高
- 官網未載明總部所在地
- 40% 自動解決率低於同業宣稱值（雖然可能更真實）
- 非 Slack／Teams 為主的組織，價值會明顯下降
價格方案
官網明示不提供自助註冊，須預約示範後報價，未公開金額。
Unthread 常見問題
在 Slack 裡開工單，會不會反而更亂？
如果沒有工單化就會亂——這正是它想解的問題。純用 Slack 求助的下場是：訊息被洗掉、沒人知道誰負責、也沒有結案概念。Unthread 的做法是保留 Slack 的低摩擦，但在背後生成有狀態、有負責人、有 SLA 的工單。使用者體感沒變，管理端才有東西可看。
自學型知識庫真的能用嗎？會不會寫進錯的答案？
會，所以一定要有審核關卡。實務上比較安全的設定是「自動草擬、人工核可」——系統從解決紀錄生成知識庫條目，但要有人按確認才會被 AI 引用。完全自動累積的話，一次錯誤解法會被無限複製。這個設定值務必在導入時問清楚。
40% 的自動解決率是不是太低？
我反而覺得這個數字比較誠實。服務台的工單裡有一大塊本質上需要人做決定——要不要批准這筆例外採購、這個權限該不該給。這些不是 AI 該自己拍板的事。所以四成自動化加六成輔助人類處理，聽起來比「七成全自動」更像真實運作的樣子。
使用者評價
還沒有足夠評價，搶先分享你的使用心得！
