国际酒店用户服务能力提升（一）

对于一个商业产品，不是只有盈利才是唯一的目的，去解决用户的诉求，提供更好的服务也是核心目的之一。本文将说下，在国际酒店一年的时间里，我们做了什么来为用户提供了更好的服务。

1. 业务背景

2018 年底 — 2019 年初对于国际酒店的业务来说是比较重要的时间节点，国际酒店从酒店业务中拆除成立单独的事业部。在 2019 年之前，酒店的业务国内与国际是统一的整体，背后的系统结构和开发人员也基本是统一的，但是这两个业务之间其实存在着很多的差异。

以国际业务为例：首先国际酒店不单单指的是国际业务，还包含了港澳台等国内海外业务，即实际的区分是根据用户的出行场景（比如是否可以使用身份证作为酒店预定和入住的凭证）；其次，在酒店商品售卖的场景中，国际的覆盖更广（国家、城市）酒店更多，并且会接入更多的代理商（包括国内以及海外的代理商）来为用户提供更优质的报价；然而，由于大环境的原因现阶段国内游的市场是比国际游更大的，在意味着国际业务有着更大的发展空间的同时，也意味着不论是从业务上还是技术上国内都是主导的。

这些差异导致在资源有限的情况下，由于业务和技术体系更向国内倾斜，整体上国际的服务不论售前还是售后在当时的情况都不是很好。2018 年底到 2019 年初，国际酒店的同事已经将国际从国内中剥离出来，但是还是沿用的国内已有的结构和系统。而我从机票事业部来到国际酒店事业部，有幸参与到了后续对售前、售后服务的改善过程。

2. 售前服务

2.1 指标定义

（1）如何理解售前服务？

售后服务我们都能理解，那么如何定义售前服务呢？售前服务在我们的定义中，指的是用户从进入我们的客户端搜索酒店开始一直到支付完酒店订单，整个过程中是否顺畅。顺畅与之相反就是在过程中对用户产生了拦截。

（2）如何衡量

从搜索开始一直到下单，总共经历了几个主要环节：酒店列表（L）、酒店详情（D）、预定（B）、填单（O 页）、支付（P）。而对于用户来说最希望的就是所见即所得：在最初搜索看到的价格就是最终购买的价格，并且在整个购买流程中发生库存变化导致无法购买要尽早的通知到用户。由此产生了两个概念：房价和房态。房价，即是酒店房型售卖的金额；房态，即是酒店房型库存状态。

那么，我们从用户的角度出发，定义了顺畅的概念：整体流程顺畅度 = L-D 顺畅度 × D-B 顺畅度 × B-O 顺畅度 × O-P 顺畅度。

其中，在 L-D、D-B、B-O 环节中存在房态顺畅度和房价顺畅度的概念，即 单一环节顺畅度 = （单一环节中）房态顺畅度 × 房价顺畅度。比如在预定环节中，房态不顺畅代表着之前浏览的报价对应的房型产品在预定时校验发现没有库存无法完成预定行为，提示给用户类似“房型售完，重新选择”；房价不顺畅代表着之前浏览的报价对应的房型产品在预定时存在库存，但是代理商对价格进行了调整，当前的价格高于浏览时的价格，提示给用户类似“价格上涨，发生变价”。O-P 环节的顺畅度构成比较简单，指交易过程中顺利完成支付。

有了抓手，才能对业务和系统进行改造以达到预期。我们的预期是将国际酒店整体流程顺畅度提升到 87%，期初的情况如下：

2.2 L-D 环节顺畅度提升

（1）What & Why & How

在上面提到的多个环节中，我主要负责的是 L-D 环节的指标提升以及系统改造。【L-D 期初指标】。这意味着只有有 30% 多的用户在这个阶段发生了变价或者房型存在问题的情况，但其实房态和房价的变化并没有那么频繁，绝大部分是由于系统机制不合理才导致问题的发生。上面有说道我们的整体流程顺畅度指标为 87%，经过推算 L-D 环节需要达到 95-98 区间，才有可能达到，意味着我们要将问题一一揪出并解决，并将 L-D 顺畅度做到极致。

我们先做出两种假设，分析下当前面临的问题：

假设一：全流程都进行实时搜索来获取酒店房价和房态，这样所有的环节都是最新的房价和房态，只有真实的报价和库存发生变化时才会有拦截产生，那么顺畅度会基本达到现实情况下的最高值。先说结论再说原因：可惜是不能的。

Qunar 作为一家 OTA 平台本身主要的售卖形式为售卖代理商提供的商品，意味着 Qunar 没有自己的库存，想要获取到酒店的房价和房态就要调用酒店的报价接口进行获取。就拿 L 页来说，L 页在客户端一页下存在几十家酒店，对于后端接口来说是几十次 D 页搜索。再看代理商接口，一个酒店可能有多个代理商都有售卖，那么要调用多个代理商的接口才能获取到尽可能更优质的酒店报价。但是不同代理商接口提供的 qps 是不一样的，从个位数到百位；单次请求的响应时间从 1s 到 10s。绝大多数的代理商提供的 qps 体量远小于 L 页实时搜索所需要的体量，并且用户在进行搜索后也不可能等待 10s 中获取 L 页的全部报价。

