网站内容管理系统后台 设计( B端产品如何进行数据驱动？指导我们去完成迭代)

　　网站内容管理系统后台 设计(

B端产品如何进行数据驱动？指导我们去完成迭代)

　　近日，创投圈的又一轮资本来了。过去，我们通过融资来进行持久战、吸引用户和将广告货币化。这种长期的C端策略不再受到资本市场的推崇，而是转变为追求如何快速变*敏*感*词*的短投资周期模式。这时，B端产品的优势就凸显出来了。毕竟，赚钱是真的。

　　作为B端产品，由于他们经常与不同的业务线交互，角色众多，需求不同甚至相互矛盾，这也造成了产品后端业务的复杂性。那么在复杂的业务设计中，如何保证仍然可以为企业用户提供最精简的流程呢？

　　这就需要引入数据驱动的产品迭代，一方面帮助我们发现系统问题，另一方面指导我们完成迭代。那么我们来看看B端产品是如何数据驱动的？

　　一、两个误会

　　首先，我想在这里说一下：B端数据驱动的两个误区。

　　1. 误解1. 阳光理论

　　B端产品不是C端产品，两者有本质区别：B端用户数量不会很大。比如曾经风靡一时的社交软件*敏*感*词*短信上线30天，总用户数近750万，但另一方面，背靠阿里巴巴的B端龙头产品钉钉，在声称企业用户已经到来之前，已经在无数资源的投入下运营了4年。50000000。它的用户增长率和用户量一目了然。

　　但这是否意味着*敏*感*词*短信已经取得了巨大的商业成功？钉钉是失败的产品吗？我不这么认为。作为B端产品，钉钉的支付能力和支付意愿高于C端产品，因为它的用户大部分是企业用户。产品实现速度更快，开发成本回报周期更短。短的。就拿我们之前在钉钉上推出的插件来说，月均成交额可以突破50万元，是C端产品无法比拟的。

　　这个时候，如果我们还停留在日常生活的理论中，一味追求B端产品的日常生活是没有意义的。B端产品真正应该追求的是高净值客户，而不是用户数量。

　　2. 神话2. 虚荣指标

　　首先我们要知道，任何产品的本质核心都是利润，最好是持续盈利。我们所做的一切数据分析的核心是监控产品的核心指标，将数据可视化，为产品提供有价值的信息反馈。

　　所谓有价值的信息是指：

　　如果指标的数据分析并不能最终指导负责人或开发商如何让产品盈利，这些指标在产品运营方面都是“虚荣指标”。

　　如上所述，日常生活其实是B端产品中的一个虚荣指标。也许你的B端产品有大量的用户，但没有带来任何利润。这对我们毫无用处。最多，我们只实现精神上的自我。舒适。

　　当然，这个问题不仅存在于B端产品，也存在于C端产品。我们这里就不提了。

　　二、究竟如何

　　说了这么多，我们怎么回到现实呢？数据如何帮助我们识别和解决问题？接下来，我们来谈谈如何创建一个有价值的数据系统。

　　从B端产品抽象的角度来看，一定时期内使用的用户和业务规模是可以预测的，所以我们需要一套更精准的数据分析系统，也就是我们需要根据自己的情况对数据进行裁剪。拥有自己的核心业务。系统。具体来说，我们需要从以下两个方向着手：

　　1. 方向 1：流程效率

　　所谓流程效率，就是衡量一个需要用户执行的流程的复杂程度。具体来说，可以衡量的具体指标有以下四个：

