客戶一直要求改稿，接案者如何訂出修改範圍？

為什麼改稿次數愈談愈多？

最常見的情況不是客戶故意找麻煩，而是雙方一開始沒有說清楚：什麼叫一輪修改、哪些內容可以調整，以及誰負責彙整意見。接案者以為「修改兩次」代表兩批集中回饋；客戶卻以為每改一個字才算一次。即使合約真的寫了次數，理解不同，仍然容易發生爭議。

接案改稿次數應該跟交付階段一起設計。重點不是單純把次數寫得越少越好，而是讓客戶有合理的確認機會，同時讓工作量可以預估。

先區分「修正錯誤」與「需求變更」

如果接案者交付的內容與雙方已確認的規格不一致，例如漏掉事先約定的頁面、寫錯客戶已提供的資料，這是需要修正的問題，不宜直接當成額外改稿收費。

如果客戶原本確認製作三個頁面，過程中新增線上預約或會員功能，就不只是改稿，而是交付範圍改變。兩者應該分開記錄、分開評估。

還有一種情況介於中間：提案本身寫得不夠清楚，導致雙方對「完成」的認知不同。這時先核對需求紀錄，不要急著把責任全部推給客戶。

修改「一輪」到底怎麼計算？

比較清楚的做法是：一輪代表客戶在約定的回饋時間內，針對某個交付版本提供一次彙整後的修改意見，由接案者依約定範圍處理，再交付下一版供確認。

例如網站首頁初稿送出後，客戶把標題、資訊順序與圖片調整一次整理在文件中，這可算一輪；接案者逐項修改後交付第二版。不是每收到一則訊息，就立刻重新計數。

如果有多位主管參與，應請主要窗口先統整意見。否則同一個版本今天依行銷部門修改，明天又被其他部門要求改回原樣，雙方都會浪費時間。

不同服務適合的修改方式不一樣

品牌設計通常需要在概念、視覺方向與細節定稿等階段確認；網站建置可能分成架構、版面、功能測試；顧問或文案工作則可能先確認策略與大綱，再進入完整內容。這些工作不宜一律套用「全部交付後免費修改兩次」。

與其先設定一個看似漂亮的數字，不如先想清楚每個階段要讓客戶確認什麼，什麼時候提出意見最不容易造成返工。實際次數由案件風險、費用與工作量評估，不存在適合所有接案者的固定標準。

提案中應該寫清楚的五項條件

第一是修改對象：針對哪個頁面、文件或設計稿；第二是修改階段：初稿、第二版或定稿前；第三是回饋方式：由誰整理、使用哪個管道；第四是修改邊界：哪些屬於原定範圍，哪些需要另行估價；第五是回覆與處理時間：收到完整意見後如何安排。

這些條件應該放在客戶真正會閱讀的提案或合作文件中，不要只寫在最後一頁不易察覺的附註。若有範例，可以直接展示一輪修改如何提出，降低理解差異。

不要把「小修改」當成免費的代名詞

客戶可能說：「只是多加一個區塊，很快吧？」實際上新增區塊可能涉及內容整理、手機版版面、不同裝置測試，甚至需要調整原本的資訊架構。

接案者可以先釐清需求：「我先確認新增內容、使用位置，以及是否會影響原定交付，評估後再回覆費用與時程。」不必用情緒化語氣否定對方，也不要在尚未評估前答應免費完成。

反過來說，如果只是補上原本遺漏的一個字，或修正自己造成的錯誤，也不應硬套新增需求的規定。

客戶持續分批回覆，怎麼把意見集中？

可以提供簡單的回饋表：頁面或段落、目前看到的問題、希望調整的方向、必要素材，以及優先順序。請客戶由同一位窗口彙整後一次提供，接案者收到後先確認是否完整，再安排修改。

例如客戶說「這段看起來沒感覺」，可以請對方指出是資訊不足、語氣不符合品牌，還是順序不容易理解。問題說清楚，比猜測對方喜好更節省時間。

這不是要求客戶自己完成設計，而是讓回饋具體。接案者仍應運用專業提出可行建議，而非只照單執行。

修改意見互相衝突，誰來決定？

企業案件經常有不同部門一起審稿。行銷窗口希望文字活潑，主管希望正式，資訊部門關心網站功能。遇到互相衝突的意見，不應自行挑一個方向就做，也不要私下向每位主管承諾不同版本。

可以把衝突整理成兩個具體選項，說明各自影響，再請指定窗口確認最後決策。例如「若維持較完整的說明，手機版篇幅會增加；若改成精簡版，部分細節需要放進內頁。」讓客戶做知情選擇。

確認後保留紀錄，若之後又改變方向，就有客觀資料判斷是否屬於新的修改需求。

超出約定次數，怎麼談才不尷尬？

先不要直接丟出額外費用。把目前已完成的版本、原定修改範圍與新要求列在同一份紀錄裡，讓客戶看出差異。接著提供選擇：維持已確認版本、刪減其他工作以騰出空間，或新增修改工作並重新確認報價。

可以這樣說：「目前約定的修改階段已完成。這次提出的內容會新增幾項工作，我先整理影響的頁面、時程與費用，您確認後我們再安排。」這句話不指責客戶，也沒有把尚未估算的數字說死。

若增加的工作很少、自己願意吸收，也可以做為商業判斷；但最好仍記錄這次屬於額外協助，避免變成無限提供的慣例。

三個實際情境：網站、設計、文案

網站案：客戶確認首頁架構後，要求把原本的服務介紹改成全新預約流程。這牽涉功能與測試，應先重新估價，不宜計入一般文字修正。

