滴滴ToB业务全案复盘

易到2010年左右最早做专车时，企业服务是同步上线的；神州原来是做租车的，本来就有企业级服务，有专车后也同步上了专车的企业服务；还有传统租车的一嗨、美国的Uber，都是同步上线的企业服务。

最早滴滴打车是出租车服务，14年8月份的时候上线了专车，15年上线了企业级服务，但跟以上当时的竞对相比，滴滴的企业出行开始得并不早。

用车背后大多数人都是上班族，企业员工加班打车，最早都是用出租车。滴滴希望优化整个出租车的运营，所以第一时间想到做B端的业务。

企业级服务在用车服务中里是普遍的，在传统租车时代，企业用车是主流，而且是毛利非常高的业务；所以传统租车企业转到了网约车以后，自然会把这个业务保留。

01 做企业级用车，到底解决了哪些痛点？

企业自有车包括政府的公车本身的运营、维护、管理效率很低：滴滴通过移动端管理、调度司机端，平台技术是较先进的。

一线城市企业员工的加班用车、差旅用车较多，涉及到早晚高峰拥堵、交通费垫付多等；尤其是发票问题，多且报销复杂——这个是我们当初整个团队做了很多调研分析，发现的一个非常突出的问题。企业内部本身在交通费报销中的服务成本非常高，每个公司财务对交通出租车发票的开票要求还是不一样的，管理难度高。

所以我们希望通过搭建这样一个平台，让整个市场透明、供需平衡，用第三方公共服务的时候，整个报销付费流程都更便捷一些。将企业的用车进行市场化与平台化的运营，来降低企业因公用车部分的管理费用，以及提高员工的使用体验。

02 组织和业务定位

滴滴2B服务，提供的是出行服务和管理的解决方案，一开始是两个平行的方向：企业和政府。

滴滴开始做企业级用车的时候，内部就有包括出租车、专车、快车、大巴、代驾，顺风车等资源，企业、政府都可以使用；滴滴企业规划时就准备提供一个企业出行服务的统一平台，也就是可以整合滴滴外部的资源，包括企业自有的车等等。

有一个相对完整的规划，包括到现在也没有太多脱离当初的规划。

我们给企业服务的定位，分了三个模块：企业用车、政府用车，跟第三方的渠道合作用车。

1. 企业用车：行政用车，服务企业员工因公出行，如加班、接送客户、差旅等；营销用车，服务企业的客户，作为营销工具的一部分。
2. 政府用车：服务政府和事业单位的公务出行。因为政府相关的数据其实都是公务人员出行，特别还有一些特种车辆，所以不能做整个透明化的运作，而是在私有云空间操作。
3. 渠道合作：作为第三方的用车服务提供商，如航空公司、OTA、酒店集团。

03 企业用车

企业用车分为行政用车和营销用车：

1. 行政用车

（1）行政用车-起因

C端用户逐步起量，但那时候竞争还是比较激烈的。刚提项目的时候，其实主要还是针对“快的”的营销补贴大战，希望寻找其他办法帮助打赢这场仗，或者其他业务线能够出力。

所以出了企业用车，主要涉及到三个方向：

1. 每个用车人背后都有个企业统一管理，因公出行的费用可以报销（例如加班和出差），决策权在企业
2. 市内因公出行主要用出租车，出租车发票可以报销，出租车贴票报销员工和企业都工作量大，不易管理
3. 因公出行价格不敏感，因公出行不需要C端补贴，通过企业可以锁定个人用车习惯，C端自己出行也用滴滴

总结起来就是：企业和个人都有用车需求，企业可以决定一些个人的行为（比如在公司用OA系统，企业所有的相关的业务都在上面，要跟其他同事、其他部门协同，不管体验好不好，都必须要用公司指定的），有利于C端用户留存和降低营销费用。

（2）行政用车-定位

整个业务的逻辑其实比较简单，包装C端已经成型的公车，提供给B端。这样就有两个收入的来源：C端用车服务的渠道佣金，B端用车服务的服务费。

（3）行政用车-场景

• 员工侧：加班、因公出行、接送机、会议、差旅等
• 企业侧：作为采购的一个项目，涉及报备、财务报销、以及发票管理的问题。

提供这样的服务，其实遇到过很多问题，最早碰到的其实是合规的问题。因为那个时候网约车的法规还没出，我们面临最大的问题是企业能不能接受开具的统一的发票——不是出租车发票。我们要先去破企业这一块，我们最早的时候都跟财务打交道，拿这个做报销凭证能不能认啊？——现在整个互联网企业应该都认识滴滴开的发票，但当初推的时候还是挺难的。

