数据处理方法及装置与流程

本申请涉及软件领域，具体而言，涉及一种数据处理方法及装置，适用于金融领域。

背景技术

普惠金融，是指以可负担的成本为有金融服务需求的社会各阶层和群体提供适当、有效的金融服务。比如，提供小额贷款。

发明人发现，目前从事普惠金融的群体人员结构参差不齐，群体的专业技能较低，能够提供的普惠金融能力也较为有效。进一步地，对于参与普惠金融的受众群体缺乏有效地数据管理方式，效率较为低下。

针对相关技术中提供金融业务服务的能力不足的问题，目前尚未提出有效的解决方案。

技术实现要素：

本申请的主要目的在于提供一种数据处理方法，以解决提供金融业务服务的能力不足的问题。

为了实现上述目的，根据本申请的一个方面，提供了一种数据处理方法。

根据本申请的数据处理方法包括：接收第一用户的业务订单；判断所述业务订单是否满足预设处理条件；以及如果判断所述业务订单满足预设处理条件，则将所述业务订单分配给第二用户。

进一步地，判断所述业务订单是否满足预设处理条件包括：判断所述业务订单是否满足渠道用户分配条件；如果判断所述业务订单满足预设处理条件，则将所述业务订单分配给第二用户包括：如果判断所述业务订单满足渠道用户分配条件，则将所述业务订单分配给第二用户。

进一步地，如果判断所述业务订单满足预设处理条件，则将所述业务订单分配给第二用户之后还包括：将所述业务订单按照预设分配条件分配给第二用户；根据分配结果向第二用户提供客户信息；其中，所述客户信息至少包括：姓名、联系方式、地址、业务金额、跟进记录中的任一一种或多种。

进一步地，判断所述业务订单是否满足预设处理条件包括：判断所述业务订单是否满足业务办理条件；如果判断所述业务订单满足预设处理条件，则将所述业务订单分配给第二用户包括：如果判断所述业务订单满足业务办理条件，则将所述业务订单按照预设条件向第二用户提供查询接口。

进一步地，接收第一用户的业务订单包括：第二用户通过唯一身份标识登录第二用户账号后接收第一用户的业务订单；和/或，第二用户通过第二用户账号中的添加接口后添加第一用户后接收第一用户的业务订单。

为了实现上述目的，根据本申请的另一方面，提供了一种数据处理装置。

根据本申请的数据处理装置包括：接收模块，接收第一用户的业务订单；判断模块，判断所述业务订单是否满足预设处理条件；以及分配模块，如果判断所述业务订单满足预设处理条件，则将所述业务订单分配给第二用户。

进一步地，所述判断模块包括：第一判断单元、第二判断单元，所述分配模块包括：第一分配单元、第二分配单元，所述第一判断单元，用于判断所述业务订单是否满足渠道用户分配条件；所述第一分配单元，用于在判断所述业务订单满足渠道用户分配条件时，则将所述业务订单分配给第二用户。所述第二判断单元，用于判断所述业务订单是否满足业务办理条件；以及所述第二分配单元，用于在判断所述业务订单满足业务办理条件时，则将所述业务订单按照预设条件向第二用户提供查询接口。

进一步地，装置还包括：客户管理模块，所述客户管理模块用于将所述业务订单按照预设分配条件分配给第二用户；根据分配结果向第二用户提供客户信息；其中，所述客户信息至少包括：姓名、联系方式、地址、业务金额、跟进记录中的任一一种或多种。

进一步地，所述接收模块包括：用户管理单元，所述用户管理单元，用于通过唯一身份标识登录第二用户账号后接收第一用户的业务订单；和/或，所述用户管理单元，用于通过第二用户账号中的添加接口后添加第一用户后接收第一用户的业务订单。

为了实现上述目的，根据本申请的另一方面，提供了客户端，包括：所述的数据处理装置。

在本申请实施例中，采用接收第一用户的业务订单的方式，通过判断所述业务订单是否满足预设处理条件，达到了将所述业务订单分配给第二用户的目的，从而实现了业务工作的合理分配的技术效果，进而解决了提供业务服务的能力不足的的技术问题。

