Method and apparatus for automatic call distribution

[0001] The invention relates to automatic call distribution systems and methods. The invention also relates to methods and apparatus for routing calls or data.

[0002] Automatic call distribution systems are known in the art. In one form of automatic call distribution system, a caller is greeted with a message and asked to remain on the line for the next available agent. In addition to keeping callers waiting on hold until an agent is free, automatic call distribution systems are used commonly with workgroups. A group of agents (e.g., sales agents or technical support agents) share responsibility for handling calls that are placed into their department. The automatic call distribution system decides how to route calls to agent's phones and places overflow calls into a queue until there is an available agent. Also, the automatic call distribution system can be used to route callers to a workgroup that contains people who are most qualified to answer the caller's questions. Agents can be added to a workgroup if they obtain a desired level of skill, e.g. knowledge of a certain product line associated with the workgroup.

[0003] The queue keeps track of the order in which callers called and may also play update messages assuring the caller that their call is important and may give the caller the option of leaving a voicemail message instead of continuing to hold. Some automatic call distribution systems inform the caller of the approximate or average wait time or their position in the queue so the caller can judge whether to continue holding.

[0004] In certain automatic call distribution systems, an incoming phone call is routed to an appropriate person, typically in response to identification of the caller by caller ID.

[0005] One use of automatic call distribution systems is in connection with businesses that have a common phone number, such as an 800 number, that is advertised in a large geographic area. When a customer or potential customer calls the number, an automatic call distribution system automatically routes the call to a local store or service provider, whose service area encompasses the location from where the caller is calling. The local store may be a franchise, corporate owned, or otherwise affiliated with the company that advertises the phone number. For example, a business may advertise the same, easy to remember phone number in many geographic locations, so that someone who travels or moves does not have to memorize multiple phone numbers. When the client or potential client calls the number, the call is routed to a local office or location of the company.

[0006] Alternatively, a company may have one call center that handles all calls. Calls from certain people are routed in a particular manner based on rules applied for the caller. For example, callers who have an existing account or who are previous callers may be routed to a different person than a first time caller or their call may be processed before a first time caller. Alternatively, a caller who is known to speak a certain language may be routed to someone who speaks that language.

[0007] Such automatic call distribution systems sometimes rely on technology to automatically identify the telephone number of the calling party. See, for example, U.S. Pat. No. 5,163,087 to Kaplan (incorporated herein by reference) which discloses a system that translates an Automatic Number Identification (ANI) of the calling party into a customer database key or customer account number previously defined by the called party. The called business can then process the key to look up customer information and present it to a customer service representative of the called business. ANI information is useful if the business has a customer record for the calling party, e.g. in view of a previous phone call.

[0008] Attention is directed to the following U.S. patents, which relate to automatic call routing, and which are incorporated herein by reference: U.S. Pat. No. 5,963,625 to Kawecki et al.; U.S. Pat. No. 5,956,397 to Shaffer et al.; U.S. Pat. No. 5,946,387 to Miloslavsky; U.S. Pat. No. 5,946,386 to Rogers et al.; U.S. Pat. No. 5,920,621 to Gottlieb; U.S. Pat. No. 5,910,983 to Dezonno et al.; U.S. Pat. No. 5,867,493 to Zisapel; U.S. Pat. No. 5,838,682 to Dekelbaum et al.; U.S. Pat. No. 5,784,451 to Smith, Jr.; and U.S. Pat. No. 5,724,418 to Brady.

[0009] Prior art automatic call distribution systems typically maintain state, or know about all agents and what they are doing at any given time. This centralizes capability and limits scalability and flexibility.

[0010] The invention provides an Internet Protocol (IP) call distribution system, for selecting agents to handle incoming requests from users, that uses publish/subscribe technology so that agent state does not need to be maintained.

[0011] In another aspect of the invention, an IP gateway is configured to convert PSTN phone calls to Internet Protocol phone calls. The IP gateway is configured to pass ANI information, if available, from the PSTN phone call.

[0012] In another aspect of the invention, a server is configured to be coupled to the IP gateway by an Internet Protocol network, and configured to be coupled to agent workstations by an Internet Protocol network. The server has a computer readable media bearing publish/subscribe software. The server further includes a memory storing call processing rules which determine how incoming calls are to be handled, and a memory storing a customer database including records about customers and customer identification information, such as ANI information, associated with the customers.

