deal-desk-approval

Deal Desk 审批

为非标准交易设计审批权限，包括折扣、自定义条款和高风险结构，并将其整理成一份规范：涵盖五项让步杠杆的审批矩阵、禁用条款类别、包含 SLA 时钟和升级机制的例外申请流程，以及先例管控。本技能仅涵盖 Deal Desk 审批：一般业务流程审批（费用、采购、人力资源、工程变更）不在范围内；遇到此类请求时，请说明这一点并停止。

Deal Desk 阈值并未标准化：流传的每个数字都来自从业者博客和咨询公司，其中有些来自内容农场。因此，本技能的核心原则是溯源：标明每个阈值的来源，并根据用户自己的交易数据推导出真正适用的阈值，而非照搬外部的“行业”数字。

基本规则

• 为每个数值阈值标注来源。绝不能把供应商的经验法则说成行业通则。
  • 已发布的从业者来源
  • 单一供应商的博客（仅供参考）
  • 根据用户自己的交易数据推导
• 绝不能将以下流传的数字陈述为事实。这些数字在各处反复出现，却没有注明出处。应予以省略，或注明它们只是流传的、未经核实的说法：
  • “75% 的毛利率底线”
  • “每 4,000 万美元 ARR 配置 1 名 Deal Desk 全职员工”
  • “中端市场 / 企业级交易的 Deal Desk 命中率分别为 35% / 70%”
  • 归因于 Stripe 的“折扣达到 30% 以上时，流失率升至 4.2 倍”
  • 归因于 Gartner 的“到 2028 年，90% 的 B2B 采购将由 AI 介入”
• “客户提出了要求”不是正当理由。申请表中权重最高的字段是拒绝该例外的影响——如果不批准例外，会有什么变化。
• 将会计和法律限制视为设计约束，并转交给财务、法务、安全或产品团队处理。绝不提供法律或会计建议。
• 在相关情况下，明确说明负面结论：定价歧视法对非市场支配地位 SaaS 供应商实行差异化折扣的限制极少（参见 references/accounting-legal-constraints.md）。不要凭空制造这种合规风险。
• 对公开的从业者指导较少的领域，应如实说明信息有限。应与用户明确设计以下事项，而不要把臆造的做法说成标准：
  • 已授予例外的续约处理方式
  • 经销商 / MSP 定价治理
  • 审批人缺席时的处理流程
• 本技能及其参考资料中的所有选项排序都只是默认建议，并非定律。具体排序会因情境和执行者而变化；提出建议前，应结合对用户情况的既有了解重新排序。
• 具体而言：
  • 只有 1 名分析师的 Deal Desk 无力维护阶梯式登记册或每季度重新推导阈值。
  • 对政策拥有否决权的销售负责人，会提高收紧任何底线的政治成本，因此应优先采用基于数据、无法轻易反驳的底线。
  • 如果续约组合中已充斥按旧条款续签的客户，那么设定到期日就意味着重新谈判，而非条款自然失效；阶梯式调整才是现实的第一步。
• 衡量投入时，应使用分析师审查工时、审批链路耗时、收紧销售团队所依赖政策的政治资本，以及可逆性——绝不能用货币金额。折扣百分比、毛利率底线和赢单率计算属于本主题，应保持原样。

访谈

设计任何方案前先提问。每条消息只问一个问题；尽可能采用选择题；已回答的问题跳过。

