CN114065981A - 订单数据处理方法、设备、平台、系统及计算机存储介质 - Google Patents

Abstract

本申请实施例提供了一种数据调用方法、装置、电子设备及计算机存储介质，其中，数据调用方法包括：监听第一订单请求的呼叫时长；当呼叫时长超过预设的时长阈值时，创建第二订单请求，第二订单请求包括第一订单请求中未包含的运力服务商；向第二订单请求包含的运力服务商的运力服务平台发送第二订单请求；监听运力服务商的运力服务平台是否返回与第二订单请求匹配的第二订单应答；若监听到第二订单应答且未监听到第一订单请求的第一订单应答时，展示第二订单应答；响应于针对第二订单应答的确认操作时，建立网约车服务订单。可以向用户推荐用户未选择的服务商的应答，避免用户等待过长时间。

Description

订单数据处理方法、设备、平台、系统及计算机存储介质

技术领域

本申请实施例涉及电子信息技术领域，尤其涉及一种订单数据处理方法、设备、平台、系统及计算机存储介质。

背景技术

随着科技的发展，网络约车服务日渐完善，乘客和司机通过网络约车平台可以快速进行需求匹配。相关技术中，用户进入网约车订单页面填写行程信息后，系统会推荐运力服务商，用户在系统推荐的运力服务商中选择运力服务商并触发呼叫，以创建网约车订单请求，该订单请求将通过所述网络约车平台发送给用户选择的运力服务商的运力服务平台，如果有运力端响应订单，则订单需求匹配成功，如果没有运力端响应订单，则用户可以选择等待或者取消订单后重新呼叫。本申请发明人发现，没有运力端响应的订单，等待或者取消订单重新呼叫，对用户而言会产生等待时间成本，这一定程度会影响用户体验。

发明内容

有鉴于此，本申请实施例提供一种订单数据处理方法、设备、平台、系统及计算机存储介质，以解决上述部分或全部问题。

根据本申请实施例的第一方面，提供了一种订单数据处理方法，包括：监听第一订单请求的呼叫时长；当呼叫时长超过预设的时长阈值时，创建第二订单请求，第二订单请求包括第一订单请求中未包含的运力服务商；向第二订单请求包含的运力服务商的运力服务平台发送第二订单请求；监听运力服务商的运力服务平台是否返回与第二订单请求匹配的第二订单应答；若监听到第二订单应答且未监听到第一订单请求的第一订单应答时，展示第二订单应答；响应于针对第二订单应答的确认操作时，建立网约车服务订单。

根据本申请实施例的第二方面，提供了一种网约车聚合服务平台，包括：监听模块，用于监听第一订单请求的呼叫时长；触发模块，用于当呼叫时长超过预设的时长阈值时，创建第二订单请求，第二订单请求包括第一订单请求中未包含的运力服务商；发送模块，用于向第二订单请求包含的运力服务商的运力服务平台发送第二订单请求；监听模块，还用于监听运力服务商的运力服务平台是否返回与第二订单请求匹配的第二订单应答；订单管理模块，用于若监听到第二订单应答且未监听到第一订单请求的第一订单应答时，展示第二订单应答；订单确认模块，用于响应于针对第二订单应答的确认操作时，建立网约车服务订单。

根据本申请实施例的第三方面，提供了一种网约车服务系统，包括：网约车聚合服务平台和运力服务平台，网约车聚合服务平台和运力服务平台之间相互通信，网约车聚合服务平台为第三方面所描述的网约车聚合服务平台。

根据本申请实施例的第四方面，提供了一种电子设备，包括：处理器、存储器、通信接口和通信总线，处理器、存储器和通信接口通过通信总线完成相互间的通信；存储器用于存放至少一可执行指令，可执行指令使处理器执行如第一方面的订单数据处理方法对应的操作。

根据本申请实施例的第五方面，提供了一种计算机存储介质，其上存储有计算机程序，该程序被处理器执行时实现如第一方面的订单数据处理方法。

本申请实施例提供的订单数据处理方法、设备、平台、系统及计算机存储介质，监听第一订单请求的呼叫时长；当呼叫时长超过预设的时长阈值时，创建第二订单请求，第二订单请求包括第一订单请求中未包含的运力服务商；向第二订单请求包含的运力服务商的运力服务平台发送第二订单请求；监听运力服务商的运力服务平台是否返回与第二订单请求匹配的第二订单应答；若监听到第二订单应答且未监听到第一订单请求的第一订单应答时，展示第二订单应答；响应于针对第二订单应答的确认操作时，建立网约车服务订单。第一订单请求超过预设的时长阈值没有应答，表明第一订单请求中包含的运力服务商短时间内未能向用户提供服务，而第二订单请求包含了第一订单请求中未包含的运力服务商，利用第二订单请求可以向用户推荐用户未选择的运力服务商的应答，可以避免用户等待过长时间，而且用户可以对第二订单应答选择是否确认，即用户可以选择第二订单应答，也可以选择继续等待第一订单请求的应答，用户选择更加灵活，提高了用户体验。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请实施例中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。

