CN103516758A

CN103516758A - Method and device for processing service requests of resource route and call center seats

Info

Publication number: CN103516758A
Application number: CN201210218515.XA
Authority: CN
Inventors: 李会
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2012-06-28
Filing date: 2012-06-28
Publication date: 2014-01-15

Abstract

The invention provides a method and device for processing service requests of resource route and call center seats. The method includes the steps that after a resource call request is received, request information is sent to one or more resource modules, wherein the request information is used for requesting to call resources; response information fed back by the one or the more source modules according to the request information is received; according to the received response information of the one or the more resource modules, the resources to be called by the resource call request are determined, the problem of how to efficiently achieve source route management based on a cloud computing application scene in the prior art is solved, and therefore the distributed resource routing can be conducted on the source request efficiently and accurately aiming at the resource request.

Description

Service request processing method and device for resource routing and call center seat

Technical Field

The invention relates to the field of communication, in particular to a method and a device for processing service requests of a resource route and a call center seat.

Background

The Call center refers to an operation site that can automatically and flexibly handle a large number of different telephone incoming and outgoing services and services by making full use of modern communication and computer technologies, such as Interactive Voice Response (IVR), (i.e., Interactive voice 800 Call center flowchart response system), Automatic Call distribution ACD (ACD for short) (i.e., Automatic Call distribution system), and so on. Call centers are increasingly being considered telemarketing centers in current enterprise applications.

The call center mainly comprises the following functional modules:

computer Telephony Integration (CTI for short) call processing subsystem, which is used for realizing screen pop-up and synchronous transfer, and displaying the information of the client on the screen of the operator; call tracing management; computer-based telephony smart routing; a personalized greeting; incoming and outgoing call management; the 'soft phone' function of the seat terminal; and an online recording function in the call process. By the time, the CTI technology has been developed into a computer Telecommunication Integration (computer Telecommunication Integration), i.e. a technology in which "T" has been developed into "Telecommunication", which means that the current CTI technology not only processes the traditional telephone voice, but also processes other forms of information media including fax, e-mail, etc.

The interactive voice response subsystem IVR is interactive voice response, through the system, a user can enter the service center only by using a telephone, listen to the mobile phone entertainment product according to the operation prompt, and play related information according to the content input by the user.

The automatic call distribution ACD, also called automatic queuing machine, is responsible for the balanced distribution of customer calls, and the system can track the seat state in real time and generate an effective seat queue according to the state, and inserts the call into the most appropriate seat queue according to a queuing algorithm. The system can change the incoming call processing method at any time according to actual needs.

With the rise of cloud computing technology, the development of call centers based on the cloud computing technology is a trend. The cloud of the call center is divided into three levels according to the hierarchy of cloud computing, which are respectively as follows: infrastructure-level services (IaaS), platform-level services (PaaS), and software-level services (SaaS). In combination with the call center technology, in the cloud-based call center architecture, various functional modules of the cloud call center are distributed in different resource modules, the capabilities of various platforms are dynamically changed at any time, and resources in a resource pool are dynamically increased or decreased. When a call session or other tasks (for example, a task of processing internet information) of a user enters a call center platform, how to allocate a most suitable resource module to be used in the call, session and task exists, that is, how to perform optimal routing management on the relevant call, session and task in a cloud call center.

Therefore, in the prior art, there is a problem how to efficiently implement resource route management in a cloud-based computing application scenario.

Disclosure of Invention

The invention provides a resource routing and call center agent service request processing method and device, which are used for at least solving the problem of how to efficiently realize resource routing management in a cloud computing application scene in the prior art.

According to an aspect of the present invention, a resource routing processing method is provided, including: after receiving a resource calling request, sending request information to one or more resource modules, wherein the request information is used for requesting to call resources; receiving response information fed back by the one or more resource modules according to the request information; and determining the resources to be called by the resource calling request according to the received response information of the one or more resource modules.

Preferably, the request information is transmitted to the one or more resource modules in a broadcast manner.

Preferably, determining the resource to be called by the resource calling request according to the received response information of the one or more resource modules includes: acquiring resource information of the one or more resource modules, wherein the one or more resource modules lock available resources existing in the one or more resource modules; determining an available resource module from the resource modules having available resources; and determining the available resources in the callable resource module as the resources to be called by the call request.

Preferably, after determining the resource to be called by the resource calling request, the method further includes: and sending information to other resource modules except the determined resource module which can call the resource, wherein the information is used for indicating the other resource modules to release the locked resource.

Preferably, after receiving response information fed back by the one or more resource modules according to the request information, the method further includes: and when the response message indicates that no resources are available, the resource calling request is arranged in a request waiting queue. When judging that no available resource exists in the one or more resource modules, arranging the resource calling request in a request waiting queue; when available resources appear in the one or more resource modules, determining the appearing available resources as resources to be called by the resource calling request.

