EXPERIMENT TRAIL / 第三方客服流程

最初想解的問題

LINE 礦場服務台

礦場檢修或場地臨時出狀況時，要快速通知受影響用戶，但不能讓每次公告都變成重複問答與無限聊天。

測試中最近紀錄：2026.08.112 筆階段紀錄

目前流程示意

ORIGIN / 起源

先理解為什麼要開始

功能不是故事的起點；這個實驗先從一個反覆出現的現場問題開始。

當時背景

問題發生在什麼情境？

把礦場檢修與臨時場地問題整理成一次可確認的通知，直達受影響用戶；個別問題再進案件流程。

最初假設

我們以為改變什麼會有用？

如果先把礦場事件整理成可直接送達的公告，再把少數個別問題分流成案件，就能讓用戶收到必要資訊，也避免合作方陷入重複聊天。

PROCESS / 驗證過程

不是一次做完，而是沿著訊號調整

先看最初設計的驗證路徑，再沿時間線讀每次卡點、改動與結果。

INITIAL TEST PLAN

最初怎麼試

01
合作礦場回報檢修公告或場地臨時問題，由第三方客服先確認範圍、時間與用戶需要知道的事項。
02
整理成一則清楚通知後，直接送達受影響用戶，不必由礦場逐一說明。
03
只有需要個別處理的問題才轉成案件；合作方處理任務，客服承接後續回覆。

2026/07/23
LINE 礦場服務台第一次試點
已有初步結果
卡點通知與客服散落群組做法LINE 統一服務入口結果入口可行，權限待補
查看完整紀錄
CAUSE / 卡點
為什麼卡住
礦場通知、客服問題與用戶溝通散落在不同 LINE 群組，缺少統一紀錄、權限與追蹤機制。
ACTION / 做法
這一階段改了什麼
第一次試點 LINE 礦場服務台，測試以 LINE 作為用戶與礦場之間的服務入口。
OUTCOME / 果
目前看到什麼
確認 LINE 適合作為前端入口，同時發現還需要補上權限、資訊隔離、人工審核與後台同步。
下一個 AI 實驗
讓 AI 判斷問題類型、查詢 Learn／Hub 資料並產生回覆草稿，無法處理時再轉交人工。
證據邊界這是第一次試點的流程結論；尚未證明能安全處理所有權限、通知或客服情境。
2026/08/11
礦場公告直達與個別案件分流
目前階段持續驗證
卡點公告變成重複問答做法廣播通知＋案件分流結果內部原型測試中
查看完整紀錄
為什麼進到這一步第一次試點確認 LINE 適合作為入口後，下一個卡點是如何讓公告直達，又不讓合作方陷入無限聊天。
CAUSE / 卡點
為什麼卡住
礦場檢修或場地臨時出狀況時，需要快速通知受影響用戶，又不能讓每次公告都變成重複問答與無限聊天。
ACTION / 做法
這一階段改了什麼
- 由第三方客服先確認公告範圍、時間與必要資訊，再一次通知受影響用戶。
- 只有需要個別處理的問題才轉成案件，交給合作方處理並回傳結果。
OUTCOME / 果
目前看到什麼
JGM 內部原型開始測試公告整理、受影響對象、權限、未讀狀態與個別案件分流。
目前狀態
公告直達與案件分流仍在內部測試。
下一個 AI 實驗
驗證公告範圍、送達狀態與案件交接是否能被清楚追蹤，再逐步加入回覆草稿。
證據邊界目前僅能確認 JGM 內部原型進入測試，尚無公開使用網址、對外服務或通知送達與案件處理成效資料。

RESULT / 結果

目前有訊號，但答案還沒有定案

進行中的實驗會保留不確定性，讓下一個行動有清楚依據。

OBSERVATION / 目前訊號

到目前為止，看到了什麼？

JGM 內部原型正在測試公告整理、受影響對象、權限、未讀狀態與個別案件分流。

目前判斷

測試中

維持小範圍驗證，不把初步結果當成完成；下一輪測試會決定要放大、調整或停止。

下一個驗證

用檢修公告與臨時場地問題測試通知送達、已讀確認，以及哪些回覆應進案件而不是留在群組聊天。

用一個更小、可觀察的動作取得下一個訊號。

VISITOR RESONANCE / 訪客共鳴

這個問題，你也遇過嗎？

這不是一般按讚；每一筆都要補上真實情況，幫助判斷需求是否存在。