CN111833138A - 订单处理方法、***和计算机可读存储介质 - Google Patents

Abstract

本发明提供了一种订单处理方法、***和计算机可读存储介质，其中，订单处理方包括：响应投诉请求，在订单数据库中确定投诉请求所对应的被投诉订单；确定被投诉订单关联有自定义路线的确认指令，结束对投诉请求的处理；其中，订单数据库包括至少一个用车订单，自定义路线的确认指令是被投诉订单在行进过程中由用户输入的确认指令，该确认指令可以作为该行程是自定义路线的证明，当确定存在被投诉订单关联有自定义路线的确认指令，对投诉请求不再进行处理，以减少平台对该类订单处理的所需要的人力、物力，如减少服务器的运算量。

Description

订单处理方法、***和计算机可读存储介质

技术领域

本发明涉及订单处理技术领域，具体而言，涉及一种订单处理方法、一种订单处理***和一种计算机可读存储介质。

背景技术

现有技术方案中，因绕路出现投诉的订单每天高达1.25万起，通过统计发现，投诉订单中存在一部分是乘客利用平台漏洞来获取利益，如在乘车过程中，乘客为司机进行指路，从而该行程与预先设定的行程路线不一致，而在行程结束后，乘客投诉本次行程，认为该行程存在绕路行为，平台需要消耗大量的人力、物力来处理这些投诉订单。

通过对后台数据分析得到如下结论：部分乘客有指路需求，会在行程中对司机按导航行驶的行为进行干预；极少数乘客利用平台规则，既主动指路，又在事后投诉司机绕路，产生大量资源损耗，并占用大量的客服人力资源的成本。该结论包括以下方面：

a)乘客利用自身经验的指路需求是正当的，平台应当保证此需求得到满足，且需要保障司机事后不因乘客指路导致的绕路行为被处罚的权利。

b)极少数乘客因为自己指路导致司机绕路产生的纠纷，本质发生在乘客和平台之间，属于乘客的骗取补偿行为；当乘客确认有指路行为后，平台不应继续受理订单后续存在的绕路投诉。

发明内容

本发明旨在至少解决现有技术或相关技术中存在的技术问题之一。

为此，本发明的第一个方面在于，提供了一种订单处理方法。

本发明的第二个方面在于，提供了一种订单处理***。

本发明的第三个方面在于，提供了一种计算机可读存储介质。

有鉴于此，根据本发明的第一个方面，本发明提供了一种订单处理方法，包括：响应投诉请求，在订单数据库中确定投诉请求所对应的被投诉订单；确定被投诉订单关联有自定义路线的确认指令，结束对投诉请求的处理；其中，订单数据库包括至少一个用车订单。

本发明提出了一种订单处理方法，具体地，响应用户发出的投诉请求，在订单数据库中确定投诉请求所对应的被投诉订单，并查找该被投诉订单是否存在关联的自定义路线的确认指令，其中，自定义路线的确认指令是被投诉订单在行进过程中由用户输入的确认指令，该确认指令可以作为该行程是自定义路线的证明，当确定存在被投诉订单关联有自定义路线的确认指令，对投诉请求不再进行处理，以减少平台对该类订单处理的所需要的人力、物力，如减少服务器的运算量。

其中，订单数据库包括至少一个用车订单，至少一个用车订单可以理解为包括历史订单和当前正在处于行进状态的用车订单。

另外，本发明提供的上述技术方案中的订单处理方法还可以具有如下附加技术特征：

在上述技术方案中，在响应投诉请求，在订单数据库中查找投诉请求所对应的被投诉订单的步骤之前，还包括：在订单数据库中的任一用车订单的行进过程中，获取用车订单的轨迹信息和用车订单的规划路线；确定轨迹信息与规划路线不一致，输出自定义路线的提示信息；接收针对提示信息的确认指令，并将确认指令与用车订单进行关联。

在该技术方案中，在订单数据库中的任一用车订单的行进过程中，获取用车订单的轨迹信息和用车订单的规划路线，并判断轨迹信息与规划路线是否一致，当轨迹信息与规划路线不一致，则判定该用车订单存在偏航情况，属于偏航订单，此时，通过输出自定义路线的提示信息，以便用户进行确认，当接收针对提示信息的确认指令时，将确认指令与用车订单进行关联，以便在该用车订单被投诉时，可以调用该确认指令，进而对投诉请求进行处理。在该技术方案中，在判定用车订单为偏航订单时，就输出自定义路线的提示信息，以便用户在接收到该提示信息后，可以主动判断司机是否绕路，减少了司机主动绕路等情况的出现。

在上述任一技术方案中，在确定轨迹信息与规划路线不一致的步骤之后，在输出自定义路线的提示信息之前，还包括：根据预先存储的标签标记规则对用车订单进行标记；确定用车订单具有风险标签，执行输出自定义路线的提示信息的步骤。

在该技术方案中，使用预先存储的标签标记规则对用车订单进行标记，通过检测用车订单是否具有风险标签来输出自定义路线的提示信息，其中，标签标记规则的使用可以理解为对用车订单的进行分析，由于用车订单是由用户发出的，因此，可以实现对用户行为的分析，进而提高了投诉请求处理的可信度。

在上述任一技术方案中，根据预先存储的标签标记规则对用车订单进行标记的步骤，具体包括：获取发出用车订单的用户的历史投诉记录；根据历史投诉记录对用车订单进行标记。