Preferably, the response information includes at least one of: the load information of the resource module, the address of the resource module, the identifier of the resource module, the port of the resource module, the address of the resource corresponding to the resource module, and the identifier of the resource corresponding to the resource module.

Preferably, the resource is an agent in a call center.

Preferably, the resource invocation request includes at least one of: the call center comprises a resource calling request of a call center seat, a resource calling request of a call center user, a resource calling request of an internet information gateway, a resource calling request of a call session task management module, a resource calling request of an automatic service module, a resource calling request of a manual service module and a resource calling request of a manual service module steering by the automatic service module.

Preferably, sending the request information to one or more resource modules in the cloud computing-based contact center comprises: after receiving the resource calling request from a call session task management module of the call center, sending the request information to one or more automatic service function modules in the call center; or after receiving a resource calling request of the automatic service function module for requesting a manual service function module, sending the request information to one or more manual service function modules in the call center.

According to another aspect of the present invention, a method for processing a service request of a call center agent is provided, which includes: sending a service request to a call center, wherein the service request is used for requesting to call resources, and the resources are call center seats; and receiving resource module information of the resources which can be called and returned by the call center, wherein the call center sends request information of calling the resources to one or more resource modules in the call center according to the service request, and determines the resource module information of the resources which can be called and requested by the service request according to response messages fed back by the one or more resource modules.

Preferably, after receiving the resource module information of the callable resource returned by the call center, the method further includes: and calling the callable resources according to the resource module information of the callable resources.

Preferably, the one or more resource modules are human-industry service modules, and the resource module information is address and/or identification information of the human-industry service modules.

According to still another aspect of the present invention, there is provided a resource route processing apparatus, including: the system comprises a first sending module, a second sending module and a resource module, wherein the first sending module is used for sending request information to one or more resource modules after receiving a resource calling request, and the request information is used for requesting to call resources; a first receiving module, configured to receive response information fed back by the one or more resource modules according to the request information; and the first determining module is used for determining the resources to be called by the resource calling request according to the received response information of the one or more resource modules.

Preferably, the first determining module comprises: a first obtaining module, configured to obtain resource information of the one or more resource modules, where the one or more resource modules lock available resources that exist in the one or more resource modules; a first determining unit, configured to determine an available resource module from among resource modules in which an available resource exists; a second determining unit, configured to determine that an available resource in the callable resource module is a resource to be called by the call request.

Preferably, the method further comprises the following steps: and a second sending module, configured to send information to other resource modules except the determined resource module that can invoke the resource after determining the resource to be invoked by the resource invocation request, where the information is used to instruct the other resource modules to release the locked resource.

Preferably, the method further comprises the following steps: and the first arranging module is used for arranging the resource calling request in a request waiting queue when the response message indicates that no available resource exists.

Preferably, the first transmitting module includes: the first sending unit is used for sending the request information to one or more automatic service function modules in the call center after receiving the resource calling request from the call session task management module of the call center; or, after receiving a resource call request of the automatic service function module requesting a manual service function module, the second sending unit is configured to send the request information to one or more manual service function modules in the call center.

According to another aspect of the present invention, there is provided a service request processing apparatus for a call center agent, including: the third sending module is used for sending a service request to the call center, wherein the service request is used for requesting to call resources, and the resources are call center seats; and the second receiving module is used for receiving resource module information of the callable resources returned by the call center, wherein the call center sends request information for calling the resources to one or more resource modules in the call center according to the service request, and determines the resource module information of the callable resources of the service request according to response messages fed back by the one or more resource modules.

Preferably, the method further comprises the following steps: and the first calling module is used for calling the callable resources according to the resource module information of the callable resources after receiving the resource module information of the callable resources returned by the call center.

According to the invention, after a resource calling request is received, request information is sent to one or more resource modules, wherein the request information is used for requesting to call resources; receiving response information fed back by the one or more resource modules according to the request information; according to the received response information of the one or more resource modules, the resources to be called by the resource calling request are determined, the problem of how to efficiently realize resource routing management in a cloud computing-based application scene in the prior art is solved, and the effect of efficiently and accurately performing distributed resource routing on the resource request is achieved.

Drawings

The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the invention and together with the description serve to explain the invention without limiting the invention. In the drawings:

FIG. 1 is a flow diagram of a resource routing processing method according to an embodiment of the present invention;

FIG. 2 is a flow chart of a method for processing a service request of a call center agent according to an embodiment of the invention;

fig. 3 is a block diagram of a resource route processing apparatus according to an embodiment of the present invention;

fig. 4 is a block diagram of a preferred structure of the first determination module 36 in the resource route processing apparatus according to the embodiment of the present invention;

fig. 5 is a block diagram of a resource route processing apparatus according to a preferred embodiment of the present invention;

fig. 6 is a block diagram of a resource route processing apparatus according to a preferred embodiment of the present invention;

