1. MaaS的真相它卖的不是“流量”是“门到门的确定性”MaaSMobility as a Service出行即服务这些年已经被喊成了行业锦鲤创业者在路演里讲它地方在做规划时讲它车企转型讲它连做支付的也想蹭它。但说句得罪人的话市面上绝大多数所谓MaaS项目本质上只是一个换了皮肤的聚合打车App甚至只是把公交卡搬到了手机里离真正的MaaS还差着好几个数量级。我见过太多团队把“把多个出行服务放进一个App”当成终点结果做了半年发现变成了一个高成本的低频工具用户打开一次比价完又回到原来的习惯里去。问题出在哪出在大家对MaaS的商业本质没有形成共识。它不只是界面层的聚合而是一整套从需求识别、路径规划、运力调度、定价结算到服务承诺的闭环体系。它最核心的价值不是“帮用户找到一辆车”而是帮用户买到一段确定性确定的时间窗口、确定的最高成本、确定的门到门方案。所以这篇分析我不打算写那种教科书式的宏观报告而是从商业模式的底层逻辑出发把MaaS从技术底座到变现路径拆开来看。适合三类人准备入局MaaS的创业者、正在做交通板块数字化的产品负责人以及想看懂出行行业投资逻辑的研究人员。2. “技术赋能”究竟是什么技术一个MaaS项目背后必须有的四个引擎MaaS的商业故事讲得很性感但落到地上全部要由技术系统扛住。技术赋能不是“接几个API做个页面”而是四层引擎协同工作。每一层做不好后面的商业化都会在某个增长节点上撞墙。2.1 数据接入引擎所有上层建筑的地基第一层是多源异构数据的接入和治理。你要把地铁、公交、网约车、共享单车、出租车、停车场、充电桩等不同所有权、不同数据标准、不同更新频率的数据源汇聚到一个统一的数据底座上。公共交通行业常用GTFS和GTFS-Realtime这类公开规范但网约车平台、第三方车队管理系统的数据接口则五花八门很多接口字段含义模糊同一个“到达时间”在不同供应商系统里可能是“预计到达”“计划到达”或“实际到达后的修正值”。这块坑特别多。我在实际项目里遇到过一个情况某个城市的公交接口返回的经纬度是GCJ-02坐标系而网约车平台用的是WGS-84坐标系两者偏差约几百米。数据接入层如果不做坐标统一和字段语义对齐上层的路径规划算出来的换乘方案就是错的。真实做法是接入后先做数据质量校验延迟率、空值率、逻辑校验例如到达时间不能早于发车时间形成一张数据质量看板低于阈值的上游接口要自动降级或标记。2.2 多模式路径规划引擎用户体验的胜负手第二层是路径规划引擎这也是普通用户最能直观感知“这App是不是聪明”的地方。传统的单模式导航只算驾车或者地铁而MaaS的路径规划是在一张多模式出行图上搜索一个多维最优解目标函数里至少要考虑总时间、换乘次数、费用、运动强度、碳排放量还可能叠加用户的偏好权重。算法层面常用的不是单一算法而是分层搜索先用较粗粒度的路网图算出一个候选走廊再在候选走廊内做更精细的多模式搜索。搜索空间的爆炸式增长是这层最大的技术压力——一个城市如果有500个地铁站和2万辆公交车把“公交步行地铁骑行”组合起来的可行路径数量级会非常惊人。行业里常见的优化手段包括预计算步行邻域表、把高频OD起终点路径做离线缓存、基于A算法改进的ALT预处理Awith Landmarks and Triangle inequality降低在线计算延迟。但这层真正的门槛不是算法本身而是成本函数的标定。你必须本地化地搞清楚这个城市的用户更在乎省5分钟还是省2块钱是更愿意少走几步还是更怕换乘这些偏好参数不能靠拍脑袋要做SP调查Stated Preference或RP调查Revealed Preference来标定。技术服务于价值判断这一步没做好再先进的算法也算不出用户买账的方案。2.3 交易与计费引擎商业闭环的主动脉第三层是交易引擎很多人低估了它。MaaS不是简单的“用户付钱平台赚差价”它涉及多供应商的清分结算、动态定价、票务规则映射、优惠券分摊、异常退款等一揽子问题。一次用户行程可能涉及地铁公司、公交公司、网约车司机三方分账而每一方的结算周期、开票主体、退款规则都不一致。这层我建议团队在MVP阶段就认真设计不要想着“先把功能跑通结算以后再说”。一旦交易量起来再重构结算体系代价极高所有的历史订单、对账单、税务记录都要迁移稍有不慎就会出现资金差异。一个常见的稳健做法是采用“信用钱包延迟清分”的模式用户先通过统一钱包实时扣款平台在T1日根据真实履约记录完成供应商清分对异常订单先冻结再人工介入。2.4 履约保障引擎让用户真的敢用最后一层是履约保障。用户选了一条“地铁公交共享单车”的组合路线最怕的是走到一半下一段公交临时停运了。MaaS平台不能两手一摊必须有能力实时监测行程中的每一个节点在异常发生时主动告知用户并提供替代方案。这也就要求调度系统不仅仅服务于司机或车辆还要服务于“行程本身”。平台要维护一张行程快照用户当前在哪、下一步要坐哪辆车、这辆车现在是否晚点、是否需要触发换乘保护。换乘保护的目的在于当用户因上游延误而错过后续班次时平台承担改签或补偿成本而不是让用户自己去和供应商扯皮。这四个引擎之间不是孤立模块而是有强依赖关系数据引擎喂给路径引擎路径引擎产生行程方案交易引擎完成购买履约引擎监督执行并把异常反馈回数据引擎。所以我始终认为MaaS本质上是一款复杂软件系统商业想象力的天花板取决于这四个引擎共同支撑的履约能力。3. 商业模式里的利益结构平台、运营商、政府三方之间到底谁买单MaaS是典型的多边市场不是简单的双边撮合。画一张全景图会看到至少有四方C端用户、B端供应商公交、地铁、网约车公司等、G端政府和平台方。四方的目的完全不同商业模式就是在这四者的利益冲突中找到平衡点。3.1 三种主流架构模式流量撮合、深度运营、公共基础设施我把目前市面上跑得通的MaaS项目分为三类架构模式代表产品形态平台角色商业模式重心流量聚合型出行聚合平台、超级App出行板块撮合流量向供应商收佣金或广告费高流量、低价心智、广告变现深度运营型订阅制MaaS应用、城市级出行通票统一采购运力、自行定价、承担服务责任订阅收入、企业合同、数据增值公共基建型政府主导的城市出行数据交换平台做标准制定者、数据中转站政府付费运维合同、数据服务、特许经营流量聚合型是当下最常见的也最容易落地但它的短板是用户忠诚度极低。用户从聚合平台打一辆车和从网约车App打一辆车在体验上没有本质差异自然谁便宜用谁。深度运营型则是真正意义上“做服务”的模式平台向各供应商批发采购运力再组合成通勤套餐卖给用户平台对最终体验负全责。这种模式的启动成本高但一旦形成规模它的护城河也是最宽的。公共基建型在国内一些城市的数字交通项目中能看到雏形。政府建设统一出行数据枢纽要求各运营方开放数据接口平台不以盈利为首要目标而是服务于城市拥堵治理、公交线网优化、碳减排核算等公共目标。这种模式里平台方的商业模式变成了“政府购买服务基于公共数据的增值开发”短期的直接商业回报不明显但社会价值很大。3.2 利益冲突是商业模式设计的第一约束在这三种架构里最让我印象深刻的不是技术难点而是利益格局决定一切。举个例子城市地铁公司希望用MaaS鼓励更多人坐地铁但地铁每一趟的边际成本几乎不变票务收入却是它的主要营收。MaaS平台为了吸引用户会做一个包含地铁、公交和共享单车的打包月票定价必须低于三者的单买之和。这中间的折扣需要有人承担。地铁公司愿不愿意牺牲票面收入换客流增长网约车公司愿不愿意为了MaaS平台的套餐降低单均抽成如果这些利益分配谈不拢再好的产品设计都等于零。所以我在评估一个MaaS项目时第一个问题不是“你有没有算法团队”而是“你的上游供应商里有没有至少一方愿意为长期用户关系让利”。没有这个基础商业模式就是空中楼阁。另一方面C端用户和B端供应商的核心痛点往往不一致用户要的是便宜和省事供应商要的是收入和效率。真正跑得好的MaaS项目常常是通过“向上游提供增量运力”或“向上游降低获客成本”来完成统一的——比如平台不仅把客流导给公交公司还帮公交公司做了动态班次优化的数据服务后者自然愿意把部分费用拿出来分成。政府在这个局里的角色也很微妙。政府在拥堵治理和环保上有硬指标更希望MaaS引导用户从小汽车转向公共交通。这意味着平台如果能把绿色出行比例、碳减排量等指标数据透明化就能在政府采购、数据授权和产业政策中获得支持。但我建议别一上来就指望政府项目养团队政府项目的招标周期长、回款慢、定制化要求高对创业公司来说很容易拖垮现金流。4. 商业变现拆到底四种收入流的利润逻辑与优先级MaaS做完了技术和生态最后绕不开的问题就是“钱从哪来”。我倾向于把MaaS的变现路径划分为四条线交易价差、订阅收入、企业合同和数据服务。每一条的毛利结构、规模天花板和启动难度都完全不同。4.1 交易价差/佣金最直接但最不性感交易价差是MaaS最基础的变现方式。平台向用户展示多个供应商的方案用户选择某个方案完成支付平台从供应商获取一定比例的佣金或固定服务费。这个模式在聚合平台里非常成熟但它的劣势也显而易见单均佣金率不高网约车行业常见的平台抽成比例约为20%25%但扣除补贴、优惠券和支付成本之后实际净抽成远低于名义值。更何况政府往往对出行平台的抽成比例有监管关注向上抽佣的空间是收敛的。所以我把交易佣金当作“现金流保底”而不是核心利润来源。它解决的问题是让平台的交易成本被覆盖让数据产生基本的流转量。4.2 订阅收入/会员权益毛利率最高的红利区订阅制是MaaS最被看好的变现模型。它的商业逻辑和健身房年卡类似用户按月或按年购买一个出行权益包获取一定次数的免费/折扣出行服务平台则通过“套餐定价”提前锁定了用户未来一段时间的出行预算。这里的关键在于基于使用行为测算的套餐定价。如果套餐定价过高用户觉得不划算定价过低平台和供应商都会亏钱。我在参与设计这类套餐时一般会先基于历史订单数据做人群分群把用户切割成极高频通勤族、中频碎片出行族、低频偶发族然后给每个族群分别测算“单次均价”和“月度出行次数分布”。套餐价格通常设定在用户月均出行支出的85%95%之间对用户来说省钱平台则依靠“有些人买了套餐但出行次数低于均值”的余额效应保持毛利。订阅收入的好处在于可预测性强且用户一旦订阅因为沉没成本心理会更愿意用平台完成行程形成使用粘性。4.3 企业合同/商务出行不需要补贴的正现金流生意很多做C端的团队完全忽视了一个比C端更优质的市场企业出行服务。企业客户对出行的核心诉求是合规、透明、可对账。他们不太纠结于单次便宜一两块钱更在意员工出差和通勤费用是否可管控、发票是否统一开具、出行数据能否和内部财务系统无缝对接。MaaS平台面向企业提供“一站式差旅通勤管理后台”员工在企业账户内用车、坐公交、订停车位费用直接从企业预充值账户扣除系统自动生成账单和审批流。这个模式的客单价远高于C端一个1000人的中型企业月度出行预算可能达到20万以上而服务成本相对固定。企业合同也让平台摆脱了对C端补贴大战的依赖业务增长靠销售能力而不只靠价格战。4.4 数据服务与生态增值看上去很美的“第二曲线”数据服务是MaaS商业模式报告里必提的一章但我建议谨慎看待。做数据分析、向城市规划部门或商业地产方输出匿名化的客流洞察报告确实是可行路径但它的落地周期很长数据合规成本很高。在个人信息保护法日渐严格的背景下数据获取必须有明确授权使用必须有明确边界稍有不慎就会踩线。相比之下生态增值服务更容易落地基于用户出行场景做保险行程延误险、骑行意外险、停车充电优惠、目的地商圈权益等。这种模式的优势是不直接向用户收费而是把“出行后的需求”变成新的货架。它的可持续性取决于平台是否真的掌握了“用户下一步要去哪”的场景数据而这也再次回到了技术引擎的支持能力。5. 从0到1跑通落地项目我的实操步骤和踩坑记录分析报告看多了容易变得宏观我更喜欢回到执行层面聊点实在的。假设你现在要在一个二线城市跑一个MaaS原型的落地验证我建议按下面这个顺序推进很多坑都可以提前规避。5.1 选好切入的“走廊”而不是做全城覆盖第一件事是选一片足够集中的“出行走廊”比如连接新城区CBD和旧城区居民区的一条主干道沿线有3条公交线路、2个地铁站、若干共享单车停放点。这个走廊的用户出行密度要足够高才能支撑起MVP阶段的数据量。用“走廊”切而不是“全城”切是为了资源聚焦你和供应商谈合作时可以用具体的“这条路上每天有X人次的跨模式出行需求”去说服对方而不是甩一份全城大盘数据。5.2 用真人客服代替前期算法神话MVP阶段不需要一上来就做完整的实时调度引擎那是过度工程。我甚至建议前期用“人工脚本”的半自动模式来跑通链路excel表格维护班次数据人工计算推荐路线再用企业微信或短信把方案发给种子用户。这看起来很土但它能让你在两周内验证一个最核心的假设——用户愿不愿意为“多模式打包出行方案”付费。等确认需求存在之后再把算法和系统逐步补齐。5.3 先签一个“让利意愿”最强的供应商和供应商谈判时不要贪多先锁定一个愿意让利的战略伙伴。这个伙伴可能是公交车公司因为它的上座率长期不饱和MaaS能给它带来增量客流也可能是一家区域性出租车公司因为它正在被全国性网约车平台挤压急需差异化服务。谈合作时关注的事能否开放实时接口、能否支持平台统一结算、是否接受打包售卖的结算价。这三个问题有一个答不上来后面都会变成持续性痛。5.4 冷启动期别用大额补贴掩盖产品问题MaaS冷启动最忌“补贴依赖症”。你补贴一个用户拉来10次订单一旦补贴停止用户就跑了你根本分不清留存是因为产品价值还是因为便宜。更有效的冷启动是找一群“复合出行焦虑感最强”的用户比如每天接送孩子且需要“开车地铁步行”组合出行的家长或者长期出差、经常在两个城市间做多段联运的商务人士。这类用户对整合方案的付费意愿最高建议直接送半年会员换取深度的使用反馈和案例背书。5.5 需要提前想清楚的坑我整理几个实操中遇到最多的问题避免你绕弯出行数据的时钟问题各供应商的时间精度不一致记录“行程开始时间”时有的取支付时间、有的取闸机刷卡时间、有的取GPS定位时间。结算时一旦出现订单时间差就容易产生对账争议。需要在接入初期就和各方约定统一的事件时间口径。取消和退款规则一定前置定义用户买了地铁网约车的联程票第一段地铁晚点导致第二段网约车迟到算谁的责任这个场景几乎100%会发生。我的建议是“平台先行赔付”政策写进用户条款先兜底用户体验再向上游供应商追责。隐私授权不是小事涉及用户的实时位置、出行轨迹、支付信息的收集使用必须在前端做明确告知和授权弹窗并预留“单次行程授权”的选项。别把用户的位置数据用来做广告投放否则合规风险随时会爆雷。6. 三个趋势正在打开MaaS的下一个窗口期但窗口可能不长聊完了商业模式和执行路径最后说点我对MaaS未来两三年走向的判断。第一电动汽车和标准化充电网络会让“出行即服务”里的“服务”范围进一步扩大。当新能源车变得像共享单车一样可以随时获取“拥有车辆”这件事在很多场景下会变得没有必要MaaS平台正好可以整合“临时租车充电还车”这条链条。第二自动驾驶技术普及后MaaS的调度引擎将从“调度人类司机”变成“调度车辆资源”平台的边际成本会显著下降但技术门槛会大幅上升。第三数据合规和出行碳积分机制正在成为新的竞争维度能够把绿色出行数据转化成碳资产的平台会获得政府侧和企业侧的双重支持。但窗口期不会永远敞开。现在很多城市的出行基础设施已经被超级App和政务系统瓜分得差不多了新玩家想从聚合入口切入机会不大往深度运营和垂直人群走反而是时间窗口仍然存在的赛道。所以我给团队的建议始终是同一句话别总想着做一个“城市级MaaS平台”先服务好一类人、跑通一段路、赚到一笔可持续的钱再谈平台。最后分享一个我在实操里养成的习惯每提一个新功能或新合作之前先问自己一句——“它到底是让用户的出行确定性更强了还是只是让后台看起来更热闹了”这个判断标准帮我砍掉了至少一半的无效需求。MaaS这个行业诱惑很多但本质是在和不确定性赛跑谁能把一段门到门的行程兑现成确定性谁就赢下了这门生意。
