一种订单管理方法和系统与流程

[0001]
本申请涉及信息处理领域，尤其涉及一种订单管理方法和系统。


背景技术：

[0002]
在线预订酒店已经成为人们外出预订酒店的一种主流方式。通常情况下，人们可通过在线旅游代理(online travel agent，ota)或旅游平台，比如携程、去哪儿等(以下简称平台)，预订酒店客房。平台可通过邮件形式将预订信息发送至酒店。酒店确认房态后给予回复，比如接受预订，或，满房不可预订。然而，酒店的处理依赖人工审核，处理效率受很多因素的影响，比如人力、忙闲时段、淡旺季等因素。因此，在有些情况下，人们可能需要等待很长时间才能收到酒店的回复。
[0003]
为了避免长时间的等待而给用户带来的不良体验，平台往往会在等待一段时间后，如未仍收到酒店回复，就安排话务员电话催单。这样一来，电话催单量也较大。这些需要催单的订单往往通过排队的方式依次达到话务员，由话务员来催单。但实际情况是，有可能某个订单大概率会较快回复，但却执行了多余的催单，而真正值得催单的订单，比如特别着急的订单，却因为排队积压未得到及时处理。即“不需要催单而催单”，同时也存在“需要优先催单但未及时催单”。


技术实现要素：

