CN112053087A - 投诉工单的处理方法、装置、设备及存储介质 - Google Patents

Abstract

本公开的实施例提供一种投诉工单的处理方法、装置、设备及存储介质。该方法包括：获取投诉工单和与投诉工单对应的订单；获取投诉工单所属用户的用户数据，用户数据包括如下一项或多项：用户的信用数据、用户的历史投诉数据；根据投诉工单、订单和用户数据，确定工单处理测量；按照工单处理策略，对投诉工单进行处理。本公开的实施例的方法，依据投诉工单、订单和用户数据，为投诉工单确定有针对性的工单处理策略，实现对不同投诉工单的分流处理，提高了投诉工单的处理效果。

Description

投诉工单的处理方法、装置、设备及存储介质

技术领域

本公开的实施例涉及计算机技术领域，尤其涉及一种投诉工单的处理方法、装置、设备及存储介质。

背景技术

为了给用户提供更到位的服务和提升自身的产品质量，互联网服务平台为用户提供有订单投诉服务和相应的赔偿服务。用户在订单完成后，可以通过对订单进行投诉的方式，反馈自身对该订单的不满和建议，服务提供商在调查属实后，会给予用户相应的赔偿。

相关技术中，互联网服务平台在接收到用户对订单的投诉后，为被投诉订单建立相应的投诉工单，通常按照投诉的发起时间，确定投诉工单的处理优先级。客服人员按照投诉工单的处理优先级顺序，处理用户的投诉。

发明人发现，投诉工单中存在占比较高的虚假投诉工单，虚假投诉工单带来的影响，一是影响到非虚假投诉工单的及时处理，二是增加了服务提供商的经济损失。上述投诉工单处理方式未考虑到虚假投诉情况，导致投诉工单的处理效果不佳。

发明内容

本公开的实施例提供一种投诉工单的处理方法、装置、设备及存储介质，用以解决投诉工单处理效果不佳的问题。

第一方面，本公开的实施例提供一种投诉工单的处理方法，包括：

获取投诉工单和与投诉工单对应的订单；

获取所述投诉工单所属用户的用户数据，所述用户数据包括如下一项或多项：所述用户的信用数据、所述用户的历史投诉数据；

根据所述投诉工单、所述订单和所述用户数据，确定工单处理策略；

按照所述工单处理策略，对所述投诉工单进行处理。

第二方面，本公开的实施例提供一种投诉工单的处理装置，包括：

获取模块，用于获取投诉工单和与所述投诉工单对应的订单，获取所述投诉工单所属用户的用户数据，所述用户数据包括如下一项或多项：所述用户的信用数据、所述用户的历史投诉数据；

确定模块，用于根据所述投诉工单、所述订单和所述用户数据，确定工单处理策略；

处理模块，用于按照所述工单处理策略，对所述投诉工单进行处理。

第三方面，本公开的实施例提供一种电子设备，包括：

存储器和处理器；

所述存储器用于存储程序指令；

所述处理器用于调用所述存储器中的程序指令执行如上述第一方面所述的方法。

第四方面，本公开的实施例提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被执行时，实现如上述第一方面所述的方法。

第五方面，本公开的实施例提供一种包含指程序指令的程序产品，所述程序产品包括计算机程序，所述计算机程序被处理器执行时实现如第一方面所述的方法。

本公开的实施例提供的一种投诉工单的处理方法、装置、设备及存储介质，获取投诉工单、投诉工单所对应的订单和投诉工单所属用户的用户数据，依据投诉工单、投诉工单所对应的订单和投诉工单所属用户的用户数据，确定投诉工单的工单处理策略，按照工单处理策略，对投诉工单进行处理，其中，用户数据包括如下一项或多项：用户的信用数据、用户的历史投诉数据。因此，结合投诉工单、投诉工单所对应的订单以及用户的信用数据和/或历史投诉数据，来确定工单处理策略，实现对不同投诉工单的分流处理，尤其能够针对虚假投诉工单进行区别处理，以提高投诉工单的处理效果。

本公开的各种可行实施例及其技术优势将在下文详述。

附图说明

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

图1为本公开的实施例适用的应用场景示例图；

图2为本公开的一实施例提供的投诉工单的处理方法的流程示意图；

图3为本公开的另一实施例提供的投诉工单的处理方法的流程示意图；

图4为本公开的另一实施例提供的投诉工单的处理方法的流程示意图；

图5为本公开的另一实施例提供的投诉工单的处理方法的流程示意图；

图6为本公开的另一实施例提供的投诉工单的处理方法的流程示意图；

图7为利用本公开实施例提供的投诉工单处理方法建立的乘客虚假投诉智能决策系统的示例图；

图8为本公开的一实施例提供的投诉工单的处理装置的结构示意图；

图9为本公开的一实施例提供的一种电子设备的结构示意图；

图10为本公开的一实施例提供的投诉工单的处理装置的框图。

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

具体实施方式

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

首先对本公开的实施例所涉及的名词进行解释：

投诉订单：用户可针对自身与商家之间成立的订单发起投诉，在接到投诉时，商家所提供的服务平台会建立相应的投诉工单，并由客服人员对投诉工单进行处理。其中，用户可能对一个订单发起多次投诉，所以，一个订单可能与一个或多个投诉工单对应。

