用途：对整套 RevOps/GTM 工具组合做宏观、周期性审查，输出逐工具裁决（保留、整合、迁移、淘汰），并把每个动作对齐到该工具的续约通知窗口，同时给出防止工具栈再次膨胀的治理方案。术语“stack rationalization”来自 Scott Brinker，强调简化到团队能有效使用的程度，但利用率本身不能作为业务理由。
主要能力：先做访谈（触发原因、范围、业务模式、规模、决策权、成本分摊、清单来源、续约日历、使用证据、截止日期、一次性还是复利、投入上限），再进行审查设计头脑风暴，随后构建工具清单、续约日历、功能重叠图，用 TIME（Tolerate/Invest/Migrate/Eliminate）打分并叠加续约窗口，最后产出裁决登记表、整合风险与治理机制。
使用方式：按工作流顺序执行——访谈、设计、清单、日历、重叠映射、使用证据、TIME 打分、买vs建检查、裁决登记、整合风险、治理、逐段交付验证。清单取合同库、AP/费用导出、SSO 日志、网络/CASB 遥测四渠道的并集；使用证据仅作诊断输入，不能单独作为裁减依据。
适用场景：B2B 销售驱动、PLG/混合、B2C/电商等不同业务模式的工具栈审查；一次性降本或建立复利运营模型。
限制：只做建议，不执行迁移；续约日历是硬约束；不得引用无来源的流传统计；套件与单点方案之争不预设结论；整合裁决须保留备选供应商以维持议价能力；B2C 基准多偏 B2B-SaaS，需明确标注。具体价格、平台与效果资料未提供。