CN115358761A - 售后处理方法和装置、售后处理设备及存储介质 - Google Patents

Abstract

本公开提供一种售后处理方法和装置、售后处理设备及存储介质；涉及计算机技术领域。该方法包括：接收针对虚拟服务对象的售后申请消息，根据所述服务属性信息，查询对应的服务类型及售后规则信息，生成售后服务单；响应于售后服务单的生成，确定服务权益和服务权益的状态信息；根据售后规则信息，匹配服务权益的售后处理规则；并根据服务权益的状态信息和售后处理规则，确定售后处理方式；根据售后处理方式进行售后处理。本公开可以解决相关技术中服务类虚拟商品的售后处理效率低且浪费人力资源的问题。

Description

售后处理方法和装置、售后处理设备及存储介质

技术领域

本公开涉及计算机技术领域，具体而言，涉及一种售后处理方法和装置、售后处理设备及存储介质。

背景技术

虚拟商品是指电子商务市场中的数字产品或服务，虚拟商品相比实物商品具有无实体交付内容、不需要仓储存放、不涉及配送收货等特性。目前服务类虚拟商品的售后处理大都采用人工审核和手动操作处理的方式，处理效率低且浪费人力资源，降低了用户对此类商品的消费意愿。

需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

本公开实施例的目的在于提供一种售后处理方法和装置、售后处理设备及存储介质，进而在一定程度上解决了相关技术中服务类虚拟商品的售后处理效率低且浪费人力资源的问题。

根据本公开的第一方面，提供了一种售后处理方法，所述方法包括：接收针对虚拟服务对象的售后申请消息，所述售后申请消息包括服务属性信息；根据所述服务属性信息，查询对应的服务类型及售后规则信息；并根据所述服务属性信息及所述售后规则信息生成售后服务单；响应于所述售后服务单的生成，确定所述服务属性信息内的服务权益；根据所述服务类型，查询对应的信息库以获取所述服务权益的状态信息；根据所述售后规则信息，匹配所述服务权益的售后处理规则；并根据所述服务权益的状态信息和所述售后处理规则，确定售后处理方式；根据所述售后处理方式进行售后处理。

可选地，在所述生成售后服务单之后，所述方法还包括：根据所述服务类型，对所述售后服务单添加服务标识信息。

所述根据所述服务类型，查询对应的信息库以获取所述服务权益的状态信息，包括：根据所述服务标识信息，查询对应的信息库以获取所述服务权益的状态信息。

可选地，所述服务类型包括线上消费服务和线下消费服务，所述获取所述服务权益的状态信息，包括：当所述服务类型为线上消费服务时，从线上数据库中匹配获取并记录所述服务权益的状态信息；当所述服务类型为线下消费服务时，查询所述服务权益对应的线下消费场地信息，并调用所述线下消费场地信息对应的信息查询接口，获取并记录所述服务权益的状态信息。

可选地，所述服务属性信息包括服务权益信息，所述方法还包括：确定所述服务权益信息是否包括多个服务权益；若所述虚拟服务对象包括多个服务权益，对所述服务属性信息内的服务权益进行分解，获得多个服务权益。

可选地，所述方法还包括：针对每种虚拟服务对象，配置所述虚拟服务对象的基本信息和服务属性信息，并以键值对的形式分别存储所述基本信息和所述服务属性信息。

可选地，所述方法还包括：针对每种服务类型，根据所述售后服务单的属性信息或者所述服务属性信息，生成相应的售后规则配置页面；根据所述售后规则配置页面定义的第一按钮，配置所述售后服务单的售后规则信息。

可选地，所述方法还包括：根据所述售后规则配置页面定义的第二按钮，配置所述售后规则信息的状态信息。

可选地，在所述确定售后处理方式之后，所述方法还包括：将所述售后处理方式记录在所述售后服务单上；响应于监听到所述售后服务单上的所述售后处理方式，读取并执行所述售后处理方式。

可选地，所述根据所述售后处理方式进行售后处理，包括：根据所述售后处理方式，向第三方平台发送相应的售后处理请求，以使所述第三方平台执行所述售后处理方式。