在互联网服务平台，以网约车平台为例，乘客可以在网约车平台上发起约车请求，若司机在网约车平台接受该约车请求，则乘客、司机和网约车的服务提供商三者之间成立网约车订单，在网约车订单中，乘客为服务接受方，司机和服务提供商为服务提供方。网约车订单的最终状态可能是取消状态，也可能是完成状态，例如，可能因为乘客迟到或者司机迟到的行为，导致网约车订单最终被取消。在网约车订单结束后，乘客若是对在网约车订单中享受的服务不满意，则可以对网约车订单发起投诉，反馈自身对打车订单的不满和建议。服务提供商在调查属实后，会给予乘客相应的赔偿，例如赔偿现金、赔偿优惠券。

在实际的投诉场景中，投诉工单中存在占比较高的虚假投诉工单，例如部分乘客可能为了获得现金、优惠券等赔偿而频繁发起不符合真实情况的投诉，为描述简洁，在此将不符合真实情况的投诉称为虚假投诉，将因不符合真实情况的投诉而建立的投诉工单，称为虚假投诉工单。这些虚假投诉工单给服务提供商带来直经济损失，也导致投诉工单数量激增，影响到正常投诉工单的处理效果和效率，进而影响到其他乘客的服务体验。

相关技术中，互联网服务平台通常按照投诉的发起时间，确定投诉工单的处理优先级，并按照投诉工单的处理优先级顺序，处理用户的投诉。这种方式未对虚假投诉工单进行识别和管控，投诉工单处理效果不佳。

相关技术中，还可以通过建立判责模型来预测投诉工单的责任方是用户还是服务提供方(例如，在网约车场景中，服务提供方为司机或者网约车服务提供商)，如果预测投诉工单的责任方为用户，则确定投诉工单为虚假投诉工单。但是发明人发现，为了避免发生用户投诉判责的误判，换句话说，为了避免将责任方为服务提供方的情形误判为责任方为用户，通常会为判责模型设置较高的准确度，这将导致虚假投诉工单的召回率不高，换句话说，虚假投诉工单的查全率不高，经过判责模型筛选的投诉工单中还是存在占比较高的虚假投诉工单。

为了解决上述问题，本公开实施例提供了一种投诉工单的处理方法，该方法获取投诉工单和与投诉工单对应的订单，获取投诉工单所属用户的用户数据，根据投诉工单、订单和用户数据，确定工单处理策略，按照工单处理策略对投诉工单进行处理，其中，用户数据包括如下一项或多项：用户的信用数据、用户的历史投诉数据，投诉工单、订单、用户的信用数据、用户的历史投诉数据都能够在一定程度上有助于确定投诉工单是否为虚假投诉工单，结合这些数据可以提高虚假投诉工单的召回率。因此，依据投诉工单、订单、用户数据来确定工单处理策略，能够对不同的投诉工单进行区别处理，尤其是能够对虚假投诉工单进行区别处理，进而能够提高投诉工单的处理效果和处理效率。

本公开的实施例提供的投诉工单的处理方法，可以适用于各类互联网服务的投诉场景，例如，网上购物的投诉场景、网约车的投诉场景、网上点餐的投诉场景。图1以网约车的投诉场景为例，如图1所示，该投诉场景包括：乘客终端101、网约车服务平台所在的服务器102、网络103，其中，乘客终端101、服务器102之间通过网络103通信，服务器102可以包括一个或多个服务器，例如，服务器102包括用于存储用户数据的服务器、用于存储并处理订单业务的服务器、用于处理存储并处理投诉业务的服务器。

如图1所示，投诉场景还可包括服务提供商终端104。服务提供商可以通过服务提供商终端104，在服务器102上查看订单、投诉工单的状态并进行相应的统计或处理操作。例如，服务提供商的客服人员在服务提供商终端104上为投诉工单提供人工服务。

在投诉场景中，乘客可通过乘客终端101向服务器102发送投诉请求，服务器102可针对投诉请求，建立相应的投诉工单。服务器102可以初步确定投诉工单的工单处理策略，按照工单处理策略，对投诉工单进行处理。例如，当投诉工单的工单处理策略为人工处理时，服务器102可以将投诉工单发送至服务提供商终端104，提醒客服人员对投诉工单进行人工处理。

其中，乘客终端101、服务提供商终端设备104比如为移动设备(例如手机、平板电脑、可穿戴式智能设备)、计算机、车载设备，服务器102比如为单个服务器、服务器群(比如分布式服务器、集中式服务器)、云服务器中的一种或任一组合。

需注意，本公开实施例中“乘客”为“用户”在网约车场景中的称谓。

下面以具体的实施例对本公开的实施例的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本公开的实施例的实施例进行描述。

图2为本公开的一实施例提供的投诉工单的处理方法的流程示意图，执行主体例如为图1所示的服务器。如图2所示，该方法包括：

S201、获取投诉工单和与投诉工单对应的订单。

其中，在检测到用户针对一个或多个订单发起投诉请求时，为该一个或多个订单分别建立对应的投诉工单。因此，一个投诉工单通常对应一个订单。

