POC 战情室

为什么 ToB POC 容易失控

ToB 场景中的 POC 常常被当成一个“有进度条的项目”来管理：测试通过率、待解决问题、客户反馈，这些信息散落在表格、聊天记录和会议纪要里。等到发现风险时，往往已经错过了最佳干预窗口——P0 阻塞项没人认领，客户沟通节奏断裂，甚至进入采购阶段后才发现关键验收条件根本没满足。

用战情室逻辑重写 POC 运营

这个技能不会输出通用的项目管理模板，而是把 POC 的实时信号转化为可决策的行动项。核心工作流包括：

• 输入收敛：只收集会改变决策的必要信息，比如通过率、未关闭问题列表（含严重程度、负责人、持续时间）、客户沉默时长、竞品动态等。即使信息不全，也会先给出分诊笔记并列出缺失证据。
• 风险分级与收口计划：根据通过率阈值（≥90% 为绿区，70-89% 为黄区）和 P0 阻塞项状态，判断当前风险等级。如果是黄区，重点锁定“影响验收的最小阻塞集合”，并生成 48 小时清零计划。
• 客户沟通与触发决策：当客户在成功演示后沉默时，建议重启采购流程；当通过率达标且核心价值已验证时，触发 poc-to-contract-closer 技能，但会明确标记残留风险。

适用边界

• 不编造客户名称、项目名或合同金额
• 不承诺转化率或成功率
• 不将 P0 阻塞项藏在“整体进展良好”的总结里
• 不将仍在验证基础可行性的 POC 标记为“可进入合同阶段”

本质上，这是一个把 POC 从“过程记录”升级为“决策引擎”的工具，让技术验证的每一步都直接关联到推进或止损的判断。

How a ToB POC Turns into a Project Without a Brain

In B2B sales, a proof-of-concept (POC) often becomes a loosely tracked project: pass rates, open issues, and customer feedback live in spreadsheets, chat threads, and meeting notes. Risks surface too late—P0 blockers lack clear ownership, customer communication rhythms break down, and procurement conversations begin without critical acceptance criteria being met.

Rethinking POC Operations as a War Room

This skill rejects generic project management templates. Instead, it converts real-time POC signals into actionable decisions. The workflow includes:

• Input convergence: Only collects data that affects decisions—pass rates, open issues (with severity, owner, and age), customer silence duration, competitor activity. Even with incomplete data, it generates a triage note and lists missing evidence.
• Risk triage and closure plans: Uses pass rate thresholds (≥90% = green zone, 70-89% = yellow zone) and P0 blocker status to determine risk levels. For yellow zones, it focuses on the minimal set of blockers affecting acceptance and drafts a 48-hour closure plan.
• Customer communication and trigger decisions: When customers go silent after a successful demo, it suggests restarting the procurement path. When pass rates hit targets and core value is validated, it triggers the poc-to-contract-closer skill—while explicitly flagging residual risks.

Boundaries

• Does not invent customer names, project titles, or contract values
• Does not promise conversion rates or success probabilities
• Does not bury P0 blockers under optimistic summaries
• Does not mark a POC as “ready for contract” when it’s still proving basic feasibility

At its core, this tool upgrades a POC from a process log to a decision engine—ensuring every technical validation step directly ties to a go/no-go judgment.