附图说明

构成本申请的一部分的附图用来提供对本申请的进一步理解，使得本申请的其它特征、目的和优点变得更明显。本申请的示意性实施例附图及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请第一实施例的数据处理方法示意图；

图2是根据本申请第二实施例的数据处理方法示意图；

图3是根据本申请第三实施例的数据处理方法示意图；

图4是根据本申请第四实施例的数据处理方法示意图；

图5是根据本申请第五实施例的数据处理方法示意图；

图6是根据本申请第一实施例的数据处理装置示意图；

图7是根据本申请第二实施例的数据处理装置示意图；

图8是根据本申请第三实施例的数据处理装置示意图；以及

图9是根据本申请第四实施例的数据处理装置示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

在本申请中，术语“上”、“下”、“左”、“右”、“前”、“后”、“顶”、“底”、“内”、“外”、“中”、“竖直”、“水平”、“横向”、“纵向”等指示的方位或位置关系为基于附图所示的方位或位置关系。这些术语主要是为了更好地描述本申请及其实施例，并非用于限定所指示的装置、元件或组成部分必须具有特定方位，或以特定方位进行构造和操作。

并且，上述部分术语除了可以用于表示方位或位置关系以外，还可能用于表示其他含义，例如术语“上”在某些情况下也可能用于表示某种依附关系或连接关系。对于本领域普通技术人员而言，可以根据具体情况理解这些术语在本申请中的具体含义。

此外，术语“安装”、“设置”、“设有”、“连接”、“相连”、“套接”应做广义理解。例如，可以是固定连接，可拆卸连接，或整体式构造；可以是机械连接，或电连接；可以是直接相连，或者是通过中间媒介间接相连，又或者是两个装置、元件或组成部分之间内部的连通。对于本领域普通技术人员而言，可以根据具体情况理解上述术语在本申请中的具体含义。

本申请中的数据处理方法能够为普惠金融端客户经理提供业务拓展、获取客户资源、客户管理等的移动便捷式工具，能够帮助销售经理更合规、更高效的从事普惠金融工作。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

如图1所示，该方法包括如下的步骤s102至步骤s106：

步骤s102，接收第一用户的业务订单；

接收到第一用户的业务订单中可以是第一用户的金融业务办理的订单。

第一用户可以是具有申请业务办理需求的渠道用户。

其中，业务订单主要是具有办理意向的用户，通过业务订单能够收集用户的意向。业务订单的获取方式为相应办理渠道的用户。通过接收第一用户的业务订单能够获取来自不同渠道的客户资源，并为下一步数据处理做准备。

比如，用户甲通过手机注册并申请需要申请金额8万，所在城市北京。

又比如，用户乙通过电脑注册并申请需要申请金额2万，所在城市上海。

再比如，用户丙通过即时通讯软件的小程序申请需要申请金额1万，所在城北京。

步骤s104，判断所述业务订单是否满足预设处理条件；

判断业务订单是否满足预设处理条件可以是判断业务订单是否满足相关的业务办理条件。比如，是申请贷款，还是想要购买保险。

通过判断所述业务订单是否满足预设处理条件，能够对提前对数据处理进行预先意向分类，并删选出满足预设处理条件的多条数据。

判断业务订单是否满足预设处理条件可以是判断业务订单是否满足提供必要的用户信息。比如，提供的联系方式是手机号码，还是即时通讯软件的账号。

通过判断所述业务订单是否满足预设处理条件，能够对提前对数据处理进行预先联络渠道分类，并删选出满足预设处理条件的多条数据。

判断业务订单是否满足预设处理条件可以是判断业务订单是否满足业务覆盖区域。比如，提供的区域属于华北地区，还是属于华南地区。

通过判断所述业务订单是否满足预设处理条件，能够对提前对数据处理进行预先地域分类，并删选出满足预设处理条件的多条数据。

判断业务订单是否满足预设处理条件可以是判断业务订单是否满足提供必要的申请金额信息。比如，提供的金额是否满足下限，还是金额是否达到上限。

通过判断所述业务订单是否满足预设处理条件，能够对提前对数据处理进行预先限额分类，并删选出满足预设处理条件的多条数据。