拓展客户的时候，最早外企是进不去的，基本上就是合规没解决不能用。其实在企业级用车服务里面，当时的环境是最大的门槛。

也会涉及到很多产品服务的问题，比如一些反作弊的问题、第三方合作中的一口价问题、以及很多其他的细节问题。

（4）行政用车-核心产品

整个行政用车最核心的是两条线，企业支付和个人支付。

通过企业支付跟个人垫付，基本上就满足了所有企业因公出行报销的需求。通过这个体系，企业一般都通过规则管好；如果不行的话，就上个人垫付跟线上报销，也很简单——就是在支付的时候，选择个人支付，需要报销就打个标签，在系统里面就会另外归类，月底报销的时候直接会在报销模块出现——提交——审核——报销一气呵成。

整个业务流程细讲的话，其实是一个特别复杂的流程。但凡有财务介入的，整个资金链的管理、对账会非常麻烦，而且合规不合规由企业说了算。跟企业之间有很多交互，甚至有的部分还得跟用车的员工进行交互，所以会有很多麻烦。

这些怎么绕过呢？其实如果我们做得更多一点，比如说跟人家的财务系统、或者第三方的财务软件打通。

B端流程会特别多，时间周期也会比较长，但毕竟是一个管理，员工很少会讲平台体验不好，毕竟是平台跟企业一起制定的规则。所以但凡用了企业用车、特别是企业支付的逻辑以后，用户的留存相当高。

（5）行政用车-思考

• 2B产品，满足客户的80%需求才可能卖出去；
• 2B产品，有一个功能不满足可能挡住一大批客户。API、成本中心；
• 2B产品，要和企业的管理模式匹配，体现的企业文化。
• 2B产品，不可能让所有角色满意，要寻找各方能接受的平衡点。企业支付。

2. 营销用车

（1）营销用车-起因

北上广深杭以外企业加班不多，加班用车起不来量；

很多企业利用企业版的代叫车业务做营销活动，尤其是代理商所在二三线城市；

特别是二三线城市里面都是代理商帮我们拓展企业客户，我们跟他们分成。但是出于反作弊的原则，比如一个人同一时间段代叫车很多，有可能代叫完以后不支付，形成坏账，因此我们会阻止。

在这种情况下，企业就有很多投诉——为什么一个人不能叫多个，我们帮客户叫车还得几个人一个一个下单？

后来，我们就推出了营销用车。逻辑上来讲，其实是把我们的B端用车服务跟客户的业务连接。最简单的，比如客户服务他的客户（代叫车等）；另外还有一些客户的运营活动、营销活动用车等。

这种模式下我们虽然赚的钱还是一样的，但是逻辑不一样，服务的客户也不一样。拿我们的产品帮助用户，在他的产品和服务里面实现增值。

（2）营销用车-核心产品

这里面的一个典型产品就是企业邀约券。

因为我们当初做邀约券分了七个方向，通过代叫车，可以控制出发地、目的地、指定的手机号来进行营销活动等，但还是会出现比如说恶意的刷单、用户企业支付做私人的事情、或者恶意地进行一些多的费用结算等。

后来慢慢通过产品优化，我们推出了ABA模式，就是A叫车-B坐车-A支付，通过券或者红包的形式发出去，可以给企业做营销。比如有一家餐饮企业开店，客户打车来这个餐饮企业，或者吃完以后回家，企业会发邀约卷，然后整个用车的费用由企业来支付。

我们当初有跟房产中介合作专车看房，在整个营销场景里面，还设有美食专车、招聘专车等。要让客户过来，也不用告诉客户在哪，给他发个邀约券，锁定了地址，只要按个键叫个车师傅就知道到哪接客户，然后送到目的地。

我们那时候想了很多种场景，给用户做宣传，帮助一些企业利用用车这个行为做营销，拉新用户，然后知道用户相关的行为以及分布的区域，其实效果是非常好的。

（3）营销用车-思考

• 帮企业省钱的产品企业愿意用，帮企业赚钱的产品企业抢着用；
• 营销类产品反作弊是非常重要的功能；
• 营销用车产品的商业逻辑是1+1>2 ，你的产品跟他的产品加起来要比他原来单独去用这个服务要好；比如让用户打车过来，不如直接发个券，或者帮推送给客户，客户看到你的广告扫个码就过去，用户体验更好，各方面转化率也好。

