生鲜B2B平台的产品体系如何迭代

严德红 发布于 2018/06/28

我们在上一篇业务部分的介绍中谈到,我们生鲜B2B的业务逻辑是围绕“规模-成本-效率”这三个关键字进行的,同理,产品也一样,也是围绕这三个关键字进行的,我们思考的问题是:如何通过产品来提升效率、降低成本、并实现规模化的增长,但同时,我们一直秉承的一个产品理念是:产品支持业务的天经地义的,但产品仅仅支持业务是不够的,产品必须长出自己的能力,产品部在宋小菜本身就是一个业务部门。

我们在第一篇文章中也介绍到了我们八大产品模块,但罗马不是一日建成的,我们也是通过三年时间逐步迭代的,下面我们将会介绍我们的产品是如何一步一步来迭代的,给大家看一张大图:

21.png | center | 747x421

可以看到,我们的产品体系是有一条清晰的演变路径的,从1.0到6.0分别是:

1.0产品体系:1.0产品的主要目的是让交易在线化,打造交易平台相关产品,包括基础的商品系统、用户系统、定价系统、支付系统、订单系统等关键模块,并需要为规模化扩张做准备;
2.0产品体系:2.0产品的主要目的是提升效率,开发一系列提升效率的工具产品,包括:供应链效率、物流效率、销售效率以及协同效率;
3.0产品体系:3.0产品的主要目的是精细化运营,开发一套控制成本的产品,包括采购成本、营销成本、损耗成本、物流成本、人力成本等等;
4.0产品体系:4.0产品的主要目的是探索客户的规模化,为上下游的客户开发产品,比如行情工具、配菜工具、销售工具等等,通过这些产品积累上下游的客户,客户是平台化的蓄水池,客户足够多才能形成平台;
5.0产品体系:5.0产品的主要目的是探索扩大交易规模的产品,比如仓单交易,1.0的交易平台中,交易方式很单薄,只有简单的上下游批发交易,但随着客户越来越多,平台越来越大,会诞生很多新的交易方式;
6.0产品体系:6.0产品主要目的是探索公司盈利,不管任何B2B公司,最终是要赚钱的,后面一定要有实现利润规模化的产品;

下面将简单介绍一下从1.0到6.0产品体系的一些核心关键点:

在1.0产品体系中,既然我们定位是B2B交易平台,你得先有一套交易系统,我们做电商平台的同学都清楚,交易系统最基本的几个核心因子:用户、商品、订单、支付,这几个因子里面,对于非标商品交易系统来说,商品体系的搭建是最麻烦的,不像标品的交易,很简单就能描述出来,比如手机:iPhone X 256G 黑色,简单明了,但我们面对的是一堆土豆、青菜、胡萝卜,让一个客户看到结构化的商品信息就下单很难,但又不得不做,比如下面这个土豆:

22.jpeg | center | 693x507

我们要用来交易,是这么描述的:山东滕州荷兰十五土豆50斤纸箱装,还有很多属性,包括:自然属性、定装属性、品质属性,如下图:

23.png | center | 261x458

这样,才是一个我们可以交易的商品,并且每个品类的属性在前台长得都不一样,但在后台又需要聚合在一起,又要让发布商品变得很简单,所以必须设计一套灵活的类目属性库,我们把商品的结构分成:BSPU,SPU,SKU,我们把自然属性、运输规范、存储规范、品质规范等属性挂在BSPU下面,把包装属性、产地属性、品牌属性、规格属性等挂载在SPU下面,真正可以交易的是SKU,包含了:价格、库存等等,如下图:

24.jpeg | center | 551x499

有了这一套商品的产品架构,我们才真正做到非标农产品可交易,并且只需要通过简单的配置,就可以快速发布各种类目、各种属性的商品,真正做到可交易;
另外,在1.0产品体系中,支付也是一个非常麻烦的事情,所有的B2B平台都面临这个难题,我们也经历了多个支付产品的变迁,最早我们采用的收现金的方式,由于B2B都是大额交易,大额的现金收付款都面临了安全问题,早期我们的工作人员经常拿着超过10万的现金跑去存款,非常不安全,后来,我们在产品上陆陆续续上了三种线上支付:支付宝支付、微信支付、网银支付,但又面临一个手续费很贵的问题,虽然拿到了最低0.25%的最低费率,一个月也需要数十万的手续费,这对平台来说负担很大,直到后来和银行合作,开发了一套“银企直连”的产品,客户可通过任何银行的客户端转账到我们的公司账号,我们通过API的方式获取支付数据,实时同步到我们自己的账户系统中,这样不需要任何手续费,又能实时到账,非常方便。