[0013] In another aspect of the invention, the server is configured, for respective incoming calls, to search the customer database for a record for the user, by searching for a record containing the customer identification information for the call. The server is further configured to apply rules appropriate for the user, using the rules engine, to determine a subset of agents with skills required to communicate with the user. The server is further configured to broadcast an event to the subset of agents indicating that a call is available to be handled. The server is configured to receive responses from available agents of the subset and to select an available agent of the subset and pass the call to the selected agent. The agents subscribe to skills using the publish/subscribe software.

[0014] One aspect of the invention provides an automatic call distribution method for selecting agents to handle incoming requests from users, that uses publish/subscribe technology so that agent state does not need to be maintained.

[0020] FIG. 1 shows a system 10 in accordance with one embodiment. The system 10 shown in FIG. 1 includes basic components as might be used in a multi-media system. Additional or fewer components could be employed.

[0021] The system 10 includes an Internet telephony gateway 12 that provides for communications between a standard telephone and an Internet Protocol phone (e.g., to allow for telephone calls over the Internet).

[0022] The Internet telephony gateway 12 takes voice or fax calls from the circuit-switched PSTN (Public Switched Telephone Network, e.g., a system used by conventional home phones) and places them on a packet-switched network, such as the Internet, for use with an IP phone. One or more such gateways 12 could be located such that a call to them would be a local phone calls for the calling party, and such that a network 18 is used for the long distance transmission. The network 18 can be the Internet or a local or wide area network that uses the Internet Procol, such as Novell Netware 5 ™ network. Thus, expenses are reduced by avoiding long distance charges. Internet telephony gateways are commercially available, and can be used to provide communications from one phone to another, from a phone to a fax, from a phone to a computer, or from a computer to a phone. For example, one gateway that could be used for the Internet telephony gateway server 12 is the VocalTec ™ telephony gateway, available from VocalTec Communications limited, One Executive Drive, Suite 320, Fort Lee, N.J. 07024. Another gateway that could be used for the Internet telephony gateway 12 is the MICOM ™ V/IP phone and fax gateway, available from Nortel Networks, 8200 Dixie Road, Brampton, Ontario, Canada L6T 5P6, and also sold by Hello Direct, 5893 Rue Ferrari, San Jose, Calif. 95138-1857. The Internet telephony gateway 12 can use any of various signaling protocols. For example, in the illustrated embodiment, the gateway 12 is an IPTel Gateway which acts as an SIP Server. IPTel stands for Internet Protocol telephony. SIP stands for Session Initiation Protocol, a standard for IP (Internet Protocol) voice communication. Further information can be obtained from IETF, the Internet Engineering Task Force, or from their web site. In an alternative embodiment, instead of using the SIP signaling protocol, the server acts as an H.323 Gateway, using the H.323 protocol. H.323 is a standard for IP Voice. The H.323 standard is known in the art and provides for communications between a standard telephone and an Internet Protocol phone. Further information about H.323 can be obtained from the International Telecommunications Union (ITU), or from their web site. Alternatively, a proprietary implementation could be employed, if desired.

[0023] Although shown as a single component, the gateway 12 may include more than one component. The system 10 further includes one or more PSTN phones 14 and fax machines 16 coupled by the gateway 12 to the network 18.

[0024] The system 10 further includes a web server 20. Although shown as a single component, the web server 20 may include one or more components. The web server 20 is a computer including components typical of web servers, e.g., such as RAM, ROM, a processor, hard drive, floppy drive, tape drive, Zip ™ drive, CD-ROM, communications hardware, etc., and runs a multi-user multi-tasking operating system such as LINUX or UNIX, for example. Software is installed on the web server 20 to support chat, collaboration, e-mail, web phone, etc. Such web servers are known in the art and will not be discussed here in any detail. The system 10 further includes one or more client machines 22, 24, 26, 28, which are selectively coupled to the web server 20 by modem or other conventional communications method. The client machines 22, 24, 26, and 28 are computers, such as personal computers, or computer terminals bearing software capable of one or more of: e-mail, web collaboration, chat, or web phone operation. Although FIG. 1 shows respective client machines 22, 24, 26, and 28 running different client software programs, it will of course be understood that the client machines are respectively capable of running more than one of the illustrated client programs. Because the web server 20 runs a multi-user, multitasking operating system, multiple clients could be running e-mail programs at the same time, multiple clients could be running chat sessions, multiple clients can be running web collaboration sessions, and multiple clients could be running web phone sessions all at the same time, for example.

