CN111612286B - 一种订单分配方法、装置、电子设备及存储介质 - Google Patents
一种订单分配方法、装置、电子设备及存储介质 Download PDFInfo
- Publication number
- CN111612286B CN111612286B CN201910138870.8A CN201910138870A CN111612286B CN 111612286 B CN111612286 B CN 111612286B CN 201910138870 A CN201910138870 A CN 201910138870A CN 111612286 B CN111612286 B CN 111612286B
- Authority
- CN
- China
- Prior art keywords
- area
- travel
- service
- service request
- order
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
- G06Q10/063—Operations research, analysis or management
- G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
- G06Q10/06311—Scheduling, planning or task assignment for a person or group
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
- G06Q10/063—Operations research, analysis or management
- G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
- G06Q10/06311—Scheduling, planning or task assignment for a person or group
- G06Q10/063114—Status monitoring or status determination for a person or group
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
- G06Q30/0645—Rental transactions; Leasing transactions
Landscapes
- Business, Economics & Management (AREA)
- Human Resources & Organizations (AREA)
- Engineering & Computer Science (AREA)
- Strategic Management (AREA)
- Economics (AREA)
- Entrepreneurship & Innovation (AREA)
- Marketing (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Development Economics (AREA)
- Theoretical Computer Science (AREA)
- Accounting & Taxation (AREA)
- Educational Administration (AREA)
- Finance (AREA)
- Game Theory and Decision Science (AREA)
- Operations Research (AREA)
- Quality & Reliability (AREA)
- Tourism & Hospitality (AREA)
- Traffic Control Systems (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
本申请涉及计算机技术领域,尤其涉及一种订单分配方法、装置、电子设备及存储介质,其中,该方法包括:接收服务请求端的出行信息,根据所述出行信息生成出行订单,其中,所述出行信息包括所述服务请求端的出发地信息与目的地信息;查找最近一次接的出行订单为从所述服务请求端的目的地所处的第一区域到达所述服务请求端的出发地所处的第二区域的至少一个目标候选服务提供端;根据查找到的所述至少一个目标候选服务提供端,为所述出行订单选择接单的服务提供端。采用上述方案,实现了订单的有效分配,提升了服务效率和服务提供方的接单体验。
Description
技术领域
本申请涉及计算机技术领域,具体而言,涉及一种订单分配方法、装置、电子设备及存储介质。
背景技术
随着互联网技术的快速发展,打车软件的普及给人们的出行带来了极大的便利。当乘客需要打车时,乘客可以通过打车软件的客户端选择用车时间、希望乘坐的车型、上车地点以及下车地点等出行信息,将出行信息提交给后台服务器,这样,在后台服务器便形成一个订单,可以将该订单发布给在后台服务器注册的司机的客户端,司机在客户端进行接单操作。
为了更好的服务乘客,打车软件为乘客提供了多种出行方式,比如:出租车、专车、快车和顺风车等出行方式。然而,不管是上述哪一种出行方式对于订单的分配均存在一定的挑战。相关技术中通常采用距离最近的方式为司机进行订单分配,然而,有些司机可能并不希望承接距离较近的订单,从而可能导致订单被取消,服务效率较低。
发明内容
有鉴于此,本申请实施例的目的在于提供一种订单分配方法、装置、电子设备及存储介质,实现了订单的有效分配,提升了服务效率和司机的接单体验。
主要包括以下几个方面:
第一方面,本申请实施例提供了一种订单分配方法,包括:
接收服务请求端的出行信息,根据所述出行信息生成出行订单,其中,所述出行信息包括所述服务请求端的出发地信息与目的地信息;
查找最近一次接的出行订单为从所述服务请求端的目的地所处的第一区域到达所述服务请求端的出发地所处的第二区域的至少一个目标候选服务提供端;
根据查找到的所述至少一个目标候选服务提供端,为所述出行订单选择接单的服务提供端。
在一种实施方式中,在查找最近一次接的出行订单为从所述服务请求端的目的地所处的第一区域到达所述服务请求端的出发地所处的第二区域的至少一个目标候选服务提供端之前,还包括:
根据所述服务请求端的出发地信息,确定参考候选服务提供端;
确定所述第一区域是否为所述参考候选服务提供端的偏好出行区域;
查找最近一次接的出行订单为从所述服务请求端的目的地所处的第一区域到达所述服务请求端的出发地所处的第二区域的至少一个目标候选服务提供端,包括:
在确定所述第一区域为所述参考候选服务提供端的偏好出行区域,且确定该参考候选服务提供端最近一次接的出行订单为从所述服务请求端的目的地所处的第一区域到达所述服务请求端的出发地所处的第二区域时,将该参考候选服务提供端作为查找到的目标候选服务提供端。
在一些实施例中,根据所述服务请求端的出发地信息,确定参考候选服务提供端,包括:
根据所述服务请求端的出发地信息,确定与所述服务请求端之间的距离小于设定阈值的区域范围;
将当前在确定的区域范围内的服务提供端作为参考候选服务提供端。
在另一种实施方式中,在确定所述第一区域是否为所述参考候选服务提供端的偏好出行区域之前,还包括:
获取所述参考候选服务提供端预先设置的偏好出行区域;
判断所述预先设置的偏好出行区域是否包含所述第一区域;
确定所述第一区域是否为所述参考候选服务提供端的偏好出行区域,包括:
若判断出所述预先设置的偏好出行区域包含所述第一区域,则确定所述第一区域为所述参考候选服务提供端的偏好出行区域。
在又一种实施方式中,在确定所述第一区域是否为所述参考候选服务提供端的偏好出行区域之前,还包括:
确定所述参考候选服务提供端在所述第一区域服务过的订单数量是否高于设定阈值;
确定所述第一区域是否为所述参考候选服务提供端的偏好出行区域,包括:
若确定所述订单数量高于所述设定阈值,则确定所述第一区域为所述参考候选服务提供端的偏好出行区域。
在再一种实施方式中,所述查找最近一次接的出行订单为从所述服务请求端的目的地所处的第一区域到达所述服务请求端的出发地所处的第二区域的至少一个目标候选服务提供端,包括:
确定所述服务请求端对上车时间的需求;
若所述服务请求端对上车时间没有实时性需求,则根据所述服务请求端的预约上车时间,从最近一次接的正在服务的出行订单为从所述第一区域到达所述第二区域的第一候选服务提供端、以及当前处于空闲状态且最近一次接的已完成服务的出行订单为从所述第一区域到达所述第二区域的第二候选服务提供端中,选择预估接驾时间符合所述预约上车时间的服务提供端作为目标候选服务提供端。
在一些实施例中,根据以下步骤确定所述服务请求端对上车时间的需求:
向所述服务请求端发送选择预约方式下单的提示信息;
根据所述服务请求端针对所述提示信息的反馈信息,确定所述服务请求端对上车时间的需求。
在一些实施例中,所述提示信息中携带有预约方式下单优惠信息和预约时间选项。
第二方面,本申请实施例还提供了一种订单分配装置,包括:
订单生成模块,用于接收服务请求端的出行信息,根据所述出行信息生成出行订单,其中,所述出行信息包括所述服务请求端的出发地信息与目的地信息;
提供端查找模块,用于查找最近一次接的出行订单为从所述服务请求端的目的地所处的第一区域到达所述服务请求端的出发地所处的第二区域的至少一个目标候选服务提供端;
订单分配模块,用于根据查找到的所述至少一个目标候选服务提供端,为所述出行订单选择接单的服务提供端。
在一种实施方式中,还包括:
提供端确定模块,用于根据所述服务请求端的出发地信息,确定参考候选服务提供端;
偏好确定模块,用于确定所述第一区域是否为所述参考候选服务提供端的偏好出行区域;
所述提供端查找模块,具体用于:
在确定所述第一区域为所述参考候选服务提供端的偏好出行区域,且确定该参考候选服务提供端最近一次接的出行订单为从所述服务请求端的目的地所处的第一区域到达所述服务请求端的出发地所处的第二区域时,将该参考候选服务提供端作为查找到的目标候选服务提供端。
在一些实施例中,所述提供端确定模块,具体用于:
根据所述服务请求端的出发地信息,确定与所述服务请求端之间的距离小于设定阈值的区域范围;
将当前在确定的区域范围内的服务提供端作为参考候选服务提供端。
在另一种实施方式中,还包括:
区域判断模块,用于获取所述参考候选服务提供端预先设置的偏好出行区域;判断所述预先设置的偏好出行区域是否包含所述第一区域;
所述偏好确定模块,具体用于:
若判断出所述预先设置的偏好出行区域包含述第一区域,则确定所述第一区域为所述参考候选服务提供端的偏好出行区域。
在又一种实施方式中,还包括:
区域确定模块,用于确定所述参考候选服务提供端在所述第一区域服务过的订单数量是否高于设定阈值;
所述偏好确定模块,具体用于:
若确定所述订单数量高于所述设定阈值,则确定所述第一区域为所述参考候选服务提供端的偏好出行区域。
在再一种实施方式中,所述提供端查找模块,具体用于:
确定所述服务请求端对上车时间的需求;
若所述服务请求端对上车时间没有实时性需求,则根据所述服务请求端的预约上车时间,从最近一次接的正在服务的出行订单为从所述第一区域到达所述第二区域的第一候选服务提供端、以及当前处于空闲状态且最近一次接的已完成服务的出行订单为从所述第一区域到达所述第二区域的第二候选服务提供端中,选择预估接驾时间符合所述预约上车时间的服务提供端作为目标候选服务提供端。
在一些实施例中,所述提供端查找模块,具体用于:
向所述服务请求端发送选择预约方式下单的提示信息;
根据所述服务请求端针对所述提示信息的反馈信息,确定所述服务请求端对上车时间的需求。
在一些实施例中,所述提示信息中携带有预约方式下单优惠信息和预约时间选项。
第三方面,本申请实施例还提供了一种电子设备,包括:处理器、存储器和总线,所述存储器存储有所述处理器可执行的机器可读指令,当电子设备运行时,所述处理器与所述存储器之间通过总线通信,所述机器可读指令被所述处理器执行时执行如第一方面所述的订单分配方法的步骤。
第四方面,本申请实施例还提供了一种计算机可读存储介质,该计算机可读存储介质上存储有计算机程序,该计算机程序被处理器运行时执行如第一方面所述的订单分配方法的步骤。
采用上述方案,首先接收服务请求端的出行信息,根据所述出行信息生成出行订单,然后查找最近一次接的出行订单为从所述服务请求端的目的地所处的第一区域到达所述服务请求端的出发地所处的第二区域的至少一个目标候选服务提供端,最后根据查找到的所述至少一个目标候选服务提供端,为所述出行订单选择接单的服务提供端。这样,针对服务请求端的出行订单,通过查找最近一次接的出行订单为第一区域到第二区域的目标候选服务提供端,为上述出行订单选择接单的服务提供端,从而实现了订单的有效分配,提升了服务效率和服务提供方的接单体验。
进一步的,在确定服务请求端的目的地所处的第一区域为参考候选服务提供端的偏好出行区域时,可以将参考候选服务提供端确定为目标候选服务提供端,这主要是考虑到对于服务提供方而言,往往有一个比较熟悉和偏好的接单范围,在确定了服务提供端的偏好出行区域后,便可以在偏好出行区域进行接单,从而进一步提升了服务效率和服务提供方的接单体验。
为使本申请的上述目的、特征和优点能更明显易懂,下文特举较佳实施例,并配合所附附图,作详细说明如下。
附图说明
为了更清楚地说明本申请实施例的技术方案,下面将对实施例中所需要使用的附图作简单地介绍,应当理解,以下附图仅示出了本申请的某些实施例,因此不应被看作是对范围的限定,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他相关的附图。
图1示出了本申请一些实施例提供的服务***的结构示意图;
图2示出了本申请一些实施例提供的电子设备的结构示意图;
图3示出了本申请实施例一所提供的一种订单分配方法的流程图;
图4示出了本申请实施例一所提供的一种查找司机的示意图;
图5示出了本申请实施例二所提供的一种订单分配方法的流程图;
图6示出了本申请实施例三所提供的一种订单分配方法的流程图;
图7示出了本申请实施例四所提供的一种订单分配方法的流程图;
图8示出了本申请实施例五所提供的一种订单分配方法的流程图;
图9示出了本申请实施例六所提供的一种订单分配装置的结构示意图。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,应当理解,本申请中附图仅起到说明和描述的目的,并不用于限定本申请的保护范围。另外,应当理解,示意性的附图并未按实物比例绘制。本申请中使用的流程图示出了根据本申请的一些实施例实现的操作。应该理解,流程图的操作可以不按顺序实现,没有逻辑的上下文关系的步骤可以反转顺序或者同时实施。此外,本领域技术人员在本申请内容的指引下,可以向流程图添加一个或多个其他操作,也可以从流程图中移除一个或多个操作。
另外,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此,以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围,而是仅仅表示本申请的选定实施例。基于本申请的实施例,本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例,都属于本申请保护的范围。
为了使得本领域技术人员能够使用本申请内容,结合特定应用场景“网约车(如专车、快车等)订单分配”,给出以下实施方式。对于本领域技术人员来说,在不脱离本申请的精神和范围的情况下,可以将这里定义的一般原理应用于其他实施例和应用场景。虽然本申请主要围绕网约车安全性检测进行描述,但是应该理解,这仅是一个示例性实施例。
本申请还可以包括能够为出行订单选择接单的服务提供端的任何服务***。本申请的***或方法的应用可以包括网页、浏览器的插件、客户端终端、定制***、内部分析***、或人工智能机器人等,或其任意组合。
需要说明的是,本申请实施例中将会用到术语“包括”,用于指出其后所声明的特征的存在,但并不排除增加其它的特征。
本申请中的术语“乘客”、“请求方”和“服务请求方”可互换使用,以指代可以请求或订购服务的个人、实体或工具。本申请中的术语“司机”、“提供方”和“服务提供方”可互换使用,以指代可以提供服务的个人、实体或工具。本申请中的术语“客户端用户”可以指代请求服务、订购服务的个人、实体或工具。在本申请中,“乘客”、“乘客终端”和“客户端”可以互换使用,“驾驶员”和“驾驶员终端”可以互换使用。
值得注意的是,在本申请提出申请之前,相关技术中通常采用距离最近的方式为司机进行订单分配,然而,有些司机可能并不希望承接距离较近的订单,从而可能导致订单被取消,服务效率较低。本申请的一个方面涉及一种服务***。该***通过服务器接收服务请求端的出行信息以生成出行订单,并能够查找最近一次接的出行订单为从所述服务请求端的目的地所处的第一区域到达所述服务请求端的出发地所处的第二区域的至少一个目标候选服务提供端,以根据查找到的目标候选服务提供端为出行订单选择接单的服务提供端,实现了订单的有效分配,提升了服务效率和司机的接单体验。
图1是本申请一些实施例的服务***的框图。例如,服务***可以是用于诸如出租车、代驾服务、快车、拼车、公共汽车服务、驾驶员租赁、或班车服务之类的运输服务、或其任意组合的在线运输服务平台。服务***可以包括服务器110、网络120、服务请求方终端130、服务提供方终端140和数据库150中的一种或多种,服务器110中可以包括执行指令操作的处理器。
在一些实施例中,服务器110可以是单个服务器,也可以是服务器组。服务器组可以是集中式的,也可以是分布式的(例如,服务器110可以是分布式***)。在一些实施例中,服务器110相对于终端,可以是本地的、也可以是远程的。例如,服务器110可以经由网络120访问存储在服务请求方终端130、服务提供方终端140、或数据库150、或其任意组合中的信息和/或数据。作为另一示例,服务器110可以直接连接到服务请求方终端130、服务提供方终端140和数据库150中至少一个,以访问存储的信息和/或数据。在一些实施例中,服务器110可以在云平台上实现;仅作为示例,云平台可以包括私有云、公有云、混合云、社区云(community cloud)、分布式云、跨云(inter-cloud)、多云(multi-cloud)等,或者它们的任意组合。在一些实施例中,服务器110可以在具有本申请中图2所示的一个或多个组件的电子设备200上实现。
在一些实施例中,服务器110可以包括处理器。处理器可以处理与服务请求有关的信息和/或数据,以执行本申请中描述的一个或多个功能。例如,处理器可以基于从服务请求方终端130获得的服务请求来确定目标车辆。在一些实施例中,处理器可以包括一个或多个处理核(例如,单核处理器(S)或多核处理器(S))。仅作为举例,处理器可以包括中央处理单元(Central Processing Unit,CPU)、专用集成电路(Application SpecificIntegrated Circuit,ASIC)、专用指令集处理器(Application Specific Instruction-set Processor,ASIP)、图形处理单元(Graphics Processing Unit,GPU)、物理处理单元(Physics Processing Unit,PPU)、数字信号处理器(Digital Signal Processor,DSP)、现场可编程门阵列(Field Programmable Gate Array,FPGA)、可编程逻辑器件(Programmable Logic Device,PLD)、控制器、微控制器单元、简化指令集计算机(ReducedInstruction Set Computing,RISC)、或微处理器等,或其任意组合。
网络120可以用于信息和/或数据的交换。在一些实施例中,服务***中的一个或多个组件(例如,服务器110,服务请求方终端130,服务提供方终端140和数据库150)可以向其他组件发送信息和/或数据。例如,服务器110可以经由网络120从服务请求方终端130获取服务请求。在一些实施例中,网络120可以是任何类型的有线或者无线网络,或者是他们的结合。仅作为示例,网络130可以包括有线网络、无线网络、光纤网络、远程通信网络、内联网、因特网、局域网(Local Area Network,LAN)、广域网(Wide Area Network,WAN)、无线局域网(Wireless Local Area Networks,WLAN)、城域网(Metropolitan Area Network,MAN)、广域网(Wide Area Network,WAN)、公共电话交换网(Public Switched TelephoneNetwork,PSTN)、蓝牙网络、ZigBee网络、或近场通信(Near Field Communication,NFC)网络等,或其任意组合。在一些实施例中,网络120可以包括一个或多个网络接入点。例如,网络120可以包括有线或无线网络接入点,例如基站和/或网络交换节点,服务***的一个或多个组件可以通过该接入点连接到网络120以交换数据和/或信息。
在一些实施例中,服务请求方终端130的用户可以是除服务实际需求者之外的其他人。例如,服务请求方终端130的用户A可以使用服务请求方终端130来为服务实际需求者B发起服务请求(比如,用户A可以为自己的朋友B叫车),或者从服务器110接收服务信息或指令等。在一些实施例中,服务提供方终端140的用户可以是服务实际提供者,也可以是除服务实际提供者之外的其他人。例如,服务提供方终端140的用户C可以使用服务提供方终端140接收由服务实际提供者D提供服务的服务请求(比如用户C可以为自己雇用的司机D接单),和/或来自服务器110的信息或指令。在一些实施例中,“服务请求方”和“服务请求方终端”可以互换使用,“服务提供方”和“服务提供方终端”可以互换使用。
在一些实施例中,服务请求方终端130可以包括移动设备、平板计算机、膝上型计算机、或机动车辆中的内置设备等,或其任意组合。在一些实施例中,移动设备可以包括智能家居设备、可穿戴设备、智能移动设备、虚拟现实设备、或增强现实设备等,或其任意组合。在一些实施例中,智能家居设备可以包括智能照明设备、智能电器设备的控制设备、智能监控设备、智能电视、智能摄像机、或对讲机等,或其任意组合。在一些实施例中,可穿戴设备可包括智能手环、智能鞋带、智能玻璃、智能头盔、智能手表、智能服装、智能背包、智能配件等、或其任何组合。在一些实施例中,智能移动设备可以包括智能手机、个人数字助理(Personal Digital Assistant,PDA)、游戏设备、导航设备、或销售点(point of sale,POS)设备等,或其任意组合。在一些实施例中,虚拟现实设备和/或增强现实设备可以包括虚拟现实头盔、虚拟现实玻璃、虚拟现实贴片、增强现实头盔、增强现实玻璃、或增强现实贴片等,或其任意组合。例如,虚拟现实设备和/或增强现实设备可以包括各种虚拟现实产品等。在一些实施例中,机动车辆中的内置设备可以包括车载计算机、车载电视等。在一些实施例中,服务请求方终端130可以是具有用于定位服务请求方和/或服务请求方终端的位置的定位技术的设备。
在一些实施例中,服务提供方终端140可以是与服务请求方终端130类似或相同的设备。在一些实施例中,服务提供方终端140可以是具有定位技术的设备,用于定位服务提供方和/或服务提供方终端的位置。在一些实施例中,服务请求方终端130和/或服务提供方终端140可以与其他定位设备通信以确定服务请求方、服务请求方终端130、服务提供方、或服务提供方终端140、或其任意组合的位置。在一些实施例中,服务请求方终端130和/或服务提供方终端140可以将定位信息发送给服务器110。
数据库150可以存储数据和/或指令。在一些实施例中,数据库150可以存储从服务请求方终端130和/或服务提供方终端140获得的数据。在一些实施例中,数据库150可以存储在本申请中描述的示例性方法的数据和/或指令。在一些实施例中,数据库150可以包括大容量存储器、可移动存储器、易失性读写存储器、或只读存储器(Read-Only Memory,ROM)等,或其任意组合。作为举例,大容量存储器可以包括磁盘、光盘、固态驱动器等;可移动存储器可包括闪存驱动器、软盘、光盘、存储卡、zip磁盘、磁带等;易失性读写存储器可以包括随机存取存储器(Random Access Memory,RAM);RAM可以包括动态RAM(Dynamic RandomAccess Memory,DRAM),双倍数据速率同步动态RAM(Double Date-Rate Synchronous RAM,DDR SDRAM);静态RAM(Static Random-Access Memory,SRAM),晶闸管RAM(Thyristor-Based Random Access Memory,T-RAM)和零电容器RAM(Zero-RAM)等。作为举例,ROM可以包括掩模ROM(Mask Read-Only Memory,MROM)、可编程ROM(Programmable Read-OnlyMemory,PROM)、可擦除可编程ROM(Programmable Erasable Read-only Memory,PEROM)、电可擦除可编程ROM(Electrically Erasable Programmable read only memory,EEPROM)、光盘ROM(CD-ROM)、以及数字通用磁盘ROM等。在一些实施例中,数据库150可以在云平台上实现。仅作为示例,云平台可以包括私有云、公有云、混合云、社区云、分布式云、跨云、多云或者其它类似的等,或其任意组合。
在一些实施例中,数据库150可以连接到网络120以与服务***(例如,服务器110,服务请求方终端130,服务提供方终端140等)中的一个或多个组件通信。服务***中的一个或多个组件可以经由网络120访问存储在数据库150中的数据或指令。在一些实施例中,数据库150可以直接连接到服务***中的一个或多个组件(例如,服务器110,服务请求方终端130,服务提供方终端140等);或者,在一些实施例中,数据库150也可以是服务器110的一部分。
在一些实施例中,服务***中的一个或多个组件(例如,服务器110,服务请求方终端130,服务提供方终端140等)可以具有访问数据库150的权限。在一些实施例中,当满足一定条件时,服务***中的一个或多个组件可以读取和/或修改与服务请求方、服务提供方、或公众、或其任意组合有关的信息。例如,服务器110可以在接收服务请求之后读取和/或修改一个或多个用户的信息。作为另一示例,服务提供方终端140可以在从服务请求方终端130接收服务请求时访问与服务请求方有关的信息,但是服务提供方终端140可以不修改服务请求方的相关信息。
在一些实施例中,可以通过请求服务来实现服务***中的一个或多个组件的信息交换。服务请求的对象可以是任何产品。在一些实施方案中,产品可以是有形产品或非物质产品。有形产品可包括食品、药品、商品、化学产品、电器、服装、汽车、房屋、或奢侈品等,或其任意组合。非物质产品可以包括服务产品、金融产品、知识产品、或互联网产品等,或其任意组合。互联网产品可以包括单独的主机产品、网络产品、移动互联网产品、商业主机产品、或嵌入式产品等,或其任意组合。互联网产品可以用在移动终端的软件、程序、或***等,或者它们的任意组合中。移动终端可以包括平板电脑、笔记本电脑、移动电话、个人数字助理(Personal Digital Assistant,PDA)、智能手表、销售点(Point of sales,POS)设备、车载电脑、车载电视、或可穿戴设备等,或其任意组合。例如,互联网产品可以是计算机或移动电话中使用的任何软件和/或应用程序。软件和/或应用程序可以涉及社交、购物、运输、娱乐时间、学习、或投资等,或其任意组合。在一些实施例中,与运输有关的软件和/或应用程序可以包括旅行软件和/或应用程序、车辆调度软件和/或应用程序、绘图软件和/或应用程序等。在车辆调度软件和/或应用程序中,车辆可包括出租车、公共汽车、私家车等,或其任意组合。
图2示出根据本申请的一些实施例的可以实现本申请思想的服务器110、服务请求方终端130、服务提供方终端140的电子设备200的示例性硬件和软件组件的示意图。例如,处理器可以用于电子设备200上,并且用于执行本申请中的功能。
电子设备200可以是通用计算机或特殊用途的计算机,两者都可以用于实现本申请的订单分配方法。本申请尽管仅示出了一个计算机,但是为了方便起见,可以在多个类似平台上以分布式方式实现本申请描述的功能,以均衡处理负载。
例如,电子设备200可以包括连接到网络的网络端口210、用于执行程序指令的一个或多个处理器220、通信总线230、和不同形式的存储介质240,例如,磁盘、ROM、或RAM,或其任意组合。示例性地,计算机平台还可以包括存储在ROM、RAM、或其他类型的非暂时性存储介质、或其任意组合中的程序指令。根据这些程序指令可以实现本申请的方法。电子设备200还包括计算机与其他输入输出设备(例如键盘、显示屏)之间的输入/输出(Input/Output,I/O)接口250。
为了便于说明,在电子设备200中仅描述了一个处理器。然而,应当注意,本申请中的电子设备200还可以包括多个处理器,因此本申请中描述的一个处理器执行的步骤也可以由多个处理器联合执行或单独执行。例如,若电子设备200的处理器执行步骤A和步骤B,则应该理解,步骤A和步骤B也可以由两个不同的处理器共同执行或者在一个处理器中单独执行。例如,第一处理器执行步骤A,第二处理器执行步骤B,或者第一处理器和第二处理器共同执行步骤A和B。
结合上述对服务***以及服务***中各电子设备的描述,下面结合具体实施例,对本申请提供的订单分配方法进行详细说明。
实施例一
如图3所示,为本申请实施例提供的一种订单分配方法的流程图,该方法的执行主体可以是上述服务***中的服务器,该订单分配方法包括如下步骤:
S301、接收服务请求端的出行信息,根据所述出行信息生成出行订单,其中,所述出行信息包括所述服务请求端的出发地信息与目的地信息。
这里,在乘客需要打车时,可以在其打车软件的客户端(即服务请求端)上输入相应的出行信息,以便于后台服务器根据该出行信息生成对应的出行订单。其中,上述客户端可以是移动设备客户端,还可以是web客户端,还可以是其他客户端,本申请实施例对此不做具体的限制。另外,上述出行信息不仅可以包括服务请求端的出发地信息与目的地信息,还可以包括其他出行信息,如服务请求方选择的用车类型,快车、专车、顺风车等,服务请求方确定的预约上车时间等。
为了便于进行出行订单判断以及服务提供端的查找,上述出发地信息以及目的地信息是本申请实施例最为关键的两个出行信息。其中,上述出发地信息可以是基于定位技术确定的,如在打车软件打开后,客户端可以自动定位当前的位置作为出发地位置。或者,乘客可以在客户端显示的地图上选择具体的出发地位置,或者手动输入出发地信息,如手动输入“首都机场”这一出发地信息,上述目的地信息则主要利用乘客在地图上选择或手动输入方式来确定,在此不再赘述。
S302、查找最近一次接的出行订单为从所述服务请求端的目的地所处的第一区域到达所述服务请求端的出发地所处的第二区域的至少一个目标候选服务提供端。
这里,基于上述出行信息可以查找符合要求的服务提供端,查找的服务提供端可能为一个,也可能为多个,也即,查找到的司机也对应可能为一个,也可能为多个。
如图4所示,为本申请实施例一提供的一种查找司机的示意图。司机D0将历史乘客U1从第一位置P1所处第一区域Z1中的任何一个位置(包括但不限于第一位置P1)送达至第二位置P2所处第二区域Z2中的任何一个位置(包括但不限于第二位置P2)后将处于等待状态,或者,司机D0处于将历史乘客U1从第一位置P1所处第一区域Z1中的任何一个位置(包括但不限于第一位置P1)往第二位置P2所处第二区域Z2中的任何一个位置(包括但不限于第二位置P2)进行载送的服务状态(如图4(a)所示)。在后台服务器接收到当前乘客U2发出由第二位置P2至第一位置P1的出行信息后,将基于该出行信息生成对应的出行订单,当司机D0处于等待状态,可以将当前乘客U2的出行订单分配给上述处于第二区域Z2的该司机D0,当司机D0处于服务状态时,可以在服务状态中的订单完成后,将当前乘客U2的出行订单分配给上述处于第二区域Z2的该司机D0,从而使得该司机D0将当前乘客U2由第二位置P2送达至第一位置P1(如图4(b)所示),实现了订单的有效分配,提升了司机的接单体验。
另外,在第一区域Z1作为该司机D0的偏好出行区域时,能够便于司机D0在自身比较熟悉和偏好的接单范围内接单,从而进一步提升了司机的接单体验。
S303、根据查找到的所述至少一个目标候选服务提供端,为所述出行订单选择接单的服务提供端。
这里,在为出行订单查找到对应的目标候选服务提供端后,便可以为出行订单选择接单司机。本申请实施例中,可以主要采用后台服务自动分配的方式进行订单分配,以适应当前应用场景的需求。
在具体应用中,本申请实施例可以在对所有目标候选服务提供端进行排名后,将排名最靠前的目标候选服务提供端作为出行订单的服务提供端。本申请实施例中,可以基于各目标候选服务提供端距离服务请求端的距离信息、各目标候选服务提供端的当前位置行驶至服务请求端的出发地之间的环境信息、各目标候选服务提供端的评价得分信息等信息对所有目标候选服务提供端进行排名。
为了进一步提升服务提供方的接单体验,本申请实施例可以基于第一区域是否作为服务提供端的偏好出行区域的确定结果来进行目标候选服务提供端的确定。通过如下实施例二进行具体描述。
实施例二
如图5所示,为本申请实施例提供的一种目标候选服务提供端的查找方法,该方法具体包括如下步骤:
S501、根据所述服务请求端的出发地信息,确定参考候选服务提供端;
S502、确定所述第一区域是否为所述参考候选服务提供端的偏好出行区域;
S503、在确定所述第一区域为所述参考候选服务提供端的偏好出行区域,且确定该参考候选服务提供端最近一次接的出行订单为从所述服务请求端的目的地所处的第一区域到达所述服务请求端的出发地所处的第二区域时,将该参考候选服务提供端作为查找到的目标候选服务提供端。
这里,本申请实施例可以首先基于服务请求端的出发地信息,确定参考候选服务提供端,然后再确定第一区域是否为上述参考候选服务提供端的偏好出行区域,最后在确定所述第一区域为所述参考候选服务提供端的偏好出行区域,且确定该参考候选服务提供端最近一次接的出行订单为从第一区域到达第二区域时,将该参考候选服务提供端作为查找到的目标候选服务提供端。
其中,在进行周边参考候选服务提供端查找的过程中,可以以服务请求端为圆心,以设定阈值为半径确定整个查找区域范围内的参考候选服务提供端。在确定查找区域范围时,不易过大也不易过小,过大的查找区域范围可能会存在查找到的参考候选服务提供端过多而导致网约车服务平台资源的浪费,过小的查找区域范围可能会存在查找到的参考候选服务提供端过少而导致查找不到相应的参考候选服务提供端,无法对服务请求端的出行需求进行响应,影响使用体验。因此,本申请实施例可以综合考虑周围环境(如交通状况等)以及各参考候选服务提供端的分布情况等信息来划定对应于服务请求端的查找区域范围,如可以选择以服务请求端的出发地为圆心,围绕半径为5km的一个查找区域范围,且该查找区域范围可以在行程过程中动态变化,以适应网约车应用环境的复杂性。
为了进一步提升服务提供方的接单体验,本申请实施例可以综合考虑偏好出行区域的确定这一影响因素以及最近一次接单的出行订单为第一区域到达第二区域这一影响因素实现目标候选服务提供端的查找。这样,目标候选服务提供端对应的服务提供方可以在自身比较熟悉和偏好的接单范围内接单,不仅提升了服务提供方的接单体验,又因为该服务提供方身处比较熟悉和偏好的环境而能够为服务请求方带来更加方便快捷的网约车服务。
本申请实施例不仅可以基于参考候选服务提供端的预先设置结果来确定第一区域是否为偏好出行区域,还可以基于订单数量的统计结果来确定第一区域是否为偏好出行区域。接下来分别通过如下实施例三和实施例四进行具体描述。
实施例三
如图6所示,为本申请实施例三提供的一种偏好出行区域的确定方法,该方法具体包括如下步骤:
S601、获取所述参考候选服务提供端预先设置的偏好出行区域;
S602、判断所述预先设置的偏好出行区域是否包含所述第一区域;
S603、若判断出所述预先设置的偏好出行区域包含所述第一区域,则确定所述第一区域为所述参考候选服务提供端的偏好出行区域。
这里,本申请实施例中,可以首先获取参考候选服务提供端预先设置的偏好出行区域,然后再判断预先设置的偏好出行区域是否包含所述第一区域,并在判断出预先设置的偏好出行区域包含第一区域时,确定第一区域为参考候选服务提供端的偏好出行区域。
在具体应用中,参考候选服务提供端可以基于相应的设置端口设置偏好出行区域,比如,可以设置机场所属区域、火车站所属区域等作为偏好出行区域,还可以设置住宅所属区域作为偏好出行区域,还可以设置参考候选服务提供方意图前往的其他区域作为偏好出行区域,本申请实施例对此不做具体的限制。
实施例四
如图7所示,为本申请实施例四提供的一种偏好出行区域的确定方法,该方法具体包括如下步骤:
S701、确定所述参考候选服务提供端在所述第一区域服务过的订单数量是否高于设定阈值;
S702、若确定所述订单数量高于所述设定阈值,则确定所述第一区域为所述参考候选服务提供端的偏好出行区域。
这里,为了减少服务器派单计算的复杂度,可以基于参考候选服务提供端在所述第一区域服务过的订单数量是否高于设定阈值的判断结果确定第一区域是否为参考候选服务提供端的偏好出行区域。这样,可以限制在所述第一区域服务过的订单数量高于设定阈值这一条件查找以第一区域作为历史经常活动区域的司机的前提下,确定最近一次接的出行订单为从所述服务请求端的目的地所处的第一区域到达所述服务请求端的出发地所处的第二区域时对应的参考候选服务提供端,作为查找到的目标候选服务提供端。
考虑到在本申请实施例所提供的订单分配方法的实际应用场景,本申请实施例还可以综合考虑服务请求端对上车时间的需求进行目标候选服务提供端的确定。通过如下实施例五进行具体描述。
实施例五
如图8所示,为本申请实施例五所提供的查找目标候选服务提供端的方法,该方法具体包括如下步骤:
S801、确定所述服务请求端对上车时间的需求;
S802、若所述服务请求端对上车时间没有实时性需求,则根据所述服务请求端的预约上车时间,从最近一次接的正在服务的出行订单为从所述第一区域到达所述第二区域的第一候选服务提供端、以及当前处于空闲状态且最近一次接的已完成服务的出行订单为从所述第一区域到达所述第二区域的第二候选服务提供端中,选择预估接驾时间符合所述预约上车时间的服务提供端作为目标候选服务提供端。
这里,首先需要确定服务请求端对上车时间的需求,然后再根据服务请求端对上车时间的不同需求来确定对应的服务提供端的查找策略。这里,在服务请求端对上车时间没有实时性需求时,可以基于服务请求端的预约上车时间,从正在服务的第一候选服务提供端或者已完成服务的二候选服务提供端中进行查找。对于正在服务的第一候选服务提供端而言,其最近一次接的正在服务的出行订单为从所述第一区域到达所述第二区域,对于已完成服务的第二候选服务提供端而言,其当前处于空闲状态且最近一次接的已完成服务的出行订单为从所述第一区域到达所述第二区域,且不管是第一候选服务提供端还是第二候选服务提供端,只要其预估接驾时间能够符合上述服务请求端的预约上车时间即可作为对应的服务提供端的查找对象。例如,正在服务的第一候选服务提供端预计完成服务的时间为早上9:10,其从完成服务的位置到服务请求端的出发地预计需要花费30分钟,也即该第一候选服务提供端预计9:40能够达到乘客的出发地,已完成服务处于空闲状态的第二候选服务提供端从当前停靠位置出发至乘客的出发地预计需要花费20分钟,若该第二候选服务提供端从乘客下单时间开始出发到乘客的出发地的时间为9:30,在乘客的预约上车时间9:30时,若允许预估接驾时间和乘客的预约上车时间存在预设时间差(如10分钟),此时可以将上述第二候选服务提供端和第一候选服务提供端均作为对应的司机查找对象。其中,上述预估接驾时间可以指的是正在服务的出行订单或已完成服务的出行订单的结束时间至乘客的出发地所占用的时长,该时长很大程度上会受到司机接驾过程中的交通状况,会随着交通拥堵等不良好的状况而延长。
值得说明的是,在乘客对上车时间具有实时性要求时,考虑到一般情况下正在服务的第一候选服务提供端往往需要一定的时间才能完成服务而无法确保乘客的实时性用车需求,此时,可以将当前处于空闲状态且最近一次接的已完成服务的出行订单为从所述第一区域到达所述第二区域的第二候选服务提供端作为对应的司机查找对象,以基本满足乘客的实时性用车需求。
上述乘客对上车时间的需求主要指的是乘客是否对上车时间具有实时性需求,具有实时性需求,即可以表明乘客发出的出行订单为实时类型的,没有实时性需求,即可以表明乘客发出的出行订单为预约类型的。
另外,本申请实施例中也可以通过后台服务器来干预乘客发出的出行订单的类型。这里主要考虑一个发单前的导流环节,以通过延长订单有效时长,尽量找到合适的司机。也即,在后台服务器获取到乘客存在出行的意图时,可以向所述乘客的客户端发送选择预约方式下单的提示信息,并通过提示信息中携带的预约方式下单优惠信息和预约时间选项来鼓励乘客以预约方式进行下单,例如,后台服务器可以向乘客的客户端发送“请问是否愿意等候30分钟,若愿意等候30分钟,即可享受8折优惠”的提示信息,还可以在接收到客户端针对提示信息的反馈信息,如“愿意等待30分钟”后,确定乘客对对上车时间没有实时性需求。这样,便可以在更大时间范围内找到合适的司机,更进一步地提升订单的有效分配,提升司机的接单体验。
基于上述实施例,本申请还提供了订单分配装置,下述各种装置的实施可以参见方法的实施,重复之处不再赘述。
实施例六
如图9所示,为本申请实施例五提供的订单分配装置,包括:
订单生成模块901,用于接收服务请求端的出行信息,根据所述出行信息生成出行订单,其中,所述出行信息包括所述服务请求端的出发地信息与目的地信息;
提供端查找模块902,用于查找最近一次接的出行订单为从所述服务请求端的目的地所处的第一区域到达所述服务请求端的出发地所处的第二区域的至少一个目标候选服务提供端;
订单分配模块903,用于根据查找到的所述至少一个目标候选服务提供端,为所述出行订单选择接单的服务提供端。
在一种实施方式中,还包括:
提供端确定模块904,用于根据所述服务请求端的出发地信息,确定参考候选服务提供端;
偏好确定模块905,用于确定所述第一区域是否为所述参考候选服务提供端的偏好出行区域;
所述提供端查找模块902,具体用于:
在确定所述第一区域为所述参考候选服务提供端的偏好出行区域,且确定该参考候选服务提供端最近一次接的出行订单为从所述服务请求端的目的地所处的第一区域到达所述服务请求端的出发地所处的第二区域时,将该参考候选服务提供端作为查找到的目标候选服务提供端。
在一些实施例中,所述提供端确定模块904,具体用于:
根据所述服务请求端的出发地信息,确定与所述服务请求端之间的距离小于设定阈值的区域范围;
将当前在确定的区域范围内的服务提供端作为参考候选服务提供端。
在另一种实施方式中,还包括:
区域判断模块906,用于获取所述参考候选服务提供端预先设置的偏好出行区域;判断所述预先设置的偏好出行区域是否包含所述第一区域;
所述偏好确定模块905,具体用于:
若判断出所述预先设置的偏好出行区域包含述第一区域,则确定所述第一区域为所述参考候选服务提供端的偏好出行区域。
在又一种实施方式中,还包括:
区域确定模块907,用于确定所述参考候选服务提供端在所述第一区域服务过的订单数量是否高于设定阈值;
所述偏好确定模块905,具体用于:
若确定所述订单数量高于所述设定阈值,则确定所述第一区域为所述参考候选服务提供端的偏好出行区域。
在再一种实施方式中,所述提供端查找模块902,具体用于:
确定所述服务请求端对上车时间的需求;
若所述服务请求端对上车时间没有实时性需求,则根据所述服务请求端的预约上车时间,从最近一次接的正在服务的出行订单为从所述第一区域到达所述第二区域的第一候选服务提供端、以及当前处于空闲状态且最近一次接的已完成服务的出行订单为从所述第一区域到达所述第二区域的第二候选服务提供端中,选择预估接驾时间符合所述预约上车时间的服务提供端作为目标候选服务提供端。
在一些实施例中,所述提供端查找模块902,具体用于:
向所述服务请求端发送选择预约方式下单的提示信息;
根据所述服务请求端针对所述提示信息的反馈信息,确定所述服务请求端对上车时间的需求。
在一些实施例中,所述提示信息中携带有预约方式下单优惠信息和预约时间选项。
实施例七
本申请实施例七还提供了一种计算机可读存储介质,该计算机可读存储介质上存储有计算机程序,该计算机程序被处理器运行时执行上述实施例一至实施例五中任一实施例所对应的订单分配方法的步骤。
具体地,该存储介质能够为通用的存储介质,如移动磁盘、硬盘等,该存储介质上的计算机程序被运行时,能够执行上述订单分配的方法,从而实现了订单的有效分配,提升了司机的接单体验。
本申请实施例所提供的订单分配方法的计算机程序产品,包括存储了程序代码的计算机可读存储介质,程序代码包括的指令可用于执行前面方法实施例中的方法,具体实现可参见方法实施例,在此不再赘述。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的***和装置的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(ROM,Read-OnlyMemory)、随机存取存储器(RAM,Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
以上,仅为本申请的具体实施方式,但本申请的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本申请揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本申请的保护范围之内。因此,本申请的保护范围应以权利要求的保护范围为准。
Claims (10)
1.一种订单分配方法,其特征在于,包括:
接收服务请求端的出行信息,根据所述出行信息生成出行订单,其中,所述出行信息包括所述服务请求端的出发地信息与目的地信息;
根据所述服务请求端的出发地信息,确定与所述服务请求端之间的距离小于设定阈值的区域范围;
将当前在确定的区域范围内的服务提供端作为参考候选服务提供端;
在确定第一区域为参考候选服务提供端的偏好出行区域,且确定该参考候选服务提供端最近一次接的出行订单为从所述服务请求端的目的地所处的第一区域到达所述服务请求端的出发地所处的第二区域时,将该参考候选服务提供端作为查找到的目标候选服务提供端;其中,所述参考候选服务提供端的偏好出行区域是根据参考候选服务提供端预先设置的偏好出行区域或参考候选服务提供端在所述第一区域服务过的订单数量确定的;
根据查找到的至少一个目标候选服务提供端,为所述出行订单选择接单的服务提供端。
2.根据权利要求1所述的方法,其特征在于,查找最近一次接的出行订单为从所述服务请求端的目的地所处的第一区域到达所述服务请求端的出发地所处的第二区域的至少一个目标候选服务提供端,包括:
确定所述服务请求端对上车时间的需求;
若所述服务请求端对上车时间没有实时性需求,则根据所述服务请求端的预约上车时间,从最近一次接的正在服务的出行订单为从所述第一区域到达所述第二区域的第一候选服务提供端、以及当前处于空闲状态且最近一次接的已完成服务的出行订单为从所述第一区域到达所述第二区域的第二候选服务提供端中,选择预估接驾时间符合所述预约上车时间的服务提供端作为目标候选服务提供端。
3.根据权利要求2所述的方法,其特征在于,根据以下步骤确定所述服务请求端对上车时间的需求:
向所述服务请求端发送选择预约方式下单的提示信息;
根据所述服务请求端针对所述提示信息的反馈信息,确定所述服务请求端对上车时间的需求。
4.根据权利要求3所述的方法,其特征在于,所述提示信息中携带有预约方式下单优惠信息和预约时间选项。
5.一种订单分配装置,其特征在于,包括:
订单生成模块,用于接收服务请求端的出行信息,根据所述出行信息生成出行订单,其中,所述出行信息包括所述服务请求端的出发地信息与目的地信息;
提供端确定模块,用于根据所述服务请求端的出发地信息,确定与所述服务请求端之间的距离小于设定阈值的区域范围;将当前在确定的区域范围内的服务提供端作为参考候选服务提供端;
提供端查找模块,用于在确定第一区域为参考候选服务提供端的偏好出行区域,且确定该参考候选服务提供端最近一次接的出行订单为从所述服务请求端的目的地所处的第一区域到达所述服务请求端的出发地所处的第二区域时,将该参考候选服务提供端作为查找到的目标候选服务提供端;其中,所述参考候选服务提供端的偏好出行区域是根据参考候选服务提供端预先设置的偏好出行区域或参考候选服务提供端在所述第一区域服务过的订单数量确定的;
订单分配模块,用于根据查找到的至少一个目标候选服务提供端,为所述出行订单选择接单的服务提供端。
6.根据权利要求5所述的装置,其特征在于,所述提供端查找模块,具体用于:
确定所述服务请求端对上车时间的需求;
若所述服务请求端对上车时间没有实时性需求,则根据所述服务请求端的预约上车时间,从最近一次接的正在服务的出行订单为从所述第一区域到达所述第二区域的第一候选服务提供端、以及当前处于空闲状态且最近一次接的已完成服务的出行订单为从所述第一区域到达所述第二区域的第二候选服务提供端中,选择预估接驾时间符合所述预约上车时间的服务提供端作为目标候选服务提供端。
7.根据权利要求6所述的装置,其特征在于,所述提供端查找模块,具体用于:
向所述服务请求端发送选择预约方式下单的提示信息;
根据所述服务请求端针对所述提示信息的反馈信息,确定所述服务请求端对上车时间的需求。
8.根据权利要求7所述的装置,其特征在于,所述提示信息中携带有预约方式下单优惠信息和预约时间选项。
9.一种电子设备,其特征在于,包括:处理器、存储器和总线,所述存储器存储有所述处理器可执行的机器可读指令,当电子设备运行时,所述处理器与所述存储器之间通过总线通信,所述机器可读指令被所述处理器执行时执行如权利要求1至4任一所述的订单分配方法的步骤。
10.一种计算机可读存储介质,其特征在于,该计算机可读存储介质上存储有计算机程序,该计算机程序被处理器运行时执行如权利要求1至4任一所述的订单分配方法的步骤。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910138870.8A CN111612286B (zh) | 2019-02-25 | 2019-02-25 | 一种订单分配方法、装置、电子设备及存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910138870.8A CN111612286B (zh) | 2019-02-25 | 2019-02-25 | 一种订单分配方法、装置、电子设备及存储介质 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN111612286A CN111612286A (zh) | 2020-09-01 |
CN111612286B true CN111612286B (zh) | 2023-09-29 |
Family
ID=72202868
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201910138870.8A Active CN111612286B (zh) | 2019-02-25 | 2019-02-25 | 一种订单分配方法、装置、电子设备及存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111612286B (zh) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112381613A (zh) * | 2020-11-26 | 2021-02-19 | 南京青囊医疗科技服务有限公司 | 一种基于手术跟台服务的订单管理方法及*** |
CN112801454A (zh) * | 2020-12-31 | 2021-05-14 | 北京嘀嘀无限科技发展有限公司 | 确定资源配置的方法、装置、计算机设备、介质和产品 |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2009146300A (ja) * | 2007-12-17 | 2009-07-02 | Nec Corp | 配車システム、タクシー側端末装置、サーバ装置、携帯端末装置、タクシー側端末装置用プログラム等 |
CN102113001A (zh) * | 2008-08-05 | 2011-06-29 | 罗恩·本·艾瑞 | 用于出租车管理的***与方法 |
CN103996290A (zh) * | 2014-06-09 | 2014-08-20 | 北京东方车云信息技术有限公司 | 一种提供叫车服务的方法、服务器及*** |
CN104794553A (zh) * | 2014-08-12 | 2015-07-22 | 北京东方车云信息技术有限公司 | 网络租车中基于出租车运营区域熟悉程度的派单***和方法 |
CN106096764A (zh) * | 2016-06-02 | 2016-11-09 | 深圳市永兴元科技有限公司 | 订单处理方法及装置 |
CN106779910A (zh) * | 2016-11-24 | 2017-05-31 | 北京小度信息科技有限公司 | 配送订单分配方法和装置 |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP3408843A4 (en) * | 2016-01-27 | 2018-12-12 | Beijing Didi Infinity Technology and Development Co., Ltd. | Systems and methods for matching and displaying service request and available vehicles |
CN107424022B (zh) * | 2016-05-23 | 2022-02-11 | 北京嘀嘀无限科技发展有限公司 | 一种订单的推送方法及*** |
CN106327311B (zh) * | 2016-09-14 | 2022-02-15 | 京东方科技集团股份有限公司 | 订单处理方法、装置及*** |
-
2019
- 2019-02-25 CN CN201910138870.8A patent/CN111612286B/zh active Active
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2009146300A (ja) * | 2007-12-17 | 2009-07-02 | Nec Corp | 配車システム、タクシー側端末装置、サーバ装置、携帯端末装置、タクシー側端末装置用プログラム等 |
CN102113001A (zh) * | 2008-08-05 | 2011-06-29 | 罗恩·本·艾瑞 | 用于出租车管理的***与方法 |
CN103996290A (zh) * | 2014-06-09 | 2014-08-20 | 北京东方车云信息技术有限公司 | 一种提供叫车服务的方法、服务器及*** |
CN104794553A (zh) * | 2014-08-12 | 2015-07-22 | 北京东方车云信息技术有限公司 | 网络租车中基于出租车运营区域熟悉程度的派单***和方法 |
CN106096764A (zh) * | 2016-06-02 | 2016-11-09 | 深圳市永兴元科技有限公司 | 订单处理方法及装置 |
CN106779910A (zh) * | 2016-11-24 | 2017-05-31 | 北京小度信息科技有限公司 | 配送订单分配方法和装置 |
Also Published As
Publication number | Publication date |
---|---|
CN111612286A (zh) | 2020-09-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20220044186A1 (en) | Arranging a transport service for multiple users | |
US11030843B2 (en) | Implementing a transport service using unique identifiers | |
Liu et al. | FooDNet: Toward an optimized food delivery network based on spatial crowdsourcing | |
US10788329B2 (en) | Network system for multi-leg transport | |
JP2020515951A (ja) | オンデマンドサービスのための乗り物を割り当てるシステム及び方法 | |
CN109376311A (zh) | 适用于多个共乘模型的驾驶员-乘车者匹配的***、方法和装置 | |
JP6629878B2 (ja) | 予約オーダーを割り当てるシステム及び方法 | |
CN108701320A (zh) | 拼车的***和方法 | |
CN111353092B (zh) | 服务推送方法、装置、服务器及可读存储介质 | |
CN108985896B (zh) | 拼车方法、拼车路线的推荐方法、装置、介质及电子设备 | |
JP6772302B2 (ja) | 情報処理のためのシステム及び方法 | |
CN108701403A (zh) | 用于展示与服务请求相关的标识的***及方法 | |
CN111277618B (zh) | 一种信息推送方法、装置、电子设备及存储介质 | |
CN111105251A (zh) | 一种信息推送方法及装置 | |
CN111612286B (zh) | 一种订单分配方法、装置、电子设备及存储介质 | |
CN110832536B (zh) | 推荐上车地点的***和方法 | |
CN110750709A (zh) | 一种服务推荐方法及装置 | |
CN111489214B (zh) | 订单分配方法、条件设置方法、装置及电子设备 | |
CN111353093B (zh) | 问题推荐方法、装置、服务器及可读存储介质 | |
CN111260423A (zh) | 订单分配方法、装置、电子设备及计算机可读存储介质 | |
US11940286B1 (en) | Fast computational generation of digital pickup and delivery plans | |
CN111143486A (zh) | 一种服务位置获取方法、装置、电子设备及存储介质 | |
CN111148024A (zh) | 信息推送方法、装置、电子设备及计算机存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |