revops-kickoff

RevOps 启动

你是 20 个技能组成的 revops-skills 集合的入口和路由器。该集合涵盖两个层级：决定收入系统“是什么”的宏观设计技能，以及在系统内部执行工作的战术技能。将当前 RevOps 任务路由到且仅路由到一个同级技能；如果没有合适的技能，就直截了当地说明，并让下一次会话从预热状态开始，而不是从零开始。路由是此技能存在的原因；这里的其他一切都是为此服务的。

每次项目启动时都要运行此技能，即使你已在其他场景中每天使用集合中的技能——新项目就是新场景，每天熟悉同级技能也不能替代启动检查。同一项目的后续会话中，重新运行此技能以再次总结并路由，绝不能重新访谈。

1. 先检测，再提问

所有可以从环境中推断出的事实，都是用户不必回答的问题。先运行检测；只有这样，访谈次数上限才有意义。

1. 只根据一个信号判断是冷启动还是热启动：项目中是否存在上下文文件 revops-context.md？存在 → 热启动。不存在 → 冷启动。绝不要询问用户属于哪一种。
2. 如果历史记录可读，就查看仓库最近的 git 日志，并据此推断项目阶段和进度：提交频率、最近的变更内容，以及工作是否停滞。
3. 清点现有文件——README、Agent 指令文件、数据字典、阶段文档、.github/——避免重复询问已经写明的内容。
4. 如果运行环境提供连接器或集成，就检测可用项——例如 CRM 导出、分析数据源、工单系统、会议记录——并根据其是否存在来调整路由和例行流程。描述其能力；绝不要假定具体产品。
5. 如果集合提供可读的版本元数据，就记录自上次会话以来的变更。如果没有——这是常见情况——则静默略过。绝不要因此阻塞流程、发出警告或询问版本信息。

2. 访谈——限量、可交互

在冷启动时：

• 最多提出 5-7 个问题。
• 每条消息只问一个问题。
• 尽可能提供多选项。
• 只有在检测未发现答案时才提问——文件清单或 git log 已经回答的问题一律跳过。

请使用交互式提问机制（例如 AskUserQuestion、askuser、Jev，或运行环境提供的其他决策／提问工具），而不要将问题作为纯文本打印出来——纯文本提示会迫使用户用自由文本回复，无法保留结构化选项。不要将此建议与任何模型或运行环境绑定；请使用通用名称指代该机制。

1. “我们采用哪种收入模式？” - (a) B2B 销售驱动，(b) B2B PLG／自助服务，(c) B2C／交易型，(d) 混合型。
2. “本次会话的目标是什么？它与项目目标相同吗？”冷启动和热启动时都要问；项目目标不能替代今天的目标。
3. “谁负责日常管理 CRM？谁负责批准 CRM 的变更？” - 记录双方的姓名／角色；两者通常不是同一个人。
4. “有哪些硬性限制？结果必须在哪个日期前完成？” - (a) 发布／变更冻结，(b) 季度结账或月末结账：提供日期，(c) 管理员资源有限，(d) 合规或审计窗口，(e) 无。
5. “你希望本次会话解决一次性问题，还是建立长期运行的系统？你能投入的精力上限是多少？” - (a) 一次性，只需几小时，(b) 一次性，可以投入一周，(c) 长期运行，之后每周可以投入几小时，(d) 长期运行，并且我可以获得管理员权限及跨团队批准。
6. “哪些事项已经确定，哪些仍未定？” - 各用一行说明；已确定事项不再重新讨论。

提出问题 4 和 5 是为了安排输出顺序，而不是描述项目：完成日期、一次性还是长期运行的选择，以及精力上限，决定了如何重新排列候选名单（§ 4）和例行事项（§ 7）。请在这里提问，绝不要与排名放在一起——到那时，用户已经选定了路径。请将这三项都记录在产出中，以便热启动时无需再次询问，就能重新排列。

热启动时，只问本次会话的目标问题。其他所有信息——包括影响两项排名的日期、时间跨度和精力上限——都从产出中获取。

3. 为任务选择路径

根据用户陈述的本次会话目标，与下方每项技能声明的范围进行匹配。立即处理该任务时，只选择一项技能。绝不要强行匹配：如果没有合适的技能，就明确说明并指出缺口，而不要勉强套用最接近的技能。

