CN109921932A - 一种呼叫中心的配置及应用方法、装置和系统 - Google Patents

Abstract

本发明公开了一种呼叫中心的配置及应用方法、装置和系统，属于计算机技术领域。所述方法包括：对所述呼叫中心采用的底层服务进行工厂模式配置，得到相互独立的操作接口和可配置的资源池；根据所述呼叫中心各个业务模块的业务标识以及预设配置策略，为各个所述业务模块分配所述操作接口和所述资源池；当接收到目标业务请求时，确定所述目标业务请求所属的目标业务模块，并基于所述目标业务模块分配得到的所述操作接口和所述资源池，对所述目标业务请求进行处理。采用本发明，可以提高呼叫中心的服务质量和可靠性。

Description

一种呼叫中心的配置及应用方法、装置和系统

技术领域

本发明涉及计算机技术领域，特别涉及一种呼叫中心的配置及应用方法、装置和系统。

背景技术

随着互联网的飞速发展，呼叫中心(Call Center，CC)系统已经成为一个综合信息服务系统，其可以采用统一的标准服务模式，为用户提供系统化、智能化、人性化的服务。业务服务商可以通过呼叫中心系统，处理业务咨询、业务投诉等各类服务请求。

呼叫中心系统的运行离不开第三方服务商提供的底层服务，如包含热线号码、坐席设置、队列管理的资源池服务、平台操作接口服务等。以用户拨打上述业务服务商的400热线电话发起业务咨询请求为例，对呼叫中心系统的运行流程进行说明。首先，用户可以通过任意终端拨打上述业务服务商的400热线电话，之后，为用户提供通话服务的电信运营商可以接收到该400电话，然后将其转接至相应的第三方服务商。之后，第三方服务商可以基于业务服务商购买的底层服务，识别出该400电话为上述业务服务商的热线号码，然后将该400电话转接至上述业务服务商的呼叫中心系统。最后，呼叫中心系统可以基于购买的底层服务，为上述用户的业务咨询请求分配坐席。

在实现本发明的过程中，发明人发现现有技术至少存在以下问题：

通常呼叫中心系统具有多个业务模块，每个业务模块对应一条业务线，如B2C业务线、C2B业务线，由于这些业务模块共用第三方服务商提供的底层服务，当对各业务线进行业务统计和坐席管理等操作时，需要花费较高的人工成本和时间成本才能够从共有的底层服务数据中筛选出各业务线所需要的数据。另外，现有的呼叫中心系统采用单个底层服务，一旦底层服务出现问题，将导致呼叫中心系统不可用。故而现有的呼叫中心系统服务质量较差，可靠性也较差。

发明内容

为了解决现有技术的问题，本发明实施例提供了一种呼叫中心的配置及应用方法、装置和系统。所述技术方案如下：

第一方面，提供了一种呼叫中心的配置及应用方法，所述方法包括：

对所述呼叫中心采用的底层服务进行工厂模式配置，得到相互独立的操作接口和可配置的资源池；

根据所述呼叫中心各个业务模块的业务标识以及预设配置策略，为各个所述业务模块分配所述操作接口和所述资源池；

当接收到目标业务请求时，确定所述目标业务请求所属的目标业务模块，并基于所述目标业务模块分配得到的所述操作接口和所述资源池，对所述目标业务请求进行处理。

进一步的，所述对所述呼叫中心采用的底层服务进行工厂模式配置，得到相互独立的操作接口和可配置的资源池，包括：

基于由接口类和资源池类组成的对于底层服务的接入与调用模型，对所述呼叫中心采用的底层服务进行配置，得到相互独立的操作接口和可配置的资源池。

进一步的，所述基于所述目标业务模块分配得到的所述操作接口和所述资源池，对所述目标业务请求进行处理，包括：

获取所述目标业务模块分配得到的所述资源池的资源池参数；

基于所述资源池参数和所述目标业务模块分配得到的所述操作接口，对所述目标业务请求进行处理。

进一步的，所述方法还包括：

