某互联网租车平台的复盘——如何hold住一整个行业

交个朋友，分享一下我的经验。

请不要复制和转载本文，谢谢理解。

2021年下半年，帮一家互联网租车平台公司做了一些事情，解决了两个重要的问题：

一个是，这个平台如何实现规模化增长。

另一个是，车辆出租率的最大化。

其实，问题的出发点是第一个问题，也就是，如何实现规模化增长。而车辆出租率最大化这个问题，只是在后来的分析中，发现这是影响规模化增长的一个关键，所以才会去解决它。

一、分析和思路

对于一家创业公司来说，增长几乎决定它的生死。

所以，我需要围绕着增长来做整体的产品架构。

一个租车平台，如何实现规模化增长？

首先，核心指标是什么？（第一关键指标是什么？）

有效订单量。

总的来说，这是一个交易平台产品。所以，它的核心指标只能是订单量或其它可以更精准表示卖了多少的指标（比如，酒店的销售用的“间夜量”）。只是，租车这个领域有一点特别。至少对于它这个平台来说，订单的取消率比较高（据说，整个行业也是这种情况）。

所以，最后，把核心指标定为：有效订单量。

提升有效订单量，无非是两点，一个是提高订单量，一个是降低订单的取消率。

订单的取消率高的根本原因，其实是供需的匹配度不高。

而，对于订单量的增长来说，关键也在于供需的匹配度。

注：其实，对于所有交易类产品来说，订单增长的关键都在供需匹配上。

1、首先，需求侧。

租车的目的是什么？也就是，租车去做什么？

旅游？上下班？商务接待？。。。

无论哪个方向，都会有大量的细分的场景。每一个场景，除了需要一辆车还会需要什么？

比如：周末，一家人租一辆车去北京古北水镇，周边游，两天一夜。除了一辆车，至少还需要一个酒店。

所以，租车的供需匹配的关键点在于，如何匹配租车的全场景和每一个细分场景？

2、然后，供应侧。

做大供应是订单量规模化增长的前提条件。

做大供应也是匹配租车的全场景和每一个细分场景的前提条件。

因为要匹配租车的全场景，所以，做大供应不仅仅是“量”的方面，还有“面”的方面。

做大供应量在于两点：

一个是B端租户的增长，也就是租车公司的增长，这意味着整个平台的车辆数量的增长。

另一个，是释放车辆出租的”未来库存“。这意味着，车辆数量保持不变，而车辆出租业务的供应量大幅度增长。

对于B端租户的增长，市场上，携程的租车宝、悟空租车、神州租车等都已经做了多年，优势明显。要想让B端租户大幅度增长，必须要找到一个能极大吸引B端的点，并且在这个点上要明显做的比竞争对手强。

对于释放“未来库存”，释放车辆的“未来库存”是将车辆的利用率最大化的关键。车辆的利用率，在租车这行有个专用的词：车辆出租率。

关于“未来库存”的问题：因为车租出去后，还车时间是无法确定的，所以导致“未来库存”不确定，所以“未来库存”不可用。进而，导致车辆利用率的浪费。

关于这个问题的详细描述可以参考：

https://www.lyustu.com/%e6%88%91%e7%9a%842021%e5%b9%b4%e5%b9%b4%e7%bb%88%e6%80%bb%e7%bb%93-%e4%bd%8e%e4%bb%a3%e7%a0%81%e5%bc%80%e5%8f%91%e5%b9%b3%e5%8f%b0%e5%92%8c%e8%bd%a6%e8%be%86%e5%87%ba%e7%a7%9f/

车辆出租率的最大化意味着两点：

• 租车公司的成本保持不变，但利润可以最大化。
• 车辆总数不变，但车辆出租业务的“供应量”最大化。也就是说，车还是那些车，但却可以接更多、甚至最多的订单，赚更多、甚至最多的钱。

这一点，对B端的吸引力是很强的。

而这一点，市面上没有一个租车平台能做到。

所以，做大供应量的关键点就在这里了。

做大供应面的关键在于：“卖”和“用”的分离。

举例说明一下。

• 周末，一家人租车去北京周边游，古北水镇，两天一夜。
• 周二，租一辆车去上班。

在这两个场景中，车，可以是同一辆。但需求是明显不同的。

第一个场景中，车，需要两天的日租，需要提前预约。另外，再打包一个酒店会更匹配它的需求。

第二个场景中，车，需要即时用车，分时租赁，用一两个小时就够了。也不需要别的东西。

也就是说，两个场景中，车，可以是同一辆，但需要的租车的“商品”是不一样的。

