先講結論
維護合約真正需要談清楚的只有三件事：哪些項目屬於維護範圍、回應時間為何、超出範圍如何計費。把這三件事寫清楚，比合約的厚度更重要。模糊的「終身維護」承諾在雙方認知不同時，反而是爭議的來源。
先區分瑕疵修正與功能開發
這是最常被混為一談的兩件事。系統原本即應達成、但未正確實作的部分屬於瑕疵修正，本即由開發方負責；上線後因業務調整而新增的需求屬於功能開發，應另行評估時程與費用。
兩者之間另有一段灰色地帶：法規變動與第三方服務改版所導致的調整。建議於合約中明確歸類，例如金流服務商 API 改版是否納入年度維護。
三種常見的維護模式
一、年度維護費
依系統規模計算固定年費，涵蓋瑕疵修正、環境維運與小幅調整。適合流程已趨穩定、每年僅有少量微調需求的系統。
二、工時包
預先購買一定時數，需要調整時扣抵。適合上線初期或業務仍在變動的階段，彈性較高，亦無須為未使用的服務付費。
三、專案式
不簽固定合約，有需求時單獨報價。適合系統相對單純、變動頻率低的情況，但須接受排程等待。
簽約前應確認的五個問題
- 回應時間如何定義：是完成回覆，或是完成修復，兩者差異甚大。
- 問題分級標準為何：系統無法使用與畫面顯示異常不應具有相同的處理優先序。
- 維護是否包含主機、網域、憑證等環境費用，或另行計算。
- 原始碼與資料的歸屬，以及日後轉由他方承接時的交接方式。
- 維護團隊是否為原開發團隊——更換團隊的成本通常高於預期。
我們的作法
我們自諮詢、設計、開發至上線後維護皆由同一團隊負責，不在交付後將系統轉由另一組人員接手。理由相當明確：最了解這套系統為何如此設計的，是當初做出決定的團隊。