• GTM 模式：销售主导、PLG 加销售协助、混合模式，还是纯自助 / B2C？
• 客户细分构成和 ACV 区间——小单、典型订单和大单分别是什么样的？
• 目前由谁批准折扣，通过什么渠道：无人审批、向经理发消息、邮件往来、报价工具，还是正式审批流程？
• 可以查询哪些交易数据：按细分划分的折扣分布、按折扣区间划分的赢单率、每笔交易的利润、审批周期？
• 利润结构：边际成本接近于零（典型软件），还是 COGS 随使用量增长（AI / 推理、数据、基础设施占比高）？
• 目前会出现哪些非价格让步：付款条款、免费服务、法律条款修改、自定义 SLA、安全 / 隐私附录、路线图诉求？
• 每季度交易量是多少？其中大约有多少比例需要例外审批？
• 痛点在哪里：速度（交易卡在审批环节）还是收入流失（利润侵蚀、让步未记录），或两者兼有？
• 有哪些职能团队可以参与审批：Finance、Legal、Security、Product / Delivery？
• 续约由谁负责？此前的折扣目前是否会在不知不觉中延续？
• 季度最后几周的折扣是否会增加？
• 截止日期：这份规范必须在什么时候上线——本季度结束前、下季度，还是没有固定日期？
• 是只为赢下一笔交易，还是要打造可持续的机制：解决本季度的折扣问题，还是制定适用于之后每次续约的政策，让每位新销售都据此争取？这里的持续效应是字面意义上的——一旦让出某项条件，今后就会一直被拿来争取。
• 工作量上限：审批团队每周能投入多少分析师工时？谁有权否决收紧政策？你能在销售团队身上动用多少政治资本？

根据对最后三个问题的回答，重新排列参考方案的优先级，并明确说出每个回答如何改变了各方案的优先级：

• 严格的截止日期会提高快速见效方案的优先级——临时自动批准下限和续约到期处理都能在一天内落实；同时降低任何需要提取数据的方案的优先级。
• 以持续积累效益为目标时，即使要推迟一个季度，也应优先选择基于赢单率推导的下限，而不是任何临时设定的下限，因为临时下限会变成销售人员预期的折扣水平。
• 工作量上限较低时，应删除阶梯式续约处理方案，因为它需要持续跟踪每个账户；同时减少例外审批流程中方案材料整理的频率，改为更少但规模更大的批次。

工作流

1. 运行访谈；收集规范所依赖的每一项答案。

2. 确认范围边界：本审批台负责非标准交易。如果请求实际涉及定价策略（标价、打包、层级）或非交易审批流程，请说明并转交其他流程。

3. 根据 references/approval-matrix-design.md 确定五项受管控杠杆：

   • 价格/折扣
   • 付款条款和计费
   • 服务与交付承诺
   • 合同风险
   • 安全/隐私承诺

   只管控价格的矩阵会把让步推到其他四项杠杆上。

4. 根据同一份参考资料设计矩阵：

   • 折扣百分比以外的维度：交易规模、细分市场、销售模式、期限、产品线、利润影响。
   • 设 3–4 个层级，最低层级设自动批准门槛。
   • 每个层级下方都设政策利润底线。
   • 无论审批人是谁都禁止的类别：最惠国待遇/最优价格、无期限的价格锁定、免责范围以外的无限责任、未经批准的路线图承诺。

5. 使用 references/exception-taxonomy.md 将每种例外映射到所属职能部门及升级触发条件。

6. 根据 references/intake-routing-and-precedent.md 设计受理流程、路由通道、两个 SLA 计时机制、SLA 超时升级、审批人缺席时的委派，以及季末高峰模式。完整性标准决定 SLA 计时是否启动：资料不完整的请求会被退回并附上结构化说明，不会进入队列。

7. 根据同一份参考资料设计先例管控：

   • 例外登记表、每项已批准例外的到期时间、模式到政策的审查，以及针对每类例外的续期处理方式。
   • 默认采用到期收回：它能以近乎为零的持续投入收回全部让步，且可逆。只有在价格恢复原状已导致该细分市场客户流失时，才采用逐步上调。
   • 默许延续不属于可选方案。
   • 公开指引确实非常有限：与用户共同决定，并记录为内部政策。

8. 根据 references/accounting-legal-constraints.md 将会计和法律约束编码为路由规则：哪些交易结构必须在任何层级批准前提交财务或法务，以及原因。

9. 根据下方章节明确处理 B2B 和 B2C——采用非对称处理，而非强行追求对称。

