作者：文超

2014年毕业于江南大学，毕业后在联想集团MBG从事手机传感器驱动研发工作。 2015年，他转行互联网，加入大众点评。 现就职于新美达KTV事业部。

我们戏称KTV事业部是大众点评内部的一个小“初创公司”。 加入KTV事业部这一年来，我们就像一个初创团队，从零开始，基本完成了KTV预订业务的第一阶段探索。

今天我就从业务角度给大家介绍一下KTV预订流程，以及我们在KTV预订流程发展上的探索。 今天的介绍主要分为以下几块：

KTV预约业务基本介绍

一个完整的KTV预订流程如上图所示：

用户从商户列表中找到目标KTV；

进入商户详情页面后，在详情页面选择演唱时段和套餐类型，进入套餐选择页面；

用户选择到店时间和包裹内容；

进入支付页面进行支付；

通知用户预订结果。

对于用户来说，在预订过程中需要决定的事情有很多，比如商家、时间、套餐类型、套餐等。在产品设计时，我们为用户简化了决策过程，让用户可以三页内做出决定。 完成所有选择。 简单流畅、决策步骤较少的购买流程对于提升用户的购买体验非常有帮助。 比如：我们刚和美团合并的时候，我们不能直接修改美团的商家详情页，所以我们就在美团的商家详情页修改。 商户详情页添加了到价目表页面的链接； 随着整合的深入，我们对美团商户详情页进行了改版。 将价目表嵌入商家详情页后，美团这边的交易量一天之内就增加了。 超过50%。

简单的流程背后，是KTV事业部成立一年来的诸多探索。 一年左右的时间，KTV预订业务经历了四轮较大的迭代：

1、KTV预订业务发展之初，KTV预订是通过商家自助录单+IVR（语音电话）通知商家接收订单的方式进行的。 每当新用户下订单时，都会向商家拨打 IVR 电话，宣布到货。 存储时间、所需套餐类型、用户手机号码等信息，然后商户决定是否接受。 这样，商家有最大的自由度来决定是否接受订单，但对于用户来说，从支付成功到预订成功（或失败）的时间间隔会比较长，用户体验不太好。

2、第二阶段，我们尝试引入库存模式：商家提前预留一部分库存供大众点评平台销售。 用户下单时，如果库存尚未售出，则直接扣除库存并通知商家； 那么IVR会通知商家的做法是库存模型的降级：当库存售完时，采用之前的IVR接单方式，让商家决定是否接受订单。 现阶段我们还拓展了商家接单的渠道。 除了IVR之外，我们还添加了商户后台通知和审核经理通知，并让用户决定使用哪种通知方式。

3、第三阶段，销售方式拓展：新增按人数销售方式（主要针对华南部分城市KTV+自助餐捆绑销售场景），时段套餐模式添加;

4、第四阶段承接美团预订业务。 在展示端，我们为商户提供POI++等增值服务； 在交易方面，我们探索了三方系统之间的直接连接，并在销售过程中与客户服务进行了干预。 同时引入了房态管理的概念，拓展了原有的KTV库存概念。

KTV预订平台整体流程与团购流程类似，包括点餐、审核、展示、下单、审价、支付、消费、退款、结算等流程。 与传统的团购模式不同，在展示环节和订购环节，我们需要关注用户选择的日期、时间段、套餐类型、套餐等信息； 从订单维度来看，KTV预订订单包含的内容比传统团购包含的内容更多。 内容会更加丰富； 另外，支付成功后，与传统团购直接扣除库存的方式不同，KTV预订会经过完整的预订流程来决定商家是否接受用户的订单。

目前KTV预订平台服务于销售、运营、用户、售中客服、商户等。KTV预订平台的订单录入以销售报表的形式发起。 通过操作审核后，在线下单供用户购买； 运营人员可以在KTV预订平台上进行预订计划审核、广告发布、活动以及即时折扣发布。 ；会员参与购买流程并付款； 付款后KTV预订，如果商家拒绝或超时未能回复订单，售中客服会介入联系商家，恢复这些失败的订单； 商家可以在平台上进行订单查询、验证、对账，发布自己的预订折扣、自我促销活动等，从而增加自己的曝光度。