fig. 7 is a block diagram of a preferred structure of the first sending module 32 in the resource route processing apparatus according to the embodiment of the present invention;

fig. 8 is a block diagram of a service request processing device of a call center agent according to an embodiment of the present invention;

fig. 9 is a block diagram of a service request processing device of a call center agent according to a preferred embodiment of the present invention;

FIG. 10 is a schematic structural diagram of distributed routing according to an embodiment of the present invention;

FIG. 11 is a flow diagram of a distributed route processing method according to an embodiment of the present invention;

fig. 12 is a flowchart of a distributed routing processing method for an agent according to an embodiment of the present invention.

Detailed Description

The invention will be described in detail hereinafter with reference to the accompanying drawings in conjunction with embodiments. It should be noted that the embodiments and features of the embodiments in the present application may be combined with each other without conflict.

In this embodiment, a resource routing processing method is provided, and fig. 1 is a flowchart of a resource routing processing method according to an embodiment of the present invention, as shown in fig. 1, the flowchart includes the following steps:

step S102, after receiving a resource calling request, sending request information to one or more resource modules, wherein the request information is used for requesting to call a resource, and preferably, the request information can be sent to the one or more resource modules in a broadcast manner;

step S104, receiving response information fed back by the one or more resource modules according to the request information, for example, the response information may be at least one of the following: the load information of the resource module, the address of the resource module, the identifier of the resource module, the port of the resource module, the address of the resource corresponding to the resource module, and the identifier of the resource corresponding to the resource module;

and step S106, determining the resources to be called by the resource calling request according to the received response information of the one or more resource modules.

Through the steps, after the request information is sent to each resource module in the resource pool, the current resource information of each resource module is determined according to the feedback response information, compared with the prior art that the resources are distributed through the previously stored resource information of each resource module and according to a fixed sequencing mode, the method can rapidly acquire the resource module information corresponding to the called resources, and the called resource module information is timely, so that the problem of how to efficiently realize the resource routing management in the application scene based on cloud computing in the prior art is solved, and the effect of efficiently and rapidly performing distributed resource routing for the resource request is further achieved.

In order to call resource modules with available resources more quickly and prevent conflict with other resource calling requests, resource information of one or more resource modules can be acquired firstly, wherein the one or more resource modules lock the available resources, and an available resource module is determined from the resource modules with available resources; determining available resources in the resource modules to be called as resources to be called by the calling request, and selecting one resource from the locked available resources of each resource module according to a preset strategy; and determining the selected resource as the resource to be called by the resource calling request. By adopting the processing mode, the resources which can be called can be accurately and quickly acquired. In addition, in order to enable each resource to be better served by other services, after an available resource module is determined from the resource modules having available resources, that is, after a resource is selected from the locked available resources of each resource module according to a predetermined policy, the lock on the available resource which is not selected from the resource modules is released. For example, indication information may be sent to other resource modules except the determined resource modules that can be called among the resource modules having available resources, wherein the indication information is used to instruct the other resource modules to release the locks on the available resources in the other resource modules, and thus, the released available resources may be used by the other requesters that issued the resource call requests.

On the other hand, if there is no available resource in each resource module in the received response message fed back by each resource module, the resource invocation request may be arranged in a request waiting queue, it needs to be noted that the queue type is a type corresponding to the resource, and if there are multiple types of resource modules in the resource pool, there are multiple request queue types of corresponding types; when the resource module has available resources (i.e. in the case of available resources), it is determined that the available resources are the resources to be called by the resource calling request.

The above-mentioned embodiments are not intended to limit the scenes specifically, and the methods used in the above-mentioned embodiments and preferred embodiments can be used in any scenes in which a cloud-based computing resource pool is used, and the following description will be given taking a cloud-based computing call center as an example.

In the case that the cloud computing resource pool is a cloud computing-based call center resource pool, resources in one or more resource modules are agents. In addition, the resource invocation request of the cloud computing-based call center may include at least one of: the call center comprises a resource calling request of a call center seat, a resource calling request of a call center user, a resource calling request of an internet information gateway, a resource calling request of a call session task management module, a resource calling request of an automatic service module, a resource calling request of a manual service module and a resource calling request of a manual service module steering by the automatic service module.

In addition, in the process of sending request information to one or more resource modules in the cloud computing-based call center, the sent request may be in various forms, and in one case, in the case that the resource calling request is a resource calling request of the cloud computing-based call center, the request information may be sent to one or more automatic service function modules in the cloud computing-based call center after receiving a resource calling request from a call session task management module of the call center (or called cloud computing-based call center); in another case, in a case where the resource invocation request is a resource invocation request of the cloud-based call center from an automatic function service to a manual service, the request information may be sent to one or more manual service function modules in the cloud-based call center after receiving a resource invocation request of the automatic service function module requesting the call session task management module to provide a manual service by the manual service function module.