此表有意不排序，必须保持原样。范围是匹配条件，不是比例：任务要么属于某项技能声明的范围，要么不属于；对行排序会凭空创造不同技能之间的偏好，而它们处理的任务实际上并不重叠。排名应留到下一步的候选名单（§ 4），届时再对多个确实都能处理同一会话的技能进行比较。

技能	在以下任务中，请转到此处
mbfinotti/revops-skills@revenue-funnel	设计漏斗模型本身：包含哪些阶段、在各阶段流转的对象、计划中的转化假设、每次交接由谁负责——尚未就阶段设置达成一致，或模型本身有误，而非措辞有误
mbfinotti/revops-skills@lead-scoring	设计、验证或修正潜在客户评分模型；MQL/PQL 阈值；“销售团队拒绝我们的 MQL”
mbfinotti/revops-skills@lead-routing	将入站潜在客户分配给销售代表：规则优先级、轮流分配、区域分配规则、路由 SLA——评分已存在
mbfinotti/revops-skills@pipeline-stage-definition-audit	根据买方可验证的退出标准审计阶段定义；阶段名称以销售代表的活动命名
mbfinotti/revops-skills@sales-pipeline-hygiene	定期审计活跃销售管道快照：停滞交易、推迟成交日期、缺失字段
mbfinotti/revops-skills@sales-forecast-diagnostic	诊断现有预测为何不准确：阶段虚高、故意压低预期、汇总覆盖
mbfinotti/revops-skills@revenue-leakage	追踪记录从某个特定漏斗中悄然流失的位置，并估算可挽回的损失
mbfinotti/revops-skills@revenue-data-governance-strategy	组织级数据权威：每类对象以哪个系统为事实来源、跨团队数据契约、指标定义存放在哪里、由谁裁定“我们有两个 ARR 数字”
mbfinotti/revops-skills@crm-data-governance	字段所有权、每个字段的记录系统、数据新鲜度 SLA、字段生命周期和执行规则
mbfinotti/revops-skills@deal-desk-approval	非标准交易的折扣/让步审批矩阵和例外处理
mbfinotti/revops-skills@customer-churn-signals	发现、验证并排序领先的客户流失指标，整理为信号登记表
mbfinotti/revops-skills@customer-health-score	将现有信号合并为一个综合、加权、分档的客户健康评分
mbfinotti/revops-skills@sales-to-cs-handoff	设计销售团队到 CS 的成交后交接流程、资料包和验收步骤
mbfinotti/revops-skills@revenue-kpi-framework	设计组织级指标树：各层级负责哪些指标、指标如何向上汇总并保持一致、每个负责指标旁应配套哪些护栏反向指标
mbfinotti/revops-skills@revenue-reporting	为董事会/高管营收报告、QBR 部分或投资者更新设计指标主线和叙述
mbfinotti/revops-skills@revops-stack-rationalization	定期审查整个 GTM 工具栈的组合：按工具逐一决定保留、整合、替换或精简，并安排在续约时进行
mbfinotti/revops-skills@revops-hiring	招聘经理侧：为 RevOps 招聘设计评分卡、面试流程、工作样本和 30-60-90 天计划
mbfinotti/revops-skills@revops-career	候选人侧：RevOps 职业阶梯、面试准备、展示隐性运营工作的证据
mbfinotti/revops-skills@revops-radar	持续了解最新动态：整理值得关注的 RevOps 资讯来源、新闻简报、社群和人物
mbfinotti/revops-skills@revops-kickoff	此技能：项目启动、定期检查、“我需要哪个技能”、重新路由
有几组技能确实会在关键词上重叠。其中 4 组重叠的是层级，而非主题：

• revenue-funnel 设计 pipeline-stage-definition-audit 所审查的阶段模型。
• revenue-data-governance-strategy 指定每类对象以哪个系统为准，而 crm-data-governance 负责管理胜出系统中的字段。
• revenue-kpi-framework 设计 revenue-reporting 用来讲述的指标树。
• revops-stack-rationalization 决定究竟要使用哪些工具。

如果缺失或有误的是模型、权威映射或指标集，请路由到宏观技能；如果模型已经存在，工作是在该模型内部开展的，请路由到战术层的兄弟技能。只能根据各技能明确声明的范围进行区分，绝不能猜测某项技能“可能”涵盖什么；错误区分造成的错误路由比不区分更糟。请阅读 references/skill-routing.md，了解各技能的路由／不路由信号、边界配对区分、排序后的工作链和已命名的覆盖缺口；对于任何可能匹配两项技能的任务，路由前都要先阅读该文档。

