行銷

pricing

依客群、價值指標、使用情境與銷售模式設計 SaaS 定價與包裝,區分方案、加購與護欄,並用可驗證的實驗取代猜測。

查看來源 ↗
作者/來源coreyhaines31★ 50,312 GitHub Stars
測試版本2.1.1更新日期:2026-09-05T04:48:02Z
支援平台OpenAI · Claude本次實測平台
安裝方式npx skills add coreyhaines31/marketingskills --skill pricing
公平比較方式

三個問題,分別測載入前與載入後。

每次回答都在全新環境中產生。兩邊使用相同模型與設定,唯一差別是右側載入了這個 Skill。

模型版本gpt-5.6-sol帳號方案ChatGPT Plus思考強度medium執行工具codex-cli-native-skill
真實測試使用本機已登入的 ChatGPT Plus 實際執行,完成於 2026年9月7日。所有檢查通過後才公開,回答未經人工改寫。
三階段測試3 個問題全部完成版本核對3/3 通過環境清理9/9 通過測試隔離每回合全新環境
01
基礎題

設計三層方案

測試問題

B2B 報表 SaaS 服務 1 人接案者、5–20 人代理商與 20 人以上企業;主要價值隨每月工作區數增加,成本隨資料刷新次數增加;採 self-serve + enterprise sales。請設計三層方案、value metric、包含額度、升級觸發與 enterprise 邊界,不需給最終價格數字。

