CN109426872A - 网约车订单分配方法及终端 - Google Patents

Abstract

本发明提供一种网约车订单分配方法及终端，方法包括：根据所述订单的用户的历史订单数据，检测所述订单的出行起点周围是否存在满足预定条件的可接单司机，所述预定条件包括曾为所述用户服务并且被所述用户给予好评；若存在满足所述预定条件的可接单司机，则从中选择到达所述出行起点所需时间最短的司机作为当前的目标司机，向所述用户推送包括所述目标司机到达所述出行起点所需的时间和包括处于可选状态的个性化选项的确认呼叫界面，以使所述用户确认是否发起叫车业务。通过本方案，能够提高订单分配的准确性和可靠性，同时使得出行服务更加个性化，提高用户体验。

Description

网约车订单分配方法及终端

技术领域

本发明涉及交通领域，尤其涉及一种网约车订单分配方法及终端。

背景技术

随着交通和经济的不断发展，为了更加方便安全地外出，越来越多的用户选择叫车出行。例如，用户参加朋友聚会和商务宴请饮酒后无法自驾出行，就可以通过出行软件请求有偿驾驶劳务活动，即呼叫代驾，或者，用户还可以通过出行软件呼叫出租车。具体的，现有的订单分配方法中，当用户触发叫车业务时，终端默认以用户的出行起点为圆心，以一定的推单距离为半径，确定出行起点周围的区域范围，从该区域范围中随机选取一批司机，并将该用户的订单优先分配给距离用户的出行起点最近的司机。

但是实际应用中，由于不同用户的出行习惯和爱好不同，因此现有的订单分配方案为用户分配的司机并不一定是能够满足用户服务要求的司机，其分配结果无法针对用户需求实现准确分配，往往无法满足需要优质服务或个性化服务的用户的要求。

发明内容

本发明提供一种网约车订单分配方法及终端，用于解决现有的订单分配方案无法针对用户需求实现准确分配的问题。

本发明的第一个方面是提供一种网约车订单分配方法，包括：根据所述订单的用户的历史订单数据，检测所述订单的出行起点周围是否存在满足预定条件的可接单司机，所述预定条件包括曾为所述用户服务并且被所述用户给予好评；若存在满足所述预定条件的可接单司机，则从中选择到达所述出行起点所需时间最短的司机作为当前的目标司机，向所述用户推送包括所述目标司机到达所述出行起点所需的时间和包括处于可选状态的个性化选项的确认呼叫界面，以使所述用户确认是否发起叫车业务。

本发明的另一个方面是提供一种终端，包括：检测模块，用于根据所述订单的用户的历史订单数据，检测所述订单的出行起点周围是否存在满足预定条件的可接单司机，所述预定条件包括曾为所述用户服务并且被所述用户给予好评；交互模块，用于若存在满足所述预定条件的可接单司机，则从中选择到达所述出行起点所需时间最短的司机作为当前的目标司机，向所述用户推送包括所述目标司机到达所述出行起点所需的时间和包括处于可选状态的个性化选项的确认呼叫界面，以使所述用户确认是否发起叫车业务。

本发明提供的网约车订单分配方法及终端，当多个用户需要出行叫车时，根据用户的历史订单数据，检测所述订单的出行起点周围是否存在曾为所述用户服务并且被所述用户给予好评的优选司机，如果存在则将这些司机当前到达出行起点所需时间中的最短时间告知给用户，并为用户提供可选的个性化选项，如果用户勾选该选项并确认叫车，则将该用户的本次订单推送给相应能够最快到达出行起点的司机，由于优选司机是基于用户的历史订单数据筛选出来的，因此能够真实可靠地反映用户对出行服务的需求和要求，为其相应分配的司机也更能满足用户的要求，从而提高订单分配的准确性和可靠性，同时使得出行服务更加个性化，提高用户体验。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1A～图1E为本发明实施例一提供的网约车订单分配方法的流程示意图；

图2A～图2D为本发明实施例二提供的终端的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

图1A为本发明实施例一提供的一种网约车订单分配方法的流程示意图，如图1A所示，本实施例以该网约车订单分配方法应用于终端来举例说明，该方法包括：

101、根据订单的用户的历史订单数据，检测所述订单的出行起点周围是否存在满足预定条件的可接单司机。

