客戶一直加需求怎麼辦？需求變更的加價話術、變更單與停損判準

接案久了會發現，真正拖垮一個案子的通常不是技術難度，而是需求一直加。原本談好三頁的形象網站，做到一半變成五頁；原本只是「調整首頁配色」，最後變成整套視覺重來。你不好意思開口收費，客戶也覺得自己只是提了一點小意見，兩邊都沒有惡意，但案子的工時和心情就這樣一起燒光。

這篇文章不談報價單怎麼列欄位（那是另一件事，我在網頁設計報價單的欄位結構與實務條款那篇寫過）。這篇要處理的是簽約之後的事：需求已經在加了，你手上這份合約還救不救得回來、怎麼開口談加價而不把關係談壞、變更請求單最少要有哪幾欄、客戶說「這只是小改動」的時候你該回什麼、什麼時候該吞下去、什麼時候該停損收尾。

你會拿到的東西是可以直接複製的條款文字和對話句型，中文和英文各一套。文中引用的法條都附全國法規資料庫連結，並且已經逐條確認過是現行有效版本。文末另有免責聲明，法律問題涉及個案，請以專業意見為準。

先講結論：需求膨脹是報價階段種下的，不是溝通階段長出來的

大部分人處理需求膨脹的方式是往「溝通技巧」找答案，覺得自己不夠會說話、不夠強勢、不敢開口。這個方向會讓你一直輸，因為溝通技巧只能改變語氣，改變不了立場。你的立場強不強，取決於你手上有沒有一份寫得夠精確的文件可以指著說「這一項不在裡面」。沒有那份文件，再好的話術都只是在跟客戶比誰比較堅持。

換句話說，你今天遇到的每一次「客戶又加需求」，答案幾乎都在幾個星期前的報價單和合約裡就決定了。範圍寫得夠細的案子，加需求會自然變成一個明確的問句：「這個要另外算嗎？」範圍寫得含糊的案子，加需求會變成一個模糊的預期：「這個應該包含在裡面吧？」同一個客戶，同樣的個性，兩種完全不同的結果。

所以這篇的順序是這樣安排的：先回頭看報價階段的三個定義缺口（不是欄位，是定義），把根源補起來；再處理你現在手上正在燒的這個案子，包含變更單、加價談判和停損。如果你正在滅火，可以直接跳到後面的談判段落；如果你想讓下一個案子不要再燒，前面兩段才是重點。關於合約本身的必備條款與驗收設計，可以搭配接案合約的必備條款與驗收設計一起看。

先分類：需求膨脹的五種型態，處理方式完全不同

把所有「客戶又加東西」都當成同一件事來處理，是很多人談判談壞的原因。有些追加你該無償吸收，有些該收全額，有些該直接拒絕。分不清楚的結果是：該收的沒收，不該爭的爭到翻臉。下面五種型態，是我把過去接案的爭議整理之後歸納出來的分類，你可以先對照自己現在遇到的是哪一種。

型態一：補完型（本來就該有，只是當初沒寫進去）

典型例子是：做電商網站，報價單只寫了商品頁、購物車、結帳，沒寫「訂單成立的通知信」。客戶說「這個當然要有啊」，客觀來說他沒說錯，一個不會寄通知信的購物流程確實不算完整。這種需求的特徵是：它不是新的想法，而是原本規格的必然延伸，只是雙方都以為對方會寫進去。

補完型的處理原則是：小的吸收，大的分攤。因為責任本來就在雙方，是規格訪談沒做完整。如果補完的工作量在一兩個小時內，直接做掉，然後在變更單上記一筆「本項以零元計」，讓客戶看得到你吞了什麼。如果補完的量很大（例如整套金流串接根本沒報價），那就得誠實地說：這一塊當初雙方都沒討論到，我需要重新報，我可以吸收一部分。

型態二：轉向型（客戶的目標變了）

特徵是：客戶提出的東西跟原本的方向不一致，甚至互相矛盾。上週確認的是走沉穩的商務風，這週老闆看了同業的網站，說要活潑一點。這種不是「加」，是「換」，但客戶通常用「加」的口氣講出來，因為在他腦中那只是一個意見。

轉向型最危險的地方是：如果你直接照做，你等於用一份合約的錢做了兩份設計，而且原本那一版的工時完全報廢。這種情況必須立刻停下來做一件事，就是把「換」這個字說出口：「這跟上週確認的方向不同，我想先確認一下，是要取代原本那一版，還是兩個並行？」一旦客戶自己承認是取代，後面談重新計費就順很多。

型態三：加碼型（真的多要了東西）

特徵最單純：原本三頁變五頁、原本不含中英雙語現在要雙語、原本靜態現在要後台可編輯。這類需求界線清楚，客戶自己心裡通常也知道這是多的，只是想試試看你收不收錢。

加碼型是唯一一種你應該乾脆俐落地報價的型態，而且愈快報愈好。拖著不報、先做再說，會讓客戶產生「原來這個免費」的印象，之後要收錢反而變成你在漲價。

型態四：轉嫁型（客戶內部沒共識，把成本丟給你）

特徵是：需求來自不同人，而且彼此打架。行銷部門說要放表單，法務說表單要加同意條款，老闆說表單太長要拿掉。你每改一次都會被另一個人推翻，工時全部消耗在來回上。

轉嫁型不能用「加價」解決，因為問題不在錢，在對方沒有決策機制。加價只會讓你賺到更多的痛苦。正確的處理是把決策責任推回去：要求指定一位單一窗口，所有意見由該窗口彙整後一次給你，並且明確寫進變更程序。這一點在需求確認的防呆流程裡有更完整的前期做法。

型態五：試探型（看你會不會擋）

特徵是：追加的東西不大、也不急，但頻率很高，而且每次都用非常客氣的方式提出來。這種客戶通常不是惡意，他只是在測試邊界在哪裡。你擋了第一次，後面就會少很多；你連續三次都吞了，他會合理地推論「這個範圍是彈性的」。