[0025] The system 10 further includes an automatic call distribution server 30 which, in one embodiment, includes a computer including standard computer server components, such as RAM, ROM, a processor, hard drive, floppy drive, tape drive, Zip ™ drive, CD-ROM, communications hardware, etc. The automatic call distribution server 30 further includes memory (e.g., memory defined by the hard drive or on a medium readable by one of the other drives) defining a customer database 32 and defining customer rules and a rules engine 34.

[0026] The system 10 further includes a unified messaging server 36 which, in one embodiment, includes a computer including standard computer server components, such as RAM, ROM, a processor, hard drive, floppy drive, tape drive, Zip ™ drive, CD-ROM, communications hardware, etc. The unified messaging server 36 further includes memory (e.g., on the hard drive or on a medium readable by one of the other drives).

[0027] In one embodiment, the system 10 further includes one or more pagers 37 coupled to the unified messaging server 36 for wireless communications.

[0028] In operation, traditional PSTN phone calls come into the server 12 and are converted to IP (Internet Protocol) by the gateway 12. The calls are like any other IP voice call after being converted. ANI (Automatic Number Identification/Caller ID) is used by the automatic call distribution server 30 to aid in customer lookup, if the caller has a profile stored in the customer database 32. The customer database 32 can reside on or off a network 31 controlled by an administrator of the system 10 and to which the server 30 is coupled. Operators of one or more call facilities maintain the server 30 and customer database 32. Each call facility can have one or more human agents. FIG. 1 shows human agents 38, 40, 42, 44, and 46 respectively operating stations 48, 50, 52, 54, and 56. The stations 48, 50, 52, 54, and 56 include a computer, an IP phone, or both. Users of the PSTN phones 14 communicate with human agents via voice conversation.

[0029] The unified messaging server 36 handles facsimiles. A facsimile sent on a fax machine 16 comes in through the gateway 12 (the gateway 12 supports facsimile transmission) and via the network 18 is forwarded to the server 36. The facsimile image is converted, via OCR (optical character recognition) software residing on the unified messaging server 36, to a text format or word processing format. OCR software is known in the art. In one embodiment, the text is analyzed for content, (e.g., by the unified messaging server 36 or elsewhere) such as for digits stored in phone number format, words following keywords like TO/FROM etc., and such information is used, for example, to aid in customer lookup in the customer database 32. In one embodiment, the ANI information from the phone line used to send the facsimile is used to aid in customer lookup in the customer database 32.

[0030] The call distribution server 30 selects an agent 38, 40, 42, 44, or 46 to which to forward the facsimile based on rules defined in the rules engine 34. The facsimile is converted (e.g., by the unified messaging server 36) to an e-mail containing text from the OCR operation, or having a facsimile image attached, or both. After an agent is selected, the facsimile is routed (e.g., by the unified messaging server 36) to the selected agent, preferably in real-time. Further communication between the selected agent and the user can be via facsimile, e-mail, or voice callback. Callback can occur if the user's phone number is stored in the customer database 32 or is found in the text of the facsimile.

[0031] E-mails that are sent by a user using a client machine, e.g. client machine 22, are handled much like a facsimile, except that OCR does not need to take place. However, ANI is not available. The sender's E-mail address can be used as an equivalent. The call distribution server 30 selects an agent 38, 40, 42, 44, or 46 to which to forward the e-mail based on rules defined in the rules engine 34. Further communication between the selected agent and the user can be via facsimile, e-mail, or voice callback. Callback can occur if the user's phone number is stored in the customer database 32 or is found in the contents of the E-mail.

[0032] A user of a client machine has the option of requesting collaboration. This is illustrated in FIG. 1 by client machine 24. Collaboration is known in the art, and can include a chat session, but also includes the ability for the agent 38, 40, 42, 44, or 46 to “guide” the user through various web sites in real-time. With web collaboration, no ANI is available. The user's e-mail address may be obtained by the server 30 by standard web “cookie” files stored on the user's client machine 24, or by user entered information, or by user's IP address if fixed and not proxied through a firewall. Note that no user identification of any kind is required, but aids an agent in determining a user's needs. The call distribution server 30 selects an agent 38, 40, 42, 44, or 46 to which to forward the collaboration request based on rules defined in the rules engine 34. Further communication between the selected agent and the user will typically be by collaboration.

