(网经社讯)互联网企业在激烈的市场竞争中，能够取得成功和突破，很重要的原因之一，就是尊重数据的价值，认可数据的重要性，能够尝试基于数据做出的分析和决策。并且，这种对数据深刻的信仰，不是只存在于形式主义的流程和制度中，而是深深植入每一位互联网人的潜意识和大脑深处。

优秀的互联网企业和团队，通过对数据的洞察来分析业务，而在产品需求和项目的迭代过程中，更会慎重的分析每一个需求上线后的表现和效果。

B端产品的收益往往难以衡量

然而，在实践中，和其他产品方向相比，B端产品的收益难以量化，或者说很难衡量需求和项目的效果。这是因为，B端产品的效果和收益，除了软件产品本身的影响以外，往往还取决于业务政策，以及业务人员的能力和态度等外部因素。

举个例子，针对给销售人员使用的OCRM系统，实现了若干需求，预期提高销售的转化率，但实际上影响转化率的因素太多了，客户质量，佣金政策，销售能力，都是影响因素，这些因素互相掺杂在一起，导致项目组很难衡量转化率指标的变化，究竟有多少是因为产品功能而改善的。

即便B端产品的收益和效果难以量化，我们依然要努力对项目进行收益分析，这是互联网人必须具备的基因，并且，思考项目收益如何衡量的过程，本身也是对需求和项目更深层次的分析论证的过程。如果你不能度量一件事情，那么你一定要谨慎思考到底该不该去做。

B端产品的项目分类

我们可以将B端项目按照属性分为三大类，分别是技术项目、业务项目、基建项目。其中，技术项目不属于产品经理的研究范畴，略过不谈，此处，重点讨论业务项目和基建项目的收益评估。

所谓业务项目，是指具备明确业务价值和收益的项目，很多时候，这类项目具备某方面明确的业务价值，但却难以衡量或度量效果。

所谓基建项目，是指业务价值不明显，但是又非常必须或必要的项目。一方面可能是因为功能完善的需要，另一方面可能是因为软件架构抽象的需要（或者用时髦的话说，是中台建设的需要）。

如何衡量业务项目的收益

1. 将收益类型归类

B端产品的核心价值，是帮助企业解决某类经营管理问题。而作为服务于某条业务线或某个业务单元的B端产品，常常在以下方面对业务产生价值：提高收入（规模）、降低成本（成本）、提升效率（效率）、保证品质（品质）、控制风险。其中规模、成本、效率、品质是业务部门运营管理的核心优化方向，而风控属于相对独特的一类业务监管需求。

B端产品在业务上的价值，基本不会超出以上提到的五点范畴。而以上五点，则可以作为B端项目的大方向的收益类型。任何业务项目的项目目标，都会落在其中某点上。如果某个项目看起来可能有多个收益，例如既可以提高效率，又可以提高品质，则要小心项目的范围是否过大，是否需要拆解项目，保证项目的聚焦和可落地性。

明确业务项目的价值收益类型后，下一步的收益评估工作会顺畅很多。

2. 拆解二级指标

不论是规模、成本，还是效率、品质，在业务线或者业务单元的运作中，都应该设立了明确的一级指标，作为公司对业务部门的核心考核指标。例如：

针对销售部门，规模的一级指标可能是“签单交易额”；针对客服部门，成本的一级指标可能是“每千人客户的客服人力成本”；针对配送部门，效率的一级指标可能是“配送及时率”；针对采购部门，品质的一级指标可能是“采购质量合格率”；各个业务线或业务单元，都会有核心一级指标作为北极星指标存在，指引业务的方向。但是，B端产品对业务的提升和改善，是很难通过一级指标来衡量的，有必要通过针对一级指标的拆解来进行分析度量。很多时候，产品经理觉得B端产品在业务上的收益和价值难以度量，是因为寻找对应的业务度量指标不够细致，如果尝试将一级指标层层拆解，有可能就会找到比较适合评估收益的二级指标甚至三级指标。

例如，某在线教育的OCRM产品经理设计实现了销售打单辅助工具，该工具在试听课结束后生成小朋友在试听课中的精彩片段视频，由销售人员发给家长，提升家长对试听课的认知程度，通过有趣的视频感受课程的乐趣和孩子的积极参与。作为销售打单工具，该产品功能，核心目标是提高转化率，但是转化率作为二级指标，颗粒度依然很粗，影响因素太多。此时，我们尝试将转化率漏斗进行层层拆解：

转化率 = 试听课邀约率*邀约出席率 * 出席完课率 * 完课支付率

此时，转化率二级指标被拆解成了更细的四个三级指标。而上述案例中提到的产品功能，显然目的不是提高试听课邀约率，也不是邀约出席率，更不是出席完课率，而是在小孩上完试听课之后，帮助销售完成产品体验结束后的拍单工作，显然，该产品功能最能影响的三级指标，是完课支付率。

因此，我们认为，针对该项目，可以考核完课支付率，观察项目上线前后指标的变化，来评估项目收益。