在该技术方案中，通过获取发出用车订单的用户的历史投诉记录，并根据历史投诉记录对用车订单进行标记，可以理解的是，通过对发出用车订单的用户的历史行为进行分析，以便根据该用户的历史行为对当前处于行进状态的订单的标记，进而提高了对投诉请求处理的可信度。

在上述任一技术方案中，根据历史投诉记录对用车订单进行标记的步骤，具体包括：确定存在与用车订单的基础信息一致，且存在绕路投诉的历史投诉记录，为用车订单标记风险标签；和/或确定在第一时长内，历史投诉记录的数量大于或等于第一数值，为用车订单标记风险标签。

在该技术方案中，当检测到存在与用车订单的基础信息一致，且存在绕路投诉的历史投诉记录，则判定目前处于行进状态的用车订单存在被投诉的风险，故为用车订单标记风险标签，和/或确定在第一时长内，历史投诉记录的数量大于或等于第一数值，则判定目前处于行进状态的用车订单存在被投诉的风险，故为用车订单标记风险标签，通过限定风险标签具体的标记场景，提高了投诉请求处理的可信度。

在上述任一技术方案中，确定存在与用车订单的基础信息一致，且存在绕路投诉的历史投诉记录，为用车订单标记风险标签的步骤，还包括：确定历史投诉记录所对应的历史行程的行程开始时间，以及根据行程开始时间与当前时间确定第二时长；确定第二时长小于或等于第三时长，为用车订单标记风险标签。

在该技术方案中，通过为历史投诉记录限定一个时间，以便减少需要与用车订单的历史投诉记录的比对数量，进而降低数据处理的数量，降低了平台的成本。

在上述任一技术方案中，基础信息包括：用车订单的起点信息和/或用车订单的终点信息。

在该技术方案中，通常情况下，相同的用户会在同一起点位置和/或终点位置再次出现绕路的情况，因此，通过限定基础信息包括：用车订单的起点信息和/或用车订单的终点信息，提高绕路订单的筛选结果的可信度，进而提高了投诉请求处理的可信度。

在上述任一技术方案中，根据预先存储的标签标记规则对用车订单进行标记的步骤，具体包括：获取发出用车订单的用户的客服提报记录，其中，客服提报记录中存储有指路行为的历史行程；确定存在与用车订单的基础信息一致，且被标记存在指路行为的历史行程，为用车订单标记风险标签。

在该技术方案中，通过引入客服提报记录，根据客服提报记录中存储的存在指路行为的历史行程来对用车订单进行标记，具体地，当确定存在与用车订单的基础信息一致，且被标记存在指路行为的历史行程，为用车订单标记风险标签。在该技术方案中，由于存在指路行为的历史行程是客服提报记录所记录的，因此，存在指路行为的历史行程具有较强的可信度，进而根据客服提报记录对用车订单所标记的风险标签具有较强的可信度，提高了投诉请求处理的可信度。

在上述任一技术方案中，在获取用车订单的轨迹信息和用车订单的规划路线的步骤之前，还包括：监测用车订单的时序事件信息，确定接收到时序事件信息包含的开始计费信息，执行获取用车订单的轨迹信息和用车订单的规划路线的步骤；以及确定接收到时序事件信息包含的停止计费信息，停止获取用车订单的轨迹信息。

在该技术方案中，通过监测用车订单的时序事件信息，以便在用车订单开始计费时，获取用车订单的轨迹信息和用车订单的规划路线，而在确定接收到时序事件信息包含的停止计费信息时，停止获取用车订单的轨迹信息，在此过程中，降低了用车订单的轨迹信息的获取数量，进而减少了数据处理的量，降低了平台的成本。

在上述任一技术方案中，还包括：将确认指令与用车订单进行存储。

在该技术方案中，通过将确认指令与用车订单进行存储，以便在接收到投诉请求时，调用该确认指令，进而判断是否对接收到的投诉请求进行继续处理。

根据本发明的第二个方面，提出了一种订单处理***，包括：控制器；存储器，用于存储计算机程序；控制器执行存储在存储器中的计算机程序以实现：响应投诉请求，在订单数据库中确定投诉请求所对应的被投诉订单；确定被投诉订单关联有自定义路线的确认指令，结束对投诉请求的处理；其中，订单数据库包括至少一个用车订单。

本发明提出了一种订单处理***，其中，控制器执行存储在存储器中的计算机程序以实现：响应用户发出的投诉请求，在订单数据库中确定投诉请求所对应的被投诉订单，并查找该被投诉订单是否存在关联的自定义路线的确认指令，其中，自定义路线的确认指令是被投诉订单在行进过程中由用户输入的确认指令，该确认指令可以作为该行程是自定义路线的证明，当确定存在被投诉订单关联有自定义路线的确认指令，对投诉请求不再进行处理，以减少平台对该类订单处理的所需要的人力、物力，如减少服务器的运算量。

其中，订单数据库包括至少一个用车订单，至少一个用车订单可以理解为包括历史订单和当前正在处于行进状态的用车订单。

另外，本发明提供的上述技术方案中的订单处理***还可以具有如下附加技术特征：