[0033] A user of a client machine has the option of requesting a chat session. This is illustrated in FIG. 1 by client machine 26. Chat is known in the art and chat rooms are available at web sites of on-line service providers such as America Online (™), for example. Much like, and often a part of collaboration, the user is able to request a real-time chat with an agent. This is also much like a voice call, simply using a different medium. The basic process is substantially similar.

[0034] A user of a client machine has the option of making a webphone call. This is illustrated in FIG. 1 by client machine 28. An IP voice call from a webphone looks like other voice calls, i.e., PSTN converted to IP. ANI might be available, as may a URL (universal resource locator), an E-mail address, or an IP address of the user. The ANI or other available information is used by the automatic call distribution server 30 to aid in customer lookup, if the caller has a profile stored in the customer database 32. Users of the webphones communicate with human agents via voice conversation.

[0035] A user of a client machine has the option of placing a page. This is illustrated in FIG. 1 by pager 37. This mechanism would be less used than the others, but may be useful in a small, specific call center that responds to field technicians, for example. A field technician pages a generic number, and his or her request is routed to the first available appropriate agent 38, 40, 42, 44, or 46 by the call distribution server 30 to return the call or otherwise respond to the page. The call distribution server 30 selects the agent 38, 40, 42, 44, or 46 based on rules defined in the rules engine 34. Further communication between the selected agent and the user may be by voice callback, facsimile, or page. A facsimile or page can occur if the user's facsimile or pager number is stored in customer database or found within the pager message.

[0036] As previously mentioned, various hardware configurations could be employed instead of the specific configuration illustrated in FIG. 1. For example, FIG. 1 shows a large number of components to illustrate a large number of alternative embodiments possible. The invention can be implemented with various subsets or supersets of the components shown in FIG. 1.

[0037] FIG. 2 illustrates logic performed by a server, such as the server 30, in one embodiment of the invention. The logic (hereinafter referred to as “Soft-ACD”) can be implemented in computer program code embodied in a computer readable medium, such as a hard drive of a server, or embodied in a carrier wave transmitted to a server, such as the server 30 alone or in combination with other servers, or another server. In one embodiment, the logic is completely or partially embodied in discrete logic components or in one or more microprocessors instead of in software.

[0038] More particularly, FIG. 2 illustrates generally how the call distribution server 30 locates a specific agent to handle an incoming request, e.g. from a phone 14 or 28.

[0039] Prior art automatic call distribution systems typically maintain state, or know about all agents and what they are doing at any given time. This centralizes capability and limits scalability and flexibility. In contrast, the call distribution server 30 does not need to maintain state (though it can for statistical purposes). The call distribution server 30 instead queries the agents 38, 40, 42, 44, and 46 in real-time to determine their status and availability. This process is generally used regardless of whether the client machine is an e-mail client 22, a web collaboration client 24, a chat client 26, a web phone 28, or a PSTN phone 14 or a facsimile machine 16. The determination of which agent to use for a specific situation is performed by the rules engine 34. In one embodiment, the rules engine 34 is a conventional rules processing component. The rules engine 34 can use an inference engine, or simple sequential logic. Rules engines are known in the art and are described, for example, in U.S. Pat. No. 5,913,061 to Gupta et al., and in U.S. Pat. No. 5,933,816 to Zeanah et al., both of which are incorporated herein by reference.

[0040] The Soft-ACD uses publish/subscribe technology. More particularly, in one embodiment, publish/subscribe software is installed on the server 30. Publish/subscribe software is known in the art for other applications. See, for example, U.S. Pat. No. 5,913,061 to Gupta et al., which is incorporated herein by reference. Publish/subscribe software that is employed, in one embodiment, is TIB/Rendezvous™ software available from TIBCO of Palo Alto, Calif., which is described in U.S. Pat. Nos. 5,557,798, 5,257,369, and 5,187,787 to Skeen et al., all of which are incorporated herein by reference. In the embodiment shown in FIG. 2, agents “subscribe” to a set of skills such as language (English, French, Spanish, German, etc.) product (home electronics, appliances, music, computers, finance, returns, etc.), customer class (standard, silver, gold, etc.) or any other business defined skills. The rule-set defines the appropriate skills for a given user (e.g., based on previous contact) or media contact type (e-mail, voice call, chat, etc.). These skills can be updated by the agents in real time.

[0041] In steps S1, S2, and S3 (FIG. 2), the Soft-ACD generally uses any user identification available, such as ANI, e-mail address, phone number, user entered info, content of contact (e-mail content, for example) or other in order to perform a customer lookup.

