合約與驗收

驗收不是「看起來好像可以」

驗收若沒有明確依據，會出現兩種極端：一種是隨便看看就簽收，日後發現問題已無立場主張；另一種是無止境地追加要求，專案永遠結不了案。

合理的做法是採功能性驗收，並以報價單所列項目為依據——報價單上有的，就要能運作；報價單上沒有的，屬於新增需求，應另行議價。

這也是為什麼報價單要列得夠細。只寫「網站設計一式」的報價單，驗收時等於沒有標準。

驗收的四個層面

一、頁面呈現

• 所有規劃的頁面是否都存在（拿樹狀圖逐一核對）
• 各頁面的版面是否與確認過的設計稿一致
• 圖片是否正常顯示、沒有破圖
• 文字有無錯字、亂碼
• 選單、麵包屑、頁尾連結是否都能正確連到目的頁

二、後台系統功能

報價單上每一項系統功能，都要實際操作一次完整流程：

• 新增一筆資料，確認前台正確顯示
• 修改該筆資料，確認前台同步更新
• 刪除該筆資料，確認前台消失
• 調整排序，確認前台順序改變
• 上傳圖片，確認顯示正常
• 測試分類、上下架時間等進階欄位（若有）

只看後台有沒有那個選單是不夠的，要走完新增、修改、刪除的完整循環。

三、表單與通知

• 從前台送出一筆表單
• 確認指定信箱收得到通知信
• 確認通知信沒有進垃圾郵件匣——這一項最常被漏掉，見通知信進垃圾桶怎麼查
• 確認必填欄位的驗證有作用

四、跨裝置與瀏覽器

• 電腦：至少測試兩種主流瀏覽器
• 手機：iOS 與 Android 各測一次
• 平板：若客群會使用
• 檢查手機版的選單、表單、圖片是否正常

現在多數流量來自手機，手機版沒測就驗收，等於沒驗收。

容易被遺漏的驗收項目

• SSL 憑證——網址列有鎖頭、http 會自動轉 https
• www 與非 www——兩種輸入方式都能開啟
• 404 頁面——輸入不存在的網址時，是否有妥善的錯誤頁
• 網站標題與描述——各頁面是否都有設定，而非全站共用一組
• 搜尋引擎封鎖是否解除——測試期間的封鎖設定若帶到正式站，整站不會被收錄。這是改版最嚴重的失誤之一
• 網站地圖檔案——是否已產生
• 後台帳號——是否已交付，密碼是否已更改
• 操作說明或教育訓練——是否已完成

驗收期與修正期

合約通常會約定一段修正與測試調整期間，讓雙方在上線後仍能處理發現的問題。這段期間的意義在於：有些問題要實際使用一段時間才會浮現。

建議在這段期間內：

1. 把後台的每個功能都實際用過一輪
2. 請兩三位同事從不同裝置瀏覽並回報
3. 把所有問題彙整成一份清單，一次提出，而非逐條零星回報

第三點對雙方都有利——零星回報會讓修正變得沒有效率，也難以判斷何時算完成。

提出修正時的表達方式

清楚的問題描述可以大幅加快處理速度。建議包含：

• 在哪一頁（附網址）
• 用什麼裝置與瀏覽器
• 做了什麼操作
• 預期結果與實際結果
• 截圖

相對地，「網站怪怪的」「排版跑掉了」這類描述，廠商需要來回確認才知道問題在哪。

修正與新增需求要分清楚

兩者的界線就是報價單。這也是為什麼發包階段把報價單列細，對雙方都是保障。

驗收完成後應取得的東西

• 後台網址與管理員帳號
• 網域註冊商與主機商的資訊
• 依合約約定應交付的原始碼檔案
• 操作說明
• 保固起訖日期的書面確認

這些資料建議整理成一份文件保存在公司內部，不要只存在承辦人的個人電腦。人員異動時，這份文件的價值會顯現出來。