图1为本申请实施例一提供的一种订单数据处理方法的场景示意图；

图2为本申请实施例一提供的一种订单数据处理方法的流程图；

图3为本申请实施例一提供的一种用户设置示意图；

图4为本申请实施例一提供的另一种订单数据处理方法的场景示意图；

图5为本申请实施例二提供的一种网约车聚合服务平台的结构框图；

图6为本申请实施例三提供的一种电子设备的结构示意图。

具体实施方式

为了使本领域的人员更好地理解本申请实施例中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本申请实施例一部分实施例，而不是全部的实施例。基于本申请实施例中的实施例，本领域普通技术人员所获得的所有其他实施例，都应当属于本申请实施例保护的范围。

下面结合本申请实施例附图进一步说明本申请实施例具体实现。

实施例一

本申请实施例一提供一种订单数据处理方法，应用于网约车聚合服务平台，为了便于理解，对本申请实施例一所提供的订单数据处理方法的应用场景进行说明，参照图1所示，图1为本申请实施例一提供的一种订单数据处理方法的场景示意图。图1示出了用户101、网约车聚合服务平台102、及云端103。

其中，网约车聚合服务平台可以是例如智能手机、平板电脑等终端设备，用户使用终端设备进行网络约车；或者，网约车聚合服务平台也可以是例如服务平台、中继设备、端到端设备等网络设备，网约车聚合服务平台作为平台服务器接收用户通过终端设备发送的订单请求，与各个运力服务商的服务平台进行交互为订单请求匹配应答。

网约车聚合服务平台可以接入网络，通过网络与云端连接，并进行数据交互，本申请中，网络包括局域网(英文：Local Area Network，LAN)、广域网(英文：Wide AreaNetwork，WAN)、移动通信网络；如万维网(英文：World Wide Web，WWW)、长期演进(英文：Long Term Evolution，LTE)网络、2G网络(英文：2th Generation Mobile Network)、3G网络(英文：3th Generation Mobile Network)，5G网络(英文：5th Generation MobileNetwork)等。当然，此处只是示例性说明，并不代表本申请局限于此。

云端可以包括服务平台、中继设备、端到端设备等网络设备。在本申请中，云端可以包括提供网络约车服务的至少一个运力服务商的服务平台，需要说明的是，如果网约车聚合服务平台是用户使用的终端设备，则云端还可以包括平台服务器。

如图1所示，在用户进行网络约车时，用户自己发起的订单请求可以作为第一订单请求，在第一订单请求的呼叫时长超过预设的时长阈值，且第一订单请求无应答时，网约车聚合服务平台创建第二订单请求；向第二订单请求包含的各个运力服务商的服务平台(云端)发送第二订单请求；接收运力服务商的服务平台(云端)返回的与第二订单请求匹配的第二订单应答；在确定未接收到对于第一订单请求的应答时，展示第二订单应答；如果用户对第二订单应答进行确认，则建立第二订单，发出第二订单应答的司机就可以为用户提供服务，用户不需要继续等待第一订单请求的应答，减少了用户等待时间，提高了用户体验。

结合图1所示的场景，详细说明本申请实施例一提供的订单数据处理方法，需要说明的是，图1只是本申请实施例一提供的订单数据处理方法的一种应用场景，并不代表该订单数据处理方法必须应用于图1所示的场景，参照图2所示，图2为本申请实施例一提供的一种订单数据处理方法的流程图，该方法包括以下步骤：

步骤201、监听第一订单请求的呼叫时长。

在本申请中，第一订单可以是用户在网络约车时建立的订单，网络约车指的是用户通过终端设备在网络上预约车辆的过程。网络约车的服务可以包括在当前时间司机驾驶车辆将用户送达目的地；也可以包括在预约的时间，司机驾驶车辆在指定地点接用户并送至目的地；也可以包括拼车、顺风车等服务。用户通过网络约车可以享受司机的送达服务，也可以享受租车自驾的服务等。当然，此处只是示例性说明。第一订单请求可以是根据用户设定创建的订单请求，呼叫时长可以表示用户等待的时间长度，示例性地，呼叫时长为第一订单请求开始呼叫到当前时刻的时间长度，或者，呼叫时长为第一订单请求从创建到当前时刻的时间。

步骤202、当呼叫时长超过预设的时长阈值时，创建第二订单请求。

其中，第二订单请求包括第一订单请求中未包含的运力服务商。运力服务商指的是向用户提供网络约车的服务商，运力服务商可以通过运力服务平台向用户提供网络约车服务，用户在不同的运力服务商的运力服务平台上可以进行网络约车。示例性地，在本申请中，用户可以在预设平台上进行网络约车，预设平台上聚合了多个运力服务商提供的服务，即用户可以在预设平台上享受多个运力服务商提供的网络约车服务。当第一订单请求地呼叫时长超过预设的时长阈值时，表明在超过时长阈值的时间内，都没有对于第一订单请求的第一订单应答，即没有司机接单，或者没有收到对于第一订单请求的第一订单应答，第一订单应答为司机反馈的针对于第一订单请求已经接单或者可以接单的应答信息。预设的时长阈值可以根据具体情况自行设定，例如，预设的时长阈值可以是1分钟、5分钟、10分钟等。