試探型的關鍵是第一次。第一次不必收很多錢，甚至可以只收象徵性的金額，重點是讓「這是一次變更」這件事被書面記錄下來。程序一旦建立，後面每一次都會自動走這條路。

型態	你怎麼認出來	該收費嗎	第一個動作
補完型	是原規格的必然延伸，雙方都沒寫	小的吞、大的分攤	承認規格訪談有缺口，重新界定
轉向型	與已確認版本方向不一致	應收，且可能要收兩次	先讓客戶承認這是「取代」不是「追加」
加碼型	界線清楚的新增項目	應收全額	當天內出變更單，不要拖
轉嫁型	需求來自多人且互相推翻	收錢解決不了	要求單一窗口與意見彙整機制
試探型	量小但頻率高、態度客氣	金額次要，程序優先	第一次就走書面變更單

分類本身就有談判價值。當你能對客戶說「這三項裡面，第一項我認為原本就該包含，我不收；第二項是新增的功能，需要另計；第三項跟上週定案的方向衝突，我們得先決定要哪一個」，你在對方眼中就不是一個計較的接案者，而是一個把事情想清楚的人。

簽約前的三個定義缺口：吵架幾乎都從這裡開始

這一段不列報價單欄位，欄位那件事在另一篇。這裡談的是三個「定義」。同樣一份報價單，欄位齊全但定義含糊，照樣會吵；欄位少一點但定義精準，反而不太會出事。這三個缺口是我看過爭議之後回推，最常成為導火線的地方。

缺口一：交付物的計數單位沒定義

報價單上寫「五頁形象網站」，看起來很明確，實際上一點都不明確。什麼叫一頁？首頁算一頁，那首頁裡面有六個區塊、每個區塊都要獨立設計，這叫一頁還是六頁？產品列表頁算一頁，那產品內頁算不算另一頁？手機版算不算另外的頁？部落格的文章樣板算一頁，那分類頁、標籤頁、搜尋結果頁呢？

這些問題如果不在報價階段回答，就會在製作階段被客戶用他的定義回答，而客戶的定義永遠比你的寬。設計類的工作要定義「一個版面」的組成；文案類要定義「一篇」的字數區間與改寫次數；開發類要定義「一支功能」包含哪些狀態（成功、失敗、空資料、載入中）。定義的顆粒度要細到「拿這份文件去問一個沒參與過的人，他數出來的數字跟你一樣」。

比較穩的寫法是列出具體清單而不是數量。與其寫「五頁」，不如寫「首頁、關於我們、服務介紹、案例列表、聯絡我們，共五個版型；本案不含案例內頁獨立設計，案例內頁沿用單欄文章樣板」。多寫兩行字，可以省掉之後兩個星期的來回。

缺口二：「完成」沒有定義，只有「滿意」

合約上寫「甲方驗收滿意後付尾款」是一個陷阱，因為「滿意」是主觀狀態，沒有終點。你把「完成」的定義交給對方的情緒，等於把交期和收款都交出去了。

可驗收的定義長這樣：在指定的瀏覽器版本上，指定的頁面清單全部可正常開啟；表單送出後可在指定信箱收到通知；在指定的測試裝置寬度下版面不破。這些條件的共同點是可以用「是」或「否」回答，而不是用「還不錯」或「感覺怪怪的」回答。

值得注意的是，法律上的「完成」跟你以為的不一定一樣。民法第 490 條把承攬定義為「當事人約定，一方為他方完成一定之工作，他方俟工作完成，給付報酬之契約」，而第 505 條規定「報酬應於工作交付時給付之，無須交付者，應於工作完成時給付之；工作係分部交付，而報酬係就各部分定之者，應於每部分交付時，給付該部分之報酬」。也就是說，只要你有分階段交付、而且報酬有按階段訂，法律的預設是每交一部分就該付一部分。把交付切段，是對抗需求無限膨脹最有效的結構性設計。

缺口三：「一次修改」沒有定義

這是三個缺口裡面最常被鑽的一個，也是最值得花時間寫清楚的一個。因為「修改次數」這四個字在客戶腦中和在你腦中，指的通常不是同一件事。下一段整段都在處理這個。

修改次數條款怎麼定義才不會被鑽漏洞

「本案含兩次修改」是接案圈最常見、也最沒有防禦力的一句話。它沒有定義什麼叫一次、沒有定義修改要在什麼時間內提出、沒有定義瑕疵修正算不算、沒有定義多人意見怎麼算。這四個缺口每一個都能讓兩次修改變成無限次。

什麼叫「一次修改」：三個要素缺一不可

一個能守得住的定義，需要同時包含三件事：批次、時窗、單一版本。

• 批次：一輪修改是指客戶把所有意見彙整成一份清單一次給你，而不是想到一項傳一項。沒有這個要件，客戶連續傳十則訊息，每則一句話，你做完十次卻只算一輪。
• 時窗：客戶必須在交付後的某個期限內提出（例如五個工作天）。沒有時窗，你交完一個月後客戶才想起來要改，而那個月你已經接了別的案子，時程全亂。時窗到期未提出，該版本視為通過。
• 單一版本：一輪修改針對的是「某一個交付版本」。客戶對第二版提意見，不能翻回去改第一版已經確認過的東西；要改，就是新的一輪或走變更程序。

三個要素缺任何一個，條款就有洞。缺批次，被拆散成無數次；缺時窗，被無限期拖延；缺單一版本，被反覆推翻已定案的部分。

bug 修正到底算不算一次修改

這是最容易吵起來的一題，而且答案在法律上其實蠻清楚：不算。修改（revision）是客戶改變主意，瑕疵修補（defect）是你交的東西跟講好的規格不符。前者是新增需求，後者是你本來就該負的義務。

民法第 493 條規定「工作有瑕疵者，定作人得定相當期限，請求承攬人修補之」，這是定作人的法定權利，不會因為你合約寫「含兩次修改」就被消耗掉。所以合約上最好直接寫明兩者分流，避免客戶把「按鈕點了沒反應」當成一次修改額度來用，也避免你把「客戶想換顏色」當成 bug 免費做掉。