在上述技术方案中，控制器执行存储在存储器中的计算机程序以实现：在响应投诉请求，在订单数据库中查找投诉请求所对应的被投诉订单的步骤之前，还包括：在订单数据库中的任一用车订单的行进过程中，获取用车订单的轨迹信息和用车订单的规划路线；确定轨迹信息与规划路线不一致，输出自定义路线的提示信息；接收针对提示信息的确认指令，并将确认指令与用车订单进行关联。

在该技术方案中，在订单数据库中的任一用车订单的行进过程中，获取用车订单的轨迹信息和用车订单的规划路线，并判断轨迹信息与规划路线是否一致，当轨迹信息与规划路线不一致，则判定该用车订单存在偏航情况，属于偏航订单，此时，通过输出自定义路线的提示信息，以便用户进行确认，当接收针对提示信息的确认指令时，将确认指令与用车订单进行关联，以便在该用车订单被投诉时，可以调用该确认指令，进而对投诉请求进行处理。在该技术方案中，在判定用车订单为偏航订单时，就输出自定义路线的提示信息，以便用户在接收到该提示信息后，可以主动判断司机是否绕路，减少了司机主动绕路等情况的出现。

在上述任一技术方案中，控制器执行存储在存储器中的计算机程序以实现：在确定轨迹信息与规划路线不一致的步骤之后，在输出自定义路线的提示信息之前，还包括：根据预先存储的标签标记规则对用车订单进行标记；确定用车订单具有风险标签，执行输出自定义路线的提示信息的步骤。

在该技术方案中，使用预先存储的标签标记规则对用车订单进行标记，通过检测用车订单是否具有风险标签来输出自定义路线的提示信息，其中，标签标记规则的使用可以理解为对用车订单的进行分析，由于用车订单是由用户发出的，因此，可以实现对用户行为的分析，进而提高了投诉请求处理的可信度。

在上述任一技术方案中，控制器执行存储在存储器中的计算机程序以实现：根据预先存储的标签标记规则对用车订单进行标记的步骤，具体包括：获取发出用车订单的用户的历史投诉记录；根据历史投诉记录对用车订单进行标记。

在该技术方案中，通过获取发出用车订单的用户的历史投诉记录，并根据历史投诉记录对用车订单进行标记，可以理解的是，通过对发出用车订单的用户的历史行为进行分析，以便根据该用户的历史行为对当前处于行进状态的订单的标记，进而提高了对投诉请求处理的可信度。

在上述任一技术方案中，控制器执行存储在存储器中的计算机程序以实现：根据历史投诉记录对用车订单进行标记的步骤，具体包括：确定存在与用车订单的基础信息一致，且存在绕路投诉的历史投诉记录，为用车订单标记风险标签；和/或确定在第一时长内，历史投诉记录的数量大于或等于第一数值，为用车订单标记风险标签。

在该技术方案中，当检测到存在与用车订单的基础信息一致，且存在绕路投诉的历史投诉记录，则判定目前处于行进状态的用车订单存在被投诉的风险，故为用车订单标记风险标签，和/或确定在第一时长内，历史投诉记录的数量大于或等于第一数值，则判定目前处于行进状态的用车订单存在被投诉的风险，故为用车订单标记风险标签，通过限定风险标签具体的标记场景，提高了投诉请求处理的可信度。

在上述任一技术方案中，确定存在与用车订单的基础信息一致，且存在绕路投诉的历史投诉记录，为用车订单标记风险标签的步骤，控制器执行存储在存储器中的计算机程序以实现：确定历史投诉记录所对应的历史行程的行程开始时间，以及根据行程开始时间与当前时间确定第二时长；确定第二时长小于或等于第三时长，为用车订单标记风险标签。

在该技术方案中，通过为历史投诉记录限定一个时间，以便减少需要与用车订单的历史投诉记录的比对数量，进而降低数据处理的数量，降低了平台的成本。

在上述任一技术方案中，基础信息包括：用车订单的起点信息和/或用车订单的终点信息。

在该技术方案中，通常情况下，相同的用户会在同一起点位置和/或终点位置再次出现绕路的情况，因此，通过限定基础信息包括：用车订单的起点信息和/或用车订单的终点信息，提高绕路订单的筛选结果的可信度，进而提高了投诉请求处理的可信度。

在上述任一技术方案中，控制器执行存储在存储器中的计算机程序以实现：根据预先存储的标签标记规则对用车订单进行标记的步骤，具体包括：获取发出用车订单的用户的客服提报记录，其中，客服提报记录中存储有指路行为的历史行程；确定存在与用车订单的基础信息一致，且被标记存在指路行为的历史行程，为用车订单标记风险标签。

在该技术方案中，通过引入客服提报记录，根据客服提报记录中存储的存在指路行为的历史行程来对用车订单进行标记，具体地，当确定存在与用车订单的基础信息一致，且被标记存在指路行为的历史行程，为用车订单标记风险标签。在该技术方案中，由于存在指路行为的历史行程是客服提报记录所记录的，因此，存在指路行为的历史行程具有较强的可信度，进而根据客服提报记录对用车订单所标记的风险标签具有较强的可信度，提高了投诉请求处理的可信度。

在上述任一技术方案中，在获取用车订单的轨迹信息和用车订单的规划路线的步骤之前，控制器执行存储在存储器中的计算机程序以实现：监测用车订单的时序事件信息，确定接收到时序事件信息包含的开始计费信息，执行获取用车订单的轨迹信息和用车订单的规划路线的步骤；以及确定接收到时序事件信息包含的停止计费信息，停止获取用车订单的轨迹信息。

