当单个销售机会只有自由文本笔记…

从单个 deal 的通话笔记、CRM 活动日志或邮件线程中提取 qualification red flags，区分已证实风险和笔记缺失，并给出下一步动作；不用于批量 pipeline 或结构化评分。

适用场景

解决思路

1. 先判断适用：用户给出单个 deal 的自由文本记录（call notes、opportunity fields、CRM activity log、email threads），目标是暴露 qualification red flags；可覆盖 B2B 和 B2C。
2. 对每个 flag 独立评两个轴：Severity（若风险为真，对 deal 的伤害）和 Confidence（笔记如何证明它）；绝不合并成单一分数。
3. 把 Unknown 作为常见且有用的结论：笔记没提不等于问题已确认；它把笔记缺口转成下一次通话的问题。
4. 硬规则：任何 Verified 或 Assumed 发现必须引用笔记中的 exact fragment；无可引用证据的发现按定义是 Unknown。
5. 硬规则：每个 flag 都有特定的 disconfirming evidence 可清除它；记录风险前先检查，避免单向棘轮让每个 deal 都看起来要失败。
6. Interview 前逐条询问，每条消息只问一个问题，能多选就多选；笔记已回答的直接跳过。
7. Interview 问：B2B 还是 B2C？B2C 指有真实销售对话的 considered purchase（remodeling、financial products、high-ticket coaching），不是冲动零售。
8. Interview 问：大致 deal size 和 expected cycle length？用于校准 severity。
9. Interview 问：seller 认为 deal 处于什么 stage；是否在 forecast/commit list；答案必须在什么日期前拿到（forecast call、stage gate、buyer 自己的 event）？
10. Interview 问：笔记覆盖什么 period，是否完整？一次 call 的笔记不能证明 trend。
11. Interview 问：目标是救这个 deal，还是修 habit？救 cycle 优先 buyer-facing asks；修 qualification/note hygiene 则提升 record work。
12. Interview 问：下一个 gate 前 effort ceiling 是多少——关系能承受几个 asks，是否有 manager/exec sponsor 可用？
13. Interview 问：用户已经怀疑什么？把它当作待检验 hypothesis，绝不当作要确认的 conclusion。
14. Intake 接受任何关于 deal 的 prose：raw call notes。
15. Intake 接受：pasted activity log。
16. Intake 接受：opportunity-record free-text fields。
17. Intake 接受：email 或 chat threads。
18. Intake 接受：recap emails。
19. Intake 接受：transcript excerpts。
20. 来自任何 CRM 或 conversation-recording tool 导出的 notes 都可用；流程不依赖具体工具。如果环境能读文件，接受 file path 或 export；否则让用户粘贴文本。
21. Partial、messy、thin notes 都可以；说明缺什么是本技能一半工作。明确告诉用户：review 评的是 notes 不是 deal；thin notes 会产生很多 Unknowns，这本身是关于 deal hygiene 的 finding。
22. Workflow 1：运行 Interview；然后确认 input 覆盖用户所有材料（一封遗漏的 email thread 常含唯一 first-hand buyer quote）。
23. Workflow 2：把 notes normalize 成 dated timeline：开了哪些会、谁参加、承诺了什么、日期如何移动；标出记录变薄的地方，那也是证据。
24. Workflow 3：提取 candidate evidence：逐字 fragment，支持或反驳 catalog 中任何内容；区分 first-hand buyer statements、rep 自己的 inferences、second-hand relays；「I have it in writing from the economic buyer」高于「my champion told me」。
25. Workflow 4：对 timeline 和 evidence 跑 `references/red-flag-catalog.md` 的每一组；把每组每个 flag 都 resolve 到某个 state，绝不跳过任何组。
26. Workflow 5：记录风险前检查每个 flag 的 disconfirming evidence；如果 notes 引用了清除证据，则记 Cleared，不是 Red。
27. Workflow 6：给每个 non-Cleared flag 评 severity，按 Interview 得到的 deal size、cycle length、motion 校准，不用固定表。
28. Workflow 7：区分「有证据」和「仅缺失」；为每个 Unknown flag 写恰好一个 diagnostic question（catalog 为每 flag 提供一个），然后按 chase order 排序 Gaps；rep 只有一个 next touch，不是十二个。
29. Workflow 8：按 output shape 写 report；给每个 Red 和 Amber flag 附一个来自 catalog 的 remediation play，并命名其 response rung。
30. Workflow 9：跑 Quality gate；iterate——重新评分和重写——直到每项通过。
31. Workflow 10：如果 harness 有 persistent memory，记录 raised flags、states、evidence，供同一 deal 下次 review 检查哪些 gap 关闭；否则在 report 末尾加 carry-forward list。
32. Confidence state Cleared：notes 含该 flag 的 disconfirming evidence；必须引用清除它的逐字 quote。
33. Confidence state Verified：first-hand、可引用的 buyer statement 证明风险；必须引用 notes 中的逐字 quote。
34. Confidence state Assumed：只有 rep inference、hearsay 或 second-hand relay 证明；必须引用 inference/relay 的逐字 quote。
35. Confidence state Unknown：notes 对该 flag 沉默；无 quote——沉默就是 finding。
36. Severity 用 High/Medium/Low：若风险为真对本 deal 的伤害，按 deal size 和 cycle length 判断，不用固定表。
37. 不要把 severity 和 confidence 两轴相互排序，也不要合并成一个 score；rubric 只评 notes 说了什么。
38. Report grade Red：Verified risk + High severity。
39. Report grade Amber：Verified risk 在 Medium/Low severity，或 Assumed risk 在 High severity。
40. Report grade Watch：Assumed risk 在 Medium/Low severity；写明什么会 confirm 或 clear 它。
41. Report grade Gap：任何 Unknown；带一个 diagnostic question，绝不带 remediation play，因为没有已确认内容可 remediate。
42. Report grade Cleared：简要列出并带 clearing quote，让下一个 reviewer 不再重提。
43. Chase order 原则：grading resolve 所有组所有 flag；chasing 是另选的小集合。Gap 只有在答案会改变下一步动作时才值得追；不能移动计划的 flag 再严重也不追。
44. Chase order 原则：rank instrument，不是 flag；同一个 gap 因 rep 如何关闭而便宜或昂贵。
45. Chase order 原则：effort = rep hours + buyer goodwill spent + calendar latency，绝不是 price。
46. Chase order 默认 efficiency：`desk check > one question > access ask > second data point > record repair`。
47. Chase order value：`access ask > one question > desk check > record repair > second data point`。
48. Chase order effort 从多到少：`record repair > access ask > second data point > one question > desk check`。
49. Chase rung Desk check：用 rep 已有记录关闭——calendar、sent mail、CRM field history、attendee lists；关闭 thread coverage、close-date pushes、seller-owned timeline、latency/attendance trends、notes thinning；近零 effort 无 goodwill；重新评价 evidence base 本身，薄/错记录污染其他 findings，所以它 gate 其余。
50. Chase rung One question：在 thread 中问单个 diagnostic question，用 email 或已 book 的 call 回答；关闭 decision process、budget owner 自己的话、blocker 实际 objection、next dated step、quantified impact；1 小时准备、一次 goodwill ask、几天 latency；通常翻转 forecast category 并命名下一个 meeting。
51. Chase rung Access ask：让 buyer 花自己的 capital——介绍、co-decider、缺失 function、co-owned plan；关闭 EB never met、co-decider unconsulted、champion reach to power、requirements from one function；一周以上 latency、真实 goodwill、可拒绝；改变最多；ask 既是 confirmation 也是 remediation，拒绝本身就是 Verified finding。
52. Chase rung Second data point：等下一次 reply gap、push 或 attendee list；关闭 two-point record 无法评的 trend flags；近零 hours 但一个 quarter latency；现在价值小，答案常在它想影响的 forecast call 之后到。
53. Chase rung Record repair：backfill 本 deal log，然后让 notes 达到可评分标准；对今天这个 deal 不关闭任何事；是 standing job；对下一次 call 无价值，但在之后每个 deal 的每次 review 中复利。
54. Deleted, not demoted：完整 re-discovery call 一次关闭多个 gaps。本技能每个 gap 只发一个问题；一次 call 五个问题像 interrogation，会耗尽 access ask 需要的 goodwill。完整问题集路由到 `mbfinotti/sales-skills@sales-discovery-questions`。
55. Chase order 会饿死 Access ask：价值最高、effort 最高，所以在 efficiency 下总输；但 unmet power 杀死 late-stage deals，而便宜 rungs 只报告 progress。deal 在 commit，或 next stage gate 是 decision meeting 时，把它 promote 到第一；没有 desk check 能 clear veto。
56. Chase order 也会饿死 Record repair：当同一 deal 连续两次 review 都是 Unknowns dominate 时 promote。
57. Re-rank chase order 时，说明哪个 fact 移动了哪一级：forecast call 在一周内 -> promote access ask，second data point 无价值。
58. Re-rank：champion 当天回复 -> 压缩 one-question rung latency，promote 到 desk check 之上。
59. Re-rank：rep 带 30 个 deals -> 留前两个 rungs；rep 带 3 个 -> 每个都能承受 access ask。
60. Re-rank：Interview 答「fix the habit」 -> record repair 从最后 promote 到第一。
61. Re-rank：notes 只覆盖一次 call -> desk check 只会返回 Unknowns，从 one-question rung 开始。
62. Response order 只适用于 Red 和 Amber。Unknown 没有已确认内容可响应，回到 chase order。
63. Response 默认 efficiency：`trade it > work it > re-forecast it > escalate it > disqualify`。
64. Response value，按 unblocked deals 或 returned cycle hours：`escalate it > trade it > work it > disqualify > re-forecast it`。
65. Response effort 从多到少：`escalate it > work it > trade it > re-forecast it == disqualify`。
66. Response 平局真实：re-forecast 和 disqualify 都近零 rep hours、零 buyer goodwill、一次 internal update；花费相等，仅 reversibility 不同，由 value axis 承担；effort 单独不能选。
67. Response rung Trade it：让 fix 成为 buyer 已经想要的下一件事的 price——proposal、scoping session、pricing；1 小时结构，无新 goodwill，buyer 自己的 ask 出资；flag 在本来就会发生的步骤内关闭。
68. Response rung Work it：把 catalog play 当作独立 touch 执行；1 小时准备、一次 touch goodwill、几天 latency；关闭一个 flag；当没有东西可 trade 时的默认。
69. Response rung Re-forecast it：把 deal 移出 committed period，并点名移动它的 flag；近零 hours、无 buyer goodwill、一些 internal capital；买到 forecast truth，不是 deal progress；是 urgency 或 budget flag 无法 clear 时的诚实答案。
70. Response rung Escalate it：带 manager 或 exec sponsor 打开 rep 打不开的门；政治资本、一周协调、每个 deal 大约只能用一次；对 blocker 是 access 的情况能解决一切，对 information 的问题无效。
71. Response rung Disqualify：把剩余 cycle hours 还给 pipeline 其他部分；近零；买到整个剩余 cycle；不可逆，所以对任何可挽回 flag 都是错的。
72. Deleted, not demoted：向 buyer 提出 flag 作为 concern 但不带 ask。它花 goodwill 且不返回 evidence；每个 catalog play 都带 ask。
73. Response order 会饿死 Escalation：它显得昂贵且政治化，efficiency 永不选它；它单独能修的 flags（EB never met、blocker unaddressed）正是 late-stage 杀死 deal 的。blocker 是 access 不是 information、champion 已被问至少两次、stage gate 在当前 period 时，promote 到 trade/work 之上。
74. Response order 会饿死 Disqualify：同理。基于一个 named unrecoverable flag promote，绝不基于 flag count。
75. 两个 order 都不是 law；随 deal、quarter、执行者变化。有 engaged exec sponsor 的 rep 便宜地 escalate；没有的人不应围绕它计划；quarter end promote trading 和 re-forecasting，高于任何有一周 latency 的动作。
76. Invocation 示例：Here are six weeks of notes on my top deal - what red flags am I missing?（后附粘贴 notes）。
77. Invocation 示例：Review this opportunity's activity log before I commit it - is this deal real?
78. Invocation 示例：Single-threaded check: everything I have on the deal is in this email thread.
79. Output 一份 report；格式：`DEAL RED-FLAG REVIEW - <deal>, reviewed <date>, notes covering <period>`。
80. Output Snapshot：size、stage、cycle age、motion（B2B/B2C）——按陈述，或写 not in notes。
81. Output Timeline：从 notes 重建 dated events；标出记录变薄处。
82. Output Red：flag - severity - verbatim evidence quote - one remediation play - its response rung，以及 promote/demote 它的事实。
83. Output Amber：与 Red 相同 shape。
84. Output Watch：flag - verbatim evidence quote - 什么会 confirm 或 clear。
85. Output Gaps：flag - one diagnostic question - its chase rung；按 chase order 列，最高 value per unit of effort 在前。
86. Output Cleared：flag - the quote that cleared it。
87. Output Risk check：回答两个 pipeline-review questions（Armand Farrokh, 30MPC）：deal 通过过去 stage criteria 的 HOW 是否有风险，以及未来 stage 的 PLAN 是否有风险——从 findings 回答。
88. Output Verdict：什么有证据 vs 什么仅缺失；单一 next action，是 Interview 后 re-rank 的 chase order 顶部。绝不写 win-probability 或 methodology score。
89. B2B 和 B2C 相同：evidence rule——引用，否则 Unknown。
90. B2B 和 B2C 相同：two-axis grading。
91. B2B 和 B2C 相同：disconfirming-evidence check。
92. B2B 和 B2C 相同：整个 Pain and value、Engagement、Urgency-quality logic——happy ears、unquantified impact、seller-owned timelines、repeated pushes、growing response latency 读法相同。
93. B2C 和高 velocity transactional 不同：single-threading 不是 flag；这些 deal 按设计就是 single-stakeholder。等价 stakeholder risks 是 unconsulted co-decider（partner/spouse 的 approval 被假定但无证据）和 unverified ability to pay（financing/credit 未确认）。
94. B2C 不同：compelling events 更常是 personal 或 seasonal（搬家、生活事件、家庭设定的 deadline），而不是 fiscal；真实有日期的 trigger 仍胜过 they seemed eager。
95. B2C 不同：procurement、security、legal review 通常不存在；Process group 压缩为一个问题——是否有 agreed、dated next step？Cart 或 trial abandonment 和加长的 reply gaps 成为主要 engagement flags。
96. 把 enterprise heuristics 套到 transactional deal 本身是 false positive；反过来也成立：用 transactional response-speed 标准判断 long-cycle enterprise deal 会制造假 ghosting flags。
97. Failure mode：把 Unknown 当 Red。Fix：Unknown 是 notes 沉默，不是 deal 坏了；它赢得一个问题，不是 escalation。
98. Failure mode：用 enterprise criteria flag 小型 transactional deal。Fix：用 Interview 校准；multithreading 和 mutual-action-plan flags 在不符合的 motion 下关闭。
99. Failure mode：notes 只覆盖一次 call 时称 deal single-threaded。Fix：一次 call 的 notes 只证明一次 call；coverage 记 Unknown，问还有谁参与。
100. Failure mode：从一封未回复 email 推断 champion departure。Fix：不断扩大的 gaps pattern 才是证据；一次沉默不是；最多 Assumed，带 quote。
101. Failure mode：按 flag count 做 qualify out。Fix：count 合并两轴，count 不是 decision rule；response order 说明什么才 justify disqualifying。
102. Failure mode：单向棘轮——记录风险但不检查 clears。Fix：每个 flag 都跑 step 5；不能输出 Cleared 的 review 总会找到 doomed deal。
103. Failure mode：把缓慢、共识驱动的购买读成 disengagement。Fix：有些购买文化和受监管流程合法地慢且安静；按 segment norm 衡量 cadence，不用通用标准。
104. Failure mode：评 deal 而不是评 notes。Fix：verdict 必须区分 evidenced risk 和 thin record；Unknowns dominate 时推荐更好的 note hygiene。
105. Quality gate：按全部六项给 finished report 打分。通过阈值 6/6；不通过就 iterate。
106. Quality gate 1：100% 的 Red 和 Amber findings 带 notes 中的 verbatim evidence quote。
107. Quality gate 2：每个 catalog group 把它的每个 flag resolve 到 state——不跳过任何，包括 Cleared 和 Unknown。
108. Quality gate 3：No Unknown 出现在 Red、Amber 或 Watch；每个 Unknown 带恰好一个 diagnostic question。
109. Quality gate 4：每个 Red 和 Amber finding 带恰好一个 remediation play。
110. Quality gate 5：每个 severity 都按本 deal 的 size、cycle、motion 论证——不用固定表 severity。
111. Quality gate 6：Gaps 按 chase order 列出，Red/Amber plays 命名 response rung；两者都按 Interview answers 重新排名，并说明移动 rung 的事实。
112. KPI：review 是否有效，看 reviewed deals 随时间：slip rate（close dates 被推到 committed period 之后）下降。
113. KPI：越来越多被 flag 的 deals 在 next stage 前关闭 flag。
114. KPI：reviewed deals 的 forecast accuracy 相比 unreviewed 改善。
115. KPI：一次 review 的 Unknowns 到下次转化为 Verified 或 Cleared。
116. KPI：同一 deal 跨 review 的 Unknown count 上升，表示要先修 note hygiene，不是 deal quality。

适用边界 · 注意事项

• 不要用于结构化 qualification scoring，如 `mbfinotti/sales-skills@meddpicc-scorecard`；本技能不输出 methodology score。
• 不要用于 stakeholder map 构建（`mbfinotti/sales-skills@deal-champion-mapping`）、完整 discovery question set（`mbfinotti/sales-skills@sales-discovery-questions`）、ROI/business-case（`mbfinotti/sales-skills@deal-value-calc`）或把这些 notes 变成 follow-up email（`mbfinotti/sales-skills@sales-meeting-recap`）。
• 不要用于多 deal pipeline export；那是 pipeline-level work（hygiene、forecasting），本技能只深读一个 deal 的书面记录。