asb-carol-inciting-events

促成事件：是什么让他们今天就买

潜在客户可能认同产品非常合适，关键优势正是他们想要的，没有任何硬伤，价格也合理——但他们仍然不会购买。他们的借口确实是真的：“我们现在没法实施；九个月后再联系。”拥有购买权的人有一到三个首要优先事项，而你不在其中。能让你跃升至首位的是促成事件：没人会毫无缘由地一觉醒来，决定今天就买——他们的生活中发生了某件事，某个陷入困境的时刻让他们必须采取行动。这项技能会逐一梳理每项关键优势对应的这些时刻。

心智模型

促成事件促成购买

有三种力量，依次是：促成事件是人们购买任何东西的原因（迫使他们现在行动的困境），关键优势是人们选择向你购买的原因（让你的优势至关重要的情况），以及硬伤会划定排除范围。关键优势意味着客户可能在意某个问题；促成事件则会让这个问题升至他们想要今天就解决的前三项优先事项。这就是为什么每个真正的促成事件都与一项关键优势相关联——没有对应关键优势的事件，只会促使他们购买别的东西。典型的配对包括：速度优势对应的事件是“SEO 顾问说，性能差正在阻碍我们的排名”和“我们看到了那项研究，发现网站越快，转化营收越高”；规模优势对应的事件是“一年中流量最大的一天，网站崩了——再也不能这样了”；安全优势对应的事件是“我们遭到黑客攻击，太可怕了，我们花了每小时 300 美元请顾问，但仍不确定问题是否已经解决”；支持优势对应的事件是“我们打电话求助，却被告知‘我们只负责让你的服务器保持运行。’”

观察到的优先于假设的——两者都要标注

识别促成事件的可靠方法是询问客户是什么促使他们开始寻找，以及为什么选择了你——最好在购买后立即询问，此时他们的回答还记忆犹新。因此，如果有访谈证据（调研结果报告、逐次访谈总结文件、入门调查问卷答案），请先收集这些证据：记录真实的触发故事，使用客户自己的措辞，并标注为已观察到，同时注明来源。然后再回过头来填补空缺，并将这些事件标注为假设——诚实地标注，因为假设的事件只是披着计划外衣的猜测，下一轮与客户的交流应该对其进行验证。绝不要把头脑风暴伪装成证据。

反向推演的视角

进行假设时，问问自己：什么会促使客户今天采取行动，而且既紧迫，又有预算，还能获得预先批准？通过以下视角进行头脑风暴：

• 迫使立即行动的危机——公开的数据泄露或数据丢失；关键供应商被收购或停业；重要客户发出最后通牒；诉讼或监管调查；高管离职；公关灾难；竞争对手发布公告，暴露出自身的差距。
• 季节性和周期性节点——年度规划、财年末、报税季、季度审查、合规审计、会议期限、行业旺季临近。
• 战略窗口期——合规截止日期、必需的认证、进入新市场、收购完成、IPO 准备、旧系统现代化改造、新资金到账，一次性带来预算和预期。
• 个人生活变化（针对消费类产品和个人专业人士使用的产品）——成为父母、退休、确诊疾病、家人离世、结婚或离婚、创业、换工作、毕业、购买第一套住房。

易于发现才能发挥作用

对于每个事件，都要回答：如何找到处于这种情况中的潜在客户？ 网站刚被黑的人不会搜索“安全托管”——他们会搜索“如何判断我的网站是否被黑”，并在茫茫网络中发帖求助：“救命！我的网站被黑了！”易于发现的信号包括：官方公告、高管参加播客、产品发布和媒体巡访、招聘信息变化、评论或社交媒体上的反复抱怨、分析师报告、监管变化通知、领导层变动、融资消息——尤其是处于那种境况的人在搜索框中输入的确切词句。无法从外部发现的事件仍值得记录，但要说明这一点：这类事件只能用于宣传文案（“如果你最近遇到了这种情况……”），不能用于定向。事件往往分成几个部分——执法事件中，诉讼部分是公开记录，而审计通知部分则不可见；请注明哪些部分可用于定向，哪些只能用于宣传文案。如果用户要求你研究触发因素——近期监管变化、融资消息、季节性周期、竞争对手动向——请用搜索工具的当前结果确认；不要依赖内部（训练）知识，因为它已经过时，也无法涵盖今年的真实事件。

不够生动，就无法宣传

在广告中，诱因往往比关键要素更有效，因为它贴合客户当下的体验——他们正在应对自身处境，而不是在寻找产品属性。只有把事件写得生动具体，这种方式才有效：明确的时刻、情绪和数字。“网站被黑是一种切身的侵犯——你每小时花 300 美元请顾问帮忙，却仍担心问题会不会再次发生”能够起到宣传作用；“客户对自己的托管服务商感到不满”则不行。泛泛的事件（“意识到自己需要更好的解决方案”）一律不予记录，无论以何种形式都不行——真实触发因素中总有一个具体时刻，找到它才是这项工作的关键。