本文說明業界常見的合約結構與實務作法，供發包時參考，不構成法律意見。實際條款請依個案需求擬定，必要時建議諮詢專業人士。

兩個名詞，兩種不同的東西

「保固一年」和「維護一年」聽起來很像，實際上處理的是完全不同的事。搞混這兩者，是驗收後最常見的認知落差。

一句話區分：「本來就該會動卻不會動」是保固；「本來就是這樣但我想改」是維護。

保固通常涵蓋什麼

保固的依據是報價單所列的功能項目。保固期內若發現瑕疵，廠商應在約定時間內回應並提出修正方案。

常見的合約會約定：網站因瑕疵而無法使用的期間，不計入保固期——這是合理的設計，避免修復期間白白消耗保固時間。

保固通常不涵蓋什麼

以下情況多半排除在保固之外：

1. 業主自行修改程式或更換執行環境——例如未經廠商確認就搬到其他主機、或自行改動程式碼
2. 業主提供的資料不正確，經通知後仍未修正
3. 非原始設計目的的使用——把形象網站當成大流量的下載站之類

這些排除條款是合理的——問題若不是源於廠商的施作，要求廠商免費處理並不公平。但反過來說，業主在保固期內要自行改動程式前，最好先跟廠商確認，以免影響保固效力。

維護服務的內容差異很大

各家的「維護」定義落差極大，簽約前務必問清楚。常見的幾種形式：

一、含一定額度的內容修改

例如約定期間內提供一定字數的文字修改。這種寫法的優點是界線明確，但要注意額度的計算方式與排除項目——常見的排除包含：新增圖片、變更架構、新增系統功能、增加其他語言版本。

這些排除是合理的，因為它們的工作量與單純改文字差距很大。重點是事先知道，而不是要改的時候才發現不含。

二、技術性維護

• 系統與外掛的安全性更新
• 定期備份
• 異常監控與故障排除
• 主機環境調整（例如 PHP 版本升級的相容性處理）

三、諮詢服務

操作問題的解答、技術建議。有些廠商含在維護方案，有些按次計費。

簽約前該確認的五個問題

1. 保固期從哪一天起算？ 是驗收日、上線日、還是次日
2. 保固期內回應時間多久？ 例如收到通知後幾日內派員了解
3. 維護含哪些、排除哪些？ 特別是圖片、架構、系統功能的界線
4. 維護額度用完之後怎麼計費？
5. 保固期滿後的維護方案是什麼？費用多少？

第五點常被忽略。合約通常會寫「保固期滿後的維護另訂合約」，這是正常的，但建議在簽約時就問到大概的價格區間，避免日後失去議價空間。年度支出的完整清單見網站每年的固定支出有哪些。

不買維護方案會怎樣

網站不會因此停止運作。只要網域與主機還在，網站就會持續正常開啟。

不買維護的實際風險是：

• 系統出現安全漏洞時，沒有人主動更新
• 網站被入侵或資料損毀時，沒有備份可還原
• 需要協助時，按次計費且可能需要排隊

是否需要，取決於網站對業務的重要程度，以及公司內部有沒有人能處理。如果網站是主要的詢價來源，維護方案的成本相對於停擺一週的損失，通常是划算的。

一個實務建議

保固期內請主動且完整地把網站用過一輪，不要等到保固快到期才發現問題。

特別是那些平常不會用到的功能——年度才用一次的表單、很少更新的單元、後台的進階設定。這些地方的問題若在保固期內發現，是免費修正；保固期後才發現，就可能要另計費用了。

本文說明業界常見的合約結構與實務作法，供發包時參考，不構成法律意見。實際條款請依個案需求擬定，必要時建議諮詢專業人士。

付款節點的設計，是雙方的風險分攤

網站架設是一段持續數週到數月的工作，中間沒有實體交付物。付款方式的設計，本質上是在處理一個問題：如果中途出狀況，誰承擔多少損失。

理解這一點，就比較容易判斷一份付款條件是否合理。

常見的分期方式

