那塊名為客服的木板，是怎麼被貫穿的？
在我的 PM 職涯中，客服是從第一天到現在都持續在面對的問題。客服有時候很簡單，就只是快速回答一些我再清楚不過（甚至存在模板）的問題；也有時候很難，像無數場上演在對話視窗裡的迷你通靈儀式，得努力在客戶的耐心用完以前，從極其有限的資訊裡推測他們真正想解決的問題。
客服不一定只存在於客服系統的聊天室裡，可能還發生在社群上（有些人就是喜歡對不特定多數人發表問題）、我跟客戶的 Line 群裡、我個人跟合作夥伴的聊天室（可能還參雜我們的私人閒聊）、某場工作上的社交活動（來自某個迎面而來的陌生人）。這些人都沒有義務搞懂我們的產品在幹嘛，所以他們提供的資訊也不太可能有多清楚。然後然後，有些問題得交給工程師處理，我壓了死線，但他們真的一定能如期完成嗎？有沒有可能我給的資訊不夠詳細、中間發生意想不到的狀況，或者就是忘了？
要我說的話，處理客服就是在跟一大團模糊的資訊打交道，然後試著在火燒屁股以前理出頭緒，還要同時做好期待管理。所以，打打字傳訊息很簡單，處理好客服很難。
我從今年一月底開始玩 Claude Code，到現在接近兩個月的時間，幾乎每天都在端出不同的實驗品來改造我和我同事們的工作流程，非常好玩。客服毫無疑問屬於改變最多的部份之一，從每天可能要花掉整個上午、痛苦又暴躁的工作項目，壓縮到有可能在 15 分鐘內邊沖咖啡邊優雅的解決。
背景：我在 Podcast Hosting 公司 Firstory 擔任 PM，最主要服務的對象包括 Podcast 創作者、他們的聽眾（包括付費訂閱的會員）。
以下說明客服這項任務在我們團隊的演化歷程，以及開始使用 Claude Code 以後我的嘗試。
Phase 1：純人工處理
建立客服流程的第一階段，毫無取巧可言。逐個回答客戶的問題，搞清楚他們最常遇到什麼狀況。
Phase 2：建立幫助中心
發現很多問題會被重複詢問後，開始可以建立幫助中心，用文章詳細說明客戶遇到的狀況該怎麽解決，順便把文章的連結也放到產品裡。這個階段最常做的事情是跟客戶說：「可以參考這篇文章唷。」
Phase 3：建立內部客服 SOP
客服量增加，業務也變複雜，客服沒辦法只有一個人處理，也有一些未必適合寫在公開文件上的流程要維護（例如帳務相關），所以撰寫了複雜的文件，確保每個人是用同樣的原則在處理客服。不過文件的問題始終都是：沒空讀、沒空寫、沒空更新。
Phase 4：建立客服後台（Daemon）
客服會收到要轉給工程師的問題分成三類，第一類屬於 bug 或產品要調整，應該直接讓 PM 開需求處理，第二類是需要查詢資料（例如檢查某個使用者的方案狀態）或進一步檢查的問題，第三類是一些未必適合做成功能開放給使用者的操作（例如退款）。第二跟第三類都有一些常態要請工程師處理的重複問題，最後決定把這類重複操作封裝成功能做進一個內部使用的後台。顯而易見的好處是不用等工程師處理，速度加快非常多。
Phase 5：引進 Intercom Fin AI
去年發現 Heptabase 在用 Intercom 內建的 Fin AI 處理客服，而且看起來效果不錯，就開來用用看。持平的說，因為可以讀取整個幫助中心跟官網作為資訊來源，Fin 回答的品質還可以，不過從結果而言，在「所有 Fin 介入的客服」當中（很多用戶還是選擇由真人客服回答），只有 60% 由 Fin 獨立完成，而且都是比較簡單的案件，沒辦法處理那種需要查詢的案件。除此之外，要持續在 Intercom 的系統裡給 AI 回饋來改進回覆也很繁瑣。
Phase 7：引進 Claude Code，接上 Intercom MCP
開始使用 Claude Code。這個階段做了很多不同嘗試：
- 試著把處理客服常用的小工具解析原理並且做成 Skill，例如可以透過 Podcast 連結反查 RSS Feed 的「GetRSSFeed」就被我封裝成了「claude-plugin-podcast-rss」。
- 串接 Intercom 官方 MCP，發現可供使用的工具非常有限，決定直接根據官方 API 設計自己用的 Intercom MCP，可以做到兩件事：根據新功能的 PRD 自動生成多語言版本的幫助中心文章，不用再手寫，以及最重要的，直接在 Claude Code 讀取並回覆客服。
- 延續前面的成果，設計了讓 Claude Code，處理客服的 Skill，基於原有的 SOP，規範 AI 回覆客服的準則（語氣、要去哪裡取得資訊等等），還有若我判定需要轉給工程師處理，需要整理哪些資訊並在專案管理工具 ClickUp 上自動建立任務。
- 設計了「line-desktop-skill」，直接讀取我跟客戶的 Line 訊息整理待辦事項，省下我自己手動做的時間。
到此為止，處理客服基本上已經變成我可以一早起來跟 Claude Code 說「幫我看 open 的客服並草擬回覆」就跑去沖咖啡，回來再請他微調就能搞定 90% 的任務。初期品質可能沒有 Fin AI 好，但因為調整起來相對簡單，我體感很快就已經比 Fin AI 好用了。
Phase 8：接上 Daemon MCP
這個階段的課題是：「有沒有可能讓 AI 進一步接手需要查詢的複雜案件？」Phase 6 & 7 AI 無法處理的問題，最後都會由人工接手在 Daemon 或其他地方查詢，但沒道理 AI 在「查資料」這方面會輸給人類。考慮到 Daemon 上的各種功能都已經有 API 可以使用，直接請 Claude Code 分析 codebase，就成功把整個 Daemon 裡所有「不危險」的功能（例如查詢）封裝成 AI 可使用的 MCP 工具。此時 Claude Code 在處理客服時能夠取得的資訊已經超越了 Fin AI。至於比較「危險」的操作，例如退款、刪除等等，暫時還是留給人類處理。
韋伯在〈政治作為一種志業〉裡這麼說道：「政治，是一種並施熱情和判斷力，去出勁而緩慢地穿透硬木板的工作。」在 AI 的協助下，我感覺到那塊名為客服的木板已經幾乎被貫穿了。Vibe Coding 容易帶給使用者一種「我無所不能」的錯覺。但我不認為單獨依靠 Claude Code 就能神奇的完成一切，是幾年來各式各樣嘗試所積累下來的知識、小工具，最終成就了這個進展。
一切迷航皆有意義。謹以本文記錄我的探索。