在设计开发KTV预约平台时，系统以微服务的形式进行组织，主要分为由各种组件组成的服务层和由Web界面/接口组成的展示层。

服务层：对于KTV预订平台的流程，有-（审核、操作）-（展示）-（点餐）-（预订）-（消费）-（退款）等； 这些服务依赖于-服务，如-（折扣）、-（房态、预订库存）、-（预订三方对接）、-（预订商家通知）、In-Sale-（预订中销售）客户服务）等

展示层：我们向用户、商户、运营、销售客服等提供相应的展示接口。展示端开发时，各个Web端只提供前端调用的接口，采用动静分离的方式来完成展示端的调用。接口与逻辑的解耦以及接口的复用。 例如：订单查询和验证接口可以同时用于PC。 网站上的商户后台和手机上的评论管理器提供数据源。

KTV预约展示端抽象

在下面介绍之前，我们先简单介绍一下KTV预订的房间模式。 房态模型会影响显示端的显示方式、能否生成新订单以及订单成功后如何进行预订流程。

由于是预订业务，所以在预订之前需要确定发生的时间和地点。 对于KTV预订，时间维度为月、日、到店时间和离店时间； 位置尺寸就是选择什么样的封装类型。 基于此，抽象出KTV预订的房态模型：

在某一天、某一时间段、某一套餐类型，可能存在三种状态：房屋可售、商家需接受订单确认、房屋已满。 房态变更发生在KTV预订平台预订后或商家或销售平台修改库存时。

对于库存订单，当预约成功时，库存减1。当库存被扣除时，特定时间段内的某个套餐类型会切换到接单状态（之所以会这样是因为商家只是我们的保证库存会少一些，线下也会有没有卖完的包房）； 当订单接收状态有订单发起预订，且商户不接受的订单总数超过一定值时，该期间的套餐类型将会切换。 当房间订满后，该期间将不再有新的预订。

商户和售中客服可以调整特定日期特定套餐类型的房态。 商户可以从空房状态切换到满房状态，也可以直接在满房状态和接单状态之间切换。

不难发现，KTV预订的房态是周期性生成的，因此房态模型在存储时会分为两张表：房态规则表和每日房态表。 当每个调用者调用每日房态表查询特定时段的房态时，如果尚未生成该时段的房态，则会从房态规则表中复制一份数据到每日房间中状态表。

预订产品的SKU粒度比传统团购产品复杂得多，这在设计预订系统时是一个挑战。

在KTV预订场景中，一个SKU需要细化为某一天的某个套餐、某个套餐类型、某个时间段。 我们在实现数据的时候，设计了三个表-Item和-Item-来存储数据。 该表用于对所有项目进行分组。 Item 和 Item-Attr 之间存在一对多关系。 该表用于补充Item表中的属性。 这样设计的存储结构在系统需求扩大时更加灵活：比如我们刚开发KTV预约系统时，没有打包模型出售。 当我们后来添加套餐销售模型时，在不改变表结构的情况下，只需要在Attr表中添加一个新的属性就可以支持新的业务。

KTV预约内容在用户界面上显示时，则是另一种风格：分为价目表页面显示和套餐选择页面显示。 价目表页面只关注某一套餐类型当周的最低价，3），为了简化逻辑，我们在将存储层的数据转换为表现层的数据时，抽象了一个概念：将同一周、同一时间段、同一套餐类型的不同套餐分类为一，用于展示价目表； 里面的内容是用来显示套餐选择页面的。

在实际订购阶段，所有放在一个包裹下的包裹共享一个库存单位。

KTV点餐模式的演变

接下来我们将介绍KTV预约点餐模式的演变。 KTV预约业务的订单模式大致分为四个阶段。 在演化过程中，数据结构越来越复杂，订单状态修改和订单状态查询涉及的子系统和查询接口也逐渐细化。 下面解释这四个阶段的演变。

KTV预约产品发展之初，KTV商业模式尚不清晰。 为了完成快速的在线验证，我们将订单所有可能的状态合并到一个字段中，导致订单状态既包括预订过程中的状态，也包括预订过程中的状态。 显示支付流程、消费流程、退款流程等多个流程的状态。

