專案進行到一半，客戶傳來訊息：「這個頁面順便加一個表單好嗎？」「簡報能不能多做一版？」「我們主管又想改個方向。」每一件事單獨看似乎不難，累積起來，卻可能使原本估計的工作量完全改變。
但另一個極端也不理想：客戶只是要求修正原本就答應要完成的成果，接案者卻回覆「這需要加價」。如果雙方都沒有清楚的判斷標準，合作容易變成爭執。
這篇先分清楚原範圍內的修正與真正新增的工作，再說明如何重新估價、約定時程與取得確認，讓專案有彈性，也不把所有變動轉成無償加班。
客戶提出新想法，不代表每一次都該追加費用
先看原本承諾的成果是什麼。如果你答應完成符合規格的網站表單，客戶在驗收時指出表單送出有問題，通常是應依約處理的工作；若對方希望再增加不同用途的新表單，則可能屬於新的交付範圍。
判斷標準不是「接案者覺得很麻煩」，也不是「客戶覺得只有一點點」。應以事前確認的工作內容、修改規則、驗收條件與雙方實際溝通紀錄為依據。約定不清楚時，先釐清理解差異，比立刻加價更有幫助。
先用三個問題判斷：這是修正，還是新的工作？
第一，是否改變原本確認的交付成果？例如原本只做一個品牌服務頁，現在增加一個新的案例頁，通常比調整既有頁面文字更接近追加項目。第二，是否超過事先約定的修改方式？例如原本確認過內容方向，後來因新主管加入而重新規劃整個架構。第三，是否增加新的整合、素材、時程或專業責任？如果答案是肯定的，就值得重新評估範圍。
不要把這三題當成自動加價公式。實際還是要依雙方的報價單、合約與確認紀錄判斷。若原本沒有寫清楚，雙方可能都以為新需求包含在原價內，此時應先把分歧說明清楚，再討論合理處理方式。
第一步：先描述變更內容，不要只說「這要加錢」
客戶一提出要求，先確認他希望改變什麼、為什麼現在要變更，以及是否會影響原本的目標。有時候新想法只是表達方式不同，不一定需要增加工作；也可能真的有新的使用情境，需要新的交付內容。
例如客戶說「首頁再放一些內容」，要先了解是把原本已有的資訊重新排序，還是要新增一整段服務介紹、案例和功能。如果沒有問清楚，直接估價可能高估或低估，也容易讓客戶覺得被隨意加收。
Asana 2026 年的專案範圍指南建議，重要變更應先被清楚提出，再評估是否需要調整範圍、資源與交付目標。這套原則對一人接案也適用，流程不一定要做得很複雜。
第二步：重新估算工時，也要看對原進度的影響
新增一個項目，不只包含實際製作時間。可能還需要需求確認、素材準備、測試、修改、驗收與交接。這些時間如果沒有算進去，追加報價就可能像原本的專案一樣失準。
除了直接費用，也要看是否會影響其他工作。例如原本的簡報已經完成主要架構，客戶要求中途改成另一個授課對象，可能需要重新整理內容，不只是修改幾張投影片。若新需求會讓原本交付延後，就應在報價時一起說明，而不是口頭答應原日期不變。
同樣地，如果需要額外授權素材、專業協作者或第三方工具，也應依實際費用和合作條件重新確認。不要先承諾自己未取得的資源，或把沒有依據的費用當作確定項目。
第三步：把「原本承諾」和「這次新增」寫在同一份對照裡
最清楚的追加報價，應讓客戶一眼知道哪些工作原本就包含、哪些是這次新增、哪些工作沒有改變。若原本文件有明確編號，可以引用原本的項目，再把變更內容另列一段。
例如原方案是「完成三個指定頁面及基本測試」，新增要求是「再做一個多步驟詢問表單」。此時可以在變更說明中列出新表單的主要功能、需要的資料、測試方式、追加費用和預計影響。若客戶真正只需要修改原有表單的文字，則不應當成全新的表單收費。
這種方式能減少客戶覺得被重複收費，也讓接案者避免漏掉新的責任。好的追加報價，不是在新需求上貼一個金額，而是把工作範圍的變化清楚呈現出來。
客戶提出新要求，可以選擇的四種處理方式
| 方式 | 適用情況 | 需要確認 |
|---|---|---|
| 維持原方案 | 新想法不是必要成果，先不增加工作 | 原本交付不變 |
| 新增獨立項目 | 可明確定義新的交付成果 | 追加費用、時程與驗收 |
| 替換原工作 | 新需求更重要，且原項目可以取消 | 已完成工作和價差怎麼處理 |
| 另開下一階段 | 變更較大或目前排程無法容納 | 新的專案範圍與合作時間 |
如果客戶同時提出很多變更，不一定要每一項都加進目前專案。可以先把真正影響核心成果的要求挑出來，其餘放到下一階段評估。這不是拒絕客戶，而是讓目前承諾的工作能照合理順序完成。
追加報價單應該包含哪些內容？
一份簡單的變更說明，可以包含原專案名稱與版本、客戶提出的新需求、對原範圍的差異、需要增加或調整的交付、預計費用、時程影響，以及由誰確認。小型專案可能一封清楚的確認信就足夠，涉及多位窗口或較大金額時，則應依合約和採購流程使用正式文件。
Asana 關於變更控制的資料指出，變更應經過提出、評估、決定與記錄。對自由工作者而言，最重要的是保留雙方看得懂的共識，而不是使用一套過度繁複、客戶也不願使用的行政制度。
如果客戶確認追加內容，應連同變更後的時程和費用一起保存。只留下「好的，麻煩處理」而沒有提到工作範圍，可能讓後續認知不一致。
實際溝通範例：客戶請你「順便」加做
可以先回覆：「我了解你希望新增這項功能。原本確認的範圍包含指定的頁面和基本表單，這次提出的是另一種使用情境。我會先把需要增加的工作與對交期的影響整理清楚，再提供你確認是否納入這個階段。」
這種說法比直接指責客戶臨時加需求更適合維持合作關係，也不代表你必須答應所有要求。等內容確認後，再提出清楚的追加價格與時間，讓對方決定是否進行。
如果新需求只是原本應完成的修正，則應承認並依約處理，不要用上面的話術把自己漏做的工作轉成額外費用。專業合作的信任來自公平，不是每次都讓自己多收一筆。
企業客戶多個窗口給意見，如何避免重複追加？
有些企業專案會遇到主管、行銷、資訊與使用部門分別提出不同想法。每一位窗口的意見可能都合理，但同時執行容易讓方向互相衝突。可以請客戶先確認主要負責窗口，由其整合意見與決策結果，再進行正式的範圍變更。
若新增要求涉及其他部門的系統、資料或權限，應先確認是否真的能取得必要資源，再估算費用。不要因為對方說「這個應該很簡單」，就把你不熟悉的整合工作當成已確認可交付的項目。
哪些情況不建議立刻承接追加需求？
- 原有工作已經接近交期，而新要求會影響品質或原本承諾。
- 需求描述太模糊，無法合理估算工作量與驗收方式。
- 需要外部專業、授權或資源，但目前還沒有確認。
- 客戶希望先做再談費用，雙方卻無法確認工作範圍。
- 新工作與原本專案目標差異很大，更適合另行規劃。
接案者不需要對每一個臨時需求都說好。把影響、費用和可行選擇說清楚，是對原本專案負責，也讓客戶更容易安排真正重要的工作。
用四週建立一套簡單的需求變更流程
第一週：整理目前報價與交付的模糊處
回顧最近幾個案子，找出最常被誤解的工作範圍。哪些需求原本就包含？哪些每次都會臨時增加？如果雙方沒有明確約定，就先整理成下一次可以說明的條件，不要替過往客戶自行補上新規則。
第二週：把修改和新增工作分成兩個處理步驟
為原範圍內修正建立簡單的意見彙整方式，為新增需求建立重新估價的步驟。客戶提出變更時，先描述想要的結果，再確認工作量與交期，避免每件事都直接變成爭議。
第三週：設計一頁追加報價說明
只需要列出原交付、追加內容、增加的費用、時程影響與確認方式。若新要求會替換原本的某項工作，也應寫清楚原工作已完成多少、哪些內容取消，以及新價差如何計算。
第四週：在真實專案中檢查效果
看看客戶是否能理解新舊範圍、你是否更容易確認是否應該收費，以及交付時程是否比以前清楚。流程不是越複雜越好，若一頁文件就能說明清楚，不必增加不必要的表單。
常見問題
客戶只是改一句話，也要另外報價嗎？
要看原本約定。若屬於已包含的修改範圍，就應依約處理；如果涉及已確認成果的重大方向變更，即使表面看起來只改少量文字，也可能需要更多評估。關鍵不是字數，而是對工作範圍的影響。
客戶說之前沒講清楚，怎麼辦？
先回到報價單、會議紀錄與雙方確認的內容，找出真正的理解差異。如果原先確實模糊，應合理協商，不適合只憑接案者自己的解讀就宣布所有新工作都要加價。
追加需求可以先做，最後再一起請款嗎？
若雙方已有清楚約定，可以依合作方式辦理；若費用與內容尚未確認，先執行可能造成後續爭議。比較穩妥的做法，是在開始前確認範圍、費用及付款安排。
加了新需求，原本交期一定要延後嗎？
不一定。若新工作很小，且原有排程有空間，可能不影響時程；但如果會占用關鍵工作時間，就應明確說明影響。不能在沒有評估的情況下保證原交期一定不變。
怎麼分辨客戶要求的成果是不是原本就有承諾？
查看原定交付、驗收標準和修改約定。如果原本應完成的功能未達約定品質，通常不該當成新工作收費；如果增加了新的功能、用途或可獨立交付的項目，就可能需要另外估價。具體仍依雙方契約和事實判斷。
追加需求的文字確認，至少要留下什麼？
不論使用電子郵件、正式變更單或其他雙方認可的紀錄，至少寫清楚新增工作、與原範圍的差異、費用或計價方式、預期交付時間，以及由誰確認。若目前仍有待確認事項，就應明確標示，不要用模糊的「照之前講的做」取代書面共識。客戶提出新想法時，也可以先提供幾種工作範圍選擇，讓對方了解時間與預算如何互相影響。
結語：追加需求不是麻煩，沒有清楚約定才容易變成麻煩
客戶在專案中產生新想法很常見。專業接案者需要的不是一律拒絕，也不是每件都免費幫忙，而是有能力說明原本要做什麼、新增了什麼、工作量如何改變，以及雙方要如何確認。
從下一次合作開始，先把服務範圍和修改方式寫清楚。真的出現新的需求時，對照原方案、評估影響、取得確認，再開始工作。這套小小的習慣，可能比事後為了一句「不是說好都包含嗎」反覆爭論更有幫助。
參考資料
Asana｜Scope Creep in Project Management: Definition & Fixes｜2026
Asana｜Change Control Process: 5 Steps, Example & Best Practices｜2026
Upwork｜How To Write a Freelance Contract and What To Include｜2026