编辑导读：用户体验好是用户无阻碍、高效率、超出主观预期地完成目标。本文作者从业务场景相对复杂的滴滴切入，从用户可感知的产品设计来简单分析滴滴服务管控的策略，借鉴其提升用户体验的方法，希望对你有帮助。

在「做用户体验的这一年」一文中，曾提及我认为“用户体验好是用户无阻碍、高效率、超出主观预期地完成目标”。

其实，不论是普通人的直觉还是实际情况，用户认为体验不好的主要场景常发生在各类异常场景中。这里说的异常场景如“用户想查询公积金，但是无法打开页面、可以打开页面但是点击查询报错、可以点击查询但是未查询”等等情况。

也是基于这样的前提，当我们去提升用户体验时，会优先从用户投诉、用户低评分等负向反馈切入，并优先解决此类问题；当然，采用此方案会导致对问题了解不够全面，更加全面的体验评估体系如NPS、CSAT、HEART等，如有机会将在以后的文章中详细介绍。

本文试图从业务场景相对复杂的滴滴切入，从用户可感知的产品设计来简单分析滴滴服务管控的策略，借鉴其提升用户体验的方法。

一、滴滴服务管控是什么

用户在打车时购买的是出行服务，是非标品。以上下班通勤为例，用户购买的打车服务虽然价格相差不大，但是车况好坏、车内环境、司机服务会存在很大差距。也因此，为了尽量保持服务水准，滴滴会对用户关心的核心体验问题进行管控。

这里需要强调一点的是，不同业务、不同场景的服务管控水平会存在差异。

不同的业务，如定位高端出行的“滴滴专车”，不仅限定准入车型、要求车内环境保持干净整洁、车内配备纸巾和瓶装水，也对司机服务进行严格规定，普通用户最有体感的是专车司机六句标准话术（您好滴滴专车为您服务、请问车内的温度合适吗、请问是否按照导航行驶、请您系好安全带现在开始出发、请您带好随身物品并从右侧下车、感谢您使用滴滴专车服务）；与专车形成鲜明对比的是快车，基本可以理解为负责“安全”“准时”送达，其他服务均为做规范。

不同的场景，如预约，在预约接送机场景下，在乘客预付费的前提下，司机可无责取消的条件更为苛刻。

二、打车核心体验和服务管控范围

如上所述，为了保持服务水准，滴滴会对用户关心的核心体验问题进行管控。

以用户最常体验的快车为例，排除派单相关场景后，结合用户经常投诉的场景，当前滴滴主要的服务管控场景如下

• 费用相关：主要是多收费，具体又可以分为为绕路、提前计费、延迟结束计费、（一口价下）更改目的地等场景
• 服务相关：主要是取消，具体又可分为乘客取消（接单前取消、司机接单后取消、司机到达后取消）和司机取消（司机接单后取消、司机到达上车点后取消、行程开始后取消）等场景

三、解决问题第一步是拆解问题

解决问题首先需要基于问题进行详细拆解，明确场景和具体原因，这是第一步也是最关键的一步。

其实，在2中，多收费这个问题已经根据逻辑和用户反馈进行了一次拆分，拆分完后粗略分为绕路、提前计费、延迟计费、更改目的地等子问题。

针对子问题，还需要基于case和用户反馈，拆分出具体原因有哪些。以绕路为例

• 用户反馈绕路，实际并未绕路，价格差异是因为路况变化新增拥堵导致的
• 用户反馈绕路，实际路线绕路，根据司乘轨迹和其他信息可推测/判定是司机原因（如，司机在五环上错过路口，只能在下一个路口掉头）
• 用户反馈绕路，实际路线绕路，根据司乘轨迹和导航路线可推测/判定是平台原因（如，平台导航路况更新不及时，原规划路线司机无法行驶）
• 用户反馈绕路，实际路线绕路，根据司乘轨迹和其他信息可推测/判定是乘客原因（如，一口价场景下乘客接送朋友）