本实施例中，可从预先存储的投诉工单和订单中，获取一个或多个待处理的投诉工单、以及与各待处理的投诉工单对应的订单。或者，也可以获取实时生成的一个或多个投诉工单，在预先存储的订单中，获取与各实时生成的投诉工单对应的订单，以对投诉工单进行及时处理。

S202、获取投诉工单所属用户的用户数据，用户数据包括如下一项或多项：用户的信用数据、用户的历史投诉数据。

其中，用户的信用数据是指能够表征用户信用情况的用户数据，例如用户进行虚假投诉的次数、用户延迟支付订单的次数，用户的历史投诉数据是指用于表征用户投诉情况的用户数据，例如，用户的投诉订单的总数量。

本实施例中，可在投诉请求或者投诉工单中，获取投诉工单所属用户的用户标识，在存储用户数据的数据库中，查找用户标识所对应的用户数据，从而得到投诉工单所属用户的用户数据。其中，用户标识例如为用户ID、用户手机号、用户账号名、用户邮箱等，存储用户数据的数据库可以位于当前服务器上，也可以位于与当前服务器通信的其它服务器上。

S203、根据投诉工单、订单和用户数据，确定工单处理策略。

本实施例中，可以预设设置多个工单处理策略，并为各个工单处理策略分别对应的工单条件，例如，内容为“与投诉工单对应的订单被投诉的总次数超过预设的第一次数阈值、用户数据中用户进行虚假投诉的次数超过预设的第二次数阈值、且用户数据中用户投诉订单的总数量超过预设的第一数量阈值”的工单条件所对应的工单处理策略为“机器处理”。因此，在确定投诉工单的工单处理策略时，可以根据投诉工单、与投诉工单对应的订单和用户数据，确定投诉工单满足的工单条件，将投诉工单满足的工单条件所对应的工单处理策略，确定为投诉工单的工单处理策略。

本实施例中，结合投诉工单、与投诉工单对应的订单和用户数据，来确定工单处理策略，能够提高工单处理策略的合理性，并能够从中区分出虚假投诉工单，为虚假投诉工单采用相应的工单处理策略。

S204、按照工单处理策略，对投诉工单进行处理。

本实施例中，在确定工单处理策略后，按照工单处理策略，对投诉工单进行处理，以对不同投诉工单进行分流处理，尤其是对虚假投诉工单进行区别处理，提高投诉工单的处理效率和效果。

本公开实施例中，根据投诉工单、与投诉工单对应的订单和用户数据，确定工单处理策略，按照工单处理策略，对投诉工单进行处理，实现对不同投诉工单的分流处理，且通过投诉工单、与投诉工单对应的订单和用户数据这些更为全面的数据，提高投诉工单中虚假投诉工单的召回率，提高投诉工单的处理效率和效果。

图3为本公开的另一实施例提供的投诉工单的处理方法的流程示意图，执行主体例如为图1所示的服务器。如图3所示，该方法包括：

S301、获取投诉工单和与投诉工单对应的订单。

本实施例中，S301的详细内容可参照S201的相关描述。

本实施例中，在获取投诉工单时，可获得投诉工单的工单信息，在获取与投诉工单对应的订单时，可获得与投诉工单对应的订单的订单信息。

其中，投诉工单的工单信息可包括如下的一项或多项：工单生成时间、工单标题、工单内容、工单状态。投诉工单的生成时间可以是接收到用户发起的投诉请求的时间、也可以是针对用户发起的投诉请求建立投诉工单的时间。投诉工单的工单标题可以体现投诉工单的类型，换句话说，可以体现投诉工单所对应的场景，例如，网约车投诉工单的工单标题可以包括“司机绕路”、“未坐车但产生费用”、“司机态度恶劣”、“司机多收附加费”。投诉工单的工单内容是指用户的投诉原因和诉求，例如“因司机绕路请求退回多收金额”。投诉工单的工单状态可以包括待处理状态和处理完成状态，处理完成状态又可以包括是否获得赔偿、赔偿方式等。

其中，订单的订单信息可包括如下的一项或多项：订单成立时间、订单标题、订单状态、订单金额、订单内容。订单的订单成立时间也可以称为订单的订单生成时间，例如在网约车订单的订单成立时间可以为司机接单的时间。订单的订单标题可以体现订单的类型，换句话说，可以体现订单所对应的场景，例如，网约车订单的订单标题可以为“快车”、“顺风车”等。订单的订单状态可以包括如下的一项或多项：发单状态、完单状态、取消状态、迟到状态、投诉状态。例如，网约车订单在成立后，订单状态为发单状态，如果司机在规定的时间内未到达用户所在地，则网约车订单的订单状态变更为迟到状态，此时如果用户取消订单，则网约车订单的订单状态变更为取消状态，如果用户未取消订单，最终等来司机并坐车达到目的地，订单完成，则网约车订单的订单状态变更为完单状态，如果用户针对完单状态或者取消状态的网约车订单发起投诉，则网约车订单的订单状态变更为投诉状态。订单的订单金额可以包括用户在订单中支付的总金额，还可以包括用户在订单中支付的各项金额，例如网约车订单的订单金额包括起步价、里程费、时长费。订单内容可以包括订单的服务内容，例如网约车订单的订单内容包括出发地、目的地、出发地到目的地之间的行程路径、行程时间、司机信息等。

