AI Micro SaaS 等待名單驗證:郵箱不是需求,行動才是需求
等待名單收 500 郵箱,但開發完只有 5 人付費?因為郵箱不是需求,行動才是。本文給你 6 檔訊號強度判定 + 5 種驗證入口 + 把弱訊號升級強訊號的轉化設計。
📖 本篇術語速查表
| 英文 / 縮寫 | 中文 | 一句話解釋 |
|---|---|---|
| landing page | 落地頁 | 用一頁說明產品物件、痛點、輸出和下一步行動。 |
| waitlist | 等待名單 | 使用者留下郵箱或聯絡方式,表示願意接收後續通知。 |
| preorder | 預訂 / 預付意向 | 使用者願意提前付款或預約付費試用,是更強訊號。 |
| demo | 演示 | 用影片、截圖或可點選原型展示產品如何工作。 |
| signal | 訊號 | 使用者用行動表達需求強弱的證據。 |
| call to action | 行動按鈕 | 引導使用者留下郵箱、預約、上傳樣例或付款的入口。 |
讀完你能交付:一張《[擬做 SaaS]》驗證頁設計卡(6 檔訊號強度 + 5 種驗證入口 + 弱→強訊號升級路徑 + 漏斗轉化指標表)。 一句話錨點:500 郵箱 = 弱訊號;50 個上傳樣例 = 強訊號;5 筆預付 = 最強訊號。驗證頁要把使用者引到行動,不是引到留郵箱。
不想讀完?把下面這段提示詞丟給 AI 幫你跑完——複製提示詞,餵給 Codex / Claude Code / Cursor / DeepSeek,把變數改成你的產品想法,AI 會按本文框架輸出驗證頁結構和訊號判斷表。
# 角色:獨立軟體 SaaS 驗證頁強訊號設計顧問
你是我 SaaS 方向的驗證頁強訊號設計顧問。我會把一個想驗證的產品想法交給你,你的工作不是替我去搭網站、寫完整程式碼、跑廣告,而是幫我設計一個落地頁骨架。這個落地頁只為一個目的服務:分辨出"路過留個郵箱的好奇心"和"願意付出真實代價的真使用者"。
你只做驗證頁結構和訊號判斷設計。不替我編郵件訂閱轉化率、Stripe 抽成、Vercel 費率;不替我做"開發還是不開發"的最終拍板(你給閾值,我自己決策);不輸出"留郵箱 = 驗證成功"這種假陽性結論;不寫"AI-powered X""智慧化 Y"這種空詞 H1;不要我收集身份證、銀行卡、病歷等敏感資訊。
## 核心任務
把產品想法翻譯成一份驗證頁骨架卡:落地頁 7 段結構(H1、痛點描述、輸入輸出展示、演示樣品、3 檔 CTA、常見問題、隱私邊界);3 檔 CTA 文案各至少 1 個具體例句,且強訊號必須含"預付 / 上傳真實樣例 / 影片面談 / 介紹同類使用者"之一;訊號閾值表寫清楚"幾個強訊號、幾個中訊號、幾個弱訊號"對應"開發 / 繼續驗證 / 暫停"三檔判斷;最後給 7 天釋出加測量計劃。
**成功標準**:交付的結果必須同時滿足——3 檔 CTA 各至少 1 個具體文案;強訊號必含真實代價動作;閾值表數字明確不模糊;未編轉化率或行業基準;H1 不含"AI-powered"空詞;CTA 不要求收集敏感個人資訊。 任意一條沒滿足即視為未達標,需補料後重跑。
## 資訊輸入
設計之前先看我手裡的欄位齊不齊。
如果痛點已經驗證過(至少 3 條使用者原文證據)、預計輸入和輸出能講清、我手裡有可以展示的演示樣品或願意做手工交付、計劃釋出渠道也想清楚,這 4 件事我能填出 70% 以上,你就直接開始設計。如果痛點沒證據或者演示樣品都沒有,你先停下來進入訪談模式:一次只問我一個問題,給我 3 到 5 個選項讓我選,等我答完你複述確認再問下一個。
訪談我時你要問的就是這五件事:
1. 痛點驗證到什麼程度?(有 3 條原文 / 有訪談記錄 / 有人預付過 / 都沒有)
2. 這一版落地頁要展示的輸入是什麼?輸出是什麼?能不能給我看一份示例?
3. 你能不能提供 1 個演示影片或 1 份手工樣品,讓前 5 個上傳樣例的使用者拿到回覆?
4. 釋出渠道是哪個?(X / Reddit / IH / LinkedIn / Product Hunt / 行業社群 / SEO 長期)
5. 前 5 個上傳樣例的使用者你能多快給手工回覆?(24 小時內 / 48 小時內 / 3 到 7 天 / 沒法保證)
如果痛點沒有任何證據,直接拒絕設計,讓我先回付費痛點驗證那一步。如果沒有演示樣品和手工交付能力,強訊號 CTA 強制走"影片面談"而不是"預付"。
## 工作流程
第一步是寫 H1。一句話講清"給誰的、解決什麼具體場景"。在 `<thinking>` 標籤裡先梳理"使用者讀完這句話有沒有想立刻往下看 vs 覺得是又一個 AI 工具廣告"再下筆。禁止用"AI-powered X""智慧化 Y""下一代 Z"這種空詞。
第二步是展示輸入到輸出。要讓訪客在 30 秒內看懂:1 段示例輸入(用真實長得像資料的樣子,不是無意義佔位文本)、1 段示例輸出(具體格式:表格、列表、文件片段都行)、1 張截圖或 GIF 演示流程。
第三步是設計 3 檔訊號 CTA。在 `<thinking>` 標籤裡再梳理"什麼動作能讓使用者付出真實代價 vs 只是好奇點選"。
| 訊號檔次 | 使用者付出的代價 | 典型 CTA 形態 |
|----------|----------------|---------------|
| 弱訊號 | 幾乎為零 | 瀏覽頁面 / 留郵箱進等待名單 / 關注社媒賬號 |
| 中訊號 | 付出時間或資料 | 上傳一份真實樣例 / 預約試用 / 進私信對話 |
| 強訊號 | 付出錢、時間或社交資本 | 預付一筆小金額(可退)/ 影片面談 30 分鐘 / 介紹至少 1 位同類使用者 |
第四步是寫 3 檔 CTA 的具體文案。每檔至少給 1 個完整句子並在末尾標訊號等級,強訊號必須含"預付 / 上傳樣例 / 影片面談 / 介紹同類"之一。例如:弱訊號"留下郵箱,新版本上線時優先通知你";中訊號"上傳一份你正在頭疼的 CSV,我親手跑一遍發給你";強訊號"預付 19 美元鎖定早鳥名額,30 天內不滿意全額退款"。
第五步是寫訊號閾值表。一張三列表:訊號檔次、達到這個數量對應的判斷、可執行下一步動作。一個保守版本:強訊號 3 個以上對應"啟動 MVP 開發"、中訊號 5 個以上但強訊號為 0 對應"再做 2 周驗證補強訊號"、只剩弱訊號或強訊號為 0 對應"暫停並換人群或換問題"。
第六步是列 3 類假驗證排查清單:點贊收藏型(X 帖子很火但沒人留郵箱)、郵箱收集型(500 個郵箱但 0 個人願付一分錢)、朋友支援型(10 個朋友點了贊但沒一個目標人群)。每條配一句"為什麼這不算開發證據"。
第七步是寫 7 天釋出加測量計劃。每天 1 件可執行的事,每件不超過 1.5 小時。前 3 天聚焦釋出到具體渠道,第 4 到 6 天聚焦回覆手工諮詢和訪談強訊號使用者,第 7 天對照閾值表給三檔判斷。
**三檔判定 + 5 層訊號 + 時間窗**(頂級方法論封裝收口):
按下表交叉判定,輸出末尾必須顯式給出"判定檔 + 下一步動作 + 再評窗具體天數",否則視為不合格。
| 判定 | 觸發條件 | 下一步動作 | 再評窗 |
|------|---------|----------|-------|
| **繼續 · 綠燈** | 所有關鍵閾值過線 + 證據齊 + 5 層訊號 ≥ 第 3 層 | 進入下一階段,單批最小動作開跑 | 30 天后回本提示詞重審 |
| **微調 · 黃燈** | 1-2 項卡在邊界 / 5 層訊號停在第 2 層 | 只動 1 個變數(不併行) | 7-14 天后重跑 |
| **暫停 · 紅燈** | ≥ 2 項紅線觸發 / 證據空 / 訊號停在第 1 層 | 暫停 + 回上一階段補料 | 30 天后再來 |
**5 層訊號梯度**(用於判定停在第幾層):
| 層 | 表現 | 強度 |
|:-:|------|:-:|
| 第 1 層 | 瀏覽 / 點贊 / 收藏 / 關注 | 弱 |
| 第 2 層 | 回覆 / 提問 / 詢問能不能做 | 中 |
| 第 3 層 | 提供材料 / 給目標 / 給截止時間 | 中強 |
| 第 4 層 | 詢價 / 約通話 / 要 proposal / 要樣品 | 強 |
| 第 5 層 | 付款 / 簽約 / 平臺下單 / 轉介紹 | 最強 |
**時間窗動作日曆**(按可投入時間檔分級,單條 ≤ 1 小時):
| 時間檔 | Day 1-2 | Day 3-5 | Day 6-7 |
|:-:|---|---|---|
| < 5h/周 | 收 5-10 條原料 | 整理 1 張對照表 | 找 1 人反饋,第 7 天重打分 |
| 5-10h/周 | 收 10-30 條 + 拆 3 標杆 | 做 1 個最小樣品 | 找 3 人反饋 + 1 輪調整 |
| 10-20h/周 | 收 30-50 條 + 拆 5 標杆 | 做 3 樣品 + 1 張對比 | 跑 1 輪投放或試發 + 重打分 |
| ≥ 20h/周 | 收 50-100 條 + 拆 10 標杆 | 做 5 樣品 + 1 個 SOP | 跑 1 輪投放 + 2 輪調整 + 覆盤 |
## 示例 / 樣板
輸入是想驗證"AI 自動整理 Etsy 差評生成商品改進建議",目標使用者是 Etsy 美區數字模板賣家,痛點已有 8 條原文,能提供手工 Sheet 樣品。
期望輸出節選:
```
H1
給 Etsy 數字模板賣家:5 分鐘把上週差評變成可執行的商品改進表
3 檔 CTA 文案
- 弱訊號:“留郵箱,下週新版本試用通知你”(訊號等級:弱)
- 中訊號:“上傳一份你這周的差評 CSV,我手工整理一份建議表寄回給你”(訊號等級:中)
- 強訊號:“預付 19 美元鎖定早鳥,48 小時內手工跑通 1 單,不滿意全額退”(訊號等級:強)
訊號閾值表
- 強訊號 ≥ 3:啟動 MVP 開發(開始寫 CSV 上傳指令碼)
- 中訊號 ≥ 5 且強訊號 = 0:再做 2 周驗證(重點訪談願上傳樣例的人是不是真的會付錢)
- 只剩弱訊號或強訊號 = 0:暫停換 Shopify 賣家或換實體賣家
```
反面例子:H1 寫"AI-powered review analytics for sellers"(違反空詞禁令);強訊號寫"Join waitlist for free"並把郵箱數算開發證據(違反假陽性硬約束);編造"行業留郵箱轉化率 30%"(無源資料);強訊號 CTA 裡要求使用者上傳身份證(違反敏感資訊禁令)。
## 輸出規範
直接輸出《[產品方向]》驗證頁骨架卡正文,不要前言後語,總字數 800 到 1200 字,按以下順序:
1. 落地頁 7 段骨架:H1 / 痛點 / 輸入輸出 / 演示 / 3 檔 CTA / 常見問題 / 隱私邊界
2. 3 檔 CTA 文案表:文案 / 訊號等級 / 使用者付出的真實代價
3. 訊號閾值表:強 / 中 / 弱各幾個對應開發 / 驗證 / 暫停三檔判斷
4. 3 類假驗證排查清單:點贊收藏型 / 郵箱收集型 / 朋友支援型
5. 7 天釋出加測量計劃:每天 1 件可執行的事 + 時長
6. 三檔判斷模板:第 7 天對照閾值表給開發 / 繼續驗證 / 暫停結論
輸出前自檢:3 檔 CTA 各至少 1 個具體文案;強訊號必含真實代價動作;閾值表數字明確不模糊;未編轉化率或行業基準;H1 不含"AI-powered"空詞;CTA 不要求收集敏感個人資訊。
## 硬約束 · 拒絕場景
遇到下面這些情況直接拒絕設計,告訴我先回去補哪一項:
- 痛點沒有任何證據回付費痛點驗證先評分
- 要求"留郵箱 100 個就啟動開發""ARR 預估"拒絕(假陽性 / 無源資料)
- CTA 要求收集身份證、銀行卡、病歷等敏感資訊一律拒絕
- 要求"H1 用 AI-powered / 智慧化 / 下一代"拒絕並解釋空詞為什麼勸退真使用者
- 欄位全空或仍是 `___` 佔位符沒替換拒絕先給結論
驗證頁要證明的不是“有沒有人點進來”,而是“有沒有目標使用者願意進一步行動”。
| 行動 | 訊號強度 |
|---|---|
| 瀏覽頁面 | 弱 |
| 點贊、收藏、轉發 | 弱 |
| 留郵箱 | 中弱 |
| 預約試用 | 中強 |
| 提供樣例資料 | 強 |
| 預付、簽約或介紹同類使用者 | 很強 |
AI Micro SaaS 的早期頁面,不要只追求好看。它要讓使用者快速看懂:這是什麼、幫誰、處理什麼輸入、輸出什麼結果、下一步要做什麼。
新手最常停在 B(500 郵箱)就以為成立。真要進 MVP 需要至少 ≥ D 訊號(≥ 10 人願提供真實樣例資料)。詳見 MVP 單迴路 設計驗證強訊號的具體動作。
為什麼等待名單不是最終證據
等待名單很容易給人進展感。你發一個頁面,很多人留下郵箱,你會覺得需求成立。但留下郵箱成本很低,和真實使用、付費、上傳資料不是一回事。
裡的煙霧測試思路適合這裡:用頁面或演示測試關鍵假設。但測試必須有明確判斷標準。如果只是收集郵箱,沒有後續動作,就只能說明標題或概念有吸引力。
強調快速釋出、和使用者一起做。這個思路對獨立開發者很實用,但“釋出”不是把頁面丟出去等奇蹟,而是把頁面當成對話入口,繼續收集真實行為。
提醒持續展示過程可以建立關係。對 Micro SaaS 來說,公開驗證過程有價值,但不能用圍觀熱度替代產品需求。
驗證入口的 5 種形式
不同階段用不同入口:
| 入口 | 適合驗證什麼 |
|---|---|
| 落地頁 | 使用者是否理解痛點和輸出 |
| 等待名單 | 是否願意接收後續通知 |
| 演示影片 | 是否理解流程和結果 |
| 預約試用 | 是否願意投入時間 |
| 預付 / 付費試點 | 是否有購買意願和預算路徑 |
不要一開始就追求複雜頁面。早期可以是一頁說明、一個演示截圖、一個預約按鈕和一個隱私說明。
如果你的產品需要使用者上傳資料,單純郵箱不夠。你至少要驗證使用者是否願意提供一份脫敏樣例。
第 1 步:寫清誰和什麼痛點
頁面第一屏只回答三件事:
| 問題 | 示例 |
|---|---|
| 給誰 | 給每週要整理電商評論的營運 |
| 解決什麼 | 把評論裡反覆出現的問題歸類 |
| 得到什麼 | 一份可給產品和客服看的問題報告 |
不要寫“AI 驅動的智慧增長平臺”。這類話很大,但客戶不知道自己是否該繼續看。
更好的寫法:
把一份商品評論 CSV 變成高頻問題、情緒標籤和改進建議,適合每週要給產品和客服做反饋的電商營運。這句話同時說明了使用者、輸入、處理和輸出。
第 2 步:展示輸入和輸出
AI 工具最需要展示輸入和輸出。使用者要知道自己需要給你什麼,也要知道能拿到什麼。
| 模組 | 寫什麼 |
|---|---|
| 輸入 | CSV、連結、文本、截圖、表單、對話記錄 |
| 處理 | 清洗、分類、總結、標註、生成、檢查 |
| 輸出 | 報告、表格、建議、標籤、待辦、提醒 |
| 邊界 | 不處理敏感資訊、不承諾平臺結果、不替代人工稽核 |
| 樣例 | 放脫敏示例,不放客戶真實隱私 |
如果使用者看完頁面仍不知道要上傳什麼,說明頁面太抽象;如果使用者不知道結果長什麼樣,說明你還沒把價值具象化。
第 3 步:設定行動門檻
行動門檻決定訊號質量。
| CTA | 訊號 |
|---|---|
| 訂閱更新 | 中弱 |
| 預約 15 分鐘試用 | 中強 |
| 上傳一份脫敏樣例 | 強 |
| 加入付費試點 | 很強 |
| 介紹一個同類使用者 | 強 |
頁面可以有一個主 CTA 和一個次 CTA。不要放太多按鈕。
例如:
主按鈕:上傳一份脫敏樣例,獲取一次手工分析結果
次按鈕:沒有樣例?預約 15 分鐘聊聊你的流程這比“加入等待名單”更接近真實使用。
第 4 步:區分弱、中、強訊號
驗證後要分層,不要混在一起。
| 訊號層級 | 例子 | 下一步 |
|---|---|---|
| 弱 | 頁面訪問、點贊、收藏 | 只記錄來源 |
| 中 | 留郵箱、回覆感興趣 | 繼續追問場景 |
| 中強 | 預約試用、回覆流程細節 | 做手工交付 |
| 強 | 提供樣例資料、介紹同類使用者 | 跑 MVP 閉環 |
| 很強 | 預付、籤試點、願意長期使用 | 進入產品化 |
如果只有弱訊號,不要馬上開發。先改頁面表達、換渠道、收窄使用者,或回到訪談。
如果有強訊號,但人數少,也不必急著做複雜產品。先用手工或半自動流程交付,確認結果是否可重複。
第 5 步:決定是否開發
驗證頁跑完後,做三選一:
| 結果 | 動作 |
|---|---|
| 多個目標使用者願意上傳樣例 | 做手工 MVP |
| 有預約但沒有樣例 | 繼續訪談,降低輸入風險 |
| 只有郵箱和點贊 | 改定位或渠道 |
| 使用者看不懂頁面 | 重寫第一屏和樣例 |
| 使用者願意付費試點 | 設計最小交付和付款路徑 |
不要把頁面當成一次性發布。它是一個實驗。每一輪只改一個變數:人群、標題、樣例、CTA 或渠道。一次改太多,你不知道是什麼影響了結果。
更穩的做法是給每一輪驗證留一張覆盤表:
| 記錄項 | 怎麼寫 |
|---|---|
| 流量來源 | 從哪裡來,不混算不同渠道 |
| 使用者身份 | 是否真是目標使用者,不是泛泛圍觀者 |
| 看到的承諾 | 使用者看到的是痛點、樣例、價格還是試點說明 |
| 做出的動作 | 留郵箱、預約、上傳樣例、回覆場景、預付 |
| 卡住的位置 | 不懂頁面、不敢上傳、不願付費、沒有預算 |
| 下一輪變數 | 只改一個地方,比如標題、樣例、CTA 或渠道 |
這張表能幫你避免兩個常見誤判。第一個誤判是“頁面沒人填,所以產品不行”。也可能只是渠道錯了,來的不是目標使用者;也可能是第一屏太抽象,使用者沒看懂你到底處理什麼。第二個誤判是“很多人留郵箱,所以可以開發”。如果這些人沒有具體場景、沒有樣例、沒有時間投入,訊號仍然偏弱。
開發前至少要回答一個具體問題:我接下來做的功能,能不能讓已經行動過的使用者更快拿到同一個結果?如果答案是不能,說明你可能是在做“看起來完整”的功能,而不是在服務真實需求。Micro SaaS 最容易浪費時間的地方,不是程式碼寫不出來,而是把還沒驗證過的流程過早產品化。
驗證頁評分表
釋出前打分:
| 維度 | 分值 | 判斷問題 |
|---|---|---|
| 使用者清楚 | 20 | 第一屏是否寫清給誰 |
| 痛點具體 | 20 | 是否有近期真實場景 |
| 輸入明確 | 20 | 使用者知道要提供什麼 |
| 輸出可見 | 20 | 使用者知道能拿到什麼 |
| 行動有門檻 | 20 | CTA 是否能產生中強以上訊號 |
80 分以上可以釋出;60-79 分先補樣例和 CTA;60 分以下回到訪談。
驗證頁不是文案比賽。它要讓目標使用者做一個真實動作。
評分後再做一次新手自檢:
| 自檢問題 | 不合格表現 | 修正方式 |
|---|---|---|
| 使用者是否一眼知道自己是不是目標人群 | 第一屏只寫“團隊”“企業”“創作者” | 改成具體崗位、任務或場景 |
| 痛點是否來自真實流程 | 只寫效率、增長、自動化 | 寫清原來怎麼做、哪裡費時間、誰負責 |
| 樣例是否能讓人想象結果 | 只有概念,沒有截圖或文本樣例 | 放一份脫敏輸入和一份輸出片段 |
| CTA 是否太輕 | 只有訂閱郵箱 | 增加預約、上傳樣例或試點申請 |
| CTA 是否太重 | 沒有信任基礎就要求付款 | 先給手工樣例、演示或清楚退款說明 |
如果你是第一次做 Micro SaaS,不要把“頁面專業”當成目標。真正要專業的是判斷邏輯:每一個模組都服務一個假設,每一個按鈕都對應一個行動,每一輪修改都能解釋為什麼改。這樣即使驗證失敗,也能知道是人群錯、痛點錯、表達錯,還是交付方式錯。
三種假驗證
第一種:只看訪問量。
訪問量可能來自好奇、標題黨或錯誤渠道。沒有後續行動,不能證明需求。
第二種:只收郵箱。
郵箱是低成本訊號。可以保留,但不要當成開發依據。至少要繼續追問使用場景。
第三種:只問社群意見。
社群回覆很容易熱鬧,但真正使用的人可能很少。把公開討論當線索,不要當結論。
AI 怎麼輔助
AI 可以幫你寫驗證頁,但不能替你判斷市場。
適合交給 AI 的任務:
- 把訪談原話改成第一屏文案。
- 設計輸入、處理、輸出說明。
- 生成 CTA 選項並標註訊號強弱。
- 檢查頁面是否太抽象。
- 整理驗證結果和下一輪變數。
不適合交給 AI 的任務:
- 編造等待名單人數。
- 假設高訪問就代表需求成立。
- 替你確認支付、郵件、隱私和 Cookie 合規。
- 把弱訊號包裝成強訊號。
AI 適合做頁面編輯,不適合替代真實行動資料。
實際用 AI 時,建議讓它做三輪檢查。第一輪檢查“是否過度抽象”:把頁面裡所有大詞圈出來,改成使用者日常會說的話。第二輪檢查“訊號是否分層”:把訪問、郵箱、預約、樣例、預付分開,不讓它們混成一個成功指標。第三輪檢查“下一步是否可執行”:如果使用者今天點選按鈕,你明天能不能手工給出一次結果;如果不能,說明驗證頁承諾和目前能力不匹配。
還要讓 AI 保留不確定性。不要讓它給你編一個看似漂亮的轉化結論,也不要讓它用行業平均數替代你的真實資料。早期驗證最有價值的材料通常不是漂亮數字,而是幾句具體反饋:使用者為什麼不上傳、為什麼不預約、為什麼擔心資料、為什麼覺得現在的方法已經夠用。這些反饋會直接決定下一篇要不要繼續做 MVP 範圍,還是回到痛點和訪談。
官方資料與核驗口徑
平臺規則、演算法動向、報價規則、政策口徑都會變化。本文保留的是可遷移的判斷框架,具體數字一律給區間。
跨平臺核驗入口:
- Indie Hackers — 看 Micro SaaS 真實營收、留存與覆盤
- Stripe Atlas Guides — 看 SaaS 收款、跨境結算與合同模板
- microconf — 看 bootstrap SaaS 報告、增長與定價案例
涉及具體資料、比例、報價區間的部分,以執行當天后臺為準。
常見問題
500 郵箱裡沒人預約試用,是頁面問題還是需求問題?
3 步排查:1)發"願不願 30 分鐘通話討論"郵件 → 收 50 郵箱中有 0 回覆 = 需求弱;收 5+ 回覆 = 頁面 CTA 不夠強;2)改 CTA 從"留郵箱"到"預約 30 分鐘試用"再測一週;3)依然 0 行動 → 不是頁面,是這群人不是真目標使用者。
沒產品能不能收預付?怎麼寫合規?
能。3 件事寫清:1)交付時間視窗("預付後 30 天內交付 V1,到期沒交付全額退款");2)退款條款(什麼情況退、幾天內);3)風險宣告("這是早期產品,可能不完整")。按執行當天 Stripe / Lemon Squeezy 規則處理跨境合規。預付獲得的強訊號 > 100 郵箱。
頁面寫價格會不會嚇跑使用者?
恰恰相反。不寫價格 = 留郵箱的人很多但都不是真買家;寫價格區間("$29/月起")= 留郵箱的人少但都是認真考慮的。新手驗證早期:寫價格區間,過濾白嫖使用者。
驗證頁第一屏要不要塞 demo 影片?
看使用者型別。技術使用者喜歡"線上試 demo"(不需要影片);非技術使用者需要 30 秒影片解釋"輸入→輸出"長什麼樣。判斷:你的目標使用者在看到截圖後還是不能理解 → 必須加 30s 影片;理解了 → 不需要。影片不是裝飾,是降低判斷成本。
執行前至少核驗:
- Carrd · Landing Pages → 最小著陸頁搭建
- Framer / Webflow · Landing Templates → 落地頁模板
- Plausible · Goals → 等待名單轉化漏斗