[0042] More particularly, in the embodiment of FIG. 2, in step S1, the Soft-ACD 30 invokes the rules engine 34 and passes to the rules engine 34 any ID information available (e.g., ANI may be the first preference if multiple forms of information are available).

[0043] In step S2, the rules engine 34 finds customer information, if available, in the customer database 32 based on the ID information passed by the Soft-ACD. If no identification is available or the user is not in the database, the rules engine 34 uses a default mechanism, typically the first agent available. In one embodiment, depending on the incoming media type, (e.g. e-mail), a request may go to a predefined group of agents that typically handle request for that communications media or contact type (e.g., e-mail).

[0044] In step S3, customer information, if available, is returned to the rules engine.

[0045] In step S4, the rules engine 34 selects an agent or group of agents who have the required skills for the user and who are appropriate for the media type with which the user initiated the request.

[0046] The agent or group of agents is returned to the Soft-ACD in step S5.

[0047] After the skill(s) required are determined for a given user or media contact type, the Soft-ACD in step S6 broadcasts an event to the selected agent or group of agents stating that a user of a certain media contact type (chat, e-mail, voice call, etc.) is available needing this skill(s).

[0048] Because one or more agents with these skills (or all) may be busy, only currently available agents respond, in step S7, and there may be multiple available agents responding.

[0049] The Soft-ACD waits for a predetermined amount of time (typically no more than a few hundred milliseconds) and then selects, in step S8, one of the available responding agents based on rules in the rules engine 34 (e.g., first come, round robin, random, etc.).

[0050] The selected agent information is passed to a media handler or call treatment server 58, which may be separate from any of the servers shown in FIG. 1, in step S9.

[0051] The media handler passes the session or event to the selected .agent in step S10. If no agent is available, the user may be “parked” or may need to simply retry.

[0052] More particularly, the call treatment provided by the media handler provides interactive voice response, (music on hold, pushed ads, etc.) and is a separate service(s) depending on the media type. It is a hand-off point if the Soft-ACD cannot find an available agent. For example, if a chat request comes in from a web browser and no agents are available, in one embodiment, the Soft-ACD sends the request to the media handler. The media handler for chat, in one embodiment, pushes information via chat to the user automatically; e.g. chat-on-hold, or passes the user to “browser-on-hold” where it pushes HTML-based advertising until an agent becomes available. This is analogous to putting a voice caller in queue and playing music or ads. In the case of non-real time requests, such as e-mail or facsimile requests, this is really not needed and the e-mail (or fax converted to e-mail) simply goes to an agent or an agent group's e-mail box, because the user is not waiting for an immediate response. Alternatively, the media handler waits some period of time, such as a few seconds, and retries, and after a certain number of failed attempts puts the contact event into an agent's e-mail inbox to be processed as time allows.

[0053] If the request is a real-time request, such as a voice call, the call can be moved (parked) to an IVR (Interactive Voice Response), or music-on-hold. If the request is in the form of a collaboration or chat request, web-based advertising is provided, in one embodiment. Alternatively, if the request is a chat request, the user, in one embodiment, is moved to a “chat” broadcast of current events, news, advertising, etc.

[0054] In one embodiment, an auto-response is also returned, giving a best-guess response based on content of the contact. For example, the e-mail content or OCR converted text of a facsimile, in one embodiment, is analyzed, compared against a frequently asked questions database, and the most appropriate response e-mailed back to the user. In one embodiment, the rules engine 34 chooses this mechanism for all first-time e-mail from a given user or regarding a given question, and only routes the e-mail to a live agent on the second request.

[0055] FIG. 3 illustrates logic, in one embodiment of the invention, for handling a request by a user for a chat session. The logic can be implemented in computer program code embodied in a computer readable medium, such as a hard drive of a server, or embodied in a carrier wave transmitted to a server. In one embodiment, the logic is completely or partially embodied in discrete logic components or in one or more microprocessors instead of in software.

[0056] In step S11, a user requests a chat session.

[0057] In step S12, the web server 20 invokes chat software.

[0058] In step S13, chat asks the Soft-ACD for a target agent to handle the chat.

[0059] In step S14, the Soft-ACD invokes the rules engine 34.

