订单处理方法、处理服务器及存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及一种订单处理方法、处理服务器及存储介质。

背景技术

随着出行便捷性的增加，出行方式的多样性也随之增加，出行过程中乘客获得的服务质量也参差不齐。当乘客再确认其获得的出行服务与其预期获得的出行服务不一致时，乘客会进行投诉操作。

传统的投诉处理方法为人工处理，即人工受理投诉所需数据，并按照收集的数据进行人工判断以得到投诉处理结果，但是，不同的人处理投诉的标准不同，获得的投诉处理结果也不同，易造成处理结果的不准确，且人工处理效率低，导致投诉处理周期长。为了提高人工处理的效率，业务服务平台利用订单处理模型处理上述处于多种投诉场景下的投诉数据以获得投诉结果，但是，处理多种投诉场景下的投诉数据的同一订单处理模型的处理逻辑复杂，且在用户对处理结果不满意的情况下，仍需要人工介入以重新处理，仍旧导致订单处理效率低，此外，该处理逻辑复杂的订单处理模型对各种投诉场景的处理过程无针对性，导致各投诉场景下的处理准确率参差不齐，部分投诉场景下的处理准确率低。

因此，如何提高订单处理的效率和准确率成为亟待解决的问题。

发明内容

本申请提供一种订单处理方法、处理服务器及存储介质，用以解决提高订单处理的效率和准确率的技术问题。

第一方面，本申请提供一种订单处理方法、处理服务器及存储介质，处理服务器获取目标订单的订单信息和待处理类型；

根据待处理类型和映射关系确定处理模型；其中，映射关系为待处理类型和处理模型之间的对应关系；

根据处理模型的输入数据确定订单信息是否完整，在确定订单信息不完整时获取用户输入的补充信息，并使用处理模型对补充信息和订单信息进行处理后输出处理结果。

在上述技术方案中，处理服务器通过获取的目标订单的订单信息和与该目标信息关联的待处理类型，确定对应的处理模型，并在上述订单信息完整的情况下获得处理结果，以实现利用不同的处理模型处理不同的投诉问题，从而降低了处理模型的复杂性，提高了该处理模型的针对性，从而提高了处理结果的准确率，且处理结果是由处理服务器根据输入数据获得的，无需人工做出处理结果的过程，保障了处理标准的一致性，提高了处理准确率和效率。

可选地，待处理类型为确定是否未正确计费，待处理类型对应的处理模型为计费处理模型，计费处理模型的输入数据包括：计费时长、实际计费里程和预计计费里程。

可选地，获取目标订单的订单信息，具体包括：

若目标订单中的行驶路线数据为可获取状态，获取实际行驶路线数据；实际行驶路线数据包括开始计费位置、结束计费位置、多个中间计费位置及各计费位置对应的时间点；

根据开始计费位置、结束计费位置和多个中间计费位置，计算相邻计费位置间的实际计费子里程；

根据实际计费子里程，计算实际计费里程；

根据开始计费位置对应的时间点和结束计费位置对应的时间点，计算计费时长。

可选地，获取目标订单的订单信息，具体包括：

获取目标订单的预设行驶路线数据，预设行驶路线数据包括开始计费位置和预设结束计费位置；

根据开始计费位置和预设结束计费位置，确定预计计费里程。

可选地，获取目标订单的订单信息，具体包括：

若目标订单中的行驶路线数据为不可获取状态，获取目标订单完成时车辆上传至业务服务器的计费时长和该时长对应的计费距离，将实际计费里程确定为计费距离，并将预计计费里程确定为预设计费里程数据。

可选地，使用处理模型对补充信息和订单信息进行处理后输出处理结果，具体包括：

当计费时长小于或等于预设计费时长阈值，实际计费里程小于或等于预设实际计费里程阈值，且预计计费里程大于或等于预设计费里程阈值时，确定目标订单未正确计费并输出处理结果。