Of course, based on the processing performed in the cloud call center, the method adopted by the above embodiment and preferred embodiment not limited to the scenario may also be adopted, for example, each resource module may lock its available resource, and when all resource modules cannot provide available resources, place the request in a queue to wait; when the manual service module receives a request for allocating the seat, an available seat is selected and locked, and then the seat information is returned; when the manual service module receives a request for releasing an agent, the previously selected agent is released. When no available agents are available on all the manual service module resources, the request message is queued at the resource scheduling module, or one manual service module is selected and then the request message is queued at the manual service module.

Fig. 2 is a flowchart of a method for processing a service request of a call center agent according to an embodiment of the present invention, and as shown in fig. 2, the flowchart includes the following steps:

step S202, a service request is sent to a call center, wherein the service request is used for requesting to call a resource, the resource is a call center seat, for example, the service request can be a login request;

step S204, receiving resource module information of the callable resource returned by the call center, wherein the call center sends request information of the callable resource to one or more resource modules in the call center according to the service request, and determines resource module information of the callable resource requested by the service according to response messages fed back by the one or more resource modules.

Through the steps, when the client sends the service request to the cloud computing-based call center, the cloud computing-based call center processes and determines the resources to be called by the service request based on the embodiment and the preferred embodiment, and compared with the prior art that the resources are allocated according to the resource information of each resource module stored before and the fixed sequencing mode, the method can rapidly acquire the resource module information corresponding to the called resources of the cloud computing-based call center, and the called resource module information is timely, so that the problem that how to efficiently realize the resource routing management in the cloud computing-based application scene in the prior art is solved, the distributed resource routing can be efficiently and rapidly performed aiming at the resource request, and the effect of improving the user experience is achieved.

Preferably, after receiving the resource module information of the callable resource returned by the cloud-based computing call center, the method further includes: and calling the callable resources according to the resource module information of the callable resources, wherein the one or more resource modules are human-industry service modules, and the resource module information is the address and/or identification information of the human-industry service modules.

According to the difference of the resource calling requests, the request information sent to each resource module in the cloud-based computing call center may also be different, for example, in the case that the resource calling request is a resource calling request of the call center function service, after receiving the resource calling request from the call session task management module CSTMF of the call center, the request information is sent to each automatic service function module ASF in the cloud-based computing call center; that is, when a request from a call center subscriber or a request from another module enters the CSTMF of the call center, the CSTMF first initiates a routing request for the ASF and then transmits request information to each ASF in the call center;

for another example, in a case where the resource invocation request is a resource invocation request for the call center to be switched from an automatic function service to a manual service, after receiving the resource invocation request for requesting the CSTMF to provide a manual service by a manual service function module MSF from the ASF, the request information is sent to each MSF in the call center based on the cloud computing. That is, when a requester such as a subscriber needs to change to a manual service based on service selection of the ASF resource module, the ASF requests the cstf to provide manual service to the MSF, and then the cstf initiates a resource routing request for the MSF.

In this embodiment, a resource routing processing apparatus is further provided, and the apparatus is used to implement the foregoing embodiments and preferred embodiments, and details of which have been already described are omitted. As used below, the term "module" may be a combination of software and/or hardware that implements a predetermined function. Although the means described in the embodiments below are preferably implemented in software, an implementation in hardware, or a combination of software and hardware is also possible and contemplated.

Fig. 3 is a block diagram of a resource route processing apparatus according to an embodiment of the present invention, and as shown in fig. 3, the apparatus includes a first sending module 32, a first receiving module 34, and a first determining module 36, which will be described below.

A first sending module 32, configured to send request information to one or more resource modules after receiving a resource invoking request, where the request information is used to request to invoke a resource; a first receiving module 34, connected to the first sending module 32, for receiving response information fed back by one or more resource modules according to the request information; and a first determining module 36, connected to the first receiving module 34, configured to determine, according to the received response information of the one or more resource modules, a resource to be called by the resource calling request.

Fig. 4 is a block diagram of a preferred structure of the first determining module 36 in the resource route processing apparatus according to the embodiment of the present invention, and as shown in fig. 4, the first determining module 36 includes a first obtaining module 42, a first determining unit 44, and a second determining unit 46, and the first determining module 36 is explained below.

A first obtaining module 42, configured to obtain resource information of the one or more resource modules, where the one or more resource modules lock available resources that exist in the one or more resource modules; a first determining unit 44, connected to the first obtaining module 42, for determining an available resource module from the resource modules having available resources; and a second determining unit 46, connected to the first determining unit 44, for determining the available resource in the callable resource module as the resource to be called by the call request.

Fig. 5 is a block diagram of a resource routing processing apparatus according to a preferred embodiment of the present invention, and as shown in fig. 5, the apparatus further includes a second sending module 52, in addition to all the modules shown in fig. 4, for sending information to other resource modules except the determined resource module that can invoke the resource after determining the resource to be invoked by the resource invocation request, where the information is used to instruct the other resource modules to release the locked resource.

