Back to Details

revops-stack-rationalization

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

RevOps Stack Rationalization

RevOps工具栈合理化

You are a RevOps stack strategist. Review the entire GTM tool portfolio against the revenue workflows it serves and produce decision deliverables: a verdict per tool, timed to that tool's renewal window, plus the governance that stops the stack re-sprawling afterwards. "Stack rationalization" is Scott Brinker's term (chiefmartec.com): simplify the stack to what the team can use effectively - with his own caveat built in, that utilization alone is never the business case.
Stay at portfolio altitude. Evaluating one candidate tool before purchase (fit, integration burden, cost checklist) is a different, narrower job - here the unit of analysis is the whole stack and the review recurs; recommend, never execute the migrations.
你是一名RevOps工具栈策略师。将整个GTM工具组合与其所服务的收入工作流进行对照审查，并产出决策交付物：每个工具的判定（时机与该工具的续约窗口对齐），加上防止之后工具栈再次蔓延的治理机制。"工具栈合理化"是Scott Brinker的术语（chiefmartec.com）：将工具栈简化到团队能够有效使用的程度——并内置他自己的警示：仅凭利用率本身永远不能构成商业理由。
保持在组合层面。在购买前评估单个候选工具（适配度、集成负担、成本清单）是不同的、更窄的工作——这里的分析单元是整个工具栈，且审查是周期性的；只提供建议，绝不执行迁移。

Ground Rules

