信息交互系统的制作方法

本公开涉及通信技术领域，具体涉及一种信息交互系统。

背景技术：

随着信息技术的不断发展，通信应用程序的功能日益丰富。现在，通信应用程序已经不再单纯的作为聊天工具，而是发展成为集交流、咨询、娱乐、搜索、电子商务、办公协作、企业客户服务和营销等服务为一体的综合化信息平台。

为了能够与群体客户进行更好的交互，公众号以及公众号服务平台应运而生。企业在公众号服务平台申请作为应用帐号的公众号之后，可以利用公众号在公众号服务平台上与其客户群体之间进行文字、图片、语音等信息的全方位交互、沟通，以满足企业对营销和客服等方面的需求。

对于企业级的公众号，公众号开发者一般需要部署两类服务：一类是对于来自公众号的各种请求的进行处理的核心业务服务，一类是通过公众号与客户之间进行交互的交互服务。举例而言，上述交互服务中通过公众号接收客户的信息，核心业务服务对接收信息的进行分析处理后得到响应信息，最后通过交互服务将响应信息返回至客户，完成与客户的交互。

如图1中所示，现有技术中，上述两类服务通常被部署在同一台服务器上，而不会进行区分，使得服务器压力面临双重压力，特别是在对于通过公众号服务平台和客户交流频繁的公众号，其对应的服务器处理核心业务的能力会明显下降。对于此种信息交互系统架构，一方面，不利于开发人员对核心业务服务的开发，另一方面，不利于向客户提供更好的交互服务。此外，由于公众号对应的服务器之间是独立的，进而各公众号交互相关的信息之间也是相互隔离的，无法实现共享，这对于同一企业旗下多个公众号业务的耦合拓展非常不利。

技术实现要素：

本公开的目的在于提供一种信息交互系统，用于至少在一定程度上克服由于相关技术的限制和缺陷而导致的一个或多个问题。

本公开的其他特性和优点将通过下面的详细描述变得清晰，或部分地通过本公开的实践而习得。

根据本公开的第一方面，提供一种信息交互系统，用于通过公众号与客户进行交互；所述信息交互系统包括独立的交互服务器以及后台服务器；其中：

所述交互服务器包括：

接收模块，用于自公众号服务平台接收客户向所述公众号发送的信息；

获取模块，用于根据所述接收模块接收的信息生成一请求信息并发出；

发送模块，用于接收一响应信息并通过公众号服务平台利用所述公众号将所述响应信息发送给所述客户；

所述后台服务器包括：

处理模块，用于接收所述获取模块发出的请求信息，并根据所述请求信息生成对应的响应信息发送至所述发送模块。

本公开的一种示例性实施例中，所述交互服务器还包括：

MySQL数据库，具有一第一安全级别，用于存储第一类型数据信息；

NoSQL数据库，具有一第二安全级别，用于存储第二类型数据信息；

其中，所述第一安全级别高于所述第二安全级别，所述第一类型数据信息所需的访问权限较所述第二类型数据信息更高，所述第二类型数据信息被访问的频率较所述第一类型数据信息更高。

本公开的一种示例性实施例中，所述第一类型数据信息为高访问权限数据信息，包括管理员信息、客户信息、多媒体文件参数以及客户交易记录中的一种或多种；在本发明中，所述高访问权限数据信息是指公众号与客户之间进行信息交互过程中被访问或调取等操作频率低于预设频率，但由于包含诸如客户隐私等因素而需具有保密要求的数据信息，其中所述的信息交互过程包括：公众号响应客户需求而进行的互动过程、公众号主动向客 户派送信息的过程等等。

所述第二类型数据信息为高访问频率数据信息，包括客户和公众号消息、公众号参数信息、通信端口、机器应答信息、支付凭据以及服务链接中的一种或多种。在本发明中，所述高访问频率数据信息是指公众号与客户之间进行信息交互过程中被访问或调取等操作频率高于预设频率的数据信息，其中所述的信息交互过程包括：公众号响应客户需求而进行的互动过程、公众号主动向客户派送信息的过程等等。

本公开的一种示例性实施例中，所述交互服务器还包括：

NAS数据库，用于存储归档数据信息。

本公开的一种示例性实施例中，所述归档数据信息包括多媒体文件、业务办理资料、客户操作记录以及日志文件中的一种或多种。

本公开的一种示例性实施例中，所述公众号为多个，所有所述公众号共用各所述数据库。

本公开的一种示例性实施例中，所述交互服务器还包括：

