AI 承諾追蹤教學：管理跨部門與供應商交付、提醒及升級

10月 23, 2026

原內容日期：2026-09-30。本文為既有教學內容補發；範例依原文標示使用，實際權限與規則請以所屬組織核定資料為準。

為什麼每週都是「下週給」？

跨部門與供應商協作中，最常聽見的答覆可能是「我再確認」「應該下週可以」「資料差不多了」。PM 回到週報，常把它整理成「對方承諾下週提供」。到了下週，對方卻認為自己只是說明預估。

很多延誤表面上是執行問題，實際上承諾從一開始就沒有完整成立。

一項可管理的承諾至少需要明確交付物、承諾者、日期或觸發條件、前置條件、完成證據與驗收者。缺少任何一項，都應先列為承諾候選，而不是正式承諾。

一、先分清希望、預測與承諾

「希望星期四拿到」是需求方的希望；「照目前進度可能下週完成」是預測；「我會在星期四前提供指定格式的文件」才接近正式承諾。

AI 很容易為了讓摘要流暢，把這些不同強度的語句合併。正確做法是保留原句、說話者、時間與來源，再分類為正式承諾、有條件承諾、預測、意向、希望、建議或待確認。

二、交付物要寫到雙方能驗收

「提供滅菌釜資料」看似清楚，實際上可能是一份圖片、一張 PDF 或完整可編輯表格。需求方期待位址、資料型別、單位與讀寫權限；提供方可能以為只要位址即可。

因此，承諾台帳應明確記錄內容、範圍、格式、版本、語言、必要附件與完成證據。越早說清楚，越能避免準時交付後仍要多輪補件。

三、日期要加上性質標籤

同一個專案可能同時存在希望日、目標日、預測日、承諾日、最晚決策日與實際交付日。

如果全部都只叫「Deadline」，週報與會議紀錄很容易失真。尤其是 PM 的希望日，不能在沒有對方確認的情況下變成承諾日。

有條件承諾也要保留條件。例如「若今天收到樣本，星期五可完成」。若樣本星期四才收到，原星期五日期不能脫離條件單獨追蹤。

四、提醒的目的不是催，而是提早修正

有效的提醒節奏可以包含 T-5 確認前置條件、T-2 確認守約信心、到期日交付或正式改期、逾期後更新影響，以及達門檻後升級。

比起每天問「好了嗎」，更好的問題是：「目前完成到哪個可驗證階段？是否有阻塞？原承諾是否仍可達成？需要哪項協助或決策？」

五、收到不代表完成

供應商準時寄來檔案，可能缺少必要欄位、格式無法使用或版本錯誤。交付狀態應至少區分完整接受、部分接受、待補件、退回修正、無法驗證與已取代。

同時要設定驗收窗口。否則提供方認為已完成，需求方過了一週才提出缺件，雙方都會覺得責任不清。

六、改期要留下歷史

重新承諾並不一定代表失敗。需求變更、前置條件延誤或新的技術資訊，都可能讓合理改期成為最佳選擇。

問題在於許多追蹤表會直接把舊日期改掉，最後只剩最新日期，看不出原承諾、改期次數與理由。正確做法是保留每次日期、提出時間、變更原因、條件變化、接受者與里程碑影響。

七、升級應該是一座階梯

升級不等於一逾期就把主管全部加入副本。可以依序採取友善提醒、正式確認、對等主管協調、專案方案決策，以及必要時的商務或治理程序。

好的升級訊息只包含事實、影響、已採取行動、可選方案與需要誰在何時決定什麼。它不推測動機，也不公開責備個人。

八、不要只看準時率

假設十項承諾有八項準時，但其中兩項需要多輪補件，只報 80% 準時就會隱藏返工成本。

建議同時觀察準時且一次驗收通過率、部分交付率、重新承諾次數、平均逾期天數，以及沒有明確承諾者或完成證據的比例。

這些指標應用來改善需求清晰度、資源與流程，不應直接當成個人績效排名。

讓追蹤從「靠人催」變成「靠規則前進」