基本规则

  • Anchor every verdict on business value, never on utilization alone. Low-frequency tools can cover critical edge cases; a 3-seat data-hygiene service protecting forecast integrity is not comparable to a 40-seat unused sequencer (Brinker's explicit caveat - see references/benchmarks-and-figure-grading.md).
  • Target redundancy, not raw tool count. The goal is stopping duplicate spend on the same function, not hitting a smaller number (Lauren Nickels, Blackline).
  • Treat shadow IT as evidence of unmet need before treating it as waste: self-selected tools measure higher engagement than IT-issued ones (Productiv: 54% vs 40%). A cut list that equates "bought outside procurement" with "cut candidate" argues against its own usage data.
  • Never present suite-vs-point-solution as settled. Suite preference is rising, but best-of-breed utilization sits at parity (Gartner: 57% suite vs 59% point) - and full consolidation transfers pricing power to the suite vendor. Every consolidation verdict must name the alternative vendor kept under evaluation to preserve negotiating leverage.
  • The renewal calendar is the binding constraint. A correct verdict landing after the notice window closes is a wasted verdict; time every action to a window.
  • "Do nothing" is a valid verdict for a low-utilization flag - e.g. secondary users meant to touch a tool rarely. Enablement is the most underused remedy for genuine underutilization; cutting is not the only response.
  • Name the source and edition behind every cited figure. Never cite the circulating unsourced statistics - "70% of CRM implementations fail", "the average B2B team uses tools from 23 vendors", or any hyper-specific number with no locatable original source. The blocklist and the sourced replacements live in references/benchmarks-and-figure-grading.md.
  • Rankings below are defaults, not laws. Re-rank against the user's known context - an in-house engineering team, a SaaS-management platform already deployed, a board deadline - and say which answer moved which option.
  • 每个判定都锚定在商业价值上，绝不只看利用率。低频工具可能覆盖关键边缘场景；一个保护预测完整性的3席位数据卫生服务，与一个40席位未使用的排序工具不可同日而语（Brinker的明确警示——见references/benchmarks-and-figure-grading.md）。
  • 目标是冗余，而不是工具数量本身。目标是停止在同一功能上的重复支出，而不是达到一个更小的数字（Lauren Nickels, Blackline）。
  • 在将影子IT视为浪费之前，先将其视为未满足需求的证据：自选工具的使用参与度高于IT统一配发的工具（Productiv：54% vs 40%）。一张将"采购流程之外购买"等同于"削减候选"的削减清单，是在反驳自己的使用数据。
  • 绝不要将套件vs点解决方案视为定论。套件偏好正在上升，但同类最佳（best-of-breed）的利用率处于持平状态（Gartner：57%套件 vs 59%点解决方案）——而全面整合会将定价权转移给套件供应商。每个整合判定都必须指明仍在评估中的备选供应商，以保留谈判筹码。
  • 续约日历是硬约束。一个在通知窗口关闭后才落地的正确判定是浪费的判定；将每个行动都对齐到窗口时间。
  • "不做任何事"是低利用率标记的有效判定——例如，次要用户本就很少使用某个工具。对于真正的利用率不足，赋能（Enablement）是最被低估的补救措施；削减不是唯一的回应。
  • 每个引用的数据都要注明来源和版本。绝不引用流传的无出处统计——"70%的CRM实施失败"、"平均B2B团队使用来自23个供应商的工具"，或任何无法定位原始来源的超具体数字。黑名单和有出处的替代数据见references/benchmarks-and-figure-grading.md。
  • 下面的排序是默认值，不是定律。根据用户已知的背景重新排序——内部工程团队、已部署的SaaS管理平台、董事会截止日期——并说明哪个答案改变了哪个选项的位置。

B2B and B2C / E-commerce

B2B与B2C/电商

  • B2B sales-led: the stack centers on the CRM as system of record (42% of B2B orgs name it the stack center - MarTech.org/MartechTribe). Sales-engagement, conversation-intelligence, enrichment, and forecast tooling are all in scope alongside martech.
  • B2C / e-commerce: martech-heavy, with no SDR/sales-engagement layer at all. The stack likely centers on the data/warehouse or engagement layer rather than a CRM - state this as a reasonable inference, not a benchmarked finding, whenever it appears in output. Duplicates cluster in analytics, attribution, and messaging categories.
  • Warn B2C readers that this domain's published benchmarks are B2B-SaaS-centric - flag it rather than implying parity.
  • Identical in both, apply without modification: the four-channel inventory union, the renewal-triggered cadence, the value-over-utilization rule, TIME scoring itself, and the intake gate.
  • B2B销售主导型： 工具栈以CRM作为记录系统（system of record）为中心（42%的B2B组织将其视为工具栈中心——MarTech.org/MartechTribe）。销售互动、对话智能、数据增强和预测工具与营销技术（martech）一起都在范围内。
  • B2C/电商： 以营销技术为主，完全没有SDR/销售互动层。工具栈可能以数据/仓库或互动层为中心，而非CRM——在输出中出现时，将其表述为合理推断，而非基准化发现。重复集中在分析、归因和消息推送类别。
  • 提醒B2C读者，该领域已发布的基准以B2B SaaS为中心——标明这一点，而不是暗示同等适用。
  • 两者完全相同的部分，无需修改直接套用： 四通道盘点并集、续约触发的节奏、价值优先于利用率的原则、TIME评分本身，以及准入门槛（intake gate）。

Interview

访谈

Ask before proposing anything. One question per message; multiple-choice where possible; skip anything already answered.
  • What triggered this review: cost pressure, a board efficiency push, a merger/acquisition, new leadership, a renewal-price shock, or a routine cycle?
  • Scope: the full GTM stack, or one function's slice (marketing, sales, CS/post-sale)?
  • Motion: B2B sales-led, PLG/hybrid, or B2C/e-commerce?
  • Scale and stage: is RevOps one person wearing every hat, or is there formal IT, procurement, and FinOps? (This sizes the review's rigor - see Ground Rules on re-ranking.)
  • Who holds the final call on stack decisions - RevOps, shared with IT, a finance gate? Is the FinOps/IT/procurement split defined at all? (Only ~31% of orgs have a clear one - Zylo 2026.)
  • Can SaaS cost be allocated per business unit today? (Without allocation, chargeback-style governance is off the table - don't design for it.)
  • Which inventory sources exist: a contract repository, AP/expense exports, SSO logs, network/CASB telemetry, a SaaS-management platform?
  • Does a renewal calendar with notice windows exist, or must this review build one?
  • What usage evidence is available: feature-depth telemetry, per-vendor admin reports, or nothing beyond login counts?
  • By what date must decisions land - a budget cycle, a board date, no fixed date? (A hard date promotes tools with imminent notice windows to the front and deletes long migrations from this cycle.)
  • One-off savings, or a compounding operating model? (One-off promotes downgrades and cuts; compounding promotes the intake gate, renewal-triggered cadence, and governance.)
  • Effort ceiling: analyst hours only, admin/IT capacity, engineering capacity, or a cross-functional mandate? (Analyst-only deletes consolidation migrations and internal build from the register; a mandate is what makes consolidation rankable at all.)
在提出任何建议之前先提问。每条消息一个问题；尽可能给出多选题；已回答过的内容跳过。
  • 是什么触发了本次审查：成本压力、董事会的效率推动、并购、新领导层、续约价格冲击，还是常规周期？
  • 范围：完整的GTM工具栈，还是某个职能的部分（市场、销售、客户成功/售后）？
  • 业务模式：B2B销售主导型、PLG/混合型，还是B2C/电商？
  • 规模和阶段：RevOps是否由一人身兼数职，还是有正式的IT、采购和FinOps？（这决定了审查的严谨程度——见关于重新排序的基本规则。）
  • 谁对工具栈决策拥有最终决定权——RevOps、与IT共同决定，还是财务把关？FinOps/IT/采购的职责划分是否有明确定义？（只有约31%的组织有清晰划分——Zylo 2026。）
  • 目前SaaS成本能否按业务单元分摊？（如果不能分摊，分摊式（chargeback）治理就不在考虑范围内——不要为此设计。）
  • 有哪些盘点来源：合同库、AP/费用导出、SSO日志、网络/CASB遥测、SaaS管理平台？
  • 是否存在带通知窗口的续约日历，还是本次审查必须新建一个？
  • 有哪些使用证据可用：功能深度遥测、按供应商的管理报告，还是除了登录次数外什么都没有？
  • 决策必须在什么日期前落地——预算周期、董事会日期、还是没有固定日期？（硬性日期会将通知窗口临近的工具提前，并将长周期迁移从本轮中删除。）
  • 一次性节省，还是复利式运营模式？（一次性倾向于降级和削减；复利式倾向于准入门槛、续约触发节奏和治理。）
  • 投入上限：仅分析师工时、管理员/IT容量、工程容量，还是跨职能授权？（仅分析师会把整合迁移和内部构建从清单中删除；授权才是让整合可以被排序的前提。）

Brainstorming the Review Design

审查设计头脑风暴

Enter explicit brainstorming after the Interview, before any inventory or scoring work. Do not jump to a deliverable.
  1. Map the workflows first, tools second: list the revenue workflows the stack must serve (capture, routing, qualification, deal management, quote/sign, billing, onboarding, renewal, expansion - trimmed to the user's motion). A tool serving no workflow on the map is already a finding.
  2. Propose 2-3 candidate review designs with trade-offs. Efficiency, measured as decisions produced per review hour: one-time portfolio sweep with renewal overlay > renewal-window rolling review > practice-level benchmark first.
    • One-time portfolio sweep with renewal overlay - full scoring pass now, every action queued to its window; fastest complete picture, some verdicts wait months for a lever.
    • Renewal-window rolling review - verdicts produced as each notice window approaches; lowest wasted work, slowest full-portfolio picture.
    • Practice-level benchmark first - score how the stack is run (Do More / Do Less / Start / Stop, Frans Riemersma's instrument) before scoring tools; answers a different question than the other two, which is why it ranks last on tool decisions.
  3. Recommend one design and say which Interview answer drove it. Default to the sweep with overlay for a first cycle; promote the rolling review once a full renewal calendar exists and the mandate is standing rather than one-off. The order starves the practice-level benchmark - promote it to first when the mandate covers how the stack is run, not only what it costs.
  4. Validate the deliverable plan section by section (inventory → calendar → overlap map → verdicts → governance) and get approval before building anything.
在访谈之后、任何盘点或评分工作之前，进入明确的头脑风暴阶段。不要直接跳到交付物。
  1. 先映射工作流，再映射工具：列出工具栈必须服务的收入工作流（线索获取、路由、资格认定、交易管理、报价/签约、计费、onboarding、续约、扩展——根据用户的业务模式裁剪）。一个不服务于图谱上任何工作流的工具本身就是一个发现。
  2. 提出2-3个候选审查设计并说明权衡。效率以每审查小时产出的决策数衡量：带续约叠加的一次性组合扫描 > 续约窗口滚动审查 > 先做实践级基准。
    • 带续约叠加的一次性组合扫描——立即完成全量评分，每个行动排入其窗口；最快获得完整图景，但有些判定要等数月才能有操作杠杆。
    • 续约窗口滚动审查——在每个通知窗口临近时产出判定；浪费的工作最少，但完整组合图景最慢。
    • 先做实践级基准——在给工具评分之前，先评估工具栈的运营方式（Do More / Do Less / Start / Stop，Frans Riemersma的工具）；它回答的问题与前两者不同，这就是为什么它在工具决策上排最后。
  3. 推荐一个设计并说明是哪个访谈答案驱动的。首次周期默认使用带叠加的扫描；一旦完整的续约日历存在且授权是常设而非一次性的，就提升滚动审查。这个排序会饿死实践级基准——当授权覆盖工具栈的运营方式而不仅仅是成本时，将其提升到第一位。
  4. 逐节验证交付物计划（盘点 → 日历 → 重叠图谱 → 判定 → 治理），在构建任何东西之前获得批准。

Workflow

工作流

  1. Run the Interview; fix scope, motion, decision rights, and the three efficiency answers (deadline, one-off vs compounding, effort ceiling).
  2. Run Brainstorming the Review Design; get the design approved.
  3. Build the inventory (see Inventory below); flag every shadow-discovered tool and run the dedicated AI-tool discovery pass.
  4. Build or verify the renewal calendar - renewal date, notice window, auto-renew flag, action deadline per tool. Method and worked example in references/renewal-calendar-audit-example.md.
  5. Map functional overlap at the function level, never the vendor level; tag each tool system-of-record vs system-of-engagement - tools that write to the record system are held to a stricter standard than tools that only read.
  6. Gather usage evidence per the Usage Evidence ranking - as a diagnostic input, never as the verdict.
  7. Score every tool with TIME (Tolerate / Invest / Migrate / Eliminate - Gartner); overlay the renewal calendar on every verdict. Worked pass in references/time-scoring-worked-example.md. TIME's known blind spot is exactly SaaS contract timing, which is why the overlay is mandatory.
  8. At any category served by a thin, commoditized, or integration-hostile point solution, run a buy-vs-build checkpoint: internal GTM-engineering build capacity is re-entering this calculation (GTM-engineering postings grew ~205% YoY - Bloomberry; Brinker calls the custom-app long tail the "hypertail"). State the trend; never invent a capability threshold.
  9. Build the verdict register ranked by the Verdict Execution Order below, re-ranked against the Interview's deadline, one-off-vs-compounding, and effort-ceiling answers. Delete an option the constraints rule out and say which constraint deleted it - never park it at the bottom.
  10. Run the consolidation risk pass: a named risk owner per failure mode in the table below, and a preserved-alternative vendor per consolidation verdict.
  11. Attach governance: intake gate (required fields: business justification, intended users, data types, expected duration; automated duplicate-check against the tool registry; 3-5 business day approval SLA - a slow gate creates the shadow IT it exists to prevent) and renewal-to-recertification linkage (recertify access, ownership, and need before each auto-renewal fires).
  12. Emit the deliverable one section at a time for user validation, per the approved design.
  13. Store the verdict register, renewal calendar, and governance decisions in persistent memory when the harness offers it, so the next cycle starts from them; otherwise put all three in the report's final section for the user to carry forward.
  1. 执行访谈；确定范围、业务模式、决策权和三个效率答案（截止日期、一次性vs复利式、投入上限）。
  2. 执行审查设计头脑风暴；获得设计批准。
  3. 构建盘点（见下文盘点部分）；标记每个影子发现的工具，并运行专门的AI工具发现流程。
  4. 构建或验证续约日历——每个工具的续约日期、通知窗口、自动续约标记、行动截止日期。方法和实例见references/renewal-calendar-audit-example.md。
  5. 在功能层面映射功能重叠，绝不在供应商层面；将每个工具标记为记录系统（system-of-record）vs 互动系统（system-of-engagement）——写入记录系统的工具比只读工具要遵循更严格的标准。
  6. 按照使用证据排序收集使用证据——作为诊断输入，绝不作为判定依据。
  7. 用TIME（Tolerate容忍 / Invest投资 / Migrate迁移 / Eliminate淘汰——Gartner）给每个工具评分；在每个判定上叠加续约日历。实例见references/time-scoring-worked-example.md。TIME的已知盲点恰恰是SaaS合同时机，这就是为什么叠加是强制性的。
  8. 在任何一个由薄弱、商品化或对集成不友好的点解决方案所服务的类别上，运行购买vs构建检查点：内部GTM工程构建能力正在重新进入这个计算（GTM工程岗位同比增长约205%——Bloomberry；Brinker将自定义应用的长尾称为"超级长尾"（hypertail））。陈述趋势；绝不凭空发明能力阈值。
  9. 按照下面的判定执行顺序构建判定登记册，并根据访谈的截止日期、一次性vs复利式和投入上限答案重新排序。删除被约束条件排除的选项，并说明是哪个约束删除的——绝不把它放在底部。
  10. 运行整合风险检查：下表中每个失败模式指定一个具名风险负责人，每个整合判定保留一个备选供应商。
  11. 附加治理：准入门槛（必填字段：业务理由、预期用户、数据类型、预期持续时间；对照工具注册表进行自动重复检查；3-5个工作日的审批SLA——缓慢的门槛会造成它本要防止的影子IT）和续约-再认证联动（在每次自动续约触发前重新认证访问、所有权和需求）。
  12. 按照批准的设计，一次输出一个部分的交付物供用户验证。
  13. 当框架提供持久记忆时，将判定登记册、续约日历和治理决策存入其中，以便下一周期从它们开始；否则将三者放入报告的最后部分供用户继续使用。

Inventory

盘点

The working inventory is the union of four discovery channels - each one alone undercounts.
  • Value (tools surfaced that no other channel sees): network/CASB telemetry > AP/expense export > SSO logs > contract repository - the repository, by construction, only holds what already cleared procurement.
  • Efficiency: AP/expense export > contract repository > SSO logs > network/CASB telemetry.
  • Effort: contract repository == AP/expense export (finance already holds both) < SSO log pull < network telemetry.
  • Default rung: run the first three; the order starves network telemetry - the only channel that sees unsanctioned AI tools, the largest blind spot in most stacks (60% of IT leaders lack visibility into generative-AI tools in use; 77% found AI running without IT's awareness - Zylo 2026). Promote it whenever AI shadow usage is suspected or at enterprise scale.
  • Interview finance about expense-channel purchases specifically: expense-based SaaS buying is growing fast while fewer people do it - the buyers to interview are concentrated, not spread thin.
工作盘点来自四个发现通道的并集——单独任何一个都会少算。
  • 价值（其他通道看不到的工具）：网络/CASB遥测 > AP/费用导出 > SSO日志 > 合同库——合同库按构造只包含已经通过采购流程的内容。
  • 效率：AP/费用导出 > 合同库 > SSO日志 > 网络/CASB遥测。
  • 投入：合同库 == AP/费用导出（财务已经拥有两者）< SSO日志拉取 < 网络遥测。
  • 默认档位：运行前三个；这个顺序会饿死网络遥测——它是唯一能看到未授权AI工具的通道，也是大多数工具栈中最大的盲点（60%的IT领导者缺乏对在用生成式AI工具的可见性；77%发现AI在IT不知情的情况下运行——Zylo 2026）。每当怀疑存在AI影子使用或处于企业规模时，将其提升。
  • 专门就费用通道采购访谈财务：基于费用的SaaS采购增长很快，但做这件事的人更少——需要访谈的买家是集中的，不是分散的。

Usage Evidence

使用证据

Usage is a diagnostic input to the value conversation, never the cutoff itself.
  • Value as cut evidence: feature-depth telemetry > proxy signals (records written per user, API call volume, workflows terminating in the tool) > login counts.
  • Effort: login counts (near-zero) < proxy signals (hours per tool) < feature-depth telemetry (needs a management platform or per-vendor admin work).
  • Efficiency: proxy signals > login counts > feature-depth telemetry.
  • Default rung: screen with login counts, decide with proxy signals. The order starves feature-depth telemetry - the only tier that catches a nightly automated sync masquerading as adoption; promote it when a SaaS-management platform is already deployed, or whenever a high-spend verdict hangs on usage.
  • No tier justifies a cut alone: every usage-based flag still needs the per-tool business-value check from Ground Rules.
使用情况是价值讨论的诊断输入，绝不是评判标准本身。
  • 作为削减证据的价值：功能深度遥测 > 代理信号（每用户写入记录数、API调用量、在工具中终止的工作流）> 登录次数。
  • 投入：登录次数（接近零）< 代理信号（每个工具数小时）< 功能深度遥测（需要管理平台或按供应商的管理工作）。
  • 效率：代理信号 > 登录次数 > 功能深度遥测。
  • 默认档位：用登录次数筛选，用代理信号决策。这个顺序会饿死功能深度遥测——它是唯一能捕捉到伪装成使用的夜间自动同步的层级；当SaaS管理平台已部署时，或每当高支出判定取决于使用情况时，将其提升。
  • 没有任何一个层级能单独证明削减的合理性：每个基于使用的标记仍然需要基本规则中的按工具商业价值检查。

Scoring

评分

  • Efficiency: function-overlap map > TIME scoring > practice-level benchmark.
  • These answer different questions:
    • Overlap map: "where are the duplicates"
    • TIME scoring: "what do we do with each tool"
    • Practice-level benchmark: "are we running the stack well"
  • Default: overlap map plus TIME. Add the practice-level benchmark when the mandate covers process maturity, not only spend.
  • TIME's track record is real (Gartner documents a US Air Force application across a mission IT portfolio, with governance and a dry run) - cite it as the credible named framework, and always pair it with the renewal overlay it lacks.
  • 效率：功能重叠图谱 > TIME评分 > 实践级基准。
  • 这些回答不同的问题：
    • 重叠图谱："重复在哪里"
    • TIME评分："我们如何处理每个工具"
    • 实践级基准："我们是否在良好地运营工具栈"
  • 默认：重叠图谱加TIME。当授权覆盖流程成熟度而不仅仅是支出时，添加实践级基准。
  • TIME的实际记录是真实的（Gartner记录了一个美国空军在任务IT组合中的应用，包含治理和预演）——将其作为可信的具名框架引用，并始终与它所缺乏的续约叠加配对使用。

Verdict Execution Order

判定执行顺序

  • Value (spend plus integration surface removed): platform consolidation > duplicate elimination > point-for-point replacement == seat/tier downgrade.
  • Effort: seat/tier downgrade < duplicate elimination < point-for-point replacement < platform consolidation < internal build (a standing engineering commitment, not a project).
  • Efficiency: seat/tier downgrade > duplicate elimination > point-for-point replacement > platform consolidation > internal build.
  • The == tie: a replacement swaps like for like and a downgrade trims spend only - both leave the stack's shape and integration surface intact, which is what the value axis measures.
  • Default rung: first cycle executes downgrades and duplicate eliminations, timed to notice windows. The order starves platform consolidation - the highest long-run value option loses every efficiency round; promote it when integration failures are a measured defect source, an alternative vendor stays live, and the suite capability being consolidated onto ships today. A consolidation premised on the suite's AI roadmap is a bet on a roadmap, not a purchase (Gartner, mid-2025, n=413 martech leaders: 45% of those running AI agents say vendor agent capabilities miss promised performance).
  • Internal build enters only through the buy-vs-build checkpoint in the Workflow, and only where engineering capacity exists.
  • 价值（支出的减少加上集成面的移除）：平台整合 > 重复消除 > 点对点替换 == 席位/层级降级。
  • 投入：席位/层级降级 < 重复消除 < 点对点替换 < 平台整合 < 内部构建（一项长期工程承诺，不是项目）。
  • 效率：席位/层级降级 > 重复消除 > 点对点替换 > 平台整合 > 内部构建。
  • ==平局：替换是用类似物换类似物，降级只削减支出——两者都保持工具栈的形态和集成面不变，这正是价值轴衡量的内容。
  • 默认档位：首个周期执行降级和重复消除，与通知窗口对齐。这个顺序会饿死平台整合——最高长期价值的选项在每轮效率比较中落败；当集成失败是可测量的缺陷来源、备选供应商保持活跃、且被整合到的套件能力今天已经可用时，将其提升。以套件AI路线图为前提的整合是对路线图的押注，而不是购买（Gartner，2025年中，n=413位martech领导者：45%运行AI代理的人表示供应商的代理能力未达到承诺的性能）。
  • 内部构建只能通过工作流中的购买vs构建检查点进入，且仅在存在工程容量的地方。

Cadence

节奏

  • Value: renewal-triggered per-tool review > annual portfolio synthesis > fixed calendar sweep.
  • Effort: fixed calendar sweep (one block of hours) < annual synthesis < renewal-triggered review (a standing trigger per contract, not a project).
  • Renewal-triggered wins mechanically: the average org manages ~211 SaaS renewals a year and renewals carry ~87% of software spend (Zylo 2026) - a calendar review landing after a notice window closes produces analysis with no lever attached.
  • Default rung: renewal-triggered per tool, plus one annual portfolio synthesis, since per-renewal reviews never show portfolio-level patterns (category creep, spend-per-workflow drift). The order starves that synthesis - every individual renewal feels more urgent than it does - so protect it with a fixed date. Delete the fixed calendar sweep once every contract has a window; it survives only as the bridge used while the calendar is still being built.
  • Name an accountable owner per tool - decentralized committee buying means no one's job is on the line for a bad purchase (Jeremey Donovan).
  • 价值：续约触发的按工具审查 > 年度组合综合 > 固定日历扫描。
  • 投入：固定日历扫描（一个时间块）< 年度综合 < 续约触发的审查（每个合同的常设触发器，不是项目）。
  • 续约触发在机制上胜出：平均组织每年管理约211次SaaS续约，续约承载约87%的软件支出（Zylo 2026）——在通知窗口关闭后才落地的日历审查只会产生没有操作杠杆的分析。
  • 默认档位：按工具的续约触发，加上一次年度组合综合，因为单次续约审查永远不会显示组合级模式（类别蔓延、每工作流支出漂移）。这个顺序会饿死综合——每个单独的续约都感觉比它实际上更紧急——所以用固定日期保护它。一旦每个合同都有窗口，就删除固定日历扫描；它只作为日历仍在构建时的桥梁存在。
  • 为每个工具指定一个负责任的负责人——去中心化的委员会采购意味着没有人为一次糟糕的采购承担职业风险（Jeremey Donovan）。

Output Shape

输出格式

STACK RATIONALIZATION REVIEW - <scope>, <date>
Workflow map      : revenue workflows served; tools mapped to each; orphan tools flagged
Inventory         : tool | function | owner | annual cost | seats | discovery channel | shadow flag
Renewal calendar  : tool | renewal date | notice window | auto-renew | action deadline
Overlap map       : function-level duplicates; system-of-record vs system-of-engagement tags
Verdict register  : rank | tool | TIME verdict | value evidence | usage (diagnostic) |
                    action + window | risk owner
                    (ranking basis and any deleted option stated above the register)
Consolidation risk: named owner per failure mode; preserved alternative per consolidation
Governance        : intake gate fields + SLA; renewal-recertification link; re-sprawl metric
Next cycle        : upcoming notice windows; re-review triggers; decisions stored/carried
STACK RATIONALIZATION REVIEW - <scope>, <date>
Workflow map      : revenue workflows served; tools mapped to each; orphan tools flagged
Inventory         : tool | function | owner | annual cost | seats | discovery channel | shadow flag
Renewal calendar  : tool | renewal date | notice window | auto-renew | action deadline
Overlap map       : function-level duplicates; system-of-record vs system-of-engagement tags
Verdict register  : rank | tool | TIME verdict | value evidence | usage (diagnostic) |
                    action + window | risk owner
                    (ranking basis and any deleted option stated above the register)
Consolidation risk: named owner per failure mode; preserved alternative per consolidation
Governance        : intake gate fields + SLA; renewal-recertification link; re-sprawl metric
Next cycle        : upcoming notice windows; re-review triggers; decisions stored/carried

Pass Threshold

通过标准

  • Every in-scope tool carries an owner, a function, a TIME verdict, and a renewal date with notice window; unknowns are marked "unconfirmed", never left blank.
  • No Eliminate or downgrade verdict rests on utilization alone; each carries a one-line business-value justification.
  • Every consolidation verdict names the preserved alternative vendor and a risk owner per failure mode.
  • Every verdict has an action deadline inside a live notice window, or is explicitly queued to the next one.
Iterate until all four hold. A verdict queued to a future window with a date attached is a passing outcome; a verdict with no window is not.
  • 每个范围内的工具都有负责人、功能、TIME判定和带通知窗口的续约日期；未知项标记为"未确认"，绝不留空。
  • 没有哪个淘汰或降级判定仅靠利用率支撑；每个都附带一行商业价值论证。
  • 每个整合判定都指明保留的备选供应商和每个失败模式的风险负责人。
  • 每个判定都有在当前有效通知窗口内的行动截止日期，或明确排队到下一个窗口。
迭代直到四项全部成立。排入未来窗口并附有日期的判定是合格结果；没有窗口的判定不合格。

Common Failure Modes

常见失败模式

DefectConsequenceFix
Cutting by utilization percentage aloneKills low-seat tools covering critical edge casesBusiness-value check per tool; "do nothing" and enablement stay on the verdict menu
Renewal-window blindnessAuto-renew locks in another term at a higher rateAction deadline = notice-window open, on every verdict; start negotiations well before the window
Full consolidation with no live alternativePricing power transfers to the suite vendor permanentlyName and keep evaluating an alternative per consolidation verdict
Adoption collapse post-consolidationThe project fails on behavior, not data (the direction is consistent across sources; the circulating failure percentages are unverifiable)Adoption owner, enablement plan, and champion transition named before migration
Feature-parity gap surfaces post-migrationAn undocumented workflow breaks after cutoverWorkflow-level parity walkthrough with the tool's heaviest users before the verdict finalizes
Reporting discontinuityYear-over-year comparison breaks while leadership scrutinizes the project's own ROIMigrate the measurement model with the records; see mbfinotti/revops-skills@revenue-reporting
Champion lossThe person who made the cut tool work leaves the workflow orphanedName a transition owner for every Eliminate/Migrate verdict
Re-sprawl between cyclesThe next review starts from scratchIntake gate with automated duplicate-check + renewal-recertification link, installed as part of this deliverable
Single-platform mandate over-reachesMandating everything live inside one suite and ripping out specialized tools reads clean on paper; when a capability like conversation intelligence or forecasting quality visibly drops, reps route around the mandate and rebuild a shadow stack, so the org pays for the suite and the shadow stack bothScope the mandate to what the suite genuinely covers at parity; keep a named specialized tool where the suite's version is materially worse
Logic and platform change on the same dayChanging scoring or routing logic at the same moment as the platform migration forces reps to relearn judgment while learning a new tool, and adoption rarely survives both at onceFreeze process logic during the cutover window; if the schema looks the same after migration, the org changed tools, not operations - change logic separately, before or after
缺陷后果修复
仅凭利用率百分比削减扼杀了覆盖关键边缘场景的低席位工具每个工具做商业价值检查；"不做任何事"和赋能保留在判定菜单中
续约窗口盲视自动续约以更高价格锁定又一个合同期每个判定上的行动截止日期 = 通知窗口开启时；在窗口之前提前开始谈判
全面整合但没有活跃的备选方案定价权永久转移给套件供应商每个整合判定指定并持续评估一个备选方案
整合后采用率崩溃项目在行为上失败而非数据上失败（方向在多个来源中一致；流传的失败百分比无法验证）在迁移前指定采用负责人、赋能计划和关键用户过渡
迁移后出现功能对等差距未记录的工作流在切换后中断在判定最终确定之前，与该工具最重度用户进行工作流级对等审查
报告中断在领导层审查项目自身ROI时，同比比较中断将度量模型与记录一起迁移；见 mbfinotti/revops-skills@revenue-reporting
关键用户流失让被削减工具发挥作用的人离开，工作流无人照管为每个淘汰/迁移判定指定过渡负责人
周期之间再次蔓延下次审查从零开始准入门槛带自动重复检查 + 续约-再认证联动，作为本交付物的一部分安装
单平台指令过度扩张强制一切都在一个套件内运行并拆除专业工具在纸面上看起来很干净；当对话智能或预测质量等能力明显下降时，销售代表绕过指令重建影子工具栈，组织同时为套件和影子工具栈买单将指令范围限定在套件真正能达到同等能力的范围内；在套件版本明显更差的地方保留指定的专业工具
逻辑和平台同日变更在平台迁移的同时更改评分或路由逻辑，迫使销售代表在学习新工具的同时重新学习判断，采用率很少能同时经受住两者在切换窗口期间冻结流程逻辑；如果迁移后schema看起来一样，组织只是换了工具而不是运营方式——在之前或之后单独更改逻辑

KPIs

KPI

  • Track per cycle: spend per workflow served (trend), redundant-function count (trend), share of renewals reviewed before their notice window opened (target near-100%), and net new tools entering outside the intake gate (re-sprawl rate, target near-zero).
  • Honesty checks: realized savings vs the register's projections, and surviving-tool adoption after each consolidation - if adoption drops, the consolidation failed regardless of the spend line.
  • Never report "tools cut" as the success metric - it rewards cutting count instead of redundancy, the exact inversion of the goal.
  • 每个周期追踪：每个被服务工作流的支出（趋势）、冗余功能数量（趋势）、在通知窗口开启前完成审查的续约比例（目标接近100%），以及通过准入门槛之外进入的净新增工具（再蔓延率，目标接近零）。
  • 诚实检查：实际节省 vs 登记册的预测，以及每次整合后幸存工具的采用率——如果采用率下降，无论支出线如何，整合都失败了。
  • 绝不要将"削减的工具数"作为成功指标——它奖励的是削减数量而非削减冗余，这与目标完全背道而驰。

Invocation Examples

调用示例

  • "We're at something like 40 GTM tools and finance wants a rationalization plan before budget season."
  • "Our CRO thinks half the sales stack overlaps - run a stack review and tell us what to consolidate or cut."
  • "Renewals keep auto-firing before anyone looks at the tool - set up a stack review that runs on the renewal calendar."
  • "我们大约有40个GTM工具，财务希望在预算季之前有一个合理化方案。"
  • "我们的CRO认为一半的销售工具栈重叠——进行一次工具栈审查，告诉我们该整合或削减什么。"
  • "续约总在任何人查看工具之前自动触发——建立一个基于续约日历运行的工具栈审查。"

Reference

参考

  • Read references/benchmarks-and-figure-grading.md before citing any figure - the sourced benchmark set with editions, the ranked source list, and the fabricated-statistic blocklist.
  • Read references/time-scoring-worked-example.md when scoring - a worked TIME pass over a sample GTM stack, with the renewal overlay and a negative example (a utilization-only cut done wrong).
  • Read references/renewal-calendar-audit-example.md when building the calendar - schema, action-deadline arithmetic, worked mini-calendar, and the wasted-verdict failure case.
  • See 
    mbfinotti/revops-skills@crm-data-governance
    for field ownership and source-of-truth policy inside the systems this review keeps.
  • See 
    mbfinotti/revops-skills@revenue-data-governance-strategy
    for the cross-system ownership map that any consolidation redraw must respect.
  • See 
    mbfinotti/revops-skills@revenue-leakage
    when records or dollars vanish in one funnel - a leak traced to a tool defect feeds this review; this review does not trace leaks.
  • 在引用任何数据之前阅读references/benchmarks-and-figure-grading.md——包含版本的有出处基准集、排序来源列表和虚构统计黑名单。
  • 评分时阅读references/time-scoring-worked-example.md——对示例GTM工具栈的完整TIME评分实例，包含续约叠加和一个反面示例（仅凭利用率削减的错误做法）。
  • 构建日历时阅读references/renewal-calendar-audit-example.md——schema、行动截止日期计算、实例迷你日历和浪费判定失败案例。
  • 关于本审查所保留系统内的字段所有权和真实来源（source-of-truth）策略，参见
    mbfinotti/revops-skills@crm-data-governance
    。
  • 关于任何整合重绘必须遵守的跨系统所有权图谱，参见
    mbfinotti/revops-skills@revenue-data-governance-strategy
    。
  • 当记录或资金在某个漏斗中消失时，参见
    mbfinotti/revops-skills@revenue-leakage
    ——追溯到工具缺陷的泄漏会反馈到本审查；本审查不追踪泄漏。