原有的方式，也是整个互联网租车领域通用的方式：车辆按照事先定好的价格模板实现计费。

其实，就是把“卖”和“用”合并到一起。这样，就导致“卖”得很死板，没有办法精准匹配租车全场景和每一个细分场景。

上面的例子，原有的方式，可以这么理解，车是同一辆车，那么，租车的“商品”也是同一个“商品”。

所以，做大供应面的关键就是把“卖”和“用”分离。

这样一来，可以把租车这件事做成各种各样的“商品”，甚至搭配各种其它资源或第三方产品（比如司机、酒店、机票、保险等等），做出匹配各种各样租车场景的“商品”，提高供需匹配度。

也就是说，做到“卖”和“用”的分离后，上面的例子，车是同一辆车，但租车的“商品”不再是同一个“商品”。

做出自己的优势和核心竞争力

其实，现在，国内主要的租车平台都是这样一个情况。像携程的租车宝、悟空租车等都是实现了基本的租车业务，也就是“卖”和“用”是合并在一起的。但，这些平台做了很多年，已经在行业中形成了自己的优势。

一个新的创业项目，如果没有比竞争对手更大的优势，没有自己的核心竞争力，基本没什么成功的可能性。所以，照搬竞争对手的、成熟的产品模式是行不通的。

解决车辆出租率最大化的问题，对于B端（也就是租车公司）来说，是一个强大的吸引力。其实，租车公司每天做的事情，主要都是在想方设法做大车辆的出租率，因为，这直接影响它的利润。

将“卖”和“用”分离，做大供应面，匹配租车的每一个细分场景，匹配每一个租车细分场景的用户需求，对C用户来说，将产生一个巨大的吸引力，也会形成一个比竞争对手更大的优势。

所以，做好这两点，无论对于B端的增长，还是C端的增长，都将成为关键。也是做出自己在互联网租车领域内的核心竞争力的关键。

二、Plan

1、增长模型

基于以上，可以搞出一个增长模型

• 核心：租车的“商品”。
• 上游生态：通过各种类型的X产品来做大租车“商品”匹配的租车场景，也就是做大供应的“面”。（上方）
• 下游生态：右侧，通过佣金换入口计划，利用开放平台、销售返佣的方式，快速和规模化地做多入口，做大有效流量、目标用户群和订单量。
• 入口和转化：有了以上基础，左侧，通过打开各种流量入口，然后，通过供需匹配来做大订单量。产品上，准备通过TO C的打包平台、推荐算法等方法提高匹配。

这里，有几件事值得说一下。

一个是用户生态。

抛开“供应”这件事，租车，还剩下两件事，那就是“卖”和“用”。这个增长模型，其实全都在“供应”和“卖”的层面，当然，主要是“卖”的层面。

租车这件事，“用”是一件比“卖”更重的事情。用户用车的过程是一个比较长的过程，在这个过程中，用户会经历很多场景，也经常会产生一些问题需要和平台或租车公司沟通，甚至像还车、续租等是必须使用这个租车平台的APP/小程序的。如何基于这些做好用户生态，促使用户产出内容、让用户对平台产生依赖、让用户愿意去传播这个平台，进而影响其周围的人，是非常值得探讨和尝试的事情。这个事情如果做的好，会产生另一个巨大的增长动力。促进用户和订单的增长。

当时，曾讨论过租车用户的一些基本的关键点。他们提出一个字：私。他们觉得这是最重要的。

就是说，用户租车，不想让别人知道这是租的。所以，他们要做好“私”。

而，我提出另一个字：“群”。挖掘租车用户的共同属性，让他们产生相互认同，进而对平台产生一定的依赖。其实就是基于“用”建立用户生态，进而促进用户和订单的健康增长的一个方面。

然而，在这个阶段的计划中，我并没有把用户生态这件事放进去。因为，对于创业的初始阶段，更需要的是简单粗暴和有效的增长，这样才能用最保险的方式让这个创业项目活下来。而，用户生态的建设是一个需要在数据分析基础上不断试错才能“试”出来的，这个过程会比较长，不可能一蹴而就。所以，第一个大阶段就围绕着这个增长模型做。而第二个大阶段再考虑建设用户生态，把它做成这个平台的第二增长极。详见后边的“演进路线”。

另一个是用户画像

他们说要建用户画像，我给他们的建议是，不要建那种大而全的、笼统的用户画像，因为，没有什么实际的作用。要根据租车的目的来建用户画像，不用考虑所有的租车的目的，只要考虑现在平台上的这些用户租车的目的即可，根据具体的租车的目的去建用户画像。

