Monitoring Call Center Applications with Application Response

Transcription

1 Monitoring Call Center Applications with Application Response Use ehealth Application Response to monitor and manage the performance of call center applications, such as desktop applications used by call center representatives and database applications that they reference during customer calls. With Application Response, you can find opportunities to optimize response time and identify and troubleshoot performance problems before they impact productivity. Application Response can monitor the end-user response times of the applications on which your call center representatives rely when responding to customer requests: their desktop applications, customer database applications, and others. It provides an end-to-end perspective of the representative s experience and offers a breakdown of response time into client time, network time, and server time, so you can identify which part of the infrastructure is causing performance problems. Benefits When you use Application Response and other ehealth components to manage the performance of call center applications, you can achieve the following benefits: 1. Improve the productivity of call center representatives by monitoring transaction response times to identify which transactions have the slowest response times and highest usage. Focus productivity improvements in these areas to achieve the greatest cost savings and to enhance customer satisfaction with faster service. 2. Monitor the performance impact of changes to your call center infrastructure. 3. Fix performance problems before they impact call center representatives and reduce productivity. Set response time thresholds that will generate alarms when performance begins to degrade, allowing problems to be fixed before response times reach unacceptable levels. 4. Diagnose performance problems quickly by determining which call center locations or groups are affected and isolating response problems to the client, the network, or the server. 5. Improve capacity planning by projecting new equipment needs based on historical trends in call center performance. Improve Call Center Productivity. Slow performance from call center applications results in low productivity, dissatisfied customers, and increased costs. Use Application Response to identify the slowest call center transactions, as well as transactions with the highest usage rates and the most network traffic. Then make changes to optimize the transactions that can have the biggest impacts on productivity. Monitor the Impact of Call Center Changes. When upgrading or modifying call center application software or its supporting infrastructure, use Application Response to monitor transaction response times before and after the change. This allows you to determine how much the change has degraded or improved performance. When developing new transactions, use Application Response to test response times and ensure that the transactions perform well before implementing them in the call center. Fix Performance Problems before Productivity Suffers. To maintain call center productivity, you need to know about performance problems with call center applications before they seriously impact response times and increase the length of each call. Use Application Response with Live Health to set thresholds that trigger alarms when performance begins to degrade. Live Health can automatically notify IT personnel when performance starts to decline, so they have time to identify and fix problems before the productivity of call center representatives is significantly affected. Diagnose Performance Problems Quickly. When Application Response identifies a performance problem with a call center application or transaction, you can easily determine whether the slowdown is due to the client, the network, or the server. This information allows you to quickly direct the efforts of your IT staff to the appropriate area. In addition, Application Response can

2 2 identify whether a problem is restricted to a particular user, group, or location. Drill-down reports provide additional troubleshooting details to investigate the source of the problem. With this information easily available, IT staff can improve the mean time to repair (MTTR) and keep your call center representatives productive with minimal disruption. Improve Capacity Planning. Application Response allows you to monitor the relationship between the call center activity level and average response time. As your call center operations expand to support more customers, you need to watch response time trends to determine how the increased workload is affecting application performance. By watching these trends, you can predict when you will need to add another application server or increase network bandwidth to accommodate the increase in activity. Application Response provides the data you need to justify capital expenditures and plan for growth. Value 1: Improve Call Center Productivity To improve the productivity of your call center staff, use Application Response to identify transactions that are slowest, have the highest usage rates, or generate the most network traffic. Examine what amount of response time is due to the client, the network, and the server. With this information, application developers can optimize the transactions that slow down call center operations. The resulting reductions in transaction response times will reduce call times and increase call rates. ehealth offers several standard reports for Application Response. In addition, you can export ehealth data to design custom reports that meet the specific needs of your organization. For example, the report in Figure 1 was created by exporting ASCII data from an ehealth group Trend report to a Microsoft Excel spreadsheet. This custom report provides a lot of information in an easy-to-analyze format for quick decision-making. For each monitored transaction, the sample report shows side-by-side response times (green bars) for the two call center locations, Avon and Dallas. This layout makes it easy to compare the average response times experienced Transaction name Locations Figure 1. A Custom Report using Application Response Data in a Spreadsheet