判断模块，用于判断所述接收模块接收的信息的类型：

若所述判断模块判断所述接收模块接收的信息属于自动应答范围，则所述获取模块生成一第一请求信息并发出；

若所述判断模块判断所述接收模块接收的信息属于业务办理范围，则所述获取模块生成一第二请求信息并发出；

若所述判断模块判断所述接收模块接收的信息属于人工解答范围，则所述获取模块生成一第三请求信息并发出。

本公开的一种示例性实施例中，所述处理模块包括：

资讯提供单元，用于根据所述第一请求信息提供对应的机器应答信息作为所述响应信息；

业务办理单元，用于根据所述第二请求信息办理对应的业务，并将业务办理信息作为所述响应信息；

人工服务中心，用于呈现所述第三请求信息以及接受向所述人工服务中心输入的信息作为所述响应信息。

本公开的一种示例性实施例中，所述后台服务器还包括：

推送模块，用于接收公众号管理员的指令生成一推送信息并发送至所 述处理模块，

所述处理模块接收所述推送信息，并根据所述推送信息生成对应的响应信息发送至所述发送模块。

本公开的一种示例性实施例中，所述数据信息具有公众号源标识，仅与所述公众号源标识对应的来源公众号标识具有对相应数据信息的访问权限。

本公开的一种示例性实施例中，所述交互服务器还包括：

学习模块，与各所述数据库连接，用于根据公众号管理员的指令开放指定公众号对全部数据信息的访问权限。

本公开的一种示例性实施例中，所述交互服务器还包括：

学习模块，与各所述数据库连接，用于根据公众号管理员的指令开放指定公众号对特定目标客户的所述数据信息的访问权限。

本公开的一种示例性实施例中，所述信息交互系统还包括：

客服模块，包括优先级依次降低的多个客服系统；所述客服模块用于在所述客户寻求客服服务时，优先利用最高优先级的客服系统进行应答，其他优先级的客服系统在上一优先级的客服系统无法应答时进行应答。

本公开的一种示例性实施例中，所述NoSQL数据库中还存储有客服设置数据，用于设定增加或减少所述客服系统以及改变所述客服系统的优先级。

本公开的一种示例性实施例中，所述公众号服务平台包括微信公众号服务平台或者微博公众号服务平台。

本公开示例性实施例中的信息交互系统中，通过设置相对独立的交互服务器和后台服务器，实现交互服务和核心业务的相互分离，二者互不影响，两种服务都可以得到优化，进而可以使得企业的信息交互系统整体处理能力得到提升。同时，相互独立的分层结构也将使得公众号交互过程中的安全性得以提升。

进一步的，本公开实施方式中还可以对公众号交互相关信息进行分类存储，在增加了信息的对外安全性的同时，也有效地提升了信息读取的速度。在数据中设置了公众号源标识，规定了仅与该源标识对应的公众号才具有对该数据信息的访问权限，从而更进一步增加系统内部的信息安全性 管理。同时，根据公众号管理员的需求增加了学习模块，在保障内部信息安全基础上，又可以实现内部信息的共享与相互学习，从而可以通过大数据分析以及自动学习等技术综合利用整体信息为客户提供更好的交互服务体验。

此外，本公开实施方式中还可以通过设置新架构的客服模块，从而可以尽可能为客户提供更优选的客服系统，因此可以使得公众号的客户体验大大提升。

附图说明

通过参照附图详细描述其示例性实施例，本公开的上述和其它特征及优点将变得更加明显。

图1是现有技术中信息交互系统的架构示意图。

图2是本公开示例性实施例中一种信息交互系统的架构示意图。

图3是本公开示例性实施例中一种信息交互系统的模块示意图。

图4是本公开示例性实施例中一种信息交互系统的拓扑结构示意图。

图5是本公开示例性实施例中另一种信息交互系统的模块示意图。

图6是本公开示例性实施例中另一种信息交互系统的拓扑结构示意图。

图7是本公开示例性实施例中一种客服系统切换流程示意图。

具体实施方式

现在将参考附图更全面地描述示例性实施例。然而，示例性实施例能够以多种形式实施，且不应被理解为限于在此阐述的实施方式；相反，提供这些实施方式使得本公开将全面和完整，并将示例性实施例的构思全面地传达给本领域的技术人员。在图中，为了清晰，夸大、变形或简化了形状尺寸及连接关系。在图中相同的附图标记表示相同或类似的结构，因而将省略它们的详细描述。

