Call-center call routing

[0002] The present invention relates to call routing in relation to call centers logically composed of a number of workgroups. In particular, but not exclusively, the present invention relates to call routing in relation to call centers capable of handling both traditional telephone calls and VoIP (“Voice over IP”) calls.

[0003] The selective routing of incoming calls through the public telephone network to the most appropriate workgroup of a call center and then to the most appropriate agent in the selected workgroup is a key activity in ensuring the efficient operation of a call center. A number of solutions have been proposed in the past, notable amongst which are those disclosed in the following US patents:

[0004] U.S. Pat. No. 4,737,983—describes a method of balancing traffic loads to a plurality of ACDs in which “call congestion data” is fedback from ACDs to an update processor that controls the updating of a routing table to cause the latter to reflect the desired % of calls to go to each ACD. The routing table is used by a service control function of the PSTN to route calls to the appropriate ACD.

[0005] U.S. Pat. No. 5,452,350—describes a system in which the service control function of a PSTN queries a routing processor of the subscriber (e.g. call center) network to be told the number to which a call should be routed to access a particular resource. Routing is done on the basis of call identification information and capacity percentages (% of calls to go to particular resources).

[0006] U.S. Pat. No. 5,335,268—describes a system in which routing is done on the basis of network usage, ACD availability, and route costing data.

[0007] U.S. Pat. No. 5,291,550—describes a system in which the call center operator defines the routing policy to ACDs and periodically uploads it to a dynamic network call distributor. Routing is dependent on call class (indicated by elements in dialed number) as well as traffic load and routing parameters.

[0008] U.S. Pat. No. 5,546,452—describes a system in which a central controller generates control signals for controlling both the telephone network and the caller resource (ACDs) so as to optimally route the call.

[0009] Whilst the foregoing prior art disclosures only concern the routing of voice calls through the telephone infrastructure, it is also known to effect routing control for other call types such as voice calls passing as packet data over a data network, or text-based calls such as e-mails. Thus, U.S. Pat. No. 5,765,033 describes a system in which information is extracted from e-mail received at a call center and is used to select an agent with appropriate skill to which the email should be routed (this system concerns internal routing in a call center rather than routing to the call center itself). U.S. Pat. No. 5,848,143 and U.S. Pat. No. 5,878,130 both describe the use of a central routing controller for routing Internet calls as well as normal PSTN calls.

[0010] An important consideration in implementing a call routing control system is how to provide fault tolerance to avoid system collapse should part of the routing control means fail for whatever reason. The usual approach adopted is to provide duplicate routing controllers connected in parallel to the other system components; one such arrangement is described in the afore-mentioned U.S. Pat. No. 5,848,143. However, the current systems do not provide easy scalability and are generally expensive to implement.

[0011] It is an object for the present invention to provide an improved call routing system and method which inherently provides fault tolerance capability and facilitates load spreading.

[0012] According to one aspect of the present invention, there is provided a call center system with multiple workgroups, each workgroup having a routing controller comprising:

[0013] routing-data generating means operative to derive workgroup routing data indicative of the suitability of destinations within the workgroup for receiving calls;

[0014] transfer means for passing the workgroup routing data directly or indirectly to the routing controllers of the other workgroups;

[0015] storage means for storing the workgroup routing data of all operative workgroups, and

[0016] global routing means for receiving a routing request in respect of a call incoming to the call center, determining from the stored routing data for all operative workgroups which workgroup is most suited to handle a call, and responding to the routing request accordingly.

[0017] According to another aspect of the present invention, there is provided a method of controlling the routing of calls to a call center system with multiple workgroups, the method involving carrying out the following operations separately for each workgroup:

[0018] generating, for the workgroup concerned, workgroup routing data indicative of the suitability of destinations within the workgroup for receiving calls;

[0019] exporting the workgroup routing data for the workgroup concerned;

[0020] receiving workgroup routing data exported in respect of the other workgroups and storing the workgroup routing data of all operative workgroups, and

[0021] receiving a routing request in respect of a call incoming to the call center, determining from the stored routing data for all operative workgroups which workgroup is most suited to handle a call, and responding to the routing request accordingly.

[0022] A call center embodying the invention will now be described, by way of non-limiting example, with reference to the accompanying diagrammatic drawings, in which:

[0023] FIG. 1 is a diagram of the call center showing its relation to a PSTN and an IP-based network;

[0024] FIG. 2 is a diagram similar to FIG. 1 showing message paths and call routing during connection of a PSTN-originating call to a call-center agent; and

[0025] FIG. 3 is a diagram similar to FIG. 1 showing message paths and call routing during connection of a network-originating VoIP call to a call-center agent.

[0026] The FIG. 1 call center comprises three logical work groups WG1, WG2, WG3 (generically referred to below as “WG”) that may be co-located or geographically dispersed. The call center interfaces both with a traditional telephone network 10, and with an inter-connected network 20 of IP-based networks (this network of networks being hereinafter referred to simply as the “IP network” 20). By way of example, the telephone network 10 is here shown as a PSTN (analog and/or ISDN based), but may equally be a PLMN, a private network, or similar telephone network. The IP network 20 may be the Internet, an intranet, or similar IP-based network.

