思考|站在产品的角度,如何提升摩拜的单车使用频率

专为互联网人打造的365天成长计划,500门视频课程随便看,构建你的产品、运营知识体系。查看详情

这篇文章是站在一个产品的角度分析,如何通过设计功能来“提升摩拜的单车使用频率”?

摩拜单车对于用户的痛点:在想用车的时候随时都能有车可用。摩拜单车对于企业的痛点:提高每台单车的日均适用频次。

所以,这个需求的核心就是“需求匹配”的问题。最好的解决方式就是“大数据”。

摩拜单车和竞争对手相比,最大的优势就是:内置GPS让单车数据化;通过数据能不能让每台单车每次的停留时间控制在10分钟以内,每天的运营时间(12个小时)达到10个小时。每天的运营次数从3次提升到10次,这是我们需要思考的问题。

解决这个问题之前,我们可以先算一笔财物帐,了解这样做的经济价值。

一台车我们按1元/30分钟计算,目前一天的运营时间就是早上和晚上高峰期,同时中午可能会有一部分运营,早上2小时、中午1小时、晚上2小时,累计5小时的收入在10元,这还是最乐观的运营时间,一台单车1天的运营收入是10元,按照2000元的制造成本,还不算折旧和维护成本,收回这个成本的时间是200天。

问题来了,我们能不能让运营的时长提升到10个小时呢,同时提高单车的运营频次?每个小时每台车运营3次,这样1台单车1天的收入:3*10=30元。这样收回成本的周期压缩到67天。这就是提高单车使用率的价值。

不能达到10个小时的使用时长或者不能每个小时使用3次的核心原因是什么呢?

需求和供给信息不共享,没有达到高度匹配。说个场景:早上7:00-9:00之间,大部分单车早上都在地铁口,早上7:00-8:00之间出地铁的人,把单车都骑到了公司楼下,而8:00很少有写字楼的人往地铁口汽车的,导致8:00出地铁的人没有车可以骑,结果就是每个单车在这2个小时使用频次,很低最多2次。而大量的人在这个时间存在需求但是没有被满足。

我们能不能用互联网和大数据解决这个问题?

  1. 给用户一个“一键预约”,就是用户在下地铁前的15分钟,能一键“预约”自己将要出的地铁口的摩拜单车,总部数据中能根据预约的需求和各个地铁口存量单车的匹配,来安排附近的调度来运送车辆。(这就是摩拜的GPS发挥的竞争力)解决了高峰期车辆调度的问题,那平时调度怎么解决呢?
  2. 还是通过这个“一键预约”功能,出门前提前30分钟预约,比如在上午的10点,我计划周围的商场买点东西,附近没有车,我们的调度中心根据数据把需求分配給当地的运营中心,运营中心在30分钟内把车送到需求放制定的地点。

晚上10点钟了,我刚刚下班要去地铁口,这个时候公司门口的车早在7点钟就被放到了地铁口,怎么办?

这个时候就需要把9点钟放在地铁口的车送到各个公司的楼下,而这个时候“预约用车”把需求发送到数据中心,数据中心根据需求来调度车辆。当用户想用车的时候,用户有车可用,这就是摩拜单车用户最好的体验,至于我们平时讨论的车是否好奇,是否好解锁这种需求都是弱需求,刚性需求就是我想骑车的时候有车可骑。

当然每个城市的调度成本会很高,需要很多线下的三轮装运车不断的在这个区域运营,成本也会很高,我们还可以用互联网来解决:

通过互联网众包来解决用车的问题。比如用户A在地铁里发布了15分钟后要用车的需求,而这个时候用户B看到了这个需求,而且B正好想去地铁口,这个时候可以打车、可以坐公交,也可以骑摩拜,但是如果B骑摩拜去了地铁站,同时A用了B之前骑的车(B只需要做一个接单的操作,同时骑车去A指定的地点,A只要使用,那B就能得到2元的收入,可用于骑车使用)。

以上案例只是一个产品经理在思考一个功能的逻辑片段,所有的功能设计都不是感性的,尤其是互联网行业,需要严密的数学计算和逻辑推理,才会有一个小小的功能。

下次和你一起分析摩拜背后的那套基于大数据的调度系统,这才是真正提升单车效率的核心系统。

 

作者:汤垒,从业电商和互联网十年老兵,欢迎各个行业有想法的朋友深度交流。

本文由 @汤垒 原创发布于人人都是产品经理。未经许可,禁止转载。