102、若存在满足所述预定条件的可接单司机，则从中选择到达所述出行起点所需时间最短的司机作为当前的目标司机，向所述用户推送包括所述目标司机到达所述出行起点所需的时间和包括处于可选状态的个性化选项的确认呼叫界面，以使所述用户确认是否发起叫车业务。

实际应用中，所述终端可以为具备通信和人机交互功能的任意设备，例如，所述终端可以包括但不限于智能手机、电脑等。

其中，所述预定条件用于反映用户的服务需求，具体的，所述预定条件可以包括曾为所述用户服务并且被所述用户给予好评。本方案中，基于用户在历史出行订单中对司机的评价，可以真实准确地反映出用户的出行习惯和喜好，并且用户可以根据当前需要等待的最短时间判断是否继续发起叫车业务，从而准确把握用户的服务要求，实现有针对性地订单分配。这里的好评指的是用户对某次出行订单中接单司机的评价达到一定良好度要求的评价，例如，五星评价。

可选的，在筛选可接单司机时，还可以预先判断司机当前是否能够接单，例如，司机当前是否处于听单状态，相应的，所述预定条件还可以包括司机当前处于听单状态。这里的听单状态指的是司机能够通过司机端实时在线接收到向其推送的消息。例如，司机端实时接收各用户发起的订单，司机根据接收到的推送订单决定自己希望接受的订单，司机接单后即建立起该司机与订单对应的发起用户之间的出行服务关系。

结合实际场景举例来说：实际应用中，101的触发场景可以有多种，即只要检测到用户当前可能需要发起叫车业务，则触发执行101。举例来说，当检测到用户打开某出行软件时，或者在某出行软件的叫车界面下输入出行起点或出行终点时，均可判定用户当前可能需要发起叫车业务。此时，为该用户生成网约车订单，并根据用户的历史订单数据，检测所述订单的出行起点周围是否存在满足预定条件的司机，其中，订单的出行起点可以由用户手动输入，或者无需用户输入，直接将用户当前的位置作为订单的出行起点。如果出行起点周围存在满足预定条件的司机，则进一步向用户确认是否确实发起叫车业务，具体的，可以从所述满足预定条件的司机中确定出到达所述出行起点所需时间最短的司机，并记录该司机到达出行起点所需的时间，向用户推送包括该最短时间的确认呼叫界面，以使用户在该确认呼叫界面下确认是否发起叫车业务，具体的，该确认呼叫界面中还设置有个性化选项，假设出行起点周围存在满足预定条件的司机，则设置该个性化选项的状态为可选状态，即用户可以选中该选项；假设用户勾选该个性化选项，则说明用户能够接受需要等待的最短时间并希望实现准确有效的个性化服务，相应的，当用户在确认呼叫界面下输入确认指令并且同时所述个性化选项为被选中的状态，则将该订单推送给当前的目标司机，即当前满足预定条件的司机中到达出行起点耗时最短的司机。

本方案中基于用户的历史订单、预定条件以及司机到达出行起点所需的时间对用户周围的司机进行筛选，筛选出的司机能够更好地满足用户的服务要求，从而提高订单分配的准确性和可靠性，实现个性化订单分配，使得出行服务更加个性化且贴心，提升用户对出行服务预期的稳定性和用户体验，同时也能够激励司机提供更优质的服务。

可选的，订单的出行起点周围的区域可以参照多种方法确定。举例来说，可以以出行起点为中心，预设的推单距离为半径确定出行起点周围的区域。相应的，在该区域内检测是否存在满足预定条件的司机。

进一步的，如果用户愿意接受当前推送的司机给予的出行服务，则可基于确认呼叫界面，发起叫车业务，相应的，如图1B所示，在实施例一的基础上，所述方法还可以包括：

103、若接收到所述用户在所述确认呼叫界面下输入的确认指令且所述个性化选项被选中，则所述订单推送给所述目标司机。

具体的，当用户在确认呼叫界面下输入确认指令并且同时所述个性化选项为被选中的状态，则将该用户的网约车订单推送给当前的目标司机。具体的，向目标司机推送订单的方式可以有多种，例如，强派单或派独享单，以保证这些司机能够接收到用户的订单，从而进一步判断是否接单。具体的，司机到达出行起点所需时间的估算方法可以有多种，例如，可以基于司机的当前位置、当前的行驶速度以及相关路况和出行起点的位置进行预估计算，本实施例在此不再具体限定和阐述。