优选地，判断所述业务订单是否满足预设处理条件时可以监测是否有第二用户发出的“抢单”操作。“抢单”操作是指，第二用户主动发出处理业务订单的请求，并按照相关预设规则判定是否满足预设处理条件。

步骤s106，如果判断所述业务订单满足预设处理条件，则将所述业务订单分配给第二用户。

如果业务订单满足预设处理条件，则可以将上述的业务订单分配给第二用户。

第二用户可以是具有相关资质或操作权限的销售经纪人、销售经理。

将业务订单分配给第二用户后，第二用户即可具有后续的操作权限。

操作权限可以是，客户跟进记录操作、客户联系操作。客户跟进记录操作是指能够记录所有与客户联系的日志。客户联系操作是指可通过短信、电话以及其他即时通信软件联系方式。

优选地，第二用户还可以记录第一用户的获取来源，比如手工输入、通过抢单获得、通过网络获得以及微店等方式获得。

从以上的描述中，可以看出，本申请实现了如下技术效果：

在本申请实施例中，采用接收第一用户的业务订单的方式，通过判断所述业务订单是否满足预设处理条件，达到了将所述业务订单分配给第二用户的目的，从而实现了业务工作的合理分配的技术效果，进而解决了提供业务服务的能力不足的的技术问题。

根据本申请实施例，作为本实施例中的优选，如图2所示，判断所述业务订单是否满足预设处理条件包括：

步骤s202，判断所述业务订单是否满足渠道用户分配条件；

渠道用户分配条件是指按照地域、申请金额区间以及“抢单”的时间差。具体地，按照地域的渠道用户分配条件是通过第二用户所在的地理位置与第一用户所在地理位置的相似度进行排列，相似度越高的具有优先分配条件。申请金额区间的渠道用户分配条件是通过第一用户所申请的金额多少分配属于不同等级的第二用户进行处理。“抢单”的时间差的渠道用户分配条件是通过第二用户对第一用户业务订单中接单时间的快慢分配接单时间较快的第二用户进行操作。

如果判断所述业务订单满足预设处理条件，则将所述业务订单分配给第二用户包括：

步骤s204，如果判断所述业务订单满足渠道用户分配条件，则将所述业务订单分配给第二用户。

将所述业务订单分配给第二用户后，第二用户具有相关的订单操作权限。

比如，第二用户具有填写跟进第一用户跟进记录的操作权限。

又比如，第二用户具有电话联系第一用户的操作权限。

再比如，第二用户具有通过即时通讯软件联系第一用户的操作权限。

根据本申请实施例，作为本实施例中的优选，如图3所示，如果判断所述业务订单满足预设处理条件，则将所述业务订单分配给第二用户之后还包括：

步骤s302，将所述业务订单按照预设分配条件分配给第二用户；

预设分配条件可以是第二用户的接单响应时间，接单响应时间是指在接收到业务订单之后到发起接单的时间过程。

步骤s304，根据分配结果向第二用户提供客户信息；

所述客户信息至少包括：姓名、联系方式、地址、业务金额、跟进记录中的任一一种或多种。

此外，在跟进记录中可以包括：记录用户的所有联系状态，比如，用户“有意向下次沟通”，“客户现在忙”，“电话无人接听”、“无意向”。

根据本申请实施例，作为本实施例中的优选，如图4所示，判断所述业务订单是否满足预设处理条件包括：

步骤s402，判断所述业务订单是否满足业务办理条件；

在第二用户通过终端登录后，通过判断业务订单是否满足业务办理条件，能够进一步对第二用户开放进件查询接口。通过将满足业务办理条件的进行管理分配，能够满足后续的查询条件。

比如，第一用甲进行了两次业务办理申请，通过判断业务办理申请是否符合条件，为后续的第二用户查询已办理的申请提供查询条件。

进一步地，在服务端的数据存储层，可以使用mysql进行数据持久化，并进行读写分离，提高多用户访问时的性能。

如果判断所述业务订单满足预设处理条件，则将所述业务订单分配给第二用户包括：