順帶提醒一個本站踩過的坑：不要在合約裡寫「保固三個月」。民法第 498 條規定瑕疵權利的發見期間是自工作交付後一年，第 499 條對建築物等工作物延為五年，而第 501 條寫得非常明白：「第四百九十八條及第四百九十九條所定之期限，得以契約加長。但不得減短。」你寫三個月，法律不會讓你減短成三個月，這個條款寫了等於白寫，還會讓客戶誤以為三個月後你就沒責任了，反而在第四個月出事時吵得更兇。要限縮責任，正確的做法是限縮「範圍」（哪些狀況屬於瑕疵、哪些屬於環境變動或第三方服務異動），不是限縮「期間」。

三種常見鑽法與對應的堵法

鑽法	實際發生的樣子	堵法（寫進條款）
拆散意見	「還有一個小地方…」連傳十五則訊息	一輪＝一份彙整清單；散發的意見累計超出該清單者另計一輪
換人再來	你改完，客戶主管加入，整套重提	指定單一窗口；新增審查者提出之意見另計一輪
把新增當修改	「順便把這個功能加進去，算在修改次數裡」	修改僅限已交付範圍內的調整；範圍外一律走變更程序
無限期回溯	交付兩個月後才回饋，還要求免費	設定回饋時窗，逾期視為驗收通過
把瑕疵當籌碼	用「還有 bug」拖住尾款，同時夾帶新需求	瑕疵與變更分流；瑕疵不計入輪次、變更不影響尾款請求

可以直接複製的修改次數條款

中文版：

修改輪次：本案含二輪修改。一輪修改係指乙方交付一個版本後，甲方於交付日起五個工作天內，以單一書面清單彙整提出之全部修改意見，並由乙方一次回應完成。甲方逾期未提出者，該版本視為驗收通過。甲方分次、分批提出，或由前述清單提出後始加入之審查人員提出之意見，累計另計為一輪。

不計入輪次者：乙方交付物與雙方已書面確認之規格不符者，屬瑕疵修補，乙方應無償修正，且不計入修改輪次。

超出輪次者：每增加一輪，計費新臺幣＿＿＿元，交付期順延＿＿＿個工作天。

範圍外者：非屬已交付範圍內之調整，而係新增、變更或取代原約定工作內容者，不適用本條，應依契約變更程序辦理。

英文版（對跨國客戶使用，可搭配接案英文信件的實戰寫法）：

Revisions. This engagement includes two (2) rounds of revisions. A "round" means one consolidated written list of change requests, submitted by the Client within five (5) business days of a delivery and addressed by the Contractor in a single pass. If no list is submitted within that period, the delivery is deemed accepted. Feedback submitted piecemeal, or submitted by reviewers introduced after that list was sent, is cumulatively counted as an additional round.

Defects are not revisions. Where a deliverable does not conform to the specification agreed in writing by both parties, the Contractor will correct it at no charge, and the correction does not consume a revision round.

Additional rounds are billed at NT$______ each and extend the delivery date by ______ business days.

Out-of-scope requests. Requests that add to, alter, or replace the agreed scope are not revisions and are handled under the Change Control clause.

寫這種條款的時候有一個心理障礙要跨過去：你會擔心客戶覺得你防他防得太緊。實際的經驗剛好相反，願意把規則寫清楚的接案者，在有經驗的客戶眼中反而比較可靠，因為對方也怕案子失控。真正會被這種條款嚇跑的客戶，多半就是那些會讓你做到一半才後悔的客戶，這一點跟開案前的客戶篩選警訊是同一件事的兩面。

變更請求單的最小可用格式

變更請求單（change request，或稱變更單、change order）聽起來很像大公司才需要的東西，實際上一人接案更需要，因為你沒有專案經理幫你擋。而它可以很小，小到一封電子郵件就是一張變更單。

七個欄位，缺三個就會出事

1. 編號與日期：CR-01、CR-02 這樣編就好。編號的作用是讓你在爭議時能說「這是第七次變更」，數字本身就是說服力。
2. 提出人：誰要求的。這一欄的存在會自動抑制「不知道是誰說的」那類需求。
3. 變更內容：用客戶的話寫一次，再用你的話寫一次。兩句話並列，可以當場抓出理解落差。
4. 對原規格的影響：這一項會動到哪些已完成或已確認的部分。這欄是說服客戶「這不是小改動」最有力的地方。
5. 費用增減：金額，或明確寫「本次以零元計」。
6. 交付期增減：加幾個工作天。這欄不能空白，空白等於你默認免費吸收時間。
7. 回覆期限與確認方式：請對方在某日前回覆「同意」二字即可生效；逾期未回覆則視為不執行，專案依原規格繼續。

七個欄位裡面，第四、第六、第七是最常被省略、也最常出事的三個。少了「對原規格的影響」，客戶永遠覺得改動很小；少了「交付期增減」，你會在準時交付和滿足需求之間被夾死；少了「回覆期限」，變更單會變成一封沒人理的信，而你不知道該不該做。

一頁式範本（可直接複製）

【變更請求單 CR-03】日期：2026/08/01
提出人：王經理（行銷部）
變更內容（客戶原話）：「首頁想加一個最新消息的區塊，可以自己更新的那種。」
變更內容（承辦理解）：首頁新增最新消息區塊一組，含後台文章類型、列表樣式、手機版樣式；不含獨立的最新消息列表頁與內頁。
對原規格的影響：首頁版面需重新配置，已確認之首頁設計稿需修改；後台需新增自訂文章類型；已完成之首頁前端需重做約三分之一。
費用增減：＋新臺幣 ＿＿＿ 元
交付期增減：＋3 個工作天（原定 8/20 交付，變更後為 8/25）
回覆期限：請於 8/5 (二) 18:00 前回覆「同意」。逾期未回覆者，本案依原規格繼續執行，本變更另行議定。

這張單子的重點不在格式漂不漂亮，而在於它把一個模糊的口頭意見，變成一個有價格、有時間、有期限的具體提案。客戶面對的不再是「你為什麼不肯改」，而是「我要不要花這筆錢和這三天」。談判的主體從人變成了選項，這是整套方法最核心的一步。