在该技术方案中，通过监测用车订单的时序事件信息，以便在用车订单开始计费时，获取用车订单的轨迹信息和用车订单的规划路线，而在确定接收到时序事件信息包含的停止计费信息时，停止获取用车订单的轨迹信息，在此过程中，降低了用车订单的轨迹信息的获取数量，进而减少了数据处理的量，降低了平台的成本。

在上述任一技术方案中，控制器执行存储在存储器中的计算机程序以实现：将确认指令与用车订单进行存储。

在该技术方案中，通过将确认指令与用车订单进行存储，以便在接收到投诉请求时，调用该确认指令，进而判断是否对接收到的投诉请求进行继续处理。

根据本发明的第三个方面，提出了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现如上述任一技术方案的订单处理方法的步骤。

本发明提出了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现如上述任一技术方案的订单处理方法的步骤，故具有上述任一项的订单处理方法的全部有益效果，在此不一一列举。

本发明的附加方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

本发明的上述和/或附加的方面和优点从结合下面附图对实施例的描述中将变得明显和容易理解，其中：

图1示出了根据本发明一个实施例的订单处理方法的流程示意图；

图2示出了根据本发明一个实施例的订单处理方法的流程示意图；

图3示出了根据本发明一个实施例的订单处理方法的流程示意图；

图4示出了根据本发明一个实施例的根据预先存储的标签标记规则对用车订单进行标记的流程示意图；

图5示出了根据本发明一个实施例的根据预先存储的标签标记规则对用车订单进行标记的流程示意图；

图6示出了根据本发明一个实施例的订单处理方法的流程示意图；

图7示出了根据本发明一个实施例的示意框图；

图8示出了根据本发明一个实施例的订单处理***的示意框图。

具体实施方式

为了能够更清楚地理解本发明的上述方面、特征和优点，下面结合附图和具体实施方式对本发明进行进一步的详细描述。需要说明的是，在不冲突的情况下，本申请的实施例及实施例中的特征可以相互组合。

在下面的描述中阐述了很多具体细节以便于充分理解本发明，但是，本发明还可以采用其他不同于在此描述的其他方式来实施，因此，本发明的保护范围并不受下面公开的具体实施例的限制。

实施例一

如图1所示，根据本发明的第一个方面，本发明提供了一种订单处理方法，包括：

步骤102，响应投诉请求，在订单数据库中确定投诉请求所对应的被投诉订单；

步骤104，确定被投诉订单关联有自定义路线的确认指令，结束对投诉请求的处理。

其中，订单数据库包括至少一个用车订单。

本发明提出了一种订单处理方法，具体地，响应用户发出的投诉请求，在订单数据库中确定投诉请求所对应的被投诉订单，并查找该被投诉订单是否存在关联的自定义路线的确认指令，其中，自定义路线的确认指令是被投诉订单在行进过程中由用户输入的确认指令，该确认指令可以作为该行程是自定义路线的证明，当确定存在被投诉订单关联有自定义路线的确认指令，对投诉请求不再进行处理，以减少平台对该类订单处理的所需要的人力、物力，如减少服务器的运算量。

其中，订单数据库包括至少一个用车订单，至少一个用车订单可以理解为包括历史订单和当前正在处于行进状态的用车订单。

进一步地，自定义路线的确认指令的引入克服了以下缺点：

1、当前平台不允许司机绕路，但部分乘客出于自身原因(熟悉路线、避开拥堵)，确有指路需求，骗取补偿行为的识别只解决了乘客骗取补偿行为，无法满足乘客指路的真实需求。

2、由于自定义路线的确认指令的引入旨在为客服补偿提供建议，无法及时阻止乘客投诉的发生，仍然会导致乘客进线投诉，从而造成客服人力资源的成本居高不下。

3、乘客表达意愿低，反馈率低，乘客投诉只覆盖了绕路的极小部分，大量司机绕路的订单由于没有产生投诉工单，导致尽管体验异常，但是没有证据可以有效控制。

在其一实施例中，如图2所示，订单处理方法，包括：

步骤202，在订单数据库中的任一用车订单的行进过程中，获取用车订单的轨迹信息和用车订单的规划路线；

步骤204，确定轨迹信息与规划路线不一致，输出自定义路线的提示信息；

步骤206，接收针对提示信息的确认指令，并将确认指令与用车订单进行关联；

步骤208，响应投诉请求，在订单数据库中确定投诉请求所对应的被投诉订单；

步骤210，确定被投诉订单关联有自定义路线的确认指令，结束对投诉请求的处理。

其中，订单数据库包括至少一个用车订单。

在该实施例中，在订单数据库中的任一用车订单的行进过程中，获取用车订单的轨迹信息和用车订单的规划路线，并判断轨迹信息与规划路线是否一致，当轨迹信息与规划路线不一致，则判定该用车订单存在偏航情况，属于偏航订单，此时，通过输出自定义路线的提示信息，以便用户进行确认，当接收针对提示信息的确认指令时，将确认指令与用车订单进行关联，以便在该用车订单被投诉时，可以调用该确认指令，进而对投诉请求进行处理。在该实施例中，在判定用车订单为偏航订单时，就输出自定义路线的提示信息，以便用户在接收到该提示信息后，可以主动判断司机是否绕路，减少了司机主动绕路等情况的出现。