可选地，待处理类型为确定订单状态是否异常，待处理模型对应的处理模型为订单异常处理模型，订单异常处理模型的输入数据包括：司机用户与乘客用户之间的通信数据、实际行驶路线数据、预设行驶路线数据。

可选地，使用处理模型对补充信息和订单信息进行处理后输出处理结果，具体包括：

对通信数据进行处理，确定司机用户对乘客用户修改目标订单状态的诱导状态；诱导状态包括已诱导状态和未诱导状态；

根据实际行驶路线数据，以预设时间间隔采样实际行驶路线数据，获得行驶采样数据集；行驶采样数据集包括多个行驶子数据，行驶子数据包括子行驶距离；

当诱导状态为已诱导状态，且行驶采样数据集中任一子行驶距离小于预设距离阈值，确定目标订单状态异常并输出处理结果。

可选地，使用处理模型对补充信息和订单信息进行处理后输出处理结果，具体包括：

根据实际行驶路线数据和预设行驶路线数据，获得接驾时间范围对应的实际接驾行驶路线数据和接驾时间范围对应的预设接驾行驶路线数据；

根据实际接驾行驶路线数据和预设接驾行驶路线数据，确定匹配行驶路线数据；

根据匹配行驶路线数据和预设接驾行驶路线数据，获得匹配率；

当匹配率小于预设匹配阈值时，确定目标订单状态异常并输出处理结果。

可选地，方法还包括：

获取业务平台信息；

根据业务平台信息和目标订单的处理结果，生成申诉确认指令和申诉数据采集指令，申诉确认指令用于获取司机用户或者乘客用户在不认可目标订单的处理结果时发起申诉请求，申诉数据采集指令用于司机用户或者乘客用户在申诉确认后提交申诉数据；

将申诉确认指令和申诉数据采集指令发送至业务平台信息对应的业务服务器；

若接收到业务服务器发送的申诉数据，利用申诉数据更新目标订单的订单信息，并再次使用处理模型对订单信息进行处理后输出处理结果。

可选地，在确定订单信息不完整时获取用户输入的补充信息，具体包括：

根据处理模型的输入数据和目标订单的订单信息，确定待补充信息；

根据目标订单的待处理类型和紧急程度映射表，确定目标订单待处理的紧急程度；

根据紧急程度和提醒时间映射表，确定提醒时间间隔；

根据提醒时间间隔和待补充信息，生成信息补充指令，并将信息补充指令发送至业务服务器；信息补充指令用于按照提醒时间间隔提醒工作人员输入补充信息直至业务服务器获得待补充信息对应的补充信息；

接收业务服务器发送的补充信息，并将补充信息整合进订单信息。

在上述技术方案中，处理服务器针对不同的处理类型确定不同的处理模型，并获得对应的处理所需数据，处理模型只对必要的输入数据进行处理而不是全部数据，以使处理模型更有针对性地解决对应的问题，处理逻辑的复杂度降低了，以此提高了处理结果的准确率和处理效率。此外，处理过程中缺少输入数据或者处理结束后用户对处理结果存疑时，可通过补充数据的方式利用上述处理模型再次进行处理，即使需要人工补入数据，处理服务器也会根据处理类型确定其紧急程度以进行至少一次的提醒，以推进对目标订单的处理进程，保障了处理效率。

第二方面，本申请提供一种处理服务器，包括：处理器以及与处理器通信连接的存储器；

存储器存储计算机执行指令；

处理器执行存储器存储的计算机执行指令，以实现第一方面涉及的订单处理方法。

第三方面，本申请提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机指令，计算机指令被处理器执行时用于实现第一方面涉及的订单处理方法。

本申请提供一种订单处理方法、处理服务器及存储介质，处理服务器获取目标订单的订单信息和待处理类型，根据待处理类型和映射关系确定处理模型以及根据处理模型的输入数据确定订单信息是否完整，在确定订单信息不完整时获取用户输入的补充信息，并使用处理模型对补充信息和订单信息进行处理后输出处理结果，使得处理模型更有针对性地处理订单，且处理模型在数据量完整时做出处理结果以保障该处理模型在每次处理的过程中均采用相同的处理逻辑进行处理，保障了处理结果的准确率。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

