CN117252397B - 确定网约车预约订单的接单司机的方法、装置及计算机设备 - Google Patents

Abstract

本申请涉及一种确定网约车预约订单的接单司机的方法、装置及计算机设备。该方法包括：获取乘客的预约订单信息；进行播单匹配；若在第一预设时长内没有匹配到司机，进入静默匹配模式，以及在乘客端展示从目标白名单中选择的司机；在静默匹配模式下，再次进行播单匹配；若匹配到司机，将播单匹配到的司机作为接单司机，并将乘客端展示的司机更换为该司机；若未匹配到司机，且当前时刻与出发时刻的时差不大于第二预设时长，进行派单匹配，将派单匹配到的司机作为接单司机，并将乘客端展示的司机更换为该司机。通过上述方法的步骤，预先向乘客端展示白名单司机，降低了预约单的取消率，并通过静默匹配提高了预约单的完单率。

Description

确定网约车预约订单的接单司机的方法、装置及计算机设备

技术领域

本发明实施例涉及网约车服务技术领域，尤其涉及一种确定网约车预约订单的接单司机的方法、装置及计算机设备。

背景技术

在目前的网约车服务领域中，网约车的司乘匹配方式一般分为派单匹配和播单匹配两类。其中，派单匹配指在乘客下单后系统自动寻找司机派单，播单匹配指在乘客下单后向多个司机展示，让司机自主进行抢单。而且，网约车订单也分为两类，第一类是实时单，指网约车业务中乘客需要立刻出发的订单种类。第二类是预约单，指网约车业务中乘客需要预约未来一段时间再出发的订单种类。其中，预约单因起点和预计出发时间不固定，网约车平台为了降低司机取消率，一般不会采用派单匹配的方式，而是采用播单匹配的方式进行司乘匹配。

然而，发明人意识到，网约车平台在为预约单进行播单匹配时，会存在播单对象不合理以及乘客预期不明确的问题。例如某预约单的出发时间较晚，需要在第二天以及更久之后出发，经常在订单附近活动的司机此刻可能不在播单半径内，这就造成了播单对象不合理的问题。而且，乘客的预约单在尚未收到司机邀约时，往往会缺乏耐心而导致预约单的取消概率偏高，造成了乘客预期不明确的问题。目前业内一般通过延长预约单的播单匹配时长来提高预约单的完单率，但目前看来效果不佳，完单率依然不高。

发明内容

本申请针对上述不足或缺点，提供了一种确定网约车预约订单的接单司机的方法、装置及计算机设备。本申请实施例通过向乘客端预先展示白名单司机的方式，降低了乘客主动取消预约单的概率，并且通过在后台执行静默匹配增强了播单匹配的时长和范围，进而提高了预约单的成单率。

本申请根据第一方面提供了一种确定网约车预约订单的接单司机的方法，包括：

获取乘客的预约订单信息，预约订单信息包括出发时刻；

进行播单匹配；

若在第一预设时长内没有匹配到司机，进入静默匹配模式，以及在乘客端展示从目标白名单中选择的司机；

在静默匹配模式下，执行以下操作：

再次进行播单匹配；若匹配到司机，将播单匹配到的司机作为接单司机，以及将乘客端展示的司机更换为该司机；若未匹配到司机，且当前时刻与出发时刻的时差不大于第二预设时长，根据预约订单信息进行派单匹配，将派单匹配到的司机作为接单司机，以及将乘客端展示的司机更换为该司机。

在一些实施例中，在获取乘客的预约订单信息之前，该方法还包括：

根据乘客的终端位置信息确定目标区域；

获取位于目标区域且符合预设条件的司机的司机信息；

根据获取的司机信息生成目标白名单。

在一些实施例中，在获取乘客的预约订单信息之前，该方法还包括：

根据乘客的终端位置信息确定目标区域；

获取目标区域对应的预先配置的白名单作为目标白名单。