兩期制（各 50%）

• 簽約金 50%——合約簽訂後一定期間內支付
• 尾款 50%——驗收無誤後支付

最常見的形式，適用於一般規模的企業網站。優點是單純，雙方風險相對均衡。

三期制

• 訂金 30～40%——簽約後
• 設計確認金 30%——版型設計稿確認後
• 尾款 30～40%——驗收後

適用於金額較高、工期較長的案子。中間增加一個節點，讓雙方在設計階段結束時就先結算一部分，降低後段的風險累積。

要留意的形式

• 尾款比例過低（例如 10%）——業主的最後籌碼太小，驗收時議價能力弱
• 要求全額預付——除非金額很小或已有長期合作關係，否則風險偏高
• 沒有明確的付款觸發條件——「完成後付款」的「完成」若沒有定義，容易產生爭議

付款節點應該綁定什麼

關鍵在於：每一期付款都應該對應一個可客觀認定的事件，而不是時間。

「經業主確認」「依驗收條款」這類字眼很重要，它們把主觀判斷變成了有程序可循的事件。驗收的作法見網站驗收怎麼做。

付款期限也要寫

合約通常會約定「甲方於 X 日內以匯款或支票方式支付」。這個期限對雙方都有意義：

• 對廠商：確保現金流可預期
• 對業主：確認付款義務的起算點，避免被主張逾期

另外建議註明金額是否含稅，以及發票開立的時點。這兩項若沒寫清楚，實務上常有落差。

延遲的處理

廠商延遲

常見作法是約定遲延每日按總價一定比例扣款，並設定累計上限，達上限時業主有權解約。

這條的重點不在罰金多寡，而在於它讓「延期」有具體代價。沒有罰則的合約，延期就只剩下口頭催促。

業主延遲

要留意合約是否有對稱的時程順延機制。實務上進度落後有很大比例源於業主端——資料未到位、審核未回覆。合理的合約會約定：若業主未於一定期間內提出審核結果而影響進度，專案時程得順延相同日數。

這對雙方都公平。業主應該在簽約時就評估自己的內部作業速度，並提前準備素材，見網站規劃階段要準備哪些資料。

第二年起的費用要在合約中寫明

建置費之外，網站空間、憑證更新等年度支出的續年金額，應該在簽約時就載明。

這是保護雙方的做法：業主可以預估長期成本，廠商也避免日後被質疑價格。完整的年度支出項目見年度固定支出。

發包前的六個確認

1. 分幾期？各期比例多少？
2. 每期的觸發條件是什麼？是否可客觀認定？
3. 付款期限多久？
4. 金額是否含稅？發票何時開立？
5. 廠商延遲有無罰則？業主延遲有無時程順延？
6. 第二年起的固定支出是多少？

六個問題都有明確答案，付款條件就算完整了。若有任何一項含糊，建議在簽約前釐清並寫入合約，而不是靠口頭承諾。

一個常見的誤解

「先付一半錢，萬一廠商跑了怎麼辦？」

這是合理的擔憂，但反過來想：廠商投入數週人力後，若業主拒付尾款，損失同樣真實。分期付款的設計就是讓雙方各自承擔一部分風險，任何一方都不會在毫無保障的狀態下投入。

降低風險的實際做法不是壓低訂金比例，而是：確認廠商的營業登記與實績、把工作項目寫細、設定明確的驗收標準、以及保留合理比例的尾款。

本文說明業界常見的合約結構與實務作法，供發包時參考，不構成法律意見。實際條款請依個案需求擬定，必要時建議諮詢專業人士。

網站做完之後，什麼東西是你的

這個問題在合作順利時不會有人問，但在想換廠商、或廠商結束營業時，會變成最關鍵的問題。

網站牽涉的權利歸屬，可以拆成四個不同的東西，各自的處理方式不同：

網域是最該優先確認的

網域拿不回來，等於品牌的網路門牌被別人握著。合約中最好直接載明註冊人登記為業主公司；即使合約沒寫，也應在網站上線後自行以 WHOIS 查詢確認。