图1为本申请一实施例提供的订单处理方法的应用场景图；

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

图3为本申请另一实施例提供的订单处理方法的流程示意图；

图4为本申请另一实施例提供的订单处理方法的信令交互图；

图5为本申请一实施例提供的处理服务器的结构示意图。

通过上述附图，已示出本申请明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围，而是通过参考特定实施例为本领域技术人员说明本申请的概念。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

随着出行便捷性的增加，出行方式的多样性也随之增加，出行过程中乘客获得的服务质量也参差不齐。当乘客再确认其获得的出行服务与其预期获得的出行服务不一致时，乘客会进行投诉操作。

传统的投诉处理方法为人工处理，即人工受理投诉所需数据，并按照收集的数据进行人工判断以得到投诉处理结果，但是，不同的人处理投诉的标准不同，获得的投诉处理结果也不同，易造成处理结果的不准确，且人工处理效率低，导致投诉处理周期长。为了提高人工处理的效率，业务服务平台利用订单处理模型处理上述处于多种投诉场景下的投诉数据以获得投诉结果，但是，处理多种投诉场景下的投诉数据的同一订单处理模型的处理逻辑复杂，且在用户对处理结果不满意的情况下，仍需要人工介入以重新处理，仍旧导致订单处理效率低，此外，该处理逻辑复杂的订单处理模型对各种投诉场景的处理过程无针对性，导致各投诉场景下的处理准确率参差不齐，部分投诉场景下的处理准确率低。

因此，如何提高订单处理的效率和准确率成为亟待解决的问题。

针对上述技术问题，本申请实施例提供一种订单处理方法、服务器及存储介质，旨在解决提高订单处理的效率和准确率的问题。本申请的技术构思是：处理服务器根据订单的处理类型确定对应的处理模型以处理不同场景下的订单，并在确保该处理模型的输入数据完整的情况下处理该数据以获得对应的处理结果，以实现在不同场景下更有针对性地处理对应地问题，降低了模型复杂度，提高了处理的准确率和效率。

图1为本申请提供的订单处理方法的应用场景图，如图1所示，包括处理服务器10、业务服务器11和终端12。其中，终端12中安装有至少一个应用程序，每个应用程序对应一个业务服务器11处理终端12通过该应用程序执行的对应的操作。在一实施例中，终端12中安装有3个应用程序，且上述3个应用程序均应用于车辆驾驶领域。3个应用程序对应3个业务服务器，包括第一业务服务器111、第二业务服务器112和第三业务服务器113。

当用户对目标订单的执行过程不满意时，可通过终端12中安装的应用程序向该应用程序对应的业务服务器11请求订单处理。业务服务器11根据上述请求获取目标订单的订单信息和上述请求对应的类型，并将获取的数据发送至处理服务器10。处理服务器10根据获取的类型确定对应的订单处理模型，以使该模型对上述获得的订单信息进行处理，以获得对目标订单的处理结果。处理服务器10将获得的处理结果发送至对应的业务服务器11，以使该业务服务器11将处理结果发送至终端12。

处理服务器10在处理上述目标订单的过程中，若目标订单中的订单信息不足以支持对应的订单处理模型作出处理结果，即目标订单中的订单信息少于订单处理模型所需的输入数据时，处理服务器10向业务服务器11发送信息补充指令，并在接收到该业务服务器11发送的补充信息之后更新目标订单的订单信息，利用上述订单处理模型处理更新后的订单信息以获得处理结果。

用户通过终端12获得上述处理结果，并在不确认处理结果时进行申诉。业务服务器11向处理服务器10提供申诉数据，处理服务器10根据上述申诉数据更新目标订单的订单信息，并利用订单处理模型再次处理更新后的订单信息，以获得新的处理结果并将其发送至业务服务器11，以使终端12及其对应的用户获得申诉后对目标订单的处理结果。