在一些实施例中，预约订单信息还包括订单地址；进行播单匹配，包括：

根据订单地址确定第一区域；

对位于第一区域中的司机进行播单匹配。

在一些实施例中，再次进行播单匹配，包括：

扩大第一区域的范围，得到第二区域，向位于第二区域内的司机进行播单匹配。

在一些实施例中，根据预约订单信息进行派单匹配之后，该方法还包括：

若通过派单匹配没有在第三预设时长内匹配到司机，取消预约订单信息对应的预约订单并通知乘客。

在一些实施例中，进行播单匹配之后，该方法还包括：

若进行播单匹配没有在第一预设时长内匹配到司机，将乘客指定的司机作为所述接单司机。本申请根据另一方面提供了一种确定网约车预约订单的接单司机的装置，该装置包括：

信息获取模块，用于获取乘客的预约订单信息，预约订单信息包括出发时刻；

第一播单模块，用于进行播单匹配；

静默匹配模块，用于在第一预设时长内没有匹配到司机时，进入静默匹配模式，以及在乘客端展示从目标白名单中选择的司机；

静默匹配模块，还用于在静默匹配模式下，执行以下操作：

再次进行播单匹配；若匹配到司机，将播单匹配到的司机作为接单司机，以及将乘客端展示的司机更换为该司机；若未匹配到司机，且当前时刻与出发时刻的时差不大于第二预设时长，根据预约订单信息进行派单匹配，将派单匹配到的司机作为接单司机，以及将乘客端展示的司机更换为该司机。

本申请根据又一方面提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述任一项确定网约车预约订单的接单司机的方法的步骤。

本申请根据又一方面提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现上述任一项确定网约车预约订单的接单司机的方法的步骤。

在上述的本申请实施例中，网约车平台先从乘客的终端设备获取乘客的预约订单信息，预约订单信息一般包括出发时刻和订单地址。然后平台进行播单匹配，若在第一预设时长内没有匹配到司机，令后台进入静默匹配模式，以及在乘客端展示从目标白名单中选择的司机。其中，向用户展示的白名单司机不一定是最终接驾的司机，通过提前向乘客展示白名单司机的方式，改善了乘客的对预约单成交的心理预期，降低了乘客主动取消预约单的概率。在静默匹配模式下，平台再次进行播单匹配；若匹配到司机，将播单匹配到的司机作为接单司机，以及将乘客端展示的司机更换为该司机。通过这样的方式，最终确定出真正接驾的司机，并在不让乘客察觉的情况下将先前展示的白名单司机替换掉，改善了用户使用体验，提高了预约单的完单率。若未匹配到司机，且当前时刻与出发时刻的时差不大于第二预设时长，根据预约订单信息进行派单匹配，将派单匹配到的司机作为接单司机，以及将乘客端展示的司机更换为该司机。综上所述，在上述的本申请实施例中，通过预先向乘客端展示白名单司机的方式，降低了预约单的取消率，并通过静默匹配提高了预约单的完单率。

附图说明

图1为本申请一个或多个实施例中一种确定网约车预约订单的接单司机的方法流程图；

图2为本申请一个或多个实施例中一种预先配置目标白名单的方法流程图；

图3为本申请一个或多个实施例中一种确定目标白名单的方法流程图；

图4为本申请一个或多个实施例中一种执行播单匹配的方法流程图；

图5为本申请一个或多个实施例中一种确定网约车预约订单的接单司机的装置结构示意图；

图6为本申请一个或多个实施例中一种计算机设备的结构示意图；

图7为本申请一个或多个实施例中一种确定网约车预约订单的接单司机的任务全过程流程图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅用以解释本申请，并不用于限定本申请。

本申请提供的确定网约车预约订单的接单司机的方法，可以应用于网约车服务提供商的用于处理出行订单的系统，该系统具体可以为服务商自己搭建的系统，也可以是向SaaS（Software as a Service，软件即服务）平台租用的系统。其中，现今的SaaS云平台通过云原生应用，访问由软件定义的、虚拟化的服务器，云原生应用指专门为了运行在云计算环境中而开发的软件应用。

