挖掘客户需求，已经成了软件销售的习惯。但对于SaaS销售来说，挖掘需求对于销售并无明显作用，而且在某些情况下，还可能产生相反的效果。
实际上，很多来自客户的需求，其实并非是业务要求，而是客户对功能的表述。比如，我就遇到过客户提出的一项需求，需求列表上是这样写的：“自动计算加工零件合格率指标，并在首页右上角高亮显示”。遇到这种需求，如果是做软件，很容易开发出来，而SaaS就很难满足或者花费额外的工作量。
实际上，如果你知道这个“需求”背后的业务目的，就完全可以用更直观的展示方式，同样能满足对应的业务目的。比如在这个例子中，“展现合格率指标”是为了给工厂参观者展示产线加工良品率的真实水平。知道了业务目的，完全可以用更合适的方式，同样能实现更好的效果。
所以你看，“挖需求”与“挖成果”并不是同一层面上的事：一个是有目的地挖，一个是随处乱挖。
而更多的情况是，也许客户自己也不能清楚地提出和表达需求。因此，围绕客户需求的销售竞争，很可能在一开始，就偏离了客户的业务目标。无论是销售方的原因，还是客户的原因，总之是将项目引向了一条前途未知的道路。而最后的“赢家”，往往并不是能解决问题的，而是善于实现客户功能需求的。
实际上，挖掘客户需求还有一个更大的问题，那就是进入销售过程后，再去挖掘客户需求已经迟了。这很可能给客户留下的印象是，你既不是有备而来，也不了解他们的业务。
其实，有一种方法可以避免需求挖掘带来的销售困境，那就是不去挖掘需求，而是直接去挖掘客户想要的成果（Customer Outcomes）。
不熟悉这种方法的销售通常会存有疑虑：如果挖掘出的成果，不被现有功能支持怎么办？其实这种担忧是多虑的，挖成果反而是用SaaS方式解决问题的更有效方法。
这里的基本逻辑是：虽然通常需求与功能是一一对应的；但客户成果与功能之间，往往是一对多的关系。这样，你无需修改功能，也可以实现客户想要的成果。换言之，不同的实现方式都可以满足客户对成果的要求，而不一定非要按照客户要求的实现方法。这在很大程度上可以规避SaaS无法定制化开发的问题。
因此，正确的做法是直接从客户成果切入展开销售，只是挖成果与挖需求所采用的方法有很大区别。
在这个过程中，你可能会遇到三种情况：
第一，你已经掌握了客户的业务成果，而所谓的成果挖掘，只是让客户认为你很快就抓到了业务的核心。如果你已有现成的业务成果，那自然是最理想的。其实这并非完全是一种幸运，事实上，如果你长期专注于某一行业或领域，这也是完全有可能的。
第二，你没有直接可用的业务成果，但有可参考的行业案例。此时的成果挖掘，只是划定了一个深入挖掘的范围，而客户的经验正好可以帮助你厘清和确定成果。这种情况下，挖掘客户成果的工作可能会麻烦一些，因为你不能想当然地认为，现有的客户成果能完全适用于同行业或另一个领域。不过，你也不需要过于担心，因为我们可以借助客户成果金字塔框架，结合同行业中类似的客户业务目标、ROI、KPI等，也能较快地挖掘出新的业务成果。
第三，完全没有可参照的业务成果，也没有类似的行业案例。这就需要从头开始挖掘了，而且挖掘客户成果的工作会更加复杂和耗时。由于公司之前在这个行业或领域的服务经验较少，所以你只能从零开始。幸运的是，你已经掌握了客户成果金字塔框架，可以从ROI、KPI、责任人到产品对应，依次套用。哪怕得到一个初步的结果，对于赢单也是很有帮助的。因为你后面还有机会，与客户进行补充和确认所定义的业务成果是否正确。
当然，也存在这样一种情况：这个客户与你的ICP偏差很大，甚至完全不符合你的ICP。在这种情况下，放弃或许是最佳选择，这样你就可以腾出时间来寻找合适的潜在客户。
顺带多说一句，如果你正在使用CRM系统，那么其中一定有一个名为“客户需求”的字段。过去，这个字段中记录的可能是客户口头提出的需求，或者是你自认为的客户需求。但现在，我们看到越来越多的销售人员在这个字段后面增加了一个“业务成果”字段，并将这两个字段进行关联。表面看来只是在CRM中增加了一个字段，其实却意味着SaaS销售思路发生了根本性转变。
你可能常常羡慕那些销售高手，他们能够使用客户的语言，对客户行业提出独到的见解，所发掘的需求很受客户认可，因此他们更容易获得订单。
但现在，你有了超越他们的机会，那就是通过挖掘客户成果来实现。虽然深入了解一个行业并非易事，更何况是多个行业。但如果你能凭借熟练挖掘和分析客户成果，就能形成一套更高级的销售方法。
这样就有可能在“客户成果”这个弯道上实现超车。