官方範本怎麼用：借用政府採購契約的變更條款

如果你覺得自己寫條款沒把握，有一份現成、公開、而且經過長期實務檢驗的中文範本可以參考：行政院公共工程委員會的勞務採購契約範本（最新版為 114 年 12 月 31 日修正）。它的第十五條「契約變更及轉讓」有四段話特別值得抄進你的接案合約：

• 機關於必要時得於契約所約定之範圍內通知廠商變更契約（含新增項目），廠商於接獲通知後，除雙方另有協議外，應於 10 日內向機關提出契約標的、價金、履約期限、付款期程或其他契約內容須變更之相關文件。
• 廠商於機關接受其所提出須變更之相關文件前，不得自行變更契約；除機關另有請求外，廠商不得因該通知而遲延其履約期限。
• 機關於接受廠商所提出須變更之事項前即請求廠商先行施作或供應，其後未依原通知辦理契約變更或僅部分辦理者，應補償廠商所增加之必要費用。
• 契約之變更，非經機關及廠商雙方合意，作成書面紀錄，並簽名或蓋章者，無效。（此為該條第五款；該條實際共六款，另有替代品與轉讓之約定）

第三點是我認為最值得學的一條。它處理的正是「客戶說先做再說、之後再補單」這個情境：如果對方要你先做，後來卻沒有把變更辦下去，你增加的必要費用還是要補償給你。把這句話用白話寫進你的合約，等於幫「先做再說」這個高風險行為裝了一個安全氣囊。

同一份範本的第七條也很有參考價值。它明訂履約期限得因「辦理契約變更或增加履約標的數量或項目」以及「機關應辦事項未及時辦妥」而展延，且不計算逾期違約金。這正是接案者最需要的一句話：客戶加東西、客戶拖延提供素材，交期就該往後推，而且不是你的錯。

「先做再說，之後補單」到底能不能做

實務上你不可能每次都拿到簽名才動手，尤其是熟客或急案。折衷的做法是分級：

• 一小時以內、不動已定稿內容：直接做，事後在週報裡列一行「本週吸收之額外工作」。
• 一小時到半天：先寄變更單，同時開始做，信裡寫明「我先動工避免影響時程，但若你決定不做，這部分費用仍請依變更單計」。
• 半天以上，或會動到已確認的交付物：不簽不做。這種量級一旦做白工，痛的是整個月的收入。

另外補充一個法律上的支點：民法第 491 條規定「如依情形，非受報酬即不為完成其工作者，視為允與報酬」，第二項則說「未定報酬額者，按照價目表所定給付之；無價目表者，按照習慣給付」。也就是說，即使你們沒有事先談好追加的價錢，只要客觀上這種工作不可能無償進行，法律就視為雙方允與報酬——條文用的是「視為」不是「推定」，對接案者更有利。這條在你被迫「先做再說」之後仍然有請款依據，前提是你留得下證據：對方要求你做的訊息、你交付的成果、你的公開價目表。所以工時與溝通紀錄要留好，這部分可以參考工時追蹤與請款的完整流程。

怎麼開口加價而不破壞關係：四步法

大部分人卡在「開口」這一關，是因為腦中預設的句子是「你這樣一直加我很困擾」。這句話的問題是它在講你的感受，而客戶不會因為你困擾就改變行為。有效的講法是把話題從「你很煩」轉到「這會影響交期，你要哪一個」，也就是把情緒問題換成資源問題。資源問題是可以一起解決的，情緒問題只能一起承受。

第一步：接住，不要當場報價

客戶提出需求的當下，最糟的兩種回應是「好啊沒問題」和「這要另外收錢喔」。前者送出免費承諾，後者把對話直接推向對立，而且你當下的估算通常不準。正確的動作是接住需求、承認它合理、然後把報價的時間點推到之後。

句型：「這個我記下來了，方向我懂。我先確認一下它會動到哪些已經排好的部分，明天中午前把時間和費用一起回你。」這句話同時做了三件事：表達你有在聽、暗示這件事有成本、把主導權拿回自己手上。

第二步：分類，然後把不收錢的那些先講

回覆的時候，先講你不收錢的部分。這一步在心理上非常關鍵，因為它讓整段對話的開頭是「我幫你做了什麼」，而不是「我要跟你收多少」。

句型：「這三項裡面，第一項本來就在規格裡，我照做，不另計；第二項嚴格說是新增的，但量不大，這次我一併吸收；第三項會動到已經定稿的首頁，這個我需要另外報。」

第三步：把成本翻譯成客戶的選擇題

這是整套方法的核心。不要把加價講成一個要求，要把它講成一組選項。人在面對要求時會抗拒，面對選項時會計算。

句型：「這個功能大概要多三個工作天。你有三個選擇：一是上線日往後推三天；二是加 X 元，我把它排進加班的時段，上線日不動；三是把原本規格裡的 Y 先拿掉，換這個進來，時間和費用都不變。你比較希望哪一個？」

三選項的設計有它的道理。第一個選項（延期）測試的是這個需求到底急不急，很多需求在「要延三天喔」之後就自動消失了。第二個選項（加價）是你真正想要的結果。第三個選項（交換）是給預算真的很緊的客戶一條路，同時把「範圍是有總量的」這個觀念植入對方腦中。

第四步：書面化，並設定回覆期限

口頭談完一定要落成文字，而且要有期限。沒有期限的變更單會一直懸著，你會陷入「不知道要不要做」的空轉，而空轉的成本比做白工還高。

句型：「變更單我今天寄給你，麻煩在週四 18:00 前回覆一個『同意』就好。如果週四前沒收到回覆，我會先照原規格往下做，避免整體交期受影響，這一項我們之後再談。」

中文句型庫：八個常用場景