图2为本申请根据一示例性实施例提供的订单处理方法的流程示意图。如图2所示，本申请提供的订单处理方法，包括：

S201、处理服务器获取目标订单的订单信息和待处理类型。

其中，目标订单为通过网络下单提供打车服务的订单。更具体地，当与目标订单关联的双方对象认为该订单的实际执行过程与预期执行过程不符时，双方对象可通过其持有的终端向该目标订单对应的业务服务器发起订单处理请求，该订单处理请求中包含该订单的待处理类型和目标订单的订单信息。处理服务器获取的目标订单的订单信息和待处理类型是业务服务器发送的上述获得的信息。其中，待处理类型根据实际执行过程与预期执行过程的不同之处确定的。

S202、处理服务器根据待处理类型和映射关系确定处理模型。

其中，待处理类型是从步骤S201获得的。

映射关系为待处理类型和处理模型之间的对应关系。

处理模型为根据处理上述待处理类型对应的问题的模型。

S203、处理服务器根据处理模型的输入数据确定订单信息是否完整，在确定订单信息不完整时获取用户输入的补充信息，并使用处理模型对补充信息和订单信息进行处理后输出处理结果。

其中，处理模型是从步骤S202中获得的，处理模型的输入数据为保障该处理模型做出正确处理结果所需要输入的数据。

当处理模型的所需输入数据在步骤S201中获得的目标订单的订单信息中均存在时，该订单信息完整，否则，该订单信息不完整。

当订单信息完整时，处理服务器直接通过处理模型处理上述完整的订单信息，以获得并输出订单结果。

当订单信息不完整时，需要再次获取补充信息直至上述订单信息包含所有的处理模型的输入数据。

处理服务器利用上述补充信息更新订单信息，并通过处理模型处理更新后的、完整的订单信息，以获得并输出处理结果。

在上述技术方案中，处理服务器通过获取的目标订单的订单信息和与该目标信息关联的待处理类型，确定对应的处理模型，并在上述订单信息完整的情况下获得处理结果，以实现利用不同的处理模型处理不同的投诉问题，从而降低了处理模型的复杂性，提高了该处理模型的针对性，从而提高了处理结果的准确率，且处理结果是由处理服务器根据输入数据获得的，无需人工做出处理结果的过程，保障了处理标准的一致性，提高了处理准确率和效率。

图3为本申请根据一实施例提供的订单处理方法的流程示意图，该方法的执行主体为处理服务器。如图3所示，本申请提供的订单处理方法，包括：

S301、获取待处理类型，并根据待处理类型和映射关系确定处理模型。

其中，待处理类型已在步骤S201中进行解释，映射关系及处理模型已在步骤S202中进行解释，此处均不再赘述。

待处理类型为确定是否正确计费，该待处理类型对应的处理模型为计费处理模型，该计费处理模型的输入数据包括：计费时长、实际计费里程和预计计费里程。

S302、判断目标订单中的行驶路线数据的状态。

其中，目标订单包括订单信息，该订单信息为步骤S301中的处理模型做出订单处理结果的依据。该订单信息包括行驶路线数据。

若行驶路线数据为可获取状态，进入步骤S303；若行驶路线数据为不可获取状态，进入步骤S309。其中，行驶路线数据不可获取状态是由两种情况产生的，第一种是行驶路线数据在数据传输或者储存的过程中丢失导致的，第二种情况是司机在提供打车服务时，忘记计费操作使得车辆未记录行驶路线数据导致的，该打车服务包括但不限于出租打车、顺风打车、网约打车。

S303、获取实际行驶路线数据。

实际行驶路线数据包括开始计费位置、结束计费位置、及多个中间计费位置及各计费位置对应的时间点；

S304、根据开始计费位置、结束计费位置和多个中间计费位置，计算相邻计费位置间的实际计费子里程。

