revops-hiring

RevOps 招聘

构建招聘经理招聘 RevOps 或 Sales Ops 人员所需的材料包：角色定义、面试流程、评分表、工作样本和上手计划。

框架采用 Geoff Smart 和 Randy Street 的 Who: The A Method for Hiring 中的评分表传统——使命、3-8 项按优先级排序且可衡量的成果，然后是能力项。它适用于从业者实际认可的几种典型角色：

• RevOps Co-op 的五条职业路径：分析师、系统管理员、赋能、交易台、项目经理。
• 为招聘精简为三种类型：系统、分析师、策略师。

在准备任何材料包之前，必须先做出两个决定：

• 是否要发布招聘需求，而不是聘用兼职运营人员或委托范围明确的代理机构项目。
• 选择哪种典型角色——大多数 RevOps 招聘失败源于角色类型不匹配，而非能力不足。

这里只涵盖招聘方的工作。不负责寻找候选人、发布职位或跟踪申请人；它会报告带有来源和日期的已发布薪酬范围，作为范围界定的输入——但绝不会撰写录用信，也不提供法律或 HR 合规建议；这些事项需要 HR／法律审核。

候选人一侧——准备并成功应聘 RevOps 职位——是其镜像姊妹项目 mbfinotti/revops-skills@revops-career。客户成交后（closed-won）的入职引导属于 mbfinotti/revops-skills@sales-to-cs-handoff，这是完全不同的工作。

面试

先提问，再设计方案。每条消息只问一个问题；尽可能提供多选答案。已回答的问题跳过。

• 公司处于什么发展阶段，规模多大？(a) A 轮前／员工不足 25 人，(b) A-B 轮／25-150 人，(c) C 轮及以上／150 人以上，(d) 非风险投资发展路线——请描述。
• GTM 团队是什么样的——销售代表、营销人员和 CS 人员大约各有多少？
• 这是首位专职运营人员，还是加入现有运营团队？如果团队已存在：团队里有哪些人，各自负责什么？
• 是什么痛点促使你招聘？(a) 行政事务和工单积压——人手不足，(b) 没人信任报表或预测——分析能力，(c) 跨团队边界的问题——流程与协作，(d) 几种情况都有。
• 技术栈的成熟度如何？(a) CRM 几乎未配置，(b) CRM 和营销自动化已在运行但较混乱，(c) 包含数据仓库和 BI 在内的完整 GTM 技术栈。
• 这项招聘的预算和级别是什么——如果市场表明预算过低，这个数字是否可以协商？
• 这位新员工将向谁汇报，谁是执行层赞助人？
• 面试小组有哪些人，实际能安排多少轮面试？
• 必须在何时解决这个问题？(a) 季度内有明确日期的事件迫使尽快解决——董事会会议、配额重置、迁移，(b) 本财年内，(c) 时间不限。季度内的硬性截止日期会排除资深内部招聘方案：仅招聘搜索就会超过期限。
• 你想要一次性修复，还是可持续累积的能力？一次性需求倾向于兼职人员和代理机构；持续累积的职责则倾向于内部招聘，而且只有这种需求足以证明头两个季度的投入合理。
• 你的投入上限是多少——每周能投入多少小时的经理时间、面试小组成员是否有空、编制是否已获批，以及如果进展不顺，能否在一个月内撤销这项安排？冻结招聘或编制未获批会直接排除招聘需求方案；对不可逆性的容忍度较低，则更适合合同方案。

工作流