此外，所描述的特征、结构或步骤可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本公开的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本公开 的技术方案而没有所述特定细节中的一个或更多，或者可以采用其它的方法、步骤、结构等。

本示例性实施例中提供了一种信息交互系统，用于通过公众号与客户进行交互。参考图2中所示，所述信息交互系统主要包括交互服务器以及后台服务器。交互服务器与后台服务器之间相互独立，分别处理各自业务。例如，交互服务器主要专注于实现交互服务，后台服务器主要专注于根据请求处理核心业务。以下将对本示例性实施例中的交互服务器与后台服务器进行更详细的说明。

交互服务器主要用于为后台服务器和公众号服务平台之间提供交互的通道，参考图3以及图4中所示，本示例性实施例中，所述交互服务器主要包括接收模块、获取模块以及发送模块。其中，接收模块主要用于自公众号服务平台接收客户向所述公众号发送的信息；获取模块主要用于根据所述接收模块接收的信息生成一请求信息并发出；发送模块主要用于接收一响应信息并通过公众号服务平台利用所述公众号将所述响应信息发送给所述客户。后台服务器可以无需处理交互服务，其主要包括处理模块，处理模块用于接收所述获取模块发出的请求信息，并根据所述请求信息生成对应的响应信息发送至所述发送模块。

以所述公众号是微信公众号，所述公众号服务平台是微信服务器为例，客户通过微信公众号办理T企业的保险业务为例：

客户首先通过手机等移动终端或其他设备获取并关注T企业办理保险业务相关的微信公众号(仅在客户第一次与业务系统服务器建立对话关系时)，T企业的交互服务器通过微信服务器建立T企业的后台服务器与客户之间的对话关系。在建立对话关系后，客户向公众号发送信息，该信息可以是客户输入的一段文字，也可能是录入的一段语音或其他类型的信息。微信服务器将客户向公众号发送的信息转发至交互服务器，交互服务器中的接收模块接收该信息，交互服务器对微信服务器转发的客户向公众号发送的信息进行分析，得知客户需要办理保险业务，则获取模块据此生成一请求办理保险业务的信息并发送给后台服务器的处理模块，处理模块根据请求办理保险业务的信息生成对应的响应信息发送至所述发送模块，响应信息可能是保险业务办理成功的信息，也可能是供客户填写办理保险 业务相关信息的电子表单，也可能是保险业务相关资讯等等；该信息的类型可能是文字、图片、语音、视频等。发送模块接收到响应信息之后，通过微信服务器利用上述公众号将所述响应信息发送给所述客户，完成一次交互。在完成办理保险业务过程中，可能需要进行多次上述的交互。

通过上述客户与保险企业微信公众号的至少一次交互，在保险企业微信公众号的数据库中即可记录该客户为目标客户，同时读取或记录下该客户的客户信息、客户交易记录以及管理员信息、多媒体文件参数等高访问权限数据信息，以及一次或多次交互过程中的客户和公众号消息、公众号参数信息、通信端口、机器应答信息、支付凭据以及服务链接等高访问频率数据信息；以及多媒体文件、业务办理资料、客户操作记录、日志文件等归档数据信息。

另外，继续参考图3中所示，在本示例实施方式中，后台服务器中还可以包括一推送模块。推送模块用于获取公众号管理员的信息推送指令生成一推送信息并发送至处理模块。处理模块接收该推送信息，并根据该推送信息生成对应的响应信息发送至交互服务器的发送模块，再由该发送模块发送给客户接收。

例如，当T企业需要向广大目标客户推出某一新型保险产品的信息时，可由微信公众号管理员发送一新产品信息推送指令至台服务器中的推送模块，推送模块接收该推送指令并生成一新产品推送信息并发送至处理模块。处理模块接收该推送信息，并根据该推送信息生成对应的响应信息发送至交互服务器的发送模块，再由该发送模块发送该新产品的推广信息至微信服务器，进而微信服务器将其转发给T企业微信公众号数据库中所有的目标客户接收。

上述信息交互系统中，交互服务器为后台服务器和公众号服务平台之间提供了交互的通道，能够相对独立的完成交互服务，因此后台服务器可以无需处理交互服务，公众号开发者可以把集中精力和资源用于开发核心业务。由于交互服务和核心业务相互分离，二者互不影响，两种服务都可以得到优化，进而可以使得企业的信息交互系统整体处理能力得到提升。同时，相互独立的分层结构也将使得公众号交互过程中的安全性得以提升。