[0027] The PSTN includes as well as normal switches (not shown), a service switching point (SSP) 22 capable of determining that a particular service is required for a call and for sending a service request to the service control subsystem of the PSTN. In the present example, the service control subsystem comprises a “WebSCP” 23, namely a service control point (SCP) with a web interface for retrieving service data and logic over the IP network 20 using the web HTTP protocol . Further details of WebSCP 23 are given in our published International Application WO97/22210 which is incorporated herein by reference. In fact, any SCP with an interface to the IP network 20 may be used for component 23. Whatever the precise form of SCP 23, the SCP will respond to a service request from SSP 22 with a number to be used for routing the call in respect of which the service request was made. As will be explained hereinafter, in the present case the SCP23 determines its response in dependence on data it receives back from a query sent out over the IP network 20.

[0028] Each workgroup WG comprises a LAN 11 to which are connected a plurality of agent workstations 12, a media gateway 13, a media server 14, a gatekeeper 15 with an associated web server 16, and a router 17. Each workgroup WG connects via its gateway 13 to the PSTN 10, and via its router 17 to the IP network 20 of which it substantially forms a part.

[0029] Each workgroup can thus receive calls from both the PSTN and from terminals 21 (such as a PC) linked to the IP network 20. Calls from the PSTN are received at the gateway 13 and are converted into a VoIP call for routing to a selected agent workstation 12 over LAN 10. VoIP calls from terminals 21 are received at the router 17.

[0030] By way of example, the VoIP calls will be taken to be in accordance with the H.323 standard though other VoIP standards can alternatively be used.

[0031] Each agent workstation 12 is capable of handling VoIP calls and, in addition, can receive caller data for screen display to the agent. This caller data can be derived from any appropriate source such as a caller database (not shown) holding known information about a caller, or from an information-collecting resource arranged to gather caller data as an initial phase of a current call (for example, using the media server or a related website interaction with the caller).

[0032] Calls received at a workgroup WG may instead of being routed to an agent workstation, be routed to the media server for delivery of voice announcements (more generally for every capability involving data streaming) and/or the collection of user input.

[0033] Although each workgroup WG has been described as being composed of elements all connecting with the same LAN 10, it would be possible to remotely locate elements. For example, one or more agent workstations may reside at a remote location on a different LAN or at the end of an ISDN link. The physical location of the components is not itself of importance, but it is necessary for the gatekeeper 15 to know (or be able to determine) the IP address of the components of the same workgroup WG.

[0034] Consideration will next be given as to how call control is effected for the call center. At a basic level, control of the VoIP calls in the IP network 20 (whether PSTN originating or terminal-originating) is effected in known manner by gatekeepers (eg gatekeepers 15) that exchange control messages (for example in accordance with the Inter-GateKeeper protocol of the H.323 standard). Thus, the gatekeeper 15 of a workgroup WG will know the IP addresses of the associated agent workstations 12 and can return the IP address of an available agent workstation in response to a request as to where to route an incoming call.

[0035] At a higher level, the gatekeeper 15 of a workgroup WG also performs a workgroup-level control function by determining priorities between its agent resources. More particularly, the gatekeeper 15 keeps track of the availability of agents at the agent workstations (“availability” being dependent on factors ranging from simple presence, to length of call-waiting queue). Additionally, the gatekeeper 15 will store policies and data relating to agent skill level and time-of day routing. Based on all these factors (and potentially further factors), the gatekeeper 15 will construct a routing table, in a manner well understood by persons skilled in the art, which it stores. This routing table is then used by the gatekeeper to determine to which workstation 12 to allocate a call (the call may not be immediately be routed to that workstation but may need to be queued and/or connected to the media server 14 as a preliminary step). The gatekeeper 15 updates its routing table at frequent intervals (or whenever a relevant parameter changes).

[0036] In the present call center, the gatekeepers 15 of all the workgroups WG are arranged to exchange their routing tables at frequent intervals, each gatekeeper 15 storing the routing tables for all workgroups WG. The exchange of routing tables (indicated by a dotted ellipse in FIG. 1) can be effected either using IGCP (in which case the gatekeepers themselves effect the exchange) or using HTTP (in which case it is the web servers 16 associated with each gatekeeper 15 that effect the exchange). Any distribution topology may be used for the exchange (ring, fully meshed, etc.).

[0037] Since each gatekeeper 15 now has access to the routing tables for all workgroups, each gatekeeper can make global routing decisions between the workgroups, that is, decide which workgroup is best suited to handle any particular call. The algorithm used to determine which workgroup is best suited should be the same for each gatekeeper to ensure consistency of decision between them; how such an algorithm may make its selection is well understood by persons skilled in the art and will therefore not be detailed.

[0038] Having described the basic structure and control functions of the call center, two examples of its operation will now be given.

