leaked-demand-recovery

用途\n\n该技能用于找回已付费获取但在系统间隙中丢失的需求。它先定位这些流失线索，在任何人接触之前证明流失真实存在，然后起草恢复沟通。\n\n主要能力\n\n- 圈定扫描范围：选择要处理的数据接缝与时间窗口。活跃流失约一个月，已成交流失复活约六个月到十二个月。若已指定窗口则确认。\n- 从捕获系统构建候选名单，而非 CRM：CRM 只记录有人记得登记的内容；邮箱、日历、通话录音器和线索捕获渠道记录实际发生的事。取并集，按人和公司去重，并纳入完全没有 CRM 记录的人，因为他们往往规模最大且沉默。references/leak-map.md 列出了值得处理的接缝及各自验证依据。\n- 对每个候选线索用两个独立系统验证，这是硬性门槛。声称某人被遗漏的记录常常有误，而代价不对称：漏掉一个恢复机会损失一个商机，而给已预约或已回复的人发消息会损害关系。运行此步前阅读 references/verification-gate.md。未通过门槛的候选线索带着一行说明离开名单，绝不把失败门槛软化为轻触。\n- 在选定语气前确认历史：被恢复的主动问询者通常不是新客户。无历史：全新首次接触。有过对话：引用上下文的重新接触语气，如实提及背景。现有或流失客户：转给客户负责人并停止起草。同事负责的进行中交易：标记负责人并停止，因为并行消息会与进行中的动作冲突。已成交流失：将所述原因带入框架，仅在阻塞因素确实改变时继续。\n- 在匹配评分前应用硬性取消资格条件：地域、监管覆盖、细分。可服务性是二元且廉价的；对一个无法服务的账户做匹配评分昂贵且无意义。验证而非轻信薄弱的数据补充，因为差记录会低报公司规模。把取消资格清单放在一处，否则过时门槛会拒绝已开放的市场并接纳已放弃的市场。\n- 为每个确认流失起草一条消息，基于他们询问的内容或上次对话到达的确切点做个性化。恢复框架本身起作用；通用重新接触文案浪费了精确知道流失点的优势。若流失是内部失误，用一句话承认并继续。一个明确的下一步。\n- 提交审批：每个确认流失包含人员与公司、流失类型、已核对证据、历史、建议动作，然后是草稿。失败门槛的候选线索各留一行可见，便于审计验证工作并发现误判。定时扫描若无发现，静默结束。\n\n使用方式\n\n按照上述流程，从捕获系统提取并去重候选名单，用两个独立系统验证，确认历史，应用硬性取消资格条件，起草个性化消息，最后提交人工审批。该技能只验证和起草，由人决定。\n\n适用场景\n\n- 聊天或表单线索从未完成预约\n- 演示请求没有会议\n- 通话结束后没有后续\n- 已成交流失的复活尝试\n- 不同系统之间可能存在需求流失的销售与增长运营场景\n\n限制与规则\n\n- 每个流失在推进前必须用两个独立系统确认。\n- 在得出无活动结论前，必须解析联系人记录并按地址和域名搜索。\n- 系统分歧时，最接近事件的系统优先：日历在预约上胜过 CRM，邮箱在最后联系上胜过 CRM，录音器在出席上胜过日历。\n- 绝不把单一系统的字段当作联系或未联系的证明。\n- 绝不把聊天记录、机器人承诺或自动应用的状态当作存在预约或举行过通话的证据。\n- 绝不自动发送或发布任何内容；此技能只验证和起草，由人决定。\n- 绝不在未先行标记的情况下向同事正在处理的账户发消息。\n- 绝不用全新入站语气重新接触先前联系人，这读起来像机构失忆，比不发更糟。\n- 绝不恢复可服务覆盖范围之外的线索；标记并停止。\n\n关于定价、平台支持细节、安装命令或具体集成方式，资料暂未提供。