现有技术中，客户通过公众号和企业之间交互的信息，例如客户信息、公众号信息、客户和公众号消息记录、客户操作记录、业务办理记录以及机器应答信息等均存储在同一数据库，且不区分重要等级、安全等级或使用频率等级等。数据查询调查时也通常采用轮询的方式，将所涉及客户的全部信息进行轮询调取，再根据管理员或客户对显示内容的具体需求进行选择展现。这主要是因为在同一数据库中根据安全性等不同进行访问权限等级的分别设定较为复杂且性价比不高。这就造成了现阶段由于不同信息的重要程度不一，常用程度不一，将不同信息存储在同一数据库将会出现安全性无法确保或者在设置高安全级别时读取不便等问题，影响交互效率。此外，在企业具有多个公众号时，各个公众号所对应的交互信息互相封闭，无法实现共享，这对于同一企业旗下多个公众号业务的耦合拓展非常不利。现阶段企业级数据在保证数据对外安全性的基础上，还要既有对内安全性也有共享耦合性。

继续参考图3以及图4中所示，针对上述问题，本示例性实施例中所述交互服务器还包括MySQL数据库以及NoSQL数据库。其中，MySQL数据库具有一第一安全级别，第一安全级别为相对更高的安全级别，用于存储第一类型数据信息。NoSQL数据库具有一第二安全级别，第二安全级别低于所述第一安全级别；NoSQL数据库用于存储第二类型数据信息。所述第一类型数据信息所需的访问权限较所述第二类型数据信息更高，所述第二类型数据信息被访问的频率较所述第一类型数据信息更高。例如，所述第一类型数据信息包括客户信息(例如实名信息)、客户交易记录以及管理员信息、多媒体文件参数以及备份文件等高访问权限信息。所述第二类型数据信息包括客户和公众号消息、公众号参数信息、通信端口(例如交互服务器和后台服务器之间的通信端口、交互服务器和公众号服务平台之间的通信端口)、机器应答信息(例如关键字)、支付凭据以及服务链接(例如业务办理连接)等高访问频率信息。当然，本领域技术人员也可以根据需求对交互涉及到的信息进行更多的分类，并对应提供相应类型数据库进行存储，例如，参考图5及图6中所示，交互服务器还可以包括NAS数据库，用于存储归档数据信息。归档数据信息可以包括多媒体文件(例如影音图像文件)、业务办理资料(例如客户理赔资料)、客户操作 记录(例如客户点击菜单记录)、日志文件等，即并不以本示例性实施例为限。

进一步的，本示例性实施例中，在所述公众号为多个时，所有所述公众号可以在同一交互服务器上进行，因此所有所述公众号的交互可以共用各所述数据库，从而可以使同一企业旗下所有公众号之间实现信息整体共享。而为实现对内的数据信息安全保障，可进一步将第一类型数据信息及第二类型数据信息设置为具有公众号源标识，仅有与所述公众号源对应的来源公众号才能拥有对相应数据信息的访问权限。而当企业的推送信息是面向所有目标客户时，交互服务器还包括学习模块，与MySQL数据库、NoSQL数据库以及以及NAS数据库连接，用于根据公众号管理员的指令开放所有公众号对全部第一类型数据信息及第二类型数据信息的访问权限，这样就实现了对所有目标客户信息的调取，保障了信息推送的全面性效果。

另外，当企业通过微信系统拥有了海量的目标客户信息时，根据大数据理论，利用统计学原理可以从海量的目标客户信息中搜索出适合于某一保险产品(例如保险理财产品)的特定目标客户(具有理财能力或愿望的客户)。但如该保险理财产品发送给对该保险理财产品无兴趣的目标客户则会浪费推送资源，甚至可能引起该客户厌恶心理，导致放弃对企业微信的关注。为解决这一问题，在本示例性实施例中的学习模块，可以根据公众号管理员的指令开放指定公众号对特定目标客户的所述数据信息的访问权限。也就是说，当某一目标客户并非通过保险理财公众号而进入T企业交互服务器的数据库内，通过搜索确认该目标客户具有理财能力或愿望，则可选定该目标客户为保险理财公众号的特定目标客户。学习模块可以为保险理财公众号开启该特定目标客户的第一类型数据信息及第二类型数据信息的访问权限，从而定向向其推送保险理财产品的信息。