S302、获取投诉工单所属用户的用户数据，用户数据包括如下一项或多项：用户的信用数据、用户的历史投诉数据。

本实施例中，S302的详细内容可参照S202的相关描述，不在赘述。

S303、根据投诉工单和订单，对投诉工单判责，得到判责结果。

其中，投诉工单的判责结果可包括两个判责结果，一个判责结果是在投诉工单中用户有责，另一个判责结果是在投诉工单中用户无责。

本实施例中，可以根据投诉工单的工单信息和与投诉工单对应的订单的订单信息，对投诉工单进行判责，以提高投诉工单的判责准确度。可以将投诉工单的工单信息与订单的订单信息进行比较，来确定用户在投诉工单中所反映的投诉原因是否真实，最终确定投诉工单中用户是否有责。例如，在投诉工单的工单标题为“司机绕路”时，可以依据订单信息中出发地到目的地之间的行程路径，来确定司机是否绕路，如果有，则确定投诉工单中用户无责，否则确定投诉工单中用户有责。

S304、根据判责结果和用户数据，确定工单处理策略。

本实施例中，可以预设设置多个工单处理策略和多个工单条件，并为各个工单处理策略和工单条件建立映射关系，每个工单处理策略分别对应一个工单条件。如果用户数据仅包括用户的信用数据或者用户的历史投诉数据中的一项，则可以将工单条件看作是二元组，二元组中的一个元素与判责结果对应，另一个元素与用户的信用数据或者用户的历史投诉数据对应。如果用户数据包括用户的信用数据和用户的历史投诉数据，则可以将工单条件看作是三元组，三元组中的三个元素分别于判责结果、用户的信用数据、用户的历史投诉数据对应。

本实施例中，在获得投诉工单的判责结果和投诉工单所属用户的用户数据后，可以在多个工单条件中，查找投诉工单所符合的工单条件，获取投诉工单所符合的工单条件对应的工单处理策略，将投诉工单所符合的工单条件对应的工单处理策略，确定为投诉工单的工单处理策略。其中，若投诉工单的判责结果和用户数据分别符合工单条件中相应元素的取值，则确定投诉工单符合该工单条件。

S305、按照工单处理策略，对投诉工单进行处理。

本实施例中，S305的详细内容可参照S204的相关描述，不再赘述。

本公开实施例中，根据投诉工单和与投诉工单对应的订单，确定投诉工单的判责结果，根据判责结果和用户数据，确定工单处理策略，按照工单处理策略，对投诉工单进行处理。因此，通过结合判责结果和用户数据，而非单单依靠判责结果，提高了投诉工单中虚假投诉工单的召回率，实现对不同投诉工单的分流处理，尤其是对虚假投诉工单，进而提高投诉工单的处理效率和效果。

在一些实施例中，投诉工单的判责结果包括投诉工单的判责置信度，换句话说，投诉工单的判责结果包括投诉工单中用户有责的概率。此时，S303的一种可能的实现方式为：根据投诉工单和与投诉工单对应的订单，通过预设的判责模型，对投诉工单进行判责，得到投诉工单的判责置信度。

本实施例中，可将投诉工单的工单信息和与投诉工单对应的订单的订单信息，输入判责模型，得到判责模型输出的判责置信度，以提高投诉工单判责的准确性，进而提高投诉工单的处理效果。其中，判责模型例如可以采用极度坡度提升(Extreme GradientBoosting，简称XGBoost)模型、或者采用XGB与逻辑回归的融合模型(简称XGBoost+LR模型)，可通过有监督训练的方式、并以已处理的投诉工单作为训练数据，预先对判责模型进行训练，得到训练好的判责模型。在此对判责模型不做详细描述。

在投诉工单的判责结果包括投诉工单的判责置信度的情况下，S304的一种可能的实现方式为：根据判责置信度和用户数据，确定工单处理策略。

本实施例中，工单条件中存在一个与判责置信度对应的元素，该元素的值是判责置信度的取值范围，如果判责置信度满足该元素给出的取值范围、且用户数据满足该工单条件中相应元素的取值范围，则确定投诉工单满足该工单条件，因此通过设置不同的工单条件，实现对不同投诉工单的分流处理，有效地提高了投诉工单的处理效果和处理效率。

图4为本公开的另一实施例提供的投诉工单的处理方法的流程示意图，执行主体例如图1所示的服务器。如图4所示，该方法包括：

S401、获取投诉工单和与投诉工单对应的订单。

S402、根据投诉工单和订单，对投诉工单判责，得到判责结果。

本实施例中，S401、S402的详细内容可参照图2、图3所示实施例中的相关描述，不再赘述。

S403、获取投诉工单所属用户的用户数据，用户数据包括用户的信用数据，用户的信用数据包括用户在第一预设时间段内的信用分。

其中，第一预设时间段可为将来时间段，比如以当前时刻为起点的24小时，或者以当日为起点的一周，以当月为起点的一个季度。

本实施例中，可预先存储各个用户在第一预设时间段内的信用分。在确定投诉工单所属的用户后，可获取投诉工单所属用户在第一预设时间段内的信用分，以通过信用分来对用户进行分层，提高用户信用的准确性。

S404、根据判责结果和用户的信用分，确定工单处理策略。

