報價單看起來像一張菜單,但如果沒寫份量與作法,你敢直接下單嗎?很多人遇到的不是「報價太高」,而是WordPress 專案報價寫得太模糊,做完才發現少了頁面、少了功能,維護也不含在內。
這篇用專案管理的方式,帶你把報價單拆成可驗證的項目。你會拿到交付物對照表、功能範圍界定表、維護方案比較表,還有必問問題清單與驗收標準範例,讓追加費用更難發生。
文章目錄
Toggle第一步先拆帳:一次性費用 vs 月費/年費,誰在「持續收費」要寫清楚
很多報價單把費用混在一起,結果你以為買斷,其實是訂閱。做法很簡單,先要求對方把每一項標上「一次性」或「持續性」,並寫出到期日與續費金額。你也可以參考市場區間,先有基本底感,例如 PRO360 的架站行情 會整理常見區間與影響因素。
下面這張表可以直接拿去對照你的報價單,缺欄位就補齊。
| 費用類型 | 常見項目 | 通常由誰付款 | 報價單一定要寫的細節 |
|---|---|---|---|
| 一次性 | 資訊架構、UI 設計、前端切版、功能開發、資料移轉 | 客戶 | 頁面數、版型數、修改輪數、功能清單、交付格式 |
| 一次性 | 上線設定、GA4/像素、基本資安設定 | 客戶 | 是否含 staging、是否含回復演練、上線窗口 |
| 月/年費 | 主機(Hosting) | 客戶或廠商代購 | 規格(流量/空間/備援)、續費金額、到期日 |
| 月/年費 | 網域(Domain) | 客戶 | 註冊商帳號歸屬、DNS 管理權 |
| 月/年費 | SSL 憑證 | 多數可免費或付費 | 免費或付費方案、續期方式 |
| 月/年費 | CDN/防火牆 | 視需求 | 是否含 WAF、流量計價、超量費 |
| 月/年費 | Email 服務 | 視需求 | 信箱數、容量、備份與移轉責任 |
| 月/年費 | 付費外掛/主題授權 | 視需求 | 授權名義(誰的帳號)、續費誰付、停用後影響 |
小提醒:報價單若寫「含外掛」但不列出名稱與授權年限,幾乎等於沒寫。因為你無法預估第二年的固定成本。
想更完整理解費用組成,也可延伸閱讀 WordPress 網站設計費用拆解 與 WPTOOLBEAR 的 客製化網站費用完整指南 先把預算框起來。
設計與功能範圍怎麼寫才算清楚:把「模糊詞」變成可量化條件
報價單最常出事的地方在兩塊,設計與功能。因為它們最容易被一句「含」帶過。你要做的是把每個項目改成「可數、可測、可交付」。
先用下面這張「範圍界定表」檢查,哪一格沒寫清楚,就請對方補上。
| 區塊 | 報價單常見寫法 | 你要看到的量化描述 |
|---|---|---|
| 視覺設計 | 客製化設計 | 幾套版型(首頁/內頁/文章/產品),是否含設計系統(字體/色彩/元件) |
| RWD 響應式 | 全站 RWD | 覆蓋裝置範圍(手機/平板/桌機),斷點規則,測試機型 |
| 頁面製作 | N 個頁面 | 頁面清單與目的,是否含素材整理,是否含多語 |
| 動效 | 基本動效 | 動效類型(淡入/視差/輪播),是否影響效能指標 |
| 功能開發 | 客製功能 | 使用情境、資料欄位、權限、例外流程、通知方式 |
| 第三方串接 | 串接表單/CRM | 串接對象、欄位對應、失敗重送機制、紀錄保存 |
接著,這些「看似很香」的句子要特別小心。它們不是不能寫,而是要補上計算方式。
| 常見報價措辭 | 風險點 | 建議寫法(可直接貼回廠商) |
|---|---|---|
| 含基本 SEO | 不知道做到哪 | 列出項目(標題/描述、sitemap、301、結構化資料是否含),並寫明「不含內容代寫與排名保證」 |
| 客製化表單 | 客製到哪不清楚 | 明確表單數、欄位數、驗證規則、寄送對象、後台匯出格式 |
| 不限次修改 | 變成無限工時 | 改成「每頁 2 輪小改」,大改定義與加購單價 |
| 後台可自行維護 | 只給你一個帳號 | 寫明教學時數、操作手冊、哪些區塊可編,哪些需工程處理 |
維護、交付物與驗收:把交付落差變成「可勾選」的文件
網站不是交件就結束。你要在報價單上,先把交付物、維護範圍、驗收標準寫成清單,後面才有依據。尤其 2026 還很常見「只上線不維護」,三個月後外掛更新衝突才開始互相推責。
交付物對照表(建議列入合約附件)
| 類別 | 交付物 | 交付形式 | 交付時間點 |
|---|---|---|---|
| 帳號權限 | WordPress 管理員、主機、網域、第三方服務 | 由客戶持有的帳號或移交流程 | 上線前完成 |
| 原始檔 | 設計稿、圖片素材(若含)、客製程式碼 | 檔案連結或版本庫存取權 | 驗收通過後 |
| 網站內容 | 頁面清單、文案與圖片來源表 | 文件(如 Google 文件) | 上線前凍結版本 |
| 文件 | 操作手冊、維護說明、緊急聯絡方式 | PDF 或線上文件 | 上線後 7 天內 |
維護方案比較表(把「維護」拆成你買得到的內容)
| 維護項目 | 基礎(常見) | 標準(建議) | 進階(電商/會員常見) |
|---|---|---|---|
| 核心/外掛更新 | 每月一次 | 每週檢查 | 變更前先測試 |
| 備份 | 有備份但不說明 | 定期備份加保留天數 | 含還原演練 |
| Staging 預備站 | 常常不含 | 建議包含 | 必備 |
| 監控 | 不含 | 站點與可用性監控 | 含效能與錯誤追蹤 |
| 資安 | 基本防護 | 弱點與權限檢查 | 含事件處理流程 |
若你沒有現成工具,至少要求對方說明備份與 staging 怎麼做,像 WPvivid 備份與 staging 外掛 這類工具,就有清楚的功能描述可以對照。
必問問題清單(把模糊處問到見底)
- 交付物有哪些,能否提供附件清單並可驗收。
- 哪些費用是月/年費,到期怎麼續,誰付款。
- 外掛與主題授權登記在誰名下,停付會發生什麼事。
- 是否提供 staging,以及變更流程怎麼走。
- 備份頻率與保留天數,以及還原由誰操作,多久完成。
- 資安責任邊界,出事時的處理時限與溝通窗口。
- 修改範圍定義,小改與大改怎麼區分,超出怎麼計價。
- 原始碼與管理權移交,是否含版本庫或至少可下載完整網站。
另外,若報價涉及客製外掛或功能,也要確認是否遵循 WordPress 的基本授權與交付慣例,你可參考 WordPress 外掛目錄開發者資訊 了解 GPL 與發布要求,避免「做完卻不能移交」的尷尬。
驗收標準範例(含測試項目)
先用一張表把測試項目寫清楚,驗收就不靠感覺。
| 測試項目 | 測試方式 | 通過標準(範例) |
|---|---|---|
| 表單送出 | 測試 3 種情境(成功/必填缺漏/格式錯誤) | 成功寄送且後台有紀錄,錯誤提示清楚 |
| RWD 顯示 | 手機/平板/桌機各檢查重點頁 | 版面不跑版,文字可讀,按鈕可點 |
| 權限 | 管理員與編輯者各登入操作 | 編輯者只可改指定內容,不可改設定 |
| 備份還原 | 指定日期備份,實際還原一次 | 還原後可正常瀏覽與登入 |
| 上線切換 | DNS 與 SSL 檢查 | HTTPS 全站生效,無混合內容警告 |
驗收不只看畫面,還要驗流程。流程沒驗,問題會在你開始投廣告後才爆。
2026 仍常見的 WordPress 專案紅旗(看到就要停下來)
- 未寫明交付物,只寫「完成網站」。
- 不含 staging,直接在正式站改版與更新。
- 未寫備份頻率與保留天數,也沒還原承諾。
- 只交付後台帳號,不交付主機與網域管理權。
- 「含資安」但沒有具體內容與事件處理時限。
- 外掛授權不列名稱,或授權登記在廠商且不移交。
- 不限次修改但沒定義範圍,最後變成爭吵。
- 功能寫「可做到」卻沒有操作流程與驗收條件。
結語:看懂報價單,你買到的才會跟你以為的一樣
清楚的報價單不是刁難廠商,而是替雙方省時間。把一次性費用、持續費用、交付物、維護與驗收寫成可量化條件,你就能把WordPress 專案報價從「看心情」變成「看規格」。下一次拿到報價,先用本文的表格對照,再把缺的欄位補齊,專案就會穩很多。






