CN105719173A - 订单处理方法和订单处理设备 - Google Patents

Abstract

本公开的实施例涉及订单处理方法和订单处理设备。该订单处理方法包括：接收订单；至少部分地基于用户偏好，为所述订单确定至少一个用户；以及将所述订单发送给所述至少一个用户。本公开的实施例所提供的订单处理方法通过考虑用户偏好，可以提高订单处理效率，改善用户满意度。

Description

订单处理方法和订单处理设备

技术领域

本公开的实施例总体上涉及计算机应用领域，并且更具体地涉及订单处理方法和订单处理设备。

背景技术

随着电子信息的发展，基于移动互联网的订单服务得到了广泛地使用。以打车为例，乘客通过打车应用发起叫车请求，然后系统生成叫车订单，并且根据周边车辆情况将订单发送给司机客户端，司机客户端通过点击确认按钮等方式来接受乘客的订单。

仍然以打车为例，现有的订单处理方法主要包括抢单和指派两种方法。但是，在这些方法中，存在一个严重的问题，也就是司机自身的用户偏好(例如，接单意愿)没有被考虑在内，从而司机本身满意度不够高，并且可能导致订单处理效率低下。

因此，如何提高用户(对于打车而言，例如，司机)的满意度，进一步改善订单处理效率，成为一种亟需解决的问题。

发明内容

针对上述问题，本公开的实施例提供了一种订单处理方法与订单处理设备。

本公开的一个方面提供了一种订单处理方法。该方法包括：接收订单；至少部分地基于用户偏好，为所述订单确定至少一个用户；以及将所述订单发送给所述至少一个用户。

在一些实施例中，至少部分地基于用户偏好，为所述订单确定至少一个用户包括：从潜在用户获取其相应的用户偏好，所述用户偏好至少包括目的地信息；以及根据所述目的地信息与所述订单的目的地，为所述订单确定至少一个用户。

在一些实施例中，根据所述目的地信息与所述订单的目的地，为所述订单确定至少一个用户包括：在所述目的地信息与所述订单的目的地一致时，为所述订单确定至少一个用户。

在一些实施例中，至少部分地基于用户偏好，为所述订单确定至少一个用户包括：基于历史订单信息，确定每个潜在用户的用户偏好，以为所述订单确定至少一个用户。

在一些实施例中，基于历史订单信息，确定每个潜在用户的用户偏好包括：对所述历史订单信息中的信息元素分配权重；针对信息元素，确定每个潜在用户的优先级；以及针对每个潜在用户，根据所分配的权重对所述优先级进行求和，以确定每个潜在用户的用户偏好。

本公开的另一方面提供了一种订单处理设备。该设备包括：接收装置，被配置成接收订单；确定装置，被配置成至少部分地基于用户偏好，为所述订单确定至少一个用户；以及发送装置，被配置成将所述订单发送给所述至少一个用户。

在一些实施例中，所述确定装置包括：获取模块，被配置成从潜在用户获取其相应的用户偏好，所述用户偏好至少包括目的地信息；以及确定模块，被配置成根据所述目的地信息与所述订单的目的地，为所述订单确定至少一个用户。

在一些实施例中，所述确定模块被进一步配置成：在所述目的地信息与所述订单的目的地一致时，为所述订单确定至少一个用户。

在一些实施例中，所述确定装置包括：历史订单处理模块，被配置成基于历史订单信息，确定每个潜在用户的用户偏好，以为所述订单确定至少一个用户。

在一些实施例中，所述历史订单处理模块被进一步配置成：对所述历史订单信息中的信息元素分配权重；针对信息元素，确定每个潜在用户的优先级；以及针对每个潜在用户，根据所分配的权重对所述优先级进行求和，以确定每个潜在用户的用户偏好。

本公开的又一方面提供了一种订单处理设备。该设备包括：处理器，所述处理器被配置成执行根据本公开的第一方面所述的方法。

本公开的示例性实施例提供的示例性解决方案通过考虑用户偏好，可以提高订单处理效率，改善用户满意度。

附图说明

结合附图并参考以下详细说明，本公开的各实施例的特征、优点及其他方面将变得更加明显，在此以示例性而非限制性的方式示出了本公开的若干实施例。在附图中：

图1是图示根据本公开的实施例的订单处理环境的示意图；

图2是图示根据本公开的实施例的订单处理方法的流程图；以及

图3是图示根据本公开的实施例的订单处理设备的框图。

具体实施方式