其中，开始计费位置、结束计费位置和多个中间计费位置均是从步骤S303获得的。

计算相邻计费位置间的实际计费子里程的过程为：将上述多个计费位置按照时间顺序进行排列，按照相同的时间变化方向，依次计算相邻两个计费时间对应的计费位置间的距离，以获得相邻计费位置间的实际计费子里程。

S305、根据实际计费子里程，计算实际计费里程。

其中，实际计费子里程是从步骤S304获得的。

实际计费里程是将上述获得的所有的实际计费子里程相加后得到的。

S306、根据开始计费位置对应的时间点和结束计费位置对应的时间点，计算计费时长。

开始计费位置对应的时间点和结束计费位置对应的时间点均是从步骤S303获得的。

S307、获取目标订单的预设行驶路线数据。

预设行驶路线数据包括开始计费位置和预设结束计费位置。

预设行驶路线数据是生成目标订单的业务服务器在订单开始计费时，从开始计费位置到目标订单中的预设结束计费位置间，提供打车服务的司机的惯用行驶路线。

S308、根据开始计费位置和预设结束计费位置，确定预计计费里程。

其中，开始计费位置和预设结束计费位置是从步骤S307获得的。

预计计费里程为开始计费位置和预设结束位置间的之间距离的里程。

本步骤完成后，计费处理模型所需要的输入数据全部获取完成，进入步骤S310。

S309、获取目标订单完成时车辆上传至业务服务器的计费时长和该时长对应的计费距离，将实际计费里程确定为计费距离，并将预计计费里程确定为预设计费里程数据。

由于目标订单的行驶路线数据为不可获取状态，若行驶路线数据的不可获取状态是由上传和存储的过程中丢失导致的，可通过业务服务器获得上述目标订单完成时车辆上传至业务服务器并储存在业务服务器中的计费时长和计费距离，其中，计费时长为提供打车服务的司机在终端上执行开始计费的操作和结束计费的操作之间，终端在上述两个操作对应的时间点间的时间差；实际计费里程为车辆在上述两个时间点对应的里程记录表显示的里程数据的差值。

若驶路线数据的不可获取状态是由提供打车服务的司机忘记计费导致的，则将计费时长置零，实际计费里程置零。

S310、当计费时长小于或等于预设计费时长阈值，实际计费里程小于或等于预设实际计费里程阈值，且预计计费里程大于或等于预设计费里程阈值时，确定目标订单未正确计费并输出处理结果。

其中，计费时长是从步骤S309或者步骤S306获得的，实际计费里程是从步骤S305或者步骤S309获得的，预计计费里程是从步骤S308或者步骤S309获得的。

当计费时长小于或等于预设计费时长阈值，实际计费里程小于或等于预设实际计费里程阈值，且预计计费里程小于或等于预设计费里程阈值时，表示提供打车服务的司机未到达目标订单的预设结束计费位置即停止为乘客提供打车服务，导致本次订单的计费与实际所提供的服务不对等，因此该计费处理模型确定目标订单未正确计费，业务服务器将上述表示目标订单未正确计费的处理结果输出至业务服务器，以使业务服务器将上述处理结果发送至终端对应的应用程序中。

在上述技术方案中，处理服务器针对确认是否计费正确的处理类型，从目标订单的订单信息获取对应的模型所需输入数据，降低了模型处理的数据量和模型复杂度，以提高处理效率，且该模型完全依靠输入数据做出处理结果，保障了每次处理过程的一致性，从而提高了处理准确率。

图4为本申请另一实施例提供的订单处理方法的信令交互图，该方法为处理服务器和业务服务器之间的信息交互。如图4所示，本申请提供的订单处理方法，包括：

S401、业务服务器向处理服务器发送待处理类型和目标订单的订单信息。

其中，待处理类型为确定订单状态是否异常。

目表订单的订单信息与该待处理类型对应的处理模型的输入数据相关联。

S402、处理服务器根据待处理类型和映射关系确定处理模型。

其中，待处理类型是从步骤S401获得的。