如果所述呼叫中心采用的底层服务为多个，则建立每个所述业务模块与至少一个所述底层服务的绑定关系；

基于建立的所述业务模块与所述底层服务的绑定关系，并根据各个所述业务模块的业务标识以及预设配置策略，在各个所述底层服务中为每个所述业务模块分配所述操作接口和所述资源池。

进一步的，所述方法还包括：

预先在多个所述底层服务中确定每个所述业务模块的主底层服务和备底层服务；

当检测到目标业务模块的主底层服务不可用时，自动将所述目标业务模块的备底层服务切换为所述目标业务模块的主底层服务。

第二方面，提供了一种呼叫中心的配置及应用装置，所述装置包括：

第一配置模块，用于对所述呼叫中心采用的底层服务进行工厂模式配置，得到相互独立的操作接口和可配置的资源池；

第二配置模块，用于根据所述呼叫中心各个业务模块的业务标识以及预设配置策略，为各个所述业务模块分配所述操作接口和所述资源池；

应用模块，用于当接收到目标业务请求时，确定所述目标业务请求所属的目标业务模块，并基于所述目标业务模块分配得到的所述操作接口和所述资源池，对所述目标业务请求进行处理。

进一步的，所述第一配置模块，还用于：

基于由接口类和资源池类组成的对于底层服务的接入与调用模型，对所述呼叫中心采用的底层服务进行配置，得到相互独立的操作接口和可配置的资源池。

进一步的，所述应用模块，还用于：

获取所述目标业务模块分配得到的所述资源池的资源池参数；

基于所述资源池参数和所述目标业务模块分配得到的所述操作接口，对所述目标业务请求进行处理。

进一步的，所述第二配置模块，还用于：

如果所述呼叫中心采用的底层服务为多个，则建立每个所述业务模块与至少一个所述底层服务的绑定关系；

基于建立的所述业务模块与所述底层服务的绑定关系，并根据各个所述业务模块的业务标识以及预设配置策略，在各个所述底层服务中为每个所述业务模块分配所述操作接口和所述资源池。

进一步的，所述装置还包括切换模块，用于：

预先在多个所述底层服务中确定每个所述业务模块的主底层服务和备底层服务；

当检测到目标业务模块的主底层服务不可用时，自动将所述目标业务模块的备底层服务切换为所述目标业务模块的主底层服务。

第三方面，提供了一种呼叫中心的配置及应用系统，所述系统至少包括客户端和服务器；

所述服务器，用于：

对所述呼叫中心采用的底层服务进行工厂模式配置，得到相互独立的操作接口和可配置的资源池；

根据所述呼叫中心各个业务模块的业务标识以及预设配置策略，为各个所述业务模块分配所述操作接口和所述资源池；

所述客户端，用于：

向所述服务器发送目标业务请求；

所述服务器，还用于：

确定所述目标业务请求所属的目标业务模块，并基于所述目标业务模块分配得到的所述操作接口和所述资源池，对所述目标业务请求进行处理。

本发明实施例提供的技术方案带来的有益效果是：

在本实施例中，对所述呼叫中心采用的底层服务进行工厂模式配置，得到相互独立的操作接口和可配置的资源池；根据所述呼叫中心各个业务模块的业务标识以及预设配置策略，为各个所述业务模块分配所述操作接口和所述资源池；当接收到目标业务请求时，确定所述目标业务请求所属的目标业务模块，并基于所述目标业务模块分配得到的所述操作接口和所述资源池，对所述目标业务请求进行处理。这样，通过将底层服务中的操作接口和资源池进行分离，使得各个业务模块可以拥有独立的底层服务，不仅可以方便地进行横向扩展与维护，而且可以对有限的底层服务资源进行合理利用。同时，当各业务模块进行业务统计和坐席管理等操作时，可以直接基于所分配的底层服务进行，极大的节省了人力成本和时间成本。另外，通过引入多个第三方服务商的底层服务，各业务模块可以很方便的在底层服务之间进行切换，有效地解决了呼叫中心系统采用单底层服务的单点问题，提高了呼叫中心系统的可靠性，还可以扩大坐席同时在线人数，解决单个底层服务存在的同时在线坐席的人数瓶颈问题。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。

