# 副業點子怎麼驗證？從客戶訪談到第一筆付費的實作流程 副業可以做什麼，常比不上有人願意買什麼。用最近真實行為、現有替代方案與手動小交付驗證需求，分清稱讚、試用、付費和再購訊號，決定下一步要繼續、調整或停止。 來源：[好日子指南｜funs.day：副業點子怎麼驗證？從客戶訪談到第一筆付費的實作流程](https://funs.day/posts/side-project-demand-validation/) 發布日期：2026-10-12T16:00:00.000Z 更新日期：2026-10-12T16:00:00.000Z（pubDate） 語言：zh-Hant-TW 引用本文整理時，請附上上述 funs.day 文章連結；原始參考資料保留於內文。 --- ## 前言 你想到一項副業：替小店整理散落在訊息裡的訂單。朋友聽完說「這個一定有人要」，於是你開始做網站、挑付款工具、設計會員方案。忙了一個月，卻還沒問過任何店家，最近一次漏單發生在哪裡。 **驗證副業點子的第一步，是確認誰正在處理什麼麻煩，再提出一項他願意付費的具體成果。** 會做工具只是起點，對方是否願意交出資料、花時間試用、接受報價，才會逐步補上需求的證據。本文用訂單整理作為虛構示例，帶你從訪談走到小規模交付；不是市場規模估算，也不承諾收入。 --- ## 🧨 常見誤區：有抱怨，就代表有生意？ **問題：** 看見競品的一星評論，就把抱怨最多的功能列進開發清單。 **真相：** 評論能提供線索，但不知道留言者是不是你的客戶、是否仍受困，也不知道他願不願意換工具。少數負評更不能直接換算市場規模。 **建議：** 把評論變成訪談題目，找相同情境的人，追問最近實際怎麼處理。 **問題：** 問朋友「如果我做出來，你會買嗎？」大家都回答會。 **真相：** 未來意願容易混入鼓勵、禮貌與想像，不能等同購買。YC 的訪談教材提醒，應了解已發生的具體經驗，避免訪談變成推銷。 **建議：** 問「上一次發生是在什麼時候？你後來做了什麼？」並保留對方原本的說法，不把「偶爾很煩」改記成「急需解決」。 **問題：** 免費試用很多人，就認定可以開始收訂閱費。 **真相：** 免費使用說明有人願意投入時間，還沒證明付款意願；一次付款也沒證明會持續購買。 **建議：** 分開記錄試用、報價、實際付款及後續需求，讓每種訊號回答不同問題。 --- ## 🎤 訪談先問最近一次，再找現有替代 先寫出一句可被推翻的假設：「接單的小店，在月底核對訂單時，需要把多個訊息來源整理成可核對的清單。」避免只寫「所有老闆都需要提升效率」，範圍太大，訪談結果很難比較。 接著找正在做這件事的人；朋友可以介紹，但受訪者要符合情境。開場先說明你正在了解工作流程、這次不必購買，也允許對方不提供敏感資料。以下是本篇設計的問法： | 要了解什麼 | 可以怎麼問 | 記錄重點 | |---|---|---| | 最近的事件 | 最近一次核對訂單，從哪一步開始？ | 發生時間、觸發情境 | | 實際卡點 | 哪一步需要回頭重做？可以描述一次嗎？ | 具體動作、後果 | | 現有替代 | 當時用什麼方式完成？還找了誰幫忙？ | 試算表、人工、既有工具 | | 換方法的阻力 | 曾試過其他方法嗎？為什麼沒留下來？ | 學習、資料搬移、合作習慣 | | 決策與付款 | 這類服務由誰決定？目前費用怎麼處理？ | 使用者、決策者是否相同 | 如果對方只說「很耗時間」，再問時間花在哪一步；若他記不得，標記為待確認，不替他填一個數字。可以請他示範去識別化的流程，但不需要拿到完整客戶名單才能做研究。 YC 提供的原則是了解過去事件、已嘗試的解法與現有解法的不滿；上表的場景與問句是本文編輯設計。**替代方案也包含「自己加班做」或「乾脆不處理」**，不是只有同類軟體。若目前方法已經夠用，這也是重要結果，表示你需要找到更明確的使用情境。 --- ## 🛠️ 用一項手動小交付，測試成果是否值得買 訪談後不要把所有要求一次做完。選一項你能完整交付、對方能驗收的成果，例如「把一份去識別化訂單資料，整理成欄位一致並標出待確認項目的清單」。這比「幫你導入數位轉型」容易判斷有沒有用。 Paul Graham 在〈Do Things that Don't Scale〉談到，早期可以先用人工完成未來想自動化的工作，從實際操作理解該做什麼。套用到副業，重點是先看成果能否解決問題，而不是把人工服務假裝成已完成的軟體。 交付前用一頁說清楚：輸入資料格式、包含哪些工作、不包含哪些工作、完成時間、價格、驗收方式，以及需要修改時怎麼處理。原型或人工流程要明說；價格依你能負擔的成本與這次服務範圍設定，不用捏造「市場公定價」。若是免費試做，也寫明到哪裡結束，避免沒有邊界的協助。 **編輯建議：** 第一輪先限制為一種客群、一項成果與一個短期檢視日期，例如兩週。這只是控制投入的起始安排，不是驗證成功的統計門檻；對採購時間較長的服務，檢視日期應另行調整。 完成後請對方拿成果做原本的工作，觀察是否真的使用、哪裡仍須重做。不要只問「滿不滿意」。如果對方願意付費，接著確認他買的是這項成果、你的額外陪伴，還是人情支持；這會影響你能否把服務提供給下一位客戶。
副業需求驗證資訊圖：稱讚、留下聯絡、試用、付費與再購是不同訊號；透過訪談、手動小交付再決定繼續、調整或停止，付費仍不代表長期成功。
點圖可放大。訊號是編輯整理的判讀框架，並非每位客戶都依序經過各階段；付費後仍須檢查成本與持續需求。
--- ## 🚦 值得行動的情境：每個訊號決定不同下一步 圖中的五種訊號由口頭反應走向實際交換。留下聯絡代表願意再談；試用代表投入時間；付費代表接受某一次交易；再購代表在後續情境仍有需要。它們不能混成一個「喜歡的人數」，也不一定依序發生。 | 目前情境 | 可以判斷什麼 | 下一步 | |---|---|---| | 有稱讚，說不出最近事件 | 還缺少問題存在的證據 | 換問真實流程，或重新找客群 | | 描述具體卡點，願意再聯絡 | 值得深入了解，尚未驗證購買 | 約定一次小交付與所需資料 | | 願意試用，看到報價就退出 | 試用有吸引力，交易條件尚未成立 | 問退出原因，分辨價格、範圍與決策權 | | 付費完成，成果卻沒被使用 | 已有交易，使用價值仍不清楚 | 查驗收方式與實際工作流程 | | 使用後再購，但每次大量客製 | 有持續需求，交付成本可能太高 | 限制範圍，計算投入與可重用部分 | | 多次邀請都未進入下一步 | 目前接觸方式或提案證據不足 | 暫停加功能，改客群、改提案或停止 | 保留一份簡單紀錄：接觸了哪些符合條件的人、多少人看過完整提案、多少人接受報價、多少人實際付費，以及每次花多少時間交付。樣本很少時，直接寫人數與原因，比寫一個看起來精準的轉換率有用。 決定繼續時，只增加已反覆卡住的環節；決定調整時，一次換一個條件，例如客群或成果範圍，才能理解差異。若沒有人願意提供必要資料，或交付負擔超過你能接受的時間，停止也是有效的驗證結果。先用[時間管理的安排方法](https://funs.day/posts/time-management/)為試驗留出固定時段，並預先寫下最多願意投入的資源。 --- ## 💡 結論懶人包 - 抱怨與稱讚提供線索，不能代替最近的實際行為。 - 訪談要問事件、現有替代與決策方式，先聽懂再提案。 - 用可驗收的手動小交付測試價值，交代範圍、價格與限制。 - 試用、付費、再購分開記錄；第一筆交易仍不是長期成功。 - 今天先寫一個客群、一個問題、一項成果，約一次訪談即可開始。 ## 🔗 延伸閱讀 - [Email 怎麼寫才有效？](https://funs.day/posts/email-writing/)：把訪談邀約或交付確認寫得清楚，讓對方容易回覆。 - [拖延怎麼辦？](https://funs.day/posts/procrastination/)：把「做出完整副業」縮成今天能完成的一個行動。 ## 📚 參考資料 - Y Combinator〈Startup School Week 1 Recap: Kevin Hale and Eric Migicovsky〉：[官方逐字稿與訪談教材](https://www.ycombinator.com/blog/startup-school-week-1-recap-kevin-hale-and-eric-migicovsky/)。本文採用了解過去事件與現有解法的原則，未將創投成長目標套用為副業門檻。 - Paul Graham〈Do Things that Don't Scale〉：[作者原文](https://www.paulgraham.com/ds.html)。本文引用早期人工交付的思路；情境表、訊號判讀與試驗安排均為編輯建議。