在其一实施例中，如图3所示，订单处理方法，包括：

步骤302，在订单数据库中的任一用车订单的行进过程中，获取用车订单的轨迹信息和用车订单的规划路线；

步骤304，确定轨迹信息与规划路线不一致，根据预先存储的标签标记规则对用车订单进行标记；

步骤306，确定用车订单具有风险标签，输出自定义路线的提示信息；

步骤308，接收针对提示信息的确认指令，并将确认指令与用车订单进行关联；

步骤310，响应投诉请求，在订单数据库中确定投诉请求所对应的被投诉订单；

步骤312，确定被投诉订单关联有自定义路线的确认指令，结束对投诉请求的处理。

其中，订单数据库包括至少一个用车订单。

在该实施例中，使用预先存储的标签标记规则对用车订单进行标记，通过检测用车订单是否具有风险标签来输出自定义路线的提示信息，其中，标签标记规则的使用可以理解为对用车订单的进行分析，由于用车订单是由用户发出的，因此，可以实现对用户行为的分析，进而提高了投诉请求处理的可信度。

实施例二

在上述任一实施例中，如图4所示，根据预先存储的标签标记规则对用车订单进行标记的步骤，具体包括：

步骤402，获取发出用车订单的用户的历史投诉记录；

步骤404，根据历史投诉记录对用车订单进行标记。

在该实施例中，通过获取发出用车订单的用户的历史投诉记录，并根据历史投诉记录对用车订单进行标记，可以理解的是，通过对发出用车订单的用户的历史行为进行分析，以便根据该用户的历史行为对当前处于行进状态的订单的标记，进而提高了对投诉请求处理的可信度。

在其一实施例中，根据历史投诉记录对用车订单进行标记的步骤，具体包括：确定存在与用车订单的基础信息一致，且存在绕路投诉的历史投诉记录，为用车订单标记风险标签；和/或确定在第一时长内，历史投诉记录的数量大于或等于第一数值，为用车订单标记风险标签。

在该实施例中，当检测到存在与用车订单的基础信息一致，且存在绕路投诉的历史投诉记录，则判定目前处于行进状态的用车订单存在被投诉的风险，故为用车订单标记风险标签，和/或确定在第一时长内，历史投诉记录的数量大于或等于第一数值，则判定目前处于行进状态的用车订单存在被投诉的风险，故为用车订单标记风险标签，通过限定风险标签具体的标记场景，提高了投诉请求处理的可信度。

其中，第一时长的取值区间为2个月至4个月，第一数值取值为1至3之间，为了便于季度统计，第一时长可以选取3个月，第一数值选取2。

在其一实施例中，确定存在与用车订单的基础信息一致，且存在绕路投诉的历史投诉记录，为用车订单标记风险标签的步骤，还包括：确定历史投诉记录所对应的历史行程的行程开始时间，以及根据行程开始时间与当前时间确定第二时长；确定第二时长小于或等于第三时长，为用车订单标记风险标签。

在该实施例中，通过为历史投诉记录限定一个时间，以便减少需要与用车订单的历史投诉记录的比对数量，进而降低数据处理的数量，降低了平台的成本。

其中，第三时长的取值区间为5个月至7个月，为了便于年度统计，可以选取为6个月。

在上述任一实施例中，基础信息包括：用车订单的起点信息和/或用车订单的终点信息。

在该实施例中，通常情况下，相同的用户会在同一起点位置和/或终点位置再次出现绕路的情况，因此，通过限定基础信息包括：用车订单的起点信息和/或用车订单的终点信息，提高绕路订单的筛选结果的可信度，进而提高了投诉请求处理的可信度。

实施例三

在上述任一实施例中，如图5所示，根据预先存储的标签标记规则对用车订单进行标记的步骤，具体包括：

步骤502，获取发出用车订单的用户的客服提报记录，其中，客服提报记录中存储有指路行为的历史行程；

步骤504，确定存在与用车订单的基础信息一致，且被标记存在指路行为的历史行程，为用车订单标记风险标签。

在该实施例中，通过引入客服提报记录，根据客服提报记录中存储的存在指路行为的历史行程来对用车订单进行标记，具体地，当确定存在与用车订单的基础信息一致，且被标记存在指路行为的历史行程，为用车订单标记风险标签。在该实施例中，由于存在指路行为的历史行程是客服提报记录所记录的，因此，存在指路行为的历史行程具有较强的可信度，进而根据客服提报记录对用车订单所标记的风险标签具有较强的可信度，提高了投诉请求处理的可信度。

实施例四

在上述任一实施例中，如图6所示，在获取用车订单的轨迹信息和用车订单的规划路线的步骤之前，还包括：

步骤602，监测用车订单的时序事件信息，确定接收到时序事件信息包含的开始计费信息，执行获取用车订单的轨迹信息和用车订单的规划路线的步骤；

步骤604，确定接收到时序事件信息包含的停止计费信息，停止获取用车订单的轨迹信息。

在该实施例中，通过监测用车订单的时序事件信息，以便在用车订单开始计费时，获取用车订单的轨迹信息和用车订单的规划路线，而在确定接收到时序事件信息包含的停止计费信息时，停止获取用车订单的轨迹信息，在此过程中，降低了用车订单的轨迹信息的获取数量，进而减少了数据处理的量，降低了平台的成本。