可选地，在一个示例中，步骤201之前还可以包括创建第一订单请求的步骤，例如，网约车聚合服务平台为终端设备，该方法还包括：响应于用户在网络约车时创建订单请求的操作以及呼叫车辆的操作，创建第一订单请求；向第一订单请求中包含的运力服务商的服务平台发送第一订单请求。具体地，用户通过与终端设备进行人机交互，设置/填写第一订单请求的内容，例如，用户可以设置起点、目的地，选择提供服务的运力服务商等，用户填写完毕后，可以通过交互操作触发呼叫车辆，终端设备即可根据用户填写/设置的内容创建第一订单请求并向第一订单请求中包含的运力服务商的服务平台发送第一订单请求。需要说明的是，在本申请中，运力服务商指的是提供网络约车服务的商家。例如，有运力服务商A到E，5个运力服务商，用户可以选择其中的一个或者多个运力服务商，网约车聚合服务平台就只向用户选择的运力服务商的服务平台发送第一订单请求。

在本申请中，第二订单请求可以表示未经用户选择的，包含第一订单未包含的运力服务商的订单请求。可选地，第二订单请求可以是快走订单请求，用于实现快速成单。可选地，在一个示例中，用户可以选择是否进入快走流程，快走流程即为利用第二订单进行约车的流程，例如，当呼叫时长超过预设的时长阈值时，创建第二订单请求，包括：当第一订单请求的呼叫时长超过时长阈值，且第一订单请求无应答时，提示用户是否触发第二订单请求；在检测到用户对于第二订单请求的触发操作时，创建第二订单请求。具体地，可以显示提示信息来提示用户是否触发快走流程，如果用户选择确认触发快走流程，则自动创建第二订单请求，如果用户选择不触发快走流程，则继续等待第一订单请求的应答。用户自主选择是否进入快走流程，为用户提供了更多选择，可以满足不同用户的需求，用户使用更加灵活，提高了用户体验。

可选地，在又一个示例中，对创建第二订单请求的过程进行说明，创建第二订单请求，包括：根据第一订单请求中包含的行程信息建立第二订单请求；对于第一订单请求未包含的至少一个运力服务商，将报价与第一订单请求的报价比例小于或等于预设比例的运力服务商，加入第二订单请求。需要说明的是，行程信息可以包括用户设定的起点和目的地。进一步可选地，在一个实施例中，对于第一订单请求未包含的至少一个运力服务商，按照第一订单请求中的起点和目的地计算各个运力服务商的订单金额(即报价)，将订单金额与第一订单请求的订单金额，比例小于或等于预设比例的运力服务商，加入第二订单请求中。需要说明的是，各个运力服务商的报价可以是终端设备根据各个运力服务商的计价策略计算得到的，也可以是预设平台根据各个运力服务商的计价策略计算之后，发送至终端设备的。可选地，报价可以是根据计价策略计算得到的一个价格区间，或者是一个预估的价格。其中，第一订单请求的订单金额可以是第一订单请求中报价最高的运力服务商的订单金额，也可以是第一订单请求中各运力服务商报价的平均值(可以是加权平均值)所表示的订单金额，也可以是第一订单请求中报价最低的运力服务商的订单金额，当然，此处只是示例性说明。例如，对于运力服务商A-E，如果第一订单请求包含运力服务商A和B，可以计算运力服务商A和B的报价平均值，分别按照运力服务商C、D、E的计价规则，计算运力服务商C、D、E按照第一订单请求中的起点和目的地进行计费的订单金额，分别计算各个运力服务商的订单金额与报价平均值(即第一订单请求中运力服务商A和B的报价平均值)的比例，将比例小于或等于预设比例的运力服务商加入第二订单请求中，第二订单请求也可以包括运力服务商A和/或B。需要说明的是，预设比例可以是1.5或者2，也可以是其他数值，此处只是示例性说明。

上述三个示例是相互独立的，可以单独执行，也可以结合起来执行，可以三个示例都执行，也可以执行其中任意两个，也可以单独只执行一个示例，当然，此处只是示例性说明。

步骤203、向第二订单请求包含的各个运力服务商的运力服务平台发送第二订单请求。

需要说明的是，第二订单请求包含第一订单请求未包含的运力服务商，第二订单请求也可以包含第一订单请求已包含的运力服务商。例如，对于运力服务商A-E，如果第一订单请求包含运力服务商A和B，第二订单请求可以包含运力服务商C、D、E中的至少一个，第二订单请求还可以包括A和/或B，也可以不包含A和B。当然，此处只是示例性说明，并不代表本申请局限于此。

