網頁設計報價點睇：逐項分清功能範圍、修改次數與後續支出

網頁設計報價：同樣寫「產品頁」，交付物可能完全不同

兩份網頁設計報價都列出「產品頁」，其中一份指設計一款版面，另一份卻包含資料整理、首次上載及後台欄位設定。只看項目名稱，很容易以為兩者提供相同工作。真正需要比較的，是每個名稱背後的交付物、數量、前提與完成條件，而不是先把不同範圍的總額放在一起判斷。

以下採用沒有金額的假設報價項目，示範如何在旁邊加批註。例子並非 Black Media 套餐或任何供應商的標準條款，也沒有暗示某類工作必然免費或收費。用途是幫公司把看似清楚的名詞拆成可以討論的範圍，令簽約前的問題有具體落點。

閱讀報價時，可準備四種標記：已清楚、需要定義、依賴外部條件，以及暫不包含。每一行都問「完成後拿到甚麼」「由誰提供起始資料」「怎樣判斷完成」。有些答案放在附件或需求文件，未必全寫在報價主頁，但文件之間應可對照，版本及適用次序亦要明確。

報價比較不等於揀公司。如果你仍未核實團隊能力、作品參與範圍與合作分工，可以先看網頁設計公司的面談評估方法。這裏集中處理工作範圍；即使已信任合作方，仍應把包含與不包含的事項說清楚，免得雙方用同一個詞，心裏卻想着不同成果。

批註一：將形容詞改成可指認的交付物

「專業」「全面」「高級」可以表達定位，卻不能直接作交付標準。若報價寫「專業公司網站」，應追問包括哪些頁面類型、功能及管理能力。假設需求只是服務介紹與查詢，便不應自行理解為同時包含會員、預約及付款。描述越接近實際操作，日後越容易核對是否完成。

批註二：先定版本，才逐行討論

同一項目可能有多輪報價，會議亦可能修改範圍。請保留日期、版本及修改摘要，讓每次確認都指向同一份文件。不要以為即時通訊中提過的所有想法，自動包含在最後報價；也不要忽略供應商已正式答應的變更。最實用的做法，是把最後共識整合成可追溯的版本。

「網站頁數」旁邊，要補上頁面類型與資料數量

一款版面，不等於只得一頁內容

產品詳情可能共用同一版面，但每件產品仍有各自資料。報價中的「一款產品頁設計」與「上載全部產品」，是兩種工作。閱讀時應分清版面類型、實際內容頁及首次輸入數量。否則商戶以為所有產品都有人整理，製作方卻以為只需提供一個可自行新增內容的後台。

同樣地，公司簡介、服務詳情及新聞文章可能有不同版型，也可能共用部分元件。你不必規定開發者如何重用程式，但需要知道哪些畫面會獨立設計，哪些沿用共同規則。若某頁有特殊表格或下載資料，應在需求清單標示，避免在版面確認後才發現一般內容欄位無法妥善呈現。

新增內容與新增結構，應分開計算工作

假設已有服務詳情版型，新增同格式的服務內容，可能只是內容操作；若新增一種需要計算、篩選或特殊資料關係的頁面，便可能涉及結構修改。報價應交代哪些工作可由商戶自行完成，哪些需要重新評估。這個界線比單寫「可無限新增頁面」更能反映實際使用能力。

也要問舊資料搬移是否屬首次輸入的一部分。由既有系統匯出後再整理欄位，與從商戶提供的乾淨表格上載，前置工作不同。可交一小份已去除敏感內容的樣本，讓製作方判斷格式及缺漏。若沒有看過原始資料便寫「全部搬移」，雙方應進一步界定保留哪些內容、哪些需要人工核對。

整理清單時，可把每頁的主要內容來源一併標示，例如公司提供文字、設計方負責排版、相片另行安排。若資料尚未齊全，寫明暫用甚麼示例及何時補交。不要讓空白欄位默默變成雙方不同假設，因為它會影響版面長度、製作時間及最後上線內容。

• 版型：哪些畫面需要獨立設計及開發。
• 內容：首次要建立多少項資料，由誰輸入及核實。
• 後續：商戶能否按既有格式自行新增，限制在哪裏。

「功能開發」旁邊，要寫出開始、結果與例外

用一段操作取代一個功能名稱

