一個人的客服與社群
本篇是「一個人做產品」系列的第 10 / 18 篇。你可以從系列總覽開始閱讀，也可以直接接著看本文。
凌晨三點的客服 Email：一個人怎麼撐住
你的產品上線一個月了，開始有穩定的用戶。某天凌晨三點，手機跳出一封信：
「你好，我剛付了年費，但登入後看不到進階功能，可以幫我處理嗎？急用。」
你翻個身，心想明天早上再回。但腦袋裡一直在想：「萬一他等不及直接退款怎麼辦？」結果四點半就醒了，五點半就爬起來處理。
這是每個 Solo Builder 都會遇到的轉折點：產品有人用是好事，但用戶的問題不會只在你方便的時候出現。
你不可能 24 小時盯著收件匣。你還有正職、有生活。但用戶的體驗不能因為你只有一個人就打折扣。
答案不是「更努力回覆」，而是建立一套系統，讓大部分問題不需要你親自回覆。
客服的真相：80% 的問題是重複的
在你急著找 AI chatbot 解決方案之前，先看看一個事實：
大多數產品的客服問題，80% 以上是重複的。
「怎麼重設密碼？」「怎麼取消訂閱？」「支援哪些付款方式？」「為什麼我的 XXX 不能用？」
這些問題反覆出現，每一次你都手動回覆同樣的內容。這是最沒效率的時間使用方式。
解決方案也很直觀：把這些重複問題的答案寫好，放在用戶找得到的地方。
聽起來很簡單。但大多數 Solo Builder 不是不知道要做，而是「沒時間做」。
2026 年，AI 改變了這件事。
第一道防線：自助式文件
你的第一優先不是裝 chatbot，而是寫出好的文件。
傳統做法
- 用戶問一個問題，你回一封信
- 同一個問題被問第三次，你想「我該寫個 FAQ」
- 但寫 FAQ 要時間，先回信再說
- 反覆循環，永遠沒有 FAQ
AI 加持做法
把你回覆過的客服信件和訊息餵給 AI，讓它幫你自動產生文件：
以下是我過去一個月回覆的客服訊息（已去除個資）：
[貼上 10-20 封典型的客服對話]
請幫我：
1. 把這些問題分類（帳號問題、付費問題、功能問題、bug 回報）
2. 每個分類列出最常見的前 3 個問題
3. 為每個問題撰寫一個標準回答，語氣友善、專業
4. 產生一個結構化的 FAQ 頁面，用 Markdown 格式15 分鐘，你就有了一個涵蓋最常見問題的 FAQ 頁面。
FAQ 的進階結構
一個好的 FAQ 不只是問答列表。它應該有層次：
| 層級 | 內容 | 目的 |
|---|---|---|
| 快速入門 | 5 分鐘上手指南 | 減少「怎麼開始」類問題 |
| 常見問題 | 分類的 Q&A | 解答 80% 的重複問題 |
| 操作指南 | 步驟式 how-to | 解答「怎麼做 XXX」類問題 |
| 疑難排解 | 已知問題 + 解法 | 減少 bug 回報信件 |
| 更新日誌 | 版本更新說明 | 減少「為什麼 XXX 變了」類問題 |
用 AI 從程式碼生成文件
這是更進階的技巧——讓 AI 直接從你的 codebase 生成使用者文件：
請閱讀以下 API 路由和元件程式碼，產生面向「非技術用戶」的操作說明。
[附上相關程式碼片段]
要求：
- 不出現任何技術術語
- 每個操作附上步驟編號
- 預期結果和常見錯誤情境都要涵蓋
- 繁體中文，語氣像在跟朋友解釋我在做 cloud-on-academy 時就用了這個方法——課程平台的操作說明幾乎全是 AI 從前端元件的程式碼生成的。我只需要做最後的語氣調整和截圖。
第二道防線：AI Chatbot
FAQ 解決了「願意自己找答案」的用戶。但有些人就是想直接問。
這時候 AI chatbot 就登場了。
2026 年的 AI 客服 chatbot
現在要做一個有用的 AI chatbot 已經不難了。核心概念是 RAG（Retrieval-Augmented Generation）——把你的 FAQ、文件、更新日誌餵給 AI，讓它根據這些內容回答用戶問題。
| 方案 | 適用場景 | 成本 | 設定難度 |
|---|---|---|---|
| Intercom Fin | 有預算的 SaaS 產品 | $0.99/次解答（每月最低 50 次解答，約 $49.5/月起；搭配 Intercom 自家 helpdesk 另計 $29/seat/月起） | 低 |
| Crisp + AI | 小型產品（Free 無 AI） | 免費（無 AI）/ 含 AI 自 $45/月起 | 低 |
| 自建 RAG | 想完全掌控的技術型創辦人 | API 費用 | 中高 |
| Cloudflare AI Gateway + Workers AI | 已用 Cloudflare 生態系 | 免費額度夠用 | 中 |
AI Chatbot 的限制：別過度期待
在你投入設定之前，先了解 AI chatbot 做不到什麼：
- 它不能處理帳號相關操作——重設密碼、退款、修改訂閱，這些需要後端操作的事情，chatbot 只能告訴用戶「請聯繫我們」
- 它偶爾會產生幻覺——回答看起來很合理但完全錯誤的資訊。一定要設定 fallback 機制
- 它不能替代「人的溫度」——當用戶真的很生氣或很困惑時，機器人的回覆反而會讓情緒更差
我的建議是：讓 chatbot 處理事實性問題，把情緒性問題留給你自己。
一個實用的 fallback 機制
chatbot 回覆流程：
1. 用戶提問
2. AI 根據知識庫回答
3. 回答結尾加上：「這有回答到你的問題嗎？」
4. 如果用戶選「沒有」→ 自動建立工單，通知你
5. 你每天花 15 分鐘處理這些「chatbot 回答不了」的問題關鍵是第 5 步：把 chatbot 回答不了的問題收集起來，定期加回知識庫。這樣 chatbot 的覆蓋率會越來越高，你的人工處理量會越來越少。
自動回覆模板：省下的 15 分鐘
就算沒有 chatbot，你也可以用自動回覆模板大幅減少回信時間。
建立模板庫
用 AI 幫你建立一組回覆模板：
我是一個 Solo Builder，產品是 [描述]。
以下是我最常收到的 10 類客服問題。
請為每一類問題撰寫一個回覆模板：
1. 密碼重設
2. 付款失敗
3. 功能建議
4. Bug 回報
5. 退款請求
6. 帳號刪除
7. 定價疑問
8. 批量授權
9. 合作邀請
10. 一般讚美（是的，也要有模板回覆感謝）
要求：
- 語氣溫暖但專業
- 每個模板有 [姓名] 和 [具體問題] 的佔位符
- 結尾都要有明確的下一步行動把這些模板存進你的 email client 或客服工具。下次收到類似問題，選模板、填空、送出。一封回信從 5 分鐘變成 30 秒。
客服 vs. 社群：它們不一樣
很多 Solo Builder 把「客服」和「社群」搞混了。
客服是被動的：用戶有問題來找你，你回答。 社群是主動的：用戶之間交流、互助、分享，你偶爾參與。
兩者都有價值，但運作方式完全不同。
| 客服 | 社群 | |
|---|---|---|
| 方向 | 用戶 → 你 | 用戶 ↔ 用戶（你在旁邊） |
| 目的 | 解決問題 | 建立歸屬感、收集回饋 |
| 你的時間 | 回覆問題 | 引導話題、營造氛圍 |
| 可自動化 | 高（FAQ、chatbot、模板） | 低（需要人味） |
| 優先級 | 必須做 | 看規模，可以晚一點做 |
什麼時候需要社群？
老實說：大多數 Solo Builder 在早期不需要社群。
社群經營是一件很花時間的事。如果你的用戶只有幾百人，一個公開的 feedback 表單 + email 就夠了。（怎麼把這些回饋系統化變成產品決策，見第 9 章：用戶回饋循環）
當以下信號出現時，再考慮建社群：
- 用戶開始在你不知道的地方討論你的產品（Reddit、Twitter）
- 用戶之間開始互相解答問題
- 你收到「有沒有交流的地方」的詢問
- 你的產品有「進階用法」值得分享
選擇社群平台
如果你決定要建社群，平台選擇很重要：
| 平台 | 適合 | 不適合 | Solo Builder 友善度 |
|---|---|---|---|
| GitHub Discussions | 開源專案、開發者社群 | 非技術用戶 | ⭐⭐⭐⭐⭐ |
| Discord | 遊戲、加密貨幣、技術社群 | 年齡層偏高的用戶 | ⭐⭐⭐ |
| Telegram | 亞洲市場、即時交流 | 需要結構化討論 | ⭐⭐⭐⭐ |
| LINE 社群 | 台灣市場、非技術用戶 | 國際化產品 | ⭐⭐⭐ |
我的建議：開發者產品用 GitHub Discussions，其他用 Telegram 或 Discord。
原因是：GitHub Discussions 的對話是公開、可搜尋、有結構的。用戶的問題會自動變成你的 FAQ 素材。而且 GitHub Discussions 幾乎不需要管理——社群成員會自己維護討論品質。
什麼時候親自回覆 vs. 讓自動化處理
這是 Solo Builder 最需要判斷的地方。
必須親自回覆
- 付費用戶的退款或不滿：這些互動決定了用戶是否留下來，不能假手機器
- 產品方向的深度回饋：當用戶花時間寫了一大段建議，他值得一個有溫度的回應
- 第一批用戶：前 50 個用戶的每一個問題都值得你親自看，因為他們代表的是你最核心的使用場景
- 情緒化的訊息：用戶在生氣的時候，chatbot 只會讓情況更糟
可以自動化
- 功能確認（「你們支不支援 XXX？」）
- 操作步驟（「怎麼做 XXX？」）
- 已知問題的解決方案
- 一般性的感謝回覆
- 合作邀請的初步篩選
黃金比例
以我的經驗，一個運作良好的系統大概是：
- 70% 的問題被 FAQ + chatbot 解決，用戶自己找到答案
- 20% 的問題用模板回覆，你花 30 秒調整後送出
- 10% 的問題需要你認真寫一封回信
如果你的比例是反過來的——70% 需要手動回覆——那代表你的文件不夠好，該回去補了。
管理期望：一個人的 SLA
Solo Builder 最怕的不是「回覆太慢」，而是「用戶以為你應該秒回」。
解法很簡單：在所有會接觸用戶的地方，寫清楚你的回覆時間。
在你的網站 footer、聯絡頁面、自動回覆信件裡加上：
客服回覆時間：工作日 24 小時內回覆。週末和假日可能會延遲。 緊急問題（無法登入、付款失敗）優先處理。
這不是敷衍。這是尊重用戶的時間，也尊重你自己的時間。
當用戶知道預期的等待時間，他們的焦慮會大幅降低。「24 小時內回覆」聽起來不快，但如果你每次都在 12 小時內回覆，用戶的感受反而是「超出預期」。
反過來，如果你什麼都不說，用戶會預設你「應該馬上回」，然後在兩小時後開始焦慮、四小時後開始生氣。
時間預算：每天 30 分鐘
最後，最重要的事：給客服一個時間上限。
我的建議是每天 30 分鐘，分兩次：
| 時段 | 做什麼 | 時間 |
|---|---|---|
| 早上（上班前） | 掃一眼有沒有緊急問題，處理付費用戶的問題 | 10 分鐘 |
| 晚上（下班後） | 處理其他問題、更新 FAQ、調整 chatbot | 20 分鐘 |
不要一直開著 email 和通知。 批次處理永遠比即時回覆有效率。
如果某一天的客服問題超過 30 分鐘能處理的量，代表兩件事：
- 你的產品可能出了 bug（大量用戶同時遇到同一個問題）
- 你的文件不夠完善（同一個問題被反覆問）
兩者都不是靠「花更多時間回覆」能解決的。解法是修 bug 或補文件。
本章重點回顧
- 🛡️ 第一道防線是自助式文件，不是 chatbot——用 AI 從客服紀錄自動產生 FAQ
- 🤖 AI chatbot 適合處理事實性問題，情緒性問題留給你自己回覆
- 📋 建立回覆模板庫，讓一封回信從 5 分鐘變成 30 秒
- 🏘️ 客服和社群是兩件不同的事——早期先把客服做好，社群可以晚一點
- ⏰ 每天 30 分鐘是客服時間上限——超過代表文件不夠好或產品有 bug
- 📢 在所有地方寫清楚回覆時間，管理用戶期望比加快回覆更重要
下一步
客服系統搞定了，但有一件事比客服更讓 Solo Builder 焦慮：產品掛了怎麼辦？
你不可能 24 小時盯著 server。但你的用戶期待產品 24 小時都能用。
下一章，我們來建立一套最小化但有效的監控和維運系統——讓你安心睡覺，產品出問題時自己會修自己。