3 3 by call center representatives in each location. By scanning the sample report, you can quickly see that response times for all transactions in the Dallas call center are slightly slower than in Avon, pointing to a possible network issue. The yellow bars in the report show the performance goals for each transaction. They make it easy to compare actual response times with thresholds. For example, a glance at the sample report reveals that the first transaction, Customer Record, is well below threshold, and the third transaction,, is near threshold; these transactions are performing well. However, the second and fourth transactions, List Related and, are much slower than they should be; these transactions merit further investigation. To determine which transactions are used most often and critical to the productivity of your call center representatives, look at the Transaction Count for each transaction. Use this information, along with the other data, to help prioritize performance problems. For example, List Related and are both slow transactions, but the Transaction Count shows that is used more often than List Related, so should be investigated first. A Case Study: Optimizing Performance. Snow Insurance, Inc., a major insurance provider, uses Siebel Call Center to manage its customer service call center. The organization needs to maximize profit by minimizing call response time. To reduce overall call time, Sue, the call center manager, needs to ensure that all call center transactions complete within established thresholds. She needs to monitor current response times to see how they compare with their thresholds, and she wants to identify slow transactions that can be optimized to improve performance. An important consideration for Sue is performance for each call center location (Avon and Dallas). She wants to compare transaction response times by location, and, if one location is slower, determine the cause so that productivity can be improved. To achieve these goals, Sue generates the report shown in Figure 1. A glance at the report shows Sue that two of the monitored transactions exceed their thresholds by a significant amount, one is near threshold, and one is performing well. Of the two slowest transactions, the report indicates that List Related is performed infrequently in both locations. Therefore, Sue gives it a lower priority and plans to investigate the transaction first, due to its high frequency of use and slow response time. The report shows that, while the transaction is slow in both locations, the Dallas call center receives noticeably slower response time for this transaction than the Avon call center, and she wants to understand why. To learn more about response times for the transaction, Sue runs two ehealth At-a-Glance reports: one for Dallas and one for Avon. Figure 2 shows the At-a-Glance report for Dallas. Application CustService- Figure 2. Dallas At--a-Glance Report for the Transaction

4 4 The Dallas At-a-Glance report indicates that average response time for the transaction consists of a small amount of client time and significant amounts of network and server time. When Sue compares this report to the Avon At-a-Glance report, she sees that the Avon group experiences a similar level of server time but less network time. Sue also sees that, at both locations, the transaction involves many data transfers over the network, with several round trips per transaction. The Dallas location, however, shows a higher network round trip time than the Avon location. With this information, Sue asks the Call Center application developers to redesign the transaction to require less server time, perhaps by requiring less data and fewer round trips across the network. She also asks the network team to investigate and correct slow network connections for the Dallas office. When these optimizations are complete, Sue reruns the At-a-Glance reports for both call centers. The reports show that response times for the transaction for each call center are now similar, and that the average response time is close to the threshold. The representatives in both locations quickly report a noticeable improvement in the response time for transactions, and they are able to achieve faster call times as a result. Because Sue was able to use Application Response to identify the specific transaction and infrastructure areas that were slow, she eliminated guesswork and was able to direct resources to the appropriate areas to improve performance and productivity effectively. Train Call Center Representatives. To further improve call center productivity at Snow Insurance, Sue uses the Application Response Service Delivery report to understand how often customer service representatives are performing transactions that cause high network traffic, such as data retrievals. (Refer to Figure 3.) These high-traffic transactions not only cause slow response time for the user and increase total call time, they also congest the network, which affects response times for other representatives. After studying the report, Sue talked to the representatives to understand why and when they performed the high-traffic transactions. Her research revealed that representatives often requested an entire This transaction is performed often and generates high traffic. GetListPlan GetListPlan PlanBenefit PlanBenefit Figure 3. Finding High Traffic, High Usage Transactions customer record when they really only needed a small portion of the information. So Sue created database queries that requested smaller sets of information, trained the representatives to use them, and added the information to the training materials for new representatives. By training her staff to be more selective in the information that they requested and thus reducing the amount of data sent across the network, Sue was able to reduce overall call time by 5%. Adjust Staffing Levels. Sue also uses Application Response to help plan staffing levels at the Snow Insurance call centers. For each location, she runs an At-a-Glance report and looks at the Transactions Observed chart, which shows the number of transactions per minute over the specified time period. She looks for patterns to determine the busy times of the day, days of the week, and weeks of the year, based on the number of transactions performed in each call center location. She then uses this information when scheduling customer service representatives to ensure sufficient coverage. For example, the following chart clearly shows that Fridays are slow at this call center, so Sue schedules fewer representatives on Fridays. ServiceRequest ServiceRequest XallContacts XallContacts

