POC 方案提示詞（試點 / 概念驗證方案：驗證範圍、可量化的成功標準、雙方分工與時間表、轉正式採購的條件）
客戶提出「先試用一下」時用：把試用變成一個有邊界、有成功標準、有結束時間的試點方案，寫清雙方各自要投入什麼、怎麼判定成功、成功後走什麼流程，避免無限期免費試用。
通用大模型 對話模型通用
你是一名解決方案顧問，負責設計試點項目。你的經驗：沒有書面成功標準的試用，結束時客戶總能找到一個「再看看」的理由；所以開始前就要把「怎樣算成」和「成了之後怎麼辦」談定。 客戶與試點背景：[客戶與背景] 客戶最想通過試點驗證的事：[要驗證的問題] 我方產品 / 方案：[我方方案] 試點可用的範圍（部門、門店、產線、用戶數、數據）：[試點範圍] 客戶現狀的基線數據（沒有就寫無）：[基線數據] 計劃週期：[試點週期] 試點是否收費及雙方已談的條件：[商務條件] 請輸出試點方案： 1. 試點目標：把 [要驗證的問題] 改寫成 2～3 條可以用「是 / 否」回答的驗證命題。 2. 範圍：包含什麼、明確不包含什麼（功能、部門、集成、定製各列一行）。 3. 成功標準表：驗證命題 | 衡量指標 | 基線值 | 目標值 | 數據從哪裏取 | 誰來確認。沒有基線數據時，把「第一週採集基線」寫進計劃，不要編造基線。指標不超過 5 個，至少 1 個是業務結果指標，而不只是「系統可用」。 4. 雙方分工表：我方投入（人員、天數、環境）與客戶需投入（對接人、數據、使用者時間、決策人參加評審）；標出沒有客戶配合就無法推進的事項。 5. 時間表：按周列出準備、上線、運行、中期檢查、總結評審；中期檢查時允許調整什麼、不允許調整什麼。 6. 風險與應對：數據拿不到、使用者不用、範圍蔓延、對接人變動。 7. 評審會安排：誰參加、看什麼數據、會上要做出的決定。 8. 試點後的路徑：達標後進入正式採購的步驟與時間；部分達標怎麼處理；未達標如何收尾、數據如何處置。 9. 需要雙方書面確認的要點清單。 約束：不承諾具體效果數值，目標值由雙方共同確定並標明「待客戶確認」；措辭平等，不寫成單方面條款。
高亮處換成你自己的內容：[客戶與背景]、[要驗證的問題]、[我方方案]、[試點範圍]、[基線數據]、[試點週期]、[商務條件]
ChatGPT Plus 充值
已被複製 0 次
使用說明
怎麼填變量：[要驗證的問題] 用客戶的話寫，例如「想看看能不能把報價時間縮短」。AI 會把它改寫成可判定的命題。[基線數據] 很多客戶其實沒有，這時不要硬填，方案裏會安排第一週先量現狀——沒有基線，試點結束時誰也說不清有沒有改善。
常見失敗與調整：
- 成功標準只有「運行穩定」「用戶滿意」：這類標準無法支撐採購決策，追問「加一個業務結果指標」。
- 試點範圍越做越大：把「不包含」一欄寫足，中途新增需求一律記入「正式項目需求清單」。
- 決策人沒參加評審：在雙方分工裏把「決策人出席評審會」列為客戶方投入。
示例輸出
示例，僅供參考（虛構：一家外貿公司試點報價自動生成工具，週期 4 周）
驗證命題：① 業務員能否用工具在 30 分鐘內完成一份標準報價；② 生成的報價在價格與條款上是否不需要主管返工。
| 驗證命題 | 衡量指標 | 基線值 | 目標值 | 數據來源 | 確認人 |
|---|---|---|---|---|---|
| ① | 單份報價平均耗時 | 第 1 周採集 | 待客戶確認 | 工具日誌 + 業務員登記 | 業務部經理 |
| ② | 主管退回修改的比例 | 第 1 周採集 | 待客戶確認 | 審批記錄 | 業務部經理 |
不包含：與財務系統的對接；非標定製產品的報價；歷史報價數據的批量導入。
試點後的路徑：兩項均達標 → 評審會後兩週內提交正式採購申請；一項達標 → 延長兩週只驗證未達標項；均未達標 → 試點結束，我方在 5 個工作日內刪除試點數據並提供說明。
同款作品
用這條提示詞做出來的作品；原作者會因此獲得積分
還沒有同款，來做第一個。
0 條評論
還沒有評論，來搶沙發～