客製化系統發包前的 SOW + 規格書 + 合約完整指南：5 條規格紅線、4 個驗收里程碑、3 條罰則模板——中小企業老闆不被廠商拖延加價的最後一道關

我們最近陪一位做連鎖餐飲的客戶做客製化中央廚房管理系統的「廠商比稿後合約審查」——他先前已經跟兩家工程廠商各開了三次會，每家都丟回一份 30 頁的「需求建議書」。客戶問我們：「這份簽下去就可以開工了吧？」打開來看——是廠商寫的功能介紹簡報，不是 SOW、不是規格書、更不是合約。換句話說，簽下去那一刻，廠商還沒承諾任何具體交付物、任何驗收條件、任何遲交罰則。客戶當下的反應是：「啊？我以為這就是合約。」

過去兩年我們陪客戶評估客製化系統合約，最常看到的不是合約寫得不嚴謹——而是根本沒分清楚 SOW、Spec、Contract 是三份不同文件。SOW（Statement of Work）規範「做什麼、什麼時候交、誰負責什麼」；Spec（規格書）規範「交出來的東西長什麼樣、有哪些驗收條件」；Contract（合約）規範「錢怎麼付、出事誰賠、智財權歸誰」。三份缺一份廠商都有理由拖延加價，但業界八成的中小企業外包案只簽其中一份（通常是合約），剩下兩份用 LINE 群組「再討論」——這是後期被拖延加價的主要破口。

這篇要把客製化系統發包前 SOW + 規格書 + 合約這三份文件的內容拆清楚——5 條規格紅線、4 個驗收里程碑、3 條罰則模板，給中小企業老闆一個發包前的最後檢查清單。先給結論：根據 PMI（Project Management Institute）2024 軟體外包失敗率報告，全球 67% 的外包軟體專案會延遲或超預算，其中「規格與合約定義不清」是首要原因（佔 41%）——換句話說，這三份文件不是法務的事，是老闆能不能拿回投資的事。

SOW、規格書、合約是三份不同的文件，缺一份都是漏洞

第一個要打破的迷思是「需求書就是合約」。我們的判斷是：這三份文件分別保護你的三個面向——時程、品質、金錢，缺任何一份廠商都有正當理由不負那塊的責任。MIT Sloan 對企業 IT 外包合約失敗的長期研究結論一致——他們把「規格／合約分離不清」列為 IT 外包失敗的 top 3 結構性原因。

實務上我們建議的順序是：先把 SOW 跟 Spec 寫到 80% 完成度，再用這兩份去談合約金額——而不是反過來先簽合約再寫規格。先簽合約再寫規格的案子，廠商有 100% 的籌碼把規格灌水，因為合約金額已經鎖死、利潤要靠縮減交付來保。

5 條規格書必寫紅線：缺一條都會在驗收時吵架

以下五條是我們陪客戶實際做合約審查時，反覆會退回去要求補的規格紅線。每一條都對應一個典型「驗收時吵架」場景——你如果讀完發現自己手上的規格書沒寫，這份就還沒到可簽狀態。

• 紅線 1：可量化的驗收條件（acceptance criteria）。不是「系統可以接受訂單」，而是「100 並發下單，95 分位回應 < 300ms，錯誤率 < 0.1%」。沒有數字就會無限重來。
• 紅線 2：邊界外（out of scope）清單。明白寫出「這版不做的功能」——例如「不含發票模組」「不含跨平台 App」。沒寫的東西廠商很容易在交付時說「啊那個本來就要另外報價」。
• 紅線 3：第三方依賴清單。用了哪些 SaaS、API、外部服務、open source license——這份直接連動智財權與供應鏈安全。沒列清楚交付後客戶才發現要自己付 OpenAI 月費。
• 紅線 4：資料模型與遷移義務。舊系統的資料要不要遷？遷到哪？欄位對應表誰做？這條沒寫，上線那天會發現舊系統一堆歷史資料根本不能直接套進新欄位。
• 紅線 5：交付物清單（source code、build script、文檔、部署 SOP）。「系統」交付了不代表「source code」交付了。明寫要交：完整 source code 上 git、CI/CD 配置、部署手冊、API 文檔、操作手冊、第三方憑證清單。少一樣未來換廠商就斷供。

4 個驗收里程碑：把廠商拖延風險切成可控制的段

中小企業老闆最容易踩的坑之一是「上線那天才驗收」——前 90% 開發過程沒有 checkpoint，最後一週爆出規格落差。我們的判斷是：客製化系統發包要把驗收切成至少 4 個里程碑、每個里程碑綁部分款項，這樣廠商不能把風險全部押到最後。

這個 20/30/30/20 的付款結構是我們做客製化軟體接案這幾年下來的標準提案——可以視專案大小微調，但「上線前已付款 ≥ 70%」是底線。低於這個比例廠商會被現金流壓垮、品質會掉；高於這個比例（例如有些業界做 30/30/40 把尾款拉很重）廠商會在保固期一直拖。

3 條合約罰則模板：把廠商拖延加價的籌碼提前收掉

罰則不是要當壞人——是要把「廠商即使拖也不會吃虧」的籌碼提前收掉。沒有罰則的合約對廠商是「拖也賺、不拖也賺」，拖就成了理性選擇。以下三條是我們建議寫進主合約的最低標：

• 罰則 1：遲交違約金按里程碑日均算。不要寫「逾期一日罰新台幣 5000 元」這種文青條款——按該里程碑款項日均的 0.1-0.3% 算，例如該里程碑款 100 萬、每日罰 1000-3000 元，整段封頂 10-15%。
• 罰則 2：規格變更（CR）走書面 + 不超過 15% 預算。Change Request 必須書面提出 + 雙方簽署、單筆 CR 不超過合約 5%、累積不超過 15%。超過 15% 廠商必須重新走完整變更程序、客戶有權暫停付款談判。
• 罰則 3：上線後 90 天瑕疵保固 + 第二年付費維護。90 天內所有瑕疵免費修補（不含新功能、不含環境變動造成的問題）、第二年起轉年度維護合約。沒寫保固期廠商可以「上線當天有問題就是新功能要報價」。

發包前一週的時間，省下後期六個月的爭吵

中小企業老闆做客製化系統發包最常見的心態是「想趕快開工」——我們完全理解，但這個趕在 SOW + 規格 + 合約這道工序省不得。我們陪客戶實際走過的案子，發包前花一週把這三份文件對齊，可以省下後期六個月的規格爭吵與付款爭議，這個 ROI 是六位數研發工時級的。這跟我們先前寫過的客製化系統「源碼託管」完整指南是同一條防線——前者保你 source code 有保險、這篇保你交付過程有可執行的約束。

想要我們幫你做客製化系統發包前的 SOW + 規格 + 合約審查，可以從 客製化系統諮詢服務頁 預約半小時諮詢，我們會帶你把現有的需求文件分類進三份文件、標出缺漏紅線。