接案者在報 WordPress 案子時最常吃虧的，不是價格開得太低，而是範圍沒有界定清楚：客戶以為「做一個網站」包含文案、圖片、資料上架與上線後的所有調整，接案者以為只做版面與功能。等到雙方認知落差在專案中段爆發，時間已經投入大半，談判籌碼也所剩無幾。這篇不談任何金額，只談影響 WordPress 接案報價的結構性因素，以及報價單與合約上該把哪些範圍、改稿規則與驗收條件寫死。
報價前先把「做完是什麼樣子」定義出來
估算之前，要先能描述交付的最終狀態：有幾種版型、幾個頁面、哪些功能、內容由誰上架、上線在誰的主機、交付哪些帳號。這段描述寫不出來，代表需求還沒被釐清，這時候報出去的數字就是猜的，而猜錯的成本一定落在接案者身上。
如果客戶當下無法提供足夠資訊，比較穩的處理方式是分段：先報一個範圍明確的規劃階段，產出網站地圖、頁面清單與功能說明，再依據這份文件報建置階段的價格。這樣做的好處是雙方在投入大量工時之前就對齊了認知，也讓客戶看得到規劃本身是有價值的工作，而不是免費的售前服務。
客製程度是報價差距最大的變數
同樣是 WordPress 網站，實作路徑可以差很多。使用現成佈景加上少量調整、用頁面編輯器逐頁組版、依設計稿客製佈景、或是另外開發自訂文章類型與後台欄位，這四種做法的工時完全不同，而客戶在詢價時往往看不出差別，只覺得「都是 WordPress」。
報價時要把採取哪一種做法寫清楚，並說明對應的限制。例如採用現成佈景時，版面調整的彈性受限於該佈景提供的設定範圍，超出範圍的需求需要另外評估；採取客製開發時，前期工時較高，但後續新增內容的操作會更貼合客戶的資料結構。把取捨講在前面，是避免後續爭議最有效的做法，也讓客戶理解價差來自哪裡，而不是隨意開價。
改稿與追加需求，規則要在報價單上先寫死
- 一輪修改的定義：一輪是指客戶內部彙整後一次提出的完整意見，而不是零星來訊的每一則，這點務必白紙黑字寫明。
- 包含幾輪、超過怎麼辦：設計稿與程式各自包含幾輪修改，超出後以什麼單位計算，都要事先約定。
- 什麼算修改、什麼算重做：調整字級與間距是修改，推翻已簽核的版面結構重新設計則屬重做，界線要具體舉例。
- 簽核節點：架構、設計稿、功能驗收各設一個正式確認點，簽核後的變更一律走追加流程。
- 追加的處理方式：新增需求先以書面評估工時與時程，雙方同意後才動工，避免口頭答應累積成無法計算的工作。
- 素材逾期的處理：客戶未依約定時間提供文案與圖片時，時程如何順延、是否影響後續排程，要一併寫進去。
驗收條件寫得夠具體，尾款才收得到
接案糾紛最常卡在最後一哩：網站看起來做完了，客戶卻說還有地方不滿意，尾款遲遲不付。防止這件事的方法不是在結案時據理力爭，而是在合約裡就寫好可以逐項打勾的驗收標準。
具體一點的寫法會包含：所有約定頁面已建置並上架約定內容、表單送出後可正常收到通知、網站在約定的瀏覽器與裝置範圍內版面正常、後台可依約定操作新增與編輯、指定的帳號與權限已交付。並且要約定驗收的期限與方式，例如交付後在約定期限內提出書面意見，逾期未提出視同驗收通過。沒有這個期限條款，專案可能被無限期擱置，而工時早就付出了。另外建議把付款節點與簽核節點綁在一起，讓每個階段的成果與收款對應，而不是把大部分款項壓在最後。
上線後的維護與保固，要跟建置分開談
建置與維護是兩件事，混在一起報價，最後往往變成無限期的免費支援。合理的做法是把保固與維護明確切開：保固處理的是原本約定要有、卻沒有正常運作的瑕疵，期間有限；維護則是持續性的服務，包含核心與外掛更新、備份、異常排除、內容協助等，另行計價。
維護條款要寫清楚幾件事：涵蓋哪些項目、每月是否有工時上限、超過如何計算、回應時間怎麼定義、緊急狀況的處理方式，以及不含哪些（例如新增功能、改版、第三方服務本身的問題）。同時要說明客戶自行安裝外掛、更動程式碼或更換主機之後，保固責任如何調整，因為這些情況會讓問題來源難以判定。把界線寫清楚，對雙方都好：客戶知道自己買到什麼，接案者也不必在結案很久之後，還持續處理沒有計價的請求。
常見問題
客戶只說「做一個公司網站」，該怎麼報價？
不要直接報。先用一組問題把範圍框出來：預計有哪些頁面、有沒有需要客戶自行更新的內容、有沒有表單或會員功能、文案與圖片誰準備、主機與網域現況如何、有沒有既有網站要轉移。問題問完通常會發現需求差異很大，這時可以提供分階段的做法，或先報一個規劃階段的價格，把需求整理成文件之後再估建置。
客戶要求先看提案再決定要不要合作，怎麼處理比較好？
可以提供說明做法與流程的簡要提案，但不宜在未收費的情況下產出具體的版面設計或架構規劃，因為那已經是實際的工作成果。折衷方式是把規劃設計成一個獨立的付費階段，成果歸客戶所有，客戶可以選擇是否繼續由你執行建置。這樣既降低客戶的決策門檻，也保護自己的工時。
使用現成佈景做的案子，報價是不是就該比較低？
不一定。使用現成佈景省下的是版型開發時間，但仍需要花工時研究該佈景的設定邏輯、調整與需求不符的區塊、處理相容性問題，有時候繞開限制花的時間比重新做還多。報價應該反映實際投入的工時與承擔的責任，並在報價單上說明採用這個做法的彈性限制在哪裡。
客戶自己買了外掛要求整合，這部分怎麼算？
建議明確列為獨立項目，並註明評估的前提。第三方外掛的品質、更新狀況與相容性不在你的控制範圍內，若整合過程發現該外掛有缺陷或與其他元件衝突，處理的工時與可行性都難以事先預估。實務上可以先報一個評估時段，確認可行性之後再報整合工時，並約定若外掛本身有問題時的處理方式。
報價單需要寫到多細才夠？
判斷標準很簡單：這份文件之後能不能拿來當驗收依據。如果上面每一項都能對應到一個可以打勾確認的成果，細緻度就夠了；如果多數項目是「網站建置」「後台設定」這類看不出邊界的描述，就還不夠。寫細一點在洽談時可能多花時間，但省下的是專案後期最難處理的爭執。
本文由京采數位科技整理。我們自 2005 年起提供官網設計、系統開發與 Google SEO 服務，實際案例可見成果與案例。
想直接討論你自己的網站狀況，或需要一份初步的搜尋機會評估？
加入京采 LINE 好友相關主題
下一步
如果你正在評估「wordpress接案報價」相關的規劃，可以參考我們的網頁設計與系統開發服務，或直接與我們聯繫，我們會依你的產業與現況給出務實的建議。