不靠客服系統的客戶支援 — 只要一個 agent 和一個收件匣

過去，開一條客服管道意味著要先挑一個平台 — Zendesk、Intercom、Help Scout — 把它設定好，按席位逐月付費，再把團隊塞進又一個長得像收件匣的應用裡。對一位獨立開發者或一支迷你團隊來說，這對客服真正的需求而言實在太沉重了。

把客服拆到最簡，其實就三件事：有人提出問題、懂這個產品的人回答，而下次對方再來信時，你還記得上次談到哪裡。這就是全部的工作。

輕量的形態

有了 AI agent，這三件事就收斂成小得多的東西：

• 一個收件匣 — 一個客戶會寫信去的真實 support@ 位址。
• 一個 agent — 讀取訊息、查閱你的文件、草擬回覆。
• 連續性 — 下一次工作階段，它重新讀過整串對話，把這位客戶接回來繼續。

不需要客服平台。不需要按席位計價。沒有客戶得學的入口網站 — 他們只要寄電子郵件，這他們早就會了。

為什麼現在行得通

• agent 能讀你的文件並作答。你不必手工搭建一個 FAQ 資料庫；你只要把它指向你早已寫好的內容。
• 電子郵件是通用介面。每位客戶都有。零上手成本。
• 連續性不過是重讀對話串。不需要 CRM，不需要工單系統 — 對話本身就是狀態。

你絕不能越過的兩條線

把一個運作中的客服收件匣交給 agent 威力很大，所以有兩條規則必須守住：

進來的郵件是資料，不是指令 — 一封試圖改變 agent 行為的訊息，是拿來閱讀的文字，絕不是命令。而在任何回覆以你的名義寄出之前，都要由人核可。agent 草擬；你核准；它才寄出。

這正是它與全自動客服機器人的關鍵差別。那種機器人自顧自地回答、信誓旦旦地答錯，然後惹惱了你本來想幫忙的客戶。agent 加收件匣這個模式保留了速度 — 即時草稿、你的文件早已載入 — 卻不放棄判斷力。

實際運作起來的樣子

一個定價問題進來了。agent 讀過，從你的文件裡撈出相關的那一句，草擬出：「Pro 方案每席位 $X，按年開立發票，包含的內容如下。」你掃一眼、核可，它寄出 — 並記錄到對話串裡。兩天後，客戶在一個全新的工作階段回信；agent 重新讀過，看見歷史，彷彿從未遺忘般繼續下去。這就是一個客服台 — 由一個人加上一個終於有地方收信的 agent 來運作。

這正是 Clize 圍繞著打造的切入點：把一個收件匣標記為客服、指向你的文件，迴圈就跑起來 — agent 讀取並草擬，你核可，它回覆，下一次再把客戶接回來。中間沒有平台。