一筆假需求的狀態，要比 AI 回覆更清楚
假資料 DEMO-REQ-001 從 LINE 進來，只產生需求草稿。Google 試算表記錄待審狀態，不把模型回覆當成核准；審核者確認後，後端才以同一請求識別碼送 ERP。這是設計範例，不是已完成的客戶串接。
- 待審 → 已核准
- 核對欄位與審核者權限，保留核准人與時間；未核准不觸發 ERP 寫入。
- 已核准 → 結果待查
- ERP 呼叫逾時時，記為結果待查，不直接判定沒建單；先用請求識別碼查詢結果。
- 結果待查 → 完成或人工處理
- 查到同一筆成功結果才記錄 ERP 編號；平台無法查詢或無防重複能力時，停止自動重送並通知負責人核對。
狀態與核准記錄需要由受控後端維護，不能只信任使用者可自行修改的試算表欄位。整合前先核對平台 API 能力，本文沒有金鑰、私人工作表連結或真實訂單。
先分開資料查詢、草稿與正式寫入
可行流程通常是「接收請求 → 驗證來源與使用者 → 檢查資料權限 → 查詢必要資料 → 產生草稿 → 人工核准 → 由系統按規則寫入 → 核對結果」。模型只協助產生內容，不能自行決定自己有什麼權限。實際能否串接，要先查你的平台方案、API 文件與測試環境。
三種工具的角色不同
不要因為 LINE 上傳了問題，就認定使用者有權查公司 ERP。通訊入口、試算表資料與正式系統各有自己的身份、授權及限制，需由系統明確連結。
| 對象 | 適合的角色 | 先確認的項目 |
|---|---|---|
| LINE | 收到提問、通知、人工處理入口 | 官方帳號與 channel、事件來源、身份綁定、發送授權 |
| Google 試算表 | 核定範圍的參考資料或待覆核清單 | 檔案持有人、欄位、授權、更新責任與 API 配額 |
| ERP／CRM | 正式訂單、客戶或庫存的業務來源 | API 與方案、測試帳號、業務規則、讀寫與操作紀錄 |
| AI 模型 | 摘要、分類、欄位建議與回覆草稿 | 允許送出的欄位、資料保存條件與用量限制 |
LINE 入口先確認來源與身份
LINE Messaging API 可以將使用者事件透過 webhook 傳到伺服器，伺服器再依事件處理。正式整合要按 LINE 官方文件驗證 webhook 簽章；這證明事件來源，不等於使用者已通過你的企業身份驗證。查訂單或內部資料仍需另外綁定身份、檢查權限與最小化回傳內容。
- 回覆草稿與真正發送分開，訂單修改或承諾退款需按核定規則覆核。
- 保留事件及處理狀態，測試重送、逾時、無法回覆及轉交人工情境。
- Channel 憑證由安全設定管理，不放公開前端、試算表或詢價需求單。
Google 試算表不必為串接改成公開
先確認哪份檔案、哪些工作表及欄位可讀寫，採核定的 OAuth 或服務帳號等授權方式；企業保有檔案與帳號控制權。分享範圍與 API 存取範圍要一起核對，不宣稱隱藏工作表就具備資料隔離。讀取、等待核准與正式寫入分開，不讓 AI 輸出直接覆蓋原資料。
- 欄位與版本
- 定義識別欄位、資料型別、必填及格式規則；有人改欄位或同時編輯時，系統應可檢查衝突。
- 配額與失敗
- 試算表 API 有配額與限流。依官方指引設計有限重試、排隊及通知，不持續重送而隱藏錯誤。
- 機密資料
- 只傳必要且已授權欄位到模型，事前約定保存與刪除；不要把完整客戶清單當成測試資料。
ERP 能不能接，先拿 API 文件驗證
提供系統名稱、版本、使用方案、API 文件、測試環境與預期讀寫項目；先由系統管理者開最低必要權限。若 ERP 沒有接口，需另評估匯出、批次交換或系統改造及服務商條件，不能保證一定串接。正式寫入還要驗證欄位、庫存、訂單狀態等業務規則，不能信任模型自行推測。
把重複、失敗與停止列入驗收
同一事件重送不應重複建單。使用穩定事件或任務識別與系統約束，寫入前確認狀態，完成後讀回結果；不同系統能力不同，要依實際 API 設計。未知結果不能盲目重試。測試 API 中斷、資料衝突、權限撤回、用量上限及人工未核准，確認有可追查錯誤、可停止流程與回復方案。
要串接的 LINE／試算表／ERP：＿＿＿＿；資料來源與持有人：＿＿＿＿；API 與測試環境：＿＿＿＿。
允許讀取：＿＿＿＿；允許產生草稿：＿＿＿＿；必須人工核准後才能寫入或發送：＿＿＿＿。
不允許外傳資料：＿＿＿＿；每日／每月頻率：＿＿＿＿；失敗與停止時由＿＿＿＿接手；驗收及交接項目：＿＿＿＿。