如何設計一個企業真的願意推的 PoC？

先講結論

好的 PoC 要有明確的企業內推動者、場域、指標、時程與下一步。

直接回答

好的 PoC 要有明確的企業內推動者、場域、指標、時程與下一步。

企業說「很有興趣」時，新創最容易太快開心。真正要追問的是：誰要推、在哪裡測、用什麼指標判斷成功、成功後誰能讓它往採購或投資走。

為什麼這個問題重要

一個沒有下一步的 PoC，很可能只是免費顧問案。

企業窗口可能真的欣賞團隊，但欣賞不等於預算、場域、採購、資安放行或高層支持。PoC 如果沒有設計好，會消耗新創大量時間，最後卻留下很難對投資人說明的成果。

檢查清單

設計 PoC 前，團隊可先確認：

企業內推動者
場域與資料權限
PoC 成果指標
採購或投資下一步
法務、資安、採購誰會卡關

如果企業窗口答不出這些問題，不一定代表不能合作，但代表現在還不是一個成熟 PoC。

如何使用這份檢查表

這份檢查表的目的，不是讓團隊顯得很會管理專案，而是避免團隊把三個月的時間投入一個沒有企業內部主人、沒有驗收標準、也沒有下一步的合作。

判斷表

判斷點	需問的問題	如果答案不清楚
企業內推動者	誰有動機、權限與時間推動	先不要承諾免費投入
場域與資料	能否拿到真實使用情境或資料	改成較小型驗證
成果指標	成功與失敗如何判斷	先共同定義驗收標準
後續路徑	成功後是採購、擴大導入或投資	先釐清企業內部流程
風險關卡	法務、資安、採購何時介入	提早拉進時程，不要最後才處理

情境範例

一個常見情境是：業務單位很想試，創新部門也願意介紹，但 IT 資安沒有排時程、法務不知道資料怎麼處理、採購也還沒進來。三個月後，新創做了很多 demo，企業內部卻沒有人能把案子往下推。這不是單純溝通問題，而是 PoC 一開始就沒有被設計成可導入的專案。

常見誤解

常見誤解是：企業願意開會，就代表合作快成了。真正有價值的不是會議次數，而是企業願不願意投入場域、資料、決策者和下一步承諾。

下一步建議

在答應 PoC 前，先寫一頁 PoC brief：企業內推動者、測試場域、成果指標、時程、法務資安採購關卡、成功後下一步。若團隊正在找企業合作，可以先用這份 brief 跟台大創創中心討論適合的場域與合作設計。

台大創創中心實務觀察

PoC 的設計品質，會直接影響企業合作是否能轉成可用證據。許多合作一開始都以「企業有興趣」啟動，但若沒有企業內部推動者、預算、資料權限與成功後路徑，最後很容易停在展示或試用。

一個企業真的願意推的 PoC，通常需要同時滿足業務價值與內部可行性。業務價值回答為什麼值得做，內部可行性回答誰來推、誰會卡、如何驗收，以及成功後是否能採購或擴大。

對新創而言，PoC 不是免費服務的代名詞，而是一個應該被設計的商業驗證。若 PoC 無法支撐募資、產品迭代、採購或策略合作，就需要重新評估投入範圍。

台大創創中心觀點

企業合作的價值不只在於大企業名稱，而在於合作是否能形成可複製的市場證據。若合作只是一次客製案，對募資、產品與成長的幫助可能有限，甚至會稀釋團隊資源。

一個能支撐成長的企業合作，通常至少要有四個元素：企業內部推動者、明確場域或資料、可量化成果指標、以及成功後的下一步。缺少其中任何一項，合作都可能停在會議和展示。

新創需要特別留意合作是否帶來隱性成本，例如過度客製、排他條款、資料使用限制、導入週期過長，或因單一企業需求而偏離原本產品方向。

匿名情境

一個匿名團隊被企業邀請做 PoC，初期只和創新窗口對接，三個月後才發現資安、法務、採購與業務 owner 都沒有排入時程。第二次設計時，團隊先確認 sponsor、場域、資料、驗收指標與成功後路徑，才開始投入開發。

反例

反例是把企業興趣當成客戶承諾。沒有內部主人、預算與導入流程的 PoC，即使 demo 成功，也可能只留下無法複製的客製工作。

好壞對照

較好的寫法 / 做法	不足的寫法 / 做法
PoC 前先定義 sponsor、資料權限、驗收指標、採購或擴大導入路徑。	先做 demo，再期待企業內部自然找到預算與流程。

參考來源與延伸閱讀

FAQ