图1是本发明实施例提供的一种呼叫中心的配置及应用方法流程图；

图2是本发明实施例提供的一种呼叫中心的系统框架图；

图3是本发明实施例提供的一种呼叫中心的配置及应用装置结构示意图；

图4是本发明实施例提供的一种呼叫中心的配置及应用装置结构示意图；

图5是本发明实施例提供的一种服务器的结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。

本发明实施例提供了一种呼叫中心的配置及应用方法，该方法的执行主体可以是运行有呼叫中心系统的任意一台服务器，或由多台服务器组成的服务集群，其可以对呼叫中心系统的各个业务模块配置相应的底层服务资源，并可以对接收到的各类服务请求进行处理。上述服务器可以包括处理器、存储器、收发器，处理器可以用于进行下述流程中对于呼叫中心的配置及应用处理，存储器可以用于存储处理过程中需要的数据以及产生的数据，收发器可以用于接收和发送处理过程中的相关数据。

下面将结合具体实施方式，对图1所示的一种呼叫中心的配置及应用方法的处理流程进行详细的说明，内容可以如下：

步骤101，对呼叫中心采用的底层服务进行工厂模式配置，得到相互独立的操作接口和可配置的资源池。

在实施中，上述呼叫中心系统可以是传统的通过电话来接听服务对象来电的系统，也可以是现代的由计算机电话、数据仓库、客户关系管理等技术搭建的多功能工作平台。呼叫中心系统可以接听服务对象来电，为服务对象提供一系列的服务与支持，如IT行业中的技术支持中心，保险行业中的电话理赔中心等。现有的呼叫中心采用的底层服务由第三方服务商提供，运行有呼叫中心系统的服务器可以通过配置文件的方式，对呼叫中心的各个业务模块所需的底层服务进行配置。第三方服务商提供的底层服务主要包括两种，一种是资源池，包括热线号码、企业编码、坐席设置、坐席分组等；一种是操作接口，如外呼接口，呼入接口等。资源池可以由第三方服务商基于业务服务商的需求进行配置，如1000人的坐席规模或10000人的坐席规模。呼叫中心可以通过配置文件对各个业务模块所需的底层服务进行配置。由于资源池和操作接口紧密耦合，当进行配置时，需要技术人员从代码层面对配置文件进行修改，难度较大，维护性差。在本发明中，服务器可以通过工厂模式对呼叫中心采用的底层服务进行配置，将资源池和操作接口进行分离，得到相互独立的操作接口和可配置的资源池。需要说明的是，工厂模式是设计模式的一种，其可以通过定义标准化的工厂类进行扩展，能够屏蔽不同第三方服务商的操作类初始化过程，具有较高的可维护性。

可选的，步骤101的具体处理可以如下：基于由接口类和资源池类组成的对于底层服务的接入与调用模型，对呼叫中心采用的底层服务进行配置，得到相互独立的操作接口和可配置的资源池。

在实施中，可以对当前的各个第三方服务商提供的底层服务进行工厂模式设计，建立由接口类和资源池类组成的对于底层服务的接入与调用模型，可以看出，底层服务中的操作接口服务和资源池服务将作为接入与调用模型中的两个标准化的工厂类，从而可以将耦合在一起的操作接口与资源池进行分类，使得操作接口不再包含具体的资源池属性。这样，上述服务器可以基于预先建立的接入与调用模型，对呼叫中心采用的底层服务进行模型匹配，即应用上述接口类和资源池类对底层服务进行类处理，以得到相互独立的操作接口和可配置的资源池。

步骤102，根据呼叫中心各个业务模块的业务标识以及预设配置策略，为各个业务模块分配操作接口和资源池。