根据本公开的第二方面，提供一种售后处理装置，装置包括：接收模块、查询模块、权益确定模块、匹配模块和处理模块；接收模块，用于接收针对虚拟服务对象的售后申请消息，所述售后申请消息包括服务属性信息；查询模块，用于根据所述服务属性信息，查询对应的服务类型及售后规则信息；并根据所述服务属性信息及所述售后规则信息生成售后服务单；权益确定模块，用于响应于所述售后服务单的生成，确定所述服务属性信息内的服务权益；根据所述服务类型，查询对应的信息库以获取所述服务权益的状态信息；匹配模块，用于根据所述售后规则信息，匹配所述服务权益的售后处理规则；并根据所述服务权益的状态信息和所述售后处理规则，确定售后处理方式；处理模块，用于根据所述售后处理方式进行售后处理。

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

根据本公开的第四方面，提供一种售后处理设备，包括：一个或多个处理器；以及存储装置，用于一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器执行上述任一实施例所述的方法。

本公开示例性实施例可以具有以下部分或全部有益效果：

在本公开示例实施方式所提供的售后处理方法中，可以针对虚拟服务对象的售后申请消息，查询与服务属性信息对应的服务类型及售后规则信息，并据此生成售后服务单；响应于售后服务单的生成，根据服务属性信息和服务类型，确定相应的服务权益及服务权益的状态信息；再匹配服务权益的售后处理规则，确定售后处理方式；根据所述售后处理方式进行售后处理。一方面，可以完成服务类虚拟商品的线上售后闭环处理，减少人力成本、提高售后处理效率，避免由于售后问题带来的用户对服务类虚拟商品的消费意愿低的问题。另一方面，以售后服务单为处理过程中的唯一凭证，可以保证虚拟服务对象与售后处理方式的对应关系，提高售后服务的准确性。此外，以售后服务单为依托，根据服务类型进行售后处理，可以提高不同服务类型的并发处理量，提高售后处理效率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示意性示出了根据本公开的一个实施例的售后处理方法及装置的应用场景架构图。

图2示意性示出了根据本公开的一个实施例中售后处理方法的流程图。

图3示意性示出了根据本公开的一个实施例中售后服务单的生成过程流程示意图。

图4示意性示出了根据本公开的一个实施例中售后规则配置页面的示意图。

图5示意性示出了根据本公开的一个实施例的售后处理装置的结构框图。

图6示意性示出了根据本公开的一个实施例中基于售后处理装置的售后处理方法实施过程的流程示意图。

图7示出了适于用来实现本公开实施例的售后处理设备框图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知技术方案以避免喧宾夺主而使得本公开的各方面变得模糊。

此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

图1示出了可以应用本公开实施例的一种售后处理方法及装置的示例性系统架构100的示意图。如图1所示，系统架构100可以包括终端设备110和服务器120。终端设备110包括但不限于手机、电脑、智能语音交互设备、智能家电、车载终端、计算机等任意具有电子显示屏的用户终端电子设备，本示例对此不做限定。终端设备110与服务器120之间通过网络进行通信，网络可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

终端设备100可以向服务器120发送针对虚拟服务对象的售后申请消息，服务器120可以基于接收的包括服务属性信息的售后申请消息，根据服务属性信息，查询对应的服务类型及售后规则信息；并根据服务属性信息及售后规则信息生成售后服务单；响应于售后服务单的生成，确定服务属性信息内的服务权益；根据服务类型，查询对应的信息库以获取服务权益的状态信息；根据售后规则信息，匹配服务权益的售后处理规则；并根据服务权益的状态信息和售后处理规则，确定售后处理方式；根据售后处理方式进行售后处理。并将售后结果以售后结果通知的形式发送给终端设备。

本示例中，服务器120可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，其中多个服务器可组成一区块链，而服务器为区块链上的节点，服务器120还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN(ContentDeliveryNetwork，内容分发网络)以及大数据和人工智能平台等基础云计算服务的云服务器。

本公开实施例所提供的售后处理方法可以在服务器120执行，相应地，售后处理装置一般设置于服务器120中。

本公开针对服务类虚拟商品的售后处理完全依赖于人工审核和处理的情况。下面结合具体的实施例，对本说明书实施例披露的售后处理方法进行介绍。

参考图2所示，本公开提供的一种示例实施方式的售后处理方法，可以包括以下步骤S210～S250。

步骤S210，接收针对虚拟服务对象的售后申请消息。

在本示例实施方式中，售后申请消息是指用户线上购买虚拟服务对象后，需要针对该虚拟服务对象申请售后时发送的售后请求消息。虚拟服务对象可以是服务类的虚拟商品，例如手机充值服务、体验服务、医疗美容服务等等。