当前很多网约车服务提供商会入驻SaaS平台以及利用SaaS平台提供的网约车软件来运营网约车业务。其中，网约车司机也可以在网约车服务提供商的系统上开通相关账号即可司机端的注册。然而，乘客一般无需入驻网约车SaaS平台，他们只有在需要打车时以游客身份接入网约车服务提供商的系统中，或者预先在系统上注册相关账号，接入了系统的乘客一般称为乘客端。在下述的实施例中，将网约车服务提供商的用于处理出行订单的系统简称为网约车平台。

本申请根据第一方面提供了一种确定网约车预约订单的接单司机的方法，如图1所示，包括：

S110：获取乘客的预约订单信息，预约订单信息包括出发时刻；

具体地，乘客可以通过终端设备登录网约车应用程序来下预约单，该预约单的订单信息会在乘客端生成后发送至网约车平台。然后，网约车平台获取到的订单信息一般包括该订单行程的出发时刻以及出发地址。

示例性地，某乘客在当日晚上7点钟通过手机登录应用程序预定了明日早上8点出发的预约单，出发地点为北京天坛，此时，相应的订单信息会在乘客端生成后发送至网约车平台。然后，网约车平台获取到的订单信息为：出发时刻为明日早上8点，出发地点为北京天坛。

S120：进行播单匹配；

具体地，网约车平台在接收到订单信息后，将订单信息向距离出发地点特定范围内的司机展示。同时，网约车平台还会对播单匹配进行记时，用于记录播单匹配的执行总时长，直至有司机接单并完成匹配。

在一些实施例中，预约订单信息还包括订单地址；进行播单匹配，如图4所示，该方法包括：

S410：根据订单地址确定第一区域；

S420：对位于第一区域中的司机进行播单匹配。

具体地，订单地址可以为出发地点，即一个特定的方位点，而第一区域可以为以出发地点为圆心，特定方圆半径所围成的圆形区域；或者第一区域也可以是以出发点为中心的各种几何图形区域，例如规则多边形区域、曲边梯形区域等等。

示例性地，网约车平台在当日晚上7点接收到的订单信息为：出发时刻为明日早上8点，出发地点为北京天坛。然后网约车平台在当日晚上7点将订单信息向以北京天坛为中心，方圆10公里范围内的司机展示来进行播单匹配。同时，网约车平台还会根据第一预设时长，假设第一预设时长为2小时，从当日晚上7点钟开始记时；若有司机在当日晚上9点钟之前完成接单，则确定接单司机。若有司机在当日晚上9点钟之后，则进入下一步骤的静默匹配模式。

S130：若在第一预设时长内没有匹配到司机，进入静默匹配模式，以及在乘客端展示从目标白名单中选择的司机；

具体地，第一预设时长为网约车平台或者乘客端自行设定的时长，用于限制播单匹配的时长，第一预设时长的设定范围一般是2-12小时。静默匹配模式一般是网约车平台的后台执行的匹配操作。此外，目标白名单是由网约车平台预先选取的多个司机信息构成的一个名单，该目标白名单中一般包括多个司机的司机信息，其中，司机信息包括对应司机的名称和历史评分。

示例性地，假设第一预设时长设定为3小时，网约车平台从当日晚上7点钟开始记时，直至晚上10点钟依然没有司机接单，则网约车平台令乘客端的手机后台进入静默匹配模式，并且令手机从目标白名单中随机选取一个司机的司机信息通过屏幕向乘客展示。

S140：在静默匹配模式下，执行以下操作：

再次进行播单匹配；若匹配到司机，将播单匹配到的司机作为接单司机，以及将乘客端展示的司机更换为该司机；若未匹配到司机，且当前时刻与出发时刻的时差不大于第二预设时长，根据预约订单信息进行派单匹配，将派单匹配到的司机作为接单司机，以及将乘客端展示的司机更换为该司机。