步骤s404，如果判断所述业务订单满足业务办理条件，则将所述业务订单按照预设条件向第二用户提供查询接口。

第二用户可以通过该查询接口查询到满足业务办理条件的订单的状态，比如正在申请中，已经申请成功等，实时获得第一用户的业务申请请求进度。

进一步地，在数据访问层：可以使用ado.netef和sqlclient两种方式进行数据访问，满足不同场景下对数据访问的要求。

根据本申请实施例，作为本实施例中的优选，如图5所示，接收第一用户的业务订单包括：

步骤s502，第二用户通过唯一身份标识登录第二用户账号后接收第一用户的业务订单；

通过唯一身份标识能够有效地管理第二用户的第二用户账号，防止数据的泄露。

比如，用户通过内部员工编号进行登录。

又比如，用户通过身份证号码进行登录。

和/或，步骤s504，第二用户通过第二用户账号中的添加接口后添加第一用户后接收第一用户的业务订单。

通过第二用户账号中的添加接口后添加第一用户后接收第一用户的业务订单即支持手动添加的方式。

需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

根据本申请实施例，还提供了一种用于实施上述数据处理方法的装置，如图6所示，该装置包括：接收模块10，接收第一用户的业务订单；判断模块20，判断所述业务订单是否满足预设处理条件；以及分配模块30，如果判断所述业务订单满足预设处理条件，则将所述业务订单分配给第二用户。

在本申请实施例的接收模块10中接收到第一用户的业务订单中可以是第一用户的金融业务办理的订单。

第一用户可以是具有申请业务办理需求的渠道用户。

其中，业务订单主要是具有办理意向的用户，通过业务订单能够收集用户的意向。业务订单的获取方式为相应办理渠道的用户。通过接收第一用户的业务订单能够获取来自不同渠道的客户资源，并为下一步数据处理做准备。

比如，用户甲通过手机注册并申请需要申请金额8万，所在城市北京。

又比如，用户乙通过电脑注册并申请需要申请金额2万，所在城市上海。

再比如，用户丙通过即时通讯软件的小程序申请需要申请金额1万，所在城北京。

在本申请实施例的判断模块20中判断业务订单是否满足预设处理条件可以是判断业务订单是否满足相关的业务办理条件。比如，是申请贷款，还是想要购买保险。

通过判断所述业务订单是否满足预设处理条件，能够对提前对数据处理进行预先意向分类，并删选出满足预设处理条件的多条数据。

判断业务订单是否满足预设处理条件可以是判断业务订单是否满足提供必要的用户信息。比如，提供的联系方式是手机号码，还是即时通讯软件的账号。

通过判断所述业务订单是否满足预设处理条件，能够对提前对数据处理进行预先联络渠道分类，并删选出满足预设处理条件的多条数据。

判断业务订单是否满足预设处理条件可以是判断业务订单是否满足业务覆盖区域。比如，提供的区域属于华北地区，还是属于华南地区。

通过判断所述业务订单是否满足预设处理条件，能够对提前对数据处理进行预先地域分类，并删选出满足预设处理条件的多条数据。

判断业务订单是否满足预设处理条件可以是判断业务订单是否满足提供必要的申请金额信息。比如，提供的金额是否满足下限，还是金额是否达到上限。

通过判断所述业务订单是否满足预设处理条件，能够对提前对数据处理进行预先限额分类，并删选出满足预设处理条件的多条数据。

优选地，判断所述业务订单是否满足预设处理条件时可以监测是否有第二用户发出的“抢单”操作。“抢单”操作是指，第二用户主动发出处理业务订单的请求，并按照相关预设规则判定是否满足预设处理条件。

在本申请实施例的分配模块30中如果业务订单满足预设处理条件，则可以将上述的业务订单分配给第二用户。

第二用户可以是具有相关资质或操作权限的销售经纪人、销售经理。

将业务订单分配给第二用户后，第二用户即可具有后续的操作权限。

操作权限可以是，客户跟进记录操作、客户联系操作。客户跟进记录操作是指能够记录所有与客户联系的日志。客户联系操作是指可通过短信、电话以及其他即时通信软件联系方式。