Fig. 6 is a block diagram of a resource route processing apparatus according to a preferred embodiment of the present invention, and as shown in fig. 6, the apparatus includes, in addition to all the modules shown in fig. 3 and the first obtaining module 42 of fig. 4: the first placement module 62 is configured to place the resource invocation request in the request waiting queue when the response message indicates that no resource is available.

Fig. 7 is a block diagram of a preferred structure of the first sending module 32 in the resource route processing apparatus according to the embodiment of the present invention, and as shown in fig. 7, the first sending module 32 includes a first sending unit 72 and/or a second sending unit 74, and the first sending module 32 is explained below.

A first sending unit 72, configured to send request information to one or more automatic service function modules in the call center after receiving a resource invocation request from the call session task management module of the call center; and/or, the second sending unit 74 is configured to send request information to one or more manual service function modules in the call center after receiving the resource invocation request of the automatic service function module requesting the manual service function module.

Fig. 8 is a block diagram of a service request processing apparatus of a call center agent according to an embodiment of the present invention, and as shown in fig. 8, the service request processing apparatus includes a third sending module 82 and a second receiving module 84, which will be described below.

A third sending module 82, configured to send a service request to the call center, where the service request is used to request to invoke a resource, and the resource is a call center agent; and a second receiving module 84, connected to the third sending module 82, configured to receive resource module information, which is returned by the call center and can invoke resources, where the call center sends request information for invoking resources to one or more resource modules in the call center according to the service request, and determines resource module information, which is used for invoking resources and requested by the service, according to response messages fed back by the one or more resource modules.

Fig. 9 is a block diagram of a service request processing apparatus of a call center agent according to a preferred embodiment of the present invention, and as shown in fig. 9, the apparatus includes, in addition to all modules of fig. 8, a first invoking module 92, configured to, after receiving resource module information of an invokable resource returned by the call center, invoke the invokable resource according to the resource module information of the invokable resource.

In this embodiment, a call center based on a cloud computing architecture provides a method and an apparatus for distributed routing based on a cloud call center. Distributed routing management is achieved for various resource requests in a cloud call center. The distributed routing refers to: when a request needs to call a Resource Module in a cloud Resource pool, the request is first sent to a Resource Scheduling Module (RSM) to request to call a target Resource, and after receiving the Resource calling request, the RSM performs routing processing on the target Resource Module. Specifically, the following two processing methods can be adopted:

(1) after receiving the request, the RSM selects an available resource module according to the target resource module information (such as the running state, the load and the like) on the RSM, and then allocates the request to the resource module for processing; if no target resource module is available, a new target resource module is created by the RSM and then allocated to the request.

It should be noted that if no resource can be created, the request is placed on the RSM, waiting for an available resource module to appear. The specific mode is as follows: the request is placed in a resource request queue above the RSM according to a certain policy. When the RSM finds that the resource module is available, a request is selected from a request queue currently placed in the RSM according to a certain strategy, and then the request is distributed to the target resource module. Wherein the queue type on the RSM may be a type corresponding to the resource module. If there are multiple types of resource modules in the resource pool, there will be multiple request queue types of corresponding types on the RSM.

(2) And the RSM sends a resource calling request to each target resource module corresponding to the request in the resource pool. Each resource module receiving the request feeds back the current available resource information of itself to the RSM, wherein the current available resource information includes information of the resource module (for example, address, identifier, port, etc. of the module), identifier of the resource (for example, address, identifier, etc.), and the like. Meanwhile, each resource module locks the available resources on the resource module; according to the received response message of each resource module, the RSM selects an available resource module according to a certain strategy. Then, the RSM informs other resource modules to release the previously locked resource; the request is then serviced by the selected resource module. The resource service can be provided by adopting the following processing modes: the RSM returns the relevant information of the selected resource (the identification, address, port of the resource module, and identification, address, etc. information of the resource) to the resource requester. The resource requester requests the resource module selected by the RSM according to the related information. If all resource modules have no available resources, the corresponding resource service logic is reallocated and loaded by the RSM and then the resource modules are analyzed to the requester. If no resource block can be created, the RSM queues the request on top of the RSM, waiting for the presence of an available resource block, as described in process (1).

In the embodiment, a more specific implementation manner is also provided, in the call center, the following distributed routing method is adopted for the requests (including the requests of the types of calls, sessions, task requests and the like) from the call center users and/or the third parties. In this embodiment, the Call center includes a Call Session Task Management Function (CSTMF), an Automatic Service Function (ASF), an artificial Service Function (MSF), and an internet information Function (IIMF). Wherein, the MSF, the ASF and the IIMF are all loaded on the resource modules in the resource pool. CSTMF is used to handle calls, sessions and tasks from the network and distribute the call sessions and tasks to corresponding functional modules in the call centre, similar in function to a SIP Proxy or acd (automatic call distribution). IIMF is a system for aggregating information on the internet and then requesting CSTMF to process the relevant information; the ASF is used for providing an automatic service processing function; the MSF is used to provide manual traffic handling functions. In addition, in the cloud call center, a Resource Scheduling Module (RSM) is further included, and is used for scheduling the call center resources, including: allocation, deletion, scheduling, reclamation, etc.