步骤204、监听运力服务平台是否返回与第二订单请求匹配的第二订单应答。

第二订单应答为司机反馈的用于表示对第二订单请求可以接单的应答信息。需要说明的是，第二订单请求中可能包含多个运力服务商，因此，可能会接收到一个或多个不同运力服务商的司机返回的响应信息，可以在一个或多个响应信息中确定一个响应信息作为第二订单应答。例如，在一个可选的实施例中，监听运力服务平台是否返回与第二订单请求匹配的第二订单应答，包括：接收多个运力服务商的运力服务平台返回的，对于第二订单请求的一个或多个响应信息；在一个或多个响应信息中确定至少一个响应信息作为第二订单应答。在一个或多个响应信息中确定至少一个响应信息作为第二订单应答，为用户省去了选择的时间，提高了整体成单效率，进一步减少用户等待时间。需要说明的是，如果选择多个响应信息作为第二订单应答，则在向用户展示第二订单应答之后，用户还可以在第二订单应答包含的多个响应信息中选择一个成单，如果选择一个响应信息作为第二订单应答，则可以直接向用户展示第二订单应答。具体地，一个或多个响应信息可以是在一个时间段内接收到，例如，在第二订单请求发出后5分钟内接收到的，当然，时间段的长度可以自行设定。在一个或多个响应信息中确定至少一个响应信息作为第二订单应答可以有多种实现方式，此处列举四种具体的实现方式进行示例性说明：

可选择，在第一种实现方式中，在一个或多个响应信息中确定至少一个响应信息作为第二订单应答，包括：基于响应信息对应的运力端的服务质量参数，选择至少一个响应信息作为第二订单应答。进一步地，服务质量参数可以包括转化率，可以按照一个或多个响应信息的接收顺序，将接收到的第一个转化率高于预设阈值的司机的响应信息作为第二订单应答，司机的转化率用于指示司机成单量与接单量的比例。成单量指的是司机响应，并且乘客确认，最终行程完成的订单量；接单量指的是司机做出响应的订单量。转化率可以表示一个司机成单的概率，将第一个转化率高于预设阈值的司机的响应信息作为第二订单应答，不仅保证了推送给用户的是成单率较高的司机，还保证了成单速度，减少用户等待时间，兼顾了成单率和成单速度。

可选择，在第二种实现方式中，在一个或多个响应信息中确定至少一个响应信息作为第二订单应答，包括：将一个或多个响应信息中，司机的转化率最高的响应信息作为第二订单应答，司机的转化率用于指示司机成单量与接单量的比例。将转化率最高的司机的响应信息作为第二订单应答，可以保证向用户推荐的第二订单应答具有较高成单的可能性，更加智能地推荐了用户很可能接受的第二订单应答，提高了用户体验。

可选择，在第三种实现方式中，在一个或多个响应信息中确定至少一个响应信息作为第二订单应答，包括：将第一个接收到的响应信息作为第二订单应答。将第一个接收到的响应信息直接作为第二订单应答推送给用户，保证了最快的响应速度，进一步减少了用户等待时间，提高了用户体验。

可选择，在第四种实现方式中，在一个或多个响应信息中确定至少一个响应信息作为第二订单应答，包括：将一个或多个响应信息中报价最低的响应信息作为第二订单应答。向用户推送报价最低的响应信息，可以减少用户开销，在控制预算的前提下，减少用户等待时间，提高了用户体验。

需要说明的是，报价和转化率可以结合起来综合考虑，然后选择一个响应信息，例如，对报价和转化率进行加权计算，得到一个匹配参数，依据匹配参数，将匹配参数最高的响应信息作为第二订单应答，其中，转化率的权值可以是正数，报价的权值可以是负数。当然，此处只是示例性说明。

另外，还需要说明的是，第二订单请求如果长时间没有响应，则可以重新发起新一轮快走流程，可选地，在一个实施例中，向第二订单请求包含的各个运力服务商的运力服务平台发送第二订单请求之后，该方法还包括：在第二订单请求的呼叫时长大于或等于预设间隔时长时，触发新一轮快走流程，向第二订单请求包含的各个运力服务商的运力服务平台重新发送第二订单请求。预设间隔时长可以自行设定，例如，预设间隔时长可以是30秒、1分钟、2分钟等，如果当前这一轮的第二订单请求在预设间隔时长之内没有响应，则发起新一轮的快走流程，这样就可以实现多轮快走，不断发起快走流程，加快成单速度，减少用户等待时间。

步骤205、若监听到第二订单应答且未监听到第一订单请求的第一订单应答时，展示第二订单应答。