設計案：初稿方向已確認，後來因公司更換品牌名稱，要重新製作整套視覺。這屬於需求基礎改變，應先確認新工作的範圍。

文案案：客戶指出你寫錯了先前提供的商品規格。這是交付品質問題，應修正。若客戶臨時要求再增加另一項產品的完整銷售頁，則應另行評估。

把情況分清楚，能避免接案者誤把合理的品質修正當成額外收費，也能讓客戶理解新需求並非原本報價的一部分。

已經答應「修改到滿意」，還能補救嗎？

先查看既有的報價、書面約定與實際溝通紀錄，確認雙方原本如何理解這句話。不要事後單方面宣布新的次數上限，或把對方尚未同意的條件當成已生效。

可以和客戶討論目前已完成的內容、剩餘需要修改的事項與可行時程，必要時取得新的書面共識。若已經涉及契約爭議，應依實際約定並尋求適當的專業意見。

下次提案則避免使用「無限修改」「保證改到滿意」等不清楚的承諾，改以具體的確認階段與工作範圍描述。

常見問題：修改兩次是指改兩個地方嗎？

不是必然。通常應由合作文件定義「一輪」如何計算，例如客戶彙整一批意見後由接案者一次處理。若文件沒有寫明，不宜事後認定每個小項目都是獨立的一次。

最簡單的檢查方式，是讓客戶在合作前看到一個真實的示意：首頁初稿、第一次集中回饋、第二版，以及最後確認。雙方都看得懂，才算規則清楚。

常見問題：修改次數到了，但有明顯錯誤怎麼辦？

先判斷錯誤來源。如果交付不符合原定規格，接案者仍應依合作條件處理；不能單純用次數到期迴避品質責任。如果是客戶改變原始資料或新增功能，處理方式就可能不同。

在實務上，將「缺失修正」「原範圍內的調整」「新增需求」分成三類，比把所有事項都塞進同一個修改次數更公平。

把修改規則變成客戶看得懂的示例

如果提案只寫「含兩次修改」，客戶不一定知道怎麼使用。可以附上簡單的時程示例：第 1 週確認方向，第 2 週交付初稿，客戶於約定時間內彙整第一次意見；第 3 週收到第二版後確認剩餘細節。這只是示意，實際安排依工作規模調整。

同時說明哪些變動會重新估價。例如「文字校對與原定頁面排版調整」可以列為原範圍，而「新增頁面、功能或重新制定整體策略」需要另外評估。客戶在付款前看懂這些差異，比合作後才爭論更有幫助。

每次交付都要標示版本與確認重點

檔案名稱可以包含專案名稱、交付項目與版本，例如「品牌首頁_第二版」。交付訊息附上此次修改摘要、還需要確認的事項，以及預計下一個工作階段。

不要同時傳送好幾份名稱相似的檔案，讓客戶不知道哪一版才是最新的。若使用共用文件，則應保留重要修改紀錄，避免修改之後完全找不到先前已確認的內容。

如果客戶沒有在約定時間回覆

先依合約或提案中已確認的回覆安排處理。沒有明確約定時，可以禮貌詢問是否需要更多時間，並說明哪些工作必須等到回覆才能繼續。

不要因為時間到了，就自行認定客戶接受某個設計或同意額外付款。若排程受到影響，應以書面重新確認預計交付日期，讓雙方都知道下一步如何安排。

收到不具體的批評，先找出判斷標準

「不夠高級」「感覺怪怪的」「不像我要的」是常見但難以執行的回饋。與其猜測，不如請客戶指出哪個段落、圖片或版面讓他有這種感受，再確認原本希望吸引的讀者與使用情境。

例如品牌首頁看起來太擁擠，可能是資訊排序問題，不一定需要全部重畫。先找出真正的問題，再決定修改範圍，也能避免兩邊花時間處理錯誤方向。

如何避免修改次數變成銷售障礙？

不要把規則寫成一長串警告。可以在方案說明中主動告訴客戶：每個主要階段都有確認機會，接案者會先提出建議並協助整理問題，超出原範圍的工作則會先報價、取得同意再執行。

這樣客戶看到的是可預期的合作方式，而不是「付完錢就不能有意見」。真正好的工作規則，能同時保護客戶取得承諾成果的權利，也保護接案者合理安排專業時間。

短期案與長期案，要用不同的修改管理方式

短期製作案通常能針對具體交付約定修改階段；長期顧問、維護或內容合作則更適合約定每月工作量、回饋方式與變更安排。

如果每個月都會發生新的需求，硬以單次設計稿的「兩輪修改」計算，可能不容易執行。此時可改成定期排定工作優先順序，超出服務內容時重新確認範圍，而非讓月費變成無限工時。

讓內部審稿流程在正式製作前完成

客戶若需要主管與多個部門審核，提案時就應確認誰有權定稿，以及不同階段需要哪些人參與。最怕的是視覺已定稿才發現真正決策者從未看過方向，最後只能整批重來。

接案者可以在初稿確認時要求相關決策者一起檢視主要方向，而不是把所有重大意見集中到交付前一天。這不是要求客戶放棄內部程序，而是讓審稿順序更符合實際工作。

結語：用清楚的階段取代無止境改稿

接案改稿次數不是為了讓客戶不能提意見，而是讓雙方知道什麼時候確認方向、如何彙整回饋，以及新增工作該怎麼處理。

提案階段先寫清楚範圍與確認方式，合作中保留版本紀錄，遇到變更先談交付與時程。如此一來，即使意見有分歧，也能把討論拉回具體工作，而不是陷入「到底誰比較難溝通」的爭執。

參考資料

Asana｜Project scope: definition, scope statement + 8 steps｜2026
Asana｜Scope Creep in Project Management｜2026