本实施例中，S404的详细内容可参照S304的相关描述。

本实施例中，工单条件可以看作是二元组，二元组中一个元素与判责结果对应，另一个元素与信用分对应，换句话说，二元组中包括判责结果和信用分这两个元素和这两个元素的取值范围，不同工单条件中这两个元素的取值范围不同。因此，可以将投诉工单的判责结果和投诉工单所属用户的信用分，与工单条件中判责结果的取值范围和信用分的取值范围分别进行比较，得到投诉工单的判责结果和投诉工单所属用户的信用分同时满足的工单条件，将该工单条件所对应的工单处理策略，确定为投诉工单的工单处理策略。因此，实现了对不同投诉工单的分流处理，尤其是虚假投诉工单。

本实施例中，在判责结果包括判责置信度的情况下，工单条件中的两个元素分别为判责置信度和信用分，两个元素的取值范围分别为判责置信度的取值范围和信用分的取值范围。因此，可以将投诉工单的判责置信度和投诉工单所属用户的信用分，与各个工单条件进行比较，得到投诉工单所满足的工单条件，将投诉工单所满足的工单条件对应的工单处理策略，确定为投诉工单的工单处理策略。

S405、按照工单处理策略，对投诉工单进行处理。

本实施例中，S405的详细内容可参照S204的相关描述，不再赘述。

本公开实施例中，根据投诉工单和与投诉工单对应的订单，确定投诉工单的判责结果，根据判责结果和用户的信用分，确定工单处理策略，按照工单处理策略，对投诉工单进行处理。因此，通过结合判责结果和用户的信用分，而非单单依靠判责结果，提高了投诉工单中虚假投诉工单的召回率，实现对不同投诉工单的分流处理，尤其是对虚假投诉工单，进而提高投诉工单的处理效率和效果。

在一些实施例中，用户的信用数据包括用户在第二预设时间内多个订单的订单状态，在获取投诉工单所属用户的用户数据之后，在根据判责结果和用户的信用分，确定工单处理策略之前，投诉工单的处理方法还包括：根据第二预设时间段内多个订单的订单状态，确定用户在第一预设时间段内的信用分，以提高用户的信用分的准确性。

本实施例中，第二预设时间段为过去时间段，比如以当前时间为终点的过去一个月内、以当前时间为终点的过去一年内。订单状态包括如下的一项或多项：发单状态、完单状态、取消状态、迟到状态、投诉状态。关于订单状态可以参照图3所示实施例中的描述，不再赘述。

本实施例中，可根据用户在第二预设时间内多个订单的订单状态，统计用户处于投诉状态的订单的数量，根据用户处于投诉状态的订单数量来确定用户的信用分，以通过信用分对用户进行信用分层。例如，如果用户处于投诉状态的订单数量小于预设的第一数量阈值，则信用分为90分，如果用户处于投诉状态的订单数量大于第一数量阈值且小于预设的第二数量阈值，则信用分为80分。又如，如果用户处于投诉状态的订单的数量占用户总订单数量的比例小于预设的第一占比阈值，则信用分为90分，如果用户处于投诉状态的订单的数量占用户总订单数量的比例大于第一占比阈值且小于预设的第二占比阈值，则信用分为80分。

图5为本公开的另一实施例提供的投诉工单的处理方法的流程示意图，执行主体例如图1所示的服务器。如图5所示，该方法包括：

S501、获取投诉工单和与投诉工单对应的订单。

S502、根据投诉工单和订单，对投诉工单判责，得到判责结果。

本实施例中，S501、S502的详细内容可参照图2、图3所示实施例中的相关描述，不再赘述。

S503、获取投诉工单所属用户的用户数据，用户数据包括用户的历史投诉数据。

其中，用户的历史投诉数据包括如下一项或多项：用户在第三预设时间段内的投诉工单数、被投诉订单数、补偿工单数、补偿金额、投诉工单类型。

其中，第三预设时间段为过去时间段，比如以当前时间为终点的过去一个月内、以当前时间为终点的过去一年内。

本实施例中，可在预先存储的用户的投诉工单和订单中，统计得到投诉工单所属用户的历史投诉数据，也即用户在第三预设时间段内的投诉工单数、被投诉订单数、补偿工单数、补偿金额、投诉工单类型中的一项或多项。其中，补偿工单数是指处理结果为补偿的投诉工单的数量，投诉工单类型是按照投诉工单的工单标题进行分类的，同一工单标题的投诉工单可认为是同一类型的投诉工单，关于投诉工单的工单标题可参照图3所示实施例的描述。

S504、根据历史投诉数据，确定用户的用户标签。

其中，用户标签用于对用户进行分类，例如，用户标签可以包括白领标签、学生标签，还可以包括一些与信用相关的标签，例如，虚假投诉标签。

本实施例中，可将历史投诉数据输入预先训练好的用户分类模型，得到用户分类模型输出的用户标签，其中，用户分类模型例如可采用XGBoost模型、或者采用XGBoost+LR模型，可通过有监督训练的方式，以已确定用户标签的用户的历史投诉数据和用户标签作为训练数据，预先对用户分类模型进行训练，得到训练好的用户分类模型。在此对用户分类模型不做详细描述。

S505、根据判责结果和用户标签，确定工单处理策略。