此外，假设当前出行起点周围没有满足上述预定条件的司机，则无法为用户提供个性化出行服务。相应的，在实施例一的基础上，在101之后，所述方法还可以包括：若出行起点周围不存在满足所述预定条件的司机，则向所述用户推送包括处于不可选状态的个性化选项的确认呼叫界面，并提示所述用户当前周围没有满足所述预定条件的司机。

以实际场景举例来说：当检测到用户当前可能需要发起叫车业务时，根据用户的历史订单数据，检测出行起点周围是否存在满足预定条件的司机。如果出行起点周围没有满足预定条件的司机，则转入普通叫车流程，具体的，仍进一步向用户确认是否确实发起叫车业务，即可以向用户推送确认呼叫界面，以使用户在该确认呼叫界面下确认是否发起叫车业务，与前述实施方式不同的是，该确认呼叫界面中虽设置有个性化选项，但该个性化选项的状态为不可选状态，即用户不能选中该选项。具体的，可以将该个性化选项置灰不可用，并提示用户当前周围没有满足预定条件的司机。具体的提示方式可以有多种，例如，弹出窗口显示“附近暂无符合条件的司机”，以告知用户附近没有满足预定条件的司机。后续，用户可以选择仍然继续按照现有的叫车流程叫车，即不选中个性化选项，只在确认叫车界面下输入确认指令进行叫车，或者，进行等待直至周围出现满足预定条件的司机时，选中个性化选项的同时在确认叫车界面下发起叫车业务。

具体的，个性化选项的状态取决于出行起点周围是否存在满足预定条件的司机。因此，个性化选项的状态可以根据当前出行起点周围是否存在满足预定条件的司机进行实时更新和切换，这里的状态包括可选状态和不可选状态。其中，个性化选项的显示方式也可以有多种，例如，个性化选项的内容显示为“选您好评过的司机”。

举例来说，假设车主王先生曾使用过代驾服务，上次为他提供过代驾服务的司机是吴师傅。在上次的代驾服务中，王先生对代驾司机吴师傅的整体服务特别满意，评价时主动选择了五星评价。本次车主王先生打开出行软件触发代驾服务，例如，确认代驾的起点和终点后，终端检测到吴师傅在起点周围的区域范围内，且状态为“上班听单中”。此时车主王先生便可使用“选您好评过的司机”功能选项，勾选该功能选项后，假设吴师傅到达起点所需的时间最短，终端将会优先派单给代驾司机吴师傅，吴师傅将优先再次为车主王先生提供代驾服务。

具体的，推送订单后需要根据接单情况进行进一步操作。一种场景为，目标司机接受向其推送的订单，如图1C所示，图1C为本发明实施例一提供的另一种网约车订单分配方法的流程示意图，在图1B所示实施方式的基础上，在103之后，还可以包括：

104、若所述目标司机接受所述订单，则将所述订单分配给所述目标司机。

以实际场景举例来说：检测到出行起点周围存在满足预定条件的司机，并将用户的订单推送给目标司机后，如果目标司机接受该订单，则将订单分配给目标司机，进入正常出行服务流程，以建立本次用户与目标司机之间的出行服务关系。具体的，司机接受订单的方式可以有多种，例如，通过触控交互界面点击确认，或者通过语音指令确认、司机也可以设置自动接单等。

进一步的，将用户订单分配给目标司机后，可以根据出行服务的进行状态更新出行订单的状态，用户也可以对订单进行查询。相应的，如图1D所示，图1D为本发明实施例一提供的另一种网约车订单分配方法的流程示意图，在图1C所示实施方式的基础上，在104之后，还可以包括：

105、根据用户的订单查询请求，在电子地图中显示被分配所述订单的司机的实时位置，预估并显示所述司机抵达出行起点所需的时间；

106、以卡片的形式显示所述订单的订单信息，以标签的形式在所述卡片中展示所述用户对所述司机的历史评价数据，所述订单信息包括司机详情。

