廠商換手「接手第一週」SOP：6 個治理動作、5 條合約條款、4 個決勝點，中小企業老闆把新外包團隊從『簽約即冷感』變『第一週就上軌道』

最近我們陪一家中小企業老闆換軟體外包，前廠商在 5 月底交完最後一版，6 月 1 日新廠商接手。第一週還沒結束，老闆 line 我們說：「新廠商在問前廠商的東西，但前廠商已經不回信了。」 他以為換廠商最痛的是『驗收能不能過』，結果真正卡死他的，是換手後沒人想到的『前一週空窗』。

換廠商這件事在 2026 年的中小企業裡愈來愈常見，SaaS 倦怠、客製化系統長期失修、外包團隊集體跳槽，每一條都是換手的觸發點。但市面上談「換廠商」的內容幾乎全在談「要不要換」、「怎麼簽合約」，談的都是「換之前」的事。我們做過 15 件系統開發客製案、處理過不只一次的廠商交接，看下來，第一週才是決定整段新合作會走多遠的真正關鍵。

我們的判斷直接放這裡：換廠商失敗的 80% 是業主自己沒把『第一週』當成一個獨立的治理週期，而非新廠商不夠強。一般人把第一週當成「新廠商開始上工」，所以給他一份合約、一份 SoW、一個程式碼 repo，就以為交接完了。事實是，新廠商接手後的第一週本質是「接管」，不是「上工」，他要在 5 個工作天內，把前廠商累積 6 個月到 3 年的隱性知識，全部吸進腦袋。沒有 SOP，誰來都會卡。

產業層的數據也是這個方向。Gartner 2024 IT Spending Forecast 指出，全球企業 IT 服務支出 2024 年突破 1.5 兆美元，這個數字背後是大量的外包合約週期更替；Deloitte Global Outsourcing Survey 2024 進一步指出，超過 40% 的外包關係在 18-24 個月內會經歷至少一次廠商更換或重新議約。換手是中小企業 IT 治理的標準週期，而非稀有事件。

接手第一週要修一個誤解：新廠商不是「上工」是「接管」

在開始拆 6 個治理動作前，先把『接手』跟『上工』的差異講清楚。上工是給他工作做，接管是讓他先接住現有狀態。差別是後者要花 5 個工作天什麼產出都拿不出來，這時候業主很容易焦慮，覺得錢花了沒看到動靜。但這 5 天如果省下來、直接讓新廠商開始寫 code，第二個月就會在前廠商埋下的雷上撞滿頭包。我們看過最痛的一個案例是某新廠商第一週就被催著上 hotfix，結果改到一個前廠商寫死的 hardcode 環境變數，整套 OAuth 認證掛掉 6 小時。

第一週的本質是「吸收 + 鋪底 + 對齊」，不是「執行」。執行從第二週開始才合理。要支撐這條原則，業主需要做 6 個治理動作，且這 6 條要在合約生效後 48 小時內全部就位。

6 個治理動作：48 小時內必跑的「文件 / 帳號 / 程式碼 / 環境 / 任務 / 客戶」清單

接手第一週的 6 個治理動作，要在合約生效的 48 小時內完成。我們把這 6 條做成一張表，老闆當週用 line 跟新廠商 PM 對表，每完成一條就打勾，沒打勾的條目就是下週爆雷的伏筆。

6 條裡面，文件移交跟客戶聯絡是最容易被低估的兩條。文件移交看起來像「把 Confluence / Notion 整理乾淨給新廠商」，但實際上前廠商寫的文件 80% 都是「他自己看得懂的版本」，術語不一致、新人讀不懂、最關鍵的「為什麼當時這樣設計」通常沒寫。我們的經驗是，文件移交的真正交付物是「新廠商讀完後能寫得出一份自己看得懂的版本」，而非「前廠商既有文件的副本」。驗收標準是新廠商能不能複述，而非文件有沒有交。

#710 客製化系統開發交付驗收完整 SOP 我們已經把驗收階段拆得很細了，那篇處理的是「前廠商交給業主」那一段，不是「業主交給新廠商」。兩段是不同的工作，常被混為一談，本文補的就是後半段。

5 條合約條款：簽約前就要把第一週的權利義務寫死

新廠商接手的合約如果只寫「工時、人月、月費」，第一週很容易卡在「誰該回前廠商的問題」、「新廠商要不要做前廠商沒做完的票」這類灰色地帶。建議直接在合約裡塞 5 條跟第一週相關的條款，把灰色寫成黑白：

進一步參考：#403 軟體外包驗收後的維運合約怎麼簽 與 #891 軟體外包 PM 配置完整指南 講「常態合約怎麼寫」，本文補上「接手第一週這個獨立週期」要怎麼寫，三篇合起來才完整。