本实施例中，S505的详细内容可参照S304的相关描述。

本实施例中，工单条件可以看作是二元组，二元组中一个元素与判责结果对应，另一个元素与用户标签对应，换句话说，二元组中包括判责结果和用户标签这两个元素和这两个元素的取值范围，不同工单条件中这两个元素的取值范围不同。因此，可以将投诉工单的判责结果和投诉工单所属用户的用户标签，与工单条件中判责结果的取值范围和用户标签的取值范围分别进行比较，得到投诉工单的判责结果和投诉工单所属用户的用户标签同时满足的工单条件，将该工单条件所对应的工单处理策略，确定为投诉工单的工单处理策略。因此，实现了对不同投诉工单的分流处理，尤其是虚假投诉工单。

本实施例中，在判责结果包括判责置信度的情况下，工单条件中的两个元素分别为判责置信度和用户标签，两个元素的取值范围分别为判责置信度的取值范围和用户标签的取值范围。因此，可以将投诉工单的判责置信度和投诉工单所属用户的用户标签，与各个工单条件进行比较，得到投诉工单所满足的工单条件，将投诉工单所满足的工单条件对应的工单处理策略，确定为投诉工单的工单处理策略。

作为示例地，如果投诉工单的判责置信度为80％、且投诉工单所属用户的用户标签包括老客标签和虚拟投诉标签，将该投诉工单与多个工单条件中，查找到投诉工单所满足的工单条件为：投诉工单的判责置信度大于60％、且投诉工单所属用户的用户标签包括虚拟投诉标签，该工单条件可以表现为二元组：【判责置信度大于60％，用户标签包括虚拟投诉标签】。

S506、按照工单处理策略，对投诉工单进行处理。

本实施例中，S405的详细内容可参照S204的相关描述，不再赘述。

本公开实施例中，根据投诉工单和与投诉工单对应的订单，确定投诉工单的判责结果，根据判责结果和用户的用户标签，确定工单处理策略，按照工单处理策略，对投诉工单进行处理。因此，通过结合判责结果和用户的用户标签，而非单单依靠判责结果，提高了投诉工单中虚假投诉工单的召回率，实现对不同投诉工单的分流处理，尤其是对虚假投诉工单，进而提高投诉工单的处理效率和效果。

图6为本公开的另一实施例提供的投诉工单的处理方法的流程示意图，执行主体例如图1所示的服务器。如图6所示，该方法包括：

S601、获取投诉工单和与投诉工单对应的订单。

S602、根据投诉工单和订单，对投诉工单判责，得到判责结果。

S603、获取投诉工单所属用户的用户数据，用户数据包括用户的信用数据和用户的历史投诉数据，用户的信用数据包括用户在第二预设时间段内多个订单的订单状态。

其中，用户的历史投诉数据包括如下一项或多项：用户在第三预设时间段内的投诉工单数、被投诉订单数、补偿工单数、补偿金额、投诉工单类型。

S604、根据第二预设时间段内多个订单的订单状态，确定用户在第一预设时间段内的信用分。

S605、根据历史投诉数据，确定用户的用户标签。

本实施例中，S601～S605的详细内容可参照上述各方法实施例中的相关描述，不再赘述。

S606、根据判责结果、信用分和用户标签，确定工单处理策略。

本实施例中，工单条件可以看作是三元组，三元组中各个元素分别与判责结果、信用分、用户标签对应，换句话说，二元组中包括判责结果、信用分、用户标签这三个元素和这三个元素的取值范围，不同工单条件中这三个元素的取值范围不同。因此，可以将投诉工单的判责结果、投诉工单所属用户的信用分、投诉工单所属用户的用户标签，与工单条件中判责结果的取值范围、信用分的取值范围、用户标签的取值范围分别进行比较，得到投诉工单的判责结果、投诉工单所属用户的信用分、投诉工单所属用户的用户标签同时满足的工单条件，将该工单条件所对应的工单处理策略，确定为投诉工单的工单处理策略。因此，结合判责结果、信用分和用户标签，提高了投诉工单中虚假投诉工单的召回率，通过工单处理策略实现了对不同投诉工单的分流处理，尤其是虚假投诉工单。

本实施例中，在判责结果包括判责置信度的情况下，工单条件中的三个元素分别为判责置信度、信用分和用户标签，三个元素的取值范围分别为判责置信度的取值范围、信用分的取值范围和用户标签的取值范围。因此，可以将投诉工单的判责置信度、投诉工单所属用户的信用分和投诉工单所属用户的用户标签，与各个工单条件进行比较，得到投诉工单所满足的工单条件，将投诉工单所满足的工单条件对应的工单处理策略，确定为投诉工单的工单处理策略。

作为示例地，如果投诉工单的判责置信度为80％、用户的信用分为70分、且投诉工单所属用户的用户标签包括老客标签和虚拟投诉标签，将该投诉工单与多个工单条件中，查找到投诉工单所满足的工单条件为：投诉工单的判责置信度大于60％、信用分低于80分且投诉工单所属用户的用户标签包括虚拟投诉标签，该工单条件可以表现为三元组：【判责置信度大于60％，信用分低于80分，用户标签包括虚拟投诉标签】。

S607、按照工单处理策略，对投诉工单进行处理。

