国际酒店用户服务能力提升（三）
本文承接《国际酒店用户服务能力提升（一）》、《国际酒店用户服务能力提升（二）》。前两篇文章中主要说了售前服务，本篇会重点说下售后服务相关业务和改进。
3. 售后体验
3.1 售后服务
售前用户体验对于用户来说是从浏览开始一直到支付完成用户购买流程的顺畅体验，而售后体验相对的是用户从购买完成一直到成功入住（离店）的体验了。
1、售后环节
从用户购买完成到成功入住的过程中，存在多个环节：
- 确认中（confirming）：用户下单支付后，需要代理商确认订单的环节。代理商会向它的货源（酒店/更上层的代理商）确认酒店商品的价格和库存，由于国际业务存在时差等原因这个环节是存在较长的确认时间的（1min 到 12h 不等）。在 confirming 环节中可能存在如下情况：
- 用户本身可能会取消订单，这种情况是用户主动触发虽然其中也会存在一些业务问题但是和缺陷无关这里不做讨论；
- 代理商也可能会拒单，拒单原因可能是库存原因无法提供房型产品也可能是由于价格上涨不能以原有价格进行售卖；
- 为保障用户的超时确认系统拒单。
- 已确认（confirmed）：用户的订单被代理商确认的环节，即代理商侧确认交易成功用户可以入住，对于用户来说是等待入住的状态。这个时候对于用户需要根据产品的退改条件进行变更，代理商在有特殊情况时也可以进行拒单。
- 到店（check-in）：用户入住到店环节。如果在 OTA 平台进行过酒店商品的预定，应该会体验过在入住酒店时，酒店的服务人员会向用户索要入住凭证并检查入住凭证是否无误，确认后酒店服务人员安排房间，用户入住。
- 到店无预定，很多时候是因为用户下单后较短时间内抵达酒店入住，代理商还没有完成向酒店下单，当然也存在代理商纰漏导致没有向酒店下单的情况；
- 到店无房，由于酒店（或代理商）存在超售的情况，即同一酒店房型售卖量超过了原有库存，可能会给用户升级房型入住或者告知用户客房已满无法入住。
- 离店（check-out）：用户完成入住离开酒店的环节，一些售后评价以及返现等都是在离店后完成。
2、售后客服
并且在售后场景中，用户还有很多其他诉求并且会在 APP 中进行线上咨询或者电话进线到客服沟通。例如：
（1）用户想要重新邮件发送入住凭证（操作类）
（2）用户想要确认售卖（已经下单的）酒店房型的基本信息（咨询类）
（3）用户到店后发现无预定或者无房（投诉类）
3.2 指标定义
为了衡量用户在售后环节的实际体验，定义了如下两个口径：缺陷率、SPO。
1、缺陷率
确认前拒单（confirming 环节）、确认后推翻（confirmed 环节）、到店无预定和到店无房（check-in 环节）与整体量做比率，再根据售后行业内的的客服专家衡量出的系数做加权，得到了加权缺陷率。从一定程度上，加权缺陷率反馈了在售后环节中我们存在问题的一个情况。其中，加权系数会以季度（年）为单位由客服专家根据用户的实际反馈情况（对用户的伤害情况）进行更新。如下图所示，是某一时间段内国际酒店的售后缺陷率情况。
2、SPO
SPO 的全称是 Service Per Order，即每个订单对应的服务量。其中服务由电话申请人工量（phone）和在线服务问题量（chat）两部分构成。如果说缺陷率是反馈我们自身问题的指标，那么 SPO 就是最直接反馈用户体验的指标。如下图所示，是某一时间段内国际酒店的售后 SPO 情况。
3.3 指标提升
1、降低缺陷率
缺陷率指标中，确认后推翻是无法干预的，能干预的只有确认前和到店环节，而确认前拒单是指标比重较大的一环，我们优先集中精力解决这一环节。由于代理商天然存在差异，各个代理商的拒单情况也是不同的，所以整体的思路在于对代理商的服务质量进行管控，扶持更高质量（缺陷率更低）的代理商，将订单流量向高质量代理商倾斜，自然可以带动整体的拒单率降低。这里面我们重点做了几件事：
（1）代理商管控：单个订单拒单后会在一段时间内禁售对应的代理商酒店商品；对代理商维度拒单严重的代理商进行惩罚，进行全量禁售即一段时间内不允许代理商在平台售卖产品；对缺陷率不好的代理商，在对客赔付等方面追加赔款；对于产单不多但是对整体缺陷影响较大的代理商，线下沟通一起协作降低确认前拒单率。并且在产品方面，在对代理商的平台上，罗列出代理商的缺陷情况、管控情况、对代理商收益的影响，使代理商能及时感知自身的缺陷情况并及时处理。
（2）流量置换：在用户订单被拒单时，我们在用户无感知的情况下更换到质量更高的代理商的同类产品上，替代用户完成下单。换单模式存在多种，涉及的业务也比较复杂，这里不一一赘述。
（3）平台补贴：为用户更换订单时为了让用户能成功入住到心怡的产品房型，会额外进行补贴价格。例如：原单被拒单并且拒单原因为价格上涨，那么系统会为用户重新生成订单并由平台补贴差价。
从问题分析、case by case 的排查、策略制定以及实施花费了近两个月的时间。期间我们改动了订单交易系统、禁售系统、售后供应链系统、代理商平台系统。当然，结果也是理想的，确认前拒单缺陷下降了 60%。而后的重点放在了解决到店缺陷率。
到店缺陷和确认前缺陷一个重要的差异点在于，这部分更依赖于代理商而不是平台的干预，所以这部分的改进我们的策略是通过运营手段干预。我们协调了部分运营的资源支持，对于存在到店风险的订单，由运营同事给代理商和酒店确认入住凭证的确认号（酒店入住的预定唯一标识）是否已经生成并且有效以及酒店是否有足够的房源能安排用户按照订单入住。
其实国际酒店业务相较于机票、国内酒店业务有一个很大的不同就在于上面提到的，有很多环节是非标准化的，可以理解成没有一套标准化的流程（接口）来解决诉求，这部分诉求无法通过系统直接实现。而非标准化的工作往往只能通过人工介入的方式来解决。对于客服人员来说，会形成一套标准的处理流程 SOP（Standard Operating Procedure），并在客服系统中呈现出来。而为了解决类似的诉求，我们也需要对运营构建一个系统来管理和解决用户的诉求。为此，我们搭建了众包系统来解决上面的问题。
众包系统的能力职责如下：
（1）事件接入能力：所有的众包任务需要有外界诉求触发，在众包系统中这一部分有用户、系统等多种不同的事件用来解决不同的诉求；
（2）任务分配和调度能力：将众包任务合理调度分配给不同处理该任务资质的运营人员，做到人效的最大化利用；
（3）任务处理和反馈能力：包含运营外呼用户代理商酒店能力（接入电信运营商坐席电话）、运营标准处理流程（SOP）、对用户展示过程和结果信息的能力（结果回填同步到订单）等；
（4）统计分析能力：包含邮件、报表、运营人员的人效统计分析能力等。
一个众包任务的基本主流程如下图所示：
2、降低 SPO
SPO 主要问题在咨询类上，经过产品同事的分析，这些问题主要原因在于订单详情页的展示和用户诉求不相匹配。在系列文章的开篇中有提到，国际酒店业务是从国内酒店业务中拆分而出，由于国内酒店业务占比更重，订单详情页的设计遵循了国内业务的诉求，而国际酒店用户的诉求在订单详情页面上没有很好的体现。我们对于国际酒店的订单详情页从页面的展示到系统代码进行了一次较大的重构。从指标方面，后续咨询类 SPO 降低了 60%。从技术方面，我们将原来分散在 4 个系统的代码整合并收口并精简了逻辑；从接口来看订单详情页的响应报文缩减 50%，优化后接口的响应时间从 2s 以上降低到 80ms。上文提到了，国际业务很多用户诉求是非标准化的。而拥有了众包系统，其实很多 SPO 的问题也迎刃而解。通过众包任务解决了很大一部分用户的咨询类、操作类诉求。在一些众包任务场景中用户在 APP 中点击按钮，后台就会生成众包任务由运营同事解决用户诉求，实现了非标准化流程的 APP 交互。从体验上也较呼入客服进线和线上 chat 沟通更好。整体来看，后续整体 SPO 指标降了约 40%。
3.4 到店缺陷预测
对于重运营的业务，研发角色一个重要的作用在于赋能和提效，而众包系统恰恰就是一个重运营的业务。我们在解决到店缺陷率时，会有运营人员人工对于可能存在风险的订单进行提前确认。那么如何衡量可能存在的风险订单是哪些呢？这里主要是当日或第二日入住的订单。但是就当日入住的订单的体量如果交给运营也是无法完全确认的，所以必须要缩小风险范围，将运营的资源用在最核心最容易发生到店缺陷的订单上。为了提前发现风险订单，我们尝试使用模型进行预测可能存在风险的国际酒店订单。这里参考借鉴了公司、业内的其他业务以及论文。
1、特征分析
我们根据业务，收集了大量可能对风险有影响的因素。经过初步的筛选，整理出了以下几个维度的特征：
（1）订单的基本信息 如：酒店房型、星级、价格；代理商；国家；有无确认号等
（2）统计信息 A. 反应酒店、城市、代理商服务能力的指标 B. 反应酒店、城市、代理商库存紧张程度的指标 C. 反应酒店、城市、代理商到店缺陷情况的指标
（3）时间信息 确认时长；提前入住天数；入住日期和预定日期日期差；入住最早 check-in 时间和确认时间差；入住时间日期周期特征；节假日因素等
2、模型选择
因为到店缺陷对用户的伤害是较大的，所以存在到店问题时基本上用户都会通过客服进行投诉，所以在客服系统中有客服对于订单问题的原因判断，即天然的存在对订单的标签标注该订单是存在到店缺陷。所以我们采用了有监督的决策树模型来进行到店缺陷风险单的预测。这里使用了 LightGBM 模型。
简单介绍下 LightGBM 模型：LigthGBM 是 boosting 集合模型中的新进成员，由微软提供，它和 XGBoost 一样是对 GBDT 的高效实现，原理上它和 GBDT 及 XGBoost 类似，都采用损失函数的负梯度作为当前决策树的残差近似值，去拟合新的决策树。LightGBM 在很多方面会比 XGBoost 表现的更为优秀。它有以下优势：
- 更快的训练效率
- 低内存使用
- 更高的准确率
- 支持并行化学习
- 可处理大规模数据
- 支持直接使用 category 特征
从下图实验数据可以看出，LightGBM 比 XGBoost 快将近 10 倍，内存占用率大约为 XGBoost 的 1/6，并且准确率也有提升。
3、效果
由于正负样本是不平衡的，即风险样本仅占非风险样本极小的一部分，所以对于特征数据我们做了过采样（OverSample）。
测试集上的效果如下： 准确率 0.93 精准率（微平均） 0.93 精准率（宏平均） 0.54 召回率（微平均） 0.93 召回率（宏平均） 0.67 f1 0.95 roc 0.67
从结果上看，运营每天最大的确认能力为 150 单，通过模型预测为风险的订单交给运营来进行确认，平均可以命中 9.4 单风险订单。虽然看上去命中数量不多，但是较原有的大海捞针方式进行确认命中率已经有了较大的提升。
3.5 疫情突发
2020 年初疫情的爆发，对国际酒店业务的打击无须赘述。但是国际酒店用户服务团队以及其他团队和部门都在坚持不懈尽己所能站在用户的角度保障用户的诉求。由于国际业务受打击最大，退改量激增，并且随着不同国家的政策等用户的行为和诉求也不停在变化。我所在的用户服务团队，很多同事年夜饭都没有吃，过年期间基本每天都是加班到深夜处理退票以及其他服务问题，保障用户顺利完成退票。在此表示对这一年期间以及疫情期间团队成员以及国际酒店其他团队同事的大力支持的感谢！相信随着疫情的好转，国际酒店业务会越来越好！
4. 总结经验
最后，分享下项目过程中的一些心得：
- 要理解业务和前人的逻辑和设计是为什么服务的才能更好的开发出贴合业务的系统；
- 业务的落地重点在于胆大心细、勇于试错、快速迭代。
1、携程专利：Ota平台到店无房的预测方法及系统 （https://patentimages.storage.googleapis.com/cf/a0/29/bbc97ae761a5d4/CN107506877A.pdf） 2、论文：预测房间取消达到减少不确定性因素同时提升收益 （https://www.researchgate.net/publication/310504011_Predicting_Hotel_Booking_Cancellation_to_Decrease_Uncertainty_and_Increase_Revenue）
头图：Unsplash
作者：张楚宸
来源：Qunar 技术沙龙 - 微信公众号 [ID：QunarTL]
转载：著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
- 发表于:
- 本文为 InfoQ 中文站特供稿件
- 首发地址：https://www.infoq.cn/article/SU0KZYI915tAQtNJrj0W
- 如有侵权，请联系 cloudcommunity@tencent.com 删除。
相关快讯
扫码
添加站长 进交流群
领取专属 10元无门槛券
私享最新 技术干货
腾讯云开发者