其实，这个建议，一方面，可以清楚地了解当下用户群的具体情况，找到具体的问题所在，另一方面，其实也是在为后续的推荐引擎做准备（增长模型左侧）。

当然，这个增长模型，如果解决不了“卖”和“用”的分离，是实现不了的。

2、产品架构

基于这个增长模型做产品架构。

具体的图就不放出来了。

大的方面，划分为平台产品和业务产品。

平台产品包括：消费侧、供应侧和管理侧（供应侧和管理侧后续的计划中，合并到一起。）

业务产品其实就是这个平台的SPU。

主要包括（在原有的一个基本的租车系统的基础上增加）：SPU系统、库存系统、整合优惠系统、开放平台、推荐引擎、C端打包平台等。

三、租车，是卖什么的？

不管是匹配租车全场景，车辆出租率最大化，还是“卖”和“用”的分离，都涉及到一个核心问题：租车，是卖什么的？

也就是，租车业务的SPU和SKU分别是什么？

原有的方式（车辆按照事先定好的价格模板实现计费）对这个问题是不明确的，所以没有实现“卖”和“用”的分离，没有这个基础，也就没法做到车辆出租率最大化和匹配租车全场景。

租车，卖的是一辆车的一段时间。

所以，参考酒店的最小库存单位——间夜（一个房间一个晚上），我搞出来了三个词：车日（一辆车一天）、车时（一辆车一小时）、车分（一辆车一分钟）。

用哪一个做SKU（最小库存单位）？

这个问题花了我整整一个星期的时间。在此期间，我分别用这三个单位为基础分别进行推演，将各种各样的租车业务依次用这三个单位去尝试处理。最后，确定，用车分，也只能用车分。

至于，SPU，有两种，一种是一堆车分的打包（定义为租车SPU，后来为了避免歧义，改为车型SPU），另一种是一堆车分再加上X产品的打包（定义为：车+X）。
X产品，可以是司机、酒店、机票、保险等等。

至此，租车是卖什么的？这个问题确定了。

“卖”和“用”的分离，SPU和SKU的确定，改变了整个互联网租车领域的产品模式，将竞争对手多年积累的、至少是产品方面的优势，消除掉了。

SKU确定了，那么库存系统的“基石”就有了。有了这块“基石”，就可以对库存的变化进行抽象建模了。

另：SKU确定之后，可以将原来定的核心指标——有效订单量，改为“车分”，因为这个可以更精准的表示“卖了多少？”

库存系统主要解决了车辆出租率最大化的问题，同时，也是将“卖”和“用”分离的关键。

四、库存系统

此处略去，核心的东西不便放出。

1、建模

此处略去。

2、策略和算法

此处略去

3、系统架构

此处略去

库存系统的架构上，还特别考虑了两件事，一个是高度可扩展性，另一个是自动化，无需人为干预。

高度可扩展性，是因为考虑到未来，随着租车业务可能出现的各种形态，有可能会产生更多的库存的“常态变化”，这个时候就需要对库存系统做相应扩展。

自动化，库存系统的运行是完全的自动化的，它默默地运行在平台的背后，默默地记录着库存的变化，默默地影响着用户的下单和使用，默默地为平台和租户创造着价值。。。

唯一能感知到库存系统的就是后台的库存日历，可以看到每辆车的出租率以及用数据可视化的方法展现的库存的具体使用情况。

租车业务的全流程的自动化、无人化，可以从最大程度上降低出租一辆车的边际成本，而这个基础就是库存系统，库存系统完全的自动化是租车全流程自动化、无人化的前提条件。所以，库存系统在设计的过程中，特别考虑了这一点。

在库存系统的设计过程中，也对订单系统和车辆管理系统做了一些相应的调整。有一点值得说一下。在订单管理系统中，有一个人工配车的环节，原本，基于库存系统，只需要增加一些策略和算法，就可以将人工配车变成自动配车。但，在这里，我特意保留了人工配车，只是用策略和算法帮助人工配车，加快人工配车的效率。之所以这样做，是考虑到库存系统上线后需要在大量的实际运营中不断完善，在这个过程中，人工配车环节可以有效地应对一些突发、特殊情况，而且，也只有在大量的实际运营中，才能积累大量的人工配车环节的场景，这样，才能知道人工配车环节要用什么策略和算法才能更好地转成自动配车。

五、演进路线

1、第一个大阶段：活下来并站稳脚跟。

基于以上增长模型，快速实现订单增长，并做出自己的核心竞争力。

2、第二个大阶段：成为市场主要玩家之一

探索和建设用户生态，形成第二个增长极。扩展上下游生态，包括更多的与车有关的企业，包括主机厂、车辆销售终端等，探索和建设多方利益生态。利用生态建设做大自己，打击对手，以图拿到市场最大份额。