术语

• 诱因（E1、E2，……）——促使符合关键要素的客户现在购买的具体触发时刻；注明对应的 [K 编号]。
• 已观察／假设——证据状态：从真实客户案例中收集（附来源）与逆向推断（有待验证）。允许使用两种限定表述：“已观察（来自记忆）”用于表示用户回忆起真实案例——这是真实证据，但来源依据较弱，应在验证阶段再次确认；如果某种模式反复出现在销售通话中，但没有对应的单一客户案例，则仍归为“假设”。假设事件可以引用支持其合理性、但并非触发证据的材料（“合理性得到支持——但尚无证据——六月复盘中提到的长期不安”），而无需因此增加“来源”一行。
• 易于发现性——如何从外部发现或触达处于该事件情境中的潜在客户，包括他们可能使用的搜索词句。

绘制者的立场

清楚表达，不耍聪明

写作的目的是让人理解，而不是让人赞叹。这项工作涉及复杂概念，巧妙的比喻、文字游戏或俏皮表达只会让人更难理解，而非更容易。把意思直白地说出来。如果删去修饰后句子更清楚，就删掉修饰。直接说明真正的要点，不要用机智的表达暗示它。

重述指代内容；不要只引用代号

提到编号或字母编号的项目时——例如 K4、W2、O17、H3 等——要加上简短易懂的说明，指出它具体是什么（“K4——职业生涯系于网站成败的所有者”）。对于几小时或几天前才看过定义的人来说，单独一个代号毫无意义：标签用于追溯，释义用于理解。保留标签以确保准确；并始终加上释义。

先收集，再头脑风暴

如果存在访谈资料——例如包含触发故事的调研结果报告、每次访谈的复盘文件、退出调查或入门调查——请先阅读这些资料，并将每个触发故事都整理为候选事件，然后再提出任何假设；确认事件时就记录已收集的内容，即使这些事件属于后续步骤中的关键需求；E 编号按确定顺序排列，而非按关键需求顺序排列。用户的记忆也算证据（“最近三位客户说，是什么促使他们开始寻找？”），并标记为“来自记忆的观察”。只有在证据不足时，才使用分析视角。如果用户完全没有访谈证据，请明确说明，在向客户提问之前，文件中的所有内容都只是推测；而询问客户就是验证路径。

让时刻变得鲜明具体

当用户给出模糊的触发因素（“他们受够了现有工具”）时，要追问具体时刻：他们是因为什么事件受够了？那天早上发生了什么？造成了什么损失？那天晚上他们在 Google 上输入了什么？如果环境中安装了预定义的魔鬼代言人式盘问技能（例如同一作者编写的 Rude Q&A / asb-rude-qa），可以用以下要求让它审查草稿：*攻击这些触发事件——找出每个只是一种情绪、而非具体时刻的事件；每个没有真实客户故事或合理情境支撑的事件；每个被当作事实对待的“假设”事件；以及每条过于含糊、无法付诸行动的可发现性说明。不要接受一厢情愿或含糊其辞的辩护。*如果没有此类技能，就亲自进行盘问，并清晰呈现：候选事件内联列出，在收尾检查时集中质疑。

每个事件都要对应一个关键需求

没有对应任何关键需求的事件是警示信号，不是记录项：要么这是购买你不销售的产品的触发因素，要么它指向前面步骤遗漏的某个关键需求。说明你认为是哪一种；如果用户认为确实遗漏了一个关键需求，那就把它作为发现带回关键需求文件，而不是记录一个无归属事件。

每轮只处理一个关键需求

按顺序逐个处理关键需求，每轮一个；一个关键需求可以产生一个或多个事件。开场尽量简短：说明读了什么、哪些关键需求已有观察到的触发材料，然后进入第一个关键需求。用户要求时可以简化流程，但不能省略结构。

如何使用此技能

阶段 A——导入

阅读关键需求文件（默认是当前目录中的 KEYSTONES.md——最好已经明确了排除条件；如果变更日志显示尚未完善，就继续，但要指出各细分项可能仍过于宽泛）。询问有哪些客户证据，并阅读用户提供的资料：客户访谈调研结果报告、每次访谈的复盘文件、调查导出数据，或用户回忆的近期客户为何开始寻找。如果不存在关键需求文件，不要为未知目标整理触发因素：提供入门路径——先运行关键需求步骤（如果安装了本方法作者编写的关键需求技能，例如 Keystones / asb-carol-keystones，请指出它），或者在聊天中整理一份最精简的关键需求列表，并说明未经审核的关键需求会产生未经审核的事件。如果存在 INCITING-EVENTS.md：标题标记为进行中，表示要继续处理；文件中没有的内容就从未确定，不要凭任何人的记忆重构已结束会话中的半成品提案，而要从证据重新推导。若状态为完成，则询问是否需要修订。（以问题映射格式编写的每次访谈复盘文件本身就表明正在开展访谈流程——无需询问，直接整理其中的信息。）

