想增加收入，先不要急著降價：服務方案怎麼包裝、分層與定價？

類型	意思	例子
核心交付	沒有它就無法完成主要結果	網站建置、必要頁面、基本上線設定
情境加值	某些客戶需要，但不是所有人都需要	進階自動化、特殊串接、額外語言
客製需求	高度依個案而變動	特殊流程、企業權限、複雜資料移轉

核心交付應該變成方案骨架；情境加值可以成為高階方案或加購；高度客製的部分則不要硬包進固定價格，否則最終會由簡單客戶補貼複雜客戶。

第二步：方案差異要建立在「需求差異」，不是故意切功能

Stripe 在價值導向定價的說明裡強調，定價與包裝應該回到不同客群真正重視的結果與願付價格。放到服務方案，就是不同層級要有不同的購買理由。

例如同樣是網站服務，可以是：

基礎層：需要一個正式、可信、可自己管理的網站。
成長層：除了網站，還需要名單、表單、內容與轉換路徑。
營運層：需要更完整的自動化、持續優化、支援或團隊協作。

差異來自客戶情境，而不是「把一個本來必要的功能故意鎖到高價方案」。安全、基本資料可攜性、正常運作這類必要條件，不適合被當成逼人升級的手段。

第三步：三層方案可以用，但不是每一種服務都硬要三層

好、更好、最好（Good-Better-Best）是常見的分層方式，優點是客戶容易比較。但三層只是工具，不是規定。

如果你的客群其實只有兩種明顯情境，兩個方案可能更清楚；如果高度客製，則可能適合「標準方案＋加購＋客製報價」。真正要避免的是為了湊三層，把差異做得模糊或塞進一堆沒人需要的內容。

每一層至少要能回答：

適合誰。
主要完成什麼結果。
和下一層最大的差異。
需要客戶投入什麼。
有哪些明確不包含的範圍。

第四步：不要只列功能，要把功能翻譯成決策價值

「每月備份」「表單串接」「兩次會議」本身只是規格。文案還要再回答：所以呢？

功能	客戶真正能理解的價值
定期備份	發生更新或操作問題時，多一個可恢復的安全點
表單串接	訪客詢問能被集中收到，不必靠私訊散落處理
兩次顧問會議	重要決策能在執行中被檢查，而不是做到最後才發現方向錯

價值不是誇大結果，而是清楚說明這項交付能降低哪種阻力、節省哪段時間，或讓哪個結果更容易完成。

第五步：價格不要只用工時加成，也要看客戶價值與交付成本

服務價格至少要同時看三件事：客戶願意為什麼結果付費、你交付這個結果的成本，以及目前市場可接受的比較範圍。

只按工時算，很容易讓效率高的人反而收得少；只談價值、不管成本，又可能賣得很多卻沒有毛利。

可以先算出：

每個方案平均需要多少交付工時。
第三方工具、金流、外包與固定成本。
修改、客服與售後的平均負荷。
合理毛利與可承受的同時客戶數。

再透過真實客戶對話、歷史成交與方案選擇去驗證願付價格，而不是只看競品多少就跟著定價。

第六步：加購項目要解決「少數人才有的需求」

好的加購不是把方案拆碎後再收一次錢，而是把不是每位客戶都需要、但某些情境價值很高的部分獨立出來。

例如：

額外頁面或額外語言。
特殊 API／系統整合。
更多顧問時數或客製工作坊。
大量資料匯入與人工整理。
高頻率內容更新或專屬支援。

這樣標準方案能維持清楚，複雜需求也不會默默吃掉毛利。

第七步：方案一定要寫「不包含什麼」

服務方案如果只寫包含內容，客戶很容易用自己的理解補上空白。例如「網站完成」對不同人，可能代表文案、攝影、Logo、SEO、廣告、維護全部都包含。

所以方案頁與報價單最好同時說清楚：

修改次數與方式。
客戶要提供的素材。
第三方費用是否另計。
交付後支援多久。
新增需求怎麼報價。
哪些工作明確不在本次範圍。

邊界不是降低成交，而是降低成交後的誤解與無限加需求。

第八步：後續收入要建立在持續價值，不是硬綁續約

一次性服務做完後，如果客戶的需求本來就會持續存在，就可以設計後續服務，例如維護、主機、內容更新、顧問、優化、報表或培訓。

關鍵是要回答：「下一期客戶為什麼還需要？」如果只是因為你希望有固定收入，而沒有持續交付的價值，續約很難穩定。

反過來說，若網站確實需要安全更新、備份與技術維護，或行銷方案需要固定分析與調整，這些就是合理的持續服務。

方案之間要有自然升級路徑，不是只把高價版塞更多東西

好的分層會讓客戶知道：什麼情況下需要往下一層升級。升級理由可以是客戶規模變大、需要更多支援、開始有團隊協作，或原本只要完成基礎建置，後來進入獲客與成長階段。