具体的，目标司机接单后，可以根据出行服务的进行状态更新出行订单的状态，例如“已为您安排司机”、“司机正赶往出行起点”、“到达目的地，待支付”等。当用户需要查询订单状态时，可以输入订单查询请求的指令，例如，点击订单查询的选项，终端根据用户的订单查询请求，可以结合电子地图，在地图中显示司机的实时位置，同时还可以预估并标注出司机抵达出行起点所需的时间、以及司机当前至出行起点的距离，以便用户合理安排时间。具体的，订单信息可以以卡片的形式直观展示给用户，例如订单编号、司机详情、通常支持的功能选项(取消订单、发送消息等)。另外，本方案中基于用户的历史订单数据为用户分配司机，因此在订单状态中，还可以展示出用户与司机之间历史建立的服务记录。具体的，可以以标签的形式在订单信息的卡片中展示用户对司机的历史评价数据，例如，在司机详情的附近显示“您好评过2次”的标签。

此外，实际应用中的另一种场景为，目标司机拒绝向其推送的订单，为了提高订单分配的可靠性，如图1E所示，图1E为本发明实施例一提供的又一种网约车订单分配方法的流程示意图，在前述任一实施方式的基础上，在103之后，还可以包括：

107、若所述目标司机拒绝所述订单，则从除所述目标司机以外的满足预定条件的其他司机中确定出当前到达所述出行起点所需时间最短的司机并将其作为当前的目标司机，返回执行103中所述将所述订单推送给所述目标司机的步骤。

以实际场景举例来说：检测到出行起点周围存在满足预定条件的司机后，将用户的订单推送给这些司机中到达出行起点所需时间最短的目标司机，如果当前的目标司机接受该订单，则将订单分配给该司机，进入正常出行服务流程；但如果当前的目标司机拒绝接单，例如，司机当前都正在执行其它订单无法再接受该订单，则为了保证出行服务的可靠性，此时重新统计满足预定条件的司机中，除该目标司机以外的其他司机到达出行起点所需的时间，并将其中花费时间最短的司机更新为当前的目标司机，并向当前更新后的目标司机推送用户的订单。

其中，司机拒绝订单的方式也可以有多种。举例来说，司机可以明示拒绝接单，具体的，司机可以点击交互界面中的拒绝选项，或者通过语音指令(例如司机说出“拒绝接单”)来拒绝向其推送的订单，或者司机根据当前的实际情况设置自动拒绝接单等；再举例来说，司机还可以默示拒绝接单，具体的，若在向目标司机推送订单后的一定时长内，司机一直都没有接受订单，则视为司机拒绝该订单。

实际应用中，除了上述实施方式中根据司机到达出行起点所需的时间来确定订单推动的目标司机外，当最短时间对应的司机有多个时，还可以由用户自主选择希望的服务提供者或者基于其它优选策略进行自动选取。相应的，本发明实施例一提供又一种网约车订单分配方法，在前述任一实施方式的基础上，在103之前，该方法还可以包括：

若所述目标司机的数量为多个，则将所述多个目标司机的司机详情推送给所述用户进行选择；根据所述用户的选择结果，将所述用户选择的司机作为当前的目标司机；或者，

若所述目标司机的数量为多个，则将其中距离所述出行起点最近的司机作为当前的目标司机。

以实际场景举例来说：假设当前用户周围有多个满足预定条件且用时最短并且相同的司机，则可以从这几个司机中进一步选取出需要向其推送该用户订单的司机。选取的策略可以根据情况和需要设定，例如，可以参照各司机与出行起点之间的距离优选距离最近的司机作为当前推送的目标司机；或者，也可以将接单的多个司机的信息推送给用户，由用户来决定和选择当前需要推送的目标司机。这里所说的多个司机的信息可以包括司机的驾龄、被评价历史数据等。本实施方式在实现个性化出行服务的同时，考虑各种实际场景，保证出行服务的可靠性。

本实施例提供的网约车订单分配方法，当多个用户需要出行叫车时，根据用户的历史订单数据，检测所述订单的出行起点周围是否存在曾为所述用户服务并且被所述用户给予好评的优选司机，如果存在则将这些司机当前到达出行起点所需时间中的最短时间告知给用户，并为用户提供可选的个性化选项，如果用户勾选该选项并确认叫车，则将该用户的本次订单推送给相应能够最快到达出行起点的司机，由于优选司机是基于用户的历史订单数据筛选出来的，因此能够真实可靠地反映用户对出行服务的需求和要求，为其相应分配的司机也更能满足用户的要求，从而提高订单分配的准确性和可靠性，同时使得出行服务更加个性化，提高用户体验。