再者，学习模块与MySQL数据库、NoSQL数据库以及以及NAS数据库连接时还可用于分析MySQL数据库、NoSQL数据库以及以及NAS数据库中的数据以改善向所述客户提供的服务，从而可以为客户提供更好的体验。举例而言，学习模块分析客户和公众号消息记录，从而不断自动优化上述机器应答信息；学习模块也可以分析客户信息、公众号参数信息、 业务办理记录、客户和公众号消息记录、客户操作记录等信息，进而可以统计客户的年龄分布、职业分布、地域分布、需求分布、服务体验等数据从而供后台服务器有针对性的为客户提供更好的交互服务等等。

相比于现有技术，本示例性实施例中一方面对公众号交互相关信息进行分类存储，在增加了安全性的同时，也有效的提升了信息读取的速度。同时，使各公众号之间实现信息的共享，从而可以通过大数据分析以及自动学习等技术综合利用整体信息为客户提供更好的交互服务体验。

继续参考图3至图6中所示，本示例性实施例中，所述交互服务器还可以包括一判断模块。判断模块用于判断所述接收模块接收的信息的类型，进而为后续处理提供便利。例如，若所述判断模块判断所述接收模块接收的信息属于自动应答范围，则所述获取模块可以生成一第一请求信息并发出；若所述判断模块判断所述接收模块接收的信息属于业务办理范围，则所述获取模块可以生成一第二请求信息并发出；若所述判断模块判断所述接收模块接收的信息属于人工解答范围，则所述获取模块可以生成一第三请求信息并发出。相对应的，所述处理模块具备处理不同请求的单元，例如，所述处理模块包括资讯提供单元、业务办理单元以及人工服务中心等。其中，资讯提供单元可以用于根据所述第一请求信息提供对应的机器应答信息作为所述响应信息；业务办理单元可以用于根据所述第二请求信息办理对应的业务，并将业务办理信息作为所述响应信息，业务办理信息可以包括办理结果或者办理业务所需电子表单等信息；人工服务中心可以用于通过屏幕向客服人员呈现所述第三请求信息以及接受客服人员向所述人工服务中心输入的信息作为所述响应信息。当然，在本公开的其他示例性实施例中，判断模块也可能判断接收模块接收的信息同时属于多种类型，此时则可能需要对应同时提供多种不同的处理方式；而且，处理模块的各单元之间也可能出现相互调用的情形等，均属本公开的保护范围。

现有技术中，企业的信息交互系统的客服系统单一，而且管理混乱，客户体验较差。继续参考图3及图5中所示，本示例性实施例中，所述信息交互系统还可以包括一客服模块，用于在客户需要向客服咨询、寻求帮助或者投诉时提供相应的文字或者语音等形式的服务。本示例性实施例 中，客服模块可以包括优先级依次降低的多个客服系统；所述客服模块用于在所述客户寻求客服服务时，优先利用最高优先级的客服系统进行应答，其他优先级的客服系统在上一优先级的客服系统无法应答时进行应答。

举例而言，客服模块可以包括优先级依次降低的UC客服、智能客服、微信客服、腾讯客服以及自定义客服。当客户求客服服务时，客服模块的工作流程如图7中所示，首先，当判断UC客服处于开启状态时，则优先通过UC客服对客户进行应答；当判断UC客服处于关闭状态时，且判断智能客服处于开启状态时，则优先通过智能客服对客户进行应答......当所有客服系统均无法应答时，则只能通过默认客服进行应答。此外，本示例性实施例中，所述NoSQL数据库中还可以存储有客服设置数据，用于增加或减少所述客服系统以及改变所述客服系统的优先级。例如，可以允许公众号管理员设置各客服系统的优先级别，也可以允许客户根据自身需要加入对应的客服。当然，在本公开的其他示例性实施例中，客户也可以根据关键字提示，主动进入任一客服系统，并不以本示例性实施例中为限。相比于现有技术，本示例性实施例中的客服模块尽可能提供更优选的客服系统，同时可以自由切换，因此可以使得公众号的客户体验大大提升。

另外，上述公众号服务平台除了微信服务器之外，还可以为微博服务平台、短信后台服务器等其它服务平台等，本实施例不对公众号服务平台的具体形式进行限定。此外，企业及所提供的服务类型不受本公开的限定，无论何种企业，都可以在得到公众号服务平台授权后，使用公众号服务平台授权的API(Application Programming Interface，应用程序编程接口)接口，根据其业务需求结合API接口进行二次开发，以实现通过公众号服务平台与客户之间的交互，此处不再一一赘述。

本公开已由上述相关实施例加以描述，然而上述实施例仅为实施本公开的范例。必需指出的是，已揭露的实施例并未限制本公开的范围。相反地，在不脱离本公开的精神和范围内所作的更动与润饰，均属本公开的专利保护范围。