其中，用车订单的时序事件信息包括但不局限于计费部分，还包括发单、接单和取消等时序事件信息，在实际应用过程中，直接获取订单事件流，其中，订单事件流包括上述时序事件信息。

在上述任一实施例中，还包括：将确认指令与用车订单进行存储。

在该实施例中，通过将确认指令与用车订单进行存储，以便在接收到投诉请求时，调用该确认指令，进而判断是否对接收到的投诉请求进行继续处理。

实施例五

在本发明的一个实施例中，首先分析乘客的历史行为，结合用车订单起终点(即本文涉及到的用车订单的起点信息和/或用车订单的终点信息)，当满足以下条件之一、且检测发生偏航时，给乘客弹一个【指定路线】的确认提醒(即本文涉及到的自定义路线的提示信息)。

(1)乘客曾在同一起始点/终点发生绕路投诉；

(2)乘客曾在同一起始点/终点的行程中被客服标记为有指路行为；

(3)乘客高频投诉司机绕路，疑似虚假投诉。

其中，高频在当前环境下可以理解为在3个月内投诉的次数超过2次。

如果乘客确认自定义路线，后续针对该订单的所有绕路投诉将不再对司机进行判责，同时会把乘客的确认信息反馈给人工客服，以便准确对乘客进行判责。

具体地，在该实施例中，订单处理方法基于flink(即Apache Flink是一个框架和分布式处理引擎，用于对无界和有界数据流进行有状态计算)流的计算***，如图7所示，具体分为以下几个步骤：

步骤一：数据接入，获取干预所需要的相关业务数据：

订阅业务线实时消息队列生产的实时流数据，其中，实时流数据包括：

1、订单事件流：订单从发单、接单、计费、结束及取消等时序事件信息。

2、订单信息：订单基础信息(即本文涉及到的基础信息)，例如，订单起始点/终点信息。

3、订单轨迹流：司机行驶中每3s时实上报坐标轨迹数据(即本文涉及到的用车订单的轨迹信息)。

4、客服提报(即本文涉及到的客服提报记录)：在客服处理投诉的历史工单中，客服通过听音/看视频在同一起始点/终点将乘客打上的指路行为标签信息。

5、乘客投诉历史：乘客的投诉历史(即本文涉及到的历史投诉记录)。

步骤二：策略检测，对实时流原始数据进行实时加工，其中，策略检测包括两个步骤：偏航实时检测和标签计算：

1、偏航实时检测：计算订单当前轨迹和规划线路的差异(即本文涉及到的轨迹信息与所述规划路线是否一致的检测过程)，检测出订单有无偏航行为。

2、标签计算(即本文涉及到的风险标签)包括以下三类标签：

1.绕路投诉高风险标签：乘客在近6个月内曾在同一起始点/终点发生绕路投诉，则标记此订单为绕路投诉高风险标签。

2.乘客指路标签：根据客服提报，乘客曾在同一起始点/终点的行程中被客服标记为有指路行为，则标记此订单为乘客指路标签。

3.乘客疑似虚假投诉高风险标签：乘客高频投诉司机绕路，则标记此订单为乘客疑似虚假投诉高风险订单。

步骤三：结果输出及干预：当订单命中实时偏航检测时，检查订单是否有步骤二中提到的三种标签。如有，则加入干预信号消息队列，对乘客端执行提醒，请乘客确认是否【自定义路线】(即本文涉及到的自定义路线的确认指令)。

步骤四：干预信号存入日志供判责输入：获取乘客【自定义路线】的输入结果，将干预信号与输入结果落Hive表，提供给下游判责***和人工客服使用。当乘客确认自己指定路线时，针对该订单的所有绕路投诉将不再对司机进行判责，同时会把乘客的确认信息反馈给人工客服。

在该实施例中，主要包括：基于乘客指路行为的标签打标方法以及基于Flink实时流处理技术的场景检测及提醒干预，提出的基于Flink实时流计算引擎进行实时策略识别，对乘客的提醒干预，能够及时有效的对乘客进行提醒确认，既保障了乘客的指路权益，同时减少了乘客指路行为造成的司机不良体验。

实施例六

在本发明的一个实施例中，如图8所示，提出了一种订单处理***800，包括：控制器802；存储器804，用于存储计算机程序；控制器802执行存储在存储器804中的计算机程序以实现：响应投诉请求，在订单数据库中确定投诉请求所对应的被投诉订单；确定被投诉订单关联有自定义路线的确认指令，结束对投诉请求的处理；其中，订单数据库包括至少一个用车订单。

本发明提出了一种订单处理***800，其中，控制器802执行存储在存储器804中的计算机程序以实现：响应用户发出的投诉请求，在订单数据库中确定投诉请求所对应的被投诉订单，并查找该被投诉订单是否存在关联的自定义路线的确认指令，其中，自定义路线的确认指令是被投诉订单在行进过程中由用户输入的确认指令，该确认指令可以作为该行程是自定义路线的证明，当确定存在被投诉订单关联有自定义路线的确认指令，对投诉请求不再进行处理，以减少平台对该类订单处理的所需要的人力、物力，如减少服务器的运算量。

其中，订单数据库包括至少一个用车订单，至少一个用车订单可以理解为包括历史订单和当前正在处于行进状态的用车订单。

另外，本发明提供的上述实施例中的订单处理***800还可以具有如下附加技术特征：