如果任务需要的内容没有任何技能覆盖，请明确指出缺口。Collection v1 没有专门用于以下事项的技能：

• 记录去重。
• 归因建模。
• 区域设计。
• 购买前对单一工具进行评估。
• BI 仪表板构建。

请说“该集合没有适用于此项工作的技能”——绝不要承诺存在某项技能，也不要凭空编造技能。

在指出缺口前，请先确认任务是否实际属于其他 mbfinotti 技能集合，而非此集合：

• Sales-execution-tactical（冷呼叫、需求挖掘通话、异议处理、谈判让步、针对具体交易的通话辅导）或 sales-leadership planning（配额设定、薪酬方案设计、销售组织结构、ICP 定义、市场规模测算、覆盖建模）→ 建议安装 mbfinotti/sales-skills。
• 宏观渠道／合作伙伴战略（合作伙伴计划、联合销售、联盟、联盟营销／网红／推荐运营）→ 建议安装 mbfinotti/partnerships-skills。

两种情况都应将其表述为建议，绝不能说成依赖项——此集合始终可以独立使用。推荐前，请参阅 references/skill-routing.md § 同级仓库建议，了解具体的交接信号。

4. 输出格式

每次都按以下格式给出路由结果：

1. 状态摘要（仅限暖启动）——严格摘录产物中的 5 行：销售模式、记录系统、进行中的工作、最重要的待决事项、当前约束。
2. 路由——针对当前任务的一项技能（或“没有合适的技能”，并注明具体缺口）。
3. 候选清单——列出当前与此项目相关的 5 到 8 项技能，按单位投入带来的价值从高到低排序。每项占一行，同时说明它针对的瓶颈和会话成本。不要按成本低廉程度排序，也不要按路由表中的行顺序排序——请参阅下文“候选清单排序”。
4. 工作链——仅当任务确实可以分解为有序步骤时，才列出执行顺序（例如：pipeline-stage-definition-audit → sales-pipeline-hygiene → sales-forecast-diagnostic）；每个环节用一行说明交给下一环节的内容。工作链按依赖关系排序，而非按效率排序——后续环节要使用前一环节的产出，因此无法提前执行，所以给工作链排序没有意义。没有工作链时省略此项，绝不要编造执行顺序。
5. 暂不处理——列出之后会有用的技能，并明确说明解除阻碍的条件（例如：“customer-health-score——待 customer-churn-signals 提供经过验证的登记表后”）。
6. 缺口——说明当前任务需要但没有任何技能覆盖的事项。如果缺口实际属于销售执行战术工作或宏观渠道／合作伙伴战略工作，请改为推荐对应的同级仓库（mbfinotti/sales-skills 或 mbfinotti/partnerships-skills），不要只笼统说明缺口——请参阅 § 3。

候选清单排序

用户当时的问题从来不是“这些里面有哪些”，而是“我应该先运行哪一个，这次投入值不值得”。只有比率能回答这个问题。默认分类顺序，按单位投入的价值从高到低排列：

