学术研究

您当前的位置: 首页 > 学术研究 > 论文荟萃 > 正文

冷静之后,我会如何做城市物流APP

发布时间:2015-08-24 11:22:11 万联网

自前几天发布《瞎搞!论当前城市物流APP》一文后,与很多朋友就城市配送问题进行了一系列的探讨。在这几天的思考中,通过对当前过度火热的互联网+浪潮的反思,脑子里不断浮现出关于从城市物流这个角度需要什么样的功能来支撑,来帮助城市物流的发展。以下,仅从我个人的角度展开,如果让我来做,我会怎么做。
  (注意,如果说还是迷信“滴滴模式”“Uber模式”,那么可以关闭此文,因为“滴滴模式”“Uber模式”并不适用于城市物流。)
  目标用户群体在哪儿?
  从严格的划分上来说,主要分为C端用户和B端用户两大类,C端用户主要以搬家为主(别提同城小件,就对个人而言,APP的价格竞争力永远比不上专业的同城快递公司),B端用户主要涵盖物流企业、专业市场、制造企业、电商O2O企业和商贸流通企业。每一类B端用户面向的收货市场又不相同,具体为:

但不是每一类企业都有对车辆的需求,对于B端用户,可以划分为三类,即增长型B端、平稳性B端和衰退型B端,以企业自购车为例,其每一段所需又不相同,具体为:    

因此,可以看到并不是所有的B端用户都只是简单的需要车辆。因为对于大多数的目标客户来说,他们都有一个固定的车辆熟人圈,别提平台的各种认证,那是APPs认证的事,目标客户会认为他们自己认证的车辆更加靠谱,因此只有针对快速增长型的用户,因熟人车辆的限制才需要大规模的引入车辆。就算是处于稳定型和衰退型的企业,他也会优先考虑自己的熟人车辆。而管理功能和消化企业闲置的资源也是用户的需求点,而这两点除了重庆本土一家叫“CE货的”之外,测试过的其他所有的APP都缺失的。
  运作模式如何设计?
  配送不等同于运输,配送的复杂程度远大于运输,且上文也提到,简单的照搬运输点对点的功能是不能满足整体城市的配送需求,且也毫无竞争力可言,但在该部分又因保有一定的业务量,因此不能割舍。但对于宅配、商超配送应该作为重点产品单独划分出来(如果划分更加细致,则可将家电宅配、生鲜宅配、普货宅配)。如果说传统的部分,即直送仓库部分可以采用传统APP所具备的点对点匹配的话,那么该部分必须以SOP运作标准为基础,以专业化的运作团队、车辆团队为核心,且该部分必须是实打实的培训,而不是一纸空文一笔带过。
  目前整个物流市场已经被200多个APP所自称的“标准”搞得够乱了,再我看来,他们所谓的“标准”即是没有标准。APP是产品,输出的各种形态也是产品,而很多APP忽略到了这一点。家电宅配,生鲜宅配,普货宅配,商超配送,每一种不同类别的配送方式均涵盖有不同的服务特性,必须根据每种不同的服务特性去完成不同的服务产品,而不是胡子眉毛一把抓,至于具体的每种产品如何设计,因篇幅原因,这里就不一一细说了。
  接单模式如何设计?
  在《瞎搞》一文中,我狠批了一下抢单和竞价模式,这里声明一下,并不是该模式不行,而是目前采用的这模式太过于简单粗暴,正如某些部门懒政一样,采取头疼医头脚疼医脚的做法。整体的定价模式采取议价制,让供需两端根据市场自行进行商议的方式完成,但仅仅依靠议价机制,会大幅提高准入门槛和流程消耗时间,不利于客户体验,容易导致用户流失。因此需要以大数据为基础,并在背后加入众多的参考维度以缩短后台数据计算时间,能够快速得到该线路历史服务价格。这还远远不够,还需再结合发运订单的时间,天气情况等众多实时客观因素综合起来后给出最终的价格供用户进行参考。因整体参考了的是历史运价,且城市配送具备一定的波动性,因此会设置一个区间范围让用户对价格进行相应的调整。在用户下单后,同样系统根据用户下单的相关参数对符合该条件的车辆进行小范围的推送,由接收到相关信息的司机进行价格反馈(当然,在界面设计上会趋于人性化的快速反馈机制),让货主选择他个人认为最为合适的车辆。当然,这里面有需要机制需要进行设置,具体的设置方式因篇幅原因,就不一一细谈,如果有兴趣,我们可以私下探讨。
  管理模式如何设计?
  我的货送到哪儿了?怎么货还没到?我今天发运了多少订单,发运金额是多少?我这个月发了多少,及时率如何?每一单耗时多少,我该如何跟我的客户承诺多少时间送到?等等诸如此类的问题。目前市面上提供的产品大多数仅仅是显示一个几个订单状态,在历史订单做沉淀就完事了。在精细化标准的今天,很多客户都有对自己物流板块经营情况的分析需求,但让他们购买一个信息系统是不现实的,采用手工台账是落后的。因此,一些简单的信息系统功能是应该具备的,对于技术成熟的今天,这些功能要实现不难。
  另根据心理特征,人们对未知的事物都是带有恐惧的心理,当货离开货主手中之后,往往需要一个跟踪信息反馈,让货主放心,放心他的货能够按时抵达,放心他的货不会串货等等。而这一点,我在3月份测试一号货车的时候,没有,到7月份测试的时候,还是没有(第一次测试的时候我是有打客服电话提出这个问题)。
  总结
  首先从C端用户说起,C端用户主要以搬家为主,而我们知道C端用户对于物流而言是非常不稳定的,其不稳定性在于需求不稳定,忠诚度难以培养(不要提德邦,德邦的主要用户群是在于企业,而非个人,对于个人,是坑一票算一票,当然这是我一家之言,因为我被坑过,所以借这里吐槽一下)。其向B端的转化率非常低。而B端,因收货目的地不同,不能简单的以车货匹配为基点,那毫无竞争力可言,点对点的以仓库为目的地的配送,人人都可以做,无外乎就是比谁烧钱烧得厉害,但毫无收益可言。因此个人认为应该突出专业化的设计来提升竞争力,搞定别人搞定不了的,设立起竞争壁垒。
  模式的设计总共只写了最为关键的三个部分,每个部分的设计都本着如何给客户解决麻烦,而不是去添堵的角度出发的实际问题。其中还想涉入虚拟仓库集拼之后的共同配送,动态拼车,批量车辆管理等功能设计,如果细化下去肯定是又臭又长,有点类似于产品说明书了,这里就不细说。整体上,想表达的是,产品的设计,要根据实际城市物流上产生的问题进行针对性的解决,而不是运用变质的“互联网思维”进行简单的改造。互联网只是工具,这个工具让我们的效率更加的快速,而非打着这个旗号忽悠。
  以上内容,是我个人的想法,再次声明,该观点与我所在的公司宝供物流无关。

首页