在本示例实施方式中，售后申请消息可以包括用户信息和服务属性信息；用户信息可以包括用户名称、用户标识、用户账号、用户IP地址、用户联系方式等信息中的一种或多种。服务属性信息可以包括服务类型、服务名称、服务对应的服务权益、服务标识信息等，还可以包括服务订单号、服务有效期等信息，本示例对此不做限定。售后申请消息还可以包括基本信息（如售后时间、售后单号、售后类型）和售后信息（售后原因、申请售后说明）等信息，根据不同业务类型，售后申请消息可以进行适当的增减，本示例对此不做限定。

举例而言，售后申请消息可以以XML形式记录，以基本信息中的售后时间、售后单号、售后类型为例，其可以记录如下：

上述第二至四行依次记录售后时间、售后单号、售后类型信息，第一行和最后一行表示该两行之间为售后服务的属性信息。本方法的执行主体可以通过监听售后申请消息，解析各部分信息，依次遍历读取并识别存储这些信息即可。

步骤S220，根据服务属性信息，查询对应的服务类型及售后规则信息；并根据服务属性信息及售后规则信息生成售后服务单。

在本示例实施方式中，可以根据消费形式将服务类型划分为线上消费服务和线下消费服务，线上消费服务是指在线上购买线上消耗的服务，例如手机充值服务、游戏点卡服务、在线问诊服务等。线下消费服务是指线上购买需要前往线下门店进行消费的服务，例如体检服务、牙齿修补服务及其他各类医疗美容服务等。还可以根据其他信息对虚拟服务对象划分服务类型，本示例对此不做限定。

在本示例实施方式中，售后规则信息可以包括售后规则的标识信息、售后规则的名称、售后规则状态、售后规则对应的操作。售后规则信息可以由业务人员提报或直接维护至管理后台，单个售后规则可以以时间节点、服务状态、其它标定等售后单属性信息或者以服务属性信息为标的，设置可售后、不可售后、可部分售后等处理操作响应。

在本示例实施方式中，售后服务单可以包括服务属性信息和售后规则信息两部分，在查询获取到售后规则信息之后即可生成售后服务单，售后服务单可以具有唯一的标识信息。

步骤S230，响应于售后服务单的生成，确定服务属性信息内的服务权益；根据服务类型，查询对应的信息库以获取服务权益的状态信息。

在本示例实施方式中，服务权益是指针对不同的虚拟服务对象，用户具有的服务权益，例如，退款或部分退款、服务升级、价保权益等，本示例对此不做特殊限定。服务权益的状态信息包括可用状态和不可用状态。

步骤S240，根据售后规则信息，匹配服务权益的售后处理规则；并根据服务权益的状态信息和售后处理规则，确定售后处理方式。

在本示例实施方式中，可以根据售后规则信息中的标识信息，匹配出对应的售后处理规则，售后处理规则可以包括单一售后方式或者多种售后方式的结合，例如，回收服务与退款相结合，还可以包括退款比例、退款方式等信息，本示例对此不做限定。

步骤S250，根据售后处理方式进行售后处理。

在本示例实施方式中，售后处理方式可以包含回收服务+退款、拒绝本次售后、移交人工处理等方式，还可以包括其他方式，本示例对此不做限定。

在本示例实施方式所提供的售后处理方法中，可以针对虚拟服务对象的售后申请消息，查询与服务属性信息对应的服务类型及售后规则信息，并据此生成售后服务单；响应于售后服务单的生成，根据服务属性信息和服务类型，确定相应的服务权益及服务权益的状态信息；再匹配服务权益的售后处理规则，确定售后处理方式；根据售后处理方式进行售后处理。一方面，可以完成服务类虚拟商品的线上售后闭环处理，减少人力成本、提高售后处理效率，避免由于售后问题带来的用户对服务类虚拟商品的消费意愿低的问题。另一方面，以售后服务单为处理过程中的唯一凭证，可以保证虚拟服务对象与售后处理方式的对应关系，提高售后服务的准确性。此外，以售后服务单为依托，根据服务类型进行售后处理，可以提高不同服务类型的并发处理量，提高售后处理效率。

以下对本公开的各个步骤进行更加详细的描述。

在一些实施例中，在生成售后服务单之后，方法还包括：根据服务类型，对售后服务单添加服务标识信息。

在本示例实施方式中，由于不同服务类型的售后处理不同，故可以在售后服务单上添加服务标识信息（如打标），以使后续处理过程可以快速识别处理。例如，可以对线上消费服务打标A，对线下消费服务打标B。

根据服务标识信息，查询对应的信息库（A查询线上数据库，B查询线下门店数据库），以获取服务权益的状态信息。

