to-be 設計 · Slack + PG
🚀 TFF To-Be 業務流程
每個時序圖與關卡明細均為可開合的共用元件；關卡明細維持「對照 As-Is」欄。
🚀 未訪處一律標 ❓ 假設／blocker；SurveyCake 不做報名。
01
To-Be：六階段設計
點標題開合時序圖與關卡明細PG 為營運真相層、鏡射 CRM；CRM 仍是主檔真相源。流程先行，不建資料表。
To-Be 設計｜時序圖
To-Be 設計｜關卡明細
階段 1｜報名 → 訂單 → 合約B↑ 回到最上方
To-Be 設計｜時序圖
To-Be 設計｜關卡明細
To-Be 設計｜時序圖
To-Be 設計｜關卡明細
To-Be 設計｜時序圖
To-Be 設計｜關卡明細
To-Be 設計｜時序圖
To-Be 設計｜關卡明細
階段 5｜結案報告 → 請款 → 開票F↑ 回到最上方
To-Be 設計｜時序圖
To-Be 設計｜關卡明細
07
分期導入提示（先殺哪一塊）
純規則零 LLM 先行 · 依賴/風險標註P1 · 純規則、零 LLM、低依賴
- 觀看通知自動寄（G22）：篩末碼 O→套模板→發，最痛且最單純
- 課前文件生產線（G19）：8 CRM 欄套版三件套
- 資安三修復：webhook 金鑰/會議密碼/回覆權限
- 前置：CRM read-only 帳號＋schema、PII 拆欄
P2 · 流程數位化
- 三關數位確認（汰紙本訂單）— 卡 C1
- 巡檢引擎＋讀 PG 即時異動（消除隔天差）— 卡 C5
- 數位簽到＋出席三源入 PG
- 前置：Slack 互動層、異動表結構化
P3 · 收尾與整合
- 結案三源比對＋產證守門
- 會計段（G32–34）— 卡 B1，需補訪才能動
- 實體物流/統編查核— 卡 B3
- 升級：官網 API→CRM 雙向 API（終局）
＊ 排程角色歸屬 as-is 的四個自動點（官網↔CRM 同步、專班表→日曆、SurveyCake→Sheet、觀課每週五）在 to-be 統一由 Worker/排程服務承擔；其中日曆串接與 webhook 保留既有 Apps Script只加固，其餘同步/發信改由 Worker 直讀 CRM（read-only）與官網。Slack bot 只管互動，不跑排程。