但是，这个评估方法依然是不完美的，即使到了很细节的三级指标，在业务上的影响因素依然非常多，以完课支付率为例，该指标依然受到潜在客户的质量，以及销售个人能力的外部因素影响。为了更加客观的分析，需要采用AB测试的办法，选取两批特征完全相同的销售线索，一组作为实验组，提供精彩视频功能，一组作为对照组，不提供精彩视频功能，从而观察两者在完课支付率上的对比，来评估项目收益。

然而，B端项目很多时候难以执行AB测试，例如，如果业务流程是涉及到外部部门协作的完整流程机制，那么如果涉及到新业务流程上线，就不可能新老流程并存，让协作部门某些时候走新流程，某些时候走旧流程。

这可能正是B端产品收益难以衡量的一个致命问题，B端产品的AB测试以及小流量实验，实施成本巨高，很多时候甚至无法实施，这就导致很难准确的比对、测量项目收益。而我们只能尽量选取精准的相关的三级指标来尝试衡量收益。

以上提到的逐层拆解指标来衡量项目收益的思路，实际上也是B端业务分析拆解的思路。在业务分析过程中，通过对数据指标的逐步拆解，发现问题，针对某个关键指标设计改进方案，落地实施，实际上，一个好的项目，在立项之前，就应该已经明确了上线后的考核指标以及收益衡量思路了。

如何衡量基建项目的收益

1. 对于基础建设项目，考核交付质量和时间

接下来我们探讨如何衡量基建项目的收益。

在B端产品项目中，基建项目必然会占到一定的比例，这是由于B端产品的性质决定的。B端产品，作为复杂系统，一整套体系的运转，必须是多种类型的软件功能组合而成，例如，要有基本的权限管理，消息提醒管理，数据字典配置管理等功能。这类对业务没有明显价值和收益，但对于软件系统又非常需要的功能，属于基础建设功能。

在B端产品中，往往存在大量基建项目，除了以上提到的配置后台功能，还有很多收益不明确，但“看起来又必须得有”的功能。例如，某个列表页的分页器需要优化；某个列表页的结果集需要增加一列；某个编辑页面的校验规则需要完善；某个消息提醒的提醒方式需要改善，等等。

这类项目都可以属于基建项目，业务价值着实难以衡量量。对于此类项目，只需要正常考核交付质量、交付时间就可以，没必要为了评估而非要生搬硬套某些业务价值，造成没必要的麻烦。

2. 对于中台建设项目，考核系统接入量以及人力节约

中台建设项目，是B端产品建设中很特殊的一类项目，也属于基础建设的范畴，因此我们放在这个版块来讨论。

中台的目的是抽象建设可以复用的软件系统或模块，例如将各个业务系统都需要使用的消息中心、短信中心抽象成基础服务，供多个系统使用。

对于中台产品或项目，我们可以考核其接入的客户端数量，来衡量其被复用能力的强弱，以及推广落地的结果。

此外，中台产品很重要的一个目标，是所谓避免重复造轮子问题，那么则可以通过其接入的客户端数量，来估算研发人力成本的节省。

通过考核中台产品客户端的接入数量，可以很好地倒逼中台产品经理像一个推销员一样去推销自己负责的中台产品。因为多数情况下，大型企业的多部门产品线，并不在意甚至并不愿意主动接入中台产品。虽然我们说中台建设需要自上而下的意志，但是更多时候也需要自下而上的倒逼推进。

终极的万能衡量指标，考核使用人数

我们讲了这么多评估的方法，但是很多时候，依然很难衡量某些B端产品功能对核心指标的影响程度，虽然两者在逻辑上有着明显的相关性。

例如，某销售人员使用的OCRM系统，产品经理对客户详情页做了全面的升级，提供了丰富的视图，可以让销售人员了解潜在客户的所有重要信息，通过对其进行画像标记，剖析其潜在需求和兴趣点，帮助销售人员更好的了解客户，从而成功转化。那么，如何衡量这套全新的“客户详情页”的价值和收益呢？

再例如，某客服系统，上线了若干针对一线主管使用的报表，帮助其更好的监控、管理下属团队的服务过程和服务水平。那么，如何衡量这些报表对客服业务服务质量和服务水平的改善作用呢？

如果不能明确业务项目对业务产生的收益是什么，那么至少可以评估有没有人使用这些功能。这是非常具备实操性的一种评估方法，如果你设计了新的功能，那么，保留老功能的入口，让用户用脚投票，看看到底哪一套功能更受欢迎。当然，有些新功能的推广是需要培育的过程，让用户慢慢适应接受。但是，如果没有明确的策略要求，则完全可以让新老功能并存，看看到底哪套功能做的好。如果用户都不愿意使用新功能，那么对业务的影响和改善就无从谈起了。

前边提到的详情页以及报表的案例，就可以考核用户使用的UV、PV，来衡量产品功能是否成功。

结语

收益难以量化评估，是B端产品共同的难点。但作为B端产品经理，依然要尽最大努力评估、分析项目，否则就没有继续优化迭代决策的依据，也是对公司宝贵RD资源最大的浪费。

以上提到的都是单一项目或需求的评估，如果要对从0到1构建的B端产品进行评估，将上述方法进行叠加使用即可。（来源：36氪）