AI 最有價值的地方，不是幫你寫更強硬的催促訊息，而是從大量對話中找出：哪些其實不是承諾、哪些交付物無法驗收、哪些日期缺少前提、哪些項目已經接近升級門檻。

今天可以先挑一項最常延誤的交付，補齊六個欄位：交付物、承諾者、承諾日、前置條件、完成證據與下一個提醒節點。你會立刻看出，問題究竟是對方不守約，還是承諾從未真正成立。

行動呼籲

打開最近一次會議紀錄，圈出所有「會、可以、應該、預計、盡快、下週」。逐一分類成承諾、預測、意向或希望，再把待確認項目發出正式確認。這一步往往比增加更多催促更有效。

逐步操作

第 1 步：先定義什麼才算承諾

一項可管理的承諾至少包含：

明確交付物
接受責任的承諾者
明確日期或觸發條件
前置條件
完成與驗收證據
接收者或驗收者

少了其中一項，只能先列為「承諾候選」或「待確認事項」。

第 2 步：蒐集所有來源並編號

整理：

會議紀錄
Email 往返
即時通訊
任務系統
合約、採購單或正式計畫
上次週報與決策紀錄

保留來源編號、日期、原句與說話者，避免 AI 將不同人的話合併成同一承諾。

第 3 步：先分類語句強度

類型	典型語句	可否當正式承諾
正式承諾	「我會在週四前提供已確認的 I/O 表」	可，但仍需確認範圍與證據
有條件承諾	「若今天收到樣本，週五可完成」	僅在條件成立時
預測	「照目前進度，可能下週完成」	不可當保證
意向	「我們會盡量處理」	不可
希望	「希望星期四拿到」	是需求方期望，不是對方承諾
建議	「建議月底前完成」	不可，除非有權者確認
待確認	「應該可以」	不可

AI 很容易把禮貌性回覆寫成確定答覆，因此分類是第一道防線。

第 4 步：把交付物寫到可驗收

錯誤：

提供滅菌釜資料。

可驗收：

提供滅菌釜 Modbus TCP 通訊參數與完整 I/O 位址表，包含欄位名稱、資料型別、單位、讀寫權限及至少一組範例值，格式為可編輯試算表。

交付物應明確定義內容、範圍、格式、版本、語言與必要附件。

第 5 步：區分日期性質

每個日期加上標籤：

希望日：需求方期待
目標日：團隊努力方向
預測日：依目前資訊推估
承諾日：責任人明確接受
最晚決策日：超過就必須改方案
實際交付日：可由證據驗證

週四「希望拿到」不能自動變成供應商「承諾週四交」。

第 6 步：確認承諾者與驗收者

會議參與者不等於承諾者，被副本也不代表接受任務。請明確記錄：

誰承諾交付
誰實際執行
誰驗收
誰有權修改日期
誰在逾期時決定替代方案

AI 可以指出角色缺口，不能替沒有開口的人接受責任。

第 7 步：列出前置條件與互相依賴

承諾常失效，不是因為忘記，而是前置條件從未成立。

例如：

先收到樣本
先取得客戶核准
測試設備可用
規格版本凍結
另一團隊先完成 API

每項條件要有負責人、成立證據與最晚確認日。

第 8 步：設計完成證據與驗收窗口

完成證據可能是：

可開啟的正式檔案
系統版本號
測試通過紀錄
簽核或回覆確認
實機畫面與記錄
對帳結果

同時設定驗收期限。例如收到後兩個工作天內回覆完整、部分接受或退回，避免交付物無限停在「已寄出、未確認」。

第 9 步：建立提醒節點

依重要性建立節奏，例如：

T-5：確認前置條件是否齊備
T-2：確認進度、阻塞與是否仍能守約
T-0：交付或提出正式變更
T+1：逾期確認與影響更新
T+3：主管或商務升級

提醒不是每天問「好了嗎」，而是確認能否守約及需要什麼支援。

第 10 步：設定黃色與紅色觸發條件

黃色訊號可能包括：

前置條件在 T-5 尚未完成
承諾者無法說明目前進度
交付範圍開始縮小
需要的核准尚未排程

紅色訊號可能包括：