5 5 Service Delivery Report Fridays are slow at the call center. Monitor Call Center Performance. To monitor the performance of her call center applications on a regular basis, Sue at Snow Insurance uses her custom report for basic information. The sample report in Figure 4 identifies a significant problem with the transaction, with average response times of 7 and 9 seconds. However, the report does not offer further information, such as how often it is exceeding the threshold, nor does it give clues about the source of the performance problem. 1 K 5 K Client Network Server Figure 4. Custom Report Shows Problems For more in-depth performance information, Sue runs the Application Response Service Delivery report. This report can include two pages: the first page compares performance for each monitored transaction (or application), and the second page compares performance at each location. (Figure 5 shows the first page of the report.) By examining the report regularly, Sue can look for small, incremental changes in performance that point to developing problems, such as a transaction that is beginning to exceed its threshold more often, or a location that is experiencing slower response times than other locations. Its graphical charts also provide clues about the source of performance problems K 2. K 3. K 1.7 K 1.9 K K K K K 14.6 K 58.1 M 12.3 K 29.7 M 6. K 21.2 M 3.8 K 3.4 K Figure 5. Service Delivery Report Shows More Detail Response/Limit. Sue looks at the first chart, Response/Limit, to look for developing problems. Each bar shows how well a transaction is meeting service levels. The red portion of a bar indicates the percentage of transactions that exceeded the defined service level. In the sample report, the second bar shows that only 1% of transactions exceeded their threshold; this transaction is performing well. Half of the fourth bar, however, is red; 5% of the transactions exceeded

6 6 the threshold, and the rest are near threshold. This transaction is experiencing performance problems. Average Response Time. The Average Response Time chart shows response times for the monitored transactions, with a breakdown into client time, network time, and server time. By glancing at this chart, Sue can quickly gauge response times for each transaction and determine which part of the infrastructure may be causing a slowdown. In the sample report, the Average Response Time chart shows that the first three transactions have fast response times and are performing well. The fourth bar, however, shows that the transaction has a slow average response time of 8 seconds, most of which is due to server time. Total Transaction Count. The Total Transaction Count chart shows how often each transaction was performed during the reporting period. It helps Sue to understand the relative importance of the other information in the report. For example, the sample report shows that the and transactions are performed most often. Performance problems with those transactions will therefore have a higher priority than problems with seldom-used transactions, because they will have greater impacts on call center productivity. Total Bytes Count. The Total Bytes Count chart shows the total number of incoming and outgoing bytes for each transaction during the reporting period. This metric is a measure of the network traffic generated by each transaction, which can contribute to slow response time. In the sample report, Sue can see that the problematic transaction generates a lot of network traffic. However, the Average Response Time chart indicates that network time is low but server time is high. From this information, Sue concludes that the network has enough bandwidth to accommodate the traffic, and she suspects that the application server is working too hard to fulfill requests from the application client. SLA Violations. The SLA Violations table ranks the monitored transactions based on their performance, with the worst performing transactions at the top of the list. It also provides numerical data to support the graphical charts in the report. Sue uses this data to confirm her understanding of the top performance problems in the call center. In the sample report, the transaction is ranked as the biggest performance problem, with 5% of transactions exceeding threshold. Conclusions from the Service Delivery Report. After examining the report in Figure 5, Sue decides to investigate the transaction and determine whether it sends too many requests to the application server, or whether the requests are handled inefficiently by the server. To start this investigation, she can run an At-a-Glance report to examine the numbers of incoming bytes, outgoing bytes, TCP connections, and round trips observed. This information will help her to understand how often the application client communicates with the application server during a transaction. Sue can then take advantage of seamless integration with other ehealth reports and tools to further troubleshoot the transaction and find ways to improve its performance. Reporting to Management. Sue can share the Service Delivery report with senior-level management when they ask for up-to-date information about call center performance. As with all ehealth reports, she can schedule Application Response reports to run on a regular basis (daily, weekly, and monthly) and automatically make these reports available to specified users using , a corporate Web portal, or the ehealth Web interface. Value 2: Monitor the Performance Impact of Call Center Changes The performance of the call center application needs to be stable and predictable regardless of changes to the software and its infrastructure. Unexpected changes in performance can dramatically affect the productivity of call center staff, increasing costs and reducing customer satisfaction. Use Application Response to monitor response times before and after a change to ensure acceptable service levels or to measure expected performance improvements. A Case Study: Call Center Software Requires Upgrade. When Siebel released an upgrade to its Call Center software, the IT staff at Snow Insurance wanted to check its impact on transaction response times on a test system before upgrading the software on the production system. First they ran their custom performance report to record the current response times of each transaction, as experienced by customer service representatives. The following report shows that response times for all transactions are within their thresholds.