具体地，第二预设时长为网约车平台或者乘客端自行设定的时长，用于限制播单匹配时长，避免距离出发时刻过近而依然在进行播单匹配，第二预设时长的设定范围一般小于10小时，可以根据具体情况进行设置。假设第二预设时长设定为y小时，乘客的出发时刻为B时（B大于y）。那么网约车平台在B-y时之前仍然进行播单匹配，在B-y时之后，需要进行派单匹配。若在B-y时之前网约车平台通过播单匹配方式匹配到司机，将该司机作为实际接驾的司机，以及将乘客端的终端设备上展示的目标白名单司机更换为该实际接驾的司机。若网约车平台直到B-y时之后也未匹配到司机，则在B-y时之后，B时之前进行派单匹配，将派单匹配到的司机作为实际接驾的司机，以及将乘客端的终端设备上展示的目标白名单司机更换为该实际接驾的司机。

示例性地，假设第二预设时长设定为8小时，乘客的出发时刻为明日早上8点。那么网约车平台在当晚12点之前仍然进行播单匹配，在当晚12点之后，即凌晨至明日早上8点的这段时间内，需要进行派单匹配。若在当晚12点之前通过播单匹配方式匹配到司机，将该司机作为实际接驾的司机，以及将乘客端的终端设备上展示的目标白名单司机更换为该实际接驾的司机。若直到当晚12点之后也未匹配到司机，则在当晚12点之后，明日早上8点之前进行派单匹配，将派单匹配到的司机作为实际接驾的司机，以及将乘客端的终端设备上展示的目标白名单司机更换为该实际接驾的司机。通过上述实施例的方法的步骤，实现了向乘客端预先展示白名单司机信息，降低了乘客主动取消预约单的概率，并且通过在后台执行静默匹配增强了播单匹配的时长和范围，进而提高了预约单的成单率。

在一些实施例中，在获取乘客的预约订单信息之前，如图2所示，该方法还包括：

S210：根据乘客的终端位置信息确定目标区域；

S220：获取位于目标区域且符合预设条件的司机的司机信息；

S230：根据获取的司机信息生成目标白名单。

具体地，终端位置信息包括乘客下预约单时的终端设备的设备地址，一般设备地址与预约单的出发地址重合。其中，设备地址可以为一个特定的方位点，而目标区域可以为一个以设备地址的方位点为圆心，特定方圆半径所围成的圆形区域；或者目标区域也可以是以出发点为中心的各种几何图形区域，例如规则多边形区域、曲边梯形区域等等。预设条件可以以司机的历史评分作为标准，将历史评分高于特定阈值的高分司机视为符合预设条件的司机。其中，司机的历史评分是由网约车平台根据对应司机在之前一段时间内的好评比例，完单率等因素综合评估得出的。一般司机的好评越多，完单率越高，其历史评分就越高。

示例性地，网约车平台在乘客下单之前，获取到乘客端的手机的设备地址为北京天坛。网约车平台将以北京天坛为中心，方圆10公里范围内的圆形区域确定为目标区域。然后，网约车平台获取该圆形区域中司机历史评分高于90分的司机信息。最后将这些获取到的高分司机信息录入目标白名单中，生成包括多个高分司机信息的目标白名单。

在一些实施例中，在获取乘客的预约订单信息之前，如图3所示，该方法还包括：

S310：根据乘客的终端位置信息确定目标区域；

S320：获取目标区域对应的预先配置的白名单作为目标白名单。

具体地，乘客端的终端设备后台可以预先根据目标区域配置白名单。具体地，终端设备后台以终端设备为方位点，将特定的方圆半径范围内的高分司机的司机信息录入白名单中，以供网约车平台调用。

