Tob Poc Budget Justify

tob-poc-budget-justify — POC 预算论证助手

客户说"先做个 POC 看看"？帮你论证 POC 需要多少预算和资源。

当销售跟客户谈 POC，客户没明确预算/范围/时间/成功标准时，快速输出：

• POC 目标对齐与范围界定
• 资源/时间估算（人天 + 周期）
• 预算论证框架（为什么 POC 需要投入）
• 成功标准定义
• POC 72h 快速响应闭环（某大型文化集团实战，93% 通过率）

使用方式

交互模式（推荐）

tob-poc-budget-justify

快速模式

tob-poc-budget-justify --client "某零售集团" --industry "零售" \
  --poc-goal "验证AI客服能否替代人工处理80%常见问题" \
  --budget "10万以内" --decision-maker "IT总监"

精简模式

tob-poc-budget-justify --quick --client "某客户" --poc-goal "试试效果"

输出结构

POC 预算论证报告（Markdown），5 模块：

模块 1：POC 目标对齐

• 客户想验证什么（功能/效果/ROI/技术可行性）
• 客户的真实诉求 vs 表面诉求
• 风险提示：来自真实项目的教训

模块 2：POC 范围界定

核心原则：POC 不是免费试用，是有边界的验证实验。

模块 3：资源/时间估算

注意：政务/金融行业含安全审计阶段，周期更长。

模块 4：成功标准定义

• 量化指标（准确率/响应时间/覆盖率）
• 验收方式（数据对比/客户打分/第三方评估）
• POC 72h 快速响应闭环（某大型文化集团实战）
• 超期警告：72h 无决策 → 标挂起 + 汇报

模块 5：预算论证

• 为什么 POC 需要预算（不是免费试用）
• 同行业 POC 投入参考（来自真实项目，去敏）
• POC 投入 vs 签单后收益对比
• 风险：无预算 POC 的隐性成本

规则来源

本 Skill 的规则萃取自 ToB 真实项目经验（去敏）：

• 零售行业：来自某零售 IT 服务商项目，"边界验证法"— 先列 3 个"不做什么"，客户才会认真谈预算。某项目 POC 预算 8 万，签单 50 万。
• 金融行业：来自某系统集成商项目，安全合规优先，低价竞品用"安全投入 = 合规保障"翻转。
• 政务行业：来自某政务集成项目，POC 最终是汇报给领导看的，必须有"领导能看懂的看板"。
• POC 72h 闭环：来自某大型文化集团实战，5 问题 48h 解决 4 个，93% POC 通过率。

不编造数据，不泄露客户信息。行业成本估算仅供参考，实际以项目具体情况为准。

实战原则

1. POC = 有边界的验证 — 不是免费试用，不是功能演示
2. 目标决定范围 — 客户说"试试效果" → 帮他翻译成具体验证指标
3. 预算 ≠ 成本 — 是双方投入的诚意，无预算 POC = 客户不认真
4. 成功标准先定义 — 签 POC 协议前先说好"什么算成功"
5. 3 周是上限（零售） — POC 超过 3 周就变成项目，失去验证意义（政务/金融适当延长）

联用

• POC 前跑 tob-poc-budget-justify 论证预算 → POC 中按 72h 闭环执行 → POC 成功后跑 tob-sales-proposal 生成提案 → POC 失败后跑 tob-win-loss-review 复盘