举例而言，如图3所示，执行主体可以通过监听接收到售后申请消息，分别查询服务数据单元和售后规则数据单元，获取与售后申请消息对应的服务类型及售后规则信息；服务数据单元和售后规则数据单元也可以是执行主体的一个存储单元，本示例对此不做限定。根据服务属性信息及售后规则信息生成售后服务单，并分别添加服务类型标识信息，如图3中，A表示线上消费服务，B表示线下消费服务。

在一些实施例中，获取服务权益的状态信息，包括：当服务类型为线上消费服务时，从线上数据库中匹配获取并记录服务权益的状态信息。

当服务类型为线下消费服务时，查询服务权益对应的线下消费场地信息，并调用线下消费场地信息对应的信息查询接口，获取并记录服务权益的状态信息。

在本示例实施方式中，线下消费场地信息可以包括线下消费门店的标识信息、地址信息、名称信息等，本示例对此不做限定。可以读取服务对应的激活门店信息，追溯门店对应商家ID，调用商家ID对应的信息查询接口，查询门店下用户服务中服务权益使用状态并返回查询值。

示例性地，本方案执行主体与商家门店可以通过HTTP协议进行接口交互，以Post方式调用接口，调用该信息查询接口时需要输入的参数如表1所示，门店信息系统的返回信息如表2所示。

表1调用信息查询接口的输入参数

表2调用信息查询接口的返回信息

例如，返回值为："state": 200," ServiceState ": "3"；根据表2可知，该返回值表示信息调用成功，查询到的服务状态为已到检，此时对应的售后处理方式可以是拒绝本次售后。

在本示例实施方式中，可以根据返回的查询值寻找匹配的售后规则信息中对应事件节点（如图4中的事件列中的事件节点），按照事件节点关联的售后规则执行售后处理。

在一些实施例中，方法还包括：确定服务权益信息是否包括多个服务权益；若虚拟服务对象包括多个服务权益，对服务属性信息内的服务权益进行分解，获得多个服务权益。

在本示例实施方式中，服务属性信息包括服务权益信息，针对一个虚拟服务对象可以具有多个服务权益，例如，对于齿科服务虚拟商品，可以具有牙齿检查、牙齿清洗、牙齿修补等多项服务权益，需要针对每个服务权益分别进行状态查询和售后处理，以提高售后处理的准确性。

在一些实施例中，方法还包括：

针对每种虚拟服务对象，配置虚拟服务对象的基本信息和服务属性信息，并以键值对的形式分别存储基本信息和服务属性信息。

在本示例实施方式中，基本信息包括虚拟服务对象的名称、有限期、服务内容等信息。根据不同业务类型可以对配置的信息进行适当增减。示例性地，服务数据以key-value键值对进行存储，以服务属性信息中的服务类型为例，其数据存储形式为key：ServiceType；value：null表示空；0表示不含服务；1表示线上消费服务；2表示线下消费服务。查询服务类型时，可以根据服务标识信息返回服务类型的属性值，根据该属性值确定服务类型。

在一些实施例中，方法还包括：针对每种服务类型，根据售后服务单的属性信息或者服务属性信息，生成相应的售后规则配置页面。

在本示例实施方式中，售后服务单的属性信息可以包括售后服务单的名称、标识、生成时间、结束时间、服务状态信息、服务类型信息等等，还可以包括其他与售后服务单相关的信息，本示例对此不做限定。在本示例中，可以根据售后服务单的属性信息生成售后规则配置页面，也可以根据服务属性信息生成售后规则配置页面，一个售后服务单可以生成一个或多个售后规则配置页面，本示例对此不做限定。

根据售后规则配置页面定义的第一按钮，配置售后服务单的售后处理规则。

在本示例实施方式中，第一按钮是用于开发人员或售后人员配置售后处理规则的，例如，可以是编辑按钮或者配置按钮。售后处理规则是指售后处理逻辑，例如，对于线下体检服务，若服务权益的状态信息为已到检，则拒绝本次售后。

根据售后规则配置页面定义的第二按钮，配置售后规则信息的状态信息。

在本示例实施方式中，售后规则信息的状态信息可以包括可用、不可用，或者启用、停用等。可以针对售后服务单的属性信息配置对应的售后处理规则可用，其他售后处理规则不可用。