「查詢表格」可以很簡單，也可以包括附件、分類分流、自動回覆及後台紀錄。應從使用者開始填寫，寫到公司收到並處理資料為止。每一步都問需要顯示甚麼、保存甚麼及通知誰。只寫一個名稱，往往無法說明商戶真正期望的工作結果。

例如假設公司希望客人選擇產品後提交詢價，可寫成：訪客選定產品，填聯絡資料，確認提交，系統保存紀錄並通知指定部門。然後補問同一查詢可否包含多項產品、附件有甚麼限制，以及通知失敗時如何查回資料。這些不是為了無限增加功能，而是找出原本一句話內尚未決定的部分。

正常情況需要有可觀察結果

正常流程應能指出完成後的畫面與資料狀態。若「成功」只代表按鈕有反應，卻沒有確認紀錄或通知去向，商戶便難以知道功能是否真的完成工作。範圍文件可列出必要結果，讓開發者選擇合理實現方式；毋須在沒有技術依據時指定所有內部寫法。

例外情況要挑重要的寫清楚

必填資料不足、重複提交、權限不符或外部服務暫時失效，都可能影響實際使用。毋須為每個想像中的情況寫長篇規則，但涉及資料遺失、重複交易或錯誤通知的情況，應提早討論。例外處理是否包含、需要甚麼資料協助判斷，也應在範圍內有交代。

第三方接駁不能只寫「支援」

接駁付款、物流、會計或其他系統，需要知道使用哪個服務、商戶能否取得權限、資料會往哪個方向流動，以及誰負責測試。某項技術上可接駁，不代表你目前的帳戶已具備所需條件。要求報價列出依賴事項，能避免把外部審批時間誤當成網站製作時間。

討論網上商店的功能範圍時，尤其要把店面操作與營運接駁分開。例如前台可顯示庫存，不代表已與現有門市同步；可以接受訂單，也不代表已自動完成對數。每個「自動」都應寫明來源、觸發條件及人工處理例外的方法，否則不同人會對自動化程度有不同理解。

1. 描述誰在甚麼情況啟動功能。
2. 列出成功後應出現的畫面、資料及通知。
3. 指出必須處理的主要例外與外部依賴。

「設計及修改」旁邊，要分清回合、階段與變更

一輪修改如何開始與結束

「包含修改」並不足以說明合作方式。可以問每輪由誰收集意見、以甚麼文件提交、需要在何時確認，以及修改後如何核對。若部門意見分散到不同渠道，同一項目便可能反覆被推翻。回合安排的用途，是讓意見集中及可追蹤，並非鼓勵雙方用計數方式處理所有溝通。

商戶應把相關人的意見在同一輪整合，供應商則應說明哪些意見互相衝突或影響其他部分。假設已確認產品頁用某套欄位，之後要求改成另一種資料結構，就不只是把顏色調整一次。報價應交代一般修訂與範圍變更的分別，讓公司知道何時需要重新評估時間與費用。

設計稿確認後的修改，可能影響不同工作

在視覺稿階段移動區塊，與程式完成後重整區塊邏輯，所涉及的工作未必相同。請對方說明每個確認點代表甚麼，是否仍可提出意見，以及哪些更改需要另行評估。你不應被迫接受與已同意範圍不符的成果，但也不能把新增方向一概理解為原定修正。

可在報價批註中加一句：「與已確認需求不符的修正，和新增需求的處理方式分別為何？」這能令討論更公平。前者應對照已同意的內容判斷，後者則應說明增加的工作。兩種情況若沒有分開，雙方很容易把所有問題都稱為修改，卻一直無法同意下一步。

批註還可以記錄變更的替代方案。假設新增功能會影響原定日期，可討論先保留人工步驟、縮窄首階段範圍，或延後公開相關功能。每個選項應交代商戶需額外承擔甚麼工作，再作決定。範圍管理並非只有接受或拒絕兩個答案，清楚列出可行取捨，往往更容易取得一致理解。

任何變更最好先寫明原因、涉及頁面或功能，以及對已完成工作的影響，再決定是否執行。避免只在電話中說「順便加埋」，之後才發現需要重做。若暫時不能判斷範圍，便先安排評估，不要要求供應商在資料不足時給出沒有條件的肯定答案。

「內容處理」旁邊，要列明誰整理、誰核實、誰批准

文案、翻譯與上載是不同工作