已逾承諾日
交付物不符合最低驗收標準
連續兩次重新承諾仍未完成
延誤已影響關鍵里程碑

觸發條件需連到具體行動，而不是只把欄位改成紅色。

第 11 步：用階梯式方式升級

建議分層：

友善提醒：確認狀態與協助需求。
正式確認：重述交付物、期限、影響與回覆要求。
對等主管協調：請雙方主管確認資源或新日期。
專案決策：啟動縮小範圍、替代來源或改期。
商務或治理程序：依合約與正式規則處理。

升級是管理依賴，不是公開責備個人。

第 12 步：處理部分交付與不合格交付

收到檔案後，狀態不要只有完成或未完成。可使用：

完整接受
部分接受
待補件
退回修正
無法驗證
已取代

列出缺少項目、對後續影響、補件期限與暫時可用範圍。

第 13 步：記錄重新承諾，不覆蓋舊日期

每次改期都保留：

原承諾日
新承諾日
提出日期
變更原因
前提是否改變
誰接受新日期
對里程碑的影響

這不是為了算帳，而是辨識估時、資源或流程上的系統問題。

第 14 步：建立承諾健康度

可追蹤：

到期承諾數
準時且一次驗收通過數
部分交付數
重新承諾次數
平均逾期天數
沒有明確承諾者或證據的比例
因外部依賴造成的里程碑影響

不要只用準時率評價個人，需同時觀察需求清晰度、前置條件與變更頻率。

第 15 步：關閉承諾並回收經驗

承諾關閉條件：

交付物收到
驗收完成
缺失已補齊或正式接受
下游工作可開始
證據與版本已保存

若承諾取消或被取代，也要保留原因與核准者。

可直接複製的完整提示詞

【角色】
你是一位審慎、重視證據與合作關係的承諾追蹤助手。你要協助我從會議、Email、聊天與任務紀錄中整理承諾，但不得把希望、預測、意向或沉默改寫成正式承諾，也不得替任何人承諾日期、資源或責任。

【任務】
1. 擷取所有承諾候選語句，保留來源、日期、原句與說話者。
2. 分類為正式承諾、有條件承諾、預測、意向、希望、建議或待確認。
3. 將交付物改寫為可驗收的內容、範圍、格式、版本與完成證據。
4. 區分希望日、目標日、預測日、承諾日、最晚決策日與實際交付日。
5. 找出承諾者、執行者、驗收者、改期核准者及缺少角色。
6. 整理前置條件、依賴、提醒節點、預警門檻與升級階梯。
7. 追蹤部分交付、不合格交付、補件與重新承諾歷史。
8. 產出友善提醒、正式確認、逾期升級及週報摘要。
9. 計算承諾健康度，但不得在資料不足時推測數字。

【專案基本資料】
- 專案名稱：[專案名稱]
- 分析期間：[起訖日期]
- 資料截點：[日期時間]
- 主要里程碑：[里程碑與日期性質]
- 交付雙方：[需求方角色／提供方角色]
- 升級原則：[正式規則；未知則填未知]
- 驗收時限：[收到後幾個工作天；未知則填未知]

【輸入資料格式】
來源編號｜日期時間｜來源類型｜說話者／寄件人｜原始內容｜相關主題｜附件或連結
[S01]｜[日期時間]｜[會議／Email／聊天／任務／合約]｜[角色]｜[原句]｜[主題]｜[備註]

原始紀錄：
[貼上會議、Email、聊天與任務紀錄]

現有承諾表：
[貼上內容；若無則填無]

【限制與判斷規則】
1. 不得捏造承諾者、日期、交付物、證據、變更原因或驗收結果。
2. 希望、目標、預測、建議與承諾必須分開。
3. 「盡快」「下週」「應該可以」若沒有明確日期與接受責任，列為待確認。
4. 沉默、被副本、參加會議或沒有反對，不代表接受承諾。
5. 有條件承諾必須保留條件，不得只摘錄日期。
6. 收到檔案不等於完成；需依驗收標準判斷。
7. 改期時保留原日期與變更歷史，不得覆蓋。
8. AI 只能產生訊息草稿，不得自動對外寄送、公開點名或啟動合約處置。
9. 涉及法務、採購、財務、資安、個資或客戶承諾時，標示需人工複核。
10. 若資料不足，先完成可確定部分，再提出最多7個高價值確認問題。