到了2.0产品体系,我们的产品都是围绕“效率”这个关键字进行的,对于物流效率,B2B是快速流转的,刚开始我们在仓储上花了很多精力做产品,做了一套WMS系统,后来发现货物大多在路上,货物在高速的流转,动销非常快,才将注意力转移到物流调度的TMS上面,线路规划、线路调度这些都是常规的功能,由于生鲜产品的特殊性,对于保鲜要求很高,所以到货时间很重要,TMS系统里面的司机GPS轨迹抓取就变成了很重要的事情,我们研究了各种型号的手机,让司机在使用我们宋小菜司机版的时候能够实时将GPS位置传输回来,只有这样,才能让我们的货物流转更有效率,客户接货时间也更好把控;
销售效率和内部协同效率也非常重要,由于市场客户的特性决定,我们有大量的销售地推人员活跃在各个农贸市场,进行客户拜访和商品推销,我们开发了一套CRM销售系统帮助提升效率,首先我们会对客户leads进行划分,分为私海和公海,销售人员领取自己的客户leads资源,如长期不成交系统会自动回收leads资源,销售人员每次拜访前,都需要写拜访计划,销售主管会根据拜访计划进行陪访,到达市场后,通过CRM进行签到,拜访结束后再将拜访记录填写到系统中,整个客户资源管理和拜访管理全部在CRM系统中进行;另外,我们底层有一套“工单系统”支撑各个业务部门之间的协同工作,比如我们前面讲到的“反向供应链”就需要一套快速响应的工单来支持,销售在下游集单完成,发起工单,采购人员接单,向供应商发起工单,供应商加工完成,向物流人员发起工单,物流人员又向司机发送,直到货品送到客户手中,我们用这一套工单系统串起整个交易流程,来提升整个公司的协同效率。

在3.0产品体系中,我们的关注的是“成本”,B2B是一个毛利低的苦活,必须精细化运营才有可能赚钱,对于利润计算,最重要的是要对成本计算形成数据闭环,必须对采购成本、营销成本、物流成本、损耗成本、人力成本几个关键成本完成成本数据采集,我们内部形成了一套计算公式,能够在当日对利润进行预估,在次日系统可以出利润精准的报表;关于成本的计算,之前遇到一个棘手的问题,成本必须和批次关联,需要单个批次计算成本,这时候有两个方案,方案一在每箱上面贴一个唯一的批次号,方案二通过先进先出的算法进行相对精准的批次匹配,最后综合考虑下来,我们选定方案二,从投入产出比来看,因为农产品的动销实在太快了,一箱货从加工好到运到终端市场不超过24小时,批次号的生命周期太短,数量又多,每箱贴批次号的人工成本太高,对线下人员提货也增加了要求(必须按照批次提),我们采取方案二,用算法进行批次匹配,虽然没法做到100%精准,但也可以把误差做到0.1%以内,这个误差完全可以接受,所以产品也是在不断权衡投入产出比,而不是盲目的追求理想化。

对于4.0产品体系,因为前面1.0到3.0,我们基本形成了“规模-成本-效率”的产品闭环,完成了B2B平台的0到1,后面,我们需要规模化扩张,必须有海量的用户才可以称之为平台,在4.0产品设计中,我们重点关注,如何通过互联网的产品获取海量的潜在交易用户,比如我们通过用户每天都非常关注的、高频的蔬菜行情信息切入,获取海量的潜在用户,让用户每天活跃在我们的平台上,为交易平台养一个很大的蓄水池,为平台蓄客,然后再通过运营手段逐步将这些用户转化为交易用户,所以4.0产品要关注如何获取海量潜在客户,为平台化作准备,有了4.0产品,就慢慢有了海量用户,用户在平台上之后,除了看行情、卖货、买货等等这些操作之外,随着平台上的角色越来越多越来越丰富,自然会衍生出一些新的业务形态,比如租冷库的、做加工厂的、做仓单交易的等等,平台会越来越丰满,用户也会越来越离不开这个平台,我们5.0和6.0都是围绕在前面的基础上迭代的,产品逻辑也类似,这里不再详述,我们的产品体系始终在围绕“规模-效率-成本”在进行。

对于B2B行业的互联网产品,必须想清楚B2B行业的特征和背后的逻辑,和ToC行业区别很大,内部产品提升效率和降低成本,外部产品提升用户数和平台化、规模化的复制,最后都是围绕交易进行,想清楚逻辑后,我们围绕“规模-效率-成本”这几个关键字,可以先整理一张产品大图,想清楚优先级,然后一个一个版本快速迭代,最终长成我们想要的平台,平台从来不是规划出来的,是一步一步长出来的,我们的产品体系就是这么一步一步走过来的。