本实施例中，S607的详细内容可参照S204的相关描述，不再赘述。

本公开实施例中，根据投诉工单和与投诉工单对应的订单，确定投诉工单的判责结果，根据判责结果、用户的信用分和用户的用户标签，确定工单处理策略，按照工单处理策略，对投诉工单进行处理。因此，通过结合判责结果、用户的信用分和用户的用户标签，而非单单依靠判责结果，提高了投诉工单中虚假投诉工单的召回率，实现对不同投诉工单的分流处理，尤其是对虚假投诉工单，进而提高投诉工单的处理效率和效果。

作为示例地，工单处理策略可以包括如下的一项或多项：高优处理、正常处理、低优处理、提示警告、延迟补偿、不补偿、重罚。

以图7为例，图7示出了利用本公开实施例提供的投诉工单处理方法建立的乘客虚假投诉智能决策系统的示例图。该决策系统用于实现投诉工单的分流处理，尤其是用于对虚假投诉工单的识别和区别处理。如图7所示，该决策系统包括数据接入模块、分流模块和处置模块，通过数据接入模块与客服系统连接，以接收客服系统发送来的投诉工单，并对接收到的投诉工单进行分流处理。

如图7所示，数据接入模块接收客服系统发送的乘客投诉的投诉工单，并获取乘客信用历史(也即上述实施例中用户的信用数据)和乘客投诉信息历史(也即上述实施例中用户的历史投诉数据)，在分流模块中，依据乘客信用历史确定乘客信用分，依据乘客投诉的投诉工单，确定投诉工单的判责置信度，依据乘客投诉信息历史，确定乘客标签，结合乘客信用分、投诉工单的判责置信度、乘客标签，确定投诉工单的分流策略(也即上述实施例中投诉工单的工单处理策略)，其中，在处置模块中预设了7种分流策略：高优处理、正常处理、低优处理、提示警告、延迟补偿、不补偿、重罚。出置模块按照分流模块所确定的分流策略，对投诉工单进行处理。

图8为本公开的一实施例提供的投诉工单的处理装置的结构示意图，如图8所示，该装置包括：

获取模块801，用于获取投诉工单和与投诉工单对应的订单，获取投诉工单所属用户的用户数据，用户数据包括如下一项或多项：用户的信用数据、用户的历史投诉数据；

确定模块802，用于根据投诉工单、订单和用户数据，确定工单处理策略；

处理模块803，用于按照工单处理策略，对投诉工单进行处理。

在一种可能的实现方式中，确定模块802，具体用于：

根据投诉工单和订单，对投诉工单判责，得到判责结果；

根据判责结果和用户数据，确定工单处理策略。

在一种可能的实现方式中，确定模块802，具体用于：

根据投诉工单和订单，通过预设的判责模型，对投诉工单进行判责，得到投诉工单的判责置信度。

在一种可能的实现方式中，信用数据包括用户在第一预设时间段内的信用分；确定模块802，具体用于：

根据判责结果和信用分，确定工单处理策略。

在一种可能的实现方式中，信用数据包括用户在第二预设时间段内多个订单的订单状态；确定模块，具体用于：

根据第二预设时间段内多个订单的订单状态，确定用户在第一预设时间段内的信用分；

根据判责结果和信用分，确定工单处理策略。

在一种可能的实现方式中，订单状态包括如下的一项或多项：发单状态、完单状态、取消状态、迟到状态、投诉状态。

在一种可能的实现方式中，确定模块802，具体用于：

根据历史投诉数据，确定用户的用户标签；

根据判责结果和用户标签，确定工单处理策略。

在一种可能的实现方式中，信用数据包括用户在第二预设时间段内多个订单的订单状态；确定模块802，具体用于：

根据第二预设时间段内多个订单的订单状态，确定用户在第一预设时间段内的信用分；

根据历史投诉数据，确定用户的用户标签；

根据判责结果、信用分和用户标签，确定工单处理策略。

在一种可能的实现方式中，历史投诉数据包括如下的一项或多项：用户在第三预设时间段内的投诉工单数、被投诉订单数、补偿工单数、补偿金额、投诉工单类型。

在一种可能的实现方式中，确定模块802，具体用于：

根据判责结果、信用分、用户标签、以及预先建立的工单处理策略与三元组的映射关系，确定工单处理策略，三元组中的元素包括判责结果、信用分和用户标签。

图8提供的投诉工单的处理装置，可以执行上述相应方法实施例，其实现原理和技术效果类似，在此不再赘述。

图9为本公开的一实施例提供的一种电子设备的结构示意图。如图9所示，该电子设备可以包括：处理器901和存储器902。存储器902用于存储计算机执行指令，处理器901执行计算机程序时实现如上述任一实施例的方法。

上述的处理器901可以是通用处理器，包括中央处理器CPU、网络处理器(networkprocessor，NP)等。上述存储器902可能包含随机存取存储器(random access memory，RAM)，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。

本公开的一实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行如上述任一实施例的方法。

本公开的一实施例还提供一种程序产品，所述程序产品包括计算机程序，所述计算机程序存储在存储介质中，至少一个处理器可以从所述存储介质中读取所述计算机程序，所述至少一个处理器执行所述计算机程序时可实现上述任一实施例的方法。