【輸出格式】
A. 主管一分鐘摘要
- 本期到期承諾
- 已完成、部分完成、逾期與待確認數量
- 對里程碑影響最大的三項
- 需要主管決定的事項

B. 承諾候選分類表
編號｜原始語句｜分類｜判斷理由｜來源｜需要確認什麼

C. 正式承諾台帳
承諾編號｜交付物｜承諾者｜執行者｜驗收者｜日期性質｜承諾日｜前置條件｜完成證據｜目前狀態｜下一節點｜來源

D. 日期與變更歷史
承諾編號｜原日期｜新日期｜變更提出日｜原因｜條件變化｜接受者｜里程碑影響

E. 提醒與升級計畫
承諾編號｜T-5行動｜T-2行動｜到期日行動｜逾期行動｜紅色門檻｜升級角色

F. 驗收與補件表
承諾編號｜收到內容｜驗收結果｜缺少項目｜可暫用範圍｜補件期限｜驗收證據

G. 依賴與影響
承諾編號｜依賴項目｜依賴負責人｜最晚成立日｜未成立影響｜替代方案｜決策者

H. 訊息草稿
1. 友善提醒：專業、簡短、以協助守約為目的。
2. 正式確認：重述交付物、承諾日、前置條件、驗收方式與回覆要求。
3. 逾期升級：只寫事實、影響、已追蹤紀錄、選項與需要決策，避免責備語氣。
4. 部分交付回覆：確認已收到部分、列出缺件與補件期限。

I. 週報摘要
- 已完成承諾
- 即將到期
- 黃色／紅色項目
- 重新承諾
- 需要決策

J. 承諾健康度
指標｜公式｜本期數值｜資料限制｜解讀注意事項

K. 高價值確認問題
最多7題，依「答案最能降低延誤與誤解」排序。

【最後自我檢查】
- 是否把希望日期誤寫成承諾日期？
- 是否保留有條件承諾的前提？
- 是否每項承諾都有明確交付物與承諾者？
- 是否定義完成證據與驗收時限？
- 是否保留每次改期歷史？
- 是否把收到檔案直接當成驗收完成？
- 是否讓升級訊息聚焦事實、影響與選項，而不是責備個人？

可替換欄位速查

[專案名稱]：例如「秤量設備通訊整合」
[分析期間]：建議至少涵蓋最近兩到四週
[資料截點]：避免後續訊息與週報狀態混在一起
[驗收時限]：若沒有正式規則，請標示待確認
[升級原則]：依公司治理、合約及專案權限設定

實際教學範例

原始對話

週一，PM：「希望星期四前拿到滅菌釜參數與 I/O 位址，才能準備測試。」
週一，供應商窗口：「我請工程師整理，應該下週可以。」
週三，工程師：「要先看到設備版本照片，才能確認表格。」
週四，PM 傳送設備照片。
下週一，供應商窗口：「資料差不多了，晚點給。」
下週二，收到一份 PDF，但缺少資料型別、單位與寫入權限。

第一步：辨識真正的承諾

原句	分類	原因
希望星期四前拿到	希望日	是 PM 的需求，並非供應商接受
應該下週可以	預測／待確認	沒有日期、交付範圍與責任確認
要先看到設備版本照片	前置條件	條件成立前不能視為日期承諾
晚點給	意向／待確認	沒有明確時間與交付內容

結論：原對話中其實沒有一項完整正式承諾。PM 若直接在週報寫「供應商承諾下週提供」，就會失真。

第二步：發出正式確認

感謝協助。為配合進廠測試準備，請確認交付內容是否為：滅菌釜 Modbus TCP 通訊參數與完整 I/O 位址表，包含欄位名稱、位址、資料型別、單位、讀寫權限及範例值，格式為可編輯檔。設備版本照片已於本週四提供。請協助回覆可承諾的交付日期；若無法一次提供完整資料，也請說明可先交付範圍與其餘項目的預計時間。收到回覆前，我方會將日期標示為待確認。