需要说明的是，在接收到第二订单应答之后，需要确认此时是否接收到了第一订单请求的第一订单应答，如果接收到第一订单应答，则说明有司机已经对第一订单请求接单，不需要继续执行快走流程，如果未接收到第一订单应答，则可以继续快走流程。例如，在一个实施例中，该方法还包括：监听是否接收到对于第一订单请求的第一订单应答；在接收到第一订单应答时，取消第二订单请求。示例性地，可以周期性判断是否接收到第一订单请求的应答，保证了以第一订单请求为主，避免第二订单请求和第一订单请求相冲突，如果接收到第一订单应答，则取消第二订单请求，减少网络资源的浪费。需要说明的是，如果网约车聚合服务平台是平台服务器，则网约车聚合服务平台可以在确定未接收到对于第一订单请求的第一订单应答时，向用户使用的终端设备发送第二订单应答，通过终端设备向用户展示第二订单应答；如果网约车聚合服务平台是终端设备，则在确定未接收到对于第一订单应答时，通过显示屏向用户展示第二订单应答。

步骤206、响应于针对第二订单应答的确认操作时，建立网约车服务订单。

建立网约车服务订单后，可以取消第一订单请求，在本申请中，建立网约车服务订单即为将第二订单请求和第二订单应答进行绑定，也可以称为绑单，同理，对于任何一个订单，在将订单请求和订单应答进行绑定，即绑单的过程，都可以称为建立服务订单。需要说明的是，如果网约车聚合服务平台是平台服务器，则网约车聚合服务平台可以通过接收终端设备的确认信息，以此确定用户对第二订单的确认操作，并建立网约车服务订单；如果网约车聚合服务平台是终端设备，则网约车聚合服务平台直接检测用户操作，在检测用户对第二订单应答的确认操作时，建立网约车服务订单。用户对第二订单应答的确认操作可以是点击确认按键，该确认按键可以是实体按键也可以是触摸屏上的虚拟按键。

结合图1所示的场景，基于上述步骤201-205的描述，此处，列举另一个具体的场景对步骤201-205所描述的订单数据处理方法进一步进行详细说明。如果网约车聚合服务平台是平台服务器，则用户通过终端设备完成交互，终端设备通过向网约车聚合服务平台传输信息反馈用户操作；如果网约车聚合服务平台是终端设备，则网约车聚合服务平台需要通过平台服务器与各运力服务商的服务平台进行交互；或者，网约车聚合服务平台可以包括终端设备和平台服务器，由终端设备和平台服务器各执行一部分功能以实现本申请所提供的订单数据处理方法。这几种实现方式中，订单数据处理方法的技术方案都是相同的，只不过是执行主体不同，可以理解到，如果只是改变执行主体，将本申请提供的订单数据处理方法由多个设备执行，或者由本申请说明书中没有示例性列举的设备执行，均属于本申请的保护范围之内。终端设备和平台服务器均可以单独实现本申请的订单数据处理方法，此处，以终端设备和平台服务器协作执行订单数据处理方法为例进行示例性说明，即网约车聚合服务平台包括终端设备和平台服务器。平台服务器可以向终端设备推送多个运力服务商提供的网络约车服务，本申请中的预设平台可以是一种聚合平台，在用户进行网络约车之前，可以进行相关设置，如图3所示，图3为本申请实施例一提供的一种用户设置示意图。用户可以在如图3所示的界面设置是否开启快走，如果选择开启快走，则在第一订单请求的呼叫时长超过预设的时长阈值时，进入快走流程，如果选择不开启快走，则不会进入快走流程；用户还可以设置预设的时长阈值，即设置第一订单请求的呼叫时长超过多长时间未应答时，进入快走流程，预设的时长阈值可以设置为1分钟、5分钟、10分钟等，用户可以自行设定；用户还可以设置是否开启多轮快走，如果开启多轮快走，则在发送了第二订单请求后，如果超过预设间隔时长没有收到应答，则重新发起新一轮快走，如果不开启多轮快走，则只发送一次第二订单请求；用户还可以设置预设间隔时长，即两轮快走之间的间隔时长；还可以设置第二订单金额(即第二订单请求的金额)范围，例如，第二订单金额是第一订单金额(即第一订单请求的金额)的m-n倍，n大于m，m和n均为大于0的数，设定第二订单金额范围，可以在触发快走流程时，由设备根据设定的第二订单金额范围自动计算出用户可接受的报价范围，并以此确定推送第二订单请求的运力服务商。当然，用户也可以不进行设定，一部分设定也可以在触发快走流程后进行设定，此处只是示例性说明。