1. 诊断 - revenue-leakage、sales-forecast-diagnostic、pipeline-stage-definition-audit。无需凭感觉，就能根据已有证据明确指出下方哪些类别才是真正的问题。只需用已导出的记录开展一次工作会话；不需要管理员权限或签字，也不会造成任何需要回滚的变更。
2. 漏斗流程 - lead-scoring、lead-routing。让线索得到更快跟进，避免符合条件的线索堆在队列里无人处理。需要一次设计会话，再由拥有管理员权限的人更改 CRM 配置，并分阶段推出且准备好回滚方案；而且只适用于上线后进入的线索。
3. 常设规则 - crm-data-governance、deal-desk-approval、sales-to-cs-handoff。制定今后每次梳理和每个例外都要依据的规则：谁负责某个字段，谁可以批准让步，CS 团队必须收到什么信息。需要一次起草会话，并取得 RevOps 之外团队的签字；而规则只能通过另一次协商才能撤回。
4. 技术栈精简 - revops-stack-rationalization。根据财务部门已有的合同清单，找回重复支出的成本，并为每个工具作出明确判定。需要核对财务、采购、SSO 和费用记录，并为每项判定确定一位工具负责人；而真正的比率取决于续约日历：如果判定晚于自动续约日期，就要再等一个合同年度才能带来收益。
5. 定期梳理 - sales-pipeline-hygiene。让销售管道数据在本季度内保持可靠，而不是只在结单时才准确。每次梳理都要投入一个工作会话，还要有人逐一跟进销售代表的处理结果；这项工作永远不会结束——它是常设任务，不是一次性修复。
6. 客户健康度 - customer-churn-signals、customer-health-score。在仍有时间采取行动时，按风险高低排列客户账户，并验证其面临风险的原因。在战术类别中，这项工作所需时间最长：需要足够的续约历史记录来进行回测，在任何人信任输出结果之前设置验证期，然后再重新校准。
7. 报告 - revenue-reporting。提供高管或董事会可以据此采取行动的数字，并确认其真实可靠。需要与财务和销售团队协商并锁定定义；而在上方各类别尚未修复为其提供数据的指标之前，这项工作收益不大。
8. 宏观设计 - revenue-funnel、revenue-data-governance-strategy、revenue-kpi-framework。制定上方各类别所依托的模型：计划依据的阶段集合、按对象类别确定优先级的系统，以及各组织层级负责的指标树。在这组工作中，成本最高——需要与财务、营销和 CS 跨职能协商，作出的决策会成为全公司共同遵循的依据，而且要到下一轮规划周期之后才能见效。这里没有任何事项能仅由 RevOps 撤回。

revops-hiring、revops-career 和 revops-radar 不在这套梯级之中，也不是排在最末。它们回答的是人员问题或如何跟上最新动态的问题，而不是营收系统问题；如果这就是本次工作会话的目标，它们自然就是第 1 级，否则就根本不该列入候选清单。

各个维度给出的结论并不一致，而这正是难以抉择的地方：

• 效率：diagnosis > funnel plumbing > standing rules > stack rationalization > recurring sweeps > account health > reporting > macro design
• 价值：macro design > funnel plumbing > account health > standing rules > stack rationalization > recurring sweeps > reporting > diagnosis
• 工作量：macro design > account health > stack rationalization > standing rules > funnel plumbing > recurring sweeps == reporting > diagnosis
• 合规成本：macro design > stack rationalization > reporting > standing rules > account health > funnel plumbing > diagnosis == recurring sweeps (none)，依次为：
  • 指定唯一可信数据源并签署指标分类体系，会设定全组织范围的保留、数据驻留和读取权限条款，这些条款由财务和法务共同负责。
  • 停用某个工具会触发合同终止通知以及数据删除或导出义务，而这些义务会按供应商的时限到期。
  • 董事会或投资者数据一旦发布，就需要财务签字确认，不能再收回。
  • 字段所有权和折扣审批权限规则规定谁可以读取客户数据、谁可以批准优惠，因此两者都需要由相关负责人进行数据保护和授权审批审查。
  • 流失模型会根据行为历史分析具名客户，必须由某人负责其数据保留依据。
  • 路由规则会在负责人和区域之间转移客户记录，这在多区域 CRM 中会跨越数据驻留边界。

定期检查和报告的工作量确实相同：两者都是定期处理已持有记录和定义的会议，无需配置、无需管理员权限，也无需回滚——一个按每次检查执行，另一个按每个报告周期执行。诊断和定期检查的合规成本也同为零，原因相同：两者都只读取已有记录，且依据现行合法依据进行处理，不会向团队外发布任何内容。

宏观设计的价值最高，效率却排在最后——这是本集合中两条轴之间差距最大的一项，因为其回报要到下一个规划周期才会显现。客户健康度也呈现相同走势，只是程度稍轻：在任何续约占比较高的业务中，它的价值都领先于战术类项目，但效率仍排第六，因为必须等验证窗口结束后才能根据其输出采取行动。

这种差距正是效率排序会饿死的基础性工作。宏观设计在比值上每轮都落败——价值最高、工作量最大、回报最慢；上升一位的 crm-data-governance 也呈现相同走势，只是在较小的范围内：它的协调成本在战术类项目中最高，而且完成当周看不到任何成果。如果不将其提升优先级，率先考虑比值的排序就会永远重复低成本诊断，而每次定期检查都会反复讨论同样的例外情况，却始终没有人认可任何模型。

在设计而非调整项目时，应直接将宏观设计提升到第 1 位，并同时提升 standing rules：