举例而言，售后规则配置页面如图4所示，以表格的形式进行配置，每个售后规则可以配置序号、标识ID、名称、状态和操作等配置属性。在操作属性下方配置两个按钮（编辑按钮和状态操作按钮），便于配置操作。图4中的下半部分为点击编辑按钮对应的编辑页面，以问诊服务售后为例，可以以表格的形式进行配置。可以包括事件序号、事件内容、售后处理方式（如退款、不可退款、人工介入等）、处理限制信息（如退款比例限制）。例如可以设置，订单已支付事件对应的售后处理方式为全额退款，服务已激活事件对应的售后处理方式为人工介入（还可设置退款限制比例如80%），服务已使用事件对应的售后处理方式为不可退款。图4中的“…”表示省略号，是指此处还可以配置其他多个事件相关信息。

在一些实施例中，方法还包括：在确定售后处理方式之后，将售后处理方式记录在售后服务单上；响应于监听到售后服务单上的售后处理方式，读取并执行售后处理方式。

在本示例实施方式中，可以根据从售后服务单上读取的售后处理方式进行售后处理，例如，售后处理方式为不可退则可以形成售后处理消息返回给用户客户端，售后处理消息可以包括售后结论、结论形成原因、处理时间，订单编号、标识、售后标识信息等，还可以包括申诉途径等信息，本示例对此不做限定。

在一些实施例中，根据售后处理方式进行售后处理，包括：

根据售后处理方式，向第三方平台或业务系统发送相应的售后处理请求，以使第三方平台或业务系统执行售后处理方式。

在本示例实施方式中，可以将本方法执行主体与业务系统关联，在形成售后处理方式之后，将该售后处理方式通过售后处理请求发送给业务系统，通过业务系统执行该售后处理方式。也可以将本方法与第三方平台（如财务平台、税务平台、结算平台等）关联，通过第三方平台协助处理。

在本示例实施方式中，本方法执行主体与业务系统或第三方平台可以采用接口交互或消息队列等方式进行交互，也可以采用其它交互方式，本示例对此不做限定。

进一步的，本示例实施方式中，还提供了一种售后处理装置500。该售后处理装置500可以应用于服务器。参考图5所示，该售后处理装置500可以包括：接收模块510、查询模块520、权益确定模块530、匹配模块540和处理模块550；接收模块510，用于接收针对虚拟服务对象的售后申请消息，售后申请消息包括服务属性信息；查询模块520，用于根据服务属性信息，查询对应的服务类型及售后规则信息；并根据服务属性信息及售后规则信息生成售后服务单；权益确定模块530，用于响应于售后服务单的生成，确定服务属性信息内的服务权益；根据服务类型，查询对应的信息库以获取服务权益的状态信息；匹配模块540，用于根据售后规则信息，匹配服务权益的售后处理规则；并根据服务权益的状态信息和售后处理规则，确定售后处理方式；处理模块550，用于根据售后处理方式进行售后处理。

在本公开的一种示例性实施例中，装置500还包括标识添加模块，标识添加模块可以用于在生成售后服务单之后，根据服务类型，对售后服务单添加服务标识信息。权益确定模块530还用于根据服务标识信息，查询对应的信息库以获取服务权益的状态信息。

在本公开的一种示例性实施例中，服务类型包括线上消费服务和线下消费服务，权益确定模块530包括第一权益确定子模块和第二权益确定子模块， 第一权益确定子模块，用于当服务类型为线上消费服务时，从线上数据库中匹配获取并记录服务权益的状态信息；第二权益确定子模块，用于当服务类型为线下消费服务时，查询服务权益对应的线下消费场地信息，并调用线下消费场地信息对应的信息查询接口，获取并记录服务权益的状态信息。

在本公开的一种示例性实施例中，服务属性信息包括服务权益信息，装置500还包括：权益分解模块，权益分解模块用于确定服务权益信息是否包括多个服务权益；若虚拟服务对象包括多个服务权益，对服务属性信息内的服务权益进行分解，获得多个服务权益。

在本公开的一种示例性实施例中，装置500还包括第一配置模块，第一配置模块用于针对每种虚拟服务对象，配置虚拟服务对象的基本信息和服务属性信息，并以键值对的形式分别存储基本信息和服务属性信息。

在本公开的一种示例性实施例中，装置500还包括第二配置模块，第二配置模块用于针对每种服务类型，根据售后服务单的属性信息或者服务属性信息，生成相应的售后规则配置页面；根据售后规则配置页面定义的第一按钮，配置售后服务单的售后处理规则。

在本公开的一种示例性实施例中，第二配置模块还用于根据售后规则配置页面定义的第二按钮，配置售后规则信息的状态信息。