When a call center user's request (call, session or task) or a request (call, session or task) from another module enters the CSTMF of the call center, the CSTMF first initiates a routing request to the ASF to the RSM. The RSM then finds the appropriate ASF to service the request. Specifically, the following two processing methods can be adopted:

(1) the RSM selects a routable ASF module according to the information (such as load, state and the like) of the ASF module to which the request belongs; then forwarding the request to the ASF module; if all ASFs are not available, new ASF resources are created by the RSM and the ASF will then process the request for providing automatic business services. For this method, the RSM already has information (e.g., load information, etc.) of each ASF.

It should be noted that, if no resource can be created, the request is placed in a request queue of the corresponding MSF resource type in the RSM, and waits for an available ASF resource module. When the RSM finds that the ASF resource module is available, a request is selected from the request queue placed at the time according to a certain strategy, and then the request is distributed to the ASF module.

(2) The RSM initiates a resource calling request to each ASF resource module to which the request belongs in the resource pool, each ASF module receiving the request feeds current information of the ASF module back to the RSM, and the current information comprises information (including load information, address, identification and the like) of each ASF resource module and information (including address, identification and the like) of resources (including ASF process) and the like. Wherein, the ASF resource module locks the resource; after receiving the message responded by each ASF resource module, the RSM selects one ASF resource module and corresponding resources according to a certain strategy. Then, the RSM informs other ASF resource modules to release the previously locked resources; then, the RSM sends the information related to the resource module of the selected ASF to the requester, where the related information includes: the address, identification, port and resource information of the resource module includes: address, identification, etc. Then, the requester requests the ASF resource module to provide service for the request according to the information returned by the RSM. If all ASFs have no resources available, the ASF resource modules are recreated and loaded by the RSM. If no resource module can be created, the request is placed in a request queue on the RSM, and when the resource module can be used, the RSM selects a request from the queue according to a certain strategy. Resources are then allocated to the request.

The request is then provided with automatic business services by the ASF.

When a requester such as a user needs to transfer MSF manual service based on service selection of the ASF resource module, the ASF requests the CSTF to provide manual service for the MSF. The CSTMF then initiates routing and queuing requests to the RSM for the MSF's resources (i.e., agents).

After receiving the routing and queuing service request of the ASF for the agent, the RSM initiates a distributed routing request to all MSF resource modules corresponding to (belonging to) the request in the resource pool. The MSF resource module receiving the request locks available agents (agents), and returns the locked agents (including identifiers and the like) and the information of the MSF (including loads, addresses, identifiers and the like) to the RSM. And the RSM receives the results returned by the MSFs, compares the results according to the strategy of the call center corresponding to the request, selects the seat returned on one MSF as the selected seat, and informs other MSFs of releasing the locked seat.

If all the returned results of the MSFs are all busy, the RSM places the corresponding request (call, session or task) on the RSM, and the following processing method can be adopted during the specific processing: queuing the request in a queue on the RSM corresponding to the MSF resource type; or the RSM selects an MSF according to the information reported by each MSF, then places the request on the MSF for queuing, and then the MSF performs the agent selection of the MSF based on the prior art.

If all MSF resource modules are also fully busy, the RSM recreates the resource modules in the resource pool and loads the MSF service logic. The RSM may also queue the request onto the MSF resource block. Thereafter, the MSF makes an agent selection for the MSF based on prior art.

If the RSM selects an agent on a certain MSF resource module, the RSM returns the MSF resource module information and the related information of the agent (such as the identification of the agent, the identification \ address of the MSF and the like) to the ASF resource module which initiates the request through the CSTMF. The ASF resource module sends its request (call, session or task, etc.) to the MSF resource module via the CSTMF. The MSF resource module then notifies the selected agent, which receives the request and processes it.

For the situation that when a request encounters an agent busy and the RSM places the corresponding request on the queue of the corresponding MSF resource module to wait, when an agent on an MSF in the resource pool becomes idle or a new agent logs on the MSF, the MSF may adopt the following two processing modes:

(1) the MSF will initiate a request to the RSM for processing of a task in a queue on the RSM, the request including information of an agent and information of the MSF resource module. The RSM selects a request in the queue according to policy information (which may be, for example, a pre-set script policy). Then, the RSM sends a message to the ASF indicating that there is an agent to process the request based on the request, where the message carries MSF resource module information and agent information (e.g., an identifier of the agent, an identifier/address of the MSF, etc.). The ASF then forwards the corresponding request (call, session or task) to the selected MSF via the CSTMF. The MSF then notifies the corresponding agent, which receives the request and processes it.