1. 接住不報價：「這個我記下來了。我先確認它會影響到哪些已經排好的部分，明天中午前把時間和費用一起回你。」
2. 分類回覆：「這一項原本就在規格裡，我照做不另計。另外兩項是新增的，我列成變更單給你。」
3. 三選項：「這會多三個工作天。延後三天上線、加 X 元趕工、或是換掉原本的 Y，你比較希望哪一個？」
4. 設期限：「變更單今天寄出，麻煩週四前回覆。沒回覆的話我會照原規格繼續，避免整體交期受影響。」
5. 反制「小改動」：「改動本身確實不大，但它會動到已經定稿的 A 和 B，重測要半天。我可以做，只是這半天要從哪裡來，我們一起決定。」
6. 面對新加入的決策者：「這個方向我完全理解。不過它跟上週確認的版本不同，我想先確認：是要取代上週那一版，還是兩個並行？兩個並行的話會是另一份預算。」
7. 已經吞很多次、這次要收：「前面這幾項追加我都直接吸收了（附清單）。這一項的量比較大，我需要另外報價，希望你能理解。」
8. 提出停損：「以目前的變更頻率，我沒辦法給你一個可靠的完成日。我建議把現在這一版收掉結算，剩下的部分重新開一個案子、重新報價，這樣對你我都比較好估。」

英文句型庫：對應的八句

1. "Thanks — noted, and I get the direction. Let me check what this touches in the current build and I'll come back before noon tomorrow with the time and cost impact."
2. "Two of these are already covered by the agreed scope, so I'll just do them. The third is new work — I'll send it over as a change order."
3. "This adds about three working days. Three options: push the launch by three days, add NT$X for expedited work and keep the date, or swap it in for feature Y in the current scope. Which works best for you?"
4. "I'm sending the change order today. Could you reply 'approved' by Thursday 6pm? If I don't hear back, I'll keep building to the original spec so the overall date holds, and we can revisit this separately."
5. "The change itself is small, but it touches two components we've already signed off, and re-testing takes half a day. I'm happy to do it — we just need to decide where that half day comes from."
6. "Completely understand. It is a different direction from the version we approved last week, though — so before I start: do you want to replace that version, or run both? Running both would be a separate budget."
7. "I've absorbed the last few additions at no charge — here's the list. This one is larger, so I'll need to quote it separately. I hope that seems fair."
8. "At the current rate of change I can't give you a completion date I'd stand behind. I'd suggest we close out and invoice the current version, then scope the remaining work as a new project. That gives us both a number we can trust."

英文句型有兩個要注意的地方。第一，避免用 "I'm afraid"、"unfortunately" 開頭，那會讓你聽起來像在道歉，而你並沒有做錯事。第二，避免用 "just" 弱化自己的話（"I just wanted to check…"），直接寫 "Could you confirm…" 更清楚也更專業。

客戶說「這只是小改動」的六種情境與應對

「這只是小改動」是需求膨脹裡出現頻率最高的一句話，而它幾乎總是真心的。客戶不是在唬你，他真的覺得那很小，因為他看到的是螢幕上一個顏色的變化，看不到底下那些連動。所以應對的重點不是拆穿他，是讓他看見。

情境一：「就換個顏色而已」

回應：「顏色本身五分鐘。不過主色一改，按鈕、連結、圖表、hover 狀態、還有已經做好的三張社群圖都要跟著調，加起來大概半天。你要現在改，還是等第一版上線之後再看實際效果決定？」

這句話的重點在最後一問。把「現在改」和「上線後再說」變成選項，很多情況下客戶會選後者，而後者往往就等於不改了。

情境二：「這個應該很快吧」

回應：「做出來確實快，大概兩小時。比較花時間的是測試，因為它會影響到結帳流程，我得把三種付款方式各測一輪，加起來大概一天。如果你能接受先上線、下週再補這個，我可以排在第二批。」

不要否定「很快」，而是把時間成本從「寫程式」轉移到客戶看不見的部分。這樣客戶不會覺得你在膨風，因為你承認了他看到的那部分確實很快。

情境三：「上次那個廠商都馬上改」

回應：「我理解，每個人的做法不一樣。我這邊每一次改動都會過測試再交，所以會慢一點，但你不會遇到改了 A 壞了 B 的狀況。如果你需要更快的節奏，我們可以改成固定每週三下午一次批次上線，你把當週的想法累積到週二給我，這樣速度和穩定度可以兼顧。」

被拿去跟別人比較的時候，不要辯解、也不要貶低前一個廠商，直接提出一個具體的節奏方案。把比較變成流程設計，對方通常會接。

情境四：「我們老闆說要加」

回應：「沒問題，我照辦。不過因為這會動到已經確認的版本，我需要一份書面的變更確認，這樣你在內部也有依據。我把變更單寄給你，你直接轉給老闆看時間和費用就好。」

這裡有一個細節值得注意：把變更單塑造成「幫窗口在內部交代」的工具，而不是「我要跟你收錢」的帳單。窗口通常也不想背這個鍋，你給他一份可以往上轉的文件，他會很願意配合。

情境五：「先做，之後一起算」

回應：「可以，我先動工。不過為了避免之後對不上，我還是會把這幾項列成單子寄給你，先不用付款，等驗收的時候一起結。這樣你也知道累積到哪裡了。」

接受「之後一起算」，但不接受「之後一起想」。單子要在事情發生的當天出，事後補的清單在爭議時說服力低很多。

情境六：「不然這樣好了，我加一點錢」

回應：「謝謝，我想先把量算清楚再談金額，這樣對你比較公平。我把這幾項的工時列出來給你看，你再決定要全做還是只做其中幾項。」

客戶主動說要加錢的時候，先不要接下那個數字。他心中的「一點錢」跟你算出來的通常差很多，先報數字再讓他選項目，比先收下再抱怨好。關於報價本身的邏輯和台灣行情，可以另外參考五種定價模型與台灣行情。

什麼時候該吞下去：策略性讓步的五個判準

不是每一次追加都該收錢。堅持每一項都計價的接案者，會在客戶心中變成「凡事都要錢」的人，長期而言反而失去溢價空間。讓步本身是一種投資，關鍵在於你有沒有想清楚投資報酬。

五個可以讓步的條件