在实施中，服务器在得到相互独立的操作接口和可配置的资源池后，可以获取到预先为每个业务模块配置的业务标识，之后，服务器可以基于技术人员预先配置好的预设配置策略，为各个业务模块分配操作接口和资源池。具体的，可以基于各个业务模块的业务规模，为其分配相应规模的坐席、热线号码以及操作接口。这样，各个业务模块可以拥有独立的底层服务，当各业务模块进行业务统计和坐席管理等操作时，可以直接基于所分配的底层服务进行，极大的节省了人力成本和时间成本，且可以较方便的进行维护。

步骤103，当接收到目标业务请求时，确定目标业务请求所属的目标业务模块，并基于目标业务模块分配得到的操作接口和资源池，对目标业务请求进行处理。

在实施中，当服务器接收到目标业务请求时，可以基于目标业务请求的业务类型，确定出目标业务请求所属的目标业务模块，并可以将该目标业务请求分配给目标业务模块处理。之后，目标业务模块可以基于分配得到的操作接口和资源池，对目标业务请求进行处理。

可选的，上述步骤103的部分处理，具体可以如下：获取目标业务模块分配得到的资源池的资源池参数；基于资源池参数和目标业务模块分配得到的操作接口，对目标业务请求进行处理。

在实施中，服务器可以在数据库中记录各个业务模块所分配到的资源池的资源池参数，并且，当各个业务模块所分配的资源池发生变更时，服务器可以及时对数据库中记录的各个业务模块所分配到的资源池的资源池参数进行更新。这样，在确定目标业务请求所属的目标业务模块后，服务器可以从数据库中获取目标业务模块分配得到的资源池的资源池参数，然后可以基于资源池参数和目标业务模块分配得到的操作接口，对目标业务请求进行处理。

可选的，对于采用多个底层服务的呼叫中心，可以进行如下配置：如果呼叫中心采用的底层服务为多个，则建立每个业务模块与至少一个底层服务的绑定关系；基于建立的业务模块与底层服务的绑定关系，并根据各个业务模块的业务标识以及预设配置策略，在各个底层服务中为每个业务模块分配独立的操作接口和资源池。

在实施中，呼叫中心可以采用多个底层服务，这些底层服务可以来自不同的第三方服务商，也可以来自同一第三方服务商的采用不同标准的底层服务，如天润的cticloud服务、clink服务。对多个底层服务，均可以基于上述接入与调用模型，对这些底层服务分别进行模型匹配，得到各个底层服务下的相互独立的操作接口和可配置的资源池。之后，上述服务器可以为呼叫中心系统的每个业务模块配置一个或多个底层服务，即建立业务模块与至少一个底层服务的绑定关系。以B2C业务模块为例，上述服务器可以为B2C业务模块配置一个底层服务，如天润的cticloud服务，也可以为B2C业务模块配置多个底层服务，如天润的cticloud服务、clink服务等。接着，服务器可以基于建立的业务模块与底层服务的绑定关系，以及各个业务模块的业务标识和预设配置策略，为业务模块分配与其绑定的底层服务的独立的操作接口和资源池。这样，通过引入多个底层服务，各业务模块可以很方便的在底层服务之间进行切换，有效地解决了呼叫中心系统采用单底层服务的单点问题，提高了呼叫中心系统的可靠性。另外，还可以扩大坐席同时在线人数，解决单个底层服务存在的同时在线坐席的人数瓶颈问题。

可选的，在呼叫中心系统采用多底层服务的情况下，还可以进行如下配置：预先在多个底层服务中确定每个业务模块的主底层服务和备底层服务；当检测到目标业务模块的主底层服务不可用时，自动将目标业务模块的备底层服务切换为目标业务模块的主底层服务。

在实施中，可以采用主底层服务和备底层服务结合的方式，提高呼叫中心的可靠性，其中，主底层服务是指业务模块默认使用的底层服务，备底层服务是指当主底层服务发生故障时，业务模块所使用的底层服务。具体的，服务器可以采用随机确定的方式，或者基于外界输入的确定指令，预先在多个底层服务中确定每个业务模块的主底层服务和备底层服务。这样，一旦检测到某个业务模块(可称为目标业务模块)的主底层服务不可用时，服务器可以自动将目标业务模块的备底层服务切换为目标业务模块的主底层服务，进一步提高了呼叫中心系统的可靠性。