优选地，第二用户还可以记录第一用户的获取来源，比如手工输入、通过抢单获得、通过网络获得以及微店等方式获得。

根据本申请实施例，作为本实施例中的优选，如图7所示，所述判断模块20包括：第一判断单元201、第二判断单元202，所述分配模块包括：第一分配单元301、第二分配单元302，所述第一判断单元201，用于判断所述业务订单是否满足渠道用户分配条件；所述第一分配单元202，用于在判断所述业务订单满足渠道用户分配条件时，则将所述业务订单分配给第二用户。所述第二判断单元301，用于判断所述业务订单是否满足业务办理条件；以及所述第二分配单元302，用于在判断所述业务订单满足业务办理条件时，则将所述业务订单按照预设条件向第二用户提供查询接口。

在本申请实施例的第一判断单元201中渠道用户分配条件是指按照地域、申请金额区间以及“抢单”的时间差。具体地，按照地域的渠道用户分配条件是通过第二用户所在的地理位置与第一用户所在地理位置的相似度进行排列，相似度越高的具有优先分配条件。申请金额区间的渠道用户分配条件是通过第一用户所申请的金额多少分配属于不同等级的第二用户进行处理。“抢单”的时间差的渠道用户分配条件是通过第二用户对第一用户业务订单中接单时间的快慢分配接单时间较快的第二用户进行操作。

在本申请实施例的第二判断单元202中将所述业务订单分配给第二用户后，第二用户具有相关的订单操作权限。

比如，第二用户具有填写跟进第一用户跟进记录的操作权限。

又比如，第二用户具有电话联系第一用户的操作权限。

再比如，第二用户具有通过即时通讯软件联系第一用户的操作权限。

在本申请实施例的第一分配单元301中在第二用户通过终端登录后，通过判断业务订单是否满足业务办理条件，能够进一步对第二用户开放进件查询接口。通过将满足业务办理条件的进行管理分配，能够满足后续的查询条件。

比如，第一用甲进行了两次业务办理申请，通过判断业务办理申请是否符合条件，为后续的第二用户查询已办理的申请提供查询条件。

进一步地，在服务端的数据存储层，可以使用mysql进行数据持久化，并进行读写分离，提高多用户访问时的性能。

在本申请实施例的第二分配单元302中第二用户可以通过该查询接口查询到满足业务办理条件的订单的状态，比如正在申请中，已经申请成功等，实时获得第一用户的业务申请请求进度。

进一步地，在数据访问层：可以使用ado.netef和sqlclient两种方式进行数据访问，满足不同场景下对数据访问的要求。

根据本申请实施例，作为本实施例中的优选，如图8所示，装置还包括：客户管理模块40，所述客户管理模块40用于将所述业务订单按照预设分配条件分配给第二用户；根据分配结果向第二用户提供客户信息；其中，所述客户信息至少包括：姓名、联系方式、地址、业务金额、跟进记录中的任一一种或多种。

在本申请实施例的客户管理模块40中预设分配条件可以是第二用户的接单响应时间，接单响应时间是指在接收到业务订单之后到发起接单的时间过程。

所述客户信息至少包括：姓名、联系方式、地址、业务金额、跟进记录中的任一一种或多种。

此外，在跟进记录中可以包括：记录用户的所有联系状态，比如，用户“有意向下次沟通”，“客户现在忙”，“电话无人接听”、“无意向”。

根据本申请实施例，作为本实施例中的优选，如图9所示，所述接收模块10包括：用户管理单元101，所述用户管理单元101，用于通过唯一身份标识登录第二用户账号后接收第一用户的业务订单；通过唯一身份标识能够有效地管理第二用户的第二用户账号，防止数据的泄露。

比如，用户通过内部员工编号进行登录。

又比如，用户通过身份证号码进行登录。

和/或，所述用户管理单元101，用于通过第二用户账号中的添加接口后添加第一用户后接收第一用户的业务订单。

通过第二用户账号中的添加接口后添加第一用户后接收第一用户的业务订单即支持手动添加的方式。

显然，本领域的技术人员应该明白，上述的本申请的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本申请不限制于任何特定的硬件和软件结合。

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