图10为本公开的一实施例提供的投诉工单的处理装置1000的框图。例如，装置1000可以被提供为一服务器。参照图10，装置1000包括处理组件1001，其进一步包括一个或多个处理器，以及由存储器1002所代表的存储器资源，用于存储可由处理组件1001的执行的指令，例如应用程序。存储器1002中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理组件1001被配置为执行指令，以执行上述任一实施例的方法。

装置1000还可以包括一个电源组件1003被配置为执行装置1000的电源管理，一个有线或无线网络接口1004被配置为将装置1000连接到网络，和一个输入输出(I/O)接口1005。装置1000可以操作基于存储在存储器1002的操作系统，例如Windows ServerTM，MacOS XTM，UnixTM,LinuxTM，FreeBSDTM或类似。

在本公开实施例中，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中，A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系；在公式中，字符“/”，表示前后关联对象是一种“相除”的关系。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b，或c中的至少一项(个)，可以表示：a，b，c，a-b，a-c，b-c，或a-b-c，其中，a，b，c可以是单个，也可以是多个。

可以理解的是，在本公开实施例中涉及的各种数字编号仅为描述方便进行的区分，并不用来限制本公开实施例的范围。

可以理解的是，在本公开的实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本公开实施例的实施过程构成任何限定。

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

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

Claims (13)

1.一种投诉工单的处理方法，其特征在于，所述方法包括：

获取投诉工单和与所述投诉工单对应的订单；

获取所述投诉工单所属用户的用户数据，所述用户数据包括如下一项或多项：所述用户的信用数据、所述用户的历史投诉数据；

根据所述投诉工单、所述订单和所述用户数据，确定工单处理策略；

按照所述工单处理策略，对所述投诉工单进行处理。

2.根据权利要求1所述的方法，其特征在于，所述根据所述投诉工单、所述订单和所述历史投诉数据，确定工单处理策略，包括：

根据所述投诉工单和所述订单，对所述投诉工单判责，得到判责结果；

根据所述判责结果和所述用户数据，确定工单处理策略。

3.根据权利要求2所述的方法，其特征在于，所述根据所述投诉工单和所述订单，对所述投诉工单判责，得到判责结果，包括：

根据所述投诉工单和所述订单，通过预设的判责模型，对所述投诉工单进行判责，得到所述投诉工单的判责置信度。

4.根据权利要求2或3所述的方法，其特征在于，所述信用数据包括所述用户在第一预设时间段内的信用分；

所述根据所述判责结果和所述用户数据，确定工单处理策略，包括：

根据所述判责结果和所述信用分，确定工单处理策略。

5.根据权利要求2或3所述的方法，其特征在于，所述信用数据包括所述用户在第二预设时间段内多个订单的订单状态；

所述根据所述判责结果和所述用户数据，确定工单处理策略，包括：

根据所述第二预设时间段内多个订单的订单状态，确定所述用户在第一预设时间段内的信用分；

根据所述判责结果和所述信用分，确定工单处理策略。

6.根据权利要求5所述的方法，其特征在于，所述订单状态包括如下的一项或多项：发单状态、完单状态、取消状态、迟到状态、投诉状态。

7.根据权利要求2或3所述的方法，其特征在于，所述根据所述判责结果和所述用户数据，确定工单处理策略，包括：

根据所述历史投诉数据，确定所述用户的用户标签；

根据所述判责结果和所述用户标签，确定工单处理策略。

8.根据权利要求2或3所述的方法，其特征在于，所述信用数据包括所述用户在第二预设时间段内多个订单的订单状态；

所述根据所述判责结果和所述用户数据，确定工单处理策略，包括：

根据所述第二预设时间段内多个订单的订单状态，确定所述用户在第一预设时间段内的信用分；

根据所述历史投诉数据，确定所述用户的用户标签；

根据所述判责结果、所述信用分和所述用户标签，确定工单处理策略。

9.根据权利要求8所述的方法，其特征在于，所述历史投诉数据包括如下的一项或多项：所述用户在第三预设时间段内的投诉工单数、被投诉订单数、补偿工单数、补偿金额、投诉工单类型。

10.根据权利要求8所述的方法，其特征在于，所述根据所述判责结果、所述信用分和所述用户标签，确定工单处理策略，包括：

根据所述判责结果、所述信用分、所述用户标签、以及预先建立的工单处理策略与三元组的映射关系，确定工单处理策略，所述三元组中的元素包括判责结果、信用分和用户标签。

11.一种投诉工单的处理装置，其特征在于，所述装置包括：

获取模块，用于获取投诉工单和与所述投诉工单对应的订单，获取所述投诉工单所属用户的用户数据，所述用户数据包括如下一项或多项：所述用户的信用数据、所述用户的历史投诉数据；

确定模块，用于根据所述投诉工单、所述订单和所述用户数据，确定工单处理策略；

处理模块，用于按照所述工单处理策略，对所述投诉工单进行处理。

12.一种电子设备，包括：存储器和处理器；

所述存储器用于存储程序指令；

所述处理器用于调用所述存储器中的程序指令执行如权利要求1-10任一项所述的方法。

13.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序；所述计算机程序被执行时，实现如权利要求1-10任一项所述的方法。

Images