下面给出了一种呼叫中心系统的框架，如图2所示，该框架可以包括接入层、应用层、平台层和数据层。在本框架中，一方面，将底层服务的资源池和业务模块重构为业务平台，既可以保证各业务模块的业务资源独立，又可以将资源池的维护功能集中在业务平台的信息管理功能，这样，当进行后期维护时，可以不用修改代码，只需更改配置即可，简化了维护难度。另一方面，将剥离出资源池的底层服务重构为基础平台，其不再包含具体的资源池属性，同时，基础平台可以接收业务平台下发的资源池参数，以提供相应的操作接口服务。

具体的，在呼叫中心系统的登录入口处，可以选择单平台模式和多平台模式。单平台模式是指，预先指定一个基础平台(底层服务)，当用户登录呼叫中心系统时，只能够通过指定的基础平台开展服务；多平台模式是指，用户在登录呼叫中心系统时，可以自由选择开展服务的基础平台。应用层是呼叫中心系统进行各项功能的基础，如呼入弹屏、外呼操作、坐席管理等。平台层包括上述的业务平台和基础平台，其数据量可以为多个。每个用户可以在每个业务平台创建一个坐席身份，并建立业务平台和用户的绑定关系，绑定关系由用户标识和业务平台标识以及用户在该业务平台上创建的坐席的标识共同组成，每个业务平台上对同一个用户只可以绑定一次。在多平台模式下，用户作为坐席使用呼叫中心系统时，需要选择待操作的业务平台，然后呼叫中心系统可以判断当前用户是否和选择的业务平台存在绑定关系，如果存在绑定关系，则可以自动获取当前用户绑定的业务平台的资源池信息，并写入到用户对话(session)中，当用户操作应用层功能时，系统可以将该用户的资源池参数(如具体热线号码，企业标识等)，传递给基础平台的相关操作接口，从而调用基础平台的相关服务。数据层是整个呼叫中心系统的数据保存部分，由各个数据库组成。

在本实施例中，对所述呼叫中心采用的底层服务进行工厂模式配置，得到相互独立的操作接口和可配置的资源池；根据所述呼叫中心各个业务模块的业务标识以及预设配置策略，为各个所述业务模块分配所述操作接口和所述资源池；当接收到目标业务请求时，确定所述目标业务请求所属的目标业务模块，并基于所述目标业务模块分配得到的所述操作接口和所述资源池，对所述目标业务请求进行处理。这样，通过将底层服务中的操作接口和资源池进行分离，使得各个业务模块可以拥有独立的底层服务，不仅可以方便地进行横向扩展与维护，而且可以对有限的底层服务资源进行合理利用。同时，当各业务模块进行业务统计和坐席管理等操作时，可以直接基于所分配的底层服务进行，极大的节省了人力成本和时间成本。另外，通过引入多个第三方服务商的底层服务，各业务模块可以很方便的在底层服务之间进行切换，有效地解决了呼叫中心系统采用单底层服务的单点问题，提高了呼叫中心系统的可靠性，还可以扩大坐席同时在线人数，解决单个底层服务存在的同时在线坐席的人数瓶颈问题。

基于相同的技术构思，本发明实施例还提供了一种呼叫中心的配置及应用装置，如图3所示，所述装置包括：

第一配置模块301，用于对所述呼叫中心采用的底层服务进行工厂模式配置，得到相互独立的操作接口和可配置的资源池；

第二配置模块302，用于根据所述呼叫中心各个业务模块的业务标识以及预设配置策略，为各个所述业务模块分配所述操作接口和所述资源池；

应用模块303，用于当接收到目标业务请求时，确定所述目标业务请求所属的目标业务模块，并基于所述目标业务模块分配得到的所述操作接口和所述资源池，对所述目标业务请求进行处理。