这种状态的一个很大的问题是无法进行状态回溯和流程排序。 例如，一个订单经历这样的流程：支付成功（1）->预订失败（3）->系统自动发起退货支付（4）->退款成功（5）； 那么其流程如下：支付成功（1）->预订成功（2）->用户发起退款（4）->退款成功（5）。 两条路径的最终状态是相同的。 仅从数据库中订单的最终状态来看，无法区分两个订单之间预订流程的差异。

第二阶段是业务拓展阶段。 现阶段，系统需要快速支持新的业务需求。 例如，预订流程不再是简单的IVR语音通话通知商家接受订单，还增加了库存模式。 如果有库存，需要先扣除库存。 当没有库存时，需要通过多种方式通知商家，由商家决定是否接受订单。 为了支持这些业务，方便业务流程回溯，迫于开发进度的压力，我们对订单表进行了扩容，增加了 、 、 等字段，使得大部分业务流程也得到了部分支持。

这种订单模式的演变很快解决了业务扩张的问题。 例如，当我们后来推出系统直连、售中恢复等多种预订模式时，已经不足以支撑每种预订模式的业务切换需求。 于是我们开始尝试将不同的业务数据存储在自己的数据表中，于是就有了第三阶段。

第三阶段KTV预订，KTV预订的订单量已达到一定规模，预订、退款等流程进一步扩大。 订单表中的混合数据被拆分到各个服务中。 不同的服务根据自身的实际情况而定。 数据组织的场景。 为了简化订单服务，订单状态只保留订单报表周期中的关键节点，如支付成功、预订成功、消费成功等。由于订单生命周期的各个阶段都会发生退款，因此也订单表中存在冗余。 一组退款结果数据，方便订单服务的各种查询场景。

现阶段的架构基本可以支持KTV预订业务，订单表的查询压力也由各个系统分担。 例如，如果结算过程依赖于消费记录表和退款记录表，则无需直接从订单表中查询数据。

为了进一步提高订单服务的稳定性，我们尝试将订单服务拆分为订单创建、更新服务和订单查询服务。 我们通过读写分离保证了系统的可靠性，避免订单创建和更新过程因大量查询而阻塞。 做作的; 它还可以防止查询服务挂起或创建挂起的服务，以确保订单的所有逻辑都不可用。

在实际应用场景中，每个调用者不仅关注订单的状态，还关注订单状态变化过程中发生的流程变化。 例如，当预约成功时，呼叫方会关注三方直连预约是否成功。 或者是否扣除库存且预订成功等； 消费成功后，商家会关注谁在什么平台发起了消费。 要组装一条“预订成功，已消费，消费后客服发起退款，退款成功”这样的订单状态描述，除了依赖订单表中的数据外，还需要消费数据、退款数据等数据。 支持。

KTV预订的来电者有很多，包括用户、商家、运营、销售、售后等。 在综合查询订单流程和订单状态时，每个来电者都需要了解订单状态、预订流程、消费流程、退款流程。 等业务流程，导致很多功能需要重复解释、重复开发，成本太高。 所以我们在原有所有服务的基础上增加了综合查询服务：综合查询服务用于响应不同调用者的查询需求，将调用者与复杂的业务逻辑隔离。

目前，KTV点餐模式正处于第三、第四阶段中期，综合查询服务正在逐步完善。 对于近期业务来说，第四阶段的订单模型已经可以满足KTV预订业务的订单查询需求。

KTV预约流程的演变

下面简单介绍一下KTV预约流程的演变。

在KTV预订业务模式的演进过程中，预订流程经历了较大的重构。

KTV 1.0探索阶段，当订单支付成功后，通过IVR直接通知商家，由商家决定接受订单还是拒绝订单，或者商家超时放弃订单而不回复。 此时的预订过程非常简单，可以在一次服务中完成。