需要强调的是，在做子问题归因的时候，不要停留在逻辑层面进行枚举，一定要去看具体的用户投诉case（一天100个不再话下，至少看1000条）。

通过用户反馈原文/录音、规划路线、司机实际轨迹、乘客实际轨迹、司机被投诉次数等尝试还原当时场景。在这个过程中，总是可以发现很多意想之外的场景，这既是线下服务的服务管控的挑战，也是它的魅力之处。

四、事前、事中、事后三管齐下保效果

滴滴的服务管控采取了事前、事中、事后三管齐下的解题思路。为了方便大家更好地理解，下文采取用户端来进行举例。

想特别说明的一点是在解决用户体验问题时，除了真正去解决问题、降低发生率外，如何管理用户预期提升用户感知也是重要的一部分。

1. 事前教育

如3中所述，“用户反馈绕路，实际并未绕路，价格差异是因为路况变化新增拥堵导致的”，此种场景大多是因为用户不了解计费规则。

当前国内快车的计价模式多为实时计价，即根据时长和里程进行计算-在用户输入起终点后根据当时的时长和里程进行预估。然而路况是瞬息万变的，快车实际价格会与预估价产生差异，当价格超出一定范围时（如，预估29元实际31元这种典型场景，用户记忆中的是二十多变成三十多了），用户就会感到多收费从而投诉绕路。

在解决问题的时候，除了通过预测路况等方式来提高预估价的准确率外，对用户的教育是很重要的一部分。

如下图，在打车确认呼叫前、等待应答时均在做用户教育

除此之外，在新功能上线或用户第一次使用时也要对用户进行教育，尤其是费用相关功能，必要时可以采用弹窗等强提醒的交互方式。

如下图，成都打车时收取超时等待费

很多产品经理会误以为用户对业务很了解，然而，事实是大部分用户没有我们想的对业务这么了解。即使用户很了解很聪明，告知义务也是人之常情，在这一点上切忌用中国家长式思维的“你怎么连这个都不知道？”来思考问题。

2. 事中干预

与线下扬招出租车相比，网约车受益于更多的数据，可以在部分场景下根据数据直接进行干预和判责。

滴滴当前可以获得的数据包括但不限于预估路线（时长和里程）、司机定位画成的行车轨迹、乘客定位画成的行车轨迹、行程结束后的提问式评价、车内的录像录音等。

举一个事中干预的典型案例，司机手机没电后导致当前乘客计费异常，在此情况下可以主动询问司机是否需要更改价格。下文再举两个乘客端案例，方便大家感知。

Case 1 司机在未按照规定路线行驶（高速上错过了路口），到达终点后支付时，系统自动改价后直接按照预估价进行支付

Case 2 杭州萧山机场司机添加过路费，系统提示用户确认费用是否合理

3. 事后反馈

经过这么多年这么多App的教育（尤其要感谢淘宝），普通用户已经知道了遇到问题可以找客服。然而，不可否认的一个事实是，客服是一个成本部门，这也是为什么现在很多公司都在做智能客服、语音客服，同时还会把客服入口藏的很深以减少人工客诉。

我一直坚持的观点是，把客服入口藏的深并不能解决客服投诉量这个问题，用户是带着极大的情绪才想要投诉，藏的深只会让用户付更多的努力找客服入口，而付出的额外努力会更加加剧用户的情绪，最终反而要付出更多的成本来解决用户问题。

一个正确的思路是，当用户遇到问题时能够让用户便捷的找到客服，同时可以根据场景推荐猜测用户遇到的问题，引导用户自助解决，最终可以实现人工客诉量的减少。

仍以滴滴为例，用户集中投诉的场景集中在行程结束后（主要因为牵涉到费用）。滴滴的做法是，在行程结束页面，客服卡片高优并采用大卡片进行展示，并根据用户场景推荐常见问答（如，根据策略识别可能存在司机延迟结束计费问题，则优先展示“司机延迟结束计费”）。

实在找不到滴滴国内的截图，只能用一下DiDiglobal的图示意

以上。

希望对你有启发。

本文由 @Estela 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。