输出：同一目录中的 INCITING-EVENTS.md。如果输入是粘贴的内容且不知道文件路径，请先询问方法文件应存放在哪里，再创建任何文件（默认当前目录）——绝不要悄悄把文件散落在各处。

阶段 B — 梳理关键支柱

从小处着手：你读了什么，哪些关键支柱已经在证据中有了记录在案的触发事件，然后是第一个关键支柱。针对每个关键支柱：

1. 收集观察到的事件，从证据中提取——客户自己的原话，并注明来源（“FINAL-REPORT.md F5” / “6 月 12 日访谈的复盘记录” / “用户对 Meridian 交易的回忆”）。
2. 通过各个视角推测缺口，并标明这是推测。
3. 让每个事件具体鲜活——当时的情景、情绪和数字。
4. 可发现性——说明如何发现或接触处于这种状况的人，包括他们可能使用的搜索词；如果无法从外部发现，也要说明。
5. 记录 K 编号、证据状态和可发现性；然后进入下一个关键支柱。

**边做边记录到文件中。**在第一个事件确定后，创建 INCITING-EVENTS.md；持续更新文件头指针（“已梳理的关键支柱：K1；当前梳理：K2”）。文件才是记忆，聊天不是。

阶段 C — 全面检查并收尾

• 关联检查——每个事件都引用一个关键支柱；每个关键支柱至少对应一个事件，或有如实记录的缺口说明（“目前还不知道触发因素——询问接下来的 5 位客户是什么促使他们开始寻找”）。
• 证据审查——对整批内容进行审查（委派或自行执行）：没有把推测的事件写成事实；每个观察到的事件都有来源；没有遗留泛泛而谈的内容。
• 验证路径——对于推测的事件，记录要问客户的问题（“是什么促使你开始寻找？”）以及提问时机（购买后立即询问，趁记忆犹新）。如果已安装本方法作者编写的客户访谈流程（其目标设定技能为 asb-interview-goals），请将其列为系统化开展验证的方式；否则，描述具体做法：在新客户入门时每次都询问，并记录答案。

完成后（移除文件头），以交接说明收尾：下一步将综合所有内容——优势、关键支柱、交易障碍和这些事件——形成理想客户定义；如果已安装本方法作者编写的定义技能（例如 Define Carol / asb-carol-define），请注明：“准备好后，对这些文件运行 asb-carol-define。”

文件结构

# Inciting events — <company / project name>

> ⚠️ IN PROGRESS — the walk is not complete. Keystones walked:
> <which>; currently on: <K-number>. If you are resuming, continue
> there. (This note is removed at finalization.)

<Two or three lines: which keystones file this maps triggers for
(name it), what customer evidence was available, and the standing
rule — observed events carry sources; hypothesized events are
guesses to validate with customers, not facts.>

## Inciting events

**E1.** <The specific trigger moment, written vividly — what
happened, what it cost, how it felt.>    [K2] — OBSERVED
    Source: <where this story came from.>
    Findability: <how to detect/reach someone in this condition;
    likely search phrases in quotes.>

**E2.** <…>    [K1] — HYPOTHESIZED (validate: ask new customers what
    prompted them to look)
    Findability: <…>

## Gaps

- <K-number> — no trigger known yet; <the question to ask the next
  customers>.

## Next steps

<Two or three sentences of prose: validate the hypothesized events by
asking customers — right after purchase, while fresh — what prompted
them to start looking; then synthesize strengths, keystones,
deal-breakers, and these events into the ideal-customer definition.
That's the final step of the method, and it works from all four
files.>

E 编号一经写入即固定。绝不重新编号；状态发生变化的事件（客户确认后从推测变为观察到）保留原编号，并补上来源。

拒绝条件

• 没有关键支柱。 不关联目标就绘制触发因素，只会描述人人都会遇到的糟糕一周。请提出梳理关键支柱这一步，或带有明确限定的快速记录方案。
• 把头脑风暴伪装成证据。 即使用户确信如此，推测的事件也不能因此去掉标签。只有得到真实客户的陈述支持后，它才能转为观察到的事件——验证路径正是为此而设。
• 无论如何坚持，都不能接受泛泛的事件。 “当他们意识到自己需要更好的东西时”不能以任何形式记录；真正触发因素背后的具体时刻一定存在，深入追问找到它才是这项工作的核心。
• 孤立事件。 未关联任何关键支柱的事件是警示信号——要么偏离目标，要么遗漏了值得补回该文件的关键支柱；绝不能将其作为条目记录。
• 撰写广告文案。 这些事件是广告和定位的原始素材；撰写文案属于后续工作，需要另行打磨。可发现性备注指出在哪里、面向谁；具体措辞留待之后。
• 编造客户引语。 “观察到”意味着有真实客户的真实陈述，并附有来源。虚构细节会毁掉这个文件相较于猜测仅有的优势。