1. 进行访谈；在设计任何内容之前，收集所有答案。
2. 根据 references/role-archetypes-and-leveling.md 中的排序画像选择测试，决定是否要发布职位需求。按你每小时投入所带来的价值排序：兼职运营人员 > 范围明确的代理项目 > 内部专家 > 内部战略人员。内部岗位则根据痛点分流：报告可信度问题交给分析师，管理工作积压交给系统专家，跨部门流程问题交给战略人员；若痛点仅限于一个职能，则完全不归 RevOps 负责，而应交给 Sales、Marketing 或 CS Ops。删除访谈答案排除的选项，而非把它们排在最后，并说明删除了哪些选项。根据你对这家公司的现有了解重新排序其余选项：公司是否已聘用代理机构、是否有内部招聘人员、这是第五个运营岗位还是第一个。只有最终选择内部岗位，才适用此工作流；随后先以书面形式明确岗位类型和级别，再起草其他内容。
3. 设置职位需求的准入门槛：以书面形式确定汇报关系和 VP 或 C 级高管赞助人——从业者称，赞助是首聘成功的最大预测因素——并参照同一文档中公布的薪酬区间，对预算进行压力测试。引用每个薪酬区间，并注明来源和日期。RevOps Co-op 的警告适用：“宁可争取更多预算来招聘经验丰富的专业人员，也不要只用现有预算，结果让新员工失败。”
4. 以记分卡形式撰写岗位定义：一句话使命、3-8 项有日期且客观可观察的排序成果，然后列出胜任能力，并将必备条件整理为要求矩阵。即使只是粗略勾勒，也要说明“优秀”是什么样子；RevOps Co-op：“你的工作是勾勒出‘优秀’可能是什么样子——哪怕只是在餐巾纸上画个草图。”按与级别相称的经验评分——资历过高和资历不足都应得低分——只有在公司已统一采用某个平台、且岗位类型为系统专家时，才将供应商认证设为必备条件。要求矩阵规则：
   • 围绕问题撰写，而非围绕工具。
   • 必备条件最多 5-7 项，权重总和为 100%。
   • 将加分项作为额外奖励分保留。
   • 将淘汰条件单独列为检查清单，不要作为扣分项纳入评分。
5. 定义 4-6 项胜任能力，并根据 references/competencies-and-question-bank.md 建立问题库：每项胜任能力设置 2-3 个行为问题和 1-2 个情境问题，并附追问；将领域常见失败模式设计为难以作假的探查问题，并用红/绿回答示例作为评分锚点。
6. 用阶段表规划面试流程，列出阶段、面试官和评估的胜任能力；每项胜任能力只能由一个阶段负责，并为每位面试小组成员分配明确职责。保持精简：RevOps Co-op CEO Matthew Volm 主张采用时长约两小时的居家作业，并且“最多安排 3 轮面试”。
7. 在任何人开始面试之前，确定评分规范。编写带有锚定评分等级的量表，并描述每个锚点分值在此岗位上的具体行为表现——禁止只给出一个数字——同时要求每份提交的评分都引用证据、原话或具体示例。面试官先独立评分，再进行讨论；淘汰信号应单独记录，不计入分数；推荐结论应根据置信度加权，而不能只看匹配度：“数据不足”是有效结论，任何单项评分都不能凌驾于整个面试流程之上。
8. 根据 references/work-sample-design.md 设计工作样本。根据其中的排序菜单选择形式——按每小时投入所带来的信号强度排序为 现场模拟 > 付费居家作业 > 无偿居家作业。无偿作业这一项既会导致最优秀的候选人放弃，也会带来实际的合规成本；应直接删除八小时的无偿练习，而非将其降级。然后设计：
   • 一份看起来像真实缺陷、而不是项目的题目。
   • 严格的时间上限。
   • 在收到第一份提交前就写好的评分标准。
   • 复盘计划——复盘所提供的信号比产出物本身更强。
9. 根据 references/ramp-plan-template.md 制定上手计划：入职前、第 1 天、第 1 周，然后是 30/60/90 天阶段。按资历和岗位类型设置分支，纳入第一周的权限清单、工单队列保护措施、坦诚的里程碑预期，以及结尾的观察重点。
10. 按章节输出招聘资料包（见下一节），逐节供用户验证，并以 references/worked-examples.md 中相匹配的示例为依据。
11. 持续迭代资料包，直到“通过门槛”中的每项要求都满足。
12. 如果你的运行框架支持持久化记忆，请记住已获批准的资料包——岗位类型、级别、胜任能力、阶段图、门槛和上手计划分支——这样筛选流程和之后的上手安排就能以此为依据，而无需重新访谈。如果不支持记忆，请告知用户将资料包文档保留为后续运行的常驻输入。

招聘资料包

每次招聘都应交付这份资料。完整示例见 references/worked-examples.md。