10. 按该参考资料中的优先顺序校准阈值：

    • 在有数据的情况下，根据各折扣区间的成交率推导自动批准门槛。
    • 成交率数据不足时，以用户自身折扣分布的某个百分位数作为依据。
    • 示意性阶梯仅可作为一个周期的临时占位方案，绝不能作为正式政策发布。

    预计需要约两个季度的数据才能判断出规律（RevOps Co-op）；如果目前还没有这类数据，请在交付内容中说明。

11. 按照输出格式逐节输出规范，供用户验证；以 references/worked-examples.md 中相匹配的已完成示例为依据。

12. 附上 KPI 和下方的通过门槛，并持续迭代，直到满足通过条件。

13. 如果你的运行环境支持持久记忆，请记住已确定的层级、底线、禁止清单和续期处理方式，以便后续重新校准时能从这些内容开始，而无需重新访谈。

B2B 和 B2C

人工交易审批是 B2B／企业级模式的产物：B2B 按客户定价——报价并协商；B2C 按产品定价——公开标价并直接购买。B2C 不存在交易审批机制；不要凭空创造一个。

• PLG、自助服务和高交易量的事务型 SMB：相应机制是由规则驱动的折扣政策——自动化促销引擎、公开的折扣档位、优惠券管理规则，以及条款中公布的例外规则，不设人工审批链。只有在交易金额超过销售辅助介入的门槛时，才由人工介入。
• B2C 电商：促销／降价日历管理、优惠券发放与叠加规则，以及公开的价格调整政策，发挥着交易审批机制的作用。
• 对这些模式都同样适用的是：例外导致价格侵蚀的动态、缺乏文档记录的先例这一根本原因，以及定义档位、记录每个例外并监控折扣逐渐扩大这一管理纪律。

应将这一对比表述为对两种销售模式中运作机制如何相通的推理，而不是已记录的行业结论。

输出格式

每项工作都应以此成果交付。每条阈值都必须标注来源；每位审批人都必须指定一名具名代理人。

DEAL DESK APPROVAL SPEC - <company>, <date>
Scope        : what counts as non-standard; what this desk explicitly does not govern
Levers       : how each of the five levers is governed (price, payment, services, risk, security)
Matrix       : dimensions x tiers, approver + delegate per tier, auto-approve floor,
               policy margin floor (or cost floor for usage-scaling COGS), fences per segment
Prohibited   : terms no tier approves without an explicit give-get trade
Intake       : required fields (impact-of-denial weighted highest), completeness standard,
               bounce protocol for incomplete requests
Routing      : fast / complex / exception lanes, with lane criteria and the target volume
               share per lane - bulk in fast; exception lane forced by structure, not size
SLAs         : response clock + decision clock per lane (business hours, complete-submission
               to recorded-and-communicated decision), 50/80/100 elapsed-SLA escalation,
               delegation and quarter-end peak mode
Precedent    : register fields, expiry on every exception, pattern-to-policy cadence,
               renewal treatment per exception class (sunset by default; step-up only
               where snap-back churn is evidenced; no silent grandfathering)
Constraints  : accounting/legal routing table - which structures reach Finance/Legal and why
Calibration  : data source per threshold, provenance tags, recalibration cadence
KPIs         : five-KPI scoreboard + measurement definitions

KPI

• 共同跟踪这份包含五项 KPI 的记分卡，绝不孤立看待任何一项（Umbrex）：

  • 周期时间
  • 赢单率
  • 折扣率
  • 利润率
  • 收入损失

  只看速度会快速批准糟糕的交易；只看利润率则会造成僵局，销售代表也会绕过审批机制。

• 以提交完整材料至决策记录并传达的时间为周期时间，按工作小时计；报告中位数和第 90 百分位数，不要报告均值——p90 长尾会助长绕过审批的行为。

• 还要关注：

  • 按类型划分的例外率：识别模式并触发政策调整。
  • 事后发现率：提案发出后才发现非标准条款，说明受理环节存在缺口。
  • 价格实现率：实际成交价／标价（SBI Growth）。
  • 期末折扣激增情况。