基于上述说明，图4为本申请实施例一提供的另一种订单数据处理方法的场景示意图，该场景示出了用户401、终端设备402、平台服务器403、运力服务商的服务平台404，以及司机端405。结合图4所示，用户进行网络约车时，可以在终端设备402显示的订单填写页面填写/设置起点和目的地，还可以设置出发时间(出发时间可以设定为当前时间)，用户还可以在推送的多个运力服务商中进行勾选，选择希望提供服务的运力服务商，用户填写好之后，可以点击呼叫车辆，终端设备根据用户填写的内容创建第一订单请求，并将第一订单请求发送至平台服务器，平台服务器将第一订单请求发送至用户选择的运力服务商的运力服务平台。图4中，以用户选择运力服务商A为例，运力服务商A的运力服务平台向司机端发送第一订单请求，如果有司机接单，则出订单创建成功，用户等待司机来接即可。平台服务器在第一订单请求的呼叫时长超过预设的时长阈值时，创建第二订单请求，或者，可以向终端设备发送提示信息，终端设备向用户展示提示信息，提示用户是否进入快走流程，如果用户选择进入快走流程，则终端设备向平台服务器返回进入快走流程的确认信息，平台服务器创建第二订单请求。平台服务器将第二订单请求发送至第二订单请求包含的运力服务商的服务平台，图4中，以运力服务商B和运力服务商C为例，收到第二订单请求的运力服务商B和运力服务商C的服务平台，向司机端推送第二订单请求，如果有司机在司机端接受第二订单请求，以运力服务商B的司机为例，司机端向对应的运力服务商B的服务平台返回对于第二订单的响应信息，运力服务商B的服务平台向平台服务器发送该响应信息。平台服务器如果接收到多个响应信息，则可以在多个响应信息中选择至少一个响应信息作为第二订单应答，在平台服务器创建第二订单请求到获取到第二订单应答的过程中，监听是否收到第一订单请求的第一订单应答，如果接收到第一订单请求的应答，则取消第二订单请求。如果没有接收到第一订单请求的应答，则平台服务器向终端设备发送第二订单应答，终端设备向用户展示第二订单应答，由用户决定是否选择第二订单应答，如果终端设备检测到用户对第二订单应答的确认操作时，向平台服务器发送用户对第二订单进行确认操作的确认信息，用户对第二订单应答的确认操作可以是用户点击确认按键，如果用户需要取消，则点击取消按键。平台服务器建立第二订单，并取消第一订单请求，通过运力服务商的服务平台，向对应的司机端发送成单指令司机端根据成单指令向司机显示第二订单，或者，平台服务器直接发送第二订单，当然，平台服务器也可以向终端设备发送第二订单，或者，终端设备在检测到用户对于第二订单应答的确认操作时，向用户显示第二订单。

本申请实施例提供的订单数据处理方法，监听第一订单请求的呼叫时长；当呼叫时长超过预设的时长阈值时，创建第二订单请求，第二订单请求包括第一订单请求中未包含的运力服务商；向第二订单请求包含的运力服务商的运力服务平台发送第二订单请求；监听运力服务商的运力服务平台是否返回与第二订单请求匹配的第二订单应答；若监听到第二订单应答且未监听到第一订单请求的第一订单应答时，展示第二订单应答；响应于针对第二订单应答的确认操作时，建立网约车服务订单。第一订单请求超过预设的时长阈值没有应答，表明第一订单请求中包含的运力服务商短时间内未能向用户提供服务，而第二订单请求包含了第一订单请求中未包含的运力服务商，利用第二订单请求可以向用户推荐用户未选择的运力服务商的应答，可以避免用户等待过长时间，而且用户可以对第二订单应答选择是否确认，即用户可以选择第二订单应答，也可以选择继续等待第一订单请求的应答，用户选择更加灵活，提高了用户体验。

实施例二

基于上述实施例一所描述的方法，本申请实施例二提供一种网约车聚合服务平台，用于执行上述实施例一所描述的方法，该网约车聚合服务平台可以是例如服务器等的网络设备，参照图5所示，该网约车聚合服务平台50包括：

监听模块501，用于监听第一订单请求的呼叫时长；

触发模块502，用于当呼叫时长超过预设的时长阈值时，创建第二订单请求，第二订单请求包括第一订单请求中未包含的运力服务商；

发送模块503，用于向第二订单请求包含的运力服务商的运力服务平台发送第二订单请求；

监听模块501，还用于监听运力服务商的运力服务平台是否返回与第二订单请求匹配的第二订单应答；

订单管理模块504，用于若监听到第二订单应答且未监听到第一订单请求的第一订单应答时，展示第二订单应答；

订单确认模块505，用于响应于针对第二订单应答的确认操作时，建立网约车服务订单。

可选地，在本申请的一个实施例中，监听模块501，用于接收多个运力服务商的运力服务平台返回的，对于第二订单请求的一个或多个响应信息；在一个或多个响应信息中确定至少一个响应信息作为第二订单应答。

可选地，在本申请的一个实施例中，监听模块501，用于基于响应信息对应的运力端的服务质量参数，选择至少一个响应信息作为第二订单应答。

可选地，在本申请的一个实施例中，触发模块501，用于根据第一订单请求中包含的行程信息建立第二订单请求；对于第一订单请求未包含的至少一个运力服务商，将报价与第一订单请求的报价的比例小于或等于预设比例的运力服务商，加入第二订单请求。