以下参考附图详细描述本公开的各个示例性实施例。附图中的流程图和框图示出了根据本公开的各种实施例的方法和系统的可能实现的体系架构、功能和操作。应当注意，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，所述模块、程序段、或代码的一部分可以包括一个或多个用于实现各个实施例中所规定的逻辑功能的可执行指令。也应当注意，在有些作为备选的实现中，方框中所标注的功能也可以按照不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，或者它们有时也可以按照相反的顺序执行，这取决于所涉及的功能。同样应当注意的是，流程图和/或框图中的每个方框、以及流程图和/或框图中的方框的组合，可以使用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以使用专用硬件与计算机指令的组合来实现。

应当理解，给出这些示例性实施例仅是为了使本领域技术人员能够更好地理解进而实现本公开的实施例，而并非以任何方式限制发明的范围。

参考图1，其图示了根据本公开的实施例的订单处理环境100的示意图。下面为了简单起见，结合专业应用说明该订单处理环境100。如图1所示，乘客使用移动设备101-105生成订单，移动设备可以指代各种拥有网络接入功能、搭载各种操作系统(包括但不限于iOS、Android、WindowsPhone等)、可根据用户需求定制各种功能的终端设备，包括但不限于智能手机、平板电脑、智能可穿戴设备等。此外，在移动设备101-105中可以安装有相关的叫车应用，从而订单可以由乘客使用移动设备101-105中的叫车应用而生成。

类似地，司机使用移动设备111-115来接收订单，在这些移动设备中可以安装有相关的接单应用，从而可以通过接单应用接收订单并且通过按键、语音等方式接受订单。在一些情况下，由乘客使用的叫车应用和由司机使用的接单应用可以由一个单独的应用来实施。

此外，订单处理环境100还可以包括服务器120。服务器120可以从乘客所使用的移动设备101-105等接收订单，并且筛选出一些订单，以发送给移动设备111-115等，从而向司机分配订单或者使司机抢单。当司机接受订单或者抢单之后，向服务器120发送确认消息。然后服务器120可以向乘客使用的移动设备101-105发送订单已被某个司机接受的消息。在抢单的情况下，服务器120还可以通过计算确定对于该订单最优的司机，并且向乘客使用的移动设备发送订单已经由这个最优司机接受的消息。

在一些实施例中，服务器120在筛选向司机发送的订单时可以进一步考虑司机的用户偏好。司机的用户偏好可以从司机所使用的移动设备收集或者根据历史订单信息确定。

应当注意，虽然图1结合打车应用示意性地说明了根据本公开的实施例的订单处理环境100，但是本公开的实施例不限于这样的实施环境，并且可以应用于其他应用环境，例如餐饮、购物等。

参考图2，其图示了根据本公开的实施例的为用户确定订单的方法200的流程图。

在步骤201，接收订单。以打车应用为例，这些订单例如由图1中所示的乘客使用的移动设备101-105所生成。

然后，在步骤202，至少部分地根据用户偏好，为订单确定至少一个用户。例如，在打车应用中，服务器可以根据司机(即，订单的用户)的用户偏好，为订单确定一个司机，这种方法通常被称为指派方法。反之，也可以为订单确定多个司机，由多个司机进行抢单，这种方法通常被称为抢单方法。

在一些实施例中，从潜在用户获取其相应的用户偏好，这些用户偏好至少包括目的地信息，并且根据目的地信息与订单的目的地之间的关系，为订单确定至少一个用户。在一个示例中，“潜在用户”可以包括任何活跃的用户，即任何准备接收订单的用户都可以被视为潜在用户。在一个示例中，“潜在用户”也可以仅包括通过常规订单处理方法进行筛选而获得的用户。以打车应用为例，“潜在用户”可以包括任何准备接单的司机，也可以仅仅包括通过常规订单处理方法筛选而获得的司机，等等。如在背景技术中所介绍的，常规订单处理方法通常不考虑用户(例如，司机)的偏好。