[0060] In step S15, the rules engine uses an e-mail address, cookie, or user entered information for customer lookup and determines an appropriate group of agents with appropriate skills. A specific agent from that group is then determined via a broadcast request for availability. (FIG. 3 is simplified compared with FIG. 2 in that step S15 is illustrated as a single step while in FIG. 2, steps S2, S3, S4, S5, S6 and S7 are illustrated).

[0061] In steps S16, S17, and S18 a selection of the agent is returned to the server 20.

[0062] In step S19, chat routes the chat session to the selected agent.

[0063] FIG. 4 illustrates logic, in one embodiment of the invention, for handling a request by a user for a web collaboration session. The logic can be implemented in computer program code embodied in a computer readable medium, such as a hard drive of a server, or embodied in a carrier wave transmitted to a server. In one embodiment, the logic is completely or partially embodied in discrete logic components or in one or more microprocessors instead of in software.

[0064] In step S20, a user requests a web collaboration.

[0065] In step S21, the web server 20 invokes collaboration software.

[0066] In step S22, collaboration asks the Soft-ACD for a target agent to handle the collaboration.

[0067] In step S23, the Soft-ACD invokes the rules engine 34.

[0068] In step S24, the rules engine uses an e-mail address, cookie, or URL (or IP address) trail for customer lookup and determines an appropriate group of agents with appropriate skills. A specific agent from that group is then determined via a broadcast request for availability. (FIG. 4 is simplified compared with FIG. 2 in that step S24 is illustrated as a single step while in FIG. 2, steps S2, S3, S4, S5, S6 and S7 are illustrated).

[0069] In steps S25, S26, and S27 a selection of the agent is returned to the server 20.

[0070] In step S28, collaboration routes a chat session to the selected agent.

[0071] FIG. 5 illustrates logic, in one embodiment of the invention, for handling an e-mail request by a user. The logic can be implemented in computer program code embodied in a computer readable medium, such as a hard drive of a server, or embodied in a carrier wave transmitted to a server. In one embodiment, the logic is completely or partially embodied in discrete logic components or in one or more microprocessors instead of in software.

[0072] In step S29, a user sends e-mail from a client machine.

[0073] In step S30, the web server 20 proxies the e-mail to the unified messaging server 36.

[0074] In step S31, the unified messaging server asks the Soft-ACD for a target.

[0075] In step S32, the Soft-ACD invokes the rules engine 34.

[0076] In step S33, the rules use the return e-mail address or e-mail text content to look up the user in the customer database 32, and determine the appropriate group of agents with appropriate skills. A specific agent from that group is then determined via a broadcast request for availability. (FIG. 5 is simplified compared with FIG. 2 in that step S33 is illustrated as a single step while in FIG. 2, steps S2, S3, S4, S5, S6 and S7 are illustrated).

[0077] In steps S34, S35, and S36 a selection of the agent is returned to the server 36.

[0078] In step S37, unified messaging routes the e-mail to the selected agent.

[0079] Note that the call distribution server 30 does not need to maintain agent state, but instead queries agent state in real-time using publish/subscribe technology. This allows multiple copies of the Soft-ACD software or server to exist at any given instance, (including redundant or geographic fail-over copies) allows the agents to change skills in real-time, and eliminates the need to login/logoff of the ACD service. This provides scalability and flexibility, and keeps the complexity of the Soft-ACD to a minimum. Combined with a generic rules engine, the Soft-ACD user (ACD customer) has added flexibility to determine how contacts (e-mail, Voice, Chat, etc.) are handled. The Soft-ACD is a process that can run on any general purpose platform costing as little as a few thousand dollars, and can run anywhere, including in the network (managed by a service provider) or on a corporation's premises.

[0080] A traditional ACD is a dedicated, expensive piece of hardware often costing hundreds of thousands of dollars, and having to reside at each customer's premise (in the customer's facility or data center). Therefore, the Soft-ACD can provide a cost reduction measuring 2-3 orders of magnitude or more, even for a handful of customers, while increasing flexibility manifold. One or more instances of the Soft-ACD can be created for each customer at an incremental cost approaching a few hundred dollars or less, depending on load requirements.

[0081] Although certain software processes have been illustrated as being implemented in certain servers, the processes could be distributed over multiple servers, centralized in a single server, or implemented by one or more microprocessors or discrete logic components without departing from the invention. The protection sought is not to be limited to the disclosed embodiments, which are given by way of example only, but instead is to be limited only by the scope of the appended claims as properly interpreted in accordance with the doctrine of equivalents.