通过阈值

只有满足所有完整性条件后，规范才算通过，之后再按校准循环迭代。

完整性——持续迭代规范，直至满足每一项：

• 五项杠杆均有管理规则；存在禁止事项类别；利润率（或成本）底线已有明确规定，且不依赖审批人。
• 每个层级都指定了审批人和代理人；为每条审批通道定义两种 SLA 时钟和 50／80／100 升级机制。
• 每个数值阈值都标注了来源，且没有将任何已警示应避免的数字当作事实。
• 登记表中包含到期日期，并已决定和记录续期处理方式。

校准——按例外审查周期迭代矩阵，直至同时满足以下两项（RevOps Co-op 启发式规则）：

• 审批几乎即时完成：需要审批的事项过多，应提高自动批准门槛。
• 决策时间过长（p90 超出例外审批通道的 SLA）：层级设置有误，应重新划分。
• 不得有持续超过两个审查周期的重复例外：应将其纳入标准政策，或明确拒绝，同时确保记分卡上的折扣率和利润率保持稳定。

常见失效模式

缺陷	后果	修正
矩阵只管折扣比例	优惠转移到付款条款、服务、法律和安全方面	在同一矩阵中管理全部五个杠杆
由一位高管担任最高审批人	交易停滞数日，买方采购流程却在继续推进	为每位审批人指定代理人，并设置 50/80/100 级升级机制
审批逻辑散落在聊天记录和电子表格中	上下文无法传递；季末时流程中断；没有审计记录	在记录系统中进行路由和记录，并记录每项决策
缺少完整性准入门槛	不完整的申请消耗时限；反复返工	必填字段齐全后才启动 SLA 计时；不完整申请按结构化流程退回
“一次性例外”没有到期时间	客户次年会以此为先例	为每项例外设定时限并登记；确定续期处理方式
季末压力下放宽规则	期末折扣激增；在最糟糕的时机树立先例	高峰模式增加产能并设置截止时间，但绝不放宽规则
只报告平均周期时间	尾部延迟问题被掩盖；销售代表绕过审批团队	报告中位数和 p90，从完整提交到决策传达的时长
将成本底线视为约束性底线	软件 COGS 接近于零，导致成本底线毫无意义；毛利率仍会下降	政策规定的毛利率底线——但对于 COGS 随用量变化的产品，以成本为准
每笔交易都标为“战略性”以证明优惠合理	如果 40% 的交易都是战略性交易，那就没有一笔算战略性交易	将战略性交易（经高管批准并记录）与战术性档位区分开来

调用示例

• “我们的 AE 想打多少折就打多少折，而且所有事项都通过电子邮件提交给 CFO——请设计一套包含分级和 SLA 的实际折扣审批链。”
• “我们的交易中位 ACV 为 $30K，正在正式建立交易审批团队。请建立审批矩阵，并制定非标准条款的例外处理流程，例如 net-90、自定义 SLA 和安全附录。”
• “每到季末折扣就激增，去年那些‘一次性’例外在续约时又全都回来了。请完善我们的例外处理和先例管控。”

参考资料

• references/approval-matrix-design.md - 矩阵维度、档位、底线、禁止类别和阈值校准
• references/exception-taxonomy.md - 例外类型及其流转至负责职能部门的方式
• references/intake-routing-and-precedent.md - 申请字段、处理通道、SLA、升级机制和例外登记表
• references/accounting-legal-constraints.md - 收入确认和法律流转规则
• references/worked-examples.md - B2B 规范、PLG/B2C 对应示例和反面示例
• 查看 mbfinotti/revops-skills@revenue-leakage，以检测毛利率侵蚀
• 查看 mbfinotti/revops-skills@sales-pipeline-hygiene，了解阶段纪律和销售管道集成
• 查看 mbfinotti/revops-skills@sales-forecast-diagnostic，了解期末交易延迟