假设二：既然实时调用不可以，那么全使用缓存呢？比如在 L-D 全部使用缓存展示同一份报价，那么必然能保证 L-D 环节顺畅度 100%，结论依然是不能。我们的目标是整体流程的顺畅度，L-D 单一环节使用缓存必然会导致大量的报价会在 D-B 环节发生房态或房价的变化。

之前业务的侧重点在于尽量让用户在 D-B 环节是顺畅的，在 D 页时会实时查询代理商报价接口获取接口中的房态和房价，这样当用户短时间内进入 B 环节时，因为 D 的报价是最新的所以会提高 D-B 的顺畅度。相对的因为流量分配给了 D 页，为了避免 L 页触发抓取导致超过代理商 qps 上限，所以对 L 页做的策略是使用缓存中的报价，而由于 D 页是实时报价，导致 L-D 顺畅度较差。这也是为什么在期初 L-D 环节顺畅度情况不理想的主要原因。

其实，假设一和假设二中是两种极限情况，即全部使用实时报价和全部使用缓存。从假设一中我们可以得到一个结论是：实时的报价抓取调度是不符合实际情况的；从假设二以及历史经验中，我们得到的一个经验是：对抓取调度策略进行调整是能解决一定问题，不能一味的追求某一环节，多环节统一的合理的缓存以及更新机制运转才能达到整体较好的效果。

（2）报价抓取调度机制改造

① 国际酒店报价结构

前面有提到缓存以及更新的机制，我们把这种机制成为报价的抓取调度机制。酒店业务中，在供应侧一个代理商（供应商）称为 supplier，在报价侧进行存储（包装）后称为 wrapper，supplier 和 wrapper 之间绝大部分是一对一的关系，少部分是一对多的关系，因为下文不涉及一对多的分析，所以会以 wrapper 为主要分析对象。整个报价的结构可以简化成下图：

从图中能看出：报价缓存池用于缓存报价，报价逻辑和展示层等售前环节不区分是 L 还是 D 环节均使用该份缓存；缓存中存储的结构为酒店维度，一个酒店下会存储不同的 wrapper 报价，当请求一个代理商的某一酒店回数后，会更新缓存中对应酒店的 wrapper 报价。

将报价结构抽象一下，可以很清晰看出因果关系。售前报价视作输出，报价逻辑视作函数，报价缓存视作输入。那么可以得出一个结论是要想提高 L-D 顺畅度指标究其根本需要分析报价缓存在 L-D 环节不一致的原因。而报价缓存是依赖抓取回数进行更新，所以在分析过后需要对抓取调度机制进行调整和改造。

② 报价缓存以及抓取调度问题分析

首先，我们分析 L-D 缓存不一致的 bad case 主要有如下图的两种情况：

如上图中的情况，是 L 页给用户展示后，有新 wrapper（w3）回数

如上图中的情况，是 L 页在给用户展示后，有 wrapper（w2）更新了价格

为什么会产生这种差异呢？我们来看下原有的抓取调度机制，如下图：当一个用户进行 L 或 D 页访问时，会优先展示缓存报价，并发送该酒店下所有 wrapper 抓取消息到调度系统。调度系统会判断该次抓取是否需要进行，如果不需要进行的话忽略本次消息，需要的话再实时告诉下游系统对代理商接口进行报价抓取。这里如何判断呢？主要是通过维护了一份上次抓取时间和需要缓存的时间用于判断，当本次抓取时间和上次抓取时间的时间差小于需要缓存的时间，那么判断本次不需要抓取。当抓取完成后，视情况可能会更新用户侧展示的报价。

这个缓存时间如何得到呢？在原有机制中对于部分重点 wrapper 由产研进行配置，区分 L 和 D 两个不同当日环节。绝大部分重点 wrapper L 环节抓取请求缓存时间为 10s 到 10min 不等，D 环节缓存时间为 0s 到 1min 不等。剩余 wrapper 会采用代理商提供的缓存时间，由代理商通知运营进行修改以求不超过代理商能提供的最大 qps 限制，不区分 L 和 D 环节，缓存时间为 10min 到 2h 不等。

通过上面的分析，我们能看出：

1. D 页基本是依赖实时报价；
2. L 页看上去是依赖缓存报价，但是国际业务天然的一个形态是请求体量不大但是覆盖的国家、城市、酒店多，请求比较离散，在这种情况下缓存很难做到很好的覆盖，所以L页也在一定程度上依赖实时报价。

而上文提到过由于代理商接口的原因，实时是不可靠的。所以我们的策略基调锁定在合理的调配和利用代理商接口资源，建立基于离线缓存的报价策略。同时，为了避免人工配置导致的低效和不合理的问题，我们希望在构建的过程尽量做到自适应的调配来替代人工配置。解决思路如下图所示，对于指标影响最大的就是相对来说比较热门的报价，而重中之重就是做好离线抓取，来做到热门报价的自动更新，来保障报价的新鲜度。

头图：Unsplash

作者：张楚宸

原文：国际酒店用户服务能力提升（一）

来源：Qunar 技术沙龙 - 微信公众号 [ID：QunarTL]

转载：著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。