示例性地，网约车平台在乘客下单之前，确定乘客端手机位于北京天坛所在的目标区域内。然后网约车平台获取乘客端手机后台根据北京天坛所在的目标区域生成的白名单，并将该白名单作为目标白名单来使用。其中，乘客端手机后台生成的白名单一般包括多个高分司机的司机信息。

在一些实施例中，再次进行播单匹配，包括：

扩大第一区域的范围，得到第二区域，向位于第二区域内的司机进行播单匹配。

具体地，已知第一区域以出发地点为圆心，特定方圆半径所围成的圆形区域。若将特定方圆半径扩大至第二方圆半径，则得到了面积更大的同心圆第二区域，最后向第二区域内的司机进行播单匹配。或者，假设第一区域为规则多边形区域，则需要通过在经纬度方向上拉长规则多边形的长度和高度来将第一区域扩大为第二区域。

示例性地，网约车平台原本以北京天坛为中心，方圆10公里范围内的司机展示以进行播单匹配。若要扩大第一区域的范围，则网约车平台变为以北京天坛为中心，方圆20公里范围作为第二区域，并将订单信息向该第二区域范围内的司机展示以进行播单匹配。或者，假设第一区域为边长为10公里的四边形区域，若要扩大第一区域的范围，则需要将该四边形的边长拉长至20公里来扩大为第二区域。相较于原本的第一区域，网约车平台可以在范围更大的第二区域中向更多的司机进行播单匹配，提高了播单匹配的效率。

在一些实施例中，根据预约订单信息进行派单匹配之后，该方法还包括：

若通过派单匹配没有在第三预设时长内匹配到司机，取消预约订单信息对应的预约订单并通知乘客。通过上述方法的步骤，可以避免派单匹配超时的问题。

在一些实施例中，进行播单匹配之后，该方法还包括：

若进行播单匹配没有在第一预设时长内匹配到司机，将乘客指定的司机作为所述接单司机。通过上述方法的步骤，可以在确认派单匹配超时后，通过人为介入指定服务司机。

具体地，第三预设时长为网约车平台或者乘客端自行设定的时长，用于避免再次播单匹配或者派单匹配超时，第三预设时长的设定范围一般小于5小时。假设第三预设时长设定为z小时，再次播单匹配或者派单匹配的启始时刻为C时。那么网约车平台在C+z时之前仍然允许播单匹配或者派单匹配的进行。然而，若C+z时之后仍然未匹配到司机，则取消预约订单信息对应的预约订单并通知乘客。

示例性地，假设乘客的预约单下单时刻为当晚7点，第一预设时长为2小时，第二预设时长设定为8小时，第三预设时长设定为5小时。乘客的出发时刻为明日早上8点。那么网约车平台在当晚7点至9点之间进行第一次的播单匹配，在9点至12点之间进行第二次的播单匹配。其中，由于第三预设时长设定为5小时，则理论上第二次的播单匹配可以持续至明日陵城2点。然而，由于第二预设时长设定为8小时，则在当晚12点之后，即凌晨12点至明日早上8点的这段时间内，需要进行派单匹配。但由于第三预设时长设定为5小时，派单匹配只能持续至凌晨5点，若派单匹配超过凌晨5点，则网约车平台取消预约订单信息对应的预约订单并通知乘客。

本申请根据另一方面提供了一种确定网约车预约订单的接单司机的装置，如图5所示，该装置包括：

信息获取模块110，用于获取乘客的预约订单信息，预约订单信息包括出发时刻；

在一些实施例中，在获取乘客的预约订单信息之前，信息获取模块110还用于根据乘客的终端位置信息确定目标区域；获取位于目标区域且符合预设条件的司机的司机信息；根据获取的司机信息生成目标白名单。

在一些实施例中，在获取乘客的预约订单信息之前，信息获取模块110还用于根据乘客的终端位置信息确定目标区域；获取目标区域对应的预先配置的白名单作为目标白名单。

