提价策略与执行方案

为什么提价总是一团糟

把价格往上调，是多数公司既想做又不敢做的动作。做砸了，老客户觉得自己被当成提款机，Twitter 上全是抱怨；做好了，几乎就是纯利润。差别通常不在价格数字本身，而在有没有把这几件事算清楚：哪些客户能承受、哪些会走、走多少我们才不亏、通知怎么发才不至于看起来在道歉。

@user_fccf428b/pricing-change-strategist 就是为这个问题准备的端到端工作流。它不负责决定"要不要涨价"（那是产品发布作战室的事），也不负责替你听客户怎么说（客户专家组的活），它只负责"怎么涨"。

它具体做什么

建立基线。 优先通过 Stripe、Mercury、Supabase（经 $SUPABASE_TOKEN）只读拉取当前定价、套餐层级、真实折扣（标价 vs 实际成交），以及按客户分层的 ACV 分布、续约流失率和各层级的服务成本。数据没接通就手动提问，但所有估算都会显式标注。

按价格敏感度分层。 把客户拆成可执行的组：

• 锚点客户：收入高、迁移成本高，能吸收涨价，值得单独人工处理
• 价格敏感的核心层：价值驱动、最容易流失，需要最强的价值叙事
• 遗留/低价层：付的钱远低于所得价值，机会最大、背叛风险也最大
• 高风险层：本身活跃度就低，涨价可能变成他们离开的借口

每组都给出现价、拟定价、涨幅百分比、预估流失反应和净收入影响。

透明建模。 保守/预期/激进三档涨幅，逐一写出流失率、留存收入、净增收入和让利回本周期，并算出盈亏平衡流失率——涨多少能承受、超过多少就是净亏损。关键假设会被明确标注为假设，而不是夹在汇总数字里糊弄过去。

敲定政策与话术。 包括祖父条款（不适用/限时/永久，每种对应的收入取舍）、通知周期、旧套餐迁移路径、年付折扣等让利手段，以及执行顺序。所有面向客户的文案都遵循同一个结构：先讲交付的价值，再讲变化，最后给路径，而不是为合理收费道歉。

适用边界

• 对账单和 CRM 系统只读，绝不修改订阅、价格或发送任何内容
• 产出物中不出现真实客户 PII，一律以聚合分层呈现
• 凭据只存环境变量，不回显、不记录、不转发
• 想验证文案效果，可以接客户专家组模拟；想监控执行，可以把回滚触发条件做成检查清单
• 涉及发送、发布、付款等外部写入时，需先展示目标与影响并取得你的明确确认