图2A为本发明实施例二提供的一种终端的结构示意图，如图2A所示，该终端包括：

检测模块21，用于根据所述订单的用户的历史订单数据，检测所述订单的出行起点周围是否存在满足预定条件的可接单司机；

交互模块22，用于若存在满足所述预定条件的可接单司机，则从中选择到达所述出行起点所需时间最短的司机作为当前的目标司机，向所述用户推送包括所述目标司机到达所述出行起点所需的时间和包括处于可选状态的个性化选项的确认呼叫界面，以使所述用户确认是否发起叫车业务。

实际应用中，所述终端可以为具备通信和人机交互功能的任意设备，例如，所述终端可以包括但不限于智能手机、电脑等。

其中，所述预定条件用于反映用户的服务需求，具体的，所述预定条件可以包括曾为所述用户服务并且被所述用户给予好评。本方案中，基于用户在历史出行订单中对司机的评价，可以真实准确地反映出用户的出行习惯和喜好，并且用户可以根据当前需要等待的最短时间判断是否继续发起叫车业务，从而准确把握用户的服务要求，实现有针对性地订单分配。

可选的，在筛选可接单司机时，还可以预先判断司机当前是否能够接单，例如，司机当前是否处于听单状态，相应的，所述预定条件还可以包括司机当前处于听单状态。这里的听单状态指的是司机能够通过司机端实时在线接收到向其推送的消息。例如，司机端实时接收各用户发起的订单，司机根据接收到的推送订单决定自己希望接受的订单，司机接单后即建立起该司机与订单对应的发起用户之间的出行服务关系。

结合实际场景举例来说：实际应用中，检测模块21的触发场景可以有多种，即只要检测到用户当前可能需要发起叫车业务，则为该用户生成网约车订单，并触发检测模块21执行相关步骤。检测模块21根据用户的历史订单数据，检测所述出行起点周围是否存在满足预定条件的司机，其中，出行起点可以由用户手动输入，或者无需用户输入，直接将用户当前的位置作为出行起点。如果出行起点周围存在满足预定条件的司机，交互模块22向用户推送确认呼叫界面，以使用户在该确认呼叫界面下确认是否发起叫车业务，具体的，交互模块22可以从所述满足预定条件的司机中确定出到达所述出行起点所需时间最短的司机，并用户推送包括该最短时间和个性化选项的确认呼叫界面。

本方案中基于用户的历史订单、预定条件以及司机到达出行起点所需的时间对用户周围的司机进行筛选，筛选出的司机能够更好地满足用户的服务要求，从而提高订单分配的准确性和可靠性，实现个性化订单分配，使得出行服务更加个性化且贴心，提升用户对出行服务预期的稳定性和用户体验，同时也能够激励司机提供更优质的服务。

可选的，出行起点周围的区域可以参照多种方法确定。举例来说，可以以出行起点为中心，预设的推单距离为半径确定出行起点周围的区域。相应的，在该区域内检测是否存在满足预定条件的司机。

进一步的，如果用户愿意接受当前推送的司机给予的出行服务，则可基于确认呼叫界面，发起叫车业务，相应的，如图2B所示，在实施例二的基础上，所述终端还可以包括：

推送模块23，用于若接收到所述用户在所述确认呼叫界面下输入的确认指令且所述个性化选项被选中，则将所述订单推送给所述目标司机。

具体的，当用户在确认呼叫界面下输入确认指令并且同时所述个性化选项为被选中的状态，则推送模块23将该订单推送给满足预定条件的司机。具体的，推送模块23向筛选出的司机推送订单的方式可以有多种，例如，强派单或派独享单，以保证目标司机能够接收到用户的订单，从而进一步判断是否接单。

此外，假设当前出行起点周围没有满足上述预定条件的司机，则无法为用户提供个性化出行服务。相应的，在实施例二的基础上，交互模块22，还用于若不存在，则向所述用户推送包括处于不可选状态的个性化选项的确认呼叫界面，并提示所述用户当前周围没有满足所述预定条件的司机。