在本公开的一种示例性实施例中，装置500还包括：记录模块和执行模块，记录模块用于在确定售后处理方式之后，将售后处理方式记录在售后服务单上；执行模块用于响应于监听到售后服务单上的售后处理方式，读取并执行售后处理方式。

在本公开的一种示例性实施例中，处理模块550包括发送模块，发送模块用于根据售后处理方式，向第三方平台或业务系统发送相应的售后处理请求，以使第三方平台或业务系统执行售后处理方式。

举例而言， 本公开基于该售后处理装置的售后处理方法的实现过程如图6所示，售后处理装置包括接收模块610、查询模块620、权益确定模块630、匹配模块640和处理模块650，具体可以通过以下步骤实现。

第一步，接收模块610接收针对虚拟服务对象的售后申请消息。

第二步，查询模块620响应于监听到该售后申请消息，分别查询服务数据单元和售后规则数据单元，确定售后申请消息对应的服务类型及售后规则信息。

第三步，查询模块620根据服务属性信息及售后规则信息生成售后服务单。

第四步，查询模块620对售后服务单添加服务类型标识信息。

第五步，响应于监听到售后服务单的生成，权益确定模块630根据该服务类型标识信息，启动对应的权益确定模块，确定服务属性信息内的服务权益。

第六步，当服务类型为线上消费服务时，第一权益确定子模块从线上数据库中匹配获取并记录服务权益的状态信息。

第七步，当服务为线下消费服务时，第二权益确定子模块查询服务权益对应的线下消费场地信息，并调用线下消费场地信息对应的信息查询接口，获取并记录服务权益的状态信息。

第八步，匹配模块640根据售后规则信息，匹配服务权益的售后处理规则；并根据服务权益的状态信息和售后处理规则，确定售后处理方式。

第九步，处理模块650根据售后处理方式进行售后处理。

本公开方法应用于售后服务系统。

上述售后处理装置中各模块或单元的具体细节已经在对应的售后处理方法中进行了详细的描述，因此此处不再赘述。

本公开针对目前对于服务类虚拟商品的售后现实情况，即采用人工审核方式，人力成本较高，且响应时效受限，处理效率低，难以大规模应用的现状。采用机审方式仅限于在付款后较短的时期内处理，业务场景不够全面，不利于对全场景售后均有诉求的业务运作。 采用不提供售后服务的方式，会降低用户购买意愿，降低用户体验。针对以上现实问题，本公开设计了服务类虚拟商品的售后处理流程，一方面通过服务类型将售后处理分为线上消费类型和线下消费类型，对于两种服务类型分别设计售后规则进行售后处理，实现了服务类虚拟商品线上闭环售后处理，减少人力成本、提高售后效率与准确性、覆盖全业务场景。另一方面通过服务权益的状态信息确定售后处理方式，提高售后处理的准确性。此外本公开可以实现服务类虚拟商品的自动售后处理，增加客户下单意愿、促成交易，提升用户体验。

本公开通过监听售后服务单的状态和内容来控制处理流程的各个环节，既保证信息准确性又减少不同处理模块对服务信息的存储空间，还可以提高处理效率，可以为后续售后提供依据并提高并发处理量与处理效率。

本公开可以将售后处理方式的确定过程与售后执行过程进行解耦，有利于快速响应、提升整体售后处理效率。

作为另一方面，本申请还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的网络设备中所包含的；也可以是单独存在，而未装配入该网络设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该电子设备执行时，使得该电子设备实现如下述实施例中的方法。例如，电子设备可以实现如图2~图4、图6所示的各个步骤等。

需要说明的是，本公开所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器（RAM）、只读存储器（ROM）、可擦式可编程只读存储器（EPROM或闪存）、光纤、便携式紧凑磁盘只读存储器（CD-ROM）、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

此外，在本公开的示例性实施例中，还提供了一种能够实现上述方法的设备。所属技术领域的技术人员能够理解，本公开的各个方面可以实现为系统、方法或程序产品。因此，本公开的各个方面可以具体实现为以下形式，即：完全的硬件实施例、完全的软件实施例（包括固件、微代码等），或硬件和软件方面结合的实施例，这里可以统称为“电路”、“模块”或“系统”。