3、第三个大阶段：全业务的自动化

一方面，出租一辆车，是有成本的。降低一辆车出租的边际成本，最重要的，就是逐渐将租车的全业务流程自动化、无人化。

另一方面，互联网租车，全业务的自动化是必然的。随着自动驾驶和智能汽车的逐渐深入发展和普及，甚至，用户的用车都可以逐渐自动化。

所以，这个领域的竞争，迟早会在自动化、智能化用车方面展开。谁能及早占位，谁就能拿到“未来”的主动权，随着时间的发展，逐渐占领市场更大的份额。

甚至，有可能，在自动驾驶和智能汽车时代，租车和打车会成为主要的用车方式。如果是这样，那这个市场会，很大。

这也是我为什么会把库存系统做成完全的自动化、智能化、无需人工干预的系统的原因。作为租车业务的“底层”的库存系统的自动化，为后续整个租车业务的自动化和无人化打下了坚实的基础。

六、总结

做完这次复盘，不禁感慨，虽然以前没有做过互联网租车这个领域，但这件事，处处都打着“过去”的烙印。

1、关于“供需匹配”

过去的经历让我快速找到整个事情的关键——供需匹配。

早年，我做的事情是“一切为了流量”，后来逐渐发现了问题，转化不了的流量没什么用。于是将重点转移到“一切以转化为中心”（在做电商的那段时间，主要做这件事）。再到后来，逐渐地意识到，增长和转化的关键其实是在供应侧和供需匹配。在某厂做机票时，做了很多供应侧的事情。（其实，某厂本身就很重视供应侧。某厂之所以有今天，关键之一就是供应侧。）

2、关于抽象建模

离开某厂后的差不多三年的时间里，我做了很多智慧城市、机器人的项目。实际上，是对人工智能技术在各种实际的场景中的落地。

在这个过程中，我需要对各种现实世界的场景和线下业务进行抽象建模。比如，对机场的人流进行抽象建模（智慧机场项目，解决机场的三大问题：提升机场运营效率、提升机场盈利能力、提高旅客出行体验。）、对停车这件事进行抽象建模（某机场大型停车楼的智慧停车项目。）、对导游的工作进行抽象建模（导游机器人，解决问题：如何让机器人代替人类做导游的工作。）等等。

这算是那三年的自我拓展中最重要的收获之一吧，而这次，这个成果用在了库存系统上。

3、关于系统架构这件事。

早年创业的时候，因为用过很多国内的CMS、论坛系统，也自己做过，但都很不满意，直到后来用了一次XOOPS，才意识到架构的重要性。

XOOPS，是当年全世界最流行的CMS，在台湾地区被称作“架站机”，只是国内，很少有人用。

从那以后，业余时间经常研究各种开源系统的架构，这件事，玩了十几年。

XOOPS、wordpress、drupal、joomla、symfony、laravel、angularjs、react native、nuxt等，这些优秀的开源系统和框架都曾研究过，重点就是架构。尤其是wordpress和drupal，对我影响最大，我这两年做自己搞的BAAS（后端即服务）和低代码开发平台（前端平台），处处可见这两个系统的“影子”。

https://www.lyustu.com/cms们的世界观和方法论/

所以，这次的库存系统的架构，只不过是多年积累的一次“小试牛刀”。

4、关于核心竞争力这件事

我做产品会特别注意这件事。

因为早年的创业，虽然赚了些钱，但总的来说，是失败的。后来的多次复盘和总结经验教训，最终得出的结论就是，当时做的事情，根本就没有任何竞争力。

所以在后来的工作中，越来越看重一个产品的核心竞争力，或者说“硬实力”。

5、关于生态建设这件事

上下游生态

从早年的站长之间的流量互换，到在IT168时，正式地建设流量生态（内容换流量，和全国的地方站、个人合作）以提升it168.com和che168.com的流量，再到做某厂机票时，整体考虑航旅的上下游生态。以至于，现在，做产品会考虑一整个行业。

用户生态

我算是做站长出身的。所以习惯了围绕着增长、成本和收益来做产品。

所有曾经出现过的增长方法都做过，有些做的还很好。

但是，实际上，最好的增长是基于用户的口碑、传播和参与。

所有在这方面做的事情，综合起来，就可以用一个词表示：用户生态。

这就是我为什么看重用户生态的建设的原因。也是我在长年的增长相关工作和经验总结的结果。

一手核心竞争力，一手生态建设。这算是我在做产品方面的一个特点吧。

就这些吧，本文请不要复制和转载，谢谢理解。