可选的，所述第一配置模块301，还用于：

基于由接口类和资源池类组成的对于底层服务的接入与调用模型，对所述呼叫中心采用的底层服务进行配置，得到相互独立的操作接口和可配置的资源池。

可选的，所述应用模块303，还用于：

获取所述目标业务模块分配得到的所述资源池的资源池参数；

基于所述资源池参数和所述目标业务模块分配得到的所述操作接口，对所述目标业务请求进行处理。

可选的，所述第二配置模块302，还用于：

如果所述呼叫中心采用的底层服务为多个，则建立每个所述业务模块与至少一个所述底层服务的绑定关系；

基于建立的所述业务模块与所述底层服务的绑定关系，并根据各个所述业务模块的业务标识以及预设配置策略，在各个所述底层服务中为每个所述业务模块分配所述操作接口和所述资源池。

可选的，如图4所示，所述装置还包括切换模块304，用于：

预先在多个所述底层服务中确定每个所述业务模块的主底层服务和备底层服务；

当检测到目标业务模块的主底层服务不可用时，自动将所述目标业务模块的备底层服务切换为所述目标业务模块的主底层服务。

需要说明的是：上述实施例提供的呼叫中心的配置及应用处理装置在进行配置及应用处理时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的呼叫中心的配置及应用处理装置与呼叫中心的配置及应用处理方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

第三方面，提供了一种呼叫中心的配置及应用系统，所述系统至少包括客户端和服务器；

所述服务器，用于：

对所述呼叫中心采用的底层服务进行工厂模式配置，得到相互独立的操作接口和可配置的资源池；

根据所述呼叫中心各个业务模块的业务标识以及预设配置策略，为各个所述业务模块分配所述操作接口和所述资源池；

所述客户端，用于：

向所述服务器发送目标业务请求；

所述服务器，还用于：

确定所述目标业务请求所属的目标业务模块，并基于所述目标业务模块分配得到的所述操作接口和所述资源池，对所述目标业务请求进行处理。

在实施中，上述客户端可以是呼叫中心系统的服务对象所使用的任意终端设备，如智能手机、笔记本电脑等。上述服务对象可以通过上述客户端进行咨询或投诉等业务请求，相应的，上述客户端发出的业务请求将通过第三方服务商的底层服务到达上述服务器。之后，上述服务器可以按照上述呼叫中心的配置及应用的处理方法实施例中的处理逻辑，进行后续处理，这里不再赘述。

图5是本发明实施例提供的服务器的结构示意图。该服务器500可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器522(例如，一个或一个以上处理器)和存储器532，一个或一个以上存储应用程序542或数据544的存储介质530(例如一个或一个以上海量存储设备)。其中，存储器532和存储介质530可以是短暂存储或持久存储。存储在存储介质530的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器522可以设置为与存储介质530通信，在服务器500上执行存储介质530中的一系列指令操作。

服务器500还可以包括一个或一个以上电源526，一个或一个以上有线或无线网络接口550，一个或一个以上输入输出接口558，一个或一个以上键盘556，和/或，一个或一个以上操作系统541，例如Windows Server TM，Mac OS XTM，Unix TM，Linux TM，FreeBSD TM等等。

服务器500可以包括有存储器，以及一个或者一个以上的程序，其中一个或者一个以上程序存储于存储器中，且经配置以由一个或者一个以上处理器执行所述一个或者一个以上程序包含用于进行上述呼叫中心的配置及应用处理指令。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (11)

1.一种呼叫中心的配置及应用方法，其特征在于，所述方法包括：

对所述呼叫中心采用的底层服务进行工厂模式配置，得到相互独立的操作接口和可配置的资源池；

根据所述呼叫中心各个业务模块的业务标识以及预设配置策略，为各个所述业务模块分配所述操作接口和所述资源池；

当接收到目标业务请求时，确定所述目标业务请求所属的目标业务模块，并基于所述目标业务模块分配得到的所述操作接口和所述资源池，对所述目标业务请求进行处理。