仍然以打车应用为例，例如，可以使潜在用户在移动终端上输入目的地信息或使用定位技术挖掘用户偏好目的地信息，这些目的地信息可以是地理名称(例如，上地)，或者地图上的一个坐标(例如，经纬度)，或者一定的范围(例如，回龙观附近2公里)等等。例如，也可以设置一些常用目的地信息，从而便于快捷选择。在一些实施例中，当所偏好的目的地信息与订单的目的地一致时，为订单确定至少一个用户。例如，如果从一些用户获得的目的地信息为上地，而订单的目的地也是上地，则可以为这些订单确定这些用户。在一些实施例中，所偏好的目的地信息也可以与订单的目的地不一致。例如，如果订单的目的地为A，用户所偏好的目的地信息为B，A与B不一致，但是A地点去往B地点的订单较多、较集中，则也可以为这些订单确定目的地信息为B的用户。从而，用户在完成这些订单之后，更容易接收到去往地点B的订单。例如，哪些路线的订单比较集中可以通过大数据分析进行获得。

在一些实施例中，基于历史订单信息，确定每个潜在用户的用户偏好，以为所述订单确定至少一个用户。例如，从历史订单信息中提取潜在用户的用户偏好，从而根据潜在用户的用户偏好，确定至少一个用户。以打车应用为例，历史订单信息可以包括用户所接收的历史订单的出发地、目的地以及订单的时间、金额等信息。这些信息通常可以反映出用户偏好。

在一些实施例中，为了对用户偏好进行量化表达，进而进行进一步处理，通过加权和模型对历史订单信息进行处理，从而提取出用户偏好。

具体而言，首先，对历史订单信息中的信息元素分配权重。以打车应用为例，这些信息元素可以包括但不限于出发地、目的地、时长、金额等。

然后，针对信息元素，确定每个潜在用户的优先级。优先级可以通过评分的方式来实现，例如，优先级越高评分越高。以打车应用为例，如果考虑订单金额这个信息元素，则如果司机A的历史订单信息中的订单金额与所考虑的订单的订单金额很接近，则可以给予该司机较高的优先级，例如，较高的评分。换言之，如果相差很远，则给予该司机较低的优先级，例如，较低的评分。这些评分可以进行归一化，例如以100％为最高评分。

最后，针对每个潜在用户根据所分配的权重对这些优先级进行求和，以确定每个潜在用户的用户偏好。例如，基于评分的加权和方法的数学表达式为：最终评分＝w1*v1+…+wm*vm，其中vi(i＝1…m)表示某个信息元素的归一化评分，wm(i＝1…m)表示该信息元素的权重。在确定了最终评分之后，可以确定这些评分高于预定阈值的用户，从而向这些用户发送订单。

在一些实施例中，还可以考虑与常规订单处理方法进行组合。例如，如果根据上述方法确定的多个司机的目的地相同，则可以根据常规订单处理方法进一步确定一个或者多个司机。常规订单处理方法可以例如根据司机与乘客之间的距离大小来确定一个或者多个司机。作为另一示例，可以先对订单通过常规订单处理方法进行处理，为该订单确定一个或多个司机，然后考虑所确定的一个或者司机的用户偏好，从而进一步筛选出更加优选的一个或者多个司机。

在步骤203，将订单发送给所确定的至少一个用户。以打车应用为例，作为订单的用户的司机在接收到订单之后，可以接单或者抢单，从而与乘客达成交易。

图3是根据本公开的实施例的订单处理设备300的框图。该设备300包括：接收装置301，被配置成接收订单；确定装置302，被配置成至少部分地基于用户偏好，为所述订单确定至少一个用户；以及发送装置303，被配置成将所述订单发送给所述至少一个用户。

在一些实施例中，确定装置302包括：获取模块，被配置成从潜在用户获取其相应的用户偏好，所述用户偏好至少包括目的地信息；以及确定模块，被配置成根据所述目的地信息与所述订单的目的地，为所述订单确定至少一个用户。

在一些实施例中，所述确定模块被进一步配置成：在所述目的地信息与所述订单的目的地一致时，为所述订单确定至少一个用户。

在一些实施例中，确定装置302包括：历史订单处理模块，被配置成基于历史订单信息，确定每个潜在用户的用户偏好，以为所述订单确定至少一个用户。

在一些实施例中，所述历史订单处理模块被进一步配置成：对所述历史订单信息中的信息元素分配权重；针对信息元素，确定每个潜在用户的优先级；以及针对每个潜在用户，根据所分配的权重对所述优先级进行求和，以确定每个潜在用户的用户偏好。

根据本公开的又一方面，提供了一种订单处理设备，包括：处理器，所述处理器被配置成：接收订单；至少部分地基于用户偏好，为所述订单确定至少一个用户；以及将所述订单发送给所述至少一个用户。

