Cowork 每朝分流客服 inbox：緊急 / FAQ / 投訴自動分類，順手起好回覆

情境

你開緊間 HK SME，可能係 e-commerce、可能係教育中心、可能係 SaaS。每朝 9 點開 inbox，見到 40 個 ticket 喺度：

• 一半係重覆嘅 FAQ（「你哋幾點開？」「點計運費？」「可唔可以改地址？」）
• 三成係真係要你睇嘅查詢（產品規格、訂造訂單）
• 兩成係投訴或者退款要求（嬲緊嗰啲）
• 中間夾住兩三個緊急（已經買咗單，今日要到貨嗰啲）

問題唔係單一條 ticket 難覆，而係你要花 30 分鐘揀邊條先答。心理成本仲貴過實際打字。

Cowork 嘅角色：每朝 8:30am 自動跑一次，幫你分晒類、起好 FAQ 嗰批回覆，9 點你開 inbox 已經有個整齊嘅 dashboard，睇一眼就 send 得。

一句提提你：Cowork 仲係 research preview，要 Pro/Max plan。佢會直接讀你嘅 inbox，第一次跑一定要預演，唔好畀佢自動 send。

跟住做

1. 先準備兩份文件：知識庫 + 品牌語氣 doc

呢一步只做一次，但係成個系統嘅靈魂。冇呢兩份嘢，Cowork 起稿出嚟嘅嘢會好空泛，似個 chatbot。

開兩個 .md / .txt 檔，擺喺一個專用 folder（例如 ~/cowork-support/）：

• faq.md — 列出你最常收嗰 15-20 條問題同標準答案。包括：營業時間、運費、退換貨政策、付款方式、出貨時間、改地址流程等等。
• voice.md — 描述你品牌嘅語氣。例：「廣東話書面語混合、用『你』唔用『您』、句尾偶然用『啦』『喎』、唔好硬銷、有問題先安撫情緒再解釋」。

2. 核心分流 + 起草 prompt

開 Claude Desktop → Cowork mode → 指住個 folder。一次過畀佢成個 prompt。

我係 [你嘅店 / 公司 名] 嘅客服。每朝 8:30am 請你幫我做以下嘢：
連去我嘅客服 inbox（Zendesk / Help Scout / Gmail label「客服」），讀晒過去 24 小時嘅未回覆 ticket
讀埋 faq.md 同 voice.md，呢兩份係你嘅參考
將每張 ticket 分做以下三類：

URGENT：客戶已付款 / 已下單，今日內要回應（例如：已出貨但未到、約咗今日交收、約咗 demo）
FAQ-answerable：問題喺 faq.md 入面有得答嘅
COMPLAINT / NEEDS-HUMAN：投訴、退款、訂造要求、情緒激動、或者 FAQ 答唔到嘅


對 FAQ-answerable 嗰批，每張 ticket 起草一個回覆：

跟 voice.md 嘅語氣
引用 faq.md 嘅事實答案，唔好作
喺需要我核實嘅地方留個 [需店主 confirm] 標記


出一份 markdown report，subject「[Date] 客服 triage」，內容分三 section：URGENT / FAQ drafted / Complaint queue
注意：
唔好自動 send 任何嘢
URGENT 嗰批唔使起草，淨係標出嚟畀我即刻睇
COMPLAINT 嗰批淨係列出 customer、ticket subject、初步情緒（嬲 / 失望 / 投訴 / 退款）——等我自己處理
報告 email 寄返畀我
設定好之後 confirm，schedule 落每朝 8:30am 自動跑。

3. 三層輸出格式（呢度係核心）

你想 Cowork 出嘅報告長成噉：

URGENT (3)

• 陳小姐 #4521 — 「今日 3pm 約咗到貨點解未收到」（已出貨 2 日）
• Ken #4533 — 「demo 預咗 10am 你哋邊個 join？」
• 林太 #4540 — 「FedEx tracking number 唔 work」

FAQ DRAFTED (12) （每張 ticket 一個收合區，撳開入去見草擬好嘅回覆）

COMPLAINT / NEEDS-HUMAN (5)

• Annie #4519 — 退款 request，sentiment：失望
• …

呢個格式嘅關鍵：URGENT 一定要喺最上，因為你 9am 開 inbox 第一眼要見。FAQ 嗰批係「一次過批量處理」嗰啲，complaint 就係「慢工出細貨」嗰啲。

