香港企業網站需求書：8 項資料與上線驗收清單
本次更新：重新擷取實際桌面與手機畫面，加入 AI 初稿驗收、可複製需求底稿及報價範圍連結。
直接答案：委託香港企業網站設計前，先準備網站目標、目標客戶、頁面清單、文字與圖片、功能、品牌素材、預算和上線時間。報價應列明誰提供內容、手機版、修改次數、網域與後台歸屬，以及上線後支援。交付時按同一份清單在桌面和手機實測。
網站需求書不必寫成技術規格書。它的作用，是讓你和設計公司在同一份文件上回答「網站要幫誰完成甚麼事」，並把未確定的地方列出來。若只說「做一個像某網站那樣的網站」，不同公司會假設不同的頁數、功能與內容工作，得到的報價自然無法比較。下面八部分可直接作為首次溝通和最後驗收的共同底稿。
從實際畫面看網站需求
先看目標
活動影像引入後，訪客要能找到服務、案例與查詢方式；設計需要為下一步服務。
再看手機
同一批重要資訊要在手機保持可讀，並以適合單欄的次序顯示。
最後驗收
用真實文字、相片及連結逐項核對，不能只看一張漂亮的情境圖。
一、網站要讓訪客完成甚麼？
先選一個最重要的行動：提交查詢、預約、致電、報名、瀏覽產品，還是下載資料。首頁可以承載多項資訊，但主要行動不宜同時有五個同樣顯眼的按鈕。你可以寫一句話：「我們希望第一次來訪的香港中小企負責人，在看完服務及案例後，填寫網站查詢。」這句話比「設計要高級」更能指導資訊排序。若網站要服務兩類客戶，請分別寫出他們的問題和路徑；不要假設兩者都會從首頁讀到頁尾。
| 網站目標 | 訪客下一步 | 應核對的頁面 |
|---|---|---|
| 獲得查詢 | 提交表單或主動聯絡 | 服務頁、聯絡入口 |
| 建立信任 | 查看作品與團隊資料 | 案例頁、關於我們 |
| 完成報名 | 選擇活動並確認資料 | 活動頁、報名流程 |
二、訪客最先想知道甚麼？
把「所有人」收窄成一至兩個真正會作決定的群體。企業採購者可能先找規格、交期和供應能力；家長可能先找日期、地點和安全安排。這些問題會決定導航名稱、首頁順序及表單欄位。請提供客戶實際常問的五條問題、成交前要看的證據，以及不能公開的資料。不要把內部產品分類直接當成客戶理解的服務名稱；先用真實查詢驗證字眼。網站可以有英文和中文，但各語言都應有完整、有用的內容，不應只翻譯選單。
- 客戶是誰寫職責或情境，不只寫年齡。
- 客戶想知道甚麼從電郵、WhatsApp、銷售電話整理真問題。
- 客戶信甚麼準備可展示的作品、流程、資歷或服務條件。
三、要做哪些頁面？如何讓訪客找到？
列出首頁、服務、個別產品、案例、關於我們、常見問題及聯絡頁，然後在每頁旁寫「它回答哪個問題」。若兩項服務的規格、對象和報價方式不同，通常值得分開寫清楚；若只是改一個區名、正文幾乎相同，勉強拆成多頁反而增加維護負擔。網站地圖不是越長越好，而是令客戶以最少步驟找到答案。技術上，網站應讓重要頁面透過一般連結到達，並讓 sitemap、正式網址及頁內 canonical 指向同一版本。Google 的 sitemap 指引及 canonical 指引都把這些視為搜尋引擎識別偏好網址的訊號；它們並不保證排名。
四、文字、照片與 Logo 由誰準備？
內容是最常被低估的工序。請逐頁標記「已有定稿文字／需整理現有資料／需要重新撰寫」，並記錄審批人。照片要註明來源、用途及授權，尤其是人物、學校和客戶活動影像。Logo 應提供原始向量檔或可用的高解析版本；不要從社交平台頭像截圖再放大。若有多語言，請列明哪一方提供翻譯、由誰校對專有名詞。圖像的替代文字要描述資訊或功能，而純裝飾圖可留空；可參考 W3C WAI 圖像教學。沒有內容的頁面無法只靠好看的版型變得清楚。
| 頁面 | 文字狀態 | 素材 | 最後確認人 |
|---|---|---|---|
| 首頁 | 服務介紹待精簡 | Logo、主圖已備 | 品牌負責人 |
| 服務頁 | 規格需核實 | 實際項目照片待授權 | 服務主管 |
| 聯絡頁 | 電話及地址待確認 | 地圖和營業時間 | 行政同事 |
五、手機版是否保留同樣重要的答案？
只把桌面畫面縮窄，不等於完成手機體驗。手機上要重新看標題是否易讀、選單能否操作、按鈕是否容易按、表格是否能橫向瀏覽，以及聯絡方法是否在讀者需要時出現。Google 的 mobile-first indexing 指引指出，搜尋系統主要使用網站的手機版本內容；因此手機版不應隱藏桌面版才有的重要說明。驗收時應拿一部真手機逐頁檢查，而不只看設計工具中的縮小預覽。不同尺寸的畫面可重排，但服務條件、價格說明和行動入口要保持一致。
把同一頁的三項資料對起來
- 標題：桌面與手機都保留「每一場矚目的盛事」及「製作團隊」。
- 正文：手機分行呈現同一段服務說明，並非只剩背景圖。
- 行動：兩個完整按鈕分別是「預約製作諮詢」與「查看製作實錄」，不應被螢幕邊緣截斷。
2026-10-17 於集團品牌 HK EventPro 實際首頁擷取；手機視窗 420×840，上方裁切 420×650。背景輪播可能不同，對照重點是同一頁的內容及行動。未改動畫面；未提交真實查詢。
六、表單、預約、付款與後台要做到哪一步？
「需要表單」仍然太籠統：欄位有哪些、送出後到哪個收件箱、客戶是否收到確認、誰要處理資料？預約要不要即時顯示空檔、收取訂金或連接現有日曆？付款要用甚麼服務、涉及退款和稅務資料嗎？這些決定了功能、測試時間和持續費用。把每項功能分成「上線必要」「上線後可加」「暫時不用」，避免第一階段做太多卻未完成核心查詢路徑。後台也要寫清楚：誰需要新增文章、更新產品或查看查詢，並由誰保管登入權限。
| 功能 | 第一階段 | 驗收方式 |
|---|---|---|
| 查詢表單 | 必要 | 測試送出及收件 |
| 預約日曆 | 視乎營運流程 | 測試可選日期與通知 |
| 網上付款 | 先核對商業需要 | 測試付款與失敗情況 |
七、誰擁有網域、內容、原始碼和分析帳戶？
簽約前要問清楚網域登記人、主機帳戶、網站原始碼或後台的交付方式、相片與字體授權，以及 Google Analytics、Search Console 的管理權限。若日後換供應商，企業至少應能取回自己的內容、域名控制權及可用的網站資料。把每年可能繼續支付的網域、主機、第三方工具與維護費逐項寫在報價中，並說明不續約時網站會怎樣。這不是要求每個網站用同一套技術，而是要避免「網站已上線，但誰都不知道帳戶在哪裡」的情況。
- 建立清單網域、主機、網站系統、分析及表單服務。
- 指定擁有人寫明公司管理員、供應商權限與移交方式。
- 安排交接確認資料備份、續費日期及離任同事的權限回收。
八、上線前應如何驗收？
驗收不是「看起來差不多」。用已確認的頁面清單逐頁核對文字、照片、電話、價格和政策；在桌面與手機按過每條主要路徑；測試表單成功與失敗情況；檢查連結、404、圖像替代文字、標題與描述。搜尋設定需檢查 robots、sitemap、canonical 與網址是否一致。可用 Chrome Lighthouse 作速度、無障礙與 SEO 的初步檢查，但分數不能代替真人試用和內容核對。最後記錄「誰簽收哪個版本」以及上線後首週由誰接收查詢和修正問題。
| 核對項 | 通過的證據 | 負責人 |
|---|---|---|
| 內容與圖片 | 逐頁對照已確認稿 | 客戶內容負責人 |
| 手機與桌面 | 實機操作，沒有重要內容遺失 | 設計及測試人員 |
| 查詢流程 | 測試送出並收到指定通知 | 銷售及技術人員 |
| 搜尋入口 | 正式網址與 sitemap 一致 | 網站管理員 |
收到 AI 網站初稿，怎樣把「好看」變成「可驗收」？
不論初稿由 AI、模板或人手製作，都先拿自己的真實內容核對。AI 草稿可能放入示範電話、虛構案例、未授權圖片或尚未接駁的按鈕；請把每項內容對回已確認資料，不能因為版面完整就當作可上線。先選一條重要路徑，例如「看懂服務 → 查看相關例子 → 聯絡」，用同一版本在電腦和手機走一次，再記錄測試結果。
| 要驗甚麼 | 截圖能顯示 | 仍需另行測試 |
|---|---|---|
| 內容可信 | 標題、服務說明、圖片、電話 | 資料來源、素材授權、是否符合真實服務 |
| 主要行動 | 完整按鈕、標籤、相鄰說明 | 連結目的地、返回、鍵盤操作 |
| 查詢流程 | 表單欄位及可見提示 | 經授權的測試環境送出、錯誤情況、指定收件與跟進 |
| 搜尋及交付 | 頁面可閱讀的內容 | 正式網址、索引設定、帳戶權限與備份；排名或 AI 引用不能由截圖判定 |
每個未完成項目記下「頁面／裝置／步驟／預期／實際／負責人／版本」，讓修正可以重現。上述 EventPro 截圖只驗證當時可見的標題與行動標籤，沒有驗證真實訊息送達、付款成功或成交。測試真實查詢前應先安排合適環境及收件人，避免把測試當成客戶個案。
若希望內容在搜尋和 AI 答案中被理解，先提供可讀的真實服務資訊、清楚連結與相關圖像。Google 的生成式 AI 搜尋指引仍以有用的原創內容和基本搜尋要求為核心；沒有保證引用的專用檔案或特殊 schema。完成驗收也不代表已獲索引、排名或 AI 推薦。
可直接複製的網站需求底稿
頁面網址及獨立版型：＿＿；語言與翻譯／校對人：＿＿
文字、Logo、照片來源及提供人：＿＿
必要功能：＿＿；成功／失敗時應發生甚麼：＿＿
內容確認人及日期：＿＿；目標上線日：＿＿
預算幣別及範圍：＿＿；建置／首年／續費請分列
手機、修改、帳戶移交、維護及簽收版本：＿＿
把同一底稿交給各供應商，再用網頁設計收費指南的範圍與續費比較表核對差異。這是溝通底稿，不會取代雙方確認的報價、合約或驗收記錄。
常見問題
未有全部文字與照片，可以先詢價嗎？
可以。請先列出預計頁數、哪些內容已備妥、哪些仍需撰寫或拍攝；報價應明確區分已包含和另行處理的內容工序。未定稿的資料可能影響排期。
網站需求書是否需要列明預算？
建議提供可接受的預算範圍。設計公司才可把必要功能與後續可加功能分開，並說明不同範圍的成本，而不是憑猜測提交一份無法比較的報價。
驗收後才發現手機版有問題怎麼辦？
先對照已確認的頁面、功能與驗收記錄，列出可重現的裝置、步驟和畫面。屬已承諾範圍的問題應按合約修正；新需求則另行確認版本、費用與排期。