可选地，在本申请的一个实施例中，触发模块501，用于当第一订单请求的呼叫时长超过时长阈值，且第一订单请求无应答时，提示用户是否触发第二订单请求；在检测到用户对于第二订单请求的触发操作时，创建第二订单请求。

可选地，在本申请的一个实施例中，订单管理模块504，还用于监听是否接收到对于第一订单请求的第一订单应答；在接收到第一订单时，取消第二订单请求。

本申请实施例提供的网约车聚合服务平台，监听第一订单请求的呼叫时长；当呼叫时长超过预设的时长阈值时，创建第二订单请求，第二订单请求包括第一订单请求中未包含的运力服务商；向第二订单请求包含的运力服务商的运力服务平台发送第二订单请求；监听运力服务商的运力服务平台是否返回与第二订单请求匹配的第二订单应答；若监听到第二订单应答且未监听到第一订单请求的第一订单应答时，展示第二订单应答；响应于针对第二订单应答的确认操作时，建立网约车服务订单。第一订单请求超过预设的时长阈值没有应答，表明第一订单请求中包含的运力服务商短时间内未能向用户提供服务，而第二订单请求包含了第一订单请求中未包含的运力服务商，利用第二订单请求可以向用户推荐用户未选择的运力服务商的应答，可以避免用户等待过长时间，而且用户可以对第二订单应答选择是否确认，即用户可以选择第二订单应答，也可以选择继续等待第一订单请求的应答，用户选择更加灵活，提高了用户体验。

实施例三

基于上述实施例一所描述的方法，本申请实施例三提供一种电子设备，用于执行上述实施例一所描述的方法，参照图6所示，图6为本申请实施例三提供的一种电子设备的结构示意图，本申请具体实施例并不对电子设备的具体实现做限定。

如图6所示，该电子设备可以包括：处理器(processor)602、通信接口(Communications Interface)604、存储器(memory)606、以及通信总线608。

其中：

处理器602、通信接口604、以及存储器606通过通信总线608完成相互间的通信。

通信接口604，用于与其它电子设备如终端设备或服务平台进行通信。

处理器602，用于执行程序610，具体可以执行上述方法实施例中的相关步骤。

具体地，程序610可以包括程序代码，该程序代码包括计算机操作指令。

处理器602可能是处理器CPU，或者是特定集成电路ASIC(Application SpecificIntegrated Circuit)，或者是被配置成实施本申请实施例的一个或多个集成电路。电子设备包括的一个或多个处理器，可以是同一类型的处理器，如一个或多个CPU；也可以是不同类型的处理器，如一个或多个CPU以及一个或多个ASIC。

存储器606，用于存放程序610。存储器606可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。

程序610具体可以用于使得处理器602执行前述实施例一中任一方法。

程序610中各步骤的具体实现可以参见上述订单数据处理方法实施例中的相应步骤和单元中对应的描述，在此不赘述。所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的设备和模块的具体工作过程，可以参考前述方法实施例中的对应过程描述，在此不再赘述。

本申请实施例提供的电子设备，监听第一订单请求的呼叫时长；当呼叫时长超过预设的时长阈值时，创建第二订单请求，第二订单请求包括第一订单请求中未包含的运力服务商；向第二订单请求包含的运力服务商的运力服务平台发送第二订单请求；监听运力服务商的运力服务平台是否返回与第二订单请求匹配的第二订单应答；若监听到第二订单应答且未监听到第一订单请求的第一订单应答时，展示第二订单应答；响应于针对第二订单应答的确认操作时，建立网约车服务订单。第一订单请求超过预设的时长阈值没有应答，表明第一订单请求中包含的运力服务商短时间内未能向用户提供服务，而第二订单请求包含了第一订单请求中未包含的运力服务商，利用第二订单请求可以向用户推荐用户未选择的运力服务商的应答，可以避免用户等待过长时间，而且用户可以对第二订单应答选择是否确认，即用户可以选择第二订单应答，也可以选择继续等待第一订单请求的应答，用户选择更加灵活，提高了用户体验。

实施例四

基于上述实施例一至实施例三所描述的方法和装置，本申请实施例四提供一种网约车服务系统，包括：网约车聚合服务平台和运力服务平台，网约车聚合服务平台和运力服务平台之间相互通信，网约车聚合服务平台为实施例二所描述的网约车聚合服务平台；

或者，网约车聚合服务平台为实施例三所描述的电子设备。

所述网约车聚合服务平台执行本申请实施例所述任意一种的订单数据处理方法

网约车聚合服务平台和至少一个运力服务平台用于执行上述实施例一种所描述的订单数据处理方法，详细解释可以参考实施例一至实施例三的说明，此处不再赘述。

实施例五

基于上述实施例一所描述的方法，本申请实施例五提供一种计算机存储介质，其上存储有计算机程序，该程序被处理器执行时实现如实施例一所描述的方法。

需要指出，根据实施的需要，可将本申请实施例中描述的各个部件/步骤拆分为更多部件/步骤，也可将两个或多个部件/步骤或者部件/步骤的部分操作组合成新的部件/步骤，以实现本申请实施例的目的。

