POC 方案提示词（试点 / 概念验证方案：验证范围、可量化的成功标准、双方分工与时间表、转正式采购的条件）
客户提出「先试用一下」时用：把试用变成一个有边界、有成功标准、有结束时间的试点方案，写清双方各自要投入什么、怎么判定成功、成功后走什么流程，避免无限期免费试用。
通用大模型 对话模型通用
你是一名解决方案顾问，负责设计试点项目。你的经验：没有书面成功标准的试用，结束时客户总能找到一个「再看看」的理由；所以开始前就要把「怎样算成」和「成了之后怎么办」谈定。 客户与试点背景：[客户与背景] 客户最想通过试点验证的事：[要验证的问题] 我方产品 / 方案：[我方方案] 试点可用的范围（部门、门店、产线、用户数、数据）：[试点范围] 客户现状的基线数据（没有就写无）：[基线数据] 计划周期：[试点周期] 试点是否收费及双方已谈的条件：[商务条件] 请输出试点方案： 1. 试点目标：把 [要验证的问题] 改写成 2～3 条可以用「是 / 否」回答的验证命题。 2. 范围：包含什么、明确不包含什么（功能、部门、集成、定制各列一行）。 3. 成功标准表：验证命题 | 衡量指标 | 基线值 | 目标值 | 数据从哪里取 | 谁来确认。没有基线数据时，把「第一周采集基线」写进计划，不要编造基线。指标不超过 5 个，至少 1 个是业务结果指标，而不只是「系统可用」。 4. 双方分工表：我方投入（人员、天数、环境）与客户需投入（对接人、数据、使用者时间、决策人参加评审）；标出没有客户配合就无法推进的事项。 5. 时间表：按周列出准备、上线、运行、中期检查、总结评审；中期检查时允许调整什么、不允许调整什么。 6. 风险与应对：数据拿不到、使用者不用、范围蔓延、对接人变动。 7. 评审会安排：谁参加、看什么数据、会上要做出的决定。 8. 试点后的路径：达标后进入正式采购的步骤与时间；部分达标怎么处理；未达标如何收尾、数据如何处置。 9. 需要双方书面确认的要点清单。 约束：不承诺具体效果数值，目标值由双方共同确定并标明「待客户确认」；措辞平等，不写成单方面条款。
高亮处换成你自己的内容：[客户与背景]、[要验证的问题]、[我方方案]、[试点范围]、[基线数据]、[试点周期]、[商务条件]
ChatGPT Plus 充值
已被复制 0 次
使用说明
怎么填变量：[要验证的问题] 用客户的话写，例如「想看看能不能把报价时间缩短」。AI 会把它改写成可判定的命题。[基线数据] 很多客户其实没有，这时不要硬填，方案里会安排第一周先量现状——没有基线，试点结束时谁也说不清有没有改善。
常见失败与调整：
- 成功标准只有「运行稳定」「用户满意」：这类标准无法支撑采购决策，追问「加一个业务结果指标」。
- 试点范围越做越大：把「不包含」一栏写足，中途新增需求一律记入「正式项目需求清单」。
- 决策人没参加评审：在双方分工里把「决策人出席评审会」列为客户方投入。
示例输出
示例，仅供参考（虚构：一家外贸公司试点报价自动生成工具，周期 4 周）
验证命题：① 业务员能否用工具在 30 分钟内完成一份标准报价；② 生成的报价在价格与条款上是否不需要主管返工。
| 验证命题 | 衡量指标 | 基线值 | 目标值 | 数据来源 | 确认人 |
|---|---|---|---|---|---|
| ① | 单份报价平均耗时 | 第 1 周采集 | 待客户确认 | 工具日志 + 业务员登记 | 业务部经理 |
| ② | 主管退回修改的比例 | 第 1 周采集 | 待客户确认 | 审批记录 | 业务部经理 |
不包含：与财务系统的对接；非标定制产品的报价；历史报价数据的批量导入。
试点后的路径：两项均达标 → 评审会后两周内提交正式采购申请；一项达标 → 延长两周只验证未达标项；均未达标 → 试点结束，我方在 5 个工作日内删除试点数据并提供说明。
同款作品
用这条提示词做出来的作品；原作者会因此获得积分
还没有同款，来做第一个。
0 条评论
还没有评论，来抢沙发～