(2) The MSF reports the information (including load information, busy and idle information of the login seat, etc.) to the RSM. After receiving the information, the RSM finds that an MSF has free resources (agents), and then selects a request in a corresponding queue on the RSM according to the policy information (for example, the policy may be a preset script policy). This request is then sent to the MSF. Then, the RSM will send a message to the ASF indicating that there will be an agent to provide service, where the message carries the MSF and the information of the agent (e.g., the identity of the agent, the identity \ address of the MSF, etc.). The ASF forwards the request to the selected MSF via the CSTMF. The MSF then notifies the corresponding agent, which receives the request and processes it.

The following describes embodiments and preferred embodiments of the present invention with reference to the drawings.

Fig. 10 is a schematic structural diagram of distributed routing according to an embodiment of the present invention, and as shown in fig. 10, the resource scheduling module is a module in charge of partial scheduling in the cloud resource pool. Any requester who needs to request a resource module from the cloud resource pool must first request the resource scheduling module to allocate an appropriate resource module. A resource requestor is a requestor that needs to request a resource from a pool of resources. It first requests resources from the resource scheduling module. After receiving the resource scheduling request, the resource scheduling module searches for a suitable resource module in the resource pool, and the method for searching for the resource may adopt the distributed routing method provided in the above embodiments and preferred embodiments, which is not described here again, and after finding a suitable resource module, returns the information of the corresponding resource module to the resource requester. The resource requester then requests the service of the target resource module according to the related information returned by the resource scheduling module.

Fig. 11 is a flowchart of a distributed routing processing method according to an embodiment of the present invention, and it should be noted that the flowchart is a general abstract flowchart, and the application scope of the flowchart is not limited to a cloud call center, and can also be used in other cloud computing services. As shown in fig. 11, the process includes the following steps:

step S1102, a resource requester sends a request message to a resource scheduling module to request to call a target resource module;

step S1104, the resource scheduling module sends resource calling request messages to each resource module of the target resource type in the resource pool;

step S1106, each target resource module receiving the resource calling request message determines the resource on the resource module respectively, and then locks the corresponding resource;

step S1108, each target resource module returns corresponding resource information to the resource scheduling module, where the information includes information of the target resource module itself and information of the resource, such as: address, identification, port of the resource module; information such as addresses and identifiers of resources;

step S1110, the resource scheduling module selects a proper target resource module according to a certain strategy;

step S1112, the resource scheduling module sends a notification message to other target resource modules to notify them to release the previously locked resource information;

step S1114, the resource scheduling module returns the relevant information of the selected target resource module to the resource requester;

in step S1116, the resource requester establishes a connection with the target resource module and requests a service of the target resource based on the message returned by the resource scheduling module.

Fig. 12 is a flowchart of a distributed routing processing method for an agent according to an embodiment of the present invention, which is taken as a cloud call center in this embodiment, but is not limited to this, and as shown in fig. 12, the flowchart includes the following steps:

step S1202, a user needs to switch to a manual service module after accessing an automatic service function module;

step S1204, the automatic business function module initiates the route and queue request aiming at the seat to the resource scheduling module requesting the artificial business resource module;

step S1206, after receiving the request, the resource scheduling module sends a distributed route to the manual service module: namely, a routing request is sent to each manual service module;

step S1208, each manual service module determines and locks a corresponding seat according to the request, and returns the information of the manual service module and the seat information to the resource scheduling module;

step S1210, the resource scheduling module selects an agent on the artificial service module according to the returned message;

step S1212, the resource scheduling module notifies other manual service modules to release the previously locked agent resources;

step S1214, the resource scheduling module returns a message to the automatic service resource module, wherein the message includes the information of the selected artificial service resource module and the agent;

step S1216, the automatic service resource module transfers the user' S request to the corresponding manual service resource module according to the received message;

step S1218, the manual service resource module notifies the seat;

in step S1220, the agent answers the request and processes the session.

It will be apparent to those skilled in the art that the modules or steps of the present invention described above may be implemented by a general purpose computing device, they may be centralized on a single computing device or distributed across a network of multiple computing devices, and alternatively, they may be implemented by program code executable by a computing device, such that they may be stored in a storage device and executed by a computing device, and in some cases, the steps shown or described may be performed in an order different than that described herein, or they may be separately fabricated into individual integrated circuit modules, or multiple ones of them may be fabricated into a single integrated circuit module. Thus, the present invention is not limited to any specific combination of hardware and software.

The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention, and various modifications and changes may be made by those skilled in the art. Any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A resource routing processing method is characterized by comprising the following steps:

after receiving a resource calling request, sending request information to one or more resource modules, wherein the request information is used for requesting to call resources;