在一些实施例中，根据预约订单信息进行派单匹配之后，信息获取模块110，还用于若通过派单匹配没有在第三预设时长内匹配到司机，取消预约订单信息对应的预约订单并通知乘客。

在一些实施例中，再次进行播单匹配之后，信息获取模块110，还用于若再次进行播单匹配没有在第三预设时长内匹配到司机，取消预约订单信息对应的预约订单并通知乘客。

第一播单模块120，用于进行播单匹配；

在一些实施例中，第一播单模块120还用于根据订单地址确定第一区域；对位于第一区域中的司机进行播单匹配。

静默匹配模块130，用于在第一预设时长内没有匹配到司机时，进入静默匹配模式，以及在乘客端展示从目标白名单中选择的司机；

静默匹配模块140，用于在静默匹配模式下，执行以下操作：

再次进行播单匹配；若匹配到司机，将播单匹配到的司机作为接单司机，以及将乘客端展示的司机更换为该司机；若未匹配到司机，且当前时刻与出发时刻的时差不大于第二预设时长，根据预约订单信息进行派单匹配，将派单匹配到的司机作为接单司机，以及将乘客端展示的司机更换为该司机。

在一些实施例中，静默匹配模块140还用于扩大第一区域的范围，得到第二区域，向位于第二区域内的司机进行播单匹配。

本申请根据又一方面提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述确定网约车预约订单的接单司机的任一项方法的步骤。

本申请根据另一方面提供了一种计算机设备，如图6所示，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现上述任一项确定网约车预约订单的接单司机的方法的步骤。

最后如图7所示提供了一种确定网约车预约订单的接单司机的任务全过程流程图。具体地，乘客通过终端设备的客户端下单后，网约车平台收到订单信息后进行播单匹配并同时开始记时。若在第一预设时长x分钟内找到司机，则向客户端反馈实际匹配到的司机。若在x分钟内找到司机未匹配到司机，则向客户端展示白名单司机，并且让终端设备的后台进入静默匹配模式，假设乘客的出发时刻为B时（B大于y）。那么网约车平台在B-y时之前仍然进行播单匹配，在B-y时之后，需要进行派单匹配。若在B-y时之前网约车平台通过播单匹配方式匹配到司机，将该司机作为实际接驾的司机，以及将乘客端的终端设备上展示的目标白名单司机更换为该实际接驾的司机。若网约车平台直到B-y时之后也未匹配到司机，则在B-y时之后，B时之前进行派单匹配，将派单匹配到的司机作为实际接驾的司机，以及将乘客端的终端设备上展示的目标白名单司机更换为该实际接驾的司机。

并且，假设再次播单匹配或者派单匹配的启始时刻为C时。那么网约车平台在C+z时之前仍然允许播单匹配或者派单匹配的进行。若C+z时之内未匹配到司机，则将派单匹配到的司机作为实际接驾的司机，以及将乘客端的终端设备上展示的目标白名单司机更换为该实际接驾的司机。然而，若C+z时之后仍然未匹配到司机，则取消预约订单信息对应的预约订单并通知乘客。

本领域普通技术人员可以理解实现上述方法实施例中的全部或部分流程，可以通过计算机程序来指令相关的硬件来完成。计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器（ROM）、可编程ROM（PROM）、电可编程ROM（EPROM）、电可擦除可编程ROM（EEPROM）或闪存。易失性存储器可包括随机存取存储器（RAM）或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM（SRAM）、动态RAM（DRAM）、同步DRAM（SDRAM）、双数据率SDRAM（DDRSDRAM）、增强型SDRAM（ESDRAM）、同步链路（Synchlink） DRAM（SLDRAM）、存储器总线（RamCus）、直接RAM（RDRAM）、直接存储器总线动态RAM（DRDRAM）、以及存储器总线动态RAM（RDRAM）等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个…”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

Claims (5)

1.一种确定网约车预约订单的接单司机的方法，其特征在于，包括：

根据乘客的终端位置信息确定目标区域；

