成交後怎麼交給交付團隊？建立決策、限制與待辦交接表

用一份可追溯的交接表核對已承諾範圍、記錄決策與限制、分派未決事項，並讓交付團隊確認執行條件與驗收方式。

成交後交給交付團隊，關鍵是把談話轉成可執行、可核對的紀錄。交接表應讓接手人快速看見承諾成果、決策依據、不可逾越的限制，以及仍待誰處理的問題；任何未確認的內容都保留其狀態，不用猜測補齊。這張表不是多一份行政手續，而是團隊開始工作的共同依據。

核對已承諾範圍

交接先從「實際承諾了什麼」開始，而不是從業務想像中的完整願景開始。逐項比對報價、提案、合約或會議紀錄，確認交付成果、數量、範圍、使用者、工作情境與明確不包含的事項。若文件版本不同，先標出採用版本與日期，將口頭補充註記為待確認，不能自行合併成承諾。遇到「協助導入」「完成自動化」這類大詞，要追問可觀察的完成狀態；例如是提供流程圖、設定一條測試流程，還是包含上線後調整？把動詞、對象和完成證據寫在同一列，交付者才知道要產出什麼。

可用「項目、已承諾內容、證據來源、排除內容、狀態」五欄整理。假設提案寫了「建立詢問表單」，就補明表單收集哪些欄位、送出後通知誰、在哪個既有網站頁面使用；若未包含舊資料清理或後續廣告設定，也要直接列出。接著把每項承諾連到原始訊息或文件段落，並標明是否已有雙方確認。業務只需整理與範圍有關的材料，不必把所有聊天逐字貼上；摘要旁保留來源位置，接手人才能在有歧義時回查。

另外，把承諾拆成可盤點的交付單位，避免一個項目名詞底下藏著多種解讀。像「完成網站更新」可分為頁面、文字素材、表單、測試與交付說明；只列本案確實談定的部分，未談到的工作標成範圍外或待確認。對每個項目問三件事：誰會使用、在哪裡看見完成、誰能確認符合原話。若提案只寫結果沒有驗收描述，先用中性語句整理疑點給承諾確認人，不要自行補進交付範圍。交接表最好保留原文摘要而非改寫成新承諾，並將推論寫成待確認問題。

記錄決策與限制

承諾清單確認後，另開一區記「為什麼這樣做」與「有哪些邊界」。決策至少寫結論、提出人或確認人、決定日期、採用理由及受影響的工作；限制則說明時間、預算、資料權限、品牌規範、現有系統或人力安排對做法造成什麼影響。不要只寫「客戶要求簡單」，應補上哪些操作要簡化、由誰使用，以及哪些需求因此先不做。若選擇尚未定案，把選項和決策期限分開記錄，不要把偏好當成批准。

例如客戶選擇先讓表單通知寄到一個共用信箱，理由是目前由單一窗口分流；限制是尚未確認是否需要自動寫入 CRM。這代表第一階段可以驗證通知內容與責任分派，卻不能預設已有 CRM 欄位對應或帳號權限。若後續改變決定，記下改動內容、確認者、日期及連帶影響，例如需重做哪個設定或重估哪段工作。限制也要標明是硬性不得違反、目前資源條件，或尚待查證；類型不同，處理方式就不同。這樣執行者不會把待確認事項默默當成既定需求，也能在變更發生時指出需要誰再作決定。

可在紀錄中標「已同意」「建議方案」「待決定」三種狀態，並記下決定是否受條件限制。當範圍牽涉多方，例如業務希望先求速度、執行者需要取得資料，寫下各方關注點與最後取捨，避免只保留一句結論而失去背景。若限制彼此衝突，列出衝突項、由誰拍板、拍板前哪些工作可以安全開始；不可由交接者替客戶或內部主管選答案。把變更前後的差異並排，指出影響的是成果、步驟、資源或時序，讓後續評估有共同基準，避免角色依不同版本安排工作。

由接手人確認可執行

交接不是把文件寄出去就算完成；接手人需要用自己的理解復述任務，並指出缺少的資料、依賴條件和風險。安排短會或非同步確認時，請他逐項回覆：我負責的成果是什麼、依據哪個版本、完成後如何驗收、目前有哪些前置條件未到位。若回覆只說「收到」，就請對方用一兩句話描述第一個可執行步驟，藉此檢查雙方是否對同一件事有相同理解。交接人應給足閱讀時間，避免在會議最後幾分鐘才丟出大量附件要求承諾時程。

可把「可執行」拆成四個判準：範圍有來源、限制可辨識、必要輸入有人提供、工作起點明確。任何一項缺失，都標記阻塞原因與解除方式，不要要求接手人先猜著做。譬如需要客戶提供現有網站管理權限，表格應寫明由誰、何時、透過何種安全管道提供；若尚無日期，就由負責窗口補定，不憑空填期限。接手人確認後，記錄姓名、回覆時間、確認的版本與保留疑問。若他提出「通知對象還沒定」，這不是拒絕交付，而是清楚揭露一個尚未具備的執行條件，應帶到待辦清單由適當的人決定。