4. 每朝睇一眼就 send 嘅習慣 + 升級處理 playbook

9:00am 你坐低：

1. 5 分鐘處理 URGENT — 即刻覆，呢啲冇得夾埋一齊做
2. 15 分鐘掃一掃 FAQ 草擬嗰批 — 每張 ticket 撳 send（或者改少少先 send）。Claude 草擬嘅嘢七成可以原文用，三成要微調
3. 20 分鐘處理 complaint queue — 呢啲先係你真正嘅工，要諗、要打電話、要向上升級

第一個禮拜你會發現 Claude 嘅 FAQ 分類大概有 10% 出錯（例如將投訴當咗 FAQ）。每次出錯你喺 faq.md 入面加多句「以下情況唔屬於 FAQ：客戶用咗『投訴』『嬲』『退錢』等字眼」，準確度會升。

變化例子

變化 1：WhatsApp Business 版

如果你個客服主要喺 WhatsApp 而唔係 email，先用 WhatsApp 客戶回覆模板 嗰個方法設定好 quick reply 模板，再駁 Cowork 入嚟：

（同主 prompt 一樣，但輸入來源改成）：
連去我嘅 WhatsApp Business（透過 Meta Business Suite 匯出，或者我每朝會將過去 24 小時嘅未覆訊息匯出做 .csv 擺入呢個 folder）
將每段對話分 URGENT / FAQ / COMPLAINT
對 FAQ 嗰批，草擬嘅回覆要：

短（WhatsApp 文化，唔好寫到好似封 email 咁）
對應返我 WhatsApp Business quick reply 嘅 short code（例如 /有貨 /運費），如果配對到就直接喺草稿入面寫「建議用 short code: /有貨」


報告同上

變化 2：雙語（中英）客服版

HK 客戶經常中英混合，甚至同一張 ticket 上半段中文下半段英文。

（同主 prompt 一樣，但加多兩條）：
對每張 ticket 額外標一個 language tag：zh / en / mixed
草擬回覆嘅語言要對應客人嗰封 ticket：客人寫中文你寫中文，客人寫英文你寫英文，客人中英夾雜你都中英夾雜
voice.md 入面要包括埋英文版嘅品牌語氣描述（例如：「friendly but professional, no exclamation marks, sign off with 'Cheers'」）
如果客人嘅英文唔太啱文法，唔好跟住佢錯，用順暢嘅英文回覆，但唔好太拘謹。

變化 3：Complaint sentiment score 模式

對 complaint queue 加多層分析，幫你決定先處理邊個：

對 COMPLAINT / NEEDS-HUMAN 嗰批，每張 ticket 加埋：
Sentiment score：1-5（1 = 輕度不滿，5 = 已經話要去消委會 / Small Claims）
Risk flag：如果出現「消委會」「投訴」「律師」「Trustpilot」「Google review」等關鍵字，加紅色 ⚠️
建議優先次序：5 分 + risk flag 嗰啲排最前
唔好草擬回覆——投訴嘅回應要我親自諗，幫我草擬反而會誤導我
排序：risk-flagged → score 5 → score 4 → 其餘

拆解：點解會 work，同點解會爆

跟到上面就已經用得。下面呢段係畀**想由「今朝跑靚仔」做到「跑足半年都信得過」**嘅人——初學者可以跳過，唔影響你跟住做。

自動化客服最唔老實嘅地方係：第一朝 triage 報告出嚟好靚，唔代表第三十朝都係咁。呢個流程，實際上會喺呢幾個位爆：

1. 「過去 24 小時」視窗會靜默漏單 Cowork 每朝讀「過去 24 小時」，但如果某日跑漏咗、延遲咗、或者你個 inbox 連線短暫斷咗，下次跑嘅時候視窗唔會自動補返。中間嗰批 ticket 就靜靜雞消失咗，唔係 URGENT 就係 COMPLAINT，你根本唔知。

• 會爆成點：有投訴 ticket 喺 queue 消失，客戶等咗幾日冇人理，去 Google 留一星。
• 點救：prompt 加多一句「如果讀到嘅 ticket 數量係零或者少於平時，請標出警告，唔好靜靜雞出空報告」；或者另外做一個定期比對：用 Zendesk / Help Scout 嘅「全部 open tickets」count 對下每日報告嘅總數有冇出入。