映射关系为待处理类型和处理模型之间的对应关系。

与上述待处理类型为确定订单状态是否异常的处理模型为订单异常处理模型。该模型的输入数据包括：司机用户与乘客用户之间的通信数据、实际行驶路线数据、预设行驶路线数据。更具体地，司机用户与乘客用户之间的通信数据包括语音通信和即时通信。

S403、根据处理模型的输入数据和目标订单的订单信息，确定待补充信息。

其中，处理模型的输入数据是从步骤S402获得的，目标订单的订单信息是从步骤S401获得的。

待补充信息的确定是从处理模型的输入数据中获得输入数据中存在，但目标订单的订单信息中没有的信息或者与上述输入数据内容不匹配的信息。

S404、处理服务器根据目标订单的待处理类型和紧急程度映射表，确定目标订单待处理的紧急程度。

其中，紧急程度映射表表示待处理类型和目标订单待处理的紧急程度间的映射关系。

S405、处理服务器根据紧急程度和提醒时间映射表，确定提醒时间间隔。

其中，紧急程度是从步骤S404获得的。

提醒时间映射表表示紧急程度的提醒时间间隔间的映射关系，其中，紧急程度包含多个紧急等级，提醒时间间隔包含多个时间段，紧急等级的等级越高，其对应的提醒时间间隔的时间段越短。

S406、处理服务器根据提醒时间间隔和待补充信息，生成信息补充指令。

其中，提醒时间间隔是从步骤S405获得的，待补充信息是从步骤S403获得的。

信息补充指令用于按照提醒时间间隔提醒工作人员输入补充信息直至业务服务器获得待补充信息对应的补充信息。

S407、处理服务器向业务服务器发送信息补充指令。

其中，信息补充指令是从步骤S406获得的。

S408、业务服务器向处理服务器发送补充信息。

其中，补充信息为业务服务器的工作人员按照信息补充指令从业务服务器的输入单元输入的信息。

S409、处理服务器将补充信息整合进订单信息。

其中，补充信息是从步骤S408获得的。

将补充信息整合进订单信息是指将补充信息添加或者替换进订单信息中。

在一实施例中，订单信息包括司机用户与乘客用户之间的通信数据、实际行驶路线数据、预设行驶路线数据，其中，司机用户与乘客用户之间的通信数据缺失，实际行驶路线数据正常，预设行驶路线数据存在但有错误，因此，处理服务器生成针对司机用户与乘客用户之间的通信数据和预设行驶路线数据的信息补充指令，在获得业务服务器补充完整的信息后，将获得的司机用户与乘客用户之间的通信数据补充进订单信息，将预设行驶路线数据替换订单信息中的原有数据。

根据上述更新后的订单信息，上述订单异常处理模型可以在两种处理情况下处理目标订单是否异常。其中，第一种订单异常处理情况是订单异常处理模型通过车辆接驾情况确定目标订单是否异常，第二种订单异常处理情况是订单异常处理模型通过司机用户接驾之后行驶过程中车辆的驾驶情况及与该目标订单对应的预设时间范围内司机用户与乘客用户之间的通信数据确定目标订单是否异常，其中，目标订单对应的预设时间范围包括接驾过程、行驶过程及行驶结束后对应的时间范围。

更具体地，第一种情况的处理过程为步骤S410至S413，第二种情况的处理过程为步骤S414至S416。

S410、处理服务器根据实际行驶路线数据和预设行驶路线数据，获得接驾时间范围对应的实际接驾行驶路线数据和接驾时间范围对应的预设接驾行驶路线数据。

其中，实际行驶路线数据和预设行驶路线数据是从步骤S409中的订单信息中获得的。

接驾时间范围是指司机用户确认接单时间点至开始计费时间点之间的时间范围。

实际接驾行驶路线数据是指实际行驶路线数据中司机用户确认接单的接单位置和开始计费位置间的行驶路线数据。