1. 成本在一小時以內，而且不會動到已定稿的東西。這種讓步的邊際成本極低，但在客戶心中的價值感很高，是報酬率最好的一種。
2. 這次讓步能換到明確的東西。例如提前付款、公開作品集的授權、一則具名推薦、或是下一期的優先議約權。換的東西要在同一次對話裡講出來，事後再要就變成討人情。
3. 錯誤根源在你這邊。規格沒問清楚、你沒把限制講明白、你估錯了。這種情況下的讓步不是投資，是修補，該做而且要做得乾脆。
4. 客戶的長期價值高，而且付款紀錄乾淨。一年給你三個案子、從不拖款的客戶，跟一次性的陌生客戶，本來就該用不同的彈性標準。
5. 這是關係中的第一次摩擦。第一次通常是誤解，不是習慣。把第一次處理得漂亮，往往能省掉後面的十次。

三個不該再吞的訊號

• 對方把你的讓步當成新的基準線。你免費做了一次，下一次他直接說「跟上次一樣」。這代表讓步沒有被認知為讓步，繼續吞只會加速下滑。
• 同一個人第三次以上提出同性質的追加。第一次是誤解，第二次是習慣，第三次是制度。到第三次還沒建立程序，問題出在你身上。
• 讓步之後對方的要求變多而不是變少。健康的關係裡，你退一步對方會退半步；如果你退一步對方進兩步，這段關係的結構本身有問題。

讓步一定要「記名」

免費做掉的東西如果不留紀錄，等於沒發生。客戶記得的永遠是他付了多少錢、拿到什麼；他不會記得你偷偷吸收了什麼。所以每一次讓步都要出現在書面上，而且要標價。

做法很簡單：變更單照出，費用欄寫「原價 NT$3,000，本次以 NT$0 計，作為專案善意」。到了專案結束的結案信裡，再把所有零元項目列成一張清單，加總金額寫出來。這張清單有兩個作用：一是讓客戶知道他拿到了什麼，二是當你未來要調價時，這就是最有力的材料。這一點跟接案調價的時機與說法是連著的：調價的說服力來自於證據，不是來自於你今年比較缺錢。

什麼時候該停損收尾：四個訊號與三種收法

有些案子救不回來。不是因為客戶壞，而是因為結構本身壞掉了：需求沒有邊界、決策沒有人負責、你的工時已經超過報價太多。這種時候繼續撐下去，通常的結局是你交出一個雙方都不滿意的東西，然後尾款還收不到。

四個停損訊號

1. 需求產生的速度超過你交付的速度。每交一版，新增的需求比解掉的還多。這是最客觀的一個訊號，你可以直接數：這一輪回饋新增了幾項、上一輪解掉了幾項。連續兩輪新增大於解決，就是紅燈。
2. 沒有人能簽字。你問「這個可以定案了嗎」，得到的答案永遠是「我再問一下」。決策鏈斷掉的專案，投入再多工時也不會收斂。
3. 已投入工時超過你自己設定的門檻。建議在報價的時候就先給自己訂一個數字，例如報價工時的一點五倍。這個數字沒有標準答案，重點是它要在你還冷靜的時候訂好，而不是在你已經很累的時候臨時判斷。
4. 你開始拖延打開這個專案的資料夾。這是心理訊號，但它通常比前三個更早出現。當你發現自己每天先做別的案子、把這個留到最後，那多半代表你心裡已經知道答案了。

收法一：範圍凍結後交付

這是最溫和的收法，也是首選。做法是明確劃線：從今天起規格凍結，剩下的工作只做已確認清單上的項目，做完交付、結算尾款；線後的所有需求整理成一份清單，另案報價。

開口的方式：「我看了一下目前的狀況，變更累積得比預期多，如果繼續這樣下去我沒辦法給你一個可靠的完成日。我的建議是：我們把目前這份清單上的項目做完、交付、結案，剩下的這些（附清單）我另外報一個價給你，時程也可以重新排。這樣你會比較清楚拿到什麼、什麼時候拿到。」

注意這段話裡沒有指責，也沒有情緒。它只講一件事：現在的做法無法給出可靠的日期。這是一個雙方都能接受的理由，因為客戶也想要一個可靠的日期。

收法二：協議終止

如果凍結範圍也談不下來，就談終止。協議終止的重點是把三件事同時談定：已完成部分怎麼計價、已交付的成果客戶能不能用（授權範圍）、雙方後續有沒有其他請求。這三件事沒有一次談清楚，就會變成拖很久的爭議。

計價的基礎可以參考前面提到的民法第 505 條：分部交付且報酬分部計價者，每交付一部分就該給付該部分報酬。所以如果你的合約有做階段拆分，終止時的計價會單純很多。這也是為什麼「把交付切段」值得在簽約時就做好。

收法三：客戶片面喊停

還有一種情況是客戶自己不做了。民法第 511 條規定：「工作未完成前，定作人得隨時終止契約。但應賠償承攬人因契約終止而生之損害。」也就是說客戶確實有權隨時喊停，但他要賠償你因此產生的損害。這條是接案者手上很重要的一張牌，很多人不知道自己有。

另外一個容易被忽略、但方向相反的條文是民法第 506 條：「訂立契約時，僅估計報酬之概數者，如其報酬，因非可歸責於定作人之事由，超過概數甚鉅者，定作人得於工作進行中或完成後，解除契約。」這條的意思是，如果你當初只給了「概數」報價，實際費用又暴增很多，客戶反而有權解約。所以在報價單上寫「約」、「概估」、「視實際情況調整」這類字眼，對你不見得有利。要保留彈性，正確的做法是明確列出「單價」與「計價方式」，而不是給一個模糊的總額。

客戶不配合、案子卡住的時候

還有一種常見的死法：不是客戶加太多，而是客戶不給東西。文案不給、圖片不給、後台帳號不給，案子卡在那裡，你的工時排程整個亂掉，最後還被說你拖延。

民法第 507 條處理的正是這件事：「工作需定作人之行為始能完成者，而定作人不為其行為時，承攬人得定相當期限，催告定作人為之。定作人不於前項期限內為其行為者，承攬人得解除契約，並得請求賠償因契約解除而生之損害。」重點在「定相當期限，催告」這六個字：你必須先用書面設定一個合理期限並催告，而不是自己默默等。這也是為什麼所有催告都要留書面紀錄。