HIRING PACKET - <company>, <role>, <date>, v<n>
Profile choice  : ranked options with the ordering stated | options deleted + why | recommendation
Role definition : archetype + level | mission | 3-8 ranked outcomes with dates | competencies
Requirements    : must-haves weighted to 100% | nice-to-haves as bonus | disqualifier checklist
Comp input      : published band quoted with source + date | flag: offer terms need HR/legal
Stage map       : stage -> interviewer -> competencies assessed (each owned by exactly one stage)
Question bank   : per competency - behavioral + situational + follow-up probes | red/green anchors
Scorecard       : anchored scale per competency | cited evidence per score | confidence rating
Work sample     : prompt + time cap + paid/unpaid call | rubric (written first) | debrief agenda
Debrief rules   : independent pre-scores | disqualifiers separate | confidence-weighted decision
Ramp plan       : pre-start, Day 1, Week 1, 30/60/90 | seniority + archetype branches |
                  week-one access list | watch areas

B2B 与 B2C

不同细分市场的招聘流程完全相同：评分卡、面试流程、工作样本、入职成长计划；有人问及时，就明确说明这一点。真正变化的是各项能力的权重、岗位负责的指标、候选人必须熟悉的技术栈，以及面试考察的内容。

• B2B 企业级：岗位负责管道覆盖率、赢单率、交易速度、净收入留存率、预测准确度、区域和配额；技术栈包括 CRM、销售互动、收入智能、CPQ——应重点考察从报价到收款流程的深度、区域与佣金设计，以及对预测节奏的判断。
• B2C 与电子商务：岗位负责 CAC、转化率、平均订单价值、购买频率、客户流失率，以及按群组模型计算的 LTV。
• PLG：激活、产品合格线索、免费转付费、扩张信号——RevOps Co-op 指出，在 PLG 中，“把漏斗阶段当作衡量团队效能的替代指标[会变得]毫无意义”。

以下是 PLG 领域供应商报告中的参考基准，仅供方向性参考，不具权威性：

• 激活：7-14 天内完成激活的注册用户占 25-40%。
• 免费转付费：免费增值模式约为 2-5%，免费试用模式约为 15-25%。
• PQL 用户的转化率约为其他用户的 3 倍。
• 实际使用 PQL 的 PLG 公司仅约占四分之一。

因此，PLG 和消费者业务的 RevOps 岗位需要具备接近分析工程的技能——扎实的 SQL 能力、数据仓库实操经验，以及转换层经验；面试应重点考察对产品信号的熟悉程度，而不是区域设计能力。

• Deal desk 接近 B2B 专属的岗位类型；消费者订阅业务很少设立这种岗位。
• 其计费和支付复杂度在 B2B 中没有对应情况。
• 纯 B2C 订阅业务通常缺少扩张路径，因此净留存率无法像 B2B 那样超过 100%。

通过门槛

反复迭代，直至每一项都满足。以下各项要么源自从业者指导，要么是本技能自身的约定。

• 在起草岗位定义前，须以书面形式明确岗位类型和级别，并确定汇报关系和高管赞助人——没有赞助人就不启动招聘需求（有来源）。
• 岗位定义须写明问题和成果，而非工具；必备条件不得超过 5-7 项（有来源）。
• 设置 4-6 项能力；每个问题必须且只能对应一项能力；每项能力必须且只能由一个面试阶段负责考察（有来源）。
• 每个评分锚点都须包含针对该岗位的行为描述，每份提交的评分都须引用原话或具体示例（有来源）；只给一个数字不符合要求。
• 面试流程最多进行 3 轮，另加一次约两小时的带回家作业；若不付费，最长不得超过三小时（有来源）。
• 必须在收到第一份提交内容前制定工作样本评分细则；其数值分值遵循本技能自身的约定。
• 入职成长计划须同时根据资历和岗位类型设置不同路径，以关注事项收尾，并设定诚实的里程碑时间线——60-90 天内取得早期成果，收入层面的成果则需 12 个月以上（有来源）。
• 资料包中的每项薪酬数字都须注明来源和日期；不得编造薪酬区间，也不得提供来源未涵盖地区的数字（自行设定）。
• 资料包提供的每个选项菜单——候选人画像选择、工作样本形式、问题选择——都须明确说明排序，删除排除的选项，而非将其降级，并说明一项基于本公司实际情况重新排序的结果（自行设定）。