预设接驾行驶路线数据是指预设行驶路线数据中司机用户确认接单的接单位置与目标订单的预设开始计费位置之间的行驶路线数据。

S411、处理服务器根据实际接驾行驶路线数据和预设接驾行驶路线数据，确定匹配行驶路线数据。

其中，实际接驾行驶路线数据和预设接驾行驶路线数据是从步骤S410获得的。

匹配行驶路线数据是指实际接驾行驶路线数据和预设接驾行驶路线数据中重合的行驶路线数据。

S412、处理服务器根据匹配行驶路线数据和预设接驾行驶路线数据，获得匹配率。

其中，匹配行驶路线数据是从步骤S411获得的，预设接驾行驶路线数据是从步骤S410获得的。

匹配率是根据匹配行驶路线数据的里程数据除以预设接驾行驶路线数据的里程数据获得的。

S413、当匹配率小于预设匹配阈值时，处理服务器确定目标订单状态异常。

其中，匹配率是从步骤S412获得的。

当匹配率小于预设匹配阈值时，订单异常处理模型确定目标订单状态异常，即该目标订单的司机用户在接驾过程中偏离预设路线，以导致乘客用户未能按照预期要求接收司机用户提供的打车服务，以导致对目标订单的状态存疑。

在已确定目标订单状态的本步骤结束后，直接进入步骤S417。

S414、处理服务器对通信数据进行处理，确定司机用户对乘客用户修改目标订单状态的诱导状态。

其中，通信数据是从步骤S409中更新的订单信息中获得的。

处理服务器对通信数据进行处理的过程分成两种情况：

当该通信数据为语音通信数据时，处理服务器根据储存在本地的语音识别模型和语义分析模型依次进行处理，获得该语音通信数据中是否包含含有诱导关联的通信数据，并确定司机用户是否存在对乘客用户出现修改目标订单状态的诱导状态。其中，语音识别模型和语义分析模型的处理过程为现有技术，此处不再赘述。

在一实施例中，司机用户与乘客用户之间的语音通信为司机用户在拨打电话的过程中，利用其对应手机号的虚拟号拨打服务与用户进行通话以保留语音通信数据。更具体地，用户终端通过呼叫与虚拟号拨打服务器建立联系，该服务器根据呼叫号码分配对应的虚拟号码并利用该虚拟号码呼叫乘客用户终端的手机号码，在虚拟号码和乘客用户的手机号码间建立通信通道后，调用语音数据存储功能，以保存语音通信数据。其中，上述语音通信数据的拨打方和接收方各使用一个声道，有助于更好地区分司机用户的语音数据和乘客用户的语音数据，保障了上述语音识别模型和语义分析模型对诱导状态确认的准确率。

当该语音数据为即时通信数据时，处理服务器根据储存在本地的语义分析模型把目标订单关联的目标时间范围内的即使通信数据进行处理，以获得司机用户和乘客用户间的多条即时通信数据中是否包含含有与诱导关联的通信数据，并确定司机用户是否存在对乘客用户出现修改目标订单状态的诱导状态。

该诱导状态包括已诱导状态和未诱导状态。

更具体地，上述通信数据对应的时间范围已在步骤S409中详细解释，此处不再赘述。

S415、处理服务器根据实际行驶路线数据，以预设时间间隔采样实际行驶路线数据，获得行驶采样数据集。

其中，实际行驶路线数据是从步骤S409中更新订单信息中获得的。

行驶采样数据集中包含多组实际行驶路线数据信息，每组实际行驶路线数据信息中包含实际行驶位置信息和实际行驶时间信息。

预设时间间隔是指小于或等于实际行驶路线数据对应的时间范围。在一实施例中，预设时间间隔为5分钟。

S416、当诱导状态为已诱导状态，且行驶采样数据集中任一子行驶距离小于预设距离阈值，处理服务器确定目标订单状态异常。

其中，诱导状态是从步骤S414中获得的。