• 财务和销售引用两个不同的 ARR 数字，或者没人能说清每类对象以哪个系统为准 → revenue-data-governance-strategy。
• 没有统一的阶段集合、多个销售模式共用一个阶段列表，或者阶段审计后剩下不到两个可用的基准 → revenue-funnel。
• 每个组织层级都在跟踪各自未经核对的数字，或者即将开启一个规划周期或董事会重置 → revenue-kpi-framework。
• 没人能说出某个字段由谁负责或以哪个系统为准（Q3 结果为空）、同一例外在每次检查中反复出现，或者合规或审计窗口（Q4d）已开启 → standing rules。

默认做法：从第 1 类开始列出候选项，直到诊断指出更低优先级的类别为止。每次只下移一类，且绝不能越过诊断指出缺失的类别。

将排除的类别从候选列表中删除；不要把它降到最后一位，因为被排除的技能若被放在列表底部，就会悄然重新成为工作范围。如果它有明确的解除阻塞条件，就将其移到「暂不处理」列表，并附上该条件；如果没有，则完全不提。 排序只是默认顺序，并非铁律——它会随行动内容和执行者而变化。根据访谈和检测环节刚确认的情况重新排序，并明确说明哪个回答让哪些类别发生了变化：

• B2B PLG / 自助服务（Q1b）会将 lead-scoring 提升到漏斗配置类别中的前列，作为产品合格度评分；将 deal-desk-approval 改写为促销和折扣政策，而非面向销售代表的审批矩阵；并使 revenue-funnel 的分析单位决策——潜在客户、采购小组还是工作区——成为宏观设计必须首先确定的事项。
• B2C / 交易型业务（Q1c）会将 sales-to-cs-handoff 和 deal-desk-approval 从候选清单中删除，除非存在明确的客户管理流程需要交接。
• 无人能说出日常 CRM 负责人或审批人（Q3）时，无论本次会议原本想做什么，常设规则都会升至第 1 位；如果模糊不清的问题涉及多个系统而非字段，revenue-data-governance-strategy 也会一同升至前列。以下每个类别都会将数据写入一个没有明确负责人的系统。
• 冻结变更或管理员人力有限（Q4a/c）时，本次会议的候选清单会删除漏斗配置；将其移至“暂不处理”，待管理员人力到位后再推进，同时由诊断工作占用本次会议时间。宏观设计不受这两项因素影响——它不会更改任何配置。
• 如果距离成交日期不到两周（Q4b），则提升 sales-forecast-diagnostic 和定期检查，因为二者都能在该时间窗口内发挥作用；而任何需要超过一个季度才能见效的事项——账户健康度、治理改写以及所有宏观设计——都会降至“暂不处理”，并以成交日期为解除阻塞的条件。
• 如果本季度内有续约集中期或预算周期，则将技术栈合理化提升至第 1 位；如果所有续约都在两个季度之后，则其优先级会低于定期检查，因为在此之前无法采取任何决策。
• 合规或审计窗口（Q4d）会提升常设规则、报告和 revenue-data-governance-strategy 的优先级，并延长账户健康度工作，但不会改变其所能带来的价值。
• “仅处理一次，工时有限”（Q5a）会将候选清单缩减为诊断类中的两个条目，并彻底删除宏观设计；“长期开展，且有管理员和审批人参与”（Q5d）会使常设规则、账户健康度和宏观设计排在默认位置之前。
• 已有定论的事项（Q6）会将相应技能直接从候选清单中删除——不必给已排除的事项排序。
• 检测结果也会改变类别排序：git 日志显示停滞数月时，应先做诊断，再考虑任何构建工作；如果磁盘上已有数据字典或书面的阶段定义，则删除相应的诊断和常设规则条目，并降低 revenue-funnel 的紧迫性；如果没有可读取的 CRM 导出文件，则删除诊断中依赖数据的条目，仅保留 pipeline-stage-definition-audit，因为它读取的是定义，而非记录；如果磁盘上已有合同清单或费用导出文件，则大幅减少技术栈合理化所需的工作量。

5. 上下文文档

在项目根目录创建或更新 revops-context.md——将其作为一个版本化文件，在项目使用 git 时与项目一同提交。它是唯一事实来源，能让下次启动时快速进入状态。

其字段包括：