在KTV2.0阶段，为了缩短预订成功的时间，最大限度地减少对商户的干扰，我们引入了库存模式：有库存时，先消耗库存订单。 此类订单不需要商家接受订单，用户成功支付后很快就会得到处理。 预订可以在短时间内完成。 同时，除了原有的IVR电话外，商户下单模式通知商户的渠道还包括商户后台和审核管家。 此时我们将商户通知流程从服务中分离出来，作为服务来使用。 利用多种渠道通知商户，为商户提供配置通知方式的功能。

相对而言，这两个阶段的项目结构都比较简单。 但当直连第三方系统、对接售内客服渠道时，服务中简单的逻辑判断就不能满足要求了。

在最近的迭代过程中，增加了与第三方系统的直连预订模式和与售中客服的订单恢复模式。

第三方系统直连是指直接与第三方KTV商家的ERP对接进行库存。 当发起新的预订请求时，直接向第三方平台发起库存削减请求，并包含预订人、预订时间等相关信息。 发送至第三方平台。 这种对接方式应该是最方便的KTV预约方式了。 但由于KTV行业系统研发能力的限制，只有部分KTV可以通过这种方式进行预订。 因此，KTV2.0阶段的库存计划和通知接单计划仍将继续。 保持。

售中客服恢复订单是指通知商家商家拒绝或者在超时时间内未接受订单。 售中客服主动联系商家，询问拒绝或漏单的原因，最大程度恢复订单。 涉及售中客服的预订渠道在酒店预订、旅游产品预订等场景已经有了一些相对成熟的应用。 KTV预订业务引入了售中客服流程，事实证明，这对于增加商户订单量非常有效。 增强。

添加三方直连和售中客服模式后，预订流程变得更加复杂（如上图）：订单支付成功后，首先判断是否是三方直连订单或者传统库存模式下的订单：如果是第三方直连订单，则直接向第三方平台发起预订，第三方平台通知预订成功或失败预订。 存在异常情况，当第三方平台出现异常时，三方直连模式将降级为商户接单模式； 库存模式为有库存则直接扣除库存，无库存则通知商家接受订单； 当商家拒绝订单或超时未接受订单时，订单将流入售中客服的订单池，由售中客服发送订单联系商家查看是否订单可以挽救。 看来预订流程比KTV2.0时代要复杂很多。

为了简化模型，我们对库存模式中的库存流程或者接单流程进行了抽象，将通知商家接单的模式视为库存抵扣模式的服务降级（如上图） 。 此次调整后，模式得到了一定程度的简化：每种预订模式都可以有自己的降级预订模式。 当当前预订方式有明确的预订结果时，预订流程结束。 当没有确认的预订结果时，切换到相应的降级。 模式重新发起订阅。 由于每种模式只有一种后续降级模式，因此该过程更容易抽象。

抽象出来的预订流程模块的执行流程如上图所示：当向预订平台成功发起订单支付后，预订平台根据参数确定当前使用的预订渠道。 判断完成后，向对应渠道发起异步预订流程，并记录在表中。 流程执行状态； 当特定通道返回预订结果时，对预订结果进行判断：如果预订结果最终状态为预订成功或预订失败，则预订流程结束； 当预订结果不是最终结果时，查询当前状态 通道的降级通道。 查询降级通道后，再次发起降级通道预约。

经过这样的抽象，KTV预订流程被拆分为五个服务：服务（用于协调责任链上的执行流程）、（用于直接与第三方系统对接）、（用于管理房间状态）、（用于管理房间状态）、（用于直接与第三方系统对接）、（用于通知商户通过各种渠道接受订单）、In-Sale（用于在售客服接收订单）。 各个服务的权责比较明确，耦合度比较低：比如需要增加新的三方直连方案时，只需要在服务中进行扩展； 当需要扩展新的商户通知方式时，只需在服务中进行相关开发即可； 添加新的预订方法时，只需在呼叫责任链中添加新的链接即可。 整个系统的可扩展性非常好。

以上是我对KTV事业部一年的业务发展过程中所经历的一些业务变化和重组的理解。 我在互联网行业的经历还不够丰富，对业务演进的总结和理解还不够完整。 希望大家批评指正。

《中生代科技》

连接技术专家的桥梁

促进科技交流