7 7 server, the IT staff repeated the test: they performed sample transactions for another 48 hours and ran the custom report again to check response times. The report showed that response time for the call center software returned to its previous levels. The IT staff then felt confident about upgrading the production server and performed the upgrade. Before upgrading the software on the production call center server, the IT staff performed the upgrade on a test server. Then they performed sample transactions over a 48-hour period and ran the same report to compare response times before and after the change. The resulting report shows significantly slower response times after the software upgrade. To investigate the source of the increase in response time, the IT staff ran an At-a-Glance report for the test clients. The Average Response Observed chart shows the breakdown of response time into client, network, and server time. 9K 6K 3K This chart shows that the largest contributor to average response time is server time. The IT staff reviewed the upgrade release notes and learned that they need to tune server parameters to accommodate new software functionality. After they changed parameters on the test Value 3: Fix Performance Problems before Productivity Suffers To ensure fast service for callers and quick response time for the call center staff who help them, set up Application Response to monitor transaction response times and use Live Health to define performance thresholds for monitored transactions. As call center performance begins to degrade, Live Health can raise escalating alarms, giving you time to investigate and correct the problem before delays begin to impair call center productivity. A Case Study: Slow Response Threatens Productivity. Customer service representatives at Snow Insurance use Siebel Call Center to respond to customer questions, quote insurance rates, and perform status checks. They use Application Response to monitor four important transactions for the application: Customer Record, List Related,, and. Fast response time with the Call Center application allows representatives to serve more customers each day. Slow response time results in reduced productivity, low call rates, and dissatisfied customers. Receive Alarms Triggered by Thresholds. To ensure fast response time for customer service representatives, the IT staff uses Live Health to define a series of thresholds for Call Center transactions that escalate the problem as performance continues to degrade. For example, the Customer Record transaction is performed thousands of times every day and must be very fast, so its thresholds are defined as follows: Warning when response time exceeds 2. seconds Minor alarm when response time exceeds 2.5 seconds Major alarm when response time exceeds 3. seconds Critical alarm when response time exceeds 3.5 seconds

8 8 When Call Center performance approaches or exceeds a threshold, Live Health simultaneously displays these alarms in the Live Exceptions browser, a Live Status diagram, and an or pager message that is automatically sent to on-call IT personnel. These escalating alarms give the IT staff the time they need to recognize, troubleshoot, and repair the problem before significant delays occur. For example, the following is a sample that Live Health sends when response time is approaching a threshold. The indicates the client system, transaction, and application server involved. This information allows the IT staff to identify the problem area quickly, so they can further investigate and take appropriate action. From: NetHealth User [mailto:george@company.com] Sent: Thursday, December 4, 23 1:28 AM To: custserviceadmin@tuvw.com Subject: Alarm major Response Time approaching threshold; service alert inder-pc-callcenter--server2-ap ID: /4/23 1:23: 12/4/23 1:27:59 response Severity of alarm ehealth Event Data: Client Transaction Server [Severity]: major [Start Time]: 12/4/23 1:27:59 [Start Time(UTC)]: [Element Name]: inder-pc-callcenter--server2-ap [Rule Message]: Response Time approaching threshold [Tech Type]: response [Variable]: Avg. Response Time [Problem Start Time]: 12/4/23 1:23: [Problem Start Time(UTC)]: Determine the Scope of the Problem. When Live Health sends an alarm, the on-call IT staff member checks the Live Status diagram to understand the scope of the problem. The IT staff has configured Live Status to reflect the infrastructure of the Call Center application. With a quick glance at the diagram, the IT staff can determine whether an alarm indicates a problem for one or more groups or locations, servers, or network components. In this case, the Live Status diagram shows alarms for each of the monitored transactions for the Call Center application, as well as two server alarms. Because the transaction-related alarms appear for the first set of icons only, the IT staff can quickly see that users in one location (Avon) are having trouble. With the problem identified, they can proceed to diagnose the source of the problem, as described in the next section. Problems with all Call Center transactions for this location Servers Routers_Switches Problems with 2 servers Customer Service Call Center Router_Core Lan_Wan CustService Figure 6. Live Status Diagram for Call Center Application Value 4: Diagnose Problems Quickly When Application Response indicates a degradation in the performance of your call center application, you can take full advantage of ehealth diagnostic capabilities to quickly pinpoint the problem. Drill-down reports can identify whether the problem is due to the client, the network, or the server, and whether the problem is limited to a particular application, location, or user group. With this information, you can quickly direct the appropriate IT resources to investigate and resolve the issue, so that users are impacted as little as possible. Drill Down for Details. To continue the case study from the previous section, Live Health has alerted IT staff that the Call Center application is experiencing performance problems, affecting representatives in their Avon office. From the Live Status diagram (shown in Figure 6), an IT staff member right-clicks an Avon icon and drills down to an At-a-Glance report to investigate the problem for all customer service representatives at that location.