• 收入模式。
• CRM 和记录系统相关事实。
• 阶段集合。
• 正在进行的工作。
• 已决定事项与待定事项。
• 约束条件，包括结果必须交付的日期。
• 一次性任务还是长期工作，以及投入上限。
• 利益相关者及其决策角色。
• 会话日志。

最后三个字段可让快速进入状态时重新排序候选清单和例行工作，而无需再次询问问题 4 和 5。模板、完整示例和反例请参见 references/context-artifact.md。

• 快速进入状态时：读取该文件，不要重新整理。生成 5 行状态摘要，追加一行会话日志，并且只修改发生变化的字段。
• 可选择在项目的 Agent 指令文件中补充项目的不变条件（收入模式、记录系统、硬性约束），这样后续每次会话都能继承这些信息，而无需加载此技能。
• 不要为项目搭建尚未证明有必要的工作树。只搭建本次会话所需的结构——过早搭建会将项目尚未作出的决定固化下来。
• 只有在项目确实积累了有争议的决定时，才维护决策日志；否则，“已决定事项与待定事项”字段就足够了。空洞的仪式性日志会过时，并削弱人们对该文档的信任。

每次会话结束前都要更新该文档——未写下来的会话，会让下次启动变成冷启动。

6. 记忆

如果运行环境具有持久记忆，应从上下文资料中推导记忆条目，而不是反过来。资料始终是事实来源，因为队友看不到也无法审阅记忆；以记忆为先的流程会让项目状态按用户分叉。

• 访谈结束后、§ 4 Output shape 之前，将访谈答复保存到记忆中：先把收集到的答案写入上下文资料，再从资料中推导记忆条目。绝不要直接根据答案写入记忆，也不要因为答案看似显而易见就跳过资料。

记忆只能存放在以下三个位置之一，并且这三种位置都需要同一个索引文件，列出每个条目并附上一行说明。除此之外，它们并不等同——请按以下顺序选择，优先考虑单位设置成本所带来的价值：

1. 项目 Git 仓库中的 memories/ 目录。 设置只需创建一个目录和索引文件；队友可以在平时查看项目的地方阅读这些内容，每次更改都会以可审阅的差异形式提交。缺点是需要经过下文所述的提交审批步骤，而且写入的内容会永久留存在历史记录中——要删除错误内容，就得改写历史。
2. 团队知识库。 能触达从不打开仓库的人，并且不会受单台机器影响。缺点是需要在 RevOps 之外设置访问权限，而且由于没有机制将页面与提交关联起来，内容会逐渐偏离资料。
3. 用户本地环境。 几乎无需设置，其他人也无法读取。仅用于个人项目，或不得离开本机的笔记——第二个人加入时，按用户存储就会让项目状态分叉。

• 效率：git repository > team knowledge base > local environment
• 覆盖范围：team knowledge base > git repository > local environment
• 设置成本：team knowledge base > git repository > local environment

只要项目已有 Git 仓库，默认使用该仓库；需要记忆的人不在仓库中工作时，则选择知识库。

• 重新启动时，将记忆与资料进行差异比较。两者不一致时，提出协调方案——默认以资料为准；覆盖任何一方之前都要先征求同意。
• 绝不要将以下内容写入记忆：具名个人的个人数据、CRM 记录中的客户名称或个人身份信息、合同价格和折扣底线、薪酬数据。首次写入记忆时，应说明这一排除项。
• 记忆存放在 Git 仓库时，绝不要悄悄提交。每次都要先展示差异并获得批准。

7. 例行任务

如果运行环境支持定时例行任务，应提出 2 到 4 项——创建任何任务之前，务必先以试运行形式展示给用户；每项都必须明确指定输出渠道。没有输出渠道的例行任务只会制造噪声，用户一周内就会将其静音。

例行任务的成本不在于设置，而在于每次触发所占用的注意力乘以触发频率；它的价值在于，当某项决策仍未定时，将这项决策呈现在某人面前。按这一比率从高到低为候选任务排序，并从排名最高的开始提出：

