[{"data":1,"prerenderedAt":268},["ShallowReactive",2],{"blog-\u002Fblog\u002Fline-bot-consulting-case-study":3},{"id":4,"title":5,"body":6,"date":255,"description":256,"extension":257,"meta":258,"navigation":259,"path":260,"seo":261,"stem":262,"tags":263,"__hash__":267},"blog\u002Fblog\u002Fline-bot-consulting-case-study.md","你有幾個 LINE OA，就有幾倍的混線風險——一個食品業經銷案的完整紀錄",{"type":7,"value":8,"toc":245},"minimark",[9,14,18,21,24,27,30,33,37,40,43,56,59,62,65,72,74,78,81,84,104,107,109,113,116,121,132,137,148,153,161,164,167,170,176,178,182,187,190,195,201,206,209,212,215,217,221,224,235,242],[10,11,13],"h2",{"id":12},"問題是什麼三個帳號一個客服沒有人知道誰在跟誰說話","問題是什麼：三個帳號，一個客服，沒有人知道誰在跟誰說話",[15,16,17],"p",{},"這家食品飲料經銷商有多個 LINE 官方帳號（OA）——不同品牌、不同通路，各自對應不同的客戶群。",[15,19,20],{},"但客服是同一組人。",[15,22,23],{},"他們每天在幾個帳號之間切換，靠記憶判斷「這個客人是哪個 OA 的」，靠默契決定「誰在回這個人」。沒有鎖定機制，沒有歷史紀錄，沒有任何辦法確認訊息有沒有用錯帳號發出去。",[15,25,26],{},"最壞的情況：客人在 A 品牌的 LINE 問了問題，客服用 B 品牌的帳號回覆。客人看到一個陌生名字，整個信任斷掉。",[15,28,29],{},"這不是偶發的疏失，是這種客服架構結構性的缺陷。",[31,32],"hr",{},[10,34,36],{"id":35},"怎麼開始先做出-poc再談合約","怎麼開始：先做出 PoC，再談合約",[15,38,39],{},"這個案子透過 Facebook 程式外包社團找到我。對方貼了需求，我去 DM 提案。",[15,41,42],{},"她問了一連串我沒料到的問題：",[44,45,46,50,53],"ul",{},[47,48,49],"li",{},"你的開發團隊幾個人？",[47,51,52],{},"用什麼技術棧？",[47,54,55],{},"有沒有同類型的上線案例？",[15,57,58],{},"我沒有。我是獨立工程師，沒有團隊，也沒有多 LINE OA 收件匣的上線案例。",[15,60,61],{},"我沒有試圖包裝，而是直說：「我是獨立工程師，你說的需求我看過，技術上沒問題，但上線案例沒有。如果你需要在簽約前確認技術可行，我可以先做一個 PoC——用你實際的需求驗證核心難點，這樣你有根據判斷，我也有機會展示能力。」",[15,63,64],{},"她接受了。",[15,66,67,71],{},[68,69,70],"strong",{},"PoC 要驗證的核心難點","：兩個不同的 LINE OA，訊息能不能進同一個收件匣，客服回覆時能不能保證走回正確的 OA，完全不混線。",[31,73],{},[10,75,77],{"id":76},"第一天poc-從零到部署","第一天：PoC 從零到部署",[15,79,80],{},"當時我對 LINE Messaging API 幾乎是零基礎。",[15,82,83],{},"從查文件、建 LINE developer console、到第一個 webhook 接到訊息，花了大概三個小時。接下來六小時是核心架構：",[44,85,86,94,101],{},[47,87,88,89,93],{},"每個 LINE OA 有自己的 ",[90,91,92],"code",{},"\u002Fwebhook\u002F:channelId"," 路由，訊息進來就知道是哪個 OA 傳的",[47,95,96,97,100],{},"DB 設計：一個 thread = 一個 ",[90,98,99],{},"(channel_id, line_user_id)"," 組合。同一個用戶傳給 OA-A 和 OA-B，一定是兩個不同的 thread，永遠不會合併",[47,102,103],{},"發送回覆時，系統從 DB 推導要用哪個 OA 的 token，前端完全碰不到任何 token 或 channel 資訊",[15,105,106],{},"第一天結束，PoC 部署上線，兩個測試 OA 串到同一個收件匣，用手機親自測試確認不混線。",[31,108],{},[10,110,112],{"id":111},"第二天她提出了三組驗收標準當天全部完成","第二天：她提出了三組驗收標準，當天全部完成",[15,114,115],{},"第二天早上，她回覆了。不只是「OK 沒問題」，而是一份結構化的驗收清單：",[15,117,118],{},[68,119,120],{},"A 組：防混線與資料約束",[44,122,123,126,129],{},[47,124,125],{},"Thread 唯一性必須有 DB constraint，不能只靠應用層邏輯",[47,127,128],{},"多坐席鎖定：同一對話不能有兩個客服同時在回",[47,130,131],{},"Webhook 去重：LINE 偶爾會重送事件，重複訊息不能進 DB",[15,133,134],{},[68,135,136],{},"B 組：營運必備",[44,138,139,142,145],{},[47,140,141],{},"對話可以結案，結案後 LINE 再來訊息自動重開",[47,143,144],{},"每個操作都要有稽核紀錄（誰、幾點、做了什麼）",[47,146,147],{},"要能匯出 CSV，Excel 開起來中文不亂碼",[15,149,150],{},[68,151,152],{},"C 組：資安與部署",[44,154,155,158],{},[47,156,157],{},"Token 和 Secret 不能出現在 Git repo",[47,159,160],{},"系統要有 health check，讓她知道服務是不是活的",[15,162,163],{},"看到這份清單我知道她是認真的。這種有結構的驗收標準，不是「感覺上線了就算」的態度。",[15,165,166],{},"整個第二天拿來做這三組需求。技術上最難的是鎖定機制——五分鐘超時、前端不算時間（只信 server）、被搶鎖時 UI 即時更新——這個部分前後修了五輪 bug 才穩定。",[15,168,169],{},"最終交出：12 個 API endpoints、完整稽核日誌、多坐席鎖定、CSV 匯出（含 BOM 解決 Excel 中文問題）、Fly.io 部署、GitHub private repo 移交。",[15,171,172,173],{},"第二天結束，她的回覆是：",[68,174,175],{},"「驗證通過，請出 Phase 1 里程碑報價。」",[31,177],{},[10,179,181],{"id":180},"兩天總結三件事","兩天，總結三件事",[15,183,184],{},[68,185,186],{},"第一件：PoC 不是免費試工，是雙方篩選的機制",[15,188,189],{},"PoC 讓她在花大錢之前確認你做得到，也讓你確認對方是不是能給出清晰需求的合作對象。她的驗收標準就是最好的證明——這種客戶，你願意花時間做 PoC。",[15,191,192],{},[68,193,194],{},"第二件：防混線的真正保障在 DB constraint，不在應用邏輯",[15,196,197,200],{},[90,198,199],{},"UNIQUE(channel_id, line_user_id)"," 這個 DB constraint，是整個系統的最後防線。就算應用層出 bug，就算前端傳錯參數，DB 層會拒絕一切混線資料。如果這個 constraint 不存在，你只是在靠運氣。",[15,202,203],{},[68,204,205],{},"第三件：多坐席搶話的問題，在幾乎所有客服系統都被低估",[15,207,208],{},"你以為的問題：「客服分不清誰在哪個 OA 回話」。",[15,210,211],{},"真正的問題：「同一個客人，兩個客服同時在回，訊息互相打架，客人以為公司有兩個人在同時處理她的問題」。",[15,213,214],{},"鎖定機制不是好看的功能，是防止這個場景的實際工程。",[31,216],{},[10,218,220],{"id":219},"如果你也有多個-line-oa","如果你也有多個 LINE OA",[15,222,223],{},"常見的觸發點：",[44,225,226,229,232],{},[47,227,228],{},"你有一個以上的 LINE 官方帳號（不同品牌、通路、或部門）",[47,230,231],{},"客服靠「大家都記得用哪個帳號回」維持秩序",[47,233,234],{},"偶爾懷疑有沒有訊息被漏掉或跳號",[15,236,237,238,241],{},"如果這三點有一點符合，統一收件匣是值得認真評估的方向。不一定需要 AI，核心是",[68,239,240],{},"讓所有訊息流進一個地方、讓每個操作都有記錄、讓坐席之間不要搶話","。",[15,243,244],{},"如果你想知道這對你的規模和業務有沒有意義，可以直接加這個網站的 LINE，說你的現況，我會告訴你值不值得做、大概要花多少時間和錢。沒有簡報，不賣套裝方案，先確認問題再討論解法。",{"title":246,"searchDepth":247,"depth":247,"links":248},"",2,[249,250,251,252,253,254],{"id":12,"depth":247,"text":13},{"id":35,"depth":247,"text":36},{"id":76,"depth":247,"text":77},{"id":111,"depth":247,"text":112},{"id":180,"depth":247,"text":181},{"id":219,"depth":247,"text":220},"2026-04-25","一家食品飲料經銷商有多個 LINE 官方帳號，客服每天用錯帳號回客人、訊息無法追溯、坐席搶話沒有機制。這篇文章記錄從接到詢問到交出可驗證的系統，實際花了幾天、做了什麼、踩了哪些技術坑。","md",{},true,"\u002Fblog\u002Fline-bot-consulting-case-study",{"title":5,"description":256},"blog\u002Fline-bot-consulting-case-study",[264,265,266],"line-bot","smb","freelance","7lsi-nWs2-flyWCIo_-FFuHvEMcyuVQLrrx3L80dP_0",1785903592272]