以实际场景举例来说：当检测到用户当前可能需要发起叫车业务时，检测模块21根据用户的历史订单数据，检测所述出行起点周围是否存在满足预定条件的司机。如果出行起点周围没有满足预定条件的司机，则转入普通叫车流程，具体的，仍进一步向用户确认是否确实发起叫车业务，即交互模块22可以向用户推送确认呼叫界面，以使用户在该确认呼叫界面下确认是否发起叫车业务，与前述实施方式不同的是，该确认呼叫界面中虽设置有个性化选项，但该个性化选项的状态为不可选状态，即用户不能选中该选项。具体的，可以将该个性化选项置灰不可用，并提示用户当前周围没有满足预定条件的司机。

具体的，交互模块22推送的确认叫车界面中，个性化选项的状态取决于出行起点周围是否存在满足预定条件的司机。因此，个性化选项的状态可以根据当前出行起点周围是否存在满足预定条件的司机进行实时更新和切换，这里的状态包括可选状态和不可选状态。其中，个性化选项的显示方式也可以有多种，例如，个性化选项的内容显示为“选您好评过的司机”。

具体的，推送订单后需要根据接单情况进行进一步操作。一种场景为，目标司机接受向其推送的订单，如图2C所示，图2C为本发明实施例二提供的另一种终端的结构示意图，在图2B所示实施方式的基础上，所述终端还可以包括：

订单分配模块24，用于若所述目标司机接受所述订单，则将所述订单分配给所述目标司机。

以实际场景举例来说：推送模块23将用户的订单推送给目标司机后，如果目标司机接受该订单，则将订单分配给目标司机，进入正常出行服务流程，以建立本次用户与目标司机之间的出行服务关系。具体的，目标司机接受订单的方式可以有多种，例如，通过触控交互界面点击确认，或者通过语音指令确认、司机也可以设置自动接单等。

进一步的，将用户订单分配给目标司机后，可以根据出行服务的进行状态更新出行订单的状态，用户也可以对订单进行查询。相应的，如图2D所示，图2D为本发明实施例二提供的另一种终端的结构示意图，在图2C所示实施方式的基础上，所述终端还可以包括：

订单查询模块25，用于根据用户的订单查询请求，在电子地图中显示被分配所述订单的司机的实时位置，预估并显示所述司机抵达所述出行起点所需的时间；

订单查询模块25，还用于以卡片的形式显示所述订单的订单信息，以标签的形式在所述卡片中展示所述用户对所述司机的历史评价数据，所述订单信息包括司机详情。

具体的，目标司机接单后，终端可以根据出行服务的进行状态更新出行订单的状态。当用户需要查询订单状态时，可以输入订单查询请求的指令，订单查询模块25根据用户的订单查询请求，可以结合电子地图，在地图中显示目标司机的实时位置，同时还可以预估并标注出目标司机抵达出行起点所需的时间、以及目标司机当前至出行起点的距离，以便用户合理安排时间。具体的，订单信息可以以卡片的形式直观展示给用户，例如订单编号、司机详情、通常支持的功能选项(取消订单、发送消息等)。另外，本方案中基于用户的历史订单数据为用户分配司机，因此在订单状态中，还可以展示出用户与司机之间历史建立的服务记录。具体的，可以以标签的形式在订单信息的卡片中展示用户对司机的历史评价数据。

此外，实际应用中的另一种场景为，目标司机拒绝向其推送的订单，为了提高订单分配的可靠性，在前述任一实施方式的基础上，交互模块22，还用于若所述目标司机拒绝所述订单，则从除所述目标司机以外的满足预定条件的其他司机中确定出当前到达所述出行起点所需时间最短的司机并将其作为当前的目标司机，并指示推送模块23再次执行所述将所述订单推送给所述目标司机的步骤。

以实际场景举例来说：推送模块23将用户的订单推送给满足预定条件的司机中到达出行起点所需时间最短的目标司机，如果当前的目标司机接受该订单，则订单分配模块24将订单分配给该司机，进入正常出行服务流程；但如果当前的目标司机拒绝接单，例如，司机当前都正在执行其它订单无法再接受该订单，则为了保证出行服务的可靠性，此时交互模块22重新统计满足预定条件的司机中，除该目标司机以外的其他司机到达出行起点所需的时间，并将其中花费时间最短的司机更新为当前的目标司机，并指示推送模块23向当前更新后的目标司机推送用户的订单。