在上述实施例中，控制器802执行存储在存储器804中的计算机程序以实现：在响应投诉请求，在订单数据库中查找投诉请求所对应的被投诉订单的步骤之前，还包括：在订单数据库中的任一用车订单的行进过程中，获取用车订单的轨迹信息和用车订单的规划路线；确定轨迹信息与规划路线不一致，输出自定义路线的提示信息；接收针对提示信息的确认指令，并将确认指令与用车订单进行关联。

在该实施例中，在订单数据库中的任一用车订单的行进过程中，获取用车订单的轨迹信息和用车订单的规划路线，并判断轨迹信息与规划路线是否一致，当轨迹信息与规划路线不一致，则判定该用车订单存在偏航情况，属于偏航订单，此时，通过输出自定义路线的提示信息，以便用户进行确认，当接收针对提示信息的确认指令时，将确认指令与用车订单进行关联，以便在该用车订单被投诉时，可以调用该确认指令，进而对投诉请求进行处理。在该实施例中，在判定用车订单为偏航订单时，就输出自定义路线的提示信息，以便用户在接收到该提示信息后，可以主动判断司机是否绕路，减少了司机主动绕路等情况的出现。

在上述任一实施例中，控制器802执行存储在存储器804中的计算机程序以实现：在确定轨迹信息与规划路线不一致的步骤之后，在输出自定义路线的提示信息之前，还包括：根据预先存储的标签标记规则对用车订单进行标记；确定用车订单具有风险标签，执行输出自定义路线的提示信息的步骤。

在该实施例中，使用预先存储的标签标记规则对用车订单进行标记，通过检测用车订单是否具有风险标签来输出自定义路线的提示信息，其中，标签标记规则的使用可以理解为对用车订单的进行分析，由于用车订单是由用户发出的，因此，可以实现对用户行为的分析，进而提高了投诉请求处理的可信度。

在上述任一实施例中，控制器802执行存储在存储器804中的计算机程序以实现：根据预先存储的标签标记规则对用车订单进行标记的步骤，具体包括：获取发出用车订单的用户的历史投诉记录；根据历史投诉记录对用车订单进行标记。

在该实施例中，通过获取发出用车订单的用户的历史投诉记录，并根据历史投诉记录对用车订单进行标记，可以理解的是，通过对发出用车订单的用户的历史行为进行分析，以便根据该用户的历史行为对当前处于行进状态的订单的标记，进而提高了对投诉请求处理的可信度。

在上述任一实施例中，控制器802执行存储在存储器804中的计算机程序以实现：根据历史投诉记录对用车订单进行标记的步骤，具体包括：确定存在与用车订单的基础信息一致，且存在绕路投诉的历史投诉记录，为用车订单标记风险标签；和/或确定在第一时长内，历史投诉记录的数量大于或等于第一数值，为用车订单标记风险标签。

在该实施例中，当检测到存在与用车订单的基础信息一致，且存在绕路投诉的历史投诉记录，则判定目前处于行进状态的用车订单存在被投诉的风险，故为用车订单标记风险标签，和/或确定在第一时长内，历史投诉记录的数量大于或等于第一数值，则判定目前处于行进状态的用车订单存在被投诉的风险，故为用车订单标记风险标签，通过限定风险标签具体的标记场景，提高了投诉请求处理的可信度。

在上述任一实施例中，确定存在与用车订单的基础信息一致，且存在绕路投诉的历史投诉记录，为用车订单标记风险标签的步骤，控制器802执行存储在存储器804中的计算机程序以实现：确定历史投诉记录所对应的历史行程的行程开始时间，以及根据行程开始时间与当前时间确定第二时长；确定第二时长小于或等于第三时长，为用车订单标记风险标签。

在该实施例中，通过为历史投诉记录限定一个时间，以便减少需要与用车订单的历史投诉记录的比对数量，进而降低数据处理的数量，降低了平台的成本。

在上述任一实施例中，基础信息包括：用车订单的起点信息和/或用车订单的终点信息。

在该实施例中，通常情况下，相同的用户会在同一起点信息和/或终点信息再次出现绕路的情况，因此，通过限定基础信息包括：用车订单的起点信息和/或用车订单的终点信息，提高绕路订单的筛选结果的可信度，进而提高了投诉请求处理的可信度。

在上述任一实施例中，控制器802执行存储在存储器804中的计算机程序以实现：根据预先存储的标签标记规则对用车订单进行标记的步骤，具体包括：获取发出用车订单的用户的客服提报记录，其中，客服提报记录中存储有指路行为的历史行程；确定存在与用车订单的基础信息一致，且被标记存在指路行为的历史行程，为用车订单标记风险标签。

在该实施例中，通过引入客服提报记录，根据客服提报记录中存储的存在指路行为的历史行程来对用车订单进行标记，具体地，当确定存在与用车订单的基础信息一致，且被标记存在指路行为的历史行程，为用车订单标记风险标签。在该实施例中，由于存在指路行为的历史行程是客服提报记录所记录的，因此，存在指路行为的历史行程具有较强的可信度，进而根据客服提报记录对用车订单所标记的风险标签具有较强的可信度，提高了投诉请求处理的可信度。

在上述任一实施例中，在获取用车订单的轨迹信息和用车订单的规划路线的步骤之前，控制器802执行存储在存储器804中的计算机程序以实现：监测用车订单的时序事件信息，确定接收到时序事件信息包含的开始计费信息，执行获取用车订单的轨迹信息和用车订单的规划路线的步骤；以及确定接收到时序事件信息包含的停止计费信息，停止获取用车订单的轨迹信息。