根据位于所述目标区域且符合预设条件的司机的司机信息生成并配置目标白名单；

获取乘客的预约订单信息，所述预约订单信息包括出发时刻；

进行播单匹配；

若在第一预设时长内没有匹配到司机，进入静默匹配模式，以及在乘客端展示从所述目标白名单中选择的司机，所述目标白名单包括多个司机信息，所述司机信息包括各个对应司机的名称和历史评分；

在所述静默匹配模式下，执行以下操作：

再次进行播单匹配；

若匹配到司机，将播单匹配到的司机作为接单司机，以及将所述乘客端展示的司机更换为该司机；

若未匹配到司机，且当前时刻与所述出发时刻的时差不大于第二预设时长，根据所述预约订单信息进行派单匹配，将派单匹配到的司机作为接单司机，以及将所述乘客端展示的司机更换为该司机；

所述进行播单匹配包括：

根据所述订单信息的订单地址确定第一区域，对位于所述第一区域中的司机进行播单匹配；所述订单地址是一个特定的方位点，所述第一区域是以所述订单地址为中心，特定方圆半径围成的圆形区域；或者是以所述订单地址为中心，特定边长围城的多边形区域；

所述再次进行播单匹配，包括：

扩大所述第一区域的范围，得到第二区域，向位于所述第二区域内的司机进行播单匹配；

若通过所述派单匹配没有在第三预设时长内匹配到司机，取消所述预约订单信息对应的预约订单并通知乘客；

所述扩大所述第一区域的范围，包括：

若所述第一区域是圆形区域，则加长所述圆形区域对应的半径；

或者，若所述第一区域是多边形区域，则加长所述多边形区域对应的边长。

2.根据权利要求1所述的方法，其特征在于，进行播单匹配之后，所述方法还包括：

若进行播单匹配没有在第一预设时长内匹配到司机，将乘客指定的司机作为所述接单司机。

3.一种确定网约车预约订单的接单司机的装置，其特征在于，所述装置包括：

信息获取模块，用于根据乘客的终端位置信息确定目标区域；

根据位于所述目标区域且符合预设条件的司机的司机信息生成并配置目标白名单；获取乘客的预约订单信息，所述预约订单信息包括出发时刻；

第一播单模块，用于进行播单匹配；

静默匹配模块，用于在第一预设时长内没有匹配到司机时，进入静默匹配模式，以及在乘客端展示从目标白名单中选择的司机，所述目标白名单包括多个司机信息，所述司机信息包括各个对应司机的名称和历史评分；

静默匹配模块，还用于在所述静默匹配模式下，执行以下操作：

再次进行播单匹配；若匹配到司机，将播单匹配到的司机作为接单司机，以及将所述乘客端展示的司机更换为该司机；若未匹配到司机，且当前时刻与所述出发时刻的时差不大于第二预设时长，根据所述预约订单信息进行派单匹配，将派单匹配到的司机作为接单司机，以及将所述乘客端展示的司机更换为该司机；

所述第一播单模块还用于：

根据所述订单信息的订单地址确定第一区域，对位于所述第一区域中的司机进行播单匹配；所述订单地址是一个特定的方位点，所述第一区域是以所述订单地址为中心，特定方圆半径围成的圆形区域；或者是以所述订单地址为中心，特定边长围城的多边形区域；

所述静默匹配模块，还用于：

当再次进行所述播单匹配时，扩大所述第一区域的范围，得到第二区域，向位于所述第二区域内的司机进行播单匹配；若通过所述派单匹配没有在第三预设时长内匹配到司机，取消所述预约订单信息对应的预约订单并通知乘客；

所述扩大所述第一区域的范围，包括：

若所述第一区域是圆形区域，则加长所述圆形区域对应的半径；

或者，若所述第一区域是多边形区域，则加长所述多边形区域对应的边长。

4.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至2中任一项所述方法的步骤。

5.一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至2中任一项所述方法的步骤。