处理服务器利用其内置的订单异常处理模型处理上述订单信息后，确定诱导状态为已诱导状态，且行驶采样数据集中任一子行驶距离小于预设距离阈值，则确定该目标订单状态异常，即司机用户在驾驶的过程中未能按照预定规则提供打车服务，并对乘客用户进行诱导，使乘客用户未能获得该目标订单中所需提供的预设服务。

S417、业务服务器向处理服务器发送业务平台信息。

其中，业务平台信息是指业务服务器的基本信息及该服务器对应的应用程序的基本信息。

处理服务器获得该业务平台信息用于获得将步骤S413或者步骤S416获得的目标订单状态判定结果发送至处理服务器并控制该服务器将上述判定结果发送至对应的终端的必要信息。其中，关于该信息的解释为现有技术，此处不再赘述。

S418、处理服务器根据业务平台信息和目标订单的处理结果，生成申诉确认指令和申诉数据采集指令。

其中，业务平台信息是从步骤S417获得的业务服务器发送的信息。

目标订单的处理结果是从步骤S413或者步骤S416获得的。

申诉确认指令是指获得上述处理结果的数据的用户对该处理结果不认可，在其确认为获得上述处理结果所输入处理模型的数据存在异常时，该用户可通过本申诉确认指令来进行对应的申诉操作。其中，该申诉确认指令中包含上诉目标订单的处理结果。

申诉数据采集指令表示用户在进行申诉时，进行处理模型的所需输入数据的重新上传。更具体地，若用户不需要申诉，则亦不需要上传上述申诉数据。

S419、处理服务器向业务服务器发送申诉确认指令和申诉数据采集指令。

其中，申诉确认指令和申诉数据采集指令均是从步骤S418中获得的。

业务服务器根据上述申诉确认指令将其包含的目标订单的处理结果及确认用户是否进行申诉的数据发送至终端，并接收与该用户通过终端确认的是否进行申诉的信息。

当用户通过其对应的终端确认进行申诉操作后，业务服务器根据申诉数据采集指令向该终端发送对应的数据采集接口，在用户通过该终端输入申诉数据并确认申诉数据已填写完成后，将获得终端发送的申诉数据。

S420、业务服务器向处理服务器发送申诉数据。

其中，申诉数据是从步骤S419获得的。

S421、处理服务器利用申诉数据更新目标订单的订单信息。

其中，申诉数据是从步骤S420获得的业务服务器发送的数据。

处理服务器利用申诉数据更新目标订单的订单信息是指将申诉数据按照其数据类型覆盖或补充进对应的订单信息中，其中，订单信息的更新过程与步骤S409中的信息整合的过程相同，此处不再赘述。

在上述技术方案中，处理服务器针对不同的处理类型确定不同的处理模型，并获得对应的处理所需数据，处理模型只对必要的输入数据进行处理而不是全部数据，以使处理模型更有针对性地解决对应的问题，处理逻辑的复杂度降低了，以此提高了处理结果的准确率和处理效率。此外，处理过程中缺少输入数据或者处理结束后用户对处理结果存疑时，可通过补充数据的方式利用上述处理模型再次进行处理，即使需要人工补入数据，处理服务器也会根据处理类型确定其紧急程度以进行至少一次的提醒，以推进对目标订单的处理进程，保障了处理效率。

如图5所示，本申请一实施例提供一种处理服务器500，处理服务器500包括存储器501和处理器502。

其中，存储器501用于存储处理器可执行的计算机指令。

处理器502在执行计算机指令时实现上述实施例中以处理服务器为执行主体的订单处理方法中的各个步骤。具体可以参见前述方法实施例中的相关描述。

可选地，上述存储器501既可以是独立的，也可以跟处理器502集成在一起。当存储器501独立设置时，该处理服务器500还包括总线，用于连接存储器501和处理器502。

本申请实施例还提供一种计算机程序产品，包括计算机指令，该计算机指令被处理器执行时实现上述实施例中订单处理方法中的各个步骤。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求书指出。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求书来限制。