上述根据本申请实施例的方法可在硬件、固件中实现，或者被实现为可存储在记录介质(诸如CD ROM、RAM、软盘、硬盘或磁光盘)中的软件或计算机代码，或者被实现通过网络下载的原始存储在远程记录介质或非暂时机器可读介质中并将被存储在本地记录介质中的计算机代码，从而在此描述的方法可被存储在使用通用计算机、专用处理器或者可编程或专用硬件(诸如ASIC或FPGA)的记录介质上的这样的软件处理。可以理解，计算机、处理器、微处理器控制器或可编程硬件包括可存储或接收软件或计算机代码的存储组件(例如，RAM、ROM、闪存等)，当软件或计算机代码被计算机、处理器或硬件访问且执行时，实现在此描述的订单数据处理方法。此外，当通用计算机访问用于实现在此示出的订单数据处理方法的代码时，代码的执行将通用计算机转换为用于执行在此示出的订单数据处理方法的专用计算机。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及方法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请实施例的范围。

以上实施方式仅用于说明本申请实施例，而并非对本申请实施例的限制，有关技术领域的普通技术人员，在不脱离本申请实施例的精神和范围的情况下，还可以做出各种变化和变型，因此所有等同的技术方案也属于本申请实施例的范畴，本申请实施例的专利保护范围应由权利要求限定。

Claims (10)

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

监听第一订单请求的呼叫时长；

当所述呼叫时长超过预设的时长阈值时，创建第二订单请求，所述第二订单请求包括所述第一订单请求中未包含的运力服务商；

向所述第二订单请求包含的运力服务商的运力服务平台发送所述第二订单请求；

监听所述运力服务平台是否返回与所述第二订单请求匹配的第二订单应答；

若监听到第二订单应答且未监听到所述第一订单请求的第一订单应答时，展示所述第二订单应答；

响应于针对所述第二订单应答的确认操作，建立网约车服务订单。

2.根据权利要求1所述的方法，其中，所述监听所述运力服务平台是否返回与所述第二订单请求匹配的第二订单应答，包括：

接收多个所述运力服务商的运力服务平台返回的，对于所述第二订单请求的一个或多个响应信息；

在所述一个或多个响应信息中确定至少一个所述响应信息作为所述第二订单应答。

3.根据权利要求2所述的方法，其中，所述在所述一个或多个响应信息中确定至少一个所述响应信息作为所述第二订单应答，包括：

基于响应信息对应的运力端的服务质量参数，选择至少一个响应信息作为所述第二订单应答。

4.根据权利要求1所述的方法，其中，所述创建第二订单请求，包括：

根据所述第一订单请求中包含的行程信息建立所述第二订单请求；

对于所述第一订单请求未包含的至少一个运力服务商，将报价与所述第一订单请求的报价的比例小于或等于预设比例的运力服务商，加入所述第二订单请求。

5.根据权利要求1所述的方法，其中，所述当所述呼叫时长超过预设的时长阈值时，创建第二订单请求，包括：

当所述第一订单请求的呼叫时长超过所述时长阈值，且所述第一订单请求无应答时，提示用户是否触发所述第二订单请求；

在检测到用户对于所述第二订单请求的触发操作时，创建所述第二订单请求。

6.根据权利要求1-5中任一项所述的方法，其中，所述方法还包括：

监听是否接收到对于所述第一订单请求的第一订单应答；

在接收到所述第一订单应答时，取消所述第二订单请求。

7.一种电子设备，包括：处理器、存储器、通信接口和通信总线，所述处理器、所述存储器和所述通信接口通过所述通信总线完成相互间的通信；

所述存储器用于存放至少一可执行指令，所述可执行指令使所述处理器执行如权利要求1-6中任一项所述的订单数据处理方法对应的操作。

8.一种计算机存储介质，其上存储有计算机程序，该程序被处理器执行时实现如权利要求1-6中任一所述的订单数据处理方法。

9.一种网约车聚合服务平台，包括：

监听模块，用于监听第一订单请求的呼叫时长；

触发模块，用于当所述呼叫时长超过预设的时长阈值时，创建第二订单请求，所述第二订单请求包括所述第一订单请求中未包含的运力服务商；

发送模块，用于向所述第二订单请求包含的运力服务商的运力服务平台发送所述第二订单请求；

监听模块，还用于监听所述运力服务平台是否返回与所述第二订单请求匹配的第二订单应答；

订单管理模块，用于若监听到第二订单应答且未监听到所述第一订单请求的第一订单应答时，展示所述第二订单应答；

订单确认模块，用于响应于针对所述第二订单应答的确认操作，建立网约车服务订单。

10.一种网约车服务系统，包括：网约车聚合服务平台和运力服务平台，所述网约车聚合服务平台和所述运力服务平台之间相互通信，所述网约车聚合服务平台执行权利要求1-6中任一所述的订单数据处理方法。

Images