04 政府用车

1. 政府用车-起因

15-16年，公车改革风声比较紧的时期——那时候号称16年底要完成公车改革，各个地方必须拿出政策来说怎么干。

16年某市政府希望进行公车改革，让滴滴提供服务。然后我们就做了一套政府用车的平台（其实就是把滴滴的能力打包一下，给其市政府使用），应该现在还在用——这也是滴滴最早开始做租车业务，因为政府中带司机、不带司机的都会有。

2. 政府用车-定位

政府用车的定位很简单，本身他们内部车辆管理就是个小滴滴，内部自己定价；另外他们还提了个建议，就是车辆如果不够的时候，希望滴滴的平台能把资源接进去。比如大的会议接待，或搞活动的时候，滴滴的车辆能服务政府的用户；另外就是政府的车辆闲置的时候，可以接外部的客户。

公车改革推进还是相对比较困难的，以上是个特别好的逻辑。因为当时大家看重的其实就是滴滴的运力，政府包括大的央企都有自己独立的用车服务公司，人员调度和各种车辆的维护都会希望跟我们合作，来将下面的车盘活。

但因为那时候还没有合规、有各种顾忌，公车改革应该只是那一个市政府合作了，但是这个其实是进行公车改革的一个特别好的解决方案。

3. 政府用车-核心产品

政府用车跟企业用车服务不一样，企业用车服务是通过C端，资源是公共平台提供的；但是政府用车的资源平台和车的类型也多，各种特种车辆、人员分类也多，有些甚至是领导专用车辆需要一对一绑定，还有一对多的绑定，然后整个车辆的管理、司机的管理都更加复杂。

所以单独给政府做了一个政府APP，就给政府调度用。只有地图服务跟策略相关的反作弊等，用了公共平台的服务，其他部分全是单独开发。我们把它定义成小滴滴，而且是能够对接大滴滴的小滴滴。当初设想如果能把企业内部的公车盘活的话，滴滴能增加很多运力，而且跟地方的关系处的会更好一点。

4. 政府用车-思考

• 让每个政府的公车管理系统变成一个和滴滴互通的小滴滴是公车改革非常好的解决方案：赋能给需要自有车管理的体系，进行内部车辆调度，然后形成轨迹，价格全部能像滴滴一样管理，效率能提高，又能跟大滴滴进行衔接，可以有波峰波谷的协调
• 当时做政府用车不是一个好时机，车辆合规问题、滴滴能力输出问题、滴滴发展方向问题；
• 每个行业的先进解决方案都是解决类似问题的好方案：跟滴滴服务C端用户逻辑是一样的，我们无非是把滴滴的整个这套东西包装成一个云的解决方案，然后提供给相关的政府跟事业单位；
• 政府是一个特殊客户，独立性要求高，有时候能力输出比直接提供服务重要：大家在做saas平台，一定会遇到私有云和公有云，或者说价值服务跟独立部署之间的矛盾，因为涉及到数据安全、信息安全跟掌控权的问题

05 渠道合作

渠道合作原来只有对外API，所以当初接航空公司、酒店的时候是用的我们的API。但本质上来讲，其实对于C端就是一个渠道。包括一些航空公司，都逐步逐步接了滴滴的这个渠道，现在应该很多端都能打到滴滴的车，其实都是属于渠道合作的方向。

结语

产品比较和整体思考：

• 产品定位的重要性：做每一款产品到底是服务谁、商业模式、怎么赚钱等，在最初的时候一定要定好，大家能看到滴滴最早定完方向到现在都基本没变
• 2B业务应该长远思考，不能看短期盈亏：虽然大家都知道To B业务本身是为了赚钱，但是其实在初期的时候，To B业务是需要进行投入的，后续客户进来以后会非常稳定
• C端业务占主导的企业很难孵化好的B端产品，除非给予足够的独立性：这个是也是后续特别能感同身受的，包括C端很多研发资源的支持等，配合都非常难。因为思维逻辑不一样，B端的业务量又没办法跟C端比，本身在内部的沟通会非常难。这个也是看各个企业的文化；
• 滴滴错过了很多很好的合作机会：政府合作、包括平台合作的很多机会
• 2B业务和2C业务的不同基因：管理和服务、合作和自我

作者：叶老师

来源：起点学院