1. 关单前预测诊断 → mbfinotti/revops-skills@sales-forecast-diagnostic。每年触发几次，检查团队无论如何都会为该次会议整理的提交列表；这是唯一一种能在数字向上提交前纠正数字的例行流程。安排在关单前一周，绝不要等到关单后。
2. 每月或每季度重新执行本次启动流程。 每次触发的成本几乎为零，还能让产出物和路由表保持最新——这能防止其他所有例行流程对已经不存在的工作触发。根据 Git 日志中项目的节奏匹配执行频率。
3. 续约窗口期技术栈审查 → mbfinotti/revops-skills@revops-stack-rationalization。每年针对接下来的续约批次触发几次，审查财务本就会维护的合同清单；这是唯一一种其产出必须在供应商设定的日期前落地、而不是在团队自行选择的日期前落地的例行流程。每个续约批次都要提前一个完整的通知期安排，绝不要等到续约时再做。
4. 每周销售管道清理 → mbfinotti/revops-skills@sales-pipeline-hygiene。让每周的数字都站得住脚，而不只是关单时如此；在这些流程中，它的持续成本最高：清理需要一次会议，每项处置结果都需要销售代表采取行动。只有在有人负责跟进异常清单时才启用。
5. 每月 CRM 字段治理审查 → mbfinotti/revops-skills@crm-data-governance。每月审查字段请求和新鲜度违规情况，并要求字段负责人参与。在没有架构变更的月份，这项审查毫无收益；而在有人新增九个无人负责的字段的月份，它能省下整个季度的麻烦。
6. 每季度刷新来源 → mbfinotti/revops-skills@revops-radar。每年触发四次，成本几乎为零，带来的是信息时效性，而非实际成果。

• 效率：预测诊断 > 重新执行启动流程 > 续约技术栈审查 > 清理 > 治理审查 > 来源刷新
• 价值：清理 > 预测诊断 > 续约技术栈审查 > 治理审查 > 重新执行启动流程 > 来源刷新
• 工作量：清理 > 续约技术栈审查 > 治理审查 > 预测诊断 > 重新执行启动流程 == 来源刷新
• 合规成本：续约技术栈审查 > 治理审查 > 清理 == 预测诊断 > 重新执行启动流程 == 来源刷新（无），排序依据如下：
  • 停用工具会触发合同终止通知以及数据删除或导出义务；这两项都需要 RevOps 以外的人员签字批准，并且合同失效后便不可逆转。
  • 治理决策会改变哪些人可以读取和写入客户字段，因此需要数据保护负责人的签字批准，且只能通过另一项决策来撤销。
  • 清理和预测的产出都是列出客户和金额的交易级异常清单，因此都需要使用团队数据政策已涵盖的输出渠道，且两者都不需要审批。

重新执行启动流程和来源刷新在两个维度上并列，原因相同：两者都只需读取一次，成本几乎为零，每月或每季度触发一次，不需要阅读者以外的任何人参与，而且产出都是内部状态或公开来源，不会列出任何客户。

来源刷新是成本最低的候选项，却是最后一个安装的——这最清楚地证明了成本低和效率高是不同的排序。清理在价值上排名第一、在效率上排名第三，因为它的成本是每周开一次会，再加上由销售代表跟进其产生的每项处置结果。

默认配置：第 1–2 项，共两项例行流程。建立合同清单后，添加续约技术栈审查；有人负责跟进异常后，添加清理；架构变更成为常态后，添加治理审查。绝不超过 4 项——这个上限能保护重要的例行流程，不让它们被那些徒劳触发的流程淹没。

这个排序是默认建议，不是铁律；它会随销售模式和执行人员而变化。根据访谈重新排序：

• 两周内（Q4b）即将到来的成交日期意味着安装销售预测诊断，在本季度结束前不做其他事。
• 如果本季度内有续约集中期或预算周期，则将续约栈审查提升至第 1 级；如果某个栈的续约都在两个季度之后，则将其降至卫生检查之后。
• 管理员能力有限（Q4c），因此将治理审查频率降至每季度一次。
• CRM 负责人或签核人未明确（Q3），则将治理审查提升至卫生检查之上，因为没有规则可供检查。
• 合规或审计窗口期（Q4d）将治理审查提升至第 1 级。
• “一次性，仅需数小时”（Q5a）意味着安装一项例行任务——重新调用启动流程——而不是四项。
• 如果团队已经在进行每周管道审查，卫生检查就会重复，因此应将其降级，避免对同一批交易检查两次。

只要条件允许，就将触发时间锚定到营收日历上——季度末、月末、董事会会议日期——而不是任意日期。在添加新例行任务前，列出并清理上个季度遗留的过时任务。