2. 投訴被錯分做 FAQ——最高風險嘅假陽性 文章講過 Claude 分類會有 10% 出錯，但最危險嗰種唔係「FAQ 被分去 COMPLAINT」，係反過來：有情緒嘅客人用咗平靜語氣問問題（「唔知係咪可以 refund 呀⋯⋯」），Claude 當佢係普通 FAQ，幫佢草擬咗一封標準運費答案。你掃一眼就 send 出去，然後爆發二次投訴。

• 會爆成點：客戶收到完全唔對題嘅 FAQ 回覆，嬲上加嬲，直接上 Trustpilot。
• 點救：喺 faq.md 加一個「升級關鍵字清單」：「唔開心」「好失望」「唔係咁講」「你哋係咁㗎？」「我唔想要」「退」「換」「唔對」——出現任何一個，不論問題係咪 FAQ，一律分去 COMPLAINT。寧願多標，唔好錯標。

3. inbox 授權過期：Cowork 以為跑咗，其實讀唔到嘢 Cowork 連 Gmail 或者 Zendesk 用嘅係 OAuth token，呢類 token 會無聲無息過期（尤其 Google Workspace，管理員有時會撤銷第三方應用授權）。Cowork 唔一定會報錯——佢可能出一份「0 tickets」嘅空報告，或者靜靜雞唔跑。

• 會爆成點：你以為每朝都有分流，但其實 inbox 塞咗三日都冇人知，直至客戶打電話入嚟。
• 點救：prompt 明寫「如果連 inbox 失敗或者讀到嘅 ticket 係零，第一行寫『⚠️ 連線異常，請手動核查』」；另外每週一自己開一次 inbox 對下 open ticket 數量同報告係咪相符。

4. faq.md 有漏洞，Claude 自己填——填錯就 send 出去 Claude 唔會在乎 faq.md 係咪真係有答案——佢見到問題，見到相近嘅資料，就會「補充」。你個 faq.md 寫「出貨 2-3 日」，但有個 ticket 問「急單可唔可以 next day？」，Claude 可能自行草擬「係，可以！」——因為佢理解「2-3 日」係一般情況，急單係另一回事，但唔知你有冇急單服務。

• 會爆成點：草擬嘅答案有你冇提供嘅承諾，客戶 screenshot 留底，你被迫 honor 一個你根本冇嘅服務。
• 點救：prompt 加硬規則「faq.md 入面搵唔到明確答案，唔好推斷，唔好估，直接喺草稿寫『[需店主 confirm]——呢條問題我嘅 FAQ 冇涵蓋』」；同時 faq.md 本身加一個 section「呢啲我哋冇提供」。

5. URGENT 靠客戶自己表達——但客戶唔會照你預想打 你個 prompt 嘅 URGENT 定義係「已付款 / 已下單，今日內要回應」，但客戶唔會話畀你聽「我已出過單」——佢只會寫「點解仲未到？？」或者「我而家喺度等緊㗎」。冇 order number、冇付款記錄，Claude 分唔到呢啲係 URGENT 定係普通查詢。

• 會爆成點：真正需要緊急處理嘅 ticket 被分去 FAQ 或者 COMPLAINT queue，你九點半先睇到，已經遲咗。
• 點救：URGENT 嘅判斷標準要加埋語氣 signal：「而家」「仲未」「等緊」「幾點到」「今日」「我喺到」「唔見」——任何一個加上過去時態嘅動作（「買咗」「付咗」「約咗」），就升做 URGENT 候選，等你確認。寧願假 URGENT 多啲，真 URGENT 一個都唔好漏。

呢幾個位，就係「第一朝 triage 靚靚」同「跑足半年、inbox 零投訴漏單」之間嘅距離。

一個香港客服特有嘅提醒

香港消委會嘅投訴生態同其他市場唔同：客人有時會喺 ticket 入面直接引條例或者話要去消委會投訴。呢類 ticket Claude 認唔認得到，完全睇你 faq.md 入面有冇教佢。

最起碼喺 faq.md 寫一段：「以下字眼出現就一定當 COMPLAINT、score 5、risk-flag：消委會、Consumer Council、Small Claims、Trustpilot、Google review、投訴信、律師信」。呢句一加，Claude 對香港客服場景嘅敏感度即刻上一級。

Cowork 唔係幫你全自動回覆客戶——係幫你將早上嗰 30 分鐘分流時間，壓縮做 5 分鐘睇一眼。剩返嗰 25 分鐘，留返畀真正要動腦嘅 ticket。