一种申诉处理方法及系统
技术领域
本说明书实施例涉及风控技术领域,尤其涉及一种申诉处理方法及系统。
背景技术
随着计算机和互联网的不断发展,在线支付方式得到了快速发展。在线支付方式是一种通过第三方提供的与银行之间的支付接口进行支付的方式,极大地提升了用户购物体验。
虽然在线支付方式可以提升用户的购物体验,但不可避免的也存在一些弊端。例如,在线支付方式存在独特的支付风险,需要实施风险管控。而在风控管控实施的过程中,不可避免的存在误判等情况,导致用户不能进行正常的交易,又或者用户通过在线支付方式购买的商品存在尺寸不符、质量较差等问题。为了解决诸如此类问题,用户可以进行申诉,在申诉通过之后,用户可以进行正常的交易、退货、退款等操作。
目前用户基本通过致电客服的形式,由客服人员告知用户申诉所需信息,并将用户提供的申诉所需信息主动上传至服务端,后续由审核人员进行审核,再由客服人员通知用户申诉结果。目前这种申诉处理方式,用户申诉体验较差,且效率较低。
发明内容
针对上述技术问题,本说明书实施例提供一种申诉处理方法及系统,技术方案如下:
一种申诉处理方法,应用于申诉处理系统,所述系统包括相互分离配置的用户交互平台和业务处理平台,所述方法包括:
用户交互平台,接收用户侧发送的申诉请求;根据所述申诉请求,确定本次申诉业务的特征信息;将所确定的特征信息发送至业务处理平台;
业务处理平台,根据所述特征信息,确定针对本次申诉业务的交互页面生成策略,并将所确定的交互页面生成策略发送至用户交互平台;所述交互页面生成策略,至少用于规定本次申诉业务所需用户填写的申诉信息;
用户交互平台,根据所述交互页面生成策略,生成针对本次申诉业务的交互页面,并将所述交互页面向用户侧呈现;接收到用户基于所述交互页面填写的申诉信息后,将所述申诉信息发送至业务处理平台,使业务处理平台对本次申诉业务进行处理。
一种申诉处理方法,应用于申诉处理系统中的用户交互平台,所述系统包括相互分离配置的用户交互平台和业务处理平台,所述用户交互平台执行以下方法:
接收用户侧发送的申诉请求;根据所述申诉请求,确定本次申诉业务的特征信息;将所确定的特征信息发送至业务处理平台;
接收业务处理平台根据所述特征信息返回的交互页面生成策略;根据所述交互页面生成策略,生成针对本次申诉业务的交互页面,并将所述交互页面向用户侧呈现;所述交互页面生成策略,至少用于规定本次申诉业务所需用户填写的申诉信息;
接收到用户基于所述交互页面填写的申诉信息后,将所述申诉信息发送至业务处理平台,使业务处理平台对本次申诉业务进行处理。
一种申诉处理方法,应用于申诉处理系统中的业务处理平台,所述系统包括相互分离配置的用户交互平台和业务处理平台,所述业务处理平台执行以下方法:
接收用户交互平台发送的特征信息;根据所述特征信息,确定针对本次申诉业务的交互页面生成策略,并将所确定的交互页面生成策略发送至用户交互平台,以使用户交互平台,根据所述交互页面生成策略,生成针对本次申诉业务的交互页面,将所述交互页面向用户侧呈现,并将接收到的用户基于所述交互页面填写的申诉信息发送至业务处理平台;
所述交互页面生成策略,至少用于规定本次申诉业务所需用户填写的申诉信息;
接收用户交互平台发送的申诉信息,根据所述申诉信息针对本次申诉业务进行处理。
一种申诉处理系统,所述系统包括:相互分配配置的用户交互平台和业务处理平台;
用户交互平台,接收用户侧发送的申诉请求;根据所述申诉请求,确定本次申诉业务的特征信息;将所确定的特征信息发送至业务处理平台;
业务处理平台,根据所述特征信息,确定针对本次申诉业务的交互页面生成策略,并将所确定的交互页面生成策略发送至用户交互平台;所述交互页面生成策略,至少用于规定本次申诉业务所需用户填写的申诉信息;
用户交互平台,根据所述交互页面生成策略,生成针对本次申诉业务的交互页面,并将所述交互页面向用户侧呈现;接收到用户基于所述交互页面填写的申诉信息后,将所述申诉信息发送至业务处理平台,使业务处理平台对本次申诉业务进行处理。
一种申诉处理装置,应用于申诉处理系统中的用户交互平台,所述系统包括相互分离配置的用户交互平台和业务处理平台,所述装置包括:
请求接收模块,用于接收用户侧发送的申诉请求;
信息确定模块,用于根据所述申诉请求,确定本次申诉业务的特征信息;
第一发送模块,用于将所确定的特征信息发送至业务处理平台;
策略接收模块,用于接收业务处理平台根据所述特征信息返回的交互页面生成策略;
页面生成模块,用于根据所述交互页面生成策略,生成针对本次申诉业务的交互页面,并将所述交互页面向用户侧呈现;所述交互页面生成策略,至少用于规定本次申诉业务所需用户填写的申诉信息;
第二发送模块,用于接收到用户基于所述交互页面填写的申诉信息后,将所述申诉信息发送至业务处理平台,使业务处理平台对本次申诉业务进行处理。
一种申诉处理装置,应用于申诉处理系统中的业务处理平台,所述系统包括相互分离配置的用户交互平台和业务处理平台,所述装置包括:
第一接收模块,用于接收用户交互平台发送的特征信息;
策略确定模块,用于根据所述特征信息,确定针对本次申诉业务的交互页面生成策略;
策略发送模块,用于将所确定的交互页面生成策略发送至用户交互平台,以使用户交互平台,根据所述交互页面生成策略,生成针对本次申诉业务的交互页面,将所述交互页面向用户侧呈现,并将接收到的用户基于所述交互页面填写的申诉信息发送至业务处理平台;
所述交互页面生成策略,至少用于规定本次申诉业务所需用户填写的申诉信息;
第二接收模块,用于接收用户交互平台发送的申诉信息,根据所述申诉信息针对本次申诉业务进行处理。
本说明书实施例所提供的技术方案,通过相互分离配置的用户交互平台与业务处理平台,由用户交互平台根据申诉请求确定本次申诉业务的特征信息,并发送至业务处理平台,业务处理平台根据特征信息确定针对本次申诉业务的交互页面生成策略,并发送至用户交互平台,用户交互平台根据交互页面生成策略,生成针对本次申诉业务的交互页面,并呈现给用户侧,用户交互平台在接收到用户基于交互页面填写的申诉信息后,将申诉信息发送至业务处理平台,使业务处理平台对本次申诉业务进行处理。如此一方面,用户可自助提交申诉信息,提高了用户申诉体验,另一方面对服务端进行解耦合,通过相互分离配置的用户交互平台与业务处理平台来进行申诉业务进行处理,提高了效率。
应当理解的是,以上的一般描述和后文的细节描述仅是示例性和解释性的,并不能限制本说明书实施例。
此外,本说明书实施例中的任一实施例并不需要达到上述的全部效果。
附图说明
为了更清楚地说明本说明书实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本说明书实施例中记载的一些实施例,对于本领域普通技术人员来讲,还可以根据这些附图获得其他的附图。
图1是本说明书实施例的申诉处理方法的交互流程示意图;
图2是本说明书实施例的用户交互平台对接业务处理平台的示意图;
图3是本说明书实施例的根据交互页面生成策略生成交互页面的效果示意图;
图4是本说明书实施例的应用于申诉处理系统中的用户交互平台的申诉处理装置的结构示意图;
图5是本说明书实施例的应用于申诉处理系统中的业务处理平台的申诉处理装置的结构示意图;
图6是用于配置本说明书实施例装置的一种设备的结构示意图。
具体实施方式
随着计算机和互联网的不断发展,在线支付方式得到了快速发展。在线支付方式是一种通过第三方提供的与银行之间的支付接口进行支付的方式,极大地提升了用户购物体验。
虽然在线支付方式可以提升用户的购物体验,但不可避免的也存在一些弊端。例如,在线支付方式存在独特的支付风险,需要实施风险管控。而在风控管控实施的过程中,不可避免的存在误判等情况,导致用户不能进行正常的交易,又或者用户通过在线支付方式购买的商品存在尺寸不符、质量较差等问题。为了解决诸如此类问题,用户可以进行申诉,在申诉通过之后,用户可以进行正常的交易、退货、退款等操作。
目前用户基本通过致电客服的形式,由客服人员告知用户申诉所需信息,并将用户提供的申诉所需信息主动上传至服务端,后续由审核人员进行审核,再由客服人员通知用户申诉结果。目前这种申诉处理方式,用户申诉体验较差,且效率较低。
针对上述问题,本说明书实施例提供一种申诉处理技术方案,通过相互分离配置的用户交互平台与业务处理平台,由用户交互平台根据申诉请求确定本次申诉业务的特征信息,并发送至业务处理平台,业务处理平台根据特征信息确定针对本次申诉业务的交互页面生成策略,并发送至用户交互平台,用户交互平台根据交互页面生成策略,生成针对本次申诉业务的交互页面,并呈现给用户侧,用户交互平台在接收到用户基于交互页面填写的申诉信息后,将申诉信息发送至业务处理平台,使业务处理平台对本次申诉业务进行处理。如此一方面,用户可自助提交申诉信息,提高了用户申诉体验,另一方面对服务端进行解耦合,通过相互分离配置的用户交互平台与业务处理平台来进行申诉业务进行处理,提高了效率。
具体的,本说明书实施例提供的技术方案如下:
用户交互平台,接收用户侧发送的申诉请求;根据所述申诉请求,确定本次申诉业务的特征信息;将所确定的特征信息发送至业务处理平台;
业务处理平台,根据所述特征信息,确定针对本次申诉业务的交互页面生成策略,并将所确定的交互页面生成策略发送至用户交互平台;所述交互页面生成策略,至少用于规定本次申诉业务所需用户填写的申诉信息;
用户交互平台,根据所述交互页面生成策略,生成针对本次申诉业务的交互页面,并将所述交互页面向用户侧呈现;接收到用户基于所述交互页面填写的申诉信息后,将所述申诉信息发送至业务处理平台,使业务处理平台对本次申诉业务进行处理。
其中,在本说明书实施例中,对服务端进行解耦合(前后端分离),通过相互分离配置的用户交互平台与业务处理平台来进行申诉业务进行处理,用户交互平台负责与用户进行交互,而业务处理平台负责业务逻辑处理,这样一方面可以防止服务端日益臃肿,另一方面用户交互平台与业务处理平台各司其职,可以显著提高申诉业务处理效率。
另外,对于用户交互平台,可以配置于服务端或者客户端,本说明书实施例对此不作限定。
为了使本领域技术人员更好地理解本说明书实施例中的技术方案,下面将结合本说明书实施例中的附图,对本说明书实施例中的技术方案进行详细地描述,显然,所描述的实施例仅仅是本说明书的一部分实施例,而不是全部的实施例。基于本说明书中的实施例,本领域普通技术人员所获得的所有其他实施例,都应当属于保护的范围。
如图1所示,为本说明书实施例提供的申诉处理方法的实施流程示意图,该方法具体可以包括以下步骤:
S101,用户交互平台,接收用户侧发送的申诉请求;
在本说明书实施例中,在现实生活环境中,由于各种各样的原因,例如用户不能进行正常的交易,又或者用户购买的商品存在尺寸不符、质量较差等问题,用户需要进行申诉,用户需要在用户交互平台侧发起申诉请求,在用户交互平台这一侧,接收用户侧发送的申诉请求。
例如,对于用户交互平台,可以配置于客户端,用户在客户端某个支付页面上,点击“我要申诉”的选项,由该支付页面跳转至用户交互平台,用户点击“我要申诉”的选项,用户申诉请求触发,在用户交互平台这一侧,可以接收到用户侧发送的申诉请求。
S102,用户交互平台,根据所述申诉请求,确定本次申诉业务的特征信息;
针对S101中用户侧发送的申诉请求,确定本次申诉业务的特征信息,对于申诉业务的特征信息,其存在多种形式。
对于申诉业务的特征信息,可以是用户ID或者任务ID。例如,用户ID可以是用户账户昵称、用户账户号码等,任务ID可以是任务编号等,本说明书实施例对此不作限定。
对于申诉业务的特征信息,可以是申诉业务类型。例如,申诉业务类型可以是国内退货申诉、国外退货申诉、国内退货申诉、国外退款申诉,或者账户解冻申诉,或者各个不同电商平台的申诉(淘宝申诉、天猫申诉、天猫海外申诉等),本说明书实施例对此不作限定。
对于申诉业务的特征信息,可以是电商平台类型。例如,电商平台类型可以是淘宝、天猫国内、天猫国外以及其它电商平台(如lazada及daraz)等,本说明书实施例对此不作限定。
对于申诉业务的特征信息,可以是用户类型。例如,用户类型可以是买家、卖家等,本说明书实施例对此不作限定。
对于申诉业务的特征信息,本说明书实施例从多维度进行了阐述说明,当然也可以是其它信息,本说明书实施例在此不再一一赘述。
S103,用户交互平台,将所确定的特征信息发送至业务处理平台;
针对S102中所确定的特征信息,用户交互平台可以将其发送至业务处理平台。其中特征信息可以是上述特征信息中的任意其中一种,或者可以是其它信息,可以根据实际需求设置,本说明书实施例对此不作限定。
另外,在本说明书实施例中,可以包括多个业务处理平台,每个业务处理平台可独立处理申诉业务,即一个用户交互平台对接多个业务处理平台,如图2所示。
例如,在本说明书实施例中,用户交互平台可以对接淘宝申诉业务处理平台、天猫国内申诉业务处理平台、天猫国外申诉业务处理平台、lazada申诉业务处理平台以及daraz申诉业务处理平台等,每个业务处理平台可独立处理申诉业务。
又例如,在本说明书实施例中,用户交互平台可以对接国内退货申诉业务处理平台、国外退货申诉业务处理平台、国内退款申诉业务处理平台、国外退款申诉业务处理平台、国内账户解冻申诉业务处理平台、国外账户解冻申诉业务处理平台等,每个业务处理平台可独立处理申诉业务。
又例如,在本说明书实施例中,用户交互平台可以对接买家申诉业务处理平台、卖家申诉业务处理平台等,每个业务处理平台可独立处理申诉业务。
基于上述用户交互平台对接多个业务处理平台,需要确定目标业务处理平台,将所确定的特征信息发送至该目标业务处理平台,具体实现方式为:
根据预设的申诉业务分派策略,确定用于处理本次申诉业务的目标业务处理平台,并将所确定的特征信息发送至该目标业务处理平台。
在本说明书实施例中,上述申诉业务分派策略可以是申诉业务特征信息与业务处理平台的对应关系,即用户交互平台中,预先配置有申诉业务特征信息与业务处理平台的对应关系,查询申诉业务特征信息与业务处理平台的对应关系,可以确定用于处理本次申诉业务的目标业务处理平台,然后将所确定的特征信息发送至该目标业务处理平台。
例如,在用户交互平台中,预先配置申诉业务特征信息与业务处理平台的对应关系,如下表1所示:
特征信息 |
业务处理平台 |
淘宝申诉 |
业务处理平台1 |
天猫申诉 |
业务处理平台2 |
天猫海外申诉 |
业务处理平台3 |
表1
当申诉业务特征信息为淘宝申诉时,查询上述申诉业务特征信息与业务处理平台的对应关系,确定用于处理本次申诉业务的目标业务处理平台1,将所确定的特征信息发送至该目标业务处理平台1。
又例如,在用户交互平台中,预先配置申诉业务特征信息与业务处理平台的对应关系,如下表2所示:
特征信息 |
业务处理平台 |
国内退货申诉 |
业务处理平台1 |
国外退货申诉 |
业务处理平台2 |
国内退款申诉 |
业务处理平台3 |
表2
当申诉业务特征信息为国内退货申诉时,查询上述申诉业务特征信息与业务处理平台的对应关系,确定用于处理本次申诉业务的目标业务处理平台1,将所确定的特征信息发送至该目标业务处理平台1。
S104,业务处理平台,根据所述特征信息,确定针对本次申诉业务的交互页面生成策略;
在业务处理平台这一侧,接收用户交互平台发送的特征信息,根据该特征信息,确定针对本次申诉业务的交互页面生成策略,用以在用户交互平台侧生成交互页面。
在业务处理平台这一侧,预先配置与特征信息相匹配的交互页面生成策略。例如,业务处理平台处理账户解冻业务,预先配置与账户解冻申诉相匹配的交互页面生成策略。又例如,业务处理平台处理淘宝申诉业务,预先配置与淘宝申诉相匹配的交互页面生成策略。
例如,业务处理平台接收用户交互平台发送的特征信息为账户解冻申诉,可以确定针对本次申诉业务(账户解冻)的交互页面生成策略。
又例如,业务处理平台接收用户交互平台发送的特征信息为国内退款申诉,可以确定针对本次申诉业务(国内退款)的交互页面生成策略。
S105,业务处理平台,将所确定的交互页面生成策略发送至用户交互平台;所述交互页面生成策略,至少用于规定本次申诉业务所需用户填写的申诉信息;
对于所确定的交互页面生成策略,业务处理平台将其发送至用户交互平台。其中该交互页面生成策略,至少用于规定本次申诉业务所需用户填写的申诉信息。
例如,该交互页面生成策略,至少用于规定本次申诉业务(账户解冻)所需用户填写的申诉信息:用户有效身份证件信息(例如身份证正反图片、驾照正面图片、社保卡正面图片等)和至少一对银行卡信息(例如银行卡编号)与账单信息,银行卡信息与账单信息一一对应,除此之外还可以包括与用户进行联系的信息(例如用户邮箱、用户手机等),本说明书实施例对此不作限定。
除此之外,该交互页面生成策略中还可以包括:针对申诉业务所需用户填写的申诉信息的渲染规则。例如,针对申诉业务所需用户填写的申诉信息横排显示或者竖排显示等,本说明书实施例对此不作限定。
另外,在上述特征信息为用户ID,或者任务ID,或者电商平台类型,或者用户类型等情形时,该交互页面生成策略中还可以包括:申诉业务类型,与上述申诉业务类型相似,本说明书实施例在此不再一一赘述。
在本说明书实施例中,对于交互页面生成策略,意味着至少规定本次申诉业务所需用户填写的申诉信息,当然也可以包括其它信息,例如本说明书实施例列举的上述信息,本说明书实施例对此不作限定。
S106,用户交互平台,根据所述交互页面生成策略,生成针对本次申诉业务的交互页面,并将所述交互页面向用户侧呈现;
在用户交互平台这一侧,接收业务处理平台根据特征信息返回的交互页面生成策略,该交互页面生成策略至少规定本次申诉业务所需用户填写的申诉信息,根据该交互页面生成策略,用户交互平台可以生成针对本次申诉业务的交互页面,并将该交互页面向用户侧呈现。
例如,用户交互平台接收业务处理平台根据特征信息返回的交互页面生成策略,该交互页面生成策略至少规定本次申诉业务所需用户填写的申诉信息为:有效身份证件证明、有效交易材料证明、联系邮箱等,根据该交互页面生成策略,用户交互平台可以生成针对本次申诉业务的交互页面,并将该交互页面向用户侧呈现,如图3所示。
S107,用户交互平台,接收到用户基于所述交互页面填写的申诉信息后,将所述申诉信息发送至业务处理平台,使业务处理平台对本次申诉业务进行处理。
针对S106中用户交互平台生成的交互页面,用户可以根据提示输入申诉信息,在用户交互平台这一侧,接收用户基于交互页面填写的申诉信息,并在接收到用户基于交互页面填写的申诉信息后,将该申诉信息发送至业务处理平台,使业务处理平台对本次申诉业务进行处理。
其中,对于用户基于交互页面填写的申诉信息,可以解析该申诉信息,以预设信息传递格式发送至业务处理平台。例如,解析该申诉信息,以JSON格式发送至业务处理平台。
另外,在将申诉信息发送至业务处理平台之前,按照预设的校验规则对申诉信息进行校验,这里可以是形式校验,业务校验交由业务处理平台来负责。
例如,用户需要填写的申诉信息为:有效身份证件证明,可以检查其形式是否合法,后续由业务处理平台来负责实质校验。
其次,为了体现用户交互友好性,在将申诉信息发送至业务处理平台之前,判断是否接收到用户发送的信息递交指令,在接收到用户发送的信息递交指令的情况下,将申诉信息发送至业务处理平台。
再者,为了保护用户申诉信息安全,不被泄露,可以在将申诉信息发送至业务处理平台之前,按照预设的加密算法对申诉信息进行加密,将加密后的申诉信息发送至业务处理平台。这里加密算法可以是对称加密算法,也可以是非对称加密算法,本说明书实施例对此不作限定。
例如,业务处理平台预先生成公钥与私钥,将自身公钥告知用户交互平台,其中对于业务处理平台生成公钥与密钥的方式,可以采用现有技术,本说明书对此不作限定。用户交互平台利用业务处理平台公钥对该申诉信息进行加密,并将经过加密的该申诉信息发送至业务处理平台。本说明书实施例中具体采用的加密算法可以是RSA、Elgamal等非对称加密算法,还可以是其它非对称加密算法,本说明书实施例对采用的非对称加密算法不作限定,可以是当前任意一种非对称加密算法。
对于上述本说明书实施例提供的几种优选实施例,可以结合使用,本说明书实施例对此不作限定。
在业务处理平台这一侧,接收申诉信息,根据申诉信息对本次申诉业务进行处理,具体申诉业务处理过程本说明书实施例在此不再一一赘述,可以依据现有技术方案进行申诉业务处理。
针对本次申诉业务的处理结果,业务处理平台可以将其发送至用户交互平台,其中发送时机可以根据实际需求设置:
业务处理平台主动将针对本次申诉业务的处理结果发送至用户交互平台;
或者
用户交互平台在接收到用户输入的处理结果查询指令的情况下,向业务交互平台发送处理结果查询的消息;
业务处理平台在接收到用户交互平台发送的消息的情况下,将针对本次申诉业务的处理结果发送至用户交互平台。
用户交互平台在接收到业务处理平台返回的处理结果之后,根据针对本次申诉业务的处理结果,进行输出显示。
通过上述对本说明书实施例提供的技术方案的描述,通过相互分离配置的用户交互平台与业务处理平台,由用户交互平台根据申诉请求确定本次申诉业务的特征信息,并发送至业务处理平台,业务处理平台根据特征信息确定针对本次申诉业务的交互页面生成策略,并发送至用户交互平台,用户交互平台根据交互页面生成策略,生成针对本次申诉业务的交互页面,并呈现给用户侧,用户交互平台在接收到用户基于交互页面填写的申诉信息后,将申诉信息发送至业务处理平台,使业务处理平台对本次申诉业务进行处理。如此一方面,用户可自助提交申诉信息,提高了用户申诉体验,另一方面对服务端进行解耦合,通过相互分离配置的用户交互平台与业务处理平台来进行申诉业务进行处理,提高了效率。
为了更清楚地说明本说明书实施例的方案,下面分别再从单侧的角度,对于执行的方法进行说明:
在用户交互平台这一侧,主要执行的步骤如下:
A,接收用户侧发送的申诉请求;根据所述申诉请求,确定本次申诉业务的特征信息;将所确定的特征信息发送至业务处理平台;
B,根据所述交互页面生成策略,生成针对本次申诉业务的交互页面,并将所述交互页面向用户侧呈现;接收到用户基于所述交互页面填写的申诉信息后,将所述申诉信息发送至业务处理平台,使业务处理平台对本次申诉业务进行处理;
在业务处理平台这一侧,主要执行的步骤如下:
C,根据所述特征信息,确定针对本次申诉业务的交互页面生成策略,并将所确定的交互页面生成策略发送至用户交互平台;所述交互页面生成策略,至少用于规定本次申诉业务所需用户填写的申诉信息;
关于客户端与服务端的单侧执行方法细节,可以参见前面实施例的描述,这里不再赘述。
相应于上述方法实施例,本说明书实施例还提供一种申诉处理装置,参见图4所示,应用于申诉处理系统中的用户交互平台,所述系统包括相互分离配置的用户交互平台和业务处理平台,该装置可以包括:请求接收模块410、信息确定模块420、第一发送模块430、策略接收模块440、页面生成模块450、第二发送模块460。
请求接收模块410,用于接收用户侧发送的申诉请求;
信息确定模块420,用于根据所述申诉请求,确定本次申诉业务的特征信息;
第一发送模块430,用于将所确定的特征信息发送至业务处理平台;
策略接收模块440,用于接收业务处理平台根据所述特征信息返回的交互页面生成策略;
页面生成模块450,用于根据所述交互页面生成策略,生成针对本次申诉业务的交互页面,并将所述交互页面向用户侧呈现;所述交互页面生成策略,至少用于规定本次申诉业务所需用户填写的申诉信息;
第二发送模块460,用于接收到用户基于所述交互页面填写的申诉信息后,将所述申诉信息发送至业务处理平台,使业务处理平台对本次申诉业务进行处理。
本说明书实施例还提供一种申诉处理装置,参见图5所示,应用于申诉处理系统中的业务处理平台,所述系统包括相互分离配置的用户交互平台和业务处理平台,该装置可以包括:第一接收模块510、策略确定模块520、策略发送模块530、第二接收模块540。
第一接收模块510,用于接收用户交互平台发送的特征信息;
策略确定模块520,用于根据所述特征信息,确定针对本次申诉业务的交互页面生成策略;
策略发送模块530,用于将所确定的交互页面生成策略发送至用户交互平台,以使用户交互平台,根据所述交互页面生成策略,生成针对本次申诉业务的交互页面,将所述交互页面向用户侧呈现,并将接收到的用户基于所述交互页面填写的申诉信息发送至业务处理平台;
所述交互页面生成策略,至少用于规定本次申诉业务所需用户填写的申诉信息;
第二接收模块540,用于接收用户交互平台发送的申诉信息,根据所述申诉信息针对本次申诉业务进行处理。
本说明书实施例还提供一种申诉处理系统,所述系统包括:相互分配配置的用户交互平台和业务处理平台;
用户交互平台,接收用户侧发送的申诉请求;根据所述申诉请求,确定本次申诉业务的特征信息;将所确定的特征信息发送至业务处理平台;
业务处理平台,根据所述特征信息,确定针对本次申诉业务的交互页面生成策略,并将所确定的交互页面生成策略发送至用户交互平台;所述交互页面生成策略,至少用于规定本次申诉业务所需用户填写的申诉信息;
用户交互平台,根据所述交互页面生成策略,生成针对本次申诉业务的交互页面,并将所述交互页面向用户侧呈现;接收到用户基于所述交互页面填写的申诉信息后,将所述申诉信息发送至业务处理平台,使业务处理平台对本次申诉业务进行处理。
上述装置中各个模块的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程,在此不再赘述。
通过上述对本说明书实施例提供的技术方案的描述,通过相互分离配置的用户交互平台与业务处理平台,由用户交互平台根据申诉请求确定本次申诉业务的特征信息,并发送至业务处理平台,业务处理平台根据特征信息确定针对本次申诉业务的交互页面生成策略,并发送至用户交互平台,用户交互平台根据交互页面生成策略,生成针对本次申诉业务的交互页面,并呈现给用户侧,用户交互平台在接收到用户基于交互页面填写的申诉信息后,将申诉信息发送至业务处理平台,使业务处理平台对本次申诉业务进行处理。如此一方面,用户可自助提交申诉信息,提高了用户申诉体验,另一方面对服务端进行解耦合,通过相互分离配置的用户交互平台与业务处理平台来进行申诉业务进行处理,提高了效率。
本说明书实施例还提供一种计算机设备,其至少包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,其中,处理器执行所述程序时实现前述的申诉处理方法,该方法至少包括:
接收用户侧发送的申诉请求;根据所述申诉请求,确定本次申诉业务的特征信息;将所确定的特征信息发送至业务处理平台;
接收业务处理平台根据所述特征信息返回的交互页面生成策略;根据所述交互页面生成策略,生成针对本次申诉业务的交互页面,并将所述交互页面向用户侧呈现;所述交互页面生成策略,至少用于规定本次申诉业务所需用户填写的申诉信息;
接收到用户基于所述交互页面填写的申诉信息后,将所述申诉信息发送至业务处理平台,使业务处理平台对本次申诉业务进行处理。
本说明书实施例还提供一种计算机设备,其至少包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,其中,处理器执行所述程序时实现前述的申诉处理方法,该方法至少包括:
接收用户交互平台发送的特征信息;根据所述特征信息,确定针对本次申诉业务的交互页面生成策略,并将所确定的交互页面生成策略发送至用户交互平台;
所述交互页面生成策略,至少用于规定本次申诉业务所需用户填写的申诉信息;
接收用户交互平台发送的申诉信息,根据所述申诉信息针对本次申诉业务进行处理。
图6示出了本说明书实施例所提供的一种更为具体的计算设备硬件结构示意图,该设备可以包括:处理器610、存储器620、输入/输出接口630、通信接口640和总线650。其中处理器610、存储器620、输入/输出接口630和通信接口640通过总线650实现彼此之间在设备内部的通信连接。
处理器610可以采用通用的CPU(Central Processing Unit,中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit,ASIC)、或者一个或多个集成电路等方式实现,用于执行相关程序,以实现本说明书实施例所提供的技术方案。
存储器620可以采用ROM(Read Only Memory,只读存储器)、RAM(Random AccessMemory,随机存取存储器)、静态存储设备,动态存储设备等形式实现。存储器620可以存储操作系统和其他应用程序,在通过软件或者固件来实现本说明书实施例所提供的技术方案时,相关的程序代码保存在存储器620中,并由处理器610来调用执行。
输入/输出接口630用于连接输入/输出模块,以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出),也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等,输出设备可以包括显示器、扬声器、振动器、指示灯等。
通信接口640用于连接通信模块(图中未示出),以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信,也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。
总线650包括一通路,在设备的各个组件(例如处理器610、存储器620、输入/输出接口630和通信接口640)之间传输信息。
需要说明的是,尽管上述设备仅示出了处理器610、存储器620、输入/输出接口630、通信接口640以及总线650,但是在具体实施过程中,该设备还可以包括实现正常运行所必需的其他组件。此外,本领域的技术人员可以理解的是,上述设备中也可以仅包含实现本说明书实施例方案所必需的组件,而不必包含图中所示的全部组件。
本说明书实施例还提供一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现前述的申诉处理方法,该方法至少包括:
接收用户侧发送的申诉请求;根据所述申诉请求,确定本次申诉业务的特征信息;将所确定的特征信息发送至业务处理平台;
接收业务处理平台根据所述特征信息返回的交互页面生成策略;根据所述交互页面生成策略,生成针对本次申诉业务的交互页面,并将所述交互页面向用户侧呈现;所述交互页面生成策略,至少用于规定本次申诉业务所需用户填写的申诉信息;
接收到用户基于所述交互页面填写的申诉信息后,将所述申诉信息发送至业务处理平台,使业务处理平台对本次申诉业务进行处理。
本说明书实施例还提供一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现前述的申诉处理方法,该方法至少包括:
接收用户交互平台发送的特征信息;根据所述特征信息,确定针对本次申诉业务的交互页面生成策略,并将所确定的交互页面生成策略发送至用户交互平台;
所述交互页面生成策略,至少用于规定本次申诉业务所需用户填写的申诉信息;
接收用户交互平台发送的申诉信息,根据所述申诉信息针对本次申诉业务进行处理。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
通过以上的实施方式的描述可知,本领域的技术人员可以清楚地了解到本说明书实施例可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解,本说明书实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在存储介质中,如ROM/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本说明书实施例各个实施例或者实施例的某些部分所述的方法。
上述实施例阐明的系统、装置、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为计算机,计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于装置实施例而言,由于其基本相似于方法实施例,所以描述得比较简单,相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的,在实施本说明书实施例方案时可以把各模块的功能在同一个或多个软件和/或硬件中实现。也可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
以上所述仅是本说明书实施例的具体实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本说明书实施例原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本说明书实施例的保护范围。