时间: 2021-08-03 08:47:23 人气: 13 评论: 0
易到2010年左右最早做专车时，企业服务是同步上线的；神州原来是做租车的，本来就有企业级服务，有专车后也同步上了专车的企业服务；还有传统租车的一嗨、美国的Uber，都是同步上线的企业服务。
最早滴滴打车是出租车服务，14年8月份的时候上线了专车，15年上线了企业级服务，但跟以上当时的竞对相比，滴滴的企业出行开始得并不早。
用车背后大多数人都是上班族，企业员工加班打车，最早都是用出租车。滴滴希望优化整个出租车的运营，所以第一时间想到做B端的业务。
企业级服务在用车服务中里是普遍的，在传统租车时代，企业用车是主流，而且是毛利非常高的业务；所以传统租车企业转到了网约车以后，自然**把这个业务保留。
企业自有车包括政府的公车本身的运营、维护、管理效率很低：滴滴通过移动端管理、调度司机端，平台技术是较先进的。
一线城市企业员工的加班用车、差旅用车较多，涉及到早晚高峰拥堵、交通费垫付多等；尤其是发票问题，多且报销复杂——这个是我们当初整个团队做了很多调研分析，发现的一个非常突出的问题。企业内部本身在交通费报销中的服务成本非常高，每个公司财务对交通出租车发票的开票要求还是不一样的，管理难度高。
所以我们希望通过搭建这样一个平台，让整个市场透明、供需平衡，用第三方公共服务的时候，整个报销付费流程都更便捷一些。将企业的用车进行市场化与平台化的运营，来降低企业因公用车部分的管理费用，以及提高员工的使用体验。
滴滴2B服务，提供的是出行服务和管理的解决方案，一开始是两个平行的方向：企业和政府。
滴滴开始做企业级用车的时候，内部就有包括出租车、专车、快车、大巴、代驾，顺风车等资源，企业、政府都可以使用；滴滴企业规划时就准备提供一个企业出行服务的统一平台，也就是可以整合滴滴外部的资源，包括企业自有的车等等。
有一个相对完整的规划，包括到现在也没有太多脱离当初的规划。
我们给企业服务的定位，分了三个模块：企业用车、政府用车，跟第三方的渠道合作用车。
企业用车分为行政用车和营销用车：
（1）行政用车-起因
C端用户逐步起量，但那时候竞争还是比较激烈的。刚提项目的时候，其实主要还是针对“快的”的营销补贴大战，希望寻找其他办法帮助打赢这场仗，或者其他业务线能够出力。
所以出了企业用车，主要涉及到三个方向：
总结起来就是：企业和个人都有用车需求，企业可以决定一些个人的行为（比如在公司用OA系统，企业所有的相关的业务都在上面，要跟其他同事、其他部门协同，不管体验好不好，都必须要用公司指定的），有利于C端用户留存和降低营销费用。
（2）行政用车-定位
整个业务的逻辑其实比较简单，包装C端已经成型的公车，提供给B端。这样就有两个收入的来源：C端用车服务的渠道佣金，B端用车服务的服务费。
（3）行政用车-场景
提供这样的服务，其实遇到过很多问题，最早碰到的其实是合规的问题。因为那个时候网约车的法规还没出，我们面临最大的问题是企业能不能接受开具的统一的发票——不是出租车发票。我们要先去破企业这一块，我们最早的时候都跟财务打交道，拿这个做报销凭证能不能认啊？——现在整个互联网企业应该都认识滴滴开的发票，但当初推的时候还是挺难的。
拓展客户的时候，最早外企是进不去的，基本上就是合规没解决不能用。其实在企业级用车服务里面，当时的环境是最大的门槛。
也**涉及到很多产品服务的问题，比如一些反作弊的问题、第三方合作中的一口价问题、以及很多其他的细节问题。
（4）行政用车-核心产品
整个行政用车最核心的是两条线，企业支付和个人支付。
通过企业支付跟个人垫付，基本上就满足了所有企业因公出行报销的需求。通过这个体系，企业一般都通过规则管好；如果不行的话，就上个人垫付跟线上报销，也很简单——就是在支付的时候，选择个人支付，需要报销就打个标签，在系统里面就**另外归类，月底报销的时候直接**在报销模块出现——提交——审核——报销一气呵成。
整个业务流程细讲的话，其实是一个特别复杂的流程。但凡有财务介入的，整个资金链的管理、对账**非常麻烦，而且合规不合规由企业说了算。跟企业之间有很多交互，甚至有的部分还得跟用车的员工进行交互，所以**有很多麻烦。
这些怎么绕过呢？其实如果我们做得更多一点，比如说跟人家的财务系统、或者第三方的财务软件打通。
B端流程**特别多，时间周期也**比较长，但毕竟是一个管理，员工很少**讲平台体验不好，毕竟是平台跟企业一起制定的规则。所以但凡用了企业用车、特别是企业支付的逻辑以后，用户的留存相当高。
（5）行政用车-思考
（1）营销用车-起因
北上广深杭以外企业加班不多，加班用车起不来量；
很多企业利用企业版的代叫车业务做营销活动，尤其是代理商所在二三线城市；
特别是二三线城市里面都是代理商帮我们拓展企业客户，我们跟他们分成。但是出于反作弊的原则，比如一个人同一时间段代叫车很多，有可能代叫完以后不支付，形成坏账，因此我们**阻止。
在这种情况下，企业就有很多投诉——为什么一个人不能叫多个，我们帮客户叫车还得几个人一个一个下单？
后来，我们就推出了营销用车。逻辑上来讲，其实是把我们的B端用车服务跟客户的业务连接。最简单的，比如客户服务他的客户（代叫车等）；另外还有一些客户的运营活动、营销活动用车等。
这种模式下我们虽然赚的钱还是一样的，但是逻辑不一样，服务的客户也不一样。拿我们的产品帮助用户，在他的产品和服务里面实现增值。
（2）营销用车-核心产品
这里面的一个典型产品就是企业邀约**。
因为我们当初做邀约**分了七个方向，通过代叫车，可以控制出发地、目的地、指定的手机号来进行营销活动等，但还是**出现比如说恶意的**、用户企业支付做私人的事情、或者恶意地进行一些多的费用结算等。
后来慢慢通过产品优化，我们推出了ABA模式，就是A叫车-B坐车-A支付，通过**或者红包的形式发出去，可以给企业做营销。比如有一家餐饮企业开店，客户打车来这个餐饮企业，或者吃完以后回家，企业**发邀约卷，然后整个用车的费用由企业来支付。
我们当初有跟房产中介合作专车看房，在整个营销场景里面，还设有美食专车、招聘专车等。要让客户过来，也不用告诉客户在哪，给他发个邀约**，锁定了地址，只要按个键叫个车师傅就知道到哪接客户，然后送到目的地。
我们那时候想了很多种场景，给用户做宣传，帮助一些企业利用用车这个行为做营销，拉新用户，然后知道用户相关的行为以及分布的区域，其实效果是非常好的。
（3）营销用车-思考
15-16年，公车改革风声比较紧的时期——那时候号称16年底要完成公车改革，各个地方必须拿出政策来说怎么干。
16年某市政府希望进行公车改革，让滴滴提供服务。然后我们就做了一套政府用车的平台（其实就是把滴滴的能力打包一下，给其市政府使用），应该现在还在用——这也是滴滴最早开始做租车业务，因为政府中带司机、不带司机的都**有。
政府用车的定位很简单，本身他们内部车辆管理就是个小滴滴，内部自己定价；另外他们还提了个建议，就是车辆如果不够的时候，希望滴滴的平台能把资源接进去。比如大的**议接待，或搞活动的时候，滴滴的车辆能服务政府的用户；另外就是政府的车辆闲置的时候，可以接外部的客户。
公车改革推进还是相对比较困难的，以上是个特别好的逻辑。因为当时大家看重的其实就是滴滴的运力，政府包括大的央企都有自己独立的用车服务公司，人员调度和各种车辆的维护都**希望跟我们合作，来将下面的车**活。
但因为那时候还没有合规、有各种顾忌，公车改革应该只是那一个市政府合作了，但是这个其实是进行公车改革的一个特别好的解决方案。
政府用车跟企业用车服务不一样，企业用车服务是通过C端，资源是公共平台提供的；但是政府用车的资源平台和车的类型也多，各种特种车辆、人员分类也多，有些甚至是领导专用车辆需要一对一绑定，还有一对多的绑定，然后整个车辆的管理、司机的管理都更加复杂。
所以单独给政府做了一个政府APP，就给政府调度用。只有地图服务跟策略相关的反作弊等，用了公共平台的服务，其他部分全是单独开发。我们把它定义成小滴滴，而且是能够对接大滴滴的小滴滴。当初设想如果能把企业内部的公车**活的话，滴滴能增加很多运力，而且跟地方的关系处的**更好一点。
渠道合作原来只有对外API，所以当初接航空公司、酒店的时候是用的我们的API。但本质上来讲，其实对于C端就是一个渠道。包括一些航空公司，都逐步逐步接了滴滴的这个渠道，现在应该很多端都能打到滴滴的车，其实都是属于渠道合作的方向。
产品比较和整体思考：
以上文稿来自起点学院行业大讲堂
分享人：叶老师，前滴滴企业线产品负责人，起点学院特聘导师
下一期将在“起点学院企业大学”服务号继续分享从滴滴企业复**得出的B端产品经理应有的思维方式与能力要求。
关注服务号，获得更全面的滴滴企业级进展案例回顾，还有更多大咖的深度经验总结。