商戶提供一段公司介紹，不代表已備妥全部服務頁內容。報價中的內容工作可以包括訪談、撰寫、編輯、翻譯、校對及輸入，各自需要不同投入。請逐項問清楚，不要把「協助整理」理解為從零開始完成所有資料。若對方只負責上載，公司便要安排內部核實者。

同樣地，多語言網站的語言切換功能與翻譯內容並非同一交付物。應確認每個版本由誰提供、專有名詞由誰定稿，以及不同語言的圖片或下載文件是否也需處理。即使文字已翻譯，版面長度及連結仍要核對，這部分工作應有安排，不能假設會自動完成。

相片與產品資料要寫清可用條件

相片可能由商戶提供、另行拍攝或按授權使用，報價應說明實際包含哪種工作。圖片裁切與基本整理，不等於完整產品拍攝；找到可下載的圖片，也不代表可用於公司網站。公司應保存素材來源及授權資料，涉及具體權利時按相關條款核實，不能只憑網上可見便當作可自由使用。

產品資料若散在不同檔案，應先定欄位及格式，再討論輸入。假設報價包含上載資料，仍要問是否包括合併重複項目、補足缺漏及核對型號。資料清理的工作量，通常取決於原始資料狀況。先提供有代表性的樣本，會比口頭說「資料不多」更有助合理界定。

• 原稿由誰提供，是否已包括所有語言及必要欄位。
• 內容整理包括甚麼，哪些仍需公司自行核實。
• 素材來源與使用條件由誰確認，文件保存在哪裏。
• 最後批准由誰作出，未批准內容如何標示及暫存。

可以把資料交付時間與項目階段連起來。若產品資料要等拍攝後才有，便要確認設計及開發可先做到哪一步，哪些測試必須等真實資料。這不是單方面要求公司提早交稿，而是讓雙方看見依賴，避免在預定上線前才發現欠缺基本內容。

「SEO及流動版」旁邊，要分清實作項目與結果期待

搜尋準備應寫成具體工作

報價寫「包含 SEO」，可以指基本標題設定，也可能包括內容研究、網址規劃或持續改善。應列明具體項目與交付方式，並分清一次性設定和後續工作。網站具備修改標題與摘要的欄位，不代表已有人替每頁撰寫；建立網站地圖，也不等於保證搜尋引擎收錄所有頁面。

討論搜尋相關成果時，應把可交付的工作與外部結果分開核對。公司可以要求確認指定設定是否完成，卻不宜將沒有條件的排名承諾當成相同服務。若需要內容研究或成效分析，應清楚列入範圍，說明所用資料、檢討方式及商戶需要提供的配合。

手機版不是一句「自動適應」便完成

流動裝置顯示需要考慮選單、長表格、表格輸入及內容次序。報價可說明涵蓋的頁面類型與操作情境，讓商戶知道會如何檢查。不要只以縮窄瀏覽器後沒有超出畫面作完整判斷；一個看得見但難以操作的功能，仍可能妨礙客人提交資料。

在網站設計需求討論中，可提供最常見的手機操作，例如客人從服務頁開始，填查詢並取得確認。這樣較容易界定需要照顧的畫面及輸入狀態。測試範圍應合理且可執行，毋須聲稱兼容所有曾出現的裝置，但不能完全沒有說明。

若有特定效能或操作要求，亦應先定量度條件。不同測試環境可能得出不同結果，單以一張分數截圖難以代表所有使用者體驗。報價中的改善工作要列明檢查對象、可控制部分及外部依賴，避免把沒有共同條件的數字變成日後爭議來源。

「工期及里程碑」旁邊，要把等待資料的時間算進去

開工條件與階段完成條件各是甚麼

某個製作時段可能從訂金、資料齊備或需求確認後才開始，報價應明確交代。不要把收到報價的日期，自動當成所有工作的起點。每個階段也應有可確認成果，例如頁面結構、設計稿或可測試功能，讓公司知道何時需要投入人手作決定。

可以沿網站項目的階段安排檢查報價是否遺漏資料整理、批核及測試時間。這些工作有些由商戶完成，卻仍影響整體日期。若只有設計與程式兩段時間，公司便可能低估自己的準備工作，也難以知道延誤應如何重新排程。

延誤與暫停，要有重新安排的方法

假設公司因產品資料未齊而暫停，應確認已完成工作如何保存、重啟需要甚麼，以及原定資源安排是否仍適用。同樣地，若供應商遇到影響日期的問題，也應有通報及修訂計劃的方法。這類安排不應只在出事後才討論，否則雙方很容易各自等待。