其中，司机拒绝订单的方式也可以有多种。举例来说，司机可以明示拒绝接单，具体的，司机可以点击交互界面中的拒绝选项，或者通过语音指令(例如司机说出“拒绝接单”)来拒绝向其推送的订单，或者司机根据当前的实际情况设置自动拒绝接单等；再举例来说，司机还可以默示拒绝接单，具体的，若在向目标司机推送订单后的一定时长内，司机一直都没有接受订单，则视为司机拒绝该订单。

实际应用中，除了上述实施方式中根据司机到达出行起点所需的时间来确定订单推动的目标司机外，当最短时间对应的司机有多个时，还可以由用户自主选择希望的服务提供者或者基于其它优选策略进行自动选取。相应的，在前述任一实施方式的基础上，所述终端还包括：

筛选模块，用于若所述目标司机的数量为多个，则将所述多个目标司机的司机详情推送给所述用户进行选择；根据所述用户的选择结果，将所述用户选择的司机作为当前的目标司机；或者，若所述目标司机的数量为多个，则将其中距离所述出行起点最近的司机作为当前的目标司机。

以实际场景举例来说：假设当前用户周围有多个满足预定条件且用时最短并且相同的司机，则筛选模块可以从这几个司机中进一步选取出需要向其推送该用户订单的司机。选取的策略可以根据情况和需要设定，例如，可以参照各司机与出行起点之间的距离优选距离最近的司机作为当前推送的目标司机；或者，也可以将接单的多个司机的信息推送给用户，由用户来决定和选择当前需要推送的目标司机。这里所说的多个司机的信息可以包括司机的驾龄、被评价历史数据等。本实施方式在实现个性化出行服务的同时，考虑各种实际场景，保证出行服务的可靠性。

本实施例提供的终端，当多个用户需要出行叫车时，根据用户的历史订单数据，检测出行起点周围是否存在曾为所述用户服务并且被所述用户给予好评的优选司机，如果存在则将这些司机当前到达出行起点所需时间中的最短时间告知给用户，并为用户提供可选的个性化选项，如果用户勾选该选项并确认叫车，则将该用户的本次订单推送给相应能够最快到达出行起点的司机，由于优选司机是基于用户的历史订单数据筛选出来的，因此能够真实可靠地反映用户对出行服务的需求和要求，为其相应分配的司机也更能满足用户的要求，从而提高订单分配的准确性和可靠性，同时使得出行服务更加个性化，提高用户体验。

本发明实施例三提供一种终端，该终端包括：通信接口、存储器和处理器。

存储器，用于存放程序。具体地，程序可以包括程序代码，所述程序代码包括计算机操作指令。存储器可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。

处理器，用于执行存储器存放的程序，以用于：根据所述订单的用户的历史订单数据，检测所述订单的出行起点周围是否存在满足预定条件的可接单司机，所述预定条件包括曾为所述用户服务并且被所述用户给予好评；若存在满足所述预定条件的可接单司机，则从中选择到达所述出行起点所需时间最短的司机作为当前的目标司机，向所述用户推送包括所述目标司机到达所述出行起点所需的时间和包括处于可选状态的个性化选项的确认呼叫界面，以使所述用户确认是否发起叫车业务。

其中，处理器可能是一个中央处理器(Central Processing Unit，简称为CPU)，或者是特定集成电路(Application Specific Integrated Circuit，简称为ASIC)，或者是被配置成实施本发明实施例的一个或多个集成电路。

可选的，在具体实现上，如果通信接口、存储器和处理器独立实现，则通信接口、存储器和处理器可以通过总线相互连接并完成相互间的通信。所述总线可以是工业标准体系结构(Industry Standard Architecture，简称为ISA)总线、外部设备互连(PeripheralComponent，简称为PCI)总线或扩展工业标准体系结构(Extended Industry StandardArchitecture，简称为EISA)总线等。所述总线可以分为地址总线、数据总线、控制总线等，但并不表示仅有一根总线或一种类型的总线。

可选的，在具体实现上，如果通信接口、存储器和处理器集成在一块芯片上实现，则通信接口、存储器和处理器可以通过内部接口完成相同间的通信。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的终端的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。