載入前 · 0 個 Skill載入後 · 版本已核對再次確認 · 0 個 Skill已確認模型套用 Skill三個環境皆已清理
未載入 Skill895 tokens · 21339 ms
| 方案 | 適用客群 | Value metric/計費單位 | 包含額度 | 升級觸發 | |---|---|---|---|---| | **Solo** | 1 人接案者 | 主要:**每月活躍工作區**;次要:**資料刷新量** | 1 位使用者、少量活躍工作區、每工作區每日 1 次排程刷新、基本資料來源與報表範本、分享連結/匯出、標準支援 | 工作區持續超額;需要更頻繁刷新、多使用者協作、品牌客製或更多資料來源 | | **Agency** | 5–20 人代理商 | 主要:**每月活躍工作區級距**;次要:**刷新點數池** | 多使用者、較高工作區額度、團隊共用刷新點數、較高刷新頻率、客戶/專案資料隔離、角色權限、白標與範本複製、優先支援 | 工作區或刷新點數連續超額;需要 20 人以上、SSO/SCIM、稽核紀錄、合約 SLA、集中治理或專屬部署 | | **Enterprise** | 20 人以上企業及高治理需求客戶 | **工作區承諾量 + 刷新容量承諾**,採年約;必要時加計超額或預購容量 | 議定使用者與工作區數、較高或客製刷新容量、SSO/SCIM、進階 RBAC、稽核紀錄、資料保留與區域選項、SLA、導入協助、專屬客戶成功與採購/法務支援 | 依合約做容量擴充、刷新容量包或更高服務等級;不以一般 self-serve 方案承接 | **Value metric** - 對外主指標採「每月活躍工作區數」,因為它最貼近客戶管理的客戶/專案價值,也容易預估與核對。 - 成本控制採「刷新點數」:依刷新執行次數計量;若不同資料來源的成本差異明顯,可設定不同點數權重。 - 使用者席次作為方案護欄,而非主要計價指標,避免懲罰協作並降低共享帳號誘因。 - 「活躍工作區」應明確定義為當月曾刷新、發布或匯出的工作區;封存工作區不計費。 **額度與超額機制** - 工作區採級距或加購包,避免每新增一個客戶就被迫整體升級。 - 刷新點數採團隊共用池;接近額度時通知,超額時可購買點數包或自動超額計費,不應立即停止既有報表。 - 建議在 70%、90%、100% 額度提供用量通知,並顯示預估月底用量。 - 當客戶連續 2–3 個月使用加購包或超額費後,提示升級至更合適的方案。 **Enterprise 邊界** 符合任一項即可轉交 enterprise sales: - 20 人以上,或需要跨部門/多團隊集中管理。 - 要求 SSO、SCIM、進階 RBAC、稽核紀錄或管理員控制台。 - 要求 SLA、資安/法務審查、DPA、客製付款條件或採購流程。 - 要求資料區域、客製保留政策、私有網路、專屬/單租戶部署。 - 工作區或刷新需求超出公開 self-serve 上限,或需要承諾容量與量體折扣。 - 需要導入、資料遷移、客製整合或專屬客戶成功服務。
已載入 Skill +2569 tokens · 58513 ms
## 建議定價架構 採「方案月費+工作區擴充包+刷新額度包」的混合模式: - 主要 value metric:每月活躍工作區數 - 成本護欄:每月資料刷新額度 - 不以席次作為主要收費單位,避免抑制代理商協作 - 工作區定義:當月曾連接資料、刷新或發布報表的獨立客戶/業務環境 - 1 次刷新:單一工作區執行一次完整排程刷新 | 方案 | Solo | Agency(主推) | Enterprise | |---|---|---|---| | 適用對象 | 1 人接案者 | 5–20 人代理商 | 20 人以上企業、成熟代理商 | | 購買方式 | Self-serve | Self-serve,可選銷售協助 | Enterprise sales | | 活躍工作區 | 3 個 | 25 個 | 50 個起,依合約配置 | | 每月刷新額度 | 100 次 | 3,000 次,共用額度池 | 客製共用池;高頻刷新另議 | | 使用者 | 1 位正式成員+客戶檢視者 | 最多 20 位團隊成員+客戶檢視者 | 依組織需求配置 | | 刷新頻率 | 每日或手動 | 最快每數小時 | 可支援更高頻率與專屬容量 | | 核心功能 | 報表建立、範本、匯出、排程寄送 | Solo 全部功能,加上白標、客戶管理、權限、批次操作、API | Agency 全部功能,加上 SSO/SCIM、稽核記錄、進階權限與治理 | | 支援 | 標準線上支援 | 優先支援 | SLA、導入服務、指定成功經理 | | 商務條件 | 月繳/年繳 | 月繳/年繳 | 年約、發票、採購與客製條款 | ## 擴充與超額機制 - 工作區擴充:以固定工作區包加購,例如每次增加 5 個;不要按單一工作區零碎計價。 - 刷新擴充:以預付刷新額度包加購,未使用額度原則上不跨月,年度方案可給有限度滾存。 - 工作區決定客戶取得的價值,因此應比刷新額度更醒目。 - 刷新是成本控制項,不應讓偶發尖峰立刻迫使用戶升整個方案。 - 在用量達 80% 時通知;額度用完後由客戶預先選擇自動加購、暫停排程或降低刷新頻率,避免意外帳單。 ## 升級觸發 ### Solo → Agency 符合任一條件即提示升級: - 需要第 4 個以上活躍工作區。 - 需要多人共同編輯或進階角色權限。 - 需要白標、客戶入口、API或批次管理。 - 刷新用量連續兩個月超過 Solo 額度的 150%。 - 頻繁購買刷新包,使 Agency 方案更合適。 ### Agency → Enterprise 符合任一條件即轉交銷售: - 超過 50 個活躍工作區,或需大量客製工作區容量。 - 每月刷新量長期超過約 10,000 次,或需要小時級/近即時刷新。 - 需要 SAML SSO、SCIM、完整稽核記錄或集中式權限治理。 - 需要 SLA、資料駐留、私有網路、客製 DPA、安全審查或供應商採購流程。 - 需要多事業部、母子帳戶、成本中心或客製帳務。 - 需要專屬導入、成功經理或優先容量。 ## Enterprise 邊界 Enterprise 不應只以公司人數判斷;「20 人以上」是銷售訊號,不是唯一門檻。建議設定兩種明確邊界: - 容量邊界:超過 50 個活躍工作區或高刷新量。 - 治理邊界:只要需要 SSO、SCIM、SLA、安全/法務審查或客製合約,即進入 Enterprise,無論工作區數。 上述工作區與刷新額度屬初始假設,應再用實際刷新成本、代理商平均客戶數及用量分布校準;但「工作區承載價值、刷新額度控制成本」的架構應維持不變。
02
實務題

修正功能堆疊定價

測試問題

目前 Basic/Pro/Business 只是隨機拆功能,所有客群都抱怨不知道選哪個;使用資料顯示真正差異是每月報表 3、20、無上限,以及是否需要多人審核。請重新設計 packaging、方案命名、比較表架構與 migration 計畫,避免強迫既有客戶立即升價。