第三步：處理部分交付

收到 PDF 後不能直接關閉：

驗收項目	結果
位址	已提供
欄位名稱	已提供
資料型別	缺少
單位	缺少
讀寫權限	缺少
範例值	缺少
可編輯格式	未提供

狀態應標示「部分交付／待補件」，並記錄可先進行的工作與仍被阻塞的測試。

部分交付回覆範例

已收到 I/O 位址 PDF，謝謝。目前已可確認位址與欄位名稱；資料型別、單位、讀寫權限、範例值及可編輯版本尚未包含，因此完整測試仍無法開始。請協助確認補件日期。若需要分批提供，可先補資料型別與讀寫權限，讓我們完成測試案例設定；其餘欄位再依確認日期補齊。

承諾台帳示例

編號	交付物	狀態	日期性質	下一步
C01	設備版本照片	已完成	實際日	證據已保存
C02	完整 I/O 位址表	部分交付	承諾日待確認	確認補件日與分批範圍
C03	完整通訊測試	等待依賴	預測日待重估	資料齊備後重新排程
C04	進廠測試日期	待決策	目標日	到門檻時選擇部分測試或改期

升級訊息範例

截至今日，供應商已提供 I/O 位址 PDF，但缺少資料型別、單位、讀寫權限、範例值與可編輯版本，完整通訊測試仍無法開始。目前尚未取得明確補件承諾日。我方已提出可分批補件方案。若於進廠日前兩個工作天仍未取得最低必要資料，請決定：A. 維持進廠日期，只執行電子秤及可獨立項目；B. 延後進廠，待資料齊備後完整測試。此升級聚焦測試影響與方案，不代表認定任何個人失職。

承諾健康度示例

假設本期共有 10 項到期承諾：

6 項準時且一次驗收通過
2 項準時但需補件
1 項重新承諾後完成
1 項逾期未完成

可同時呈現：

準時交付率：8／10
準時且一次驗收通過率：6／10
補件率：2／10
逾期未完成率：1／10

不能只報 80% 準時，否則會隱藏品質與補件成本。

常見錯誤、隱私與使用注意事項

常見錯誤

1. 把自己的希望寫成對方承諾

「我希望週四拿到」只代表需求，不代表對方接受。

2. 交付物只寫「資料」

沒有範圍、格式與版本，就無法驗收，也容易爭議。

3. 接受「盡快」與「下週」

要求明確日期、時區與工作日定義。

4. 忘記有條件承諾的前提

只記日期、不記「收到樣本後」，會造成不公平追蹤。

5. 收到附件就關閉

交付可能缺欄位、版本錯誤或無法使用，必須驗收。

6. 改期時覆蓋舊日期

這會失去變更歷史，無法辨識持續性問題。

7. 每天只問「好了嗎」

更有效的是確認目前進度、阻塞、守約信心與支援需求。

8. 一逾期就越級公開點名

先依預先約定的升級階梯處理，聚焦影響與方案。

9. 用準時率評價個人

需同時考量需求清晰度、前置條件、臨時變更與資源承諾。

10. 讓 AI 自動寄送催促訊息

涉及外部關係、合約與聲譽，應由人複核後發送。

資料隱私與商務注意事項

送入 AI 前，請移除或代碼化：

客戶、供應商與員工個資
合約價格、付款條件與未公開報價
系統帳密、Token、內網位址與安全資訊
未公開缺陷、事故與法務爭議
私人聊天內容與未經同意的錄音逐字稿
尚未公告的產品與交付日期

使用注意事項

合約承諾與一般專案承諾的法律效果不同，涉及違約需由法務或採購處理。
承諾台帳是管理工具，不應作為公開羞辱個人的排行榜。
自動提醒頻率要依關係與風險設定，避免造成訊息轟炸。
對外訊息發布前，確認收件人、日期、時區、版本與附件。
任何新承諾日都需由有權者接受，PM 不能替供應商或工程師承諾。