基礎介紹
專案背景與問題說明
本專案旨在解決既有 Tracking 狀態更新仰賴人工通知、易重複寄信且缺乏一致控管的問題。
過往流程中，訂單狀態雖已記錄於 Airtable，但狀態異動後需由人員手動判斷是否通知客戶，導致以下風險：
- 通知時機不一致，易延誤或遺漏
- 狀態更新後重複寄送通知信
- 通知是否已寄送缺乏明確紀錄
- 無法有效區分「狀態更新」與「通知行為」
本專案透過 Airtable 與 Make 串接，建立一套可控、可追蹤、非全自動化的狀態通知機制，作為後續擴充之基礎。
核心設計原則
本系統設計遵循以下原則：
-
狀態與通知行為分離
- 訂單狀態更新不等於立即通知
- 通知行為需具備明確判斷與紀錄
-
避免全自動黑箱流程
- 關鍵狀態仍保留人工判斷空間
- 系統僅負責輔助與防呆，不取代決策
-
防重複、可追溯
- 每一次通知皆需留下可回查之紀錄
- 避免因資料修正或回寫造成重複寄送
系統架構概述
Tracking x MAKE 系統分為以下三個層面：
1. 資料結構層（Airtable）
作為系統核心，負責狀態紀錄與通知控管：
- 訂單狀態欄位（如 In Transit）
- 通知防重複欄位（如 Last Notified / Notified）
- 客戶聯絡資訊與通知用 Email 欄位
詳細說明請參閱：
資料結構說明
2. Automation 輔助層（Make）
本系統採用「非全自動化」策略：
- 僅於條件成立時觸發通知流程
- 寄送成功後回寫通知狀態與時間
- 加入基本防呆與錯誤判斷機制
Automation 不負責決策，僅負責：
- 條件判斷
- 寄信動作
- 狀態同步
整體效益
本專案完成後，可達成以下效益：
- 降低人工通知錯誤與重複寄信風險
- 提升訂單狀態通知一致性
- 強化通知行為之可追溯性
- 建立後續多狀態、多模板通知之擴充基礎
本系統定位為「可擴充之基礎架構」，未來可依實際營運需求，逐步延伸通知狀態、Email 模板或整合其他模組。