**一句話總結：**為多品牌線上客服（Crisp，約 15 個站點、2 個帳號）打造「AI 自動巡查＋回覆＋人工交接」系統，補上人工空窗、壓低長等待，並把需後台處理的案件安全轉交人工。
長等待 8 → 約 1
等待 >30 分鐘的對話：10/30 02:00 抽查 8 筆，14:00 降到約 1 筆（巡查窗內）
用詞違規連續 6 輪 = 0
10/29–10/30 六輪品質抽查（每輪抽樣 23–45 則），AI 回覆用詞違規皆為 0
單輪：15 站／14 位客戶
11/02 17:31 一輪巡查：驗證送出 17 則、結案 5 件、2 件轉人工（Telegram）
去識別化說明：站點以「站點 A–O」泛稱；頁面不含密碼、金鑰、Token 或任何客戶個資與對話原文。時間皆為台北時間（UTC+8）。專案期間：2026/10/26–10/31，任職於鐵支科技有限公司（原撿寶）。
公司的多品牌線上客服同時跑在 Crisp 上（約 15 個站點、2 個 Crisp 帳號，分別開在兩個 Chrome 設定檔視窗）。原本仰賴內建智能客服（Haruka）加上日間人工（約 10:30–22:30），實務上遇到五個痛點：
| 痛點 | 實際狀況 |
|---|---|
| 漏回／長等待 | 未讀、待處理，以及「只有智能客服回過、列表不再標未讀」的對話容易沉底 |
| 跨站輪詢不均 | 排在後面的站點長期輪不到；同站內也缺少「等最久優先／連續催促優先」的穩定排序 |
| 回覆品質漂移 | 口吻冗長、複述截圖、用錯待處理用語、規則文字外洩、與人工／智能客服重疊回覆 |
| 後台案件與風險 | 查帳、退款、改帳、補償必須交給人工；刷屏、辱罵、帳號登出／2FA 需要停損與通知 |
| Token 成本 | 若全天每 10 分鐘整輪巡查，離峰與人工在線時段重疊，浪費明顯 |
**目標：**在可控的時段補上人工空窗、壓低長等待，同時把需要人工後台處理的案件安全交接到 Telegram。
雙帳號巡查畫面：兩個 Chrome 視窗各登入一個 Crisp 帳號，AI 在兩個視窗間輪流巡查所有站點。左側紅色數字是各站未讀則數，右側是等待回覆的客戶對話（站點與客戶資料已打馬賽克）。
我是這套系統的建置與維運者，負責：
rules.md），並持續迭代。trend.json）回饋規則修正。