例如基礎方案負責「先把網站正式上線」，成長方案再處理名單、內容與轉換，營運方案則處理持續優化與團隊支援。每一層解決的是不同階段的問題，而不是單純多送幾頁、多送幾次會議。

如果高階方案只是把低階方案所有東西加倍，客戶很容易只比較數量；如果每一層都對應新的需求，升級會更有邏輯。

方案頁要不要直接放價格？看購買複雜度決定

標準化程度高的方案，可以公開固定價格或清楚起價；需求差異大的服務，可以先公開價格區間、影響報價的因素與基本門檻，再進一步詢價。

完全不談價格，會讓部分合適客戶因為不確定而離開；所有複雜案都硬塞固定價格，也容易造成交付失控。可以延伸看服務型網站要不要放價格？公開價格、起價與詢價怎麼選。

收入增加之前，先算「這個方案最多能同時交付幾位客戶」

服務方案一旦變得比較好買，下一個問題往往不是沒有客戶，而是交付容量。若每一位標準方案客戶平均都需要大量會議、修改與即時回覆，成交越多不一定代表利潤越高。

可以先估每一層方案的平均工時與最忙時段，再看哪些工作一定要由你本人處理、哪些可以標準化、哪些能交給團隊或工具。這會決定你真正能承接的同時客戶數。

如果高階方案價格提高，卻同時讓服務工時增加更多，實際毛利反而可能更低。所以方案設計不只要看客戶願不願意買，也要看你能不能穩定交付。

方案包裝完成後，先用真實成交驗證，不要一次做得太大

第一版不需要一次設計 5 個方案、20 個加購。可以先把最常見的一種需求整理成標準方案，找幾個真實客戶測試。

觀察的不只是「有沒有買」，還包括：

客戶最常問哪個差異。
哪一個方案最常被選。
哪些內容大家都不在意。
哪些需求總是成交後才冒出來。
實際交付工時和原本預估差多少。

方案不是一次定型，而是透過成交與交付資料持續修正。Stripe 對價值導向定價的建議也把持續回饋與不同客群的價值差異列為重要依據。

一張檢查表：你的服務現在真的「好買」嗎？

一句話能說清楚適合誰、解決什麼問題。
方案名稱反映需求，而不是只有 A／B／C。
每一層都有明確購買理由。
客戶知道包含與不包含什麼。
價格能支撐實際交付成本。
高複雜需求有加購或客製機制。
後續服務有持續價值，不只是綁約。
網站上能看懂價格或至少知道報價依據。
實際成交與交付資料會回頭修正方案。

FAQ

服務一定要做三種方案嗎？

不用。三層方案只是常見做法。若客群只有兩種明顯需求，兩層更清楚；高度客製的服務，也可以採標準方案加客製報價。

方案越多，越能滿足不同客戶嗎？

不一定。方案太多會增加比較負擔，也會提高內部交付複雜度。先服務最常見、最值得做的需求，再逐步增加。

價格比競爭對手高，怎麼辦？

先確認你交付的結果、範圍、專業與支援是否真的不同。如果差異說不清楚，客戶自然只剩價格可比較；如果差異有價值，就要用清楚方案與證據呈現。

怎麼知道客戶願意付多少？

不要只直接問「你願意付多少」。可以從歷史成交、拒絕原因、不同方案選擇、價值訪談與價格範圍測試交叉判斷，並持續觀察真正的購買行為。

低價方案應該把功能砍很多嗎？

應該降低的是服務範圍、支援深度或適用情境，而不是拿掉基本安全、正常交付或必要品質。低價方案仍然要能完成它承諾的核心結果。

服務包裝後還能做客製嗎？

可以。標準方案負責大多數共同需求，少數高價值特殊需求再用加購或客製處理，通常比每一案全部從零報價更容易管理。

結論：增加收入，先讓價值更容易被理解與購買

服務包裝的目的，不是把原本的工作換幾個好聽名稱，也不是用三層價格逼客戶升級。

真正有效的方案，會讓客戶更容易判斷「這是不是我現在需要的」，同時也讓你更容易估工、報價、交付與續約。

先從真實客戶問題整理出核心結果，再設計邊界、方案差異、價格與後續服務。當購買決策變清楚、交付也變穩定，收入才有機會在不無限增加工作量的情況下成長。

參考資料：
Stripe｜Value-driven pricing strategy: What it is and how it works，2025。
Stripe｜Tiered pricing – the basics: A guide for a strategic approach，2026。
Madhavan Ramanujam、Georg Tacke｜Monetizing Innovation。

先分清楚：你現在賣的是工作項目，還是客戶結果？

為什麼降價通常不是第一個該做的動作？

第一步：先找出「所有客戶都需要」的核心交付