法律工具箱（速查）

條文	重點	用在什麼情境
民法第 490 條	承攬的定義；供給材料之價額推定為報酬之一部	釐清你和客戶之間是承攬關係；素材、外掛授權若由你供給，記得另行約定不含在報酬內
民法第 491 條	非受報酬即不為完成者，視為允與報酬；未定報酬額按價目表或習慣	被要求「先做再說」卻沒談價時的請款依據
民法第 493 條	定作人得定期限請求修補瑕疵	區分「瑕疵修補」與「修改次數」，避免兩者混算
民法第 498 條、第 501 條	瑕疵發見期間一年；得以契約加長，但不得減短	不要寫「保固三個月」，那個條款無效
民法第 502 條	可歸責於承攬人之遲延，定作人得減少報酬或請求賠償；以特定期限為要素者得解約	提醒你：交期延誤若可歸責於你，代價不小，所以變更一定要同步調交期
民法第 505 條	分部交付且報酬分部訂者，每部分交付時給付該部分報酬	把交付切段的法律基礎；終止時的計價依據
民法第 506 條	僅估計概數，實際超過概數甚鉅者，定作人得解約	提醒你不要用「概估總額」報價，要列單價與計價方式
民法第 507 條	定作人不為協力行為，承攬人得定期催告，逾期得解約並請求賠償	客戶不給素材、不回覆、專案卡住時
民法第 511 條	工作未完成前定作人得隨時終止，但應賠償承攬人因終止而生之損害	客戶中途喊停時的求償依據
民法第 514 條	相關請求權與解約權因瑕疵發見後一年間不行使而消滅	時效很短，爭議不要一直拖
民法第 227 條之 2	情事變更且依原有效果顯失公平者，得聲請法院增減給付	極端情況下的最後手段，門檻高、要走法院，不是日常談判工具
民法第 153 條	意思表示一致，無論明示或默示，契約即成立	提醒你：通訊軟體上答應的話也可能構成契約

最後這一條值得多說一句。民法第 153 條的「默示」兩個字，是很多接案者吃虧的地方。你在通訊軟體上回一句「好，我看看」，在對方眼中可能就是承諾。所以在變更談判期間，回覆的用字要比平常更精確：「我確認一下」和「好」是完全不同的兩句話。

遠距與平台情境的額外變數

前面的方法在面對面或同時區的案子上很好用，但如果你的客戶在別的國家、或案子是透過接案平台成立的，還有幾個變數要處理。

通訊軟體上的需求怎麼收攏成證據

台灣的案子有很高比例在通訊軟體上溝通，而通訊軟體的訊息是最糟糕的需求載體：沒有版本、沒有結構、搜尋困難、而且會被對方撤回。實務上可行的做法是建立一個固定動作：每次通話或每段訊息討論結束，你主動寄一封短信，開頭寫「跟你確認一下今天談的三件事」，條列出來，結尾寫「如果理解有誤請在明天中午前告訴我，否則我就照這個往下做」。

這封信的價值在於它把「散落的訊息」轉成「有時間戳記的單一版本」。真的走到爭議的那一天，你能拿出來的是一串有結構的信件，而不是一千則訊息的截圖。

接案平台上的變更機制

如果案子是在國內外的外包平台上成立的，變更的處理會受平台規則影響。多數平台的固定價（fixed-price）合約都有里程碑機制，變更金額和項目需要透過平台的變更流程、並經雙方確認才會生效；有些平台則提供在進行中的訂單裡追加服務的功能。實務上要注意兩件事：一是平台外的口頭承諾在爭議時通常不被平台採認，所有變更都要回到平台上留紀錄；二是追加金額會照樣被抽成，所以報價時要把平台費率算進去。各平台的抽成結構與適用情境，可以參考接案平台的比較與抽成實務；平台的具體規則會不定期調整，簽約前請以該平台的官方說明頁為準。

跨時區客戶的隱藏成本

跨時區的案子有一個容易被低估的成本：每一次來回的等待時間。同時區的案子，一個問題問出去可能半小時內有答案；十二小時時差的案子，同一個問題可能要等一整天。這代表同樣數量的變更，在跨時區案子上會消耗掉多好幾倍的日曆天。

對應的做法是把「回覆時窗」寫得更嚴格，並且在報價階段就把來回次數當成一個計價因子。相關的排程與界線設計，在跨時區協作的排程與界線設定裡有更完整的討論。

一組可以直接抄的條款：中英對照

把前面談的東西收攏成五組條款。空格處請自行填入數字，並依你的案型調整。這些是寫作範例，不是法律意見；重要或金額較大的案子，請找律師看過再用。

一、規格凍結

中文：「規格凍結：自甲方書面確認設計稿（或規格文件）之日起，該版本之結構、頁面數量及功能清單即為凍結。凍結後之任何變更，一律依本契約變更程序辦理。」

英文："Specification Freeze. From the date the Client approves the design or specification document in writing, the structure, page count, and feature list of that version are frozen. Any change after that date is handled under the Change Control clause."

二、變更程序

中文：「契約變更：任何影響工作範圍、交付物、規格、交付期或價金之變更，均應以書面變更單為之，經雙方簽署或以電子郵件明示同意後始生效力。乙方於收到甲方變更需求後 ＿ 個工作天內提出變更單，載明變更內容、對原規格之影響、價金增減與交付期增減。變更單生效前，乙方不負執行該變更之義務，原定交付期亦不因該需求而受影響。甲方要求乙方於變更單生效前先行施作者，其後未辦理變更或僅部分辦理時，應補償乙方因此增加之必要費用。」

英文："Change Control. Any change affecting scope, deliverables, specification, schedule, or price must be made by a written change order, effective once signed by both parties or expressly approved by email. Within ___ business days of receiving a change request, the Contractor will issue a change order stating the change, its impact on the approved specification, the price adjustment, and the schedule adjustment. Until a change order takes effect, the Contractor is not obliged to perform the change and the original delivery date is unaffected. If the Client asks the Contractor to begin work before the change order takes effect and the change is subsequently not executed, or only partly executed, the Client shall reimburse the Contractor for the additional necessary costs incurred."