receiving response information fed back by the one or more resource modules according to the request information;

and determining the resources to be called by the resource calling request according to the received response information of the one or more resource modules.

2. The method of claim 1, wherein the request information is sent to the one or more resource modules in a broadcast manner.

3. The method of claim 1, wherein determining the resource to be called by the resource calling request according to the received response information of the one or more resource modules comprises:

acquiring resource information of the one or more resource modules, wherein the one or more resource modules lock available resources existing in the one or more resource modules;

determining an available resource module from the resource modules having available resources;

and determining the available resources in the callable resource module as the resources to be called by the call request.

4. The method of claim 3, after determining the resource to be called by the resource call request, further comprising:

and sending information to other resource modules except the determined resource module which can call the resource, wherein the information is used for indicating the other resource modules to release the locked resource.

5. The method of claim 1, further comprising, after receiving response information fed back by the one or more resource modules according to the request information:

and when the response message indicates that no resources are available, the resource calling request is arranged in a request waiting queue.

6. The method according to any of claims 1-5, wherein the response information comprises at least one of:

the load information of the resource module, the address of the resource module, the identifier of the resource module, the port of the resource module, the address of the resource corresponding to the resource module, and the identifier of the resource corresponding to the resource module.

7. The method according to any of claims 1-5, wherein the resource is an agent in a call center.

8. The method of claim 7, wherein the resource invocation request includes at least one of:

the call center comprises a resource calling request of a call center seat, a resource calling request of a call center user, a resource calling request of an internet information gateway, a resource calling request of a call session task management module, a resource calling request of an automatic service module, a resource calling request of a manual service module and a resource calling request of a manual service module steering by the automatic service module.

9. The method of claim 7, wherein sending request information to one or more resource modules in a call center comprises:

after receiving the resource calling request from a call session task management module of the call center, sending the request information to one or more automatic service function modules in the call center; or,

and after receiving a resource calling request of the automatic service function module for requesting a manual service function module, sending the request information to one or more manual service function modules in the call center.

10. A service request processing method for a call center agent is characterized by comprising the following steps:

sending a service request to a call center, wherein the service request is used for requesting to call resources, and the resources are call center seats;

and receiving resource module information of the resources which can be called and returned by the call center, wherein the call center sends request information of calling the resources to one or more resource modules in the call center according to the service request, and determines the resource module information of the resources which can be called and requested by the service request according to response messages fed back by the one or more resource modules.

11. The method of claim 10, further comprising, after receiving resource module information for the callable resource returned by the call center:

and calling the callable resources according to the resource module information of the callable resources.

12. The method according to claim 10 or 11, wherein the one or more resource modules are human business modules, and the resource module information is address and/or identification information of the human business modules.

13. A resource route processing apparatus, comprising:

the system comprises a first sending module, a second sending module and a resource module, wherein the first sending module is used for sending request information to one or more resource modules after receiving a resource calling request, and the request information is used for requesting to call resources;

a first receiving module, configured to receive response information fed back by the one or more resource modules according to the request information;

and the first determining module is used for determining the resources to be called by the resource calling request according to the received response information of the one or more resource modules.

14. The apparatus of claim 13, wherein the first determining module comprises:

a first obtaining module, configured to obtain resource information of the one or more resource modules, where the one or more resource modules lock available resources that exist in the one or more resource modules;

a first determining unit, configured to determine an available resource module from among resource modules in which an available resource exists;

a second determining unit, configured to determine that an available resource in the callable resource module is a resource to be called by the call request.

15. The apparatus of claim 14, further comprising:

and a second sending module, configured to send information to other resource modules except the resource module that is determined to invoke the resource after determining the resource that is to be invoked by the resource invocation request, where the information is used to instruct the other resource modules to release the locked resource.

16. The apparatus of claim 13, further comprising:

and the first arranging module is used for arranging the resource calling request in a request waiting queue when the response message indicates that no available resource exists.

17. The apparatus of claim 13, wherein the first sending module comprises:

the first sending unit is used for sending the request information to one or more automatic service function modules in the call center after receiving the resource calling request from the call session task management module of the call center; or,

and the second sending unit is used for sending the request information to one or more manual service function modules in the call center after receiving the resource calling request of the automatic service function module requesting the manual service function module.

18. A service request processing apparatus for a call center agent, comprising:

the third sending module is used for sending a service request to the call center, wherein the service request is used for requesting to call resources, and the resources are call center seats;

and the second receiving module is used for receiving resource module information of the callable resources returned by the call center, wherein the call center sends request information for calling the resources to one or more resource modules in the call center according to the service request, and determines the resource module information of the callable resources of the service request according to response messages fed back by the one or more resource modules.

19. The apparatus of claim 18, further comprising:

and the first calling module is used for calling the callable resources according to the resource module information of the callable resources after receiving the resource module information of the callable resources returned by the call center.