載入前 · 0 個 Skill載入後 · 版本已核對再次確認 · 0 個 Skill已確認模型套用 Skill三個環境皆已清理
未載入 Skill2035 tokens · 42205 ms
# 新版方案設計 ## 1. Packaging 原則 將方案差異集中在兩個已被使用資料驗證的購買驅動因素: 1. 每月報表需求量:3 份、20 份、無上限 2. 工作流程複雜度:個人使用或多人審核 其他功能不再隨機拆分: - 核心功能三個方案皆提供 - 安全性、穩定性與基本支援不作為升級門檻 - 次要限制只用於成本控制,不作為主要行銷訊息 - 「無上限」應搭配合理使用政策;實際成本上限尚未提供,定價前需驗證毛利 ## 2. 方案命名與定位 | 新方案 | 適合誰 | 報表額度 | 多人審核 | |---|---|---:|---| | **Starter** | 每月只需少量固定報表的個人或小型團隊 | 3 份/月 | 不提供 | | **Growth** | 報表已進入日常營運、需要較高用量的團隊 | 20 份/月 | 不提供 | | **Workflow** | 需要跨角色協作、審核與治理的組織 | 無上限* | 提供 | \*受合理使用政策約束。 命名刻意避免 Basic/Pro/Business 這類抽象等級,讓名稱對應客戶所處的工作階段。若品牌希望更直白,也可採用 **3 Reports/20 Reports/Workflow**,但品牌延展性較弱。 ### 升級邏輯 - 報表不超過 3 份:選 Starter - 報表介於 4–20 份:選 Growth - 超過 20 份:選 Workflow - 無論報表量,只要需要多人審核:選 Workflow 多人審核是 Workflow 的核心價值,不應拆成零散附加功能。若市場對此價格敏感,可在後續測試「Workflow add-on」,但不建議首波同時推出,以免再次增加選擇複雜度。 ## 3. 比較表架構 比較表先協助客戶做決策,再補充完整功能清單。不要從數十項勾選框開始。 ### 第一層:快速選擇 | | Starter | Growth | Workflow | |---|---|---|---| | 一句話定位 | 少量定期報表 | 日常報表營運 | 大量報表與正式審核 | | 每月報表 | 3 | 20 | 無上限* | | 多人審核 | — | — | ✓ | | 建議對象 | 個人/輕量使用 | 成長中團隊 | 多角色組織 | | 價格 | 待定 | 待定 | 待定/聯絡銷售 | | CTA | 開始使用 | 選擇 Growth | 啟用 Workflow | 在表格上方加入兩題選擇器: 1. 每月需要幾份報表? 2. 是否需要兩人以上提交、審核或核准? 回答後直接推薦方案,並說明原因,例如:「你需要約 12 份報表且不需多人審核,因此建議 Growth。」 ### 第二層:依工作分類的功能 完整比較表依客戶任務分組,而非依內部產品模組分組: - 建立與輸出報表 - 分享與協作 - 審核與治理 - 管理與權限 - 支援與服務 共同功能標記為「所有方案皆包含」,只突出真正不同之處。避免用大量刻意製造差異的勾選項暗示低階方案不完整。 ### 第三層:限制與政策 在表格下方清楚說明: - 報表額度如何計算 - 未使用額度是否結轉 - 超額時是停止、加購還是提示升級 - 「無上限」的合理使用範圍 - 多人審核包含的角色、步驟與歷程紀錄 上述規則目前未提供,正式上線前必須定義,否則方案仍會產生理解落差。 ## 4. Migration 計畫 ### 階段一:建立對照與保護機制 先依既有客戶最近 3–6 個月的實際用量及多人審核需求,產生建議方案,不只根據原方案名稱搬移。 基本原則: - 新客戶:新版發布後直接使用新方案 - 既有客戶:保留原價格與原權益至少 12 個月 - 若合約承諾更長,保護期延至當期合約結束 - 不因重新命名立即減少功能或提高價格 - 客戶可自願切換新版,但切換前顯示完整差異 - 切換新版後是否能返回舊版,需在操作前明確告知 ### 階段二:影子映射 發布前先在後台為每位既有客戶计算: - 過去 3、6 個月的平均及最高報表量 - 是否實際使用多人審核 - 對應的新方案 - 新舊價格差異 - 是否可能失去既有權益 先運行一個帳務週期但不改計費,以找出異常映射與可能遭遇大幅漲價的客戶。 ### 階段三:通知與自願遷移 分三次溝通: - 上線前 60 天:說明方案將變得更容易選擇,既有價格暫時不變 - 上線前 30 天:提供個人化建議方案、新舊權益及價格比較 - 上線當日:開放一鍵切換;未操作客戶維持原方案 避免使用「你必須升級」的語言。訊息重點應是:「你的現有方案與價格目前保持不變;依實際使用情況,我們建議未來選擇 Growth。」 ### 階段四:逐步轉換舊方案 保護期結束前至少 90 天,再提供三種選項: 1. 遷移至建議的新方案 2. 保留較低用量方案並加購超額報表 3. 聯絡客服安排過渡方案 若新價格明顯較高,可採用分階段調整,例如首年只承擔部分價差;具體幅度需根據價格、毛利與流失風險決定,目前資料不足,不宜直接設定。 舊方案停止銷售,但應在帳單中標示為「Legacy」,不要立即刪除。待絕大多數客戶自然遷移後,再決定是否設最終退場日期。 ## 5. 遷移保護規則 - **No surprise bill:** 未取得明確同意,不自動切換至更高價格。 - **No capability loss:** 保護期內不移除客戶已在使用的功能。 - **Best-fit recommendation:** 依實際使用推薦,不把所有高用量客戶一律推向最高方案。 - **Usage alerts:** 在 50%、80%、100% 額度時提醒,避免月底才發現受限。 - **Temporary overage grace:** 遷移初期允許短期超額,不立即中斷報表。 - **Human exception path:** 對合約客戶、季節性用量及特殊工作流程提供人工審查。 ## 6. 成效指標 新版上線後應追蹤: - 訪客能否正確選擇方案 - 定價頁到試用/購買的轉換率 - 因「不知道選哪個」產生的客服工單 - 各方案報表額度使用率 - Starter/Growth 的超額頻率 - Workflow 客戶的多人審核啟用率 - 既有客戶自願遷移率、降級率與流失率 - 遷移後每客收入及毛利变化 首要成功標準不是短期升價收入,而是方案选择错误与相关投诉明显下降,同时既有客户流失保持在可接受范围内。具体价格、保护期最终长度及合理使用门槛,仍需结合成本、合约结构与客户用量分布验证。
已載入 Skill +3434 tokens · 80301 ms
## 建議方案架構 把所有核心功能統一開放,不再隨機拆分;只用兩個真正影響購買的維度定價: 1. 每月產出多少份報表:3、20、無上限 2. 是否需要多人審核:獨立加購,不強迫客戶為審核功能升到最高方案 ### 方案命名 | 方案 | 定位 | 每月報表 | |---|---|---:| | **Launch 3** | 偶爾製作報表 | 3 份 | | **Grow 20** | 固定、持續產出 | 20 份 | | **Scale Unlimited** | 高頻、大量產出 | 無上限 | 名稱直接帶出容量,避免 Basic/Pro/Business 這類無法解釋差異的標籤。 多人審核命名為 **Review & Approvals**,作為所有方案皆可加購的協作模組。若企業級安全、權限或合約需求確實存在,可另設 Enterprise,但不應只因「無限報表」就被歸入企業方案。 ## Packaging 原則 - 所有方案包含相同的核心建立、編輯、匯出與分享能力。 - 方案升級只增加報表額度,不以零碎功能製造障礙。 - Review & Approvals 提供多人審核、指定審核人、核准狀態與流程紀錄。 - 不按一般使用者席次收費,除非資料證明使用者數量與客戶價值高度相關。 - 接近額度時於 70%、90%、100% 提醒,不產生無預警帳單。 - 達上限後允許購買報表加購包或升級;不要鎖住既有報表。 - Unlimited 應訂明合理使用政策,但價格頁仍顯示「無上限」,不要用模糊點數取代。 這會形成簡單的混合模型: **基本方案價格(報表容量)+ Review & Approvals 加購費** 如此,低用量但需要審核的團隊不必被迫購買 Unlimited;高用量的個人使用者也不必為不需要的協作功能付費。 ## 定價頁與比較表架構 頁首先讓客戶回答兩個問題: > 每月需要幾份報表? > 是否需要兩人以上共同審核? ### 首屏方案卡 | | Launch 3 | Grow 20 | Scale Unlimited | |---|---:|---:|---:| | 適合 | 偶爾產出 | 固定產出 | 高頻產出 | | 每月報表 | 3 | 20 | 無上限 | | 核心功能 | 全部包含 | 全部包含 | 全部包含 | | Review & Approvals | 可加購 | 可加購 | 可加購 | | CTA | 選擇 Launch | 選擇 Grow | 選擇 Scale | 將 **Grow 20** 標示為「最常選擇」,前提是實際客戶分布支持;不要只為製造錨定效果而指定。 ### 詳細比較表順序 1. **報表容量** - 每月報表數 - 額度重置時間 - 超額處理方式 - 額外報表價格 2. **審核與協作** - 單人確認:所有方案包含 - 多人審核:Review & Approvals - 指定審核人 - 審核狀態與歷程 3. **所有方案共同包含** - 將現有核心功能集中列在一個區塊 - 不要重複三欄勾選,避免客戶誤以為仍有隱藏差異 4. **FAQ** - 未使用額度是否累積 - 超過額度後會發生什麼 - 是否能隨時升降級 - 加購審核後有多少審核人 - Unlimited 的合理使用範圍 - 既有客戶如何遷移 ## Migration 計畫 ### 第一階段:盤點與映射 - 保存每位既有客戶的目前價格、功能權限、報表用量與審核使用狀況。 - 以最近六個月的最高月用量,而非平均值,建立建議方案。 - 遷移映射採「權益不減」原則:新方案不得突然移除客戶已在使用的功能。 - 在後台先進行 shadow mapping,只顯示建議方案,不改帳單或權限。 ### 第二階段:新客戶先上線 - 新 packaging 先只套用新客戶。 - 觀察至少一至兩個完整帳單週期。 - 追蹤各方案轉換率、Grow 選擇率、加購率、升級率、銷售詢問與「不知道選哪個」類客服量。 - 價格金額先維持為待驗證項目;目前缺少現價、ARPU、轉換率與支付意願資料,不宜直接指定價格。 ### 第三階段:既有客戶選擇性遷移 向既有客戶提供: - 系統建議的新方案與選擇理由。 - 至少 90 天通知期。 - 新架構推出後 **12 個月價格保護,或保障至下一次續約,以較晚者為準**。 - 保護期內維持原付款金額及既有權益。 - 可自願提前遷移;年繳鎖價或一次性 credit 可作為誘因,但不強迫。 - 如果客戶不操作,自動映射至不低於既有權益的方案,不立即加價。 建議映射: | 既有使用狀況 | 建議新方案 | |---|---| | 每月不超過 3 份、無多人審核 | Launch 3 | | 每月 4–20 份、無多人審核 | Grow 20 | | 每月超過 20 份、無多人審核 | Scale Unlimited | | 任一用量且需要多人審核 | 對應報表方案+Review & Approvals | | 用量接近邊界或資料不足 | 暫時配置較高權益,下一週期再確認 | ### 第四階段:分批結束保護期 - 先選 5–10% 的低風險客群測試,再依帳單週期分批展開。 - 不永久保留 Legacy 方案,但也不一次切換全部客戶。 - 保護期結束後若價格上升,可設定年度漲幅上限,建議先測試 10–15%,而非一次補足全部價差。 - 若某批次的流失率、降級率或客服量顯著高於基準,暫停下一批並調整映射或溝通。 - 客戶若因新結構付款更少,立即適用較低價格;不要只執行向上的調整。 ## 對客溝通主訊息 > 我們正在簡化方案。之後所有方案都包含完整核心功能,您只需依每月報表數量,以及是否需要多人審核來選擇。既有權益不會突然消失,價格也不會立即調升;我們會先提供建議方案與價格保護期,讓您有充足時間決定。 最終應讓客戶在十秒內完成判斷:**需要 3、20 還是無限份報表;需要或不需要多人審核。**
03
壓力題

