同樣寫著「企業網站建置」，兩份報價可能一份只做頁面與視覺，另一份還包含內容整理、後台、主機設定與上線後維護。網站報價怎麼看，關鍵不是先找最低總價，而是把每個項目換成可以交付、可以測試、可以移交的成果。若表格上只有「首頁設計一式」「後台一式」，往往到驗收時才發現雙方對範圍的理解不同。
比較報價前，先建立一張交付矩陣：橫列是工作項目，縱欄分別記錄交付物、負責人、包含次數或範圍、驗收方式、上線後誰維護。要求所有候選供應商依同一張表回覆；沒有列入的工作先標示待議，避免把口頭提到的功能視為已報價。
把建置費與持續費用分開
第一組是一次性建置：需求訪談、資訊架構、設計、內容上稿、功能開發、測試與上線。第二組是可能持續發生的服務：網域、主機、備份、監控、系統更新與內容維護。第三組是條件式工作：新增語系、外部服務串接、資料搬遷或大量頁面增修。這三組不宜合併成一個模糊的「網站費用」。
MDN Web Docs 的 Publishing your website將網域視為網站的網址，主機則是讓網站檔案可供訪客存取的伺服器空間；兩者若由不同業者提供，還需要設定連接方式。報價因此應列出誰註冊或管理網域、誰持有主機帳號、誰負責 DNS 與部署、服務到期由誰續約。這些是要釐清的作業責任，不能從「含上線」三個字推定已涵蓋。
不要猜一個通用的網域或主機價格。實際費用取決於服務商、規格、期間與使用量，應由供應商提供可核對的方案名稱、計費週期及續約處理方式。若使用第三方表單或郵件服務，也應列入外部服務清單，寫明帳號歸屬與超出原方案後由誰決定升級。
用功能情境替代「有做」或「沒做」
一個表單是否完成，不能只看頁面上有輸入框。以「森嶼環境學苑」案例來看，網站有課程梯次、名額狀態、報名及「我的報名」查詢。若拿這樣的流程詢價，矩陣要拆成：誰維護梯次、滿額時前台顯示什麼、重複報名如何處理、訪客如何查回資料、管理員如何匯出或更正紀錄。每一項都對應畫面、資料規則與驗收測試；不能用「報名系統一套」概括。
「曦谷共好教會」案例同時有課程報名、線上奉獻、站內搜尋與無障礙友善版。若實際需求只需要課程報名，就不應把其他案例功能當成預設套餐；若希望搜尋涵蓋活動與影音，也要先說明收錄範圍和更新方式。案例是規格拆解的參考，不代表每個專案都必須採用同樣功能或頁數。
表單驗收可從 W3C 的 Labeling Controls提到的欄位標籤開始：標籤要能說明用途，並與控制項正確連結，讓不同使用方式都能辨識。矩陣中可寫「報名表單的每個必填欄位有可見標籤；錯誤時指出欄位；手機與鍵盤皆可完成；成功後呈現確認訊息」。這比「支援 RWD、優化 UX」更容易共同驗收。
變更與延期要先有決策程序
網站進行中常出現新想法：多一個分類、加一個審核關卡、增加語系或改接新的服務。不是所有變更都該免費吸收，也不是每次調整都要重開整份合約。報價附件可以先約定變更單的格式：提出原因、受影響頁面或資料、增加的工作、費用與時程估算、批准人，以及原定交付是否調整。
若企業提供產品資料晚於約定時間，也應記錄哪個里程碑受影響；若供應商交付未達驗收條件，則記錄缺陷、修正期限和重新測試方式。這些是專案管理建議，不替代個別契約的法律判斷。尾款與完成定義最好連到具體交付，例如測試紀錄、正式環境確認與管理權限移交，而不是只寫「網站完成」。
付款前走一遍移交流程
最容易漏掉的不是版面，而是最後一週。請供應商示範用客戶帳號更新一個頁面、匯出需要保存的資料、查詢備份狀態、確認網域與主機管理入口，並提供故障通報方式。若有程式碼或設計檔交付需求，需在報價時列明格式、範圍、存放位置與依賴的第三方授權；不要等合作結束才問「能不能給檔案」。
最後再把兩份報價放回矩陣：相同項目比交付品質，不同項目比是否必要，未寫明的項目要求補充。如此可以保留成本選擇的彈性，同時讓驗收有客觀依據。真正能比較的不是一行總價，而是這筆支出換得哪些網站能力、由誰維持，以及出現問題時能如何確認和處理。
