Wait, 不能输出 h1. 修正如下：
刚做阿里云销售的人，常会先把产品目录背熟，然后等客户来问价。但云服务的销售周期长，决策链条也长。能把项目往前推的人，通常是先想清楚客户的业务问题，再谈资源怎么配。下面结合两个实际场景，说说一个项目一般怎么走。
先判断客户处在上云的哪个阶段
同样是企业，有的还在机房里跑老服务器，有的已经把一部分业务放到公有云上，关心的东西完全不同。前者多半担心迁移成本和稳定性，后者更在意弹性、成本和多云管理。第一次接触时，先弄清楚对方在哪一步，话术才不会错位。
- 观望期：对云有兴趣，但对数据安全和业务连续性心里没底。这时别急着推方案，可以先说清楚迁移过程中的备份和回滚方式，让对方有办法验证。
- 试点期：已有小规模业务上云，想看到实际效果。适合一起定一个能量化的试点，比如某个报表系统的响应时间从多久降到多久。
- 规模化期：核心系统陆续迁移，关注架构治理、成本分摊和运维效率。这时要把运维和财务拉进来一起谈，只讲技术参数不够。
案例一：制造企业的 ERP 迁移
一家华东地区的中型制造企业，ERP 系统部署在自建机房。每到月末结账，系统明显变慢，而扩容采购要等两个月。客户最初只问“能不能便宜点买服务器”。销售没有直接报价，而是约了信息部和财务部一起开会，先问清三件事：高峰期并发量是多少，历史数据要保留多久，故障时业务能接受多长停机时间。
问清楚之后，方案没有一上来就整体迁移，而是建议先把报表和查询类负载搬到云上，核心交易库暂时留在原处。风险小，客户三个月内就能看到结账时间变短。试点通过后，才逐步迁移核心系统。整个项目用了八个月，节奏慢，但客户后面愿意把更多系统交给我们评估。
问对问题，比直接报价更有用
客户很少一开始就说出真正的痛点。与其问技术参数，不如从业务结果反推。下面几个问题可以直接用在电话或拜访中，重点听的是对方回答里的具体数字和人名。
- 现在最让你头疼的业务场景是什么？一个月会出现几次？如果对方说不清次数，可以请他翻一下当月的工单记录。
- 如果这个问题解决了，业务部门的工作会有哪些变化？能说出一个具体动作，比如“月底不用加班对数”，说明需求是真的。
- 现在的 IT 投入里，哪一块你觉得花得最不值？这个问题容易让对方说出预算的去向，也能看出他的态度。
- 如果半年内要看到成果，内部最看重哪个指标？把这个指标记下来，后面方案汇报时直接对应它。
问题问对了，预算、决策人和时间表往往会自己冒出来。这些信息比产品介绍更能决定方案能不能切中要害。
案例二：电商团队的大促保障
一家做家居用品的电商企业，每年大促前都很紧张。去年他们的技术负责人直接问：“你们的产品能扛住多少 QPS？”这个问题很常见，但只报一个数字，对方不会有感觉。销售请客户把去年大促的流量曲线拿出来看，发现峰值集中在晚八点到十点，订单系统的瓶颈在库存扣减环节。
方案于是重点放在弹性伸缩和缓存改造上，并建议大促前做一次全链路压测。销售还帮客户算了一笔账：全年都按峰值配置资源，花费会高很多；只在大促期间扩容，整体支出能明显降下来。客户最后选择分阶段采购，这次沟通的重点是他们自己的业务节奏，而不是参数表。
同一个方案，给不同角色讲不同的话
方案写得再完整，决策人看不懂它能带来什么，也推不动。给管理层汇报时，可以按三层来讲：先说要解决的业务问题，再说方案能带来的可量化改善，最后说风险和实施节奏。技术细节放到附录里，交给技术团队自己评估。
比如同样是高可用架构，对技术负责人可以讲多可用区部署和故障切换机制，对财务负责人则讲停机损失怎么减少，以及按需付费之后成本怎么控制得住。讲的是同一个方案，话要换成对方关心的那一头。
几个容易踩的坑
- 需求没问清就报价：价格一出来，客户就拿去和别家比，很容易落进价格战，后面再讲架构价值就难了。
- 只讲功能不讲场景：功能列表再长，客户也记不住。讲清一个具体问题怎么被解决，他才会记得。
- 只和一个人打交道：项目能不能推下去，常常要看客户内部的技术负责人愿不愿意替你说话。提前和他把关系建起来，比在会上多讲十分钟更管用。
- 签完单就停：云服务是按用量持续消耗的。签约后用量怎么涨、架构要不要优化、什么时候续费，都是接下来要跟进的事。
签单之后，续费和扩容才开始
一个项目签下来，只是合作的开头。定期回访客户的资源使用情况，主动提示成本上可以优化的地方，客户业务增长时及时给出新的架构建议，这些日常沟通做扎实了，续费和扩容自然会来。很多客户的增购，靠的就是这些不起眼的跟进。
做阿里云销售，关键不在于背了多少参数。先判断客户在哪个阶段，再把问题挖出来，用一个能验证的试点建立信任，最后把方案讲成对方听得懂的业务语言。项目一般就是这样一步步推下去的。