　　(1）跨系统的数量

　　交互涉及的系统数量，比如客服系统，连接到商户后台、仓储、物流、支付等。这里的数字是5；

　　(2）参与此过程的人数

　　我们参与的一个流程需要多人参与，比如三级审批，这里我们需要一个一级审批人，一个二级审批人，一个三级审批人，所以一共有4个发起人；

　　(3）信息流页数

　　还是审批流程的例子，具体是指每个用户完成审批需要跳转的页面数，比如这个审批流程：

　　图1.原审批流程

　　前后浏览 4 页。当然，我们实际上可以将其缩减为以下三页：

　　图2.优化审批流程

　　整个流程去掉审批列表，当用户点击审批消息时，直接进入审批详情。不要小看这只是一个环节的减少。如果系统中的几十个模块全部减一，累积效果会很大。

　　(4）单用户操作数

　　用户需要执行几个操作才能完成此页面的动作，例如：在审批过程中，我们点击审核→填写5-10个汉字（20-40个键盘操作）→点击同意→确认是否同意→点击关闭弹窗→点击左上角返回→点击下一个审批项，一共7个操作。

　　你为什么这样做？

　　作为一款成熟的B端产品，它对企业有着明确的内部需求，所以它存在的核心意义是帮助用户更高效地完成任务，而不是增加负担。

　　因此，我们产品的重点应该是帮助用户提高效果，降低成本，规范流程。我们不能简单地靠感觉来评价，而是需要一个准确的数字来告诉我们当前产品的复杂性并找出问题所在。.

　　让我们看看上述指标如何与我之前制作的示例一起使用。

　　我们有一个面向企业的管理系统，我们的软件中有付费包，客户可以根据需要购买。

　　此前，由于历史原因，我们产品的内部采购历史由财务部门人工统计。现在，由于公司市场部的需要，我们需要开发一个模块来统计客户的消费。客户的消费类型可以分为以下两类：

　　产品内购买：客户可以直接在产品内购买服务。购买后需要财务确认。然后CRM用户会记录下订单信息，然后释放用户在产品中的权限。线下下单：通过线下销售团队完成线下产品销售，确认付款流程，然后将信息录入系统。由于线下销售一般具有一定的灵活性，我们的系统应该支持销售的定制化。用户包修改，如多赠送几个包等

　　在这种业务背景下，我们可以设计支付管理流程的第一个版本：

　　图3.Process A业务交互

　　接下来，让我们开始评估CRM中这个支付记录流程的效率：（我们使用需要人们访问的页面作为统计基准）。

　　我们如上拆解后，对这个过程的具体用户复杂度有了一个清晰的认识。我们系统中的单个信息记录需要3个系统和6个页面跳转。说太笨重了。好在找到问题后，可以有针对性地进行优化。

　　首先我们分析一下“穿越系统子项”和“参与这个动作的人”这两个指标，因为三者各有专业分工，所以不能简化，然后锁定我们的优化信息流的方向 优化了页面和操作。

　　细看流程A的设计思路，其实是面向最简单的技术实现的。我们把所有的操作和逻辑判断都交给用户，用户把流程往前推了一步，那么所有的动作都是用户必须的吗？完成它？有了这个起点，我们得到了流程B：

　　图4.流程B业务交互

　　既然要减少信息流的页数和操作次数，就必须引入大量的系统判断逻辑来完成。

　　第一个优化内容：这里，财务已经确认付款，项目必须处于已付款状态。此时CRM用户无需修改付费状态，系统会以财务确认为触发点自动修改状态。

　　第二个优化内容：由于是应用内购买，所以我们所有的购买信息都是标准化的，可以直接获取，所以这个时候不需要让CRM用户再次输入购买信息和权限，使用内置的即可- 系统中的信息。.

　　第三个优化内容：作为优秀的产品设计，必须考虑惊喜和扩展性。假设有支付信息和权限需要调整的场景。如果我们随意取消调整功能，系统将不再支持。. 但是这个场景的频率不是很高，那怎么设计呢？

　　这里我们介绍判断。如果CRM管理员不做任何更改，默认直接使用信息流和权限流，突发情况随时在线调整。这解决了这个看似矛盾的问题，同时，也绝对将大场景下的操作进行了简化，从 2 步操作变为低频的 0 步和 1 步。

　　完成以上优化后，我们再来看看两者的流程效率对比：

　　通过这次拆分，我们可以清楚地看到这次优化的效果，优化后运行提升了近76%，几乎是一个流程的重生提升。

　　2. 方向 2：功能生命周期

　　与上面的概念相比，这里的概念很容易理解。由软件生命周期演化而来的功能生命周期的参考维度是指功能从启动到迭代更新或替换的时间段。通过这个，我们可以看出产品设计能力的水平。高能力决定了长的功能生命周期，反之亦然。

　　对于B端产品来说，如果一个功能的生命周期太短，就意味着浪费了每一个开发人力，更严重的是延迟了新的盈利开发时间。因此，不仅这个功能需要返工，而且新模块的开发进度也被耽搁了，造成一倍以上的损失。

　　比如我们开发的审批模块，由于前期研究不足，不支持多人会签功能，发现不支持多人会签功能。这时候就需要返工开发，也就是标准的0个月生命周期。

　　因此，我们需要在之前的版本中统计每个函数在上线后的生命周期，力求延缓其生命周期。这里给你一个参考值，B端的良性生命周期：一般3到4个自然月。

　　您可以根据这个指标进行自测，看看您的产品是否也存在此类问题。

　　三、终于

　　B端产品成为近几年市场的新宠，不是因为这几年自身业务体系发生翻天覆地的变化，而是因为C端的人口红利随着这些年的发展而消失了，而资本和市场的注意力会自动转移。面对困难的企业业务，如何在新浪潮中站稳脚跟，是每个B端产品人必须思考的问题。而这里的数据是我们解决问题的最佳工具，帮助我们了解“人”，了解人的需求，了解人性。

　　#专栏作家#

　　三叶，微信公众号：三叶茶馆，大家都是产品经理专栏作家，2019年度作者。《中泰产品经理合集》作者，原万达资深产品，MBA特聘讲师，独立创业者，现任负责人叮咚买菜B端产品线，拥有从零到一的多种集团项目经验，引领实现商业化布局。

　　这篇文章 原创 由 每个人都是产品经理发布。未经许可禁止复制

　　题图来自Unsplash，基于CC0协议