跟企業合作前，創辦人要確認的 7 件事
跟企業合作前，新創要確認問題、owner、PoC 範圍、資料權限、採購路徑、資源消耗與募資影響。 適合創辦人用於會議準備、資料修正與下一步判斷。
先講結論
跟企業合作前，創辦人不應只問對方有沒有興趣，而要確認這個合作是否能產生明確證據。企業合作可能帶來場域、客戶、收入與信任，也可能變成長期客製和免費顧問。
準備度的核心是七件事：問題是否明確、企業 owner 是否存在、PoC 範圍是否可控、資料權限是否清楚、採購路徑是否可見、團隊資源是否足夠、是否有助於募資或成長敘事。
直接回答
新創適合跟企業合作前，至少要能回答：合作要解決什麼問題、成功指標是什麼、誰負責推進、需要多少資源、資料怎麼處理、成功後是否能採購或擴大。答不出來時，應先把合作降成探索，不要直接承諾 PoC。
主要判斷與使用方法
為什麼這個問題重要
企業合作若不能留下可複製證據，可能只是一個辛苦的專案，不一定會幫助募資或成長。
工具型文章的價值，不是多給一張表，而是讓創辦人知道現在該先整理什麼、哪些可以晚點補、哪些如果缺了會直接影響下一次會議。
檢查清單
正式行動前，團隊可先檢查：
- 企業內推動者
- 場域與資料權限
- PoC 成果指標
- 採購或投資下一步
如果其中兩項以上還答不出來，通常代表現在不適合急著進入下一階段。比較好的做法，是先把缺口整理成一頁問題清單，再找業師、投資人或企業窗口確認優先順序。
如何使用這份檢查表
不要把檢查表當成形式文件。它的用途是幫團隊判斷「現在缺的是資料、證據、決策者，還是題目本身」。能清楚指出缺口，比勉強寫出一份看似完整的文件更有價值。
最低可行版本
最小合作準備包括：一頁合作摘要、PoC 範圍、成功指標、雙方 owner、資料與權限邊界、預計時程、會後下一步。
企業會怎麼看
企業會評估風險、導入成本、內部資源與是否符合部門目標。創辦人若只談技術，不談導入與維運，合作容易卡住。
會議上可以怎麼問
- 企業內部誰會負責這個題目？
- 成功指標是技術可行、使用成效，還是採購準備？
- 若 PoC 成功，下一步是什麼流程？
判斷表
| 判斷點 | 需問的問題 | 建議下一步 |
|---|---|---|
| 合作目標是否明確 | PoC、採購、投資或併購前探索是哪一種 | 先定義合作類型 |
| 企業內推動者是否存在 | 誰有預算、權限與動機推動 | 確認 sponsor 與內部流程 |
| 成果能否轉成證據 | 合作是否能證明可複製性或商業價值 | 設計可量化成果指標 |
實務判斷
情境範例
新創常遇到企業窗口說「很有興趣」，但三個月後沒有預算、沒有場域、沒有採購，也沒有下一次會議。這通常不是對方不喜歡，而是一開始沒有定義合作類型和企業內推動者。 這也是「企業合作若不能留下可複製證據，可能只是一個辛苦的專案，不一定會幫助募資或成長。」在實務現場會反覆出現的原因。
若合作牽涉 AI、資料或企業流程，更要先確認合作目標。企業可能想看技術可行性，業務單位可能想看轉換率，資訊部門可能在意資料治理，法務則會在意資料使用與責任分界。創辦人若只聽到「我們想試試看」就投入客製開發，很容易在不同部門期待不一致時被拖住。
常見誤解
常見誤解是：大企業有興趣就等於合作成立。真正要看的是企業內部有沒有人、預算、場域和下一步。
下一步建議
下一步先寫一頁合作判斷表：企業是要 PoC、採購、策略合作，還是投資前探索？如果這一點不清楚，先不要急著投入大量人力。
操作方法
操作補充
企業合作的價值不只在於大企業名稱，而在於合作是否能形成可複製的市場證據。若合作只是一次客製案，對募資、產品與成長的幫助可能有限，甚至會稀釋團隊資源。
這份檢查框架的重點，是讓團隊能立即整理資料或修正會議準備。表格與清單不應只是形式文件，而應用來確認目前有哪些資訊已經可以被外部查核，哪些仍只是內部假設。
使用時的判斷順序
第一，先確認使用情境：是會前準備、會後補件、內部討論，還是對外投遞。第二，確認資料是否足以支撐本文中的核心判斷。第三，把尚未完成的項目排成優先順序，避免一次補太多低影響資料，卻漏掉真正會影響決策的證據。
新創需要特別留意合作是否帶來隱性成本，例如過度客製、排他條款、資料使用限制、導入週期過長，或因單一企業需求而偏離原本產品方向。
可補強的具體材料
正式使用這份框架時，可優先補三類材料。第一類是可匿名化的實務情境，例如一場投資人會議、一個資料室缺口、一個 PoC 設計問題。第二類是可複用的檢查項目，例如會前需要確認的資料、會後需要追蹤的問題、或決策前需要補齊的證據。第三類是相鄰主題入口，讓團隊能從概念判斷移動到具體操作。
若只列清單但缺少情境，容易變成一般模板；若只有情境但缺少檢查表，又不利於帶回實務使用。好的工具型內容應同時回答三件事：什麼情境下使用、怎麼判斷是否完成、完成後會影響哪個決策。
因此，結尾應回到一個明確輸出：一份資料、一個會議決定、一個風險判斷，或一個下一步追蹤項目。這能避免文章停在「知道」，而是推進到「可以拿去開會或修資料」。
情境與對照
匿名情境
一個匿名團隊被企業邀請做 PoC，初期只和創新窗口對接，三個月後才發現資安、法務、採購與業務 owner 都沒有排入時程。第二次設計時，團隊先確認 sponsor、場域、資料、驗收指標與成功後路徑，才開始投入開發。
一個匿名 SaaS 團隊在企業合作前先問了七件事：這次是採購、投資前探索還是共同開發；誰負責內部推動；資料從哪裡來；成功指標是成本、收入、效率還是風險降低；法務資安何時介入；是否有付費或擴大導入路徑；以及合作結果能否成為下一輪募資證據。
反例
反例是把企業興趣當成客戶承諾。沒有內部主人、預算與導入流程的 PoC，即使 demo 成功，也可能只留下無法複製的客製工作。
好壞對照
| 較好的寫法 / 做法 | 不足的寫法 / 做法 |
|---|---|
| PoC 前先定義 sponsor、資料權限、驗收指標、採購或擴大導入路徑。 | 先做 demo，再期待企業內部自然找到預算與流程。 |
參考來源與延伸閱讀
FAQ
企業說有興趣就可以開始 PoC 嗎？
不建議。應先確認問題、owner、範圍、成功指標和下一步，避免變成免費探索。
新創最容易低估什麼？
最容易低估企業內部協調、資安、法務、採購和資料權限所需時間。
PoC 要不要收費？
視情況而定，但至少要界定範圍與資源投入。免費 PoC 也應有明確目標與期限。
企業合作會影響募資嗎？
會。若能形成可查核 traction 是加分；若消耗大量客製資源且無採購路徑，可能扣分。