付款里程碑亦應與文件中的階段定義一致。這篇不提供付款比例或金額建議，因為不同項目安排不同；你需要核對的是每次付款對應甚麼、如何確認完成，以及有爭議或變更時按甚麼程序處理。涉及具體合約權利的問題，應就實際文件取得合適意見。

1. 標出每個階段的起始前提及交付物。
2. 列出需要公司批准或提供的資料。
3. 對未能確定的依賴訂澄清時間，更新雙方共用排程。

「後續支出」旁邊，要分開續期、維護與新增工作

網站完成後，哪些項目仍會持續

域名、寄存、電郵、第三方服務及某些授權，可能有各自續期安排。報價應說明哪些由製作方代辦、哪些由商戶直接支付，以及誰接收續期通知。不能只看首期包含甚麼，也要知道後續由誰管理。這裏不需要猜測金額，而是先建立完整項目清單。

對第三方授權，可補問是否綁定特定帳戶、網站或管理安排，以及更換維護者時需要重新申請甚麼。答案應按實際條件核實，不能假設購買一次便永久適用。把這些限制列入文件，並不表示將來一定要更換合作方，而是讓公司知道持續使用網站所依賴的條件。

每個持續項目都應有用途及負責人。假設某項外部服務只是測試期間使用，上線後是否仍需要，應由技術人員確認；若是維持網站必要的一部分，便要避免通知只寄到已離職同事。清楚的續期表可減少漏項，但仍需有人定期核對服務是否符合現況。

保養、故障修正及功能改善不可混稱

網站交付後的問題，可能是原定功能未符合要求、環境改變造成故障，或商戶新增想法。各類工作如何處理，應在報價及相關條款中分清。不要自行假設維護包含任何改動，也不要接受完全沒有定義的「全部另計」。把例子放進討論，較容易找到雙方一致的理解。

可問維護是否包括定期檢查、更新、備份處理、問題排查及內容協助，各項的範圍又到哪一層。若只提供按需要處理，也應知道提出工作的方法及如何確認範圍。這些安排直接影響日後人手，不應等網站完成才開始尋找負責者。

• 定期項目逐項列出，不把不同服務合成一個不明名稱。
• 確認服務中止或更換時，資料及帳戶可如何交接。
• 保存正式文件及最新聯絡方法，避免只留零散聊天紀錄。

簽署前，把不明範圍整理成一頁待答清單

先問影響決定的問題，再處理細節

若報價仍有很多空白，先處理影響架構、主要功能及公司人手的問題。字體細節可以在適當階段確認，但誰整理產品資料、接駁是否可行、後台能更新甚麼，往往會影響整個項目。不要因為容易討論的小問題很快得到答案，就誤以為範圍已完整。

待答清單可寫原文、疑問、期望核實資料及負責回覆者。回覆後把正式共識併入文件，而非留下兩套互相矛盾的說法。若某項需要後續研究，便保留前提及決定時間，不要強行把未知變成固定承諾。可管理的不確定，比表面上沒有空白更實用。

比較的是完整工作組合

當兩份報價範圍不同，先補足差異再比較。某方案由商戶自行輸入資料，另一方案包含整理，便要把公司內部所需工時一併考慮；某方案需要另找維護者，也要看你是否已有合適人手。這並不代表任何一種必然較好，而是避免只比較主頁上的總額。

若決策人只收到摘要，可在摘要旁列出最重要的排除項目與未決前提。例如何種資料由公司自行整理、哪項外部接駁尚待核實，應與總額及日期一起呈現。否則批准者可能以為所有事項已包含，項目人員卻知道仍有缺口。讓決策資料完整，比在後續會議解釋當初文件沒有說清更省力。

最後請實際負責內容、營運及技術協調的人核對自己那部分。老闆能批准預算，未必知道每天更新產品的細節；行政同事知道操作需要，卻未必掌握外部帳戶控制。讓不同負責人各自確認範圍，能減少簽約後才發現有人一直沒有參與的情況。

1. 圈出仍只有名稱、未有交付定義的項目。
2. 補齊資料責任、外部依賴及修改安排。
3. 確認最後版本與附件一致，再作合作決定。

你可以帶同已刪去敏感資料的需求清單及未明項目，向 Black Media 查詢網站製作範圍。先把「產品頁」「後台」「維護」等用語逐項講清楚，才容易得到能反映公司實際需要的工作安排。