常见失败模式

按每项预防措施能消除表中多少问题排序，性价比从高到低：已落实的高管赞助人 > 职责类型诊断 > 阶段图谱与独立评分 > 有保障的入职爬坡日程。前两项各只需一次沟通，并能在职位需求开放前预防前四类问题；其余是面试流程和入职培训方面的规范，只有在落实前两项后才开始发挥作用。

症状	根本原因	解决方法
招来的人能力出众，CRM 更整洁了，预测却仍不稳定	职责类型不匹配——为流程问题招来了系统管理员	重新进行人才画像选择测试；问题“从来不是软件，而是收入运营方式”
新员工开头几个月都在开会，然后辞职	职责不明确——三位高管都认为自己负责这次招聘	在职位需求开放前，写明职责章程、预期成果和唯一的赞助人
每项改进都变成一场谈判	没有高管赞助人	在 VP 或 C 级赞助人书面承诺之前，不要开放职位需求
入职前 90 天都耗在工单队列上	没有受保障的日程或明确职责	明确保护爬坡时间；将工单队列处理列为指定的关注领域
所有面试官都问同样的问题	没有阶段图谱	每项能力对应一个阶段；为每位面试官分配一个面试领域
复盘很快就跟着第一个语气坚定的人达成一致	讨论前就共享了评分	讨论前独立评分；复盘时间应重点用于分数不一致之处
优秀候选人因缺少某项认证而被拒	将供应商认证设为必备条件	认证是基本门槛，而非预测指标——除非是标准化平台上的系统类职责，否则仅作为加分项
面试时表现出色，实际工作却能力薄弱	面试流程奖励表达流畅，而非工作方法	使用工作样题和红／绿方法锚点；较弱与较强的回答差异在于方法，而非信心
最优秀的候选人拒绝完成带回家的测试	耗时过长的无偿练习会筛出有充足空闲时间的人	将时长限制在 2-3 小时，考虑付费，并将评估重点转移到复盘环节
优秀的新员工因六个月内没有带来收入影响而被辞退	时间预期不切实际	一开始就设定合理的里程碑——“任何承诺 30 天内带来收入影响的人，都是在向你兜售什么东西”

调用示例

• “我们是一家有 40 人的 A 轮 B2B SaaS 公司，CRM 一团糟，也没人相信收入预测——帮我明确需求并招聘第一位 RevOps 人员。”
• “我在现有的五人运营团队中有一个 RevOps 分析师职位需求待招——帮我设计面试流程、评分表，以及真正能考察实际工作的带回家测试。”
• “我们的新任收入运营总监将在三周后入职——帮我撰写 30-60-90 天爬坡计划。”

参考资料

• 诊断职位类型、确定级别、界定首位员工与第 N 位员工的招聘范围，或根据公开薪资区间评估预算时，请阅读 references/role-archetypes-and-leveling.md。
• 定义能力项、撰写问题与追问，或构建带锚点的评分卡和要求矩阵时，请阅读 references/competencies-and-question-bank.md。
• 设计练习时，请阅读 references/work-sample-design.md，了解所需时间与付费规范、合成数据集的构建、评分标准和复盘。
• 编写入职成长计划时，请阅读 references/ramp-plan-template.md，了解从入职前到 90 天的框架，以及针对资历和职位类型的分支与关注事项。
• 设计交付内容时，请阅读 references/worked-examples.md，其中包含一套完整的正面示例材料，以及一个列明成本的反面示例。
• 查看 mbfinotti/revops-skills@revops-career，了解候选人视角的对应内容——如何准备、定位自己并在 RevOps 职位上取得进展。
• 查看 mbfinotti/revops-skills@sales-to-cs-handoff，了解如何在交易成功后为客户办理入职——这是本技能不涉及的另一项工作。
• 查看 mbfinotti/revops-skills@lead-scoring、mbfinotti/revops-skills@sales-forecast-diagnostic 和 mbfinotti/revops-skills@pipeline-stage-definition-audit，深入了解面试追问所涉及的领域——这些技能要解决的失败模式，正是面试中考察候选人的内容。