[0039] FIG. 2 illustrates how a call from a PSTN phone 30 is handled. The caller calls a number N (here given as “0800 123456”) that indicates to the SSP 22 that the caller wishes to place call (in this example, a free-phone call) to the call center. The number N may already designate a particular workgroup or it may simply designate the call center as a whole. The SSP 22 makes a service request to the SCP 23 which, in turn, makes a request to one of the HTTP servers 16 of the call-center workgroups asking for the telephone number to which the call should be routed. The server 16 contacted may be dependent on the number N or may chosen according to some predetermined ordering (for example, on a round robin principle). In the present case, it is the server 16 of workgroup WG1 that is contacted (see thick dashed line 31 in FIG. 2). On receiving the request, the server 16 passes it to its gatekeeper 15 which then determines from the routing tables available to it, which workgroup WG is best suited to handle the call (in this example, workgroup WG2). The telephone number of this workgroup is then returned by the server 16 to the SCP 23 which, in turn, passes it back to the SSP 22. SSP 22 then routes the call from phone 30 to the gateway 13 of workgroup WG2 at the number passed back to the SSP 22 from the gatekeeper 15 of workgroup WG1.

[0040] The gateway 13 then asks the gatekeeper 15 of workgroup WG2 where it should route the call i.e. to which agent workstation 12 or media server 14 (see dashed line 32). The gatekeeper 15 responds appropriately and the gateway 13 then passes the call as a VoIP call over the LAN 11 to the designated agent workstation/media server.

[0041] The route of the call from phone 30 to the agent workstation is indicated by a chain-dashed line in FIG. 2.

[0042] If during this call set up process, SCP 23 had been unable to obtain a response from the server 16 of workgroup WG1, then it will try contacting the server 16 of a different workgroup according to a default schedule held by the SCP. If the second choice server also fails to respond, the SCP may try a third server 16. This fallback messaging is indicated by light dashed lines 33, 34 in FIG. 2.

[0043] This fault tolerant behaviour of the call center is made possible by the fact that the routing tables for all the workgroups are available at each workgroup whereby global routing decisions can be made by any of the gatekeepers 15.

[0044] FIG. 3 shows the handling of a call placed from terminal as a VoIP call (for example a “Help Desk” call). In this case, the gatekeeper 40 of the LAN on which the terminal 21 is situated contacts a gatekeeper 15 of one of the workgroups—in this case workgroup WG3 (see dashed line 43). The gatekeeper of workgroup WG3 determines from all the workgroup routing tables available to it that the call should be handled by workgroup WG2 and informs the gatekeeper 40 accordingly. Gatekeeper 40 then contacts the gatekeeper 15 of workgroup WG2 (see dashed line 44) asking it for the IP address of the agent/media server to which the VoIP call should be routed. Gatekeeper 15 returns the IP address of a particular agent workstation 12 in workgroup WG2 and gatekeeper 40 passes this information back to terminal 21. Terminal 21 then establishes a VoIP call to the appropriate agent workstation (see chain-dashed line).

[0045] It will be appreciated that if the most suitable workgroup was the one first contacted (workgroup WG3 in the present example), the gatekeeper of that workgroup will directly respond with the IP address of the agent (or other resource) to be contacted. Indeed, since the first contacted gatekeeper 15 has available to it the routing table for the workgroup determined by it to be the most suitable, it can in theory directly determine and return the IP address of the agent/resource to receive the call (assuming it had been passed these addresses). However, this is not consistent with the intended operation of the gatekeepers which are generally in charge of routing VoIP calls within their related domains. Furthermore, it is not necessarily the best strategy to adopt since although the routing tables will be reasonably current, they may not have the very latest information concerning agent situation in every workgroup and it will generally be better to leave final workgroup-internal routing up to the gatekeeper of the workgroup selected.

[0046] With respect to how the gatekeeper 40 determines which gatekeeper 15 to contact initially, a number of possibilities exist. Thus, gatekeeper 40 could have previously registered with the call center to be informed of the IP addresses of the gatekeepers 15; the gatekeeper 15, knowing the addresses of the gatekeepers 15 could then either select one according to a predetermined policy or broadcast to all gatekeepers 15 (in which case, gatekeeper 40 would then utilise only the first response only).

[0047] As with calls placed from the PSTN, calls placed form a terminal 21 benefit from the routing information redundancy inherent in the call center whereby should the contacted gatekeeper 15 be down, the other gatekeepers 15 can be contacted to give the same global routing decision.

[0048] Various modifications are, of course, possible to the arrangement described above. For example, the SCP 23 rather than talking to the workgroups WG using HTTP, could talk IGCP directly to the gatekeepers 15 thereby avoiding the need for the servers 16. Furthermore, rather than the full routing table of each workgroup being passed to the other workgroups, a subset of the full routing table could be passed giving sufficient information to enable the most suitable workgroup to be selected according to the selection algorithm in use.

[0049] The network 10, rather than being a telephone network, could, in fact, be any switched telecommunications network. The network 20 may also be a non IP-based packet network. Furthermore, at least one of the workgroups could be arranged to handle non-voice calls, such as text-based calls (for example, e-mails or web-based forms) or video calls.