概念地圖・反向試用模式
作者 山姆（謝冠生）・喵喵書評創辦人
發布
分類：創業
這一頁不只是把一個概念解釋一遍——一張自己畫的結構圖，加上拿台灣情境從頭走一次的實例演練、這個框架什麼時候會騙你，以及它接回 P.A.I.N. 之後長什麼樣。一頁必須交付的三層 →
反向試用模式：倒數之後的免費價值
控制面板的試用倒數只剩一天。滴灌設備商的客戶已看過跨田區報表，開始問免費方案會保留哪些紀錄，原有的澆灌排程還能不能用。反向試用先讓新帳號接觸付費功能，期限到後分成付費延續與免費方案兩條路——產品必須先定義退回哪裡，再談升級誘因。一次試用能否留下價值，取決於使用者在期限內完成了什麼工作。
先試用、再分流，免費方案留在哪裡
Elena Verna 在 Amplitude 的反向試用解說指出，新使用者先試付費功能，到期回到免費方案，之後仍能按需要升級。把這個順序落到產品上，每一站都有一個要交付的東西。
| 路徑 | 使用者得到什麼 | 產品要交代什麼 |
|---|---|---|
| 註冊 → 全功能試用 | 有期限地接觸付費能力 | 試用何時開始、功能範圍與期限 |
| 試用 → 付費延續 | 延續需要的進階工作 | 收費內容、價格及確認方式 |
| 試用 → 免費方案 | 繼續完成基本工作 | 撤回哪些功能，紀錄如何保留與匯出 |
| 免費 → 日後升級 | 需求增加時恢復進階能力 | 升級後能接續哪些既有工作 |
免費方案需要獨立成立。若使用者到期只剩登入畫面，日後回來的理由就很薄——先做出可持續使用的基本工作，再決定哪些擴充能力值得收費。上圖只整理路徑，沒有宣稱各分流的人數，也沒有預測營收。
設計降級路徑時，四個交代要說清楚
一、期限要容得下一次價值發生。滴灌報表要先有紀錄，再能比對田區差異。帳號建好當天就啟動倒數，可能把設備接線、感測器校正與資料匯入全部算進試用天數。先追一位新客戶，從第一筆可用資料到完成一份比較花多久，再按不同使用條件安排期限——等待資料的日子，也在消耗他的耐心。自問：使用者需要多久，才能完成一次有價值的核心工作？
二、基本工作要能自己走完。滴灌服務可以把單一田區的基本紀錄留在免費版，讓客戶查到昨天灌了多久、今天是否按排程完成。跨田區比較與彙整報表再放進付費範圍。產品團隊應實際切換成免費帳號，從查紀錄走到完成例行確認——每一步都能走通，免費方案才有完整用途。自問：退回免費方案後，使用者還能獨立完成哪一項工作？
三、把資料與功能分開交代。進階分析到期，會牽涉既有比較表能否讀取、新報表能否產生、原始紀錄存多久，以及匯出入口在哪裡。這些要在開始試用與期限前說清楚，提供能操作的說明。案例中的原有滴灌排程與基本控制持續可用，試用撤回只涉及進階報表——水流的承諾必須守住。自問：到期變更、資料保留及匯出方式，是否已事前清楚揭露？
四、把時間拉長，也把成本放進來。管理一個田區與管理多個田區，可能有不同的升級需要。分群看試用中是否完成比較、到期是否留下、何時開始付費，再記下資料整理與客服協助的工時。觀察窗口要一致，流量來源也要交代——先讓比較站得住，才知道這種安排值不值得維持。自問：各類使用者的留存、付費與服務成本，放在同一段時間看會如何？
滴灌報表服務的試用期，走一遍
底下這家台灣中部的滴灌設備商，是為了把這個結構講清楚而編出來的示意情境，沒有指涉任何真實公司。接著開場那位客戶往下看：這項假想報表服務提供 14 天進階分析試用，天數是案例設定，實際產品要依完成價值的週期決定。
- 先完成一次比較：客戶把兩個田區的有效灌溉紀錄放到同一張報表，核對時間與用水紀錄，帶著結果討論下一輪排程。資料不足時，服務先協助確認缺漏，並記錄卡在哪一步。他拿到一份可以討論的成果——付費功能開始有了用途。
- 到期前預覽留下的內容：通知清楚列出單一田區基本紀錄與既有設備控制持續保留，跨田區比較與彙整報表到期停止新增。既有進階報表的可讀期限、匯出格式與操作入口在試用開始時已揭露，通知再帶他走一次。手上能留下什麼，點開就看得到。
- 未付費者接回基本工作：客戶選擇免費方案後，仍能查單一田區紀錄、使用原有澆灌排程。付費提示出現在他要新增跨田區比較時，說明需要的方案與費用。任何試用撤回都不可停止基本灌溉控制——這是本案例的產品承諾。
- 日後升級另記一條帳：客戶後來增加管理田區，重新需要彙整報表，才決定付費。團隊記下從到期到升級的時間，也把期間協助整理資料、處理匯出的工時算進來。後續收入與照顧成本，一起回到同一群客戶身上。
這段路徑最需要測試的接縫，是客戶按下「繼續免費使用」之後的第一個工作日。他照樣要確認設備運作，照樣得調出單一田區紀錄；進階能力撤回之後，基本工作仍應順利完成。團隊可以先用測試帳號重走一次，再找剛到期的客戶觀察操作。把中斷、困惑與協助工時記下來，才能決定要改功能邊界、通知內容，或試用起算方式。14 天只是一個待驗證的安排，後續升級也仍需持續觀察。以上為說明結構用的示意情境，僅供理解框架之用。
反向試用模式，什麼時候會騙你
- 核心工作還沒開始，倒數已經跑完。設備安裝與資料校正可能占掉試用的大半時間，客戶只看過一張空白報表。這時寄更多到期提醒，只會提醒他還有一件事沒弄好——先拆開等待與使用的時間，確認第一次比較是否真的完成。期限長短應隨價值發生的條件調整，固定天數只是方便管理的起點。
- 免費邊界全靠讓人難受。撤去查詢入口、藏起匯出按鈕，或把既有排程綁上付費提醒，都會破壞客戶的日常工作。尤其滴灌控制牽動田間運作，這個案例已承諾持續保留——不能拿來製造報表服務的升級壓力。付費項目要有清楚的新增用途，免費項目也要有可完成的結果。
- 第一批付款掩蓋了長期照顧成本。業務替客戶代做報表，客服反覆解釋匯出規則，都可能換來一筆短期訂閱。若只報到期當天的轉換率，那些工時與後續流失就散在別處——把同一群人往後追，連同退款、停用、回流付費與支援工時一起看。這種模式是否划算，要靠產品自己的資料回答。
用痛點的眼光看倒數結束那一刻
倒數歸零，免費方案才正式接受考試。
《痛點》的 P.A.I.N. 提醒產品團隊回到那個正在做事的人。對滴灌客戶而言，報表的價值可能是把田區差異講給共同管理者聽，也可能是少花一個晚上抄寫紀錄。這張圖畫得出帳號的分流，畫不出使用者當下最擔心失去的工作。那份擔心會藏在「我昨天的資料還在嗎」或「明早還會澆水嗎」這些問題裡。產品把答案藏得愈深，客戶就愈難安心留下——即使頁面上寫著免費。今晚找一個已到期的測試帳號，從手機登入，把查紀錄、確認排程與匯出各做一遍，再將操作錄影交給一位熟悉田間工作的人，請他指出哪一步需要停下來猜。
常見問題
反向試用一定要設成 14 天嗎？
天數由產品的價值週期決定。本文的 14 天是滴灌報表案例的假設；若有效資料要累積更久，就要重新安排起算點與期限。可以先觀察新客戶何時完成第一次有用的比較，並分開設備已就緒與仍在設定的帳號——先理解需要多久，再測試期限對留存、付款及支援成本的影響。
試用到期後，使用者的資料要怎麼處理？
把功能權限、原始資料、既有成果與匯出方式逐項定義，並在使用者投入工作以前說清楚。本文案例保留單一田區基本紀錄與既有滴灌控制，進階報表另外揭露到期規則。實際服務還需設定保存範圍與期限，提供好找的匯出入口——客戶應能預先安排工作，不必等通知跳出才開始猜。
反向試用會比一般免費方案更容易讓人付費嗎？
它增加了新使用者接觸付費能力的機會，結果仍取決於功能是否切中需求、期限是否足夠，以及免費版是否值得留下。比較時應固定觀察窗口，分群追蹤註冊、核心工作完成、留存、到期付款與日後升級，並加入支援成本——這些資料能幫團隊判斷自己的產品，單看短期轉換率很容易漏掉代價。
基礎方案留下多少可用價值，會繼續影響日後的升級動機。接著用免費增值轉換檢查付費邊界，再用免費方案與限時試用的取捨比較入口安排；把今天準備寄出的到期通知打開，讓保留項目與操作入口出現在客戶最先看見的地方。
喜歡這篇文章嗎？
每週幫你拆二本好書，把判斷力、好書金句、好問題，直送你的信箱。
不適合你可隨時退訂 · 每週兩封，陪你把書讀進生活。
送出即表示同意我們依隱私權政策使用你的 email。