参见图7，图7是本申请实施例提供的一种售后处理设备的结构示意图。如图7所示，该售后处理设备700包括处理器710、存储器720、输入输出接口730以及通信总线740。处理器710连接到存储器720和输入输出接口730，例如处理器710可以通过通信总线740连接到存储器720和输入输出接口730。处理器710被配置为支持该售后处理设备执行图2-图4、图6中售后处理方法中相应的功能。该处理器710可以是中央处理器(Central ProcessingUnit，CPU)，网络处理器(Network Processor，NP)，硬件芯片或者其任意组合。上述硬件芯片可以是专用集成电路(Application-Specific Integrated Circuit，ASIC)，可编程逻辑器件(Programmable Logic Device ，PLD) 或其组合。上述PLD可以是复杂可编程逻辑器件(Complex Programmable Logic Device，CPLD)，现场可编程逻辑门阵列(Field-Programmable Gate Array，FPGA)，通用阵列逻辑(Generic Array Logic，GAL)或其任意组合。存储器720用于存储程序代码等。存储器720可以包括易失性存储器(VolatileMemory，VM)，例如随机存取存储器(Random Access Memory，RAM)；存储器720也可以包括非易失性存储器(Non-Volatile Memory，NVM)，例如只读存储器(Read-Only Memory，ROM)，快闪存储器(flash memory)，硬盘(Hard Disk Drive，HDD)或固态硬盘(Solid-State Drive，SSD)；存储器720还可以包括上述种类的存储器的组合。

该输入输出接口730用于输入或输出数据。

处理器710可以调用上述程序代码以执行以下操作：接收针对虚拟服务对象的售后申请消息，售后申请消息包括服务属性信息；根据服务属性信息，查询对应的服务类型及售后规则信息；并根据服务属性信息及售后规则信息生成售后服务单；响应于售后服务单的生成，确定服务属性信息内的服务权益；根据服务类型，查询对应的信息库以获取服务权益的状态信息；根据售后规则信息，匹配服务权益的售后处理规则；并根据服务权益的状态信息和售后处理规则，确定售后处理方式；根据售后处理方式进行售后处理。

可选的，上述处理器710还可以执行以下操作：在生成售后服务单之后，根据服务类型，对售后服务单添加服务标识信息；根据服务标识信息，查询对应的信息库以获取服务权益的状态信息。

可选的，服务类型包括线上消费服务和线下消费服务，上述处理器710还可以获取服务权益的状态信息，执行以下操作：当服务类型为线上消费服务时，从线上数据库中匹配获取并记录服务权益的状态信息；当服务类型为线下消费服务时，查询服务权益对应的线下消费场地信息，并调用线下消费场地信息对应的信息查询接口，获取并记录服务权益的状态信息。

可选的，服务属性信息包括服务权益信息，上述处理器710还可以执行以下操作：确定服务权益信息是否包括多个服务权益；若虚拟服务对象包括多个服务权益，对服务属性信息内的服务权益进行分解，获得多个服务权益。

可选地，上述处理器710还可以执行以下操作：针对每种虚拟服务对象，配置虚拟服务对象的基本信息和服务属性信息，并以键值对的形式分别存储基本信息和服务属性信息。

可选的，上述处理器710执行以下操作：针对每种服务类型，根据售后服务单的属性信息或者服务属性信息，生成相应的售后规则配置页面；根据售后规则配置页面定义的第一按钮，配置售后服务单的售后处理规则。

可选的，上述处理器710还可以执行以下操作：根据售后规则配置页面定义的第二按钮，配置售后规则信息的状态信息。

可选的，上述处理器710还可以执行以下操作：在确定售后处理方式之后，将售后处理方式记录在售后服务单上；响应于监听到售后服务单上的售后处理方式，读取并执行售后处理方式。

可选的，上述处理器710还可以根据售后处理方式进行售后处理，执行以下操作：根据售后处理方式，向第三方平台或业务系统发送相应的售后处理请求，以使第三方平台或业务系统执行售后处理方式。

需要说明的是，各个操作的实现还可以对应参照图2-图4、图6所示的方法实施例的相应描述；上述处理器710还可以与输入输出接口730配合执行上述方法实施例中的其他操作。

通过以上的实施例的描述，本领域的技术人员易于理解，这里描述的示例实施例可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施例的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质（可以是CD-ROM，U盘，移动硬盘等）中或网络上，包括若干指令以使得一台设备执行根据本公开实施例的方法。

此外，上述附图仅是根据本公开示例性实施例的方法所包括的处理的示意性说明，而不是限制目的。易于理解，上述附图所示的处理并不表明或限制这些处理的时间顺序。另外，也易于理解，这些处理可以是例如在多个模块中同步或异步执行的。

