CallCoordinator call management improves telephone efficiency, helps your agents serve your clients better, and saves time for your agents.
When someone calls your company, an agent can answer questions immediately because the business application panel appropriate to the call is already displayed on the terminal screen. The agent is ready for productive, efficient work the minute the telephone rings.
If the caller is transferred to another agent, the transaction environment on the terminal panel can be transferred with the call. The second agent doesn't waste time accessing the caller's computer record or irritate the caller by asking the caller to repeat information. The caller's record appears on the second agent's terminal screen as the telephone rings.
Callers appreciate being asked only once to supply their information, and you save money by reducing the length of the call.
Figure 6. CallCoordinator improves service to those calling in.
This chapter describes the primary features of CallCoordinator:
In a call center, different types of calls require different agent services. CallCoordinator knows which telephone line a call arrives on, and, if available, which number the caller dialed and/or which telephone number the customer is calling from. Based on this call information, CallCoordinator selects and starts a transaction on the receiving agent's terminal -- as the telephone rings.
For example, a catalog order center can take calls for many different catalog companies. A different application panel appears on an agent's terminal screen for each catalog-specific number that the customer can dial.
You can determine what transaction to start and display according to:
The application panel for the transaction can be filled automatically with the customer's data if you also use Automatic Number Identification (ANI).
The Intelligent Answering feature works differently based on the support provided by each telephone switch. Switches from different vendors send differing call event messages. Refer to your IBM representative for information about the messages the switch sends that affect Intelligent Answering.
If you subscribe to DNIS from your long distance carrier, the central office switch passes along information about the digits a caller dialed. CallCoordinator can use the 1 to 32 digits of DNIS information to determine which panel to display for an agent.
If you publish different DNIS numbers for different departments within your company, CallCoordinator can know which department a caller is trying to reach, even though the calls to all departments come in on the same trunk.
If Customer A dials the DNIS number for the Sales Department, CallCoordinator starts the Sales Department transaction for the answering agent.
Figure 7. A CallCoordinator agent answers a call for the Sales Department.
If Customer B dials the DNIS number for the Shipping Department, CallCoordinator starts the Shipping Department transaction for the answering agent.
Figure 8. A CallCoordinator agent answers a call for the Shipping Department.
Traditionally, when a company had two or three different numbers for two or three different services, the company dedicated trunk groups to each service. Recently, DNIS has been used to tell the difference between services, while allowing callers trying to reach different numbers to share an incoming trunk group.
For example, if your company is a savings and loan company, you might publish one toll-free number for auto loans, another for home loans, and yet another for financial services.
Even though the auto loans, home loans, and financial services departments each have different numbers, you use one trunk group and as many groups of agents as required to take all incoming calls. CallCoordinator gets and uses DNIS information about the number the caller originally dials.
You can use DNIS and CallCoordinator data collection for other purposes. You can publish different numbers in different area newspapers, for example, and track each area's response by collecting information from DNIS calls.
You can configure CallCoordinator to display a panel based on the ID of the trunk that received the call.
Your company can publish different telephone numbers for different departments. For example, a travel agency can advertise cruise specials with one telephone number and advertise airline discounts with another telephone number. The calls for these two numbers can come in on separate trunks, each with a unique trunk ID.
Figure 9. CallCoordinator starts different transactions for different trunk IDs.
If your switch sends trunk identification to the host computer, and your call center is organized in trunk groups, you could use trunk IDs for Intelligent Answering.
When a customer calls your organization, the customer might have dialed one of several different telephone numbers. For example, there might be one for sales, another for shipping, and another for accounts receivable. All of these numbers can come in on the same trunk in your switch to the dialed pilot number.
A pilot number is associated with a particular group or department. It doesn't actually ring a telephone. It automatically forwards the call to an agent who is a member of the group. Different pilot numbers are used for different agent groups.
For Intelligent Answering, the host computer can access the transaction associated with the pilot number. For example, the pilot number for cruise specials is 1111 and the pilot number for airline discounts is 1113. When a customer calls 1111, the agent who receives the call sees the transaction for cruise information.
Figure 10. CallCoordinator starts different transactions for different pilot numbers.
If your call center uses automatic call distribution (ACD), hunt, or distribution groups, you could use pilot numbers for Intelligent Answering.
You can determine what application transactions should be started for individual extension numbers. For example, if an agent using extension 8967 always handles loan rate inquiries, the Loan Rate Menu is displayed with each incoming call for that extension.
Figure 11. CallCoordinator starts a specified transaction for an extension number.
This is effective in call centers where individual agents or specialists always handle the same kind of call. For example, you might want your preferred customers to use the extension number of a particular agent.
You can display data for a caller based on ANI information, if this service is available from your telephone company. With ANI service, CallCoordinator can get the billable telephone number, when provided, of the telephone that the caller is using to make the call. This number is passed to your application transaction, which can match it to the calling customer's record, and then display the caller's information. The agent has access to the customer's record without typing anything or asking the caller for information.
Your programmer can customize your business application program to match the telephone number (the number of the telephone that the caller is using) to the customer's name, account number, and account information. The result? This information appears on the agent's terminal screen.
Figure 12. CallCoordinator gives the agent immediate access to the Customer's Record.
Of course, this works only if the customer is calling from the ANI telephone number that you have defined in your record. Your application programmer can customize your business application program so that your agents can update the ANI telephone number for a customer during a call.
Using ANI with CallCoordinator, you can get reports showing the calling location: the address where the telephone is located. This can be useful for measuring or analyzing regional responses to an advertising or information campaign. For example, you can track who responded and called an advertised toll-free number, based on ANI information that reveals the caller's location.
The Coordinated Voice and Data Transfer feature improves customer service and agent productivity by ensuring that information is collected from the caller only once. The first agent enters customer information into the system. When the first agent transfers the call, CallCoordinator displays the current customer information at the receiving agent's terminal.
Similarly, IVRs can prompt the callers for information. Callers can enter data on their telephone keypad. The system updates the transaction. If the IVR transfers the call, the agent receives the updated transaction and sees the information immediately.
To make transferring faster for your agents, your application programmer can use a CallCoordinator API to provide your agents with system dialing. Your agents then press a function key rather than dial the second agent's number on the telephone keypad.
The Coordinated Voice and Data Transfer feature works differently depending on how your switch works. Some switches require the computer to start the transfer, but others allow it to be started from the telephone keypad. If your switch does not send transfer messages, you can still use the Coordinated Voice and Data Transfer feature. CallCoordinator provides an API that causes the host computer to initiate the transfer. The Planning section of the CallPath CallCoordinator/CICS System Management Guide and the CallPath CallCoordinator/CICS Application Programming Guide describe the Host-Initiated Telephony API.
Depending on the business procedures for your call center, you might want the same application panel or a different application panel transferred to the second agent. Here are two examples of application panel transfer:
Let's look at an example for a stock brokerage.
A customer calls to make an account inquiry. The agent (or IVR) requests the customer's record on the computer terminal. After hearing the individual stock prices, the customer decides to buy more stock. The agent transfers the customer to another department for placing orders. The transaction is sent to the terminal of the second agent when the call is transferred.
The second agent receives the call and sees the caller's name and account information. If the first agent had entered more information, such as the caller's new address for receiving statements, the second agent sees this, too. CallCoordinator transfers all this information with the call.
Figure 13. Data already collected transfers to the next agent.
The caller gets faster service, because the agent immediately sees the caller's information. The second agent saves time when the first agent or IVR has already entered information in the transaction.
Let's use an insurance company as an example of a call center that needs to display a different application panel for an agent receiving a transferred call. In an insurance company, some agents take calls for automobile insurance, other agents take home insurance calls, and others take calls about life insurance.
After a caller has talked with an automobile insurance representative, the caller might want to discuss his or her home insurance coverage. The auto insurance agent transfers the caller to a home insurance agent, and CallCoordinator displays a home insurance application panel at the home insurance agent's terminal.
If the application has been customized, the home insurance application panel can contain any customer information, such as new address or telephone number, that the auto insurance agent just collected and entered.
Figure 14. CallCoordinator can display a different transaction on the transferred-to terminal.
There are several ways your CICS application programmer can customize CallCoordinator to display a different transaction on a call transfer. The Planning section of the CallPath CallCoordinator/CICS System Management Guide describes the choices for you to make. The CallPath CallCoordinator/CICS Application Programming Guide gives instructions for these methods.
The Consultation and Conference feature helps you use your staff's varying levels of experience and expertise efficiently. It's difficult, if not impossible, to train every agent to handle every call situation. An agent might need to consult with a supervisor or trained specialist during a call.
In a consultation, the caller is on hold while the agent speaks with another party. In a conference, the caller is included in the conversation.
As with the Coordinated Voice and Data Transfer feature, the Consultation and Conference feature works differently depending on how your switch works.
The second person can more quickly help the agent because CallCoordinator transfers the application transaction that the first agent was using so the second agent can see the problem. When the first agent reconnects with the customer, the transaction control returns from the second agent to the first agent.
For example, a caller asks a new agent to estimate the cost of complicated insurance coverage. The agent is unsure about the estimate and wants to verify it before giving it to the caller. Knowing that customers prefer to talk with only one person, the agent asks the customer to hold, instead of transferring the customer to another agent.
The new agent calls an experienced agent to ask for advice, while putting the caller on hold.
Note: Depending on your particular switch, the following example may be the way the Consultation feature works.
The experienced agent receives the application panel with the customer's information from the new agent's terminal. The experienced agent reviews the work, finds an error in the second column, and corrects it. The experienced agent hangs up and the revised application panel appears on the new agent's terminal screen. The new agent reconnects with the caller and gives the caller the estimate.
As this example shows, Consultation works well for continued training. The new agent follows the transaction through and completes the call, rather than making the transfer and turning the call over to another agent.
Consultation also works well if you have different levels of authority among agents or protected fields on an application panel. For example, suppose a caller asks an agent for a higher credit limit than normal and the agent does not have the authority to grant it. The agent can quickly transfer the transaction-in-progress to a manager who can make the credit decision and update the transaction. The agent completes the call while the manager goes on to other work.
Conference calls include the caller and more than one agent. CallCoordinator agents who are added to the conference can request a copy of the first agent's current application panel. The agents involved in a conference call can view the same panel while discussing a problem.
Only the first agent has control of the application transaction. If the first agent changes the transaction, the other agents can request a new copy of the application panel so that they can see the change.
How the agent requests a copy of the panel depends on how your application programmer uses the CallCoordinator API provided for this feature. The agent might request the copy by pressing a function key or by selecting an option on a panel. The CallPath CallCoordinator/CICS Application Programming Guide gives your programmers instructions for copying a panel onto additional terminal screens.
Agents participating in a conference call can be at the same or different sites, as long as they all can access the same host computer application and use the Transfer Load Balancing feature. See "Conferencing Across Switches".
This feature allows you to route calls, or redirect them, depending on some caller-related information. The Host-based Routing feature of CallCoordinator allows your host-based application to make a redirection decision, and send instructions back to your switch.
The host-based application can instruct the switch to redirect the call to a specific ACD group, or agent. The redirection decision could be based on caller-related information such as ANI, DNIS, late payments, VIP status, call back record or any other application-based trigger mechanism.
The application can alternatively return control to the switch so that the switch routing program continues with its normal routing decisions.
The Host_Initiated Telephony API (HIT API) has been enhanced to allow you to use Host-based routing. Details of the HIT API, and all the CallCoordinator APIs are in the CallPath CallCoordinator/CICS Application Programming Guide
Note: In order to use the Host-based Routing feature, your switch must be capable of requesting routing instructions from a host-based application. This is usually included as part of the queued call routing steps.
You might have a number of customers who are "GoldCard" holders, meaning that they have an especially high credit limit, or that they are frequent users of a particular service and have been awarded VIP status. When a call is received from a GoldCard holder you may want to have the call answered by a special group of agents, regardless of which department or service the customer is calling.
A host-based application uses some caller-related information to identify the caller as a GoldCard holder by reference to the customer data base. The application then sends a rerouting instruction to the switch so that the caller is connected to a "GoldCard Agent".
Figure 15. A host-based application can re-route a call.
You can transfer peak work loads among your ACD agent groups as needed, whether they are all located in one building or at different sites on different switches. CallCoordinator's Transfer Load Balancing feature finds the least-busy agent group of a particular type.
With agents in different time zones, the peak call hours occur at different times. You can use Transfer Load Balancing to smooth out the peaks in agent activity. This can have a positive effect on staffing at the various locations.
Figure 16. Smooth out peak call hours across time zones
For example, if there is a bad snowstorm in Syracuse, New York, and only half the Syracuse agents come into work, call queues for Syracuse agents would become large. CallCoordinator could locate agent groups in other cities whose queues are small. The extra calls could be transferred to agents in other locations, such as Chicago and Los Angeles.
In order to use all of the functionality of the Transfer Load Balancing feature, your switch must support the following capability:
When an CallCoordinator agent or IVR requires a call transfer to an agent in another group, they request the number of the least-busy agent group for a specific function. The agent types a key word or name for the function, such as SALES, CallCoordinator looks for agent groups with that name on every switch in the network. Transfer Load Balancing displays the number for the group that is least busy.
CallCoordinator uses an algorithm to find the least-busy agent group. Your installer enters information on CallCoordinator configuration panels such as:
A stream of call-progress event messages from the switch about each call informs CallCoordinator where every incoming call is and how many calls are waiting in each agent group queue. This way, CallCoordinator knows which agent group is most busy and which is least busy.
When an agent asks for the number of the least-busy agent group of a particular type, CallCoordinator displays the number on the requesting agent's terminal screen. It also gives the agent a backup number, in case there is a problem transferring to the first number.
To transfer a call to the target group, the agent can either dial the number on the telephone or request host dialing if this capability has been implemented. The Coordinated Voice and Data Transfer feature ensures that the second agent receives the transaction that was started for the first agent.
You can train an IVR to use Transfer Load Balancing. An IVR can send the same requests and receive the same responses from CallCoordinator as an agent.
For example, a customer might call a bank to verify a checking account balance and inquire about a credit card balance. After giving the customer the balances, the IVR prompts the customer to find out if the customer wants to speak to an agent, and if so, what type of agent. If the customer wants to increase his/her credit card limit, he/she asks for a credit counselor. CallCoordinator finds the least-busy credit agent group.
Using IVRs with Transfer Load Balancing is particularly effective for a company with call centers in different time zones. If the IVR works 24 hours a day but the agents do not, the IVR can transfer the caller to the least-busy agent group in another time zone.
CallCoordinator comes with a sophisticated algorithm for assisting you in load balancing the calls in your call center. Also, the CallPath CallCoordinator/CICS Application Programming Guide gives instructions for your application programmer on how to modify the CallCoordinator Transfer Load Balancing module if your call center needs to use a different algorithm.
If your switch does not have the ACD feature that reports call queueing, you cannot use Transfer Load Balancing to find the least-busy group. However, if your switch has the inter-switch tracking capability, you can use Transfer Load Balancing to extend the use of the Coordinated Voice and Data Transfer feature to handle:
With Transfer Load Balancing, an agent can:
The sections below describe how an agent can use Transfer Load Balancing to transfer voice and data across switches and make conference calls across switches.
Agents can transfer a call and the accompanying application panel to agent groups on different switches in your network. To do this, the agent requests a number for an ACD group. CallCoordinator reserves a number that will do the inter-switch tracking to the number of the ACD group and sends this reserved number to the agent's terminal screen.
When the agent initiates a transfer and dials the reserved number, the switch forwards to the ACD group's inter-switch tracking number, and the next available agent answers the call. CallCoordinator transfers the application panel and control of the panel to the second agent.
Agents can hold conference calls with agents who are on different switches in your network. Because Transfer Load Balancing works with supported switches in a network, the added party in a conference call can request a copy of the application panel, even though the added party is on a different switch. Without Transfer Load Balancing, the added party in a conference call between switches cannot request a copy of the application panel.
The agent initiates a transfer after requesting a Transfer Load Balancing number for the specific ACD group by entering the ACD group identifier. When the agent on another switch answers the call, that agent requests a copy of the application panel. After talking with the second agent, the first agent includes the customer in the conference call by pressing the conference button.
When a call arrives at a monitored resource, the switch sends messages to the host computer (called call-progress event messages) about what happens to the progress of that call. The host computer sends requests to the switch, such as when CallCoordinator wants the switch to transfer a call. CallCoordinator collects this data to provide various reports based on the data. If errors occur, CallCoordinator also collects information about error conditions.
Calls can come into one switch and be routed to a different switch. CallCoordinator collects data for this too, if both switches are configured to communicate with CallCoordinator.
You can use CallCoordinator to produce reports about call patterns. You can analyze agent and call center effectiveness and relate call patterns to business activity.
CallCoordinator saves records with information from every call-progress event message that the host computer receives and every request that the host computer sends to the switch. The records reside in the Management Information System (MIS) Log file. This file keeps all data for a call's entire history.
With CallCoordinator, you can generate reports with information that you cannot get from your switch alone. But switches from different vendors provide different information. The following information is provided by most switches. If your switch provides the information, CallCoordinator saves the information in the MIS Log:
CallCoordinator keeps a detailed log of call-progress event messages for each telephony session and for each party in a call. CallCoordinator continues to track a call even when the caller transfers to another CallCoordinator switch, when the parties in a call change, and when calls are combined. This is also true if the caller's initial contact is with an IVR.
To collect business data related to a call, your application programmers can modify your business applications to get CallCoordinator data, to add an account number to a call record, or to add business records to the MIS Log file. CallCoordinator provides the Write to MIS Record API to write the records into the MIS Log. Using other APIs, your programmers can get data from CallCoordinator such as the following:
You can use the Write to MIS Record API to record business-related events and application-related data in the MIS Log. This one file can contain both telephony and business-related data to be printed in reports. Such reports could be quantitative sales statistics, evaluation of sales methods, advertising campaigns, or caller access patterns.
For example, to determine costs associated with making a sale, use the Write to MIS Record API to write a record to the MIS Log from the business application. The record might contain the identifying control number (such as the policy number for insurance or account number), the item purchased, and the selling price. To collect all data associated with a telephony session, your programmer can include call index data fields in these records by using the Inquire Call Data API to get the index data.
As another example, you can use an identifying control number (policy account number) to associate business records with telephony records, using the Set Control Number API. You can then produce a report from the MIS Log that relates telephone activity and business data with a specific account.
CallCoordinator provides a Call Analysis Program that collects MIS Log data and generates a file called the Totals Report. You can print this file as is. Or, you can use the file as input to a spreadsheet program or a database program to analyze your call center operation. The Call Analysis Program is an example program that shows how to select the information you need from the MIS Log for a specific purpose.
The Call Analysis Program calculates the following for each call:
CallCoordinator provides the job control language (JCL) to extract and print data for the following sample reports:
The CallPath CallCoordinator/CICS Application Programming Guide describes the JCL and print programs for these reports, which can be used as examples. Or, your programmers can use a report generator to organize the records in the MIS Log and print in whatever format you want. Your programmer can run a report generator to search and sort data to get reports such as these:You can get reports that analyze call patterns, correlate call activity with application activity, or show how much business your company did during calls. You can also target selected caller accounts. The CallPath CallCoordinator/CICS Application Programming Guide shows programmers how to get this information.
Because CallCoordinator collects both switch and host computer data in one log, your programmers can obtain reports that relate telephone activity to business activities. If your company subscribes to ANI, CallCoordinator receives the billable telephone number a calling party called from. With this information, you can pinpoint the geographic location of the caller. This information is helpful in analyzing geographic response to an advertising campaign.
Or, you can use ANI information to collect a database of callers' telephone numbers from the MIS Log and print out a report of potential customers to contact in future call campaigns.
The ANI information also includes telephone numbers of callers on hold who hang up before an agent answers. These calls are referred to as abandoned calls. You can collect the telephone numbers for the abandoned calls in the MIS Log and print a separate report of telephone numbers for this group of callers. With this information, you can direct your agents to conduct a customer survey to find out why the callers abandoned the calls. The survey may indicate ways you can improve your customer service, and, therefore, increase your business.
In summary, this chapter has described the major features of CallCoordinator:
If you recognize any of the following situations for your call center, you can use CallCoordinator to improve your customer service, save agent time and network costs, and increase efficiency:
With CallCoordinator, an application panel appears automatically on a computer terminal when the telephone rings. Agents who handle incoming calls are immediately ready to work with information, update an account, or place an order.
If people who call in usually talk to a second agent, or if your agents frequently send callers to a different extension, CallCoordinator is for you.
For example, if your business is retail sales, customers might call to find out their credit balance. Then, if they have enough credit, they might want to transfer to the order department to make a purchase.
When the call transfers to an agent in the order department, CallCoordinator displays the current information about that customer on the order entry agent's terminal. The agent is ready to respond to the caller, quickly and efficiently.
If you have switches in more than one location, CallCoordinator can send the transaction that the first agent used to an agent attached to a different switch. CallCoordinator can transfer transactions and calls across networks, finding the least-busy agent group.
With CallCoordinator, you can run many different call centers in different locations as if they were all in the same building. CallCoordinator with Transfer Load Balancing lets agents send callers elsewhere -- even to another city in a different time zone.
If agents in your call center answer calls from people asking for different services, CallCoordinator can improve their ability to handle the call quickly and efficiently. Intelligent Answering provides an agent with the correct application panel for each call. From the application panel, the agent knows how to greet the caller and is ready to conduct business.
Use host-based routing to redirect those calls to the particular agents. The redirection of the calls is determined by a some caller-related information.