讀回內容可以用簡短模板：「我會先做＿＿，交付＿＿；開始前需要＿＿由＿＿提供；完成以＿＿檢查；目前卡在＿＿。」請接手人自行填寫，交接者再對照承諾表，而不是先給標準答案讓對方點頭。若答案與原承諾不符，追查是資訊漏傳、文件歧義，還是接手者辨認到能力或權限缺口，修正相應紀錄並通知相關人。當開始條件已齊全，可明確確認第一個工作項目；尚未齊全就讓待辦成為明確阻塞，而不是設定一個無依據的開工日期。

分派未決事項責任

未決事項要轉成有負責人、有下一步、有檢查點的待辦，而不是留在會議紀錄的問號裡。每一項寫清問題、可能影響、決策或提供資料的人、實際追蹤者、需要的回覆，以及預計檢查日期；兩個角色可以不同，例如客戶負責提供名單，業務負責追蹤是否收到。若答案會改變範圍或成本，標成決策待辦並暫停受影響的工作；若不影響主線，可註明先行工作和之後的依賴，避免整個團隊空等。負責人應由實際能採取行動的人承接，不能只把責任寫給沒有決策權的人。

表中的時間若尚未獲同意，就寫「待窗口回覆日期」，不要把建議日期偽裝成已承諾。每次追蹤只更新狀態、證據和下一步，保留先前決策的變更紀錄。當一項待辦逾期或無法由原負責人處理，應明確升級給有權協調資源的人，並說明被卡住的工作與影響；不以反覆提醒取代責任調整。這讓每個人知道自己要做什麼，也避免未決事項被誤認為已納入承諾。

待辦排序可依「會不會阻擋下一步」和「答案會不會改變承諾」判斷。兩者皆是時先找決策人，不應排在提醒後；不阻塞但有期限關聯的事項，寫出最晚確認時點及逾期影響。同一問題有多種解法時，列出要比較的條件並指派一位收斂答案的人，避免把「大家討論」當成責任人。回顧只看狀態改變與待升級事項。分工後請負責人回覆承接；若卡在權限或資料，另找決策者解鎖。

交付驗收條件摘要

交付驗收摘要要把「做完」轉成雙方都看得見的條件，並連回一開始的承諾。每項成果說明交付物或可檢視狀態、驗收方式、檢查人、需要的測試資料，以及不屬於本次驗收的項目。條件要描述結果而非感受，例如「表單可送出並顯示確認訊息」比「表單體驗良好」更容易共同檢查；若還需要在不同裝置或情境檢視，列出代表性情境及如何記錄問題。驗收規則若當初沒有談清楚，先把它列為待確認決策，讓負責人定義後再作為基準，不能在交付末端臨時加上未談過的要求。

可以將摘要排成「承諾項目、驗收觀察、所需輸入、確認人、結果」幾欄。假設成果是詢問表單，示例條件可寫：使用者填入必填欄位後能送出，指定窗口收到通知，測試紀錄附上成功或失敗畫面；真實收件地址和測試帳號由客戶確認提供。這只是示範格式，不代表任何既有專案或保證。另列出變更如何處理：若驗收時提出原範圍之外的欄位或新通知路徑，先記錄請求、影響和決策人，再確認是否調整範圍與排程。摘要最後要連到對應的需求或決策紀錄，讓驗收依據可追溯，避免最後只剩模糊的「看起來可以」。

驗收時保存容易找到的檢查證據，記下日期與提出者；依成果選用測試表、截圖或操作結果。未符合條件時記錄重現步驟、實際與預期結果，分開「需修正」和「新增需求」，再定複驗方式。涉及外部帳號或客戶資料，先確認測試方式與可用資料，避免把敏感資料放進一般交接文件。部分成果已驗收、部分仍等輸入時，逐項標明狀態和依賴，不把未驗收項目寫成完成。

記錄正式移交時點

正式移交時點應由實際接手人確認，而非以寄信、群組訊息已讀或會議結束作為推定。交接紀錄寫明移交人、接手人、版本識別、移交時間、附件或連結、已確認的待辦，以及尚未解除的阻塞。接手人回覆確認時，若仍有疑問，就一併保留在紀錄；這表示資料已交到明確的人手上，未必代表每項工作已可開始。團隊可約定交接成立的最低條件，例如範圍和依據可找到、主要限制已列明、接手人知道第一步與求助窗口。若關鍵輸入尚未到位，記為「已移交，等待輸入」，不要把開始執行與責任接手混為一談。

移交後若再新增資訊，使用新紀錄補充來源與影響，不直接覆蓋舊版；接手人需回覆哪些工作受影響、是否需要重新確認時程。業務也應保留一個清楚的回問窗口，並說明何種問題找誰：範圍疑義回原承諾確認人，資料缺漏找提供者，技術或執行障礙找交付負責人。完成交接後，將核對表存放在團隊約定的位置，並讓相關人員能開啟所引用的文件。下一步可先挑一筆即將啟動的案子，依本文欄位整理範圍、限制與待辦，再由接手人復述第一步；若團隊也在梳理工作流程、網站或 AI／自動化整合，可從 ZhenheAI 官網 了解相關方向。

把三個事件分開記：資料已移交、接手人確認責任與狀態、成果通過驗收；日期不同，各自留下連結、回覆或驗收紀錄。若同意先做部分工作，寫明同意者和仍需等待的項目。接手人尚不能確認時，記下具體缺口與補件責任；不要以改時間戳記假裝完成。回顧時檢查待辦是否有人承接、是否因資料缺漏重做，據此調整表格，並保留版本歷程供後續回查。