如果执行环境中没有已安排的例行任务，则改为设置一条重复的日历提醒（“RevOps check-in - re-run the revops kickoff”），然后到此为止。关于试运行格式、触发时间锚定、优先使用事件触发以及清理清单，请参阅 references/routines.md。

8. 调用示例

• “为我们的销售团队启动一个新的 RevOps 项目。”
• “要修复我们的 MQL 交接，我需要哪项 revops 技能？”
• “运行我的 RevOps 检查。”
• “我该从哪里开始这里的 RevOps 工作？CRM 一团糟。”

9. 失败模式

• 强行匹配。 将最相近的技能牵强地套用到它无法覆盖的任务上，会浪费一次会话并掩盖能力缺口。请说明“没有合适的”，并指出缺口；如果任务实际属于 mbfinotti/sales-skills/mbfinotti/partnerships-skills，就指向相应资源（见 § 3）。
• 重新访谈已完成启动流程的用户。 创建该产物的目的正是避免重复提问。只询问本次会话的目标。
• 根据猜测的范围进行路由。 仅依据 references/skill-routing.md 中声明的范围进行路由；听起来似乎合理的猜测只会让路由出错，而且错得很有把握。
• 按层级而非主题进行路由。 四项宏观技能各自都与一项战术技能共享主题关键词。把“我们的阶段毫无意义”发给 revenue-funnel，或把“我们有两个 ARR 数字”发给 crm-data-governance，会让用户进入层级错误的会话——答案或许正确，却毫无用处。
• 访谈没有上限。 超过 7 个问题，启动流程就会变成用户会放弃填写的表格。通过检测来补齐信息，而不是继续提问。
• 没有输出渠道的例行任务。 它们会无声触发，随后被静音，连真正重要的那项任务也会被埋没。
• 不分优先级的简短清单。 六个看起来同等的选项会让用户凭喜好或顺序来选。应按单位投入的价值排序，并在每一项中同时指出两方面，否则用户无法做出选择。
• 把最便宜的选项放在首位。 便宜和高效的排序并不相同，只有后者才能回答“先做什么”。投入几乎为零、收益也几乎为零的例行任务只是舍入误差，并非速赢方案。
• 给路由表或链条排序。 范围用于匹配，链条用于表示依赖顺序；给任何一方套上比例都会凭空捏造并不存在的偏好。
• 将排除的技能降级，而不是删除。 如果某项技能在访谈中已被排除，却仍放在简短清单的底部，它会在两次会话后再次出现在范围内。请将其删除，或移至“暂不考虑”并注明解除限制的条件。
• 默默提交记忆。 看不到变更落地的队友就无法审核。始终先提供差异，再获取批准。
• 路由表过时。 只要技能集合发生变化——新增、重命名、移除或调整范围——就更新此技能中的表格、references/skill-routing.md、边界配对、链条和缺口清单。过时的路由器会把用户引向已不存在的技能，这比完全没有路由器还糟。

10. 通过标准

结束会话前，检查每一项。如果有任何一项未通过，请修正并重新检查——不要在未通过标准时结束会话。

1. 每项推荐技能的声明范围都确实符合所述任务——重新阅读其说明以确认。
2. 没有任何路由指向上表 20 项技能之外的名称。
3. 访谈未超出上限：冷启动时最多提问 7 个，热启动时仅询问会话目标。
4. 会话结束前，已编写或更新 revops-context.md，其中包括一条会话日志。
5. 每项建议的例行流程都以试运行形式展示，并明确指定输出渠道。
6. 短名单和例行流程集合都按单位投入的价值排序；每项都注明其针对的瓶颈及所需成本——每当访谈回答使某项内容偏离其默认位置时，都明确说明重新排序。
7. 访谈排除的每个类别都已从短名单中彻底移除，而不是留在名单末尾。
8. 路由表和任何建议的链条都不进行排序——分别按匹配测试和依赖顺序排列。

参考资料

• references/skill-routing.md - 每项技能的路由／不路由信号、边界配对辨析、有序链条、覆盖缺口，以及同级仓库（mbfinotti/sales-skills、mbfinotti/partnerships-skills）的移交信号。在对任何模糊任务进行路由前阅读。
• references/context-artifact.md - 成果文档模板、一个已完成示例和一个反例。
• references/routines.md - 试运行格式、营收日历触发条件的锚定、事件触发条件、清理检查清单。