Best Practices - Contact Center Data Collection

The purpose of Call Centre Best Practices is for managers to be able to improve the call centre productivity and efficiencies. Productivity and efficiency improvements begin with the agents. By following best practices for each application the call centre improvements will happen.  The best practices will help you run an effective inbound, outbound or blended call centre.

This is an enewsletter copy of the Best Practices for Agent Desktops.  Visit the Spectrum website or SlideShare for the full version.

Data collection is one of the key points to contact center reporting.  Prior to just going ahead and building your reports, investigate the data, the methods and the outcome of the collections.  By taking these few steps your contact center report will have more value to you and others that take advantage of the reports.

• Collect the data that will show you key information
• Use the right methods to collect the data
• Disregard data that has little value to the reports
• Security during data collection and new storage

With new technology we are able to collect a lot of data from almost any application we use in the contact center.  These applications are storing data that can be very helpful to the agent, supervisor and managers.  The challenge for the contact center is having that amount of data and knowing what should be captured for multi-channel reporting.

The data that is collected and added to the reporting should be data that is targeted to help resolve internal contact center challenges.  The challenges may be real time (calls waiting), daily (schedule adherence) or historical (working or non-working state time).  It is dependent upon the managers to determine the challenges and learn what data is associated with these challenges.

Data from multi-channel applications is available and some of the data is critical and some of it is nice to have at times.  The best practice for managers is to ignore some of the data on specific reports.  Target only the data that will help with the daily challenges in the call center.  Learn to ignore and not pay attention to nice to see data that will not resolve the problems.

Another way to look at the data collection for the reporting is to think about the goal for the report itself.  Now go into detail about what is necessary for you to see on that report to help you meet your goal.  Don’t be vague about the details go into specifics.  You need to be able to clearly state exactly the data you need to see not the category of the data you need.

The data could be real time, for the interval or for the day.  What data do you truly need on this report? If you need all three then create three tabs to this report which will show you the results for each time slot on a separate tab.

Using the right methods to collect the data will:

• Be more secure;
• Prevent other problems with the data source;
• Improve the end results of the report and
• Will be faster and more reliable.

A good example of using the right methods is with screen scraping (AKA data emulation).  A text file can be scraped and all of the data taken from the file and stored in a database.  If this file is a real time data file many problems can occur.

The software used to capture the report screen can write the text file to a location that could either be local to the primary software suite, or on a network share.  In either case, the software creating the file must have adequate permissions on the local machine, and network share to successfully create, modify and delete.  If the user account assigned changes for any reason, the method could be broken.

When screen scraping a unique starting point word and ending point word must exist.  This typically means creating a new report.  Now your system will have multiple reports running just so you can screen scrape the data.  Then if there is a request to capture new data the report has to be written again. Multiple reports running on some systems will slow the system down.

Very often when creating a text file from a screen capture, the program creating the file may be attempting to update the file at the same time another program is attempting to read the file.  Only one application can read / modify the file at a time, and although this happens quickly, these collisions do occur.  In most cases this simply means that the data will not be refreshed on this interval causing data to be stagnant until the next refresh, which increases the total refresh time. Another result is the data is not available so it will be captured as a blank.  The data may also be refreshed on part of the report but not on another part of the report.

This is an example of screen scraping and the real time report.  The blank rows and column are due to the data source and the screen scraping collision.  The data that is blank is due to the collision between the collection and refresh.  Instead of an integer the value is null and therefore voided.

Disregarding data that has little value to the report will improve the report refresh rate, make the reports smaller and less confusing and will improve the end result value.  There is the potential that the calculations will improve as well when certain data is left off of the report.

When building the report being able to ignore data that is not truly needed so your report will show you the cause or symptoms of the problems you are having in the call center.  Too much data on the report can be confusing and lead you down the wrong direction to problem solving.

Who is the audience for the report? The audience will help determine the right data that should be captured and displayed.  What do you need to see and what does an agent need to see? Are they the same, of course not therefore for the agent reports do not capture the same data only what is needed for them.

Security during data collection and storage is important.  Data that is collected should be done so that the data coming across the network and being stored is encrypted.  If the data is wide open anyone can see it and at a minimum visually obtain information.  Worst case someone can hack into the storage of the data and if it is not encrypted steal the data to be used against the business.  Data should always be encrypted when it is being transmitted and stored.

However, be aware that strict security measures can change data refresh rates and can block data collection altogether.  If the data collectors have to go through many gateway nodes (hops) these hops can slow down the process of data collection.  If the data collection is slowed to an extreme your data collection software may shutdown this collector to protect the software engine application from failing.  Most ACD platforms have this protection in place as well to prevent the ACD system failure because of report overload or security restrictions.

The amount of data on the report can require multiple reports running on the ACD.  Each ACD report that is functioning can cause multiple problems for the main server. 

1. Slow down the processor on the server as it maintains all activities.
2. Failure of the reports or causing the reports to shut down.  
3. Slow down the refresh rate of the reports.

Another problem that occurs is the poor quality of the reports.  Some employees build their own reports but do not do a good job.  Simple errors happen that make the report useless to the end user.  A math error which causes the report to fail and rather than deleting the report the employee will leave it as is and build another report.  Each report running will add work load to the processor.

On a regular basis your IT department should be checking the number of reports that are running and make sure they are accurate and being used and if not delete the report.  Reducing the amount of reports will improve processor power.

The process of collecting data for reporting needs to be done efficiently so as to ensure the reports are accurate and meet the needs of the users.  Following best practices on data collection will also help the ACD processor so it is able to function properly.

Spectrum is a leading provider of Unified Contact Center Reporting.  Contact Spectrum today to discuss best practices.  For more examples of reporting visit our website and the products page. http://www.specorp.com/products

Follow Spectrum Corporation:

• SlideShare
• LinkedIn
• Blog

Dan Boehm
VP Sales and Marketing
Spectrum
dboehm@specorp.com
+1 713 986 8839