![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
This article encapsulates what is required in a typical call management solution, the protocols available to solution designers, and how server-side technology plays a dominating role. Originally, I titled article "Implementing Web call management," but I soon realized that concentrating solely on the HTTP protocol ignores the functionality and scope offered by other protocols, such as SMTP and WAP. The Internet provides a feature-rich environment for a call centre and is capable of conveying visually engaging information, retrieving statistically valuable data, and providing seamless resource management.
A call management system is the complete process in which customers submit information (either verbally, by e-mail, as Internet data, or via some other form of communication), the call centre deals with that information, and the response is sent back. It also encompasses all the intermediary processes in between those steps, such as additional communication with the customer and dispatching engineers.
A good call management system must:
- Be seamless for both the customer and the call centre, allowing for rapid submission of calls and efficient administration of those calls. Many call centres exist for customers with problems, complaints, or queries, and this type of audience has little tolerance for poorly designed systems. Bearing this in mind, the user should be required to enter as little data (and hence spend as little time) as possible for the call to be processed.
- Be able to aid the productivity of the call centre responding to the calls. Otherwise, there is little point in the system existing. Productivity increases (such as calls completed per time unit) can be achieved through the implementation of resource management functions that determine the next call to be answered (e.g. highlighting urgent calls).
- Provide suitable quantitative data for statistical analysis. Statistics are the core of administrative call management, and can provide the call centre with more than enough information to improve services, quantify customer satisfaction, and highlight time lags. For example, implementing the correct time stamping points during a call life cycle (discussed later) can allow the call centre to dynamically generate average turnaround times (time between call submission and call closure), time lags in the system, and call centre response times (e.g., how long it takes to acknowledge a new call). This data can then be broken down into more specific categories, offering statistics per business area, per customer, per call centre agent, etc. A certain level of statistical abstraction can be used so that the data is also relevant to higher levels of management.
Historically, many call management systems have used conventional telephones as their primary method of communicating with customers. This, however, poses problems for the Internet system; for example, retrieving quantitative statistical data from verbal communications is, at this point, nearly impossible. Certain information can be extrapolated, such as the time required to answer the phone, the duration of the call, and whether either party hung up. However, statistics regarding the actual content of the call are difficult to determine. If an Internet call management system is running alongside a phone system, there needs to be a mechanism that consolidates the information from the Internet and from the phones (for example, by redirecting callers to the Internet system or allowing call agents to enter the information directly into the system for the user).
System portability issues can also determine the technologies used. If, for example, engineers in the field need to submit or respond to calls, then what's required is something more than a simple HTTP front end. We may need to consider appropriate data format modifiers, such as those found generating Wireless Markup Language (WML) for mobile appliances. This should be designed into the system at the outset so that the content is independent of the platform. This can be achieved by implementing standard text templates that allow a back-end program to reformat the textual content to different standards.
As a real world example, the Core Systems Support Group at IBM Headquarters (UK) originally used a telephone and e-mail-based call management system. Emerging from the old system was a strong need for more accurate statistical data, as little could be extracted from the phone calls or the e-mail system (the data being qualitative and erratically formatted). The intranet-based call management system that was implemented as a result of these limitations allows for more automated points of contact with the customers. For example, when a call's status changes (a call is usually allocated a status such as "read," "submitted," or "closed") the customers are notified of this progress by e-mail. The new system also provides a complete statistical analysis of call data, such as average turnaround times and system usage.
The data produced from an Internet call centre can benefit management as well as customers and call agents. For example, data about users of the system can be used to automatically perform customer satisfaction surveys (by e-mail for example), which can then produce dynamic statistics. The results can provide those interested with quantitative proof of the success or failure of the system, and suggest ways in which it can be improved.
A typical life cycle of a Core Systems Support Group call is illustrated in the flow chart below. For simple call solutions only one source of customer input is required, as shown by the gray box; but for more complex problems, the "Call solution compiled" stage may require more input from the user.
Figure 1
The Internet offers a suite of protocols that are beneficial to a call management implementation; this enables coverage of geographically dispersed customers, call agents, or engineers, and provides broad support for multiple data formats. The Internet is also capable of offering a more complete statistically oriented solution than, for example, a phone-based implementation. Anything that is accessed, modified, opened, etc. across the Internet can be very accurately traced with server-side software (and client-side cookies), allowing precise dynamic statistics to be compiled.
We will focus our attention on the following Internet protocols: SMTP (Simple Mail Transmission Protocol), WAP (Wireless Application Protocol), and HTTP (Hypertext Transmission Protocol). Each offers different functionality, and normally they are used together to maximise the usefulness of a solution.
Internet implementation issues
The most obvious, and probably most valuable, protocol to use for an Internet-based call centre is the HTTP protocol. Using the Common Gateway Interface (CGI) and back-end databases, the HTTP protocol offers customers the opportunity to do things like track the status of their calls, compile statistics, and view their call history. However, HTTP has limitations, such as a limited ability to transfer large files across the Internet. File transfers are not particularly natural to HTTP (though this can be achieved using PUT), are poorly supported by Internet browsers, and more easily achieved through File Transfer Protocol (FTP). These complexities need to be transparent to the user so that quick and easy call submission can occur without unnecessary technical details being made apparent.
Client-side persistent data is a big issue on the Internet, particularly for call management, as a user's settings, login information, and other details need to be made persistent for the duration of the session. Ordinarily, this is achieved by the Web server sending data to the user (which is then cached locally on the user's machine), though many users turn this feature off as they regard cookies as a security risk. An alternative method is maintaining state by passing hidden form elements between each Web page. The Web server inserts hidden forms into each HTML document so that the information can be parsed from request to request. The data inside the form can be accessed through JavaScript or passed in the Web site address (URL) to a server-side script. However, on larger Web sites where the amount and type of data is variable, this is an unattractive solution to the problem of session management. A cookie solution is discussed later where mod_perl automatically sends a session key to the client upon connection to the site.
A customer who raises a problem with a call centre that uses a phone system expects the agent to be polite, attentive, and clear. Likewise, a customer who uses an Internet call centre expects the process to be intuitive, quick, and error free. Human Computer Interaction (HCI), which focuses on issues such as computer ergonomics, interface design, and international design differences, is vital to the successful implementation of an Internet call management system. HCI takes into account colours, typefaces, consistency of style, and many other factors that contribute to a user-friendly system. HCI also requires the system to use symbols and errors that the user can associate with. For example, using an image of a camel for a stop button would inevitably confuse users, whereas a stop sign icon would not. Effective prototyping and thorough testing can eliminate many of these HCI issues.
Across protocols such as HTTP or WAP, HCI also focuses on both the actual speed of the system and the perceived speed. Actual speed is the measurable time it takes for something to happen, whereas perceived speed is how long the user thinks it takes. Perceived speed can be increased by implementing progress meters or moving objects while the system is busy, whereas actual speed can only be increased through better programming, or more expensive hardware. Performance should be a consideration at every stage of the software development life cycle, from design to coding. This requires the database to be designed thoughtfully so that SQL statements are not greedy and inefficient (e.g., querying more rows than necessary), and that a minimum number of database references are made. HTTP progress meters can only be implemented on the client, which can raise problems with browsers (like Internet Explorer 4.0 and Netscape 4.0) that support different technologies, or even different Document Object Models. This can be addressed by writing cross-browser code, but it does slow development and considerably increases the required testing time.
Internet call centres are likely to use the Web (HTTP) for conveying visual information and retrieving user input. HTML has improved in recent years, allowing designers to give an application-like look and feel to Web front ends. CGI is used to tie what the user sees (e.g. their call history) to the back-end database that stores all the information. The CGI model can be expressed in context using the following flow chart:
Figure 2
The above flow chart also illustrates the interface with the data source (possibly a Relational Database Management System, or RDBMS). Implementing this as a three-tiered system (separating back-end data, application and interface) can enable faster responses to customer requests, though this is not necessary and the data can reside on the same machine as the Web server. Changes made to a call by an engineer or a call agent need to be propagated to the data source. Changes can occur from various sources -- such as a Personal Digital Appliance (PDA), a Web browser or even a mobile phone -- so data consistency is vital to the prompt reaction of both the engineer and the call agent.
Call centres produce an enormous amount of data. For example, the Core Systems Support Group at IBM UK receives approximately 500 requests through the intranet each week, resulting in about 2000 a month. Since many of these requests need to be kept for reference, tens of thousands of calls are stored (many of them with embedded files like screenshots). To guarantee that the system does not grind to a halt after realistic usage, it is very important to ensure that the appropriate database is used. Often, many developers think of Oracle or IBM UDB (Universal Database) as the databases to use. Though both databases are impressively powerful (capable of dealing with 1,000,000 page views per second), they are often overkill for many call centre solutions. MySQL is relational database software under General Public License (GPL) that offers huge scalability and a simple API (Application Program Interface) free of charge. It is inherently supported by PHP4.0 and is supported by PERL through the installation of DBI.pm and DBD::mysql. Like DB2 and Oracle, MySQL is a command-line RDBMS that can be implemented using API calls or across Open Database Connectivity (ODBC).
ODBC provides a generic front end to many different database systems, and allows fourth-generation SQL (Structured Query Language) to be issued in a standard form. However, connecting the ODBC source -- i.e. the database -- to the application is pure overhead. This can be overcome by running Apache and mod_perl, instantiating a persistent database handle that is created only when the server is started, rather than every time a user requests data from the database. Despite the performance limitations of ODBC under Windows, it provides a very simple interface with the database so that SQL can be used to query data.
Choosing the right Web server for a solution depends on the type and quantity of data that needs to be sent back to the user. A typical Internet call centre predominantly uses dynamic content (referencing databases and compiling real-time graphical statistics), which differs hugely from the needs of a server supplying static HTML. Apache (currently version 1.3.22) is used by 59% of Web sites (Source: September 2001 Netcraft Web Server Survey), primarily because of its agility at serving dynamic content (through CGI) and the stability it offers. An Internet call centre requires a CGI-oriented Web server, so our code example will focus on Apache.
Apache is highly configurable, which makes it possible for custom modules (handlers) to be written in PERL or C; this means the Web pages/data can be manipulated before being sent back to the user. For example, data can be automatically compressed as it is passed by Apache (before being sent to the user), reducing download time and network usage. A solution to session management can be easily written in Apache (using mod_perl) that attempts to send a cookie back with every HTML request to the server (see Listing 1 below, and Listing 2). If the client already has a cookie, it returns the document (keeping the session ID by re-instantiating the cookie); otherwise, additional headers are sent with a new ID.
Note: In a real system the GenerateSessionID function would be replaced with a better session ID generator, such as an ID retrieved from an RDBMS.
SetHandler perl-script
PerlHandler Apache::SendSessionKey::handler
|
The Internet provides an extensive tool set for call centres, allowing geographically dispersed groups to communicate across a familiar and widely supported medium. Middleware applications (such as MQSeries -- see the MQSeries sidebar) can be used to efficiently and safely interface with older legacy systems. In addition, these implementations not only benefit users (through convenience, speed, quantity, and quality of call information), but also the call centre itself, allowing users to communicate with the system in a structured and quantitative manner. This makes it possible for highly accurate statistics to be generated with very little manual intervention. Ideally, this article has provided you with enough background information that you can tackle the problem of Internet call management more confidently.
- The PHP graphing library JPGraph can be obtained free of charge from http://www.aditus.nu/jpgraph/. This was used in the development of the Core Systems Support Group call centre, allowing quick and easy dynamic generation of complex graphs.
- Technical documents, developer information, and purchasing information on IBM MQSeries can be found at http://www-3.ibm.com/software/ts/.
- A free copy of the Apache Web Server can be downloaded from http://httpd.apache.org/. This site also contains vast quantities of tutorials and documentation on programming Apache.
- Mod_perl, which can be downloaded from http://perl.apache.org/, includes information on how to port old CGI programs to mod_perl.
- ActiveState PERL (http://www.activestate.com/) is a Windows build of PERL that can be useful for those running PERL under Apache in Windows 2000/NT.
- To learn more about the databases discussed in the article:
- For technical details on all major Internet protocols, go to Internet Engineering Task Force site (http://www.ietf.org/).
- For more information on Human Computer Interaction (HCI), take a look at IBM's research at http://www-3.ibm.com/ibm/easy/eou_ext.nsf/publish/10.
- IBM's Ease of Use site offers new innovations, user-centered design, guidelines, stories, technologies, and other resources to help improve the total user experience for your products and services.
- For coverage of a wide range of usability issues, check out the developerWorks Usability topic.
Jon Hatcher has been working on an intranet call management system in PERL, PHP, Apache, DB2, HTML, and JavaScript for the last six months. It comprises over 10,000 lines of code and provides a complete call/resource management suite for call agents and administrators. Jon is a member of the Integrated Degree Scheme (IDS) -- an IBM sponsored Computer Science degree course -- and is currently in his 2nd year. You can reach Jon at jon.hatcher@uk.ibm.com.
Table of contents
Local resources
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