打赏也是一种认可
4人打赏
评论
有话不说憋着难受!
  1. :oops: 我想说的是有车但不能用比没车用更烦人,简直在透支用户的耐心

    回复
  2. 太多人人写摩拜ofo了,看不到你的文章亮点在哪里

    回复
  3. 角度比较新颖,但是如何把调度的成本降下来是个问题。作为一个摩拜用户,个人觉得当前预约这个功能体验很差,因为没有任何标识显示车辆被预定,常常出现地铁口一堆的车,然后去扫码后发现连续好几辆都已经被预定了,多次就直接放弃了。另外针对已预定了车辆的人,也比较尴尬,一堆车放在一起,要通过编号找到它还是比较困难。

    回复
  4. 假如是一键预约,但同时就存在问题:没有预约的a用户刚好看到已经被b用户预约的车,是不是意味着a用户就用不了?这里就会产生一个问题,用户有车却用不了的窘境。

    回复
    1. 在此基础上再做一个假设,如果在同样地点预约了车的3用户来到指定地点,看到3辆车。他们其实是没有动机找到自己预约的那辆的,但如果他们随便用一辆的话,转送车辆的B如何得到收入? 然后会发现,咱俩的这两个假设中存在的问题似乎是不能同时解决的

      回复
    2. 所以其实作者在思考产品上还是存在一定的产品逻辑错误。这可能跟写产品与做产品的最大区别吧

      回复
  5. 其实共享单车的调度最大的问题在于成本不是么,一个用户需要车于是就安排调度员去给他送车,这个成本测算划算么。?

    回复
  6. 纯理论想法、完全不切实际

    回复
  7. 看到这个预约就知道这篇文章有点闭门造车。竞争对手很容易就可以利用你主动提供的功能,锁死你全部的车辆,只需要一周,用户就认为你的车子没法用。先在竞品这么多,可替换性太强。

    回复
    1. 得有个时间限制吧,不能一直等待预约啊,其实我不明白你说的如何锁死了啊

      回复
    2. 确实

      回复
    3. 新时代的产物在创新,在方向

      回复
  8. 1、作者所说的预约功能。个人觉得还是有些鸡肋的。现有的膜拜预约,是针对已经在使用点放置的车,可以提前十几分钟预约,然后使用,这一点还是蛮符合用户需求的,因为膜拜有GPS定位,用户可以查看附近的车位置,看到后可以先预约然后去找车骑车;如果不能预约,在用户找车的过程中,可能车就被其他用户骑走。如果一定要加用户使用预约,不妨设“发布使用需求”(就是作者所说的,例如提前30分钟发布消息说我要在10点用车从XX到XX地点)。用户提前发完使用需求,第一点便于商家统计用户的使用意向数据,第二点可以针对需求旺盛的地点,根据大数据估计供需关系,如果供小于需,可以调度车辆。这样用户发布消息,是为了提高用车成功率,不一定百分百保证有车用。
    2、就是调度车辆的方式,基于大数据是必要的前提。但是运送方式呢,如果有区域适合集中调配,那么三轮车装运是前期可用的手段(当然也要计算好投入产出比)。另外的采用传统的众包模式恐怕很难实行,比如推送用车消息会打扰用户、再有众包用户B把车送至地点,并不能保证发送需求的A正好能用到那辆车。个人觉得可以让用户A自主选择,要不要加入互帮运车,如果加入,当用户A周围有用车需求时,可推送消息到消息中心到A的消息中心,不一定是push推送,当A用车前可以查看这些信息,如果A领取任务,并且如约将车送达,就给A一定的奖励。再有就是A也可以发布用户需求消息。后期根据数据,可以将模式推广到全部用户

    回复
    1. 预约应该是 附近显示没有车辆,是吧,如果有的话 就不用了,如何保证这10分钟车还一直有呢,或者绑定一辆车 不让用 到了 ,都存在问题啊,还要细细的想 才行

      回复
    2. 对的,用户长期在附近住,对于有没有车会有一定的了解。如果知道XX时间一般没车,就可以提前发布使用需求。我觉得这些方面真要做,有很多细节要考虑,尤其是年轻用户爱用的共享单车,有潮时尚、年轻化的氛围,鼓励措施不能只考虑到钱、券,精神鼓励和趣味性才是更有效的

      回复
  9. 一键预约可以参考Uber滴滴的模式,对于想要接单并且顺路的用户,进行推送预约A的消息,同时限制推送的消息数量避免给想要接单的用户B造成干扰,可以限制最多推送3条可以接单消息;并且基于用户体验,用户B可以主动选择是否接单已经最近时间段不在接受推送。给予用户的奖励,考虑公司利益的最大化,可以采取免费的奖励,或者根据对预约用户A对用户B的及时性进行奖励……菜鸟拙见 交流

    回复
  10. 用大数据合理安排摩拜单车的位置,提高使用频率是很好很好的~但是互联网众包的话,感觉有点难推。比起微利,时间成本可能更贵一点,而且开了众包服务和相关的定位以后,假设真的有用户不停发布用车需求,那么一直推送的信息对其他客户来说可能是种打扰。如果不开推送通知,那么怎么才能及时看到别人的用车信息呢?只靠A和B自身的需求来匹配,还是蛮有限的吧~小菜鸟的一点点拙见

    回复
  11. 预测以后会有“单车专属调度员”的角色出现了-o- 就像饿了么跟蜂鸟专送的关系一样……

    回复