在该实施例中，通过监测用车订单的时序事件信息，以便在用车订单开始计费时，获取用车订单的轨迹信息和用车订单的规划路线，而在确定接收到时序事件信息包含的停止计费信息时，停止获取用车订单的轨迹信息，在此过程中，降低了用车订单的轨迹信息的获取数量，进而减少了数据处理的量，降低了平台的成本。

在上述任一实施例中，控制器802执行存储在存储器804中的计算机程序以实现：将确认指令与用车订单进行存储。

在该实施例中，通过将确认指令与用车订单进行存储，以便在接收到投诉请求时，调用该确认指令，进而判断是否对接收到的投诉请求进行继续处理。

实施例七

在本发明的一个实施例中，提出了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现如上述任一实施例的订单处理方法的步骤。

本发明提出了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现如上述任一实施例的订单处理方法的步骤，故具有上述任一项的订单处理方法的全部有益效果，在此不一一列举。

在本发明的描述中，术语“多个”则指两个或两个以上，除非另有明确的限定，术语“上”、“下”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制；术语“连接”、“安装”、“固定”等均应做广义理解，例如，“连接”可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是直接相连，也可以通过中间媒介间接相连。对于本领域的普通技术人员而言，可以根据具体情况理解上述术语在本发明中的具体含义。

在本发明的描述中，术语“一个实施例”、“一些实施例”、“具体实施例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或特点包含于本发明的至少一个实施例或示例中。在本发明中，对上述术语的示意性表述不一定指的是相同的实施例或实例。而且，描述的具体特征、结构、材料或特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

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

Claims (12)

1.一种订单处理方法，其特征在于，包括：

响应投诉请求，在订单数据库中确定所述投诉请求所对应的被投诉订单；

确定所述被投诉订单关联有自定义路线的确认指令，结束对所述投诉请求的处理；

其中，所述订单数据库包括至少一个用车订单。

2.根据权利要求1所述的订单处理方法，其特征在于，在响应投诉请求，在订单数据库中查找所述投诉请求所对应的被投诉订单的步骤之前，还包括：

在所述订单数据库中的任一所述用车订单的行进过程中，获取所述用车订单的轨迹信息和所述用车订单的规划路线；

确定所述轨迹信息与所述规划路线不一致，输出自定义路线的提示信息；

接收针对所述提示信息的确认指令，并将所述确认指令与所述用车订单进行关联。

3.根据权利要求2所述的订单处理方法，其特征在于，在所述确定所述轨迹信息与所述规划路线不一致的步骤之后，在输出自定义路线的提示信息之前，还包括：

根据预先存储的标签标记规则对所述用车订单进行标记；

确定所述用车订单具有风险标签，执行输出自定义路线的提示信息的步骤。

4.根据权利要求3所述的订单处理方法，其特征在于，所述根据预先存储的标签标记规则对所述用车订单进行标记的步骤，具体包括：

获取发出所述用车订单的用户的历史投诉记录；

根据所述历史投诉记录对所述用车订单进行标记。

5.根据权利要求4所述的订单处理方法，其特征在于，所述根据所述历史投诉记录对所述用车订单进行标记的步骤，具体包括：

确定存在与所述用车订单的基础信息一致，且存在绕路投诉的历史投诉记录，为所述用车订单标记风险标签；和/或

确定在第一时长内，历史投诉记录的数量大于或等于第一数值，为所述用车订单标记风险标签。

6.根据权利要求5所述的订单处理方法，其特征在于，确定存在与所述用车订单的基础信息一致，且存在绕路投诉的历史投诉记录，为所述用车订单标记风险标签的步骤，还包括：

确定所述历史投诉记录所对应的历史行程的行程开始时间，以及根据所述行程开始时间与当前时间确定第二时长；

确定所述第二时长小于或等于第三时长，为所述用车订单标记风险标签。

7.根据权利要求5所述的订单处理方法，其特征在于，所述基础信息包括：用车订单的起点信息和/或用车订单的终点信息。

8.根据权利要求3所述的订单处理方法，其特征在于，所述根据预先存储的标签标记规则对所述用车订单进行标记的步骤，具体包括：

获取发出所述用车订单的用户的客服提报记录，其中，所述客服提报记录中存储有指路行为的历史行程；

确定存在与所述用车订单的基础信息一致，且被标记存在指路行为的历史行程，为所述用车订单标记风险标签。

9.根据权利要求2至8中任一项所述的订单处理方法，其特征在于，在获取用车订单的轨迹信息和所述用车订单的规划路线的步骤之前，还包括：

监测所述用车订单的时序事件信息，确定接收到所述时序事件信息包含的开始计费信息，执行获取用车订单的轨迹信息和所述用车订单的规划路线的步骤；以及

确定接收到所述时序事件信息包含的停止计费信息，停止获取用车订单的轨迹信息。

10.根据权利要求2至8中任一项所述的订单处理方法，其特征在于，还包括：

将所述确认指令与所述用车订单进行存储。

11.一种订单处理***，其特征在于，包括：

控制器；

存储器，用于存储计算机程序；

所述控制器执行存储在所述存储器中的计算机程序以实现如权利要求1至10中任一项所述的订单处理方法的步骤。

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

Images