三、單一窗口與有權指示

中文：「單一窗口：甲方應指定一位專案窗口，所有需求、意見及確認事項均由該窗口以書面提出。乙方接受非該窗口之指示前，得先向該窗口確認；未經確認之指示，不構成本契約內容之變更，亦不增加乙方之責任。」

英文："Single Point of Contact. The Client shall nominate one project contact. All requirements, feedback, and approvals shall be submitted in writing by that contact. Before acting on instructions from anyone else, the Contractor may seek confirmation from that contact. Unconfirmed instructions do not amend this agreement and do not increase the Contractor's obligations."

四、甲方協力義務與延遲

中文：「甲方應辦事項：甲方應於乙方請求後 ＿ 日內提供文案、圖片、素材、帳號權限及審查意見。甲方未於期限內提供者，乙方得以書面定相當期限催告；交付期依甲方延遲之日數順延，且該延遲不計入乙方之遲延。甲方延遲累計逾 ＿ 日者，乙方得就已完成部分請求給付價金；累計逾 ＿ 日者，乙方得終止契約並請求賠償因終止而生之損害。」

英文："Client Responsibilities. The Client shall provide copy, images, assets, account access, and review feedback within ___ days of the Contractor's request. If the Client does not, the Contractor may set a reasonable deadline by written notice; the delivery date shall be extended by the number of days of the Client's delay, and such delay shall not count as the Contractor's default. If the Client's cumulative delay exceeds ___ days, the Contractor may invoice for work completed to date; if it exceeds ___ days, the Contractor may terminate this agreement and claim damages arising from the termination."

五、終止與已完成部分之計價

中文：「終止：甲方於工作完成前終止本契約者，應給付乙方已完成部分之價金，並賠償乙方因契約終止而生之損害。已交付並經甲方確認之階段成果，其授權範圍依本契約約定，不因終止而變更。」

英文："Termination. If the Client terminates this agreement before the work is complete, the Client shall pay for the work completed to date and compensate the Contractor for damages arising from the termination. The licence granted over stage deliverables already delivered and approved remains as set out in this agreement and is unaffected by termination."

最後提醒一個實務細節：這些條款要在「報價階段」就出現，不要等到客戶已經口頭答應了才補一份長合約過去。人在還沒投入的時候比較容易接受規則，投入之後才看到規則，會覺得你在事後加碼。如果你的尾款已經出問題，處理方式是另一套流程，可以參考三階段催款與支付命令的實務做法。

常見問題

合約已經簽了、而且沒寫變更條款，現在還來得及補嗎

來得及，但要換一個講法。不要說「我要補一份合約」，那會讓客戶覺得你在改遊戲規則。可行的做法是把它包裝成專案管理工具：「案子進行到一半，需求累積得比較多，我做了一份變更紀錄表，之後每一項追加我都會列進去、標上時間和費用，這樣我們兩邊對進度和預算都比較有底。」先寄第一份變更單過去，程序建立起來之後，效果和寫在合約裡差不多。至於法律上的請求依據，即使合約沒寫，民法第 491 條「非受報酬即不為完成其工作者，視為允與報酬」仍然存在，關鍵是你要留得下客戶要求你做的書面紀錄。

客戶說「這些本來就應該包含」，我要怎麼證明不是

先接受一件事：如果報價單真的沒寫清楚，你在道理上不完全站得住腳，硬拗只會讓關係惡化。比較有效的處理是把爭點從「有沒有包含」轉到「怎麼往下走」：承認規格文件確實沒有寫到這一項，說明你原本的認知是什麼、為什麼會這樣估，然後提出一個雙方各退一步的方案（例如你吸收一半工時、或這一項免費但交期順延）。同時，在同一封信裡把接下來所有還沒定案的項目一次列清楚，避免同樣的爭議再發生第二次。長期的解方還是回到報價階段，把交付物清單寫成具體項目而不是抽象數量。

加價會不會讓客戶跑掉，改找更便宜的人

會，而且這通常不是壞事。願意因為一筆合理的變更費用就換人的客戶，代表他對這個案子的價值認定本來就低，繼續合作下去你只會持續虧工時。比較值得擔心的其實是相反的情況：你不敢加價，案子拖了三個月，最後你交出一個品質普通的成果，客戶也不滿意，兩邊都沒賺到。從結果來看，該收的時候收，反而是保住關係比較好的方式，因為專案能準時結束、雙方能好好道別的機率高很多。如果你怕的是收入斷掉，那要處理的是案源結構而不是這一次的談判。

免責聲明與資料來源

本文引用之法條均取自法務部全國法規資料庫，並已確認為現行有效條文（民法第 166 條之 1 的施行日期由行政院會同司法院另定、迄今未定，其餘條文不受影響）。法律適用高度依賴個案事實，本文為一般性資訊整理，不構成法律意見；涉及金額較大或已進入爭議的案件，請諮詢律師。

• 法務部全國法規資料庫．民法（第 490 條、第 491 條、第 493 條、第 498 條、第 499 條、第 501 條、第 502 條、第 505 條、第 506 條、第 507 條、第 511 條、第 514 條、第 227 條之 2、第 153 條）
• 行政院公共工程委員會．勞務採購契約範本（114 年 12 月 31 日修正版，第七條履約期限、第十五條契約變更及轉讓）
• 行政院公共工程委員會．採購契約變更或加減價核准監辦備查規定一覽表（91 年 3 月 29 日修正；其對「契約變更」的定義為「原契約標的之規格、價格、數量或條款之變更，並包括追加契約以外之新增工作項目」，本文僅借用此定義用語）

關於作者｜Andes
自由接案與遠距工作者，長期經營 digitnomad.net，寫接案實務、自架站與遠距工作的取捨。這篇文章裡的條款與句型，都是從實際吵過的案子裡整理出來的，歡迎直接複製去改成你自己的版本。