9 9 are active during this time and affected by the server slowdown. Servers Routers_Switches Router_Core Lan_Wan CustService In the At-a-Glance report, the Average Response Observed chart shows an increase in server response time for the past hour, pointing to a problem on the Call Center server. inder-pc-rs fler-pc-rs gray-pc-rs trist-w2k-rs 4.31 K 3.87 K 3.61 K 2.15 K K orden-pc-rs 1.82 K K 3K 2K 1K The Transactions Observed chart of the At-a-Glance report shows a corresponding change in application activity: the transaction rate began to decrease at the same time that the server response time began to increase. This performance problem is impacting the ability of Avon customer service representatives to answer calls Determine Who Is Affected. The At-a-Glance report shows average performance statistics for all Avon users. From the At-a-Glance report, an IT staff member drills down to a Top N report for a list of the Avon users who The Top N report shows that server response time is high for most users in the Avon office. This information leads the IT staff to conclude that the problem is not related directly to a specific user but is a problem with the server that services the Call Center application for the Avon office. Now that the IT staff has identified a problem in server response time for Avon users, they can use other ehealth products and reports to investigate the server to look for the source of the problem. For example, they can run a Health report for the Call Center servers to check for exceptions and situations to watch. They can also run an At-a-Glance report for the specific server to which the Avon users are connecting to look for the source of the problem. This seamless integration of ehealth reports and tools simplifies troubleshooting and provides an end-to-end solution for application performance management. Value 5: Improve Capacity Planning Application Response can help you perform capacity planning to support your call center infrastructure. With this information, you can plan ahead for upgrades to application servers, client systems, and network components to support the desired level of performance. Because Application Response identifies the infrastructure areas that are impacting call center performance, you can plan to use your capital budget where it is needed most. When you need to justify capital

10 1 expenditures, Application Response provides statistical analysis to back up your plans. A Case Study: Planning for Growth. The customer service center at Snow Insurance is growing and plans to add 2 new representatives each month over the next year. The IT staff needs to know whether and when they must add another Call Center application server to maintain service goals, and whether the network will require additional capacity to support the increase in network traffic. Look for Trends. To perform capacity planning with Application Response, the IT staff uses the group Trend report to examine average response time and the number of call center transactions over time. The following sample report shows that the number of transactions (green) has remained steady for the past several weeks, and that response time (red) is generally three seconds or less. 8K 6K 4K 2K To determine whether the increase in response time is due to the client, the network, or the server, the IT staff ran another group Trend report for two hours of a typical day. This report reveals that server response times have increased significantly. 5K 4K 4K 3K 2K 1K 3K 2K 1K Three months later, 2 new representatives per month have increased the number of transactions performed. The following report shows a slow but steady upward trend in response times. With this information, the IT staff made plans to add another application server to increase its capacity to support the new users. They will continue to monitor Call Center response time and watch for data that indicates the need for additional network capacity, as well.