需要说明的是，尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等，均应视为本公开的一部分。

应可理解的是，本说明书公开和限定的本公开延伸到文中和/或附图中提到或明显的两个或两个以上单独特征的所有可替代组合。所有这些不同的组合构成本公开的多个可替代方面。本说明书的实施方式说明了已知用于实现本公开的最佳方式，并且将使本领域技术人员能够利用本公开。

Claims (12)

1.一种售后处理方法，其特征在于，所述方法包括：

接收针对虚拟服务对象的售后申请消息，所述售后申请消息包括服务属性信息；

根据所述服务属性信息，查询对应的服务类型及售后规则信息；并根据所述服务属性信息及所述售后规则信息生成售后服务单；

响应于所述售后服务单的生成，确定所述服务属性信息内的服务权益；根据所述服务类型，查询对应的信息库以获取所述服务权益的状态信息；

根据所述售后规则信息，匹配所述服务权益的售后处理规则；并根据所述服务权益的状态信息和所述售后处理规则，确定售后处理方式；

根据所述售后处理方式进行售后处理。

2.根据权利要求1所述的售后处理方法，其特征在于，在所述生成售后服务单之后，所述方法还包括：

根据所述服务类型，对所述售后服务单添加服务标识信息；

所述根据所述服务类型，查询对应的信息库以获取所述服务权益的状态信息，包括：

根据所述服务标识信息，查询对应的信息库以获取所述服务权益的状态信息。

3.根据权利要求1所述的售后处理方法，其特征在于，所述服务类型包括线上消费服务和线下消费服务，所述获取所述服务权益的状态信息，包括：

当所述服务类型为线上消费服务时，从线上数据库中匹配获取并记录所述服务权益的状态信息；

当所述服务类型为线下消费服务时，查询所述服务权益对应的线下消费场地信息，并调用所述线下消费场地信息对应的信息查询接口，获取并记录所述服务权益的状态信息。

4.根据权利要求1所述的售后处理方法，其特征在于，所述服务属性信息包括服务权益信息，所述方法还包括：

确定所述服务权益信息是否包括多个服务权益；

若所述虚拟服务对象包括多个服务权益，对所述服务属性信息内的服务权益进行分解，获得多个服务权益。

5.根据权利要求1所述的售后处理方法，其特征在于，所述方法还包括：

针对每种虚拟服务对象，配置所述虚拟服务对象的基本信息和服务属性信息，并以键值对的形式分别存储所述基本信息和所述服务属性信息。

6.根据权利要求1或5所述的售后处理方法，其特征在于，所述方法还包括：

针对每种服务类型，根据所述售后服务单的属性信息或者所述服务属性信息，生成相应的售后规则配置页面；

根据所述售后规则配置页面定义的第一按钮，配置所述售后服务单的售后处理规则。

7.根据权利要求6所述的售后处理方法，其特征在于，所述方法还包括：

根据所述售后规则配置页面定义的第二按钮，配置所述售后规则信息的状态信息。

8.根据权利要求1所述的售后处理方法，其特征在于，在所述确定售后处理方式之后，所述方法还包括：

将所述售后处理方式记录在所述售后服务单上；

响应于监听到所述售后服务单上的所述售后处理方式，读取并执行所述售后处理方式。

9.根据权利要求1或8所述的售后处理方法，其特征在于，所述根据所述售后处理方式进行售后处理，包括：

根据所述售后处理方式，向第三方平台或业务系统发送相应的售后处理请求，以使所述第三方平台或业务系统执行所述售后处理方式。

10.一种售后处理装置，其特征在于，所述装置包括：

接收模块，用于接收针对虚拟服务对象的售后申请消息，所述售后申请消息包括服务属性信息；

查询模块，用于根据所述服务属性信息，查询对应的服务类型及售后规则信息；并根据所述服务属性信息及所述售后规则信息生成售后服务单；

权益确定模块，用于响应于所述售后服务单的生成，确定所述服务属性信息内的服务权益；根据所述服务类型，查询对应的信息库以获取所述服务权益的状态信息；

匹配模块，用于根据所述售后规则信息，匹配所述服务权益的售后处理规则；并根据所述服务权益的状态信息和所述售后处理规则，确定售后处理方式；

处理模块，用于根据所述售后处理方式进行售后处理。

11.一种售后处理设备，其特征在于，包括：一个或多个处理器；

存储装置，用于存储一个或多个程序；

当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如权利要求1-9中任一项所述的方法。

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

Images