Claims (12)

1.一种网约车订单分配方法，其特征在于，包括：

根据所述订单的用户的历史订单数据，检测所述订单的出行起点周围是否存在满足预定条件的可接单司机，所述预定条件包括曾为所述用户服务并且被所述用户给予好评；

若存在满足所述预定条件的可接单司机，则从中选择到达所述出行起点所需时间最短的司机作为当前的目标司机，向所述用户推送包括所述目标司机到达所述出行起点所需的时间和包括处于可选状态的个性化选项的确认呼叫界面，以使所述用户确认是否发起叫车业务。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

若接收到所述用户在所述确认呼叫界面下输入的确认指令且所述个性化选项被选中，则将所述订单推送给所述目标司机。

3.根据权利要求2所述的方法，其特征在于，所述将所述订单推送给所述目标司机之后，还包括：

若所述目标司机拒绝所述订单，则从除所述目标司机以外的满足预定条件的其他司机中确定出当前到达所述出行起点所需时间最短的司机并将其作为当前的目标司机，返回执行所述将所述订单推送给所述目标司机的步骤。

4.根据权利要求2所述的方法，其特征在于，所述将所述订单推送给所述目标司机之后，还包括：

若所述目标司机接受所述订单，则将所述订单分配给所述目标司机。

5.根据权利要求4所述的方法，其特征在于，所述将所述订单分配给所述目标司机之后，还包括：

根据用户的订单查询请求，在电子地图中显示被分配所述订单的司机的实时位置，预估并显示所述司机抵达所述出行起点所需的时间；

以卡片的形式显示所述订单的订单信息，以标签的形式在所述卡片中展示所述用户对所述司机的历史评价数据，所述订单信息包括司机详情。

6.根据权利要求1-5中任一项所述的方法，其特征在于，所述根据所述订单的用户的历史订单数据，检测所述订单的出行起点周围是否存在满足预定条件的可接单司机之后，还包括：

若不存在满足所述预定条件的可接单司机，则向所述用户推送包括处于不可选状态的个性化选项的确认呼叫界面，并提示所述用户当前周围没有满足所述预定条件的司机。

7.一种终端，其特征在于，包括：

检测模块，用于根据所述订单的用户的历史订单数据，检测所述订单的出行起点周围是否存在满足预定条件的可接单司机，所述预定条件包括曾为所述用户服务并且被所述用户给予好评；

交互模块，用于若存在满足所述预定条件的可接单司机，则从中选择到达所述出行起点所需时间最短的司机作为当前的目标司机，向所述用户推送包括所述目标司机到达所述出行起点所需的时间和包括处于可选状态的个性化选项的确认呼叫界面，以使所述用户确认是否发起叫车业务。

8.根据权利要求7所述的终端，其特征在于，所述终端还包括：

推送模块，用于若接收到所述用户在所述确认呼叫界面下输入的确认指令且所述个性化选项被选中，则将所述订单推送给所述目标司机。

9.根据权利要求8所述的终端，其特征在于，

所述交互模块，还用于若所述目标司机拒绝所述订单，则从除所述目标司机以外的满足预定条件的其他司机中确定出当前到达所述出行起点所需时间最短的司机并将其作为当前的目标司机，并指示所述推送模块再次执行所述将所述订单推送给所述目标司机的步骤。

10.根据权利要求8所述的终端，其特征在于，所述终端还包括：

订单分配模块，用于若所述目标司机接受所述订单，则将所述订单分配给所述目标司机。

11.根据权利要求10所述的终端，其特征在于，所述终端还包括：

订单查询模块，用于根据用户的订单查询请求，在电子地图中显示被分配所述订单的司机的实时位置，预估并显示所述司机抵达所述出行起点所需的时间；

所述订单查询模块，还用于以卡片的形式显示所述订单的订单信息，以标签的形式在所述卡片中展示所述用户对所述司机的历史评价数据，所述订单信息包括司机详情。

12.根据权利要求7-11中任一项所述的终端，其特征在于，

所述交互模块，还用于若不存在满足所述预定条件的可接单司机，则向所述用户推送包括处于不可选状态的个性化选项的确认呼叫界面，并提示所述用户当前周围没有满足所述预定条件的司机。