4 個第一週決勝點：你能不能從第二週開始放手

如果第一週做到位，業主第二週開始就能從「盯著新廠商」退回「正常 review」。要判斷第一週是不是真的做到位，看 4 個訊號，4 條都達標才算過關，少 1 條就要再壓一週緩衝。

決勝點 1 ， 新廠商有沒有自己跑出一次完整 deploy

是新廠商主動找出一個改動點、走完 PR → review → CI → staging → production 的完整流程，而非「業主給的 hotfix」。沒跑過一次，第二週只要碰真實 incident 就會卡。判定基準很簡單：第一週有沒有出現新廠商獨立 deploy 的 commit 紀錄。沒有，就退回延長一週。

決勝點 2 ， 新廠商能不能用自己的話複述前廠商的系統架構

找一個 30 分鐘的會議，讓新廠商 PM 對著架構圖講給業主聽，業主帶 2-3 個沒寫在文件裡的 why 問題追問。聽起來像背書代表他還在背，業主聽得懂、追問得到答案代表他真的吸進去了。這個會議建議錄影存檔，未來如果第三波交接還用得到。

決勝點 3 ， 三層環境（dev / staging / production）有沒有重新建一次

是新廠商自己 provision 一次 staging，而非「沿用前廠商的環境」。一是排除前廠商殘留的 access，二是確認部署文件可重現。這條是換廠商失敗最常被忽略的一條前廠商環境裡藏的 hardcode 變數、過期的 SSL 憑證、沒清乾淨的 cron job，是第二個月才會爆的雷。第一週就把 staging 重建，等於主動把這些雷炸出來。

決勝點 4 ， 客戶有沒有收到「換手通知 + 新窗口」

業主自己寫一封信，把新廠商 PM 介紹給前段已建立關係的客戶。客戶如果第一週還在打前廠商的 line，第二週業主自己會被夾爆，新廠商不知道有這個客戶承諾、前廠商離開不想再幫忙、客戶卡在中間覺得被丟包。換手通知是治理動作，而非行政動作。

這 4 個決勝點裡，第 3 條我們踩過很重的雷，曾經有一次接手系統時沒重建 staging，結果第二個月 production 改一個 cron 排程，整套 backup job 全部失效，業主損失 3 天的訂單資料。從那之後，我們的內部 SOP 第一週必含「環境自建驗收」，沒做完不算第一週交付。

換廠商不是「重新開始」是「兜底前一段」，3 條業主自己也要做的事

很多老闆以為換廠商是「重置」，前廠商的問題清掉、新廠商從零開始。實際上換廠商更像「兜底」：前廠商累積的負債（技術債、流程債、客戶承諾債）會被新廠商一口氣繼承。如果業主自己不在第一週做 3 件事，新廠商接手後第二個月就會說「這不是我們做的，我們也修不了」。

業主自做 1 ， 整理前廠商的「未爆彈清單」

列出前廠商離開前還沒解決的 bug、p1 issue、客戶投訴、即將到期的 SSL/憑證/SaaS 訂閱、需要續約的第三方服務。這份清單交給新廠商當作「接手第一週的優先任務排序依據」。沒這份，新廠商會自己決定優先順序，常常跟業主想的不一樣。

業主自做 2 ， 建立「決策歷史」摘要

過去 12 個月做過的重大架構決策、為什麼這樣做、有哪些被否決的方案。新廠商接手後最危險的一句話是「我覺得這裡可以重構」，重構是對的，但前提是他得先理解為什麼當初不那樣做。#901 員工離職帶走系統知識的防禦框架 講的是「員工」的版本，本條是「廠商」的版本，邏輯一樣。

業主自做 3 ， 準備 60 天的「回頭找前廠商」預算

第一週不可能問完所有問題。預留前廠商 60 天的「限額諮詢預算」（例：每週 2 小時、共 8 次），在合約結束前就約進去。沒這條，前廠商離開後新廠商遇到無解問題只能猜。這筆錢遠比第二個月真實 incident 的 downtime 成本便宜。

#917 客製化系統上線後 3 個月隱性成本指南 把上線後 3 個月的成本拆得很細，換廠商可以視為「重啟一次上線後 3 個月」，所以那篇的 6 條維運帳本，也適用於本文的「第二個月起算」。「換廠商 = 第二次上線」這個 framing 對中小企業老闆判斷預算特別有用。

整篇談的都是「中小企業老闆 / 採購評估者」視角，主詞是業主、KPI 是「第二週能不能放手」與「第二個月重複事故能不能 -50%」、決策層級是 IT 採購委員會、CTA 落點是 系統開發 與 AI 顧問服務。個人開發者換工作不存在「接手第一週」的合約議題，這篇不打 C 端。