你有幾個 LINE OA，就有幾倍的混線風險——一個食品業經銷案的完整紀錄

問題是什麼：三個帳號，一個客服，沒有人知道誰在跟誰說話

這家食品飲料經銷商有多個 LINE 官方帳號（OA）——不同品牌、不同通路，各自對應不同的客戶群。

但客服是同一組人。

他們每天在幾個帳號之間切換，靠記憶判斷「這個客人是哪個 OA 的」，靠默契決定「誰在回這個人」。沒有鎖定機制，沒有歷史紀錄，沒有任何辦法確認訊息有沒有用錯帳號發出去。

最壞的情況：客人在 A 品牌的 LINE 問了問題，客服用 B 品牌的帳號回覆。客人看到一個陌生名字，整個信任斷掉。

這不是偶發的疏失，是這種客服架構結構性的缺陷。

怎麼開始：先做出 PoC，再談合約

這個案子透過 Facebook 程式外包社團找到我。對方貼了需求，我去 DM 提案。

她問了一連串我沒料到的問題：

你的開發團隊幾個人？
用什麼技術棧？
有沒有同類型的上線案例？

我沒有。我是獨立工程師，沒有團隊，也沒有多 LINE OA 收件匣的上線案例。

我沒有試圖包裝，而是直說：「我是獨立工程師，你說的需求我看過，技術上沒問題，但上線案例沒有。如果你需要在簽約前確認技術可行，我可以先做一個 PoC——用你實際的需求驗證核心難點，這樣你有根據判斷，我也有機會展示能力。」

她接受了。

PoC 要驗證的核心難點：兩個不同的 LINE OA，訊息能不能進同一個收件匣，客服回覆時能不能保證走回正確的 OA，完全不混線。

第一天：PoC 從零到部署

當時我對 LINE Messaging API 幾乎是零基礎。

從查文件、建 LINE developer console、到第一個 webhook 接到訊息，花了大概三個小時。接下來六小時是核心架構：

每個 LINE OA 有自己的 /webhook/:channelId 路由，訊息進來就知道是哪個 OA 傳的
DB 設計：一個 thread = 一個 (channel_id, line_user_id) 組合。同一個用戶傳給 OA-A 和 OA-B，一定是兩個不同的 thread，永遠不會合併
發送回覆時，系統從 DB 推導要用哪個 OA 的 token，前端完全碰不到任何 token 或 channel 資訊

第一天結束，PoC 部署上線，兩個測試 OA 串到同一個收件匣，用手機親自測試確認不混線。

第二天：她提出了三組驗收標準，當天全部完成

第二天早上，她回覆了。不只是「OK 沒問題」，而是一份結構化的驗收清單：

A 組：防混線與資料約束

Thread 唯一性必須有 DB constraint，不能只靠應用層邏輯
多坐席鎖定：同一對話不能有兩個客服同時在回
Webhook 去重：LINE 偶爾會重送事件，重複訊息不能進 DB

B 組：營運必備

對話可以結案，結案後 LINE 再來訊息自動重開
每個操作都要有稽核紀錄（誰、幾點、做了什麼）
要能匯出 CSV，Excel 開起來中文不亂碼

C 組：資安與部署

Token 和 Secret 不能出現在 Git repo
系統要有 health check，讓她知道服務是不是活的

看到這份清單我知道她是認真的。這種有結構的驗收標準，不是「感覺上線了就算」的態度。

整個第二天拿來做這三組需求。技術上最難的是鎖定機制——五分鐘超時、前端不算時間（只信 server）、被搶鎖時 UI 即時更新——這個部分前後修了五輪 bug 才穩定。

最終交出：12 個 API endpoints、完整稽核日誌、多坐席鎖定、CSV 匯出（含 BOM 解決 Excel 中文問題）、Fly.io 部署、GitHub private repo 移交。

第二天結束，她的回覆是：「驗證通過，請出 Phase 1 里程碑報價。」

兩天，總結三件事

第一件：PoC 不是免費試工，是雙方篩選的機制

PoC 讓她在花大錢之前確認你做得到，也讓你確認對方是不是能給出清晰需求的合作對象。她的驗收標準就是最好的證明——這種客戶，你願意花時間做 PoC。

第二件：防混線的真正保障在 DB constraint，不在應用邏輯

UNIQUE(channel_id, line_user_id) 這個 DB constraint，是整個系統的最後防線。就算應用層出 bug，就算前端傳錯參數，DB 層會拒絕一切混線資料。如果這個 constraint 不存在，你只是在靠運氣。

第三件：多坐席搶話的問題，在幾乎所有客服系統都被低估

你以為的問題：「客服分不清誰在哪個 OA 回話」。

真正的問題：「同一個客人，兩個客服同時在回，訊息互相打架，客人以為公司有兩個人在同時處理她的問題」。

鎖定機制不是好看的功能，是防止這個場景的實際工程。

如果你也有多個 LINE OA

常見的觸發點：

你有一個以上的 LINE 官方帳號（不同品牌、通路、或部門）
客服靠「大家都記得用哪個帳號回」維持秩序
偶爾懷疑有沒有訊息被漏掉或跳號

如果這三點有一點符合，統一收件匣是值得認真評估的方向。不一定需要 AI，核心是讓所有訊息流進一個地方、讓每個操作都有記錄、讓坐席之間不要搶話。

如果你想知道這對你的規模和業務有沒有意義，可以直接加這個網站的 LINE，說你的現況，我會告訴你值不值得做、大概要花多少時間和錢。沒有簡報，不賣套裝方案，先確認問題再討論解法。