易到2010年左右最早做專車時，企業服務是同步上線的；神州原來是做租車的，本來就有企業級服務，有專車後也同步上了專車的企業服務；還有傳統租車的一嗨、美國的Uber，都是同步上線的企業服務。
最早滴滴打車是出租車服務，14年8月份的時候上線了專車，15年上線了企業級服務，但跟以上當時的競對相比，滴滴的企業出行開始得並不早。
用車背後大多數人都是上班族，企業員工加班打車，最早都是用出租車。滴滴希望優化整個出租車的運營，所以第一時間想到做B端的業務。
企業級服務在用車服務中裏是普遍的，在傳統租車時代，企業用車是主流，而且是毛利非常高的業務；所以傳統租車企業轉到了網約車以後，自然會把這個業務保留。
01 做企業級用車，到底解決了哪些痛點？
企業自有車包括政府的公車本身的運營、維護、管理效率很低：滴滴通過移動端管理、調度司機端，平台技術是較先進的。
一線城市企業員工的加班用車、差旅用車較多，涉及到早晚高峯擁堵、交通費墊付多等；尤其是發票問題，多且報銷複雜——這個是我們當初整個團隊做了很多調研分析，發現的一個非常突出的問題。企業內部本身在交通費報銷中的服務成本非常高，每個公司財務對交通出租車發票的開票要求還是不一樣的，管理難度高。
所以我們希望通過搭建這樣一個平台，讓整個市場透明、供需平衡，用第三方公共服務的時候，整個報銷付費流程都更便捷一些。將企業的用車進行市場化與平台化的運營，來降低企業因公用車部分的管理費用，以及提高員工的使用體驗。
02 組織和業務定位滴滴2B服務，提供的是出行服務和管理的解決方案，一開始是兩個平行的方向：企業和政府。
滴滴開始做企業級用車的時候，內部就有包括出租車、專車、快車、大巴、代駕，順風車等資源，企業、政府都可以使用；滴滴企業規劃時就準備提供一個企業出行服務的統一平台，也就是可以整合滴滴外部的資源，包括企業自有的車等等。
有一個相對完整的規劃，包括到現在也沒有太多脱離當初的規劃。
我們給企業服務的定位，分了三個模塊：企業用車、政府用車，跟第三方的渠道合作用車。
- 企業用車：行政用車，服務企業員工因公出行，如加班、接送客户、差旅等；營銷用車，服務企業的客户，作為營銷工具的一部分。
- 政府用車：服務政府和事業單位的公務出行。因為政府相關的數據其實都是公務人員出行，特別還有一些特種車輛，所以不能做整個透明化的運作，而是在私有云空間操作。
- 渠道合作：作為第三方的用車服務提供商，如航空公司、OTA、酒店集團。
企業用車分為行政用車和營銷用車：
1. 行政用車（1）行政用車-起因
C端用户逐步起量，但那時候競爭還是比較激烈的。剛提項目的時候，其實主要還是針對“快的”的營銷補貼大戰，希望尋找其他辦法幫助打贏這場仗，或者其他業務線能夠出力。
所以出了企業用車，主要涉及到三個方向：
- 每個用車人背後都有個企業統一管理，因公出行的費用可以報銷（例如加班和出差），決策權在企業
- 市內因公出行主要用出租車，出租車發票可以報銷，出租車貼票報銷員工和企業都工作量大，不易管理
- 因公出行價格不敏感，因公出行不需要C端補貼，通過企業可以鎖定個人用車習慣，C端自己出行也用滴滴
總結起來就是：企業和個人都有用車需求，企業可以決定一些個人的行為（比如在公司用OA系統，企業所有的相關的業務都在上面，要跟其他同事、其他部門協同，不管體驗好不好，都必須要用公司指定的），有利於C端用户留存和降低營銷費用。
（2）行政用車-定位
整個業務的邏輯其實比較簡單，包裝C端已經成型的公車，提供給B端。這樣就有兩個收入的來源：C端用車服務的渠道佣金，B端用車服務的服務費。
（3）行政用車-場景
- 員工側：加班、因公出行、接送機、會議、差旅等
- 企業側：作為採購的一個項目，涉及報備、財務報銷、以及發票管理的問題。
提供這樣的服務，其實遇到過很多問題，最早碰到的其實是合規的問題。因為那個時候網約車的法規還沒出，我們面臨最大的問題是企業能不能接受開具的統一的發票——不是出租車發票。我們要先去破企業這一塊，我們最早的時候都跟財務打交道，拿這個做報銷憑證能不能認啊？——現在整個互聯網企業應該都認識滴滴開的發票，但當初推的時候還是挺難的。
拓展客户的時候，最早外企是進不去的，基本上就是合規沒解決不能用。其實在企業級用車服務裏面，當時的環境是最大的門檻。
也會涉及到很多產品服務的問題，比如一些反作弊的問題、第三方合作中的一口價問題、以及很多其他的細節問題。
（4）行政用車-核心產品
整個行政用車最核心的是兩條線，企業支付和個人支付。
通過企業支付跟個人墊付，基本上就滿足了所有企業因公出行報銷的需求。通過這個體系，企業一般都通過規則管好；如果不行的話，就上個人墊付跟線上報銷，也很簡單——就是在支付的時候，選擇個人支付，需要報銷就打個標籤，在系統裏面就會另外歸類，月底報銷的時候直接會在報銷模塊出現——提交——審核——報銷一氣呵成。
整個業務流程細講的話，其實是一個特別複雜的流程。但凡有財務介入的，整個資金鍊的管理、對賬會非常麻煩，而且合規不合規由企業説了算。跟企業之間有很多交互，甚至有的部分還得跟用車的員工進行交互，所以會有很多麻煩。
這些怎麼繞過呢？其實如果我們做得更多一點，比如説跟人家的財務系統、或者第三方的財務軟件打通。
B端流程會特別多，時間週期也會比較長，但畢竟是一個管理，員工很少會講平台體驗不好，畢竟是平台跟企業一起制定的規則。所以但凡用了企業用車、特別是企業支付的邏輯以後，用户的留存相當高。
（5）行政用車-思考
- 2B產品，滿足客户的80%需求才可能賣出去；
- 2B產品，有一個功能不滿足可能擋住一大批客户。API、成本中心；
- 2B產品，要和企業的管理模式匹配，體現的企業文化。
- 2B產品，不可能讓所有角色滿意，要尋找各方能接受的平衡點。企業支付。
（1）營銷用車-起因
北上廣深杭以外企業加班不多，加班用車起不來量；
很多企業利用企業版的代叫車業務做營銷活動，尤其是代理商所在二三線城市；
特別是二三線城市裏面都是代理商幫我們拓展企業客户，我們跟他們分成。但是出於反作弊的原則，比如一個人同一時間段代叫車很多，有可能代叫完以後不支付，形成壞賬，因此我們會阻止。
在這種情況下，企業就有很多投訴——為什麼一個人不能叫多個，我們幫客户叫車還得幾個人一個一個下單？
後來，我們就推出了營銷用車。邏輯上來講，其實是把我們的B端用車服務跟客户的業務連接。最簡單的，比如客户服務他的客户（代叫車等）；另外還有一些客户的運營活動、營銷活動用車等。
這種模式下我們雖然賺的錢還是一樣的，但是邏輯不一樣，服務的客户也不一樣。拿我們的產品幫助用户，在他的產品和服務裏面實現增值。
（2）營銷用車-核心產品
這裏面的一個典型產品就是企業邀約券。
因為我們當初做邀約券分了七個方向，通過代叫車，可以控制出發地、目的地、指定的手機號來進行營銷活動等，但還是會出現比如説惡意的刷單、用户企業支付做私人的事情、或者惡意地進行一些多的費用結算等。
後來慢慢通過產品優化，我們推出了ABA模式，就是A叫車-B坐車-A支付，通過券或者紅包的形式發出去，可以給企業做營銷。比如有一家餐飲企業開店，客户打車來這個餐飲企業，或者吃完以後回家，企業會發邀約卷，然後整個用車的費用由企業來支付。
我們當初有跟房產中介合作專車看房，在整個營銷場景裏面，還設有美食專車、招聘專車等。要讓客户過來，也不用告訴客户在哪，給他發個邀約券，鎖定了地址，只要按個鍵叫個車師傅就知道到哪接客户，然後送到目的地。
我們那時候想了很多種場景，給用户做宣傳，幫助一些企業利用用車這個行為做營銷，拉新用户，然後知道用户相關的行為以及分佈的區域，其實效果是非常好的。
（3）營銷用車-思考
- 幫企業省錢的產品企業願意用，幫企業賺錢的產品企業搶着用；
- 營銷類產品反作弊是非常重要的功能；
- 營銷用車產品的商業邏輯是1+1>2 ，你的產品跟他的產品加起來要比他原來單獨去用這個服務要好；比如讓用户打車過來，不如直接發個券，或者幫推送給客户，客户看到你的廣告掃個碼就過去，用户體驗更好，各方面轉化率也好。
15-16年，公車改革風聲比較緊的時期——那時候號稱16年底要完成公車改革，各個地方必須拿出政策來説怎麼幹。
16年某市政府希望進行公車改革，讓滴滴提供服務。然後我們就做了一套政府用車的平台（其實就是把滴滴的能力打包一下，給其市政府使用），應該現在還在用——這也是滴滴最早開始做租車業務，因為政府中帶司機、不帶司機的都會有。
2. 政府用車-定位
政府用車的定位很簡單，本身他們內部車輛管理就是個小滴滴，內部自己定價；另外他們還提了個建議，就是車輛如果不夠的時候，希望滴滴的平台能把資源接進去。比如大的會議接待，或搞活動的時候，滴滴的車輛能服務政府的用户；另外就是政府的車輛閒置的時候，可以接外部的客户。
公車改革推進還是相對比較困難的，以上是個特別好的邏輯。因為當時大家看重的其實就是滴滴的運力，政府包括大的央企都有自己獨立的用車服務公司，人員調度和各種車輛的維護都會希望跟我們合作，來將下面的車盤活。
但因為那時候還沒有合規、有各種顧忌，公車改革應該只是那一個市政府合作了，但是這個其實是進行公車改革的一個特別好的解決方案。
3. 政府用車-核心產品政府用車跟企業用車服務不一樣，企業用車服務是通過C端，資源是公共平台提供的；但是政府用車的資源平台和車的類型也多，各種特種車輛、人員分類也多，有些甚至是領導專用車輛需要一對一綁定，還有一對多的綁定，然後整個車輛的管理、司機的管理都更加複雜。
所以單獨給政府做了一個政府APP，就給政府調度用。只有地圖服務跟策略相關的反作弊等，用了公共平台的服務，其他部分全是單獨開發。我們把它定義成小滴滴，而且是能夠對接大滴滴的小滴滴。當初設想如果能把企業內部的公車盤活的話，滴滴能增加很多運力，而且跟地方的關係處的會更好一點。
4. 政府用車-思考- 讓每個政府的公車管理系統變成一個和滴滴互通的小滴滴是公車改革非常好的解決方案：賦能給需要自有車管理的體系，進行內部車輛調度，然後形成軌跡，價格全部能像滴滴一樣管理，效率能提高，又能跟大滴滴進行銜接，可以有波峯波谷的協調
- 當時做政府用車不是一個好時機，車輛合規問題、滴滴能力輸出問題、滴滴發展方向問題；
- 每個行業的先進解決方案都是解決類似問題的好方案：跟滴滴服務C端用户邏輯是一樣的，我們無非是把滴滴的整個這套東西包裝成一個雲的解決方案，然後提供給相關的政府跟事業單位；
- 政府是一個特殊客户，獨立性要求高，有時候能力輸出比直接提供服務重要：大家在做saas平台，一定會遇到私有云和公有云，或者説價值服務跟獨立部署之間的矛盾，因為涉及到數據安全、信息安全跟掌控權的問題
渠道合作原來只有對外API，所以當初接航空公司、酒店的時候是用的我們的API。但本質上來講，其實對於C端就是一個渠道。包括一些航空公司，都逐步逐步接了滴滴的這個渠道，現在應該很多端都能打到滴滴的車，其實都是屬於渠道合作的方向。
結語產品比較和整體思考：
- 產品定位的重要性：做每一款產品到底是服務誰、商業模式、怎麼賺錢等，在最初的時候一定要定好，大家能看到滴滴最早定完方向到現在都基本沒變
- 2B業務應該長遠思考，不能看短期盈虧：雖然大家都知道To B業務本身是為了賺錢，但是其實在初期的時候，To B業務是需要進行投入的，後續客户進來以後會非常穩定
- C端業務佔主導的企業很難孵化好的B端產品，除非給予足夠的獨立性：這個是也是後續特別能感同身受的，包括C端很多研發資源的支持等，配合都非常難。因為思維邏輯不一樣，B端的業務量又沒辦法跟C端比，本身在內部的溝通會非常難。這個也是看各個企業的文化；
- 滴滴錯過了很多很好的合作機會：政府合作、包括平台合作的很多機會
- 2B業務和2C業務的不同基因：管理和服務、合作和自我
以上文稿來自起點學院行業大講堂
分享人：葉老師，前滴滴企業線產品負責人，起點學院特聘導師
下一期將在“起點學院企業大學”服務號繼續分享從滴滴企業覆盤得出的B端產品經理應有的思維方式與能力要求。
關注服務號，獲得更全面的滴滴企業級進展案例回顧，還有更多大咖的深度經驗總結。