規劃價格實驗

測試問題

團隊想把 Pro 從 NT$599 漲到 NT$899,但只有 60 位付費客戶,不能直接對全部人 A/B。請提出低樣本下的研究與 rollout 計畫,包含訪談、willingness-to-pay、先測新客、護欄、成功指標與回滾條件。

載入前 · 0 個 Skill載入後 · 版本已核對再次確認 · 0 個 Skill已確認模型套用 Skill三個環境皆已清理
未載入 Skill2294 tokens · 46666 ms
# Pro 低樣本定價研究與 Rollout 計畫 ## 原則 - 不對現有 60 位付費客戶直接做全面 A/B。 - 先測「新客的真實購買行為」,現有客以訪談、續約意向及小批次 rollout 驗證。 - NT$899 比 NT$599 高 50%;單看營收,新價格最多可承受約 33% 的付費量下降才打平,但實務上應設定更嚴格門檻,避免成長、口碑與留存受損。 - 低樣本結果只能提供方向性證據,不應宣稱達到傳統統計顯著。 ## 第一階段:質化訪談 招募 15–20 人: - 8–10 位現有 Pro 客戶:高頻、低頻、近期升級及曾考慮取消者都要涵蓋。 - 4–6 位符合 Pro 輪廓、但尚未付費的活躍用戶。 - 3–4 位近期流失或降級者。 訪談時先問價值,再談價格,避免 NT$899 成為錨點: 1. Pro 解決了什麼問題?若取消,會改用什麼方案? 2. 哪些功能是升級或續約的主要原因? 3. 使用頻率、替代方案及替代成本。 4. 在什麼情況下會覺得 Pro 值得更高價格? 5. 價格從 NT$599 調整後,可能續約、降級或取消的原因。 輸出: - 主要購買情境與高/低價格敏感族群。 - NT$899 必須搭配的價值說明或產品改善。 - 取消風險、信任風險與客戶可接受的通知方式。 ## 第二階段:Willingness-to-pay 對訪談者與更廣泛的非付費活躍用戶進行簡短調查,目標 30–50 份有效回覆。結果僅作為區間估計,不單獨決定價格。 採兩種方法交叉驗證: - Van Westendorp:詢問「便宜到懷疑品質、划算、開始覺得貴、貴到不考慮」的價格。 - Gabor-Granger:將受訪者隨機分配到 NT$699、NT$799、NT$899 或 NT$999 起問,詢問是否願意購買;避免所有人先看到 NT$899。 降低假設性偏誤: - 明確列出當前功能、付款週期和取消政策。 - 加入「若今天真的需要付款,是否仍會購買」。 - 記錄價格接受度及信心程度,不把「可能購買」等同成交。 - 若可行,以可退款訂金、候補名單或限時報價驗證真實承諾。 通過條件:NT$899 落在合理價格區間內,且目標客群的購買意願沒有相對 NT$599 出現明顯斷崖式下降;若答案分歧很大,優先測 NT$799 或做分層方案。 ## 第三階段:先測新客 現有客維持 NT$599,不改價。新訪客採按時間區段或週次切換價格,降低流量來源差異: 1. 基準期 2–4 週:維持 NT$599,記錄完整漏斗。 2. 測試期 2–4 週:新客顯示 NT$899。 3. 驗證期:再切回 NT$599 一週,或交替兩個完整週期,以排除季節、投放和流量品質變化。 若流量足夠,可對新客隨機分配價格;同一帳號應固定看到相同價格,並避免搜尋、裝置切換造成價格不一致。付款後不得追溯改價。 每週同時記錄: - 價格頁到結帳率。 - 結帳到付款成功率。 - 每位合格訪客營收。 - 新增付費數及獲客成本。 - 退款、取消、客服詢問和價格負面回饋。 - 7/14/30 日啟用、使用與早期留存。 ## 低樣本判讀方式 以「每位合格訪客營收」作為主要指標: `每位合格訪客營收 = 新客付費率 × 實收價格` NT$899 的損益平衡付費率約為 NT$599 時的 66.6%。但建議成功門檻設定為: - 每位合格訪客營收至少提升 15%。 - 付費率不得下降超過 25%。 - 貝葉斯估計中,「新價格使每位合格訪客營收提升」的機率至少達 80%。 - 即使尚未達門檻,也先跑到最低資訊量,例如每個價格至少 15–20 筆成交或 4 個完整週期;若流量不足,應承認結論仍不確定,不以單週結果決策。 ## 第四階段:現有客小批次 Rollout 新客測試通過且至少觀察到初步 30 日品質後,再處理現有客: - 第一批:5–10 位高使用、高價值且近期不在重大客訴中的客戶。 - 至少提前一個完整帳單週期通知。 - 可先採 NT$699/799 過渡價、年度方案鎖價,或為早期支持者保留 3–6 個月優惠。 - 每批觀察一個續約週期,再擴到 25%、50%、100%。 - 每批保留未調價客群作為同期參考,但不必進行大規模 A/B。 通知應清楚交代生效日期、方案價值、降級/取消方式及是否提供過渡選項,不能用模糊或強迫續約方式降低流失。 ## 護欄 - 不對同一客戶反覆顯示不同價格。 - 不在付款最後一步突然加價。 - 不以假折扣或虛構原價測試。 - 客服可提供有限、規則一致的留客方案。 - 價格實驗期間凍結重大投放、產品包裝或 onboarding 改版;無法凍結時必須分開標記。 - 分別追蹤自然流量、廣告、地區、裝置與主要客群,避免流量組成誤導結果。 - 既有客每批人數設上限,確保異常時可人工處理。 ## 成功指標 新客正式採用 NT$899,需同時滿足: - 每位合格訪客營收提升至少 15%。 - 退款率增加不超過 2 個百分點。 - 30 日取消率增加不超過 5 個百分點。 - 核心啟用率下降不超過 5 個百分點。 - 客服價格相關負面事件沒有超過基準期兩倍。 - 獲客回收期仍在團隊可接受範圍內。 現有客 rollout 成功需滿足: - 每批續約率下降不超過 10 個百分點。 - 該批月度經常性營收高於不漲價的預估值。 - 降級加取消比例不超過 15%。 - 無重大信任、合規或付款爭議。 - 調價後至少觀察兩個帳單週期;年度客戶則需另行追蹤,不能假設月繳結果可直接套用。 ## 回滾條件 任一條件成立即暫停擴量,新客恢復 NT$599 或降至 NT$799;尚未生效的現有客調價延後: - 每位合格訪客營收連續兩個完整週期低於基準。 - 新客付費率下降超過 30%,且沒有流量品質變化可解釋。 - 退款率增加超過 3 個百分點。 - 30 日取消率增加超過 8 個百分點。 - 現有客單批取消或降級超過 20%。 - 價格相關客訴超過基準三倍。 - 出現公開負面事件、付款爭議或價格呈現不一致。 - 資料追蹤異常,無法可靠辨識價格、來源或 cohort。 回滾後應保留已成交客戶的原交易條件,完成流失訪談,判斷問題來自價格、價值包裝、客群或溝通,再決定測試 NT$799、增加年度折扣,或維持 NT$599。
已載入 Skill +4056 tokens · 89516 ms
## 建議結論 不要直接把 60 位既有客戶全面升到 NT$899。先把 NT$899 視為「待驗證假設」,依序用訪談、WTP 研究、新客實際購買行為,以及既有客戶分批遷移驗證。 NT$599 → NT$899 是約 50% 漲幅。在其他條件不變時,新價格的付費轉換率只要維持原本的 **66.6%**,短期新客營收即可打平: `899 價格轉換率 ÷ 599 價格轉換率 ≥ 599 ÷ 899 = 66.6%` 但最終仍須納入退款、留存、服務成本與品牌影響;不能只看首月 MRR。 ## 第一階段:建立基準線 先固定方案內容,避免同時更改功能、試用期或折扣,否則無法判斷結果是價格還是包裝造成。 整理最近 8–12 週資料: - 定價頁訪客 → 結帳 → 付費轉換率 - 各來源、客群及使用情境的轉換率 - 7/30/60/90 日退款與流失 - 啟用率及核心功能使用率 - 每位新客營收、毛利及支援量 - 因價格未成交、降級或取消的原因 主要評估單位應是「每位合格訪客/試用者帶來的 90 日毛利」,而不只是付費人數。 ## 第二階段:訪談研究 進行約 12–18 場訪談,追求不同客群的訊號飽和,而非統計代表性: - 6–8 位高使用、高留存的現有 Pro 客戶 - 3–4 位低使用或價格敏感客戶 - 3–4 位近期流失或降級者 - 3–4 位考慮過但沒有購買的潛在客戶 訪談先談價值,再談價格: 1. 當初為何購買或沒有購買? 2. 若沒有產品,會用什麼替代?成本是多少? 3. 產品實際節省多少時間、費用或風險? 4. 哪個成果最值得付費? 5. 目前 NT$599 感覺如何?為什麼? 6. 若為 NT$899,會購買、需要考慮,還是不會購買? 7. 什麼條件或功能能讓 NT$899 合理? 8. 若取消,最可能原因是價格、使用頻率,還是價值不足? 不要直接把「你最多願意付多少」當成決策依據;受訪者的假設答案通常比真實付款樂觀。 ## 第三階段:Willingness-to-pay 由於樣本低,Van Westendorp 只能作方向性參考,不能宣稱找到統計上的「最佳價格」。 建議向 25–40 位符合目標輪廓的潛在客戶或近期試用者進行: - Van Westendorp 四問:太便宜、便宜、開始覺得貴、貴到不考慮。 - Gabor–Granger:隨機由 NT$699、799、899 或 999 起問「會不會購買」,避免所有人都從低價一路問上去。 - 購買意向追問:「一定會買/可能會買/不會買」,並詢問原因。 - 最強驗證:提供 NT$899 的真實付費、可退訂預購或付費試用,而不是只填問卷。 分析時按使用強度、客群、替代方案與價值成果分組。若 NT$899 只被高價值客群接受,應考慮重新包裝 Pro,而不是把同一方案全面漲價。 ## 第四階段:先測新客 既有 60 位客戶完全不動,先測沒有 NT$599 價格錨點的新客。 若新客流量足夠: - 新訪客以帳號或裝置固定分流,NT$599 與 NT$899 各 50%。 - 至少跑滿 4 週並涵蓋完整週期。 - 使用貝葉斯區間或精確信賴區間呈現不確定性,不因「未達顯著」就視為兩價格相同。 - 不要頻繁偷看數據後提早宣布勝負。 若流量太低: - 對全部新客上 NT$899,連續跑 4–8 週。 - 與相同渠道、星期與活動條件下的前期 cohort 比較。 - 可採兩週 NT$599、兩週 NT$899 的 switchback,但必須固定訪客看到的價格,並控制行銷活動差異。 - 把結果標記為準實驗,保留季節性及流量組成造成的因果不確定性。 ## 新客成功指標 晉級至下一階段需同時滿足: - `NT$899 轉換率 / NT$599 基準轉換率 ≥ 66.6%`,且每位合格訪客營收沒有下降。 - 以 90 日毛利估計,NT$899 優於 NT$599 的機率至少 80%;這只足以晉級,不代表已證明永久勝出。 - 啟用率下降不超過 5 個百分點。 - 7/30 日退款率未比基準增加超過 5 個百分點。 - 30/60/90 日留存沒有明顯惡化。 - 客群與渠道組成沒有出現足以解釋結果的偏移。 - 定價相關客服量仍可負荷,且沒有大量「價格與價值不符」的共同原因。 若觀測量仍太少,結果應定義為「尚無定論」,延長測試或維持新客限定,不能把缺乏證據解讀為價格已獲驗證。 ## 第五階段:既有客戶 rollout 只有在新客 NT$899 已累積至少 60–90 日留存訊號後才開始: 1. 提前 60–90 天通知,說明新增價值與生效日期。 2. 提供過渡方案,例如年度方案鎖定舊價 12 個月、3 個月緩衝期或一次性抵用額。 3. 先選 6 位客戶做帳務與溝通演練;此波不作統計推論。 4. 再以使用量、任期與客群分層,隨機選 12 位進入第一個正式波次,其餘作暫時對照。 5. 觀察至少一個完整計費週期,再依序擴至 18 位、24 位,最後才處理其餘客戶。 6. 對取消、降級及抱怨者進行短訪談,區分價格造成的增量流失與原本就會發生的流失。 既有客戶成功標準: - 價格造成的額外 60/90 日流失不超過基準 5 個百分點。 - 升價後 cohort 的 MRR 與預估 12 個月毛利增加。 - 降級、退款和逾期付款沒有顯著惡化。 - 核心使用與活躍度沒有超過 10% 的相對下降。 - 每一波沒有出現一致性的信任、溝通或公平性問題。 ## 回滾條件 符合任一項即暫停擴大;已通知客戶可延後生效或提供抵用額,不溯及追收: - 新客每位合格訪客營收連續兩個 cohort 低於基準,或轉換率低於基準的 60%。 - 模型顯示 90 日毛利下降超過 10% 的機率達 80%。 - 退款率增加超過 5 個百分點,或啟用率下降超過 10 個百分點。 - 既有客戶波次的價格增量流失超過 5 個百分點。 - 發生重複計費、價格顯示不一致或未依通知執行等帳務問題。 - 訪談顯示問題不是價位本身,而是 Pro 的價值、定位或功能邊界不清楚。 回滾後應維持 NT$599,或改測 NT$699/799、重新包裝 NT$899 Pro;不要在同一批客戶間反覆升降價格。
測試紀錄

這次測試記錄了什麼?

固定不變兩邊使用相同的模型版本、帳號方案、系統指令、思考強度與測試問題。

分開測試每次回答都使用全新環境。載入前不含任何 Skill,載入後只含本頁指定的 Skill。

完整才公開三題的所有步驟與環境清理都成功後,才顯示結果。若無法確認模型是否套用 Skill,也會清楚標示。