2.根据权利要求1所述的方法，其特征在于，所述对所述呼叫中心采用的底层服务进行工厂模式配置，得到相互独立的操作接口和可配置的资源池，包括：

基于由接口类和资源池类组成的对于底层服务的接入与调用模型，对所述呼叫中心采用的底层服务进行配置，得到相互独立的操作接口和可配置的资源池。

3.根据权利要求1所述的方法，其特征在于，所述基于所述目标业务模块分配得到的所述操作接口和所述资源池，对所述目标业务请求进行处理，包括：

获取所述目标业务模块分配得到的所述资源池的资源池参数；

基于所述资源池参数和所述目标业务模块分配得到的所述操作接口，对所述目标业务请求进行处理。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括：

如果所述呼叫中心采用的底层服务为多个，则建立每个所述业务模块与至少一个所述底层服务的绑定关系；

基于建立的所述业务模块与所述底层服务的绑定关系，并根据各个所述业务模块的业务标识以及预设配置策略，在各个所述底层服务中为每个所述业务模块分配所述操作接口和所述资源池。

5.根据权利要求4所述的方法，其特征在于，所述方法还包括：

预先在多个所述底层服务中确定每个所述业务模块的主底层服务和备底层服务；

当检测到目标业务模块的主底层服务不可用时，自动将所述目标业务模块的备底层服务切换为所述目标业务模块的主底层服务。

6.一种呼叫中心的配置及应用装置，其特征在于，所述装置包括：

第一配置模块，用于对所述呼叫中心采用的底层服务进行工厂模式配置，得到相互独立的操作接口和可配置的资源池；

第二配置模块，用于根据所述呼叫中心各个业务模块的业务标识以及预设配置策略，为各个所述业务模块分配所述操作接口和所述资源池；

应用模块，用于当接收到目标业务请求时，确定所述目标业务请求所属的目标业务模块，并基于所述目标业务模块分配得到的所述操作接口和所述资源池，对所述目标业务请求进行处理。

7.根据权利要求6所述的装置，其特征在于，所述第一配置模块，还用于：

基于由接口类和资源池类组成的对于底层服务的接入与调用模型，对所述呼叫中心采用的底层服务进行配置，得到相互独立的操作接口和可配置的资源池。

8.根据权利要求6所述的装置，其特征在于，所述应用模块，还用于：

获取所述目标业务模块分配得到的所述资源池的资源池参数；

基于所述资源池参数和所述目标业务模块分配得到的所述操作接口，对所述目标业务请求进行处理。

9.根据权利要求6所述的装置，其特征在于，所述第二配置模块，还用于：

如果所述呼叫中心采用的底层服务为多个，则建立每个所述业务模块与至少一个所述底层服务的绑定关系；

基于建立的所述业务模块与所述底层服务的绑定关系，并根据各个所述业务模块的业务标识以及预设配置策略，在各个所述底层服务中为每个所述业务模块分配所述操作接口和所述资源池。

10.根据权利要求9所述的装置，其特征在于，所述装置还包括切换模块，用于：

预先在多个所述底层服务中确定每个所述业务模块的主底层服务和备底层服务；

当检测到目标业务模块的主底层服务不可用时，自动将所述目标业务模块的备底层服务切换为所述目标业务模块的主底层服务。

11.一种呼叫中心的配置及应用系统，其特征在于，所述系统至少包括客户端和服务器；

所述服务器，用于：

对所述呼叫中心采用的底层服务进行工厂模式配置，得到相互独立的操作接口和可配置的资源池；

根据所述呼叫中心各个业务模块的业务标识以及预设配置策略，为各个所述业务模块分配所述操作接口和所述资源池；

所述客户端，用于：

向所述服务器发送目标业务请求；

所述服务器，还用于：

确定所述目标业务请求所属的目标业务模块，并基于所述目标业务模块分配得到的所述操作接口和所述资源池，对所述目标业务请求进行处理。