這一點的完整說明與糾紛處理方式，見網域要自己註冊還是交給網頁設計公司。

原始碼的交付

合約應寫明是否交付、何時交付、以什麼形式交付。常見的約定是：驗收完成後，廠商提供網站或系統的原始碼檔案予業主。

「提供原始碼」不等於「提供技術支援」

這是需要理解的界線。合約中常會註明不包含程式開發教學與技術文件——意思是廠商交付可運作的程式檔案，但不負責教你如何開發、修改或說明程式架構。

這是合理的：撰寫技術文件與教學本身就是額外的工作量。若業主確實需要，應該在簽約時提出並另行議價。

拿到原始碼實際上能做什麼

• 搬到其他主機繼續運作——這是最主要的價值
• 交由其他廠商接手維護或改版
• 作為資產保存，避免完全依賴單一廠商

相對地，租用型平台通常不提供原始碼，這也是它與一次性建置最根本的差別，見便宜網站的隱藏成本。

開放原始碼核心的著作權處理

許多網站是基於開放原始碼的系統核心開發的。這種情況下，合約通常會載明：業主付清價款後保有本案的修改權，而因使用開放原始碼核心，著作財產權依該開放原始碼的授權規範為準則。

這句話的意思是：

• 核心系統本身的授權，遵循原開發社群的規範（通常允許自由使用與修改）
• 廠商為此案所做的開發成果，業主付款後可自行修改
• 業主不能主張擁有核心系統本身的著作權——因為那本來就不屬於廠商

這是常見且合理的安排。發包時可以理解為：你買到的是使用與修改的權利，以及不被單一廠商綁住的自由。

雙向的著作權保證

完整的合約會有對稱的兩條：

1. 業主保證提供的資料與企劃不侵害他人權利，若引起糾紛由業主負責
2. 廠商保證設計的網頁與程式不侵害他人權利，若引起糾紛由廠商負責

各自為自己提供的內容負責。若合約只寫其中一方，就要留意風險是否被單方面轉嫁。

對業主而言，第一條的實際意義是：從網路下載的圖片、抄來的文案，責任在自己。素材的準備原則見網站規劃階段要準備哪些資料。

保密義務

廠商在開發過程中會接觸到業主的營業資料。合約通常會約定廠商負保密責任，非經書面同意不得複製、備份或向他人揭露，且此義務及於廠商的員工。

若網站涉及客戶資料、報價系統、內部流程，這一條特別重要。

合約終止

一般終止

常見約定是：合約有效期間內雙方不得任意終止，如需終止應提前一定日數以書面通知，並結算至終止時已發生的費用。

「結算已發生費用」是關鍵——中途喊停時，已投入的工作仍應計價。這對雙方都公平。

可歸責於一方的終止

若終止的原因可歸責於廠商，業主通常不需負擔廠商所發生的費用與損失。反之亦然。

違約的處理程序

一般會約定：一方違約時，他方應先定相當期間催告改正，逾期未改正才得解除合約並請求損害賠償。

這個「先催告」的程序很重要——它避免因單一爭議就直接破局，也讓雙方有修補的機會。

終止或換廠商時，應取回的清單

1. 網域的註冊商後台帳號與移轉授權碼
2. 主機控制台帳號（若主機在自己名下）
3. 網站原始碼與資料庫完整備份
4. 網站後台管理員帳號
5. SSL 憑證資訊
6. 各項第三方服務的帳號歸屬確認

建議以書面提出並留下紀錄。若合作已經不愉快，書面往來在後續若有爭議時是必要的依據。

更根本的做法是：在簽約階段就把這些權責寫清楚，讓終止時無須爭論。合約應涵蓋的完整條款見網站設計合約應該包含哪些條款。

本文說明業界常見的合約結構與實務作法，供發包時參考，不構成法律意見。實際條款請依個案需求擬定，必要時建議諮詢專業人士。