应当理解，以上订单处理设备可以利用各种方式来实现。例如，在某些实施例中，以上订单处理设备可以通过硬件、软件或者软件和硬件的结合来实现。其中，硬件部分可以利用专用逻辑来实现；软件部分则可以存储在存储器中，由适当的指令执行系统，例如微处理器或者专用设计硬件来执行。本领域的普通技术人员可以理解上述的方法和系统可以使用计算机可执行指令和/或包含在处理器控制代码中来实现，例如在诸如磁盘、CD或DVD-ROM的载体介质、诸如只读存储器(固件)的可编程的存储器或者诸如光学或电子信号载体的数据载体上提供了这样的代码。本公开的实施例的设备和装置不仅可以由诸如超大规模集成电路或门阵列、诸如逻辑芯片、晶体管等的半导体、或者诸如现场可编程门阵列、可编程逻辑设备等的可编程硬件设备的硬件电路实现，也可以用例如由各种类型的处理器所执行的软件实现，还可以由上述硬件电路和软件的结合(例如固件)来实现。

应当注意，尽管在上文的详细描述中提及了设备的若干装置或子装置，但是这种划分仅仅是示例性而非强制性的。实际上，根据本公开的实施例，上文描述的两个或更多装置的特征和功能可以在一个装置中具体化。反之，上文描述的一个装置的特征和功能可以进一步划分为由多个装置来具体化。

以上所述仅为本公开的实施例可选实施例，并不用于限制本公开的实施例，对于本领域的技术人员来说，本公开的实施例可以有各种更改和变化。凡在本公开的实施例的精神和原则之内，所作的任何修改、等效替换、改进等，均应包含在本公开的实施例的保护范围之内。

虽然已经参考若干具体实施例描述了本公开的实施例，但是应该理解，本公开的实施例并不限于所公开的具体实施例。本公开的实施例旨在涵盖在所附权利要求的精神和范围内所包括的各种修改和等同布置。所附权利要求的范围符合最宽泛的解释，从而包含所有这样的修改及等同结构和功能。

Claims (10)

1.一种订单处理方法，包括：

接收订单；

至少部分地基于用户偏好，为所述订单确定至少一个用户；以及

将所述订单发送给所述至少一个用户。

2.根据权利要求1所述的方法，其中至少部分地基于用户偏好，为所述订单确定至少一个用户包括：

从潜在用户获取其相应的用户偏好，所述用户偏好至少包括目的地信息；以及

根据所述目的地信息与所述订单的目的地，为所述订单确定至少一个用户。

3.根据权利要求2所述的方法，其中根据所述目的地信息与所述订单的目的地，为所述订单确定至少一个用户包括：

在所述目的地信息与所述订单的目的地一致时，为所述订单确定至少一个用户。

4.根据权利要求1所述的方法，其中至少部分地基于用户偏好，为所述订单确定至少一个用户包括：

基于历史订单信息，确定每个潜在用户的用户偏好，以为所述订单确定至少一个用户。

5.根据权利要求4所述的方法，其中基于历史订单信息，确定每个潜在用户的用户偏好包括：

对所述历史订单信息中的信息元素分配权重；

针对所述信息元素，确定每个潜在用户的优先级；以及

针对每个潜在用户，根据所分配的权重对所述优先级进行求和，以确定每个潜在用户的用户偏好。

6.一种订单处理设备，包括：

接收装置，被配置成接收订单；

确定装置，被配置成至少部分地基于用户偏好，为所述订单确定至少一个用户；以及

发送装置，被配置成将所述订单发送给所述至少一个用户。

7.根据权利要求6所述的设备，其中所述确定装置包括：

获取模块，被配置成从潜在用户获取其相应的用户偏好，所述用户偏好至少包括目的地信息；以及

确定模块，被配置成根据所述目的地信息与所述订单的目的地，为所述订单确定至少一个用户。

8.根据权利要求7所述的设备，其中所述确定模块被进一步配置成：

在所述目的地信息与所述订单的目的地一致时，为所述订单确定至少一个用户。

9.根据权利要求6所述的设备，其中所述确定装置包括：

历史订单处理模块，被配置成基于历史订单信息，确定每个潜在用户的用户偏好，以为所述订单确定至少一个用户。

10.根据权利要求9所述的设备，其中所述历史订单处理模块被进一步配置成：

对所述历史订单信息中的信息元素分配权重；

针对所述信息元素，确定每个潜在用户的优先级；以及

针对每个潜在用户，根据所分配的权重对所述优先级进行求和，以确定每个潜在用户的用户偏好。