[0004]
本申请实施例提供了一种订单管理方法和系统，以期根据订单的缓急程度来催单，减小不必要的人力浪费，同时提高订单处理效率。
[0005]
第一方面，提供了一种订单管理方法，该方法包括：向酒店管理系统发送订单，该订单用于向该酒店管理系统请求预订酒店，该订单包括入住时间；基于该订单的创建时间与入住时间的时间差，以及该订单的预测回复时长，确定等待时长；其中，所述预测回复时长是从向酒店管理系统发送所述订单到接收到对所述订单的回复所经历的时长的预测值，所述等待时长是在发出催单提示前等待所述回复的时长；在等待时长内未接收到对该订单的回复的情况下，发出催单提示。
[0006]
应理解，上述方法可以由订单管理系统来执行。该订单管理系统例如可以是旅游平台、旅游代理、差旅平台等可提供在线预订酒店服务的系统。本申请对于该订单管理系统的具体形式和实现方式不作限定。
[0007]
基于上述技术方案，基于订单的创建时间与入住时间的时间差，以及该订单的预订回复时长，来设计不同的等待时长。例如，对于那些预测回复时长很长，比如超出了用户能够容忍的时长范围，但又希望尽快入住的订单，设计较短的等待时长，也即可以在短时间内安排催单，从而提升了处理效率；对于那些预测回复时长较短，比如在用户能够容忍的时长范围内，或者不着急入住的订单，设计较长的等待时长，可以使得部分订单在等待的过程中因接收到回复而免去催单，从而可以节省人力。因此总体而言，可以优先处理急单，同时也兼顾其他订单，对有限的人力资源做出合理地安排，订单的处理效率得以提升。
[0008]
结合第一方面，在第一方面的某些实现方式中，所述时间差越小，所述等待时长越小。
[0009]
时间差小，也就意味着用户的下单时间和入住时间挨得很近，用户可能很快就要入住酒店。换言之，订单的创建时间与入住时间的时间差越小，订单越着急。对于着急的订单，可以设计较短的等待时长，使得系统在等待时长内未接收到对该订单的回复的情况下，尽快安排电话催单。从而可以快速地处理急单，使得用户体验提升。
[0010]
结合第一方面，在第一方面的某些实现方式中，所述基于订单的创建时间与入住时间的时间差以及对所述订单的回复的预测回复时长，确定等待时长，包括：基于所述订单的类型、所述创建时间所属的时段，以及所述订单预测回复时长，确定所述等待时长。
[0011]
通过订单的类型和创建时间所属的时段来将上述创建时间与入住时间的时间差具体化，可以系统可以基于多个不同的场景来设计等待时长。
[0012]
可选地，订单的类型包括当天订单和隔天订单。
[0013]
可选地，时段包括：早间、午间、晚间和夜间；或，所述时段包括：日间、晚间、夜间、凌晨。
[0014]
基于上述订单的类型和时段的不同组合，可以得到多种不同的场景。比如将当天订单、隔天订单和早间、午间、晚间、夜间这四个时段组合，可以得到如下八种场景：早间创建的当天订单、午间创建的当天订单、晚间创建的当天订单、夜间创建的当天订单、早间创建的隔间订单、午间创建的隔天订单、晚间创建的隔天订单和夜间创建的隔天订单。
[0015]
结合第一方面，在第一方面的某些实现方式中，所述等待时长包括第一等待时长和第二等待时长，其中，所述第一等待时长是在所述预测回复时长小于或等于预设门限的情况下的等待时长；所述第二等待时长是在所预测回复时长大于所述预设门限的情况下的等待时长，所述第一等待时长大于所述第二等待时长。
[0016]
对不同缓急程度和不同预测回复时长的订单，设计不同的等待时长。基于不同的等待时长，系统可以优先处理急单，同时兼顾其他订单，对有限的人力资源做出合理地安排，订单的处理效率得以提升。
[0017]
结合第一方面，在第一方面的某些实现方式中，所述预测回复时长是由预测模型基于所述订单预测得出的。
[0018]
可选地，所述预测模型是基于至少两种机器学习算法得到的至少两个子模型的融合。
[0019]
通过采用多种机器学习算法来训练子模型，并将多个子模型的输出融合，可以得到融合模型输出的预测回复时长。采用多种机器学习算法可以平衡各种算法的特点，提高预测的稳定性、准确性和泛化能力。
[0020]
可选地，所述至少两种机器学习算法包括：极致梯度提升(extreme gradient boosting，xgboost)算法、随机森林(random forest)算法或自适应增强(adaptive boosting，adaboost)算法。
[0021]
一种可能的设计是，上述至少两个子模型包括：基于极致梯度提升算法训练得到的子模型、基于随机森林算法训练得到的子模型和基于自适应增强算法训练得到的子模型。
[0022]
进一步地，所述方法还包括：基于更新的样本对所述预测模型进行训练。
[0023]
基于更新的样本对预测模型进行训练，可以提高预测模型的预测准确性。更新的样本可以是指基于新增的订单确定的预测回复时长、等待时长以及酒店管理系统回复订单实际等待的时长。通过周期性地对样本进行更新，可以使得预测模型能够基于近期的变化趋势来更准确地预测未来的订单的预测回复时长。
[0024]
第二方面，提供了一种订单管理系统，该订单管理系统包括用于执行第一方面中任一种可能实现方式中的方法的各个模块或单元。应理解，所述各个模块或单元可通过执行计算机程序来实现相应的功能。
[0025]
第三方面，提供了一种计算设备，该计算设备包括：存储器和处理器。该存储器可用于存储计算机程序；该处理器可用于调用所述存储器中的计算机程序，以使得所述计算设备执行上述第一方面中任一种可能实现方式中的方法。可选地，该计算设备还包括通信接口，该通信接口与处理器耦合，该通信接口用于输入和/或输出信息，所述信息比如包括订单。
[0026]
可选地，该计算设备中部署有如第二方面中所述的订单管理系统。
[0027]
可选地，该计算设备为服务器。
[0028]
第四方面，提供了一种计算机程序产品，所述计算机程序产品包括：计算机程序(也可以称为代码，或指令)，当所述计算机程序被运行时，使得计算机执行上述第一方面任一种可能实现方式中的方法。
[0029]
第五方面，提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序(也可以称为代码，或指令)。当所述计算机程序被运行时，使得计算机执行上述第一方面任一种可能实现方式中的方法。
附图说明
[0030]
图1是适用于本申请实施例提供的订单管理方法的系统架构的示意图；
[0031]
图2是本申请实施例提供的订单管理方法的示意性流程图；
[0032]
图3是本申请实施例提供的订单管理系统的示意性框图；
[0033]
图4是本申请实施例提供的订单管理系统的另一示意性框图；
[0034]
图5是本申请实施例提供的计算设备的示意性框图。
具体实施方式
[0035]
下面将结合附图，对本申请中的技术方案进行描述。
[0036]
本申请实施例提供的订单管理方法可以应用于计算机上。该计算机包括硬件层、运行在硬件层之上的操作系统层，以及运行在操作系统层上的应用层。该硬件层包括(central processing unit，cpu)、内存管理单元(memory management unit，mmu)和内存(也称为主存)等硬件。该操作系统可以是任意一种或多种通过进程(process)实现业务处理的计算机操作系统，例如，linux操作系统、unix操作系统、安卓操作系统(android operating systerm，android os)、鸿蒙(harmony)os、ios操作系统或windows操作系统等。该应用层包含浏览器、通讯录、文字处理软件、即时通信软件等应用。并且，在本申请实施例中，该计算机可以是任何能够通过运行记录有本申请实施例的订单管理方法的代码的程序，以根据本申请实施例的订单管理方法进行订单管理即可。本申请实施例的订单管理方
法的执行主体可以是计算机设备，或者，是计算机设备中能够调用程序并执行程序的功能模块。
[0037]
在本申请实施例中，终端也可以称为用户设备(user equipment，ue)、接入终端、用户单元、用户站、移动站、移动台、远方站、远程终端、移动设备、用户终端、终端设备、无线通信设备、用户代理或用户装置。
[0038]
终端可以是一种向用户提供语音/数据连通性的设备。终端可以包括具有无线连接功能的设备。例如，具有无线连接功能的手持式设备、车载设备等。目前，一些终端的举例可以为：手机(mobile phone)、平板电脑(pad)、具有无线收发功能的电脑(如笔记本电脑、掌上电脑等)、移动互联网设备(mobile internet device，mid)、虚拟现实(virtual reality，vr)设备、增强现实(augmented reality，ar)设备、工业控制(industrial control)中的无线终端、无人驾驶(self driving)中的无线终端、远程医疗(remote medical)中的无线终端、智能电网(smart grid)中的无线终端、运输安全(transportation safety)中的无线终端、智慧城市(smart city)中的无线终端、智慧家庭(smart home)中的无线终端、蜂窝电话、无绳电话、会话启动协议(session initiation protocol，sip)电话、无线本地环路(wireless local loop，wll)站、个人数字助理(personal digital assistant，pda)、具有无线通信功能的手持设备、计算设备或连接到无线调制解调器的其它处理设备、车载设备、可穿戴设备，5g网络中的终端或者未来演进的公用陆地移动通信网络(public land mobile network，plmn)中的终端等。
[0039]
当然，终端也可以包括可通过有线连接接入网络的设备。比如，个人计算机(personal computer，pc)等。
[0040]
此外，终端还可以是物联网(internet of things，iot)系统中的终端设备。iot是未来信息技术发展的重要组成部分。其主要技术特点是将物品通过通信技术与网络连接，从而实现人机互连、物物互连的智能化网络。iot技术可以通过例如窄带(narrow band，nb)技术，做到海量连接，深度覆盖，终端省电。
[0041]
图1是适用于本申请实施例提供的订单管理方法的系统架构的示意图。如图1所示，该系统100可以包括：平台110、终端120和酒店管理系统130。
[0042]
其中，平台110可以是旅游代理、旅游平台、差旅平台等可用于实现在线预订酒店客房的系统。平台110的功能例如可通过计算设备来实现，比如，该平台110可以部署在一台或多台服务器(即，计算设备的一例)上。本申请对此不作限定。
[0043]
用户若希望预订酒店，可通过客户端登录平台110。比如，用户可通过安装有该平台110的应用程序(application，app)(即，客户端的一例)的终端120登录平台110，并通过平台110在线预订酒店。平台110可基于用户的操作，生成订单，并可通过互联网将该订单发送至酒店管理系统130。平台110例如可以通过邮件或传真等形式向酒店管理系统130发送订单。酒店管理系统130可基于订单，给予回复。比如，若用户预订的酒店已满房，则回复不可预订；若用户预订的客房为空房，则回复可预订等。本申请实施例对此不作限定。
[0044]
应理解，图1中仅为示例，示出了一个终端与平台的互连关系。事实上，在同一个时段，可能有成千上万个用户正在通过客户端登录平台110，以通过平台110在线预订酒店。
[0045]
由于酒店的处理依赖人工审核，处理效率受人力、忙闲时段、淡旺季等诸多因素的影响而不同。比如，淡季的处理效率高于旺季，空闲时段的处理效率高于繁忙时段。为了避
免长时间等待酒店回复可能带来的不良的用户体验，平台在等待一段时间后，比如等待x分钟(x为预定义的值)，如未收到酒店方回复，会安排话务员电话催单。
[0046]
但可以理解，在订单较多的情况下，比如旺季、繁忙时段，将会存在较多的订单需要催单。这些订单可通过排队的方式依次被话务员处理。然而，订单的缓急程度并不相同。比如，有些订单可能是需要预定一周后的酒店客房；也有些订单可能是需要预定当天或第二天的酒店客房。而话务员依次从队列中获取到订单信息，挨个进行催单，可能会导致不需要催单的订单被催单，而真正需要催单的订单却未及时催单。一方面造成了人力资源的浪费，另一方面部分着急的订单未得以及时处理，导致用户体验不好。
[0047]
鉴于此，本申请提供了一种订单管理方法和系统。通过结合订单的创建时间与入住时间的时间差，以及对订单的回复时长的预测，确定催单的等待时长。从而可以对急需处理的订单优先催单。比如，订单的创建时间与入住时间的时间差较小的订单，也即可能需要尽快入住的订单，如当天订单，可以优先安排催单；订单的创建时间与入住时间的时间差较大的订单，也即可能不是着急要入住的订单，如隔天订单，可以稍微暂缓处理。由此，可以将有限的人力资源优先安排用来处理真正需要催单的订单，使得着急的订单得以及时处理，提升用户体验。
[0048]
下面将结合附图对本申请提供的订单管理方法和系统做详细说明。
[0049]
图2是本申请实施例提供的订单管理方法200的示意性流程图。图2所示的方法例如可以由订单管理系统来执行。该订单管理系统例如可以是部署在计算设备(如服务器)上的系统。因此更具体地说，图2所示的方法例如可以由部署了该订单管理系统的计算设备来实现。
[0050]
如图2所示，该方法200可以包括步骤210至260。下面将对方法200中的各步骤做详细说明。
[0051]
在步骤210中，向酒店管理系统发送订单。
[0052]
如前所述，用户可通过客户端登录订单管理系统，并通过订单管理系统在线预订酒店。该订单管理系统基于用户的在线操作，可以接收到用户预订酒店的请求。此后，该订单管理系统可以基于用户预订酒店的请求，生成发送至该酒店的酒店管理系统的订单。该订单中例如可以包括创建时间、最晚到店时间、入住时间、离店时间、入住房间号、支付方式、下单渠道、房价金额等信息。下文示例性地给出了由该订单管理系统发送至酒店管理系统的订单的一例：
[0053][0054]
其中，订单编号可以由订单管理系统基于用户提交的订单生成。每个订单可对应一个唯一的编号。创建时间可以是指基于用户的下单而创建订单的时间。通常情况下，订单管理系统可基于用户的下单，实时地创建订单，因此创建时间也可以理解为是用户的下单时间。最晚到店时间可以是指用户到店的最晚时间。也就是说，用户最晚不超过该时间到店。如果用户超过该时间还未到店，可视为用户自动放弃对该订单中所预订的房间的预订。
[0055]
应理解，上文所列举的订单所包含的具体信息仅为示例，不应对本申请构成任何限定。订单也可以包括比上文所列举更多或更少的信息，或者，其中的部分术语也可通过其他可表示相同或相似含义的术语来替代。本申请实施例对此不作任何限定。
[0056]
在本申请实施例中，可以将订单管理系统中用于创建和保存订单的模块称为订单模块。该订单模块可用于，基于用户的在线预订，创建订单；还可用于存储订单，例如可以将历史订单以数据库的形式保存在本地。
[0057]
酒店管理系统可以在步骤210中接收到来自订单管理系统(比如，来自订单管理系统中的订单模块)的订单。基于该订单中的信息，酒店管理系统可以获知用户希望预订的房间、入住时间、离店时间、最晚到店时间、下单渠道等信息。
[0058]
酒店的工作人员可以基于该订单所预订的入住时段、房间等信息来确定是否可接受该订单的预订。比如，若在预订的入住时段内该房间暂未被其他用户预订，则可接受该订单；若在预订的入住时段内该房间已经被其他用户预订，则拒绝该订单，或者还可根据订单信息，比如房型、入住时段，推荐其他可预订的房间供用户选择。本申请实施例对此不作限定。
[0059]
如前所述，酒店的工作人员可能会受到人力、忙闲时段、淡旺季等诸多因素的影响，可能未能够在接收到该订单后及时予以回复。通常情况下，为了避免用户的长时间等
待，订单管理系统可以在等待一段时间后，若仍为收到来自酒店管理系统的回复，则安排话务员催单。
[0060]
本申请实施例中对订单管理系统的等待时间做出改进，使得订单管理系统能够根据订单的缓急程序来安排话务员催单。
[0061]
在步骤220中，获取该订单的预测回复时长。
[0062]
订单管理系统可以基于该订单，获取从向酒店管理系统发送订单到接收到酒店管理系统对该订单的回复可能需要经历的时长的预测值。其中，从向酒店管理系统发送订单到接收到该酒店管理系统对该订单的回复所经历的时长的预测值可以称为预测回复时长。该预测回复时长可以由部署在该订单管理系统中的预测模型来预测，或者说，该订单管理系统可以从预测模型来获取该订单的预测回复时长。该预测模型可以通过机器学习的算法，基于历史数据训练得到。下面将分别对模型训练阶段和模型预测阶段分别展开说明。
[0063]
模型训练阶段：
[0064]
该预测模型可以是通过机器学习算法进行训练获得的。用于训练的样本可以是历史数据。比如，可以将从当前时间往前推算若干个月或若干年的历史数据作为样本来对该预测模型进行训练。其中，历史数据从历史订单中获取。如前所述，历史订单可以保存在该订单管理系统中，比如，订单管理系统的订单模块中。历史订单可以以数据库的形式存储在订单模块中，由该历史订单所获取到的历史数据具体可以包括订单编号、创建时间、入住时间、离店时间、预订渠道、支付方式、城市编号、酒店编号、房型编号、入住人等。这些历史数据可以输入至预测模型中，以获得预测回复时长。
[0065]
该历史数据还可以包括每个订单的实际回复时长，也即，从该订单管理系统向酒店管理系统发送订单至接收到该酒店管理系统对该订单的回复实际经历的时长。
[0066]
在训练过程中，可以将实际回复时长作为优化目标来构建函数，比如包括但不限于，损失函数(loss function)、代价函数(cost function)或目标函数(objective function)。通过构建函数，可以衡量预测值与目标值的差异，从而训练得到预测模型。在本实施例中，预测值可以是上述预测回复时长，回复值可以是上述实际回复时长。通过训练，可以使得该预测模型输出的预测回复时长越来越逼近实际回复时长。
[0067]
可选地，在训练之前还可对历史数据进行数据清洗、特征提取等操作。
[0068]
其中，数据清洗可以是指对订单中的原始数据进行处理，剔除错误值、缺失值，得到可用于分析的结构化数据集。例如：原始数据中可能会包含一些错误信息，比如创建订单时间晚于入住时间这种不合逻辑的脏数据，或者因某些信息缺失导致的空数据，都需要剔除，最终得到干净完整的表格数据。该数据表格可以理解为标准的excel表格形式的数据结构，行与列对应真实有效的数据值。
[0069]
特征提取具体可以是指，对结构化数据进行深度加工，构造出更多能体现数据规律的信息，追加更新到数据表中，这些信息比原始信息更能反应数据的特点，对预测有着更好的效果，能够提升预测的准确度。
[0070]
特征提取具体可以包括特征构造和特征选择。其中，特征构造可以是指创建特征，特征选择可以是指从新创建的特征中以合适的方式提取出重要的特征。
[0071]
下文列举了一些特征提取的具体处理方式。
[0072]
二值化处理：比如，订单的创建时间是否是节假日当天，是为1，否为0。研究发现这
一信息对酒店管理系统的回复时长有很强的影响。如果在节假日当天预订，酒店普遍的反应速度较慢，反之则较快。
[0073]
分箱处理：比如，提前预订的天数，当天预订标记为0，提前一天预订标记为1，提前2-7天标记预订为2，提前8-13天预订标记为3，提前14天以上预订标记为4。研究发现提前预订的时间越短，订单越紧急，酒店的处理效率越高，反之则回复越慢。
[0074]
统计学特征：比如，该酒店历史回复时长的平均值。统计学特征刻画了酒店的历史表现，凸显了不同酒店的服务差异，研究发现这个信息有着很高的影响力。
[0075]
时间特征：比如，入住的月份。研究发现酒店存在淡旺季，入住的月份也会影响回复时长的长短。
[0076]
特征提取的常用方法还包括统计学变换、特征组合、归一化、对数变换等，为了简洁，这里不一一列举。
[0077]
应理解，上文仅为便于理解特征提取的具体处理方式，而结合具体的例子来说明，这些例子不应对本申请实施例构成任何限定。
[0078]
基于上述操作后的数据可被输入至待训练的预测模型中，以用于对预测模型进行训练。
[0079]
将历史数据(比如原始的历史数据或经过数据清洗、特征提取等操作得到的数据)作为样本，通过机器学习算法，例如可以包括但不限于，支持向量机(support vector machine，svm)，卷积神经网络(convolutional neural network，cnn)或者循环神经网络(recurrent neural network，rnn)等，对该历史数据进行学习，可以构建得到预测模型。在构建得到该预测模型后，该预测模型便可上线使用。
[0080]
基于上述方法训练得到的预测模型可以是一个线性模型，例如，线性函数，也可以是非线性模型，例如，神经网络模型。该预测模型可直接应用于本申请实施例所提供的订单管理系统中，以用于对订单的回复时长进行预测。
[0081]
为了提高预测的稳定性和准确性，同时提高预测的泛化能力，还可以通过多种算法来构建多个模型，并将该多个模型进行融合。为便于区分和说明，下文中将用于融合的模型称为子模型，多个子模型可以融合得到预测模型。
[0082]
上述历史数据可以作为样本，输入至多个子模型中，以基于不同的算法来训练。
[0083]
一示例，可以通过极致梯度提升树算法、随机森林算法和自适应增强算法来分别训练子模型。
[0084]
其中，极致梯度提升树算法是一种串行决策树算法，通过构造m棵树，最终将m个结果累加起来得到最终预测值。预测公式为：第m棵树最终预测值＝第m-1棵树预测值+学习速率
×
第m棵树的预测值。学习速率是一个大于0的常数，默认取0.1，越大累加的速度越快。
[0085]
随机森林算法是一种并行决策树算法，它与极致梯度提升树算法的不同之处在于极致梯度提升树算法要将所有预测结果串行的累加起来，而随机森林算法是将所有的预测结果求平均值。例如：第一棵树预测值为15分钟，第二棵树为30分钟，第三棵树为20分钟，最终预测值＝(15+30+20)/3＝21.6分钟。
[0086]
自适应增强算法也是一种串行算法，但它与极致梯度提升树算法的区别在于，极致梯度提升树算法的学习速率为固定的常数，而自适应增强算法可以自动的获取每一棵树最优的学习速率，相当于树的权重。例如：第一棵树预测值为15分钟，权重0.5；第二棵树为
30分钟，权重0.3；第三棵树为20分钟，权重0.2。最终预测值＝15
×
0.5+30
×
0.3+20
×
0.2＝20.5分钟；另一个区别是自适应增强算法可以给样本赋权重，预测错误的样本权重更高，从而可以增加、对错误的重视程度。
[0087]
应理解，关于极致梯度提升树算法、随机森林算法和自适应增强算法的相关描述可以参看现有技术。为了简洁，这里不做详述。
[0088]
还应理解，上文所列举的用于训练预测模型的机器学习算法仅为示例。例如可以通过极致梯度提升树算法、随机森林算法和自适应增强算法一种或多种，以及其他机器学习算法来训练子模型，本申请实施例对此不作限定。
[0089]
将多个子模型融合为一个加权模型，各子模型可以以最优百分比的形式来融合，权重之和为100％。比如，由极致梯度提升树算法训练得到的子模型1预测的等待时长为30分钟，占比32％；由随机森林算法训练得到的子模型2预测的等待时长为15分钟，占比46％；由自适应增强算法训练得到的子模型3预测的等待时长为20分钟，占比22％。融合模型输出则为：30
×
32％+15
×
46％+20
×
22％＝20.9分钟。通过对多种算法训练得到的子模型的融合，可以平衡各个子模型的表现，也就是平衡各种算法的特点。从而达到提升预测的稳定性、准确性和泛化能力的目的。
[0090]
上述各子模型的权重可以是预先配置的，也可以通过训练获得，比如可以通过一个线性模型训练得到。本申请实施例对此不作任何限定。
[0091]
为了提高预测模型的预测准确性，还可定期地对样本进行更新，以基于更新后的样本对预测模型进行训练。比如，每天固定时间从当天往前推算两年的历史数据作为样本，来对该预测模型进行训练。其具体的训练过程可以参考上文的描述，为了简洁，这里不再重复。
[0092]
在本申请实施例中，可以将用于训练预测模型的模块称为模型训练模块。基于不同的功能，该模型训练模块还可进一步细分为数据清洗、特征提取、多个子模型以及加权模型等多个子模块。该模型训练模块可以作为订单管理系统的一部分，也可以是独立于该订单管理系统而存在。本申请实施例对此不作任何限定。
[0093]
基于上述训练所获得的预测模型可用于对新创建的订单进行预测，以输出预测回复时长。
[0094]
模型预测阶段：
[0095]
为了获得较为准确的预测回复时长，可以先对订单进行数据校验、特征提取等操作。
[0096]
其中，数据校验具体可以是指对订单进行数据规范性校验，屏蔽不符合预测规范的实时数据。数据校验与前文所述的数据清洗是相似的。
[0097]
特征提取具体可以是指对结构化数据进行深度加工。关于特征提取的相关说明可以参看上文模型训练阶段对特征提取的相关说明，为了简洁，这里不再重复。特征提取可以保证模型训练阶段和预测极端的数据处理的逻辑相吻合，避免预测结果出现偏差。
[0098]
此后，可以加载预测模型，对特征提取得到的数据进行预测。如前文所述，本申请实施例中采用了多个子模型融合的方法来获取预测值。该特征提取数据可以被输入至该多个子模型中，该多个子模型可分别基于特征提取数据进行预测，输出的预测值此后被输入至融合模型，以获得加权后的预测值。该预测值即前文所述的预测回复时长。
[0099]
在本申请实施例中，将订单管理系统中用于获得该预测回复时长的模块称为模型预测模块。基于不同的功能，该模型预测模块还可进一步细分为数据校验、特征提取和模型预测等子模块。
[0100]
在步骤230中，基于该订单的创建时间与入住时间的时间差，以及对订单的回复的预测回复时长，确定等待时长。
[0101]
其中，等待时长具体可以是指发出催单提示前等待酒店管理系统对该订单的回复的时长。等待时长的起算时间例如可以是该订单管理系统将该订单发送至酒店管理系统的时间。若在等待时长内未接收到来自该酒店管理系统的回复，则可将该订单放入催单队列中。话务员可基于该催单队列的排序依次对其中的订单进行催单。因此，等待时长可以理解为是由该订单管理系统确定的、由发送订单至酒店管理系统至将该订单放入催单队列的时间长度的最大值。换言之，一旦等待的时间超出该等待时长，便不再继续等待。
[0102]
在本申请实施例中，预测回复时长一定的情况下，等待时长可以随订单的创建时间与入住时间的时间差的增大而增大。时间差越小，等待时长越短；时间差越大，等待时长越长。
[0103]
可以理解，订单的创建时间与入住时间的时间差越小，则表明该订单越着急；订单的创建时间与入住时间的时间差越大，则表明订单可略暂缓。例如，用户a在早晨9:00下单，希望预定当天晚上8:00入住的酒店客房，则说明该用户希望尽快入住酒店，该订单为急单。又例如，用户b在周一的晚上7:00下单，希望预定本周六晚上6:00入住的酒店客房，则说明该用户并不是特别着急要入住酒店，该订单并非急单。
[0104]
该订单管理系统可以基于订单的创建时间与入住时间的时间差，以及该订单的预测回复时长，确定等待时长。
[0105]
在一种可能的实现方式中，可以在该订单管理系统中预设门限，该预设门限可以理解为是用户能够容忍的最长回复时长，例如可以简称为容忍阈值、容忍门限等。订单管理系统可以基于预测模型输出的预测回复时长与预设门限的大小关系、订单的创建时间与入住时间的时间差，来确定等待时长。
[0106]
比如，当上述预测模型输出的预测回复时长大于该预设门限，则说明等待该订单的回复的时长已经超出了用户可以容忍的时长，需要安排催单。进一步地，可以结合订单的创建时间与入住时间的时间差来确定等待时长。若该时间差较小，则可以对该等待时长赋予较小的取值，甚至可以取值为零；若该时间差较大，则可以对该等待时长赋予较大的取值。
[0107]
又如，当上述预测模型输出的预测回复时长小于或等于该预设门限，则说明等待该订单的回复的时长还处于用户可以容忍的时长范围内，可以暂缓。当然，也可以对该订单进行催单。订单管理系统仍然可以结合订单的创建时间与入住时间的时间差来确定等待时长。若该时间差较小，则可以对该等待时长赋予较小的取值；若该时间差较大，则可以对该等待时长赋予较大的取值。
[0108]
可选地，该订单的创建时间与入住时间的时间差可以基于订单的类型、创建时间所属的时段来具体化。
[0109]
其中，订单的类型可以包括当天订单和隔天订单。当天订单是指当天创建且当天就要入住的订单；隔天订单是指当天创建但不是当天就要入住的订单。订单的类型可以订
单中根据创建订单的时间和入住时间来确定。比如，若入住时间与创建订单的时间为同一天，则为当天订单；若入住时间与创建订单的时间不为同一天，则为隔天订单。
[0110]
基于酒店工作人员一天不同的忙闲时段、班次、业务专家的经验、用户在线预订的高峰期等因素，可以将一天的24小时分为早间、午间、晚间和夜间；或者，也可以分为日间、晚间、夜间和凌晨。
[0111]
其中，早间例如可以是指07:00-11:59；午间例如可以是指12:00-17:59；晚间例如可以是指18:00-19:59；夜间例如可以是指20:00-次日6:59。
[0112]
日间例如可以是指07:00-17:59；晚间例如可以是指18:00-19:59；夜间例如可以是指20:00-23:59；凌晨例如可以是指次日00:00-6:59。
[0113]
应理解，上文所列举的不同时段以及不同时段的具体时间仅为便于理解而示例，不应对本申请构成任何限定。例如，也可将一天的24小时分为更多或更少的时段，且每个时段对应的时间也可以做出不同的定义。本申请对此不作限定。
[0114]
下表示出了基于不同的订单类型、订单创建时间所属的不同时段以及预测模型输出的预测回复时长而确定的等待时长。
[0115][0116]
由上表可以看到，对于创建于同一时段的不同类型的订单，在预测回复时长与预设时长的大小关系一致的情况下，可以分配不同的等待时长。如，当天订单的等待时长短于隔天订单的等待时长。如表中所示，在07:00-17:59时段，预测回复时长≤预设门限的情况下，当天订单的等待时长为30分钟，隔天订单的等待时长为60分钟，后者长于前者；预测回复时长＞预设门限的情况下，当天订单的等待时长为15分钟，隔天订单的等待时长为40分钟，后者长于前者。其他时段的订单的等待时长也具有如上规律，为了简洁，这里不一一列举说明。
[0117]
另外还可以看到，在00:00-6:59的时段内下单的当天订单，预测回复时长与预设时长的大小关系如何，都可以设计等待时长为0分钟，即，不等待，直接发出催单提示。这是因为考虑到，一方面用户会在下单的当天入住，用户急需预订房间；另一方面，这个时段的订单量较少，话务员可以及时处理急单。因此等待时长可以为0分钟。当然，等待时长也可以设计为较小值，比如，等待1分钟。本申请实施例对此不作限定。
[0118]
对于创建于同一时段、同一类型的订单，在预测回复时长与预设时长的大小关系不同的情况下，也可以分别分配不同的等待时长。如，预测回复时长≤预设门限的情况下，等待时长例如记为第一等待时长，可通过t1表示；预测回复时长＞预设门限的情况下，等待时长例如记为第二等待时长，可通过t2表示。其中，t1＞t2≥0。
[0119]
需要说明的是，在有些情况下，可以将t2设为0。此情况下，也可认为该等待时长仅
包括上述第一等待时长。
[0120]
还需要说明的是，上述等待时长(包括第一等待时长和第二等待时长)、预设门限都可以由人工设定。比如，可以预先输入至该订单管理系统中，订单管理系统可以基于不同的订单类型、不同的创建时间所属的时段以及预设时长与预设门限的大小关系，选择不同的等待时长。
[0121]
此外，上述等待时长、预设门限等都可以调整。比如，在酒店管理系统的回复时长普遍缩短后，可以减小等待时长和/或预设门限的取值。又比如，在催单率较高的情况下，可以增大等待时长和/或预设门限的取值。诸如此类，这里不一一举例说明。
[0122]
在本申请实施例中，将订单管理系统中用于确定等待时长的模块称为决策模块。
[0123]
在步骤240中，确定在等待时长内是否接收到对该订单的回复。
[0124]
所述对订单的回复，也就是来自酒店管理系统的针对该订单的回复。订单管理系统可以自发送订单起开始计时，比如在本地设置一个计时器，该计时器的计时长度可以为由步骤230所确定的等待时长。若计时器超时，还未收到回复，则可执行步骤250，发出催单提示。若收到回复，则可执行步骤260，根据来自酒店管理系统的回复，确认房态。
[0125]
在步骤250中，催单提示例如可以是在该订单管理系统的界面上弹出对话框，提示话务员对某一订单进行电话催单，也可以是通过声音信号来提示话务员对某一订单进行电话催单。本申请实施例对于该订单管理系统发出催单提示的具体方式不作限定。
[0126]
在本申请实施例中，订单管理系统中的决策模块还可用于确定是否发出催单提示，并在需要发出催单提示的情况下，发出催单提示。
[0127]
话务员可以基于催单提示，针对该订单进行电话催单。并在催单后，继续等到酒店管理系统的回复。并可在接收到回复后，执行步骤260，根据来自酒店管理系统的回复，确认房态。
[0128]
可以理解，订单管理系统在步骤260中接收到的回复，可能是未经过话务员的催单而接收到的回复，也可能是经过话务员的催单而接收到的回复。本申请实施例对此不作任何限定。
[0129]
此后，订单管理系统可以根据所确认的房态，将预订结果发送至客户端，以通知用户该订单是否预订成功。
[0130]
为了更好地理解本申请实施例，下面结合该订单管理系统的示意图对上述流程做简单说明。用户通过客户端在线预定酒店后，订单模块可基于来自客户端的预订创建订单。订单模块创建的订单一方面可以被发送至模型预测模块，用于预测对订单的回复时长；另一方面被保存在本地，用于周期性地对预测模型进行训练和更新。
[0131]
订单模块可以每天定时将历史数据发送至模型训练模块。模型训练模块通过数据清洗、特征提取等操作后，将经特征提取得到的数据输入至多个子模型，例如图中所示的子模型1、子模型2直至子模型n。该n个子模型的输出可以进一步输入至加权模型，以得到预测模型。
[0132]
基于每一个新创建的订单，订单模块可以将其发送至模型预测模块。模型预测模块通过数据校验、特征提取等操作后，将特征提取数据输入至预测模型，以预测从向酒店管理系统发送订单到接收到酒店管理系统对该订单的回复所经历的时长(即，图中所示的预测回复时长)。基于预测模型输出的预测回复时长，决策模块可以基于订单类型、订单的创
建时间所属的时段以及预测回复时长与预设门限的大小关系，确定等待时长，以便于后续作出决策，是否需要将该订单放入催单队列。
[0133]
另一方面，预测回复时长、实际回复时长可以被输入至订单模块，与该订单相对应。该订单与其对应的预测回复时长、实际回复时长还可以作为历史数据，以对训练样本进行更新。此后，可以基于更新后的样本对预测模型进行训练。
[0134]
应理解，由于上述各个步骤在上文方法200中已经做了详细说明，为了简洁，这里不再赘述。
[0135]
基于上述技术方案，对不同类型、创建于不同的时间的订单，依据不同的预测回复时长，设计了不同的等待时长。对于那些预测回复时长已经超出用户能够容忍的时长范围，且较着急的订单，优先权可以排在首位。对于预测回复时长已经超出用户能够容忍的时长范围，而并不是特别着急的订单，优先权可以排在第二。对于那些预测回复时长在用户能够容忍的时长范围内，但比较着急的订单，优先权可以排在第三。对于那些预测回复时长在用户能够容忍的时长范围内，且不是特别着急的订单，优先权可以放到最后。订单管理系统可以按照优先权依次递减的顺序，将对应的订单依次放入催单队列，等待话务员的处理。因此可以将最需要催单的订单排在前面，不需要催单的订单排在后面。从而对有限的人力资源作出合理地安排，且订单的处理效率也能得到提升。并且，在这段等待的时间里，有可能就已经有部分订单接收到来自酒店管理系统的回复，从而也就免去了后续的催单工作，减小了话务员的工作量。
[0136]
为了实现上述方法实施例中的各功能，作为执行主体的订单管理系统可以包括硬件结构和/或软件模块，以硬件结构、软件模块、或硬件结构加软件模块的形式来实现上述各功能。上述各功能中的某个功能以硬件结构、软件模块、还是硬件结构加软件模块的方式来执行，取决于技术方案的特定应用和设计约束条件。
[0137]
图3是本申请实施例提供的订单管理系统300的示意性框图。如图3所示，该系统300包括订单模块、模型训练模块、模型预测模块和决策模块。其中，模型训练模块可进一步包括数据清洗、特征提取、子模型1、子模型2至子模型n以及加权模型等子模块；模型预测模块可进一步包括数据校验、特征提取、模型预测等子模块。各模块执行的功能在上文方法实施例中已经做了详细说明，为了简洁，这里不再重复。
[0138]
图4是本申请实施例提供的订单管理系统400的另一示意性框图。如图4所示，该系统400可以包括：通信单元410和管理单元420。其中，通信单元410可用于向酒店管理系统发送订单，所述订单用于向所述酒店管理系统请求预订酒店，所述订单包括入住时间；管理单元420可用于基于所述订单的创建时间与所述入住时间的时间差，以及所述订单的预测回复时长，确定等待时长，所述预测回复时长是从发送所述订单到接收到对所述订单的回复所经历的时长的预测值，所述等待时长是在发出催单提示前等待所述回复的时长；并用于在所述等待时长内未接收到对所述订单的回复的情况下，发出所述催单提示。
[0139]
应理解，图4所示的订单管理系统400可对应于前文结合图2所示的方法实施例中的订单管理系统，并执行订单管理系统执行的方法。订单管理系统400的具体工作方式及原理可参照前文结合图2所示的方法实施例的相关描述，为了简洁，这里不在赘述。
[0140]
还应理解，图4所示的订单管理系统400也可对应于图3所示的订单管理系统。其中，通信单元410中的部分功能可以由订单模块来实现，比如，向酒店管理系统发送订单；管
理单元420中的功能可以由模型训练模块、模型预测模块和决策模块来实现，比如，训练预测模型，预测订单的预测回复时长，确定等待时长，以及是否发出催单提示等。各单元或模块的具体工作方式及原理可参照前文结合图2所示的方法实施例的相关描述，为了简洁，这里不在赘述。
[0141]
应理解，订单管理系统可以包括但不限于上文所列举的多个模块或单元。上文结合图3和图4示出的各模块或单元仅为便于理解而示出，不应对本申请实施例构成任何限定。
[0142]
图3或图4所示的订单管理系统可以部署在计算设备上。比如，部署在服务器上。图5是本申请实施例提供的计算设备500的示意性框图。如图5所示，该计算设备500可以包括：处理器510、通信接口520和存储器530。其中，处理器510、通信接口520和存储器530通过内部连接通路互相通信，该存储器530用于存储指令，该处理器510用于执行该存储器530存储的指令，以控制该通信接口520发送信号和/或接收信号。
[0143]
应理解，该计算设备500可部署有上述方法实施例中的订单管理系统，并且可以用于执行上述方法实施例中订单管理系统执行的各个步骤和/或流程。可选地，该存储器530可以包括只读存储器和随机存取存储器，并向处理器提供指令和数据。存储器的一部分还可以包括非易失性随机存取存储器。存储器530可以是一个单独的器件，也可以集成在处理器510中。该处理器510可以用于执行存储器530中存储的指令，并且当该处理器510执行存储器中存储的指令时，该处理器510用于执行上述方法实施例的各个步骤和/或流程。
[0144]
可选地，通信接口520也可以是输入/输出接口、电路等。该通信接口520与处理器510和存储器530都可以集成在同一个芯片中，也可以集成在不同的芯片中。本申请对此不作限定。
[0145]
在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。为避免重复，这里不再详细描述。
[0146]
上述各个实施例中的处理器可以是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法实施例的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。
[0147]
应理解，上述处理器可以是通用处理器、数字信号处理器(digital signal processor，dsp)、专用集成电路(application specific integrated circuit，asic)、现成可编程门阵列(field programmable gate array，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存取存储器(random access memory，ram)、闪存、只读存储器(read-only memory，rom)、可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存
储器，处理器读取存储器中的指令，结合其硬件完成上述方法的步骤。
[0148]
根据本申请实施例提供的方法，本申请还提供一种计算机程序产品，所述计算机程序产品包括：计算机程序(也可以称为代码，或指令)，当所述计算机程序被运行时，使得计算机执行上述实施例中订单管理系统执行的方法，其实现原理以及有益效果与上文方法实施例所述的实现原理及有益效果类似，此处不再进行赘述。
[0149]
根据本申请实施例提供的方法，本申请还提供一种计算机可读存储介质，该计算机可读存储介质存储有程序代码，当该程序代码在计算机上运行时，使得该计算机执行上述实施例中订单管理系统执行的方法，其实现原理以及有益效果与上文方法实施例所述的实现原理及有益效果类似，此处不再进行赘述。
[0150]
根据本申请实施例提供的方法，本申请还提供一种芯片，芯片上存储有计算机程序，在计算机程序被处理器执行时，执行上述任一实施例所述的订单管理方法，其实现原理以及有益效果与订单管理方法的实现原理及有益效果类似，此处不再进行赘述。
[0151]
在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，比如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式；又如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
[0152]
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
[0153]
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
[0154]
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read-only memory，rom)、随机存取存储器(random access memory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。
[0155]
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。