PakNetX has released the latest version (PakNetX 1.1) of its Web-based ACD, also known
as the PNX ACD. Here's how it works: a PakNetX-written CGI program sits beneath a
customizable .GIF button on an organization's Web site. Users click this button and
transfer to a queue. When an agent is available, the software opens either Microsoft
NetMeeting or Intel Business Video Conferencing on both parties' computers, enabling
real-time audio, video, file exchange, and whiteboarding. After the call, users hang up,
agents follow wrap-up procedures, and the server software logs the entire process.
The PNX ACD stands at the nexus of two key trends: the acquisition of Web capabilities
by the call center, and the growing importance of multimedia. Basically, the PNX ACD
combines the call center's interactivity and multimedia's visual appeal. Because the PNX
ACD automatically opens the collaboration software on both machines, "callers"
need only have that software installed, and they needn't be expert users. Moreover,
products like NetMeeting are free, the actual communication is IP-based, and the CGI
program is editable. These attributes, in combination, allow call centers to give
customers a seamless multimedia encounter, while password-enabling site access and billing
for it, by customizing the script and by exploiting PakNetX's logging features.
INSTALLATION
A tedious business, installing the PNX ACD. Such strict requirements. The server software
must run on a Windows NT 4.0 server that also has Internet Explorer 4.0. This machine can
be the organization's Web server as well. Agent PCs can run on NT or Windows 95. Callers
using Internet Explorer must have version 3.02 or above with ActiveX enabled, and callers
using a Netscape browser must have Navigator 3.01 or above.
The PNX ACD can handle a maximum of 150 agents in up to 12 groups, but only 50 agents
may log in at once. The call center's LAN firewalls must be enabled for the H.323 and
T.120 protocols, running on a TCP/IP network with a permanent Internet connection. It's
important to close all programs and uninstall any previous versions of the PNX ACD before
installing the new version. Administrators install the server and clients from separate
CD-ROMs. The server and every agent must have the same version of NetMeeting or IBVC.
If the PNX ACD server runs on a machine other than the organization's Web server, then
the NT Web server must have its guest account enabled. If the Web server runs Microsoft
Internet information Server 4.0, then the file Pnxcall.exe must have its security option
set to allow automatic password synchronization, with a blank password.
Finally, the administrator must transfer a series of files to various directories on
the server PC, and they must integrate the CGI connection button into the organization's
Web page. The Pnxcall.exe file goes into the C:\InetPub\wwwroot directory, along with five
other files: SampleX.htm and CallerX.dll (for Internet Explorer users); Sample.htm and
ACDCaller.exe (for Netscape users); and either the ConnectMe.gif or any other .GIF file
(for the connection button). To edit the HTML code, refer to the "edit sample web
page" section of the quick start guide, in chapter two of the online help file.
DOCUMENTATION
The PNX ACD's documentation is helpful, but it's poorly organized and not available in
printed form. To truly understand the PNX ACD (and its installation, operation, and
maintenance), administrators need to read a file of release notes and five instruction
documents, three help files and two readme.txt files.
It makes sense that the release notes should occupy an independent online file, but we
can't understand why PakNetX didn't compile the five instruction documents into one book
or master file. Such consolidation would make the PNX ACD easier to understand and simpler
to implement.
As it is, the documentation lacks any overall organization. All the information is
there, somewhere, but you have to read virtually every word to find anything in
particular. For example, the second chapter of the online help manual does meet the
definition of a quick start guide, but any kind of read-me-first document is useless if
the packaging doesn't alert you to its existence. This is a shame, because the text itself
did consist of sound technical information.
We should point out another shortcoming of the documentation: It contained hardly any
screen shots.
FEATURES
We liked the server GUI. It was well designed, giving administrators easy access to a wide
range of functionality. It presented six tabs, which corresponded to general settings,
agent management, statistics, agents' status, messages, and customization. (We'll discuss
the general settings and statistics tabs, since they present users the most options. Users
would find nothing particularly challenging about the other tabs.) We also liked the agent
client. It was appropriately clean and simple.
Server
Under the general tab, administrators can select an IP address (ideally, this is a static
IP address), the call center's hours of operation, and the license key. They can also
switch the server is on or off. (Switching the server to "off" will prevent new
calls from coming in but will not disconnect calls already in the queue.) By using
multiple copies of the CGI program linked to different .GIF buttons on a Web site,
administrators can configure specific agents or agent groups to field specific types of
queries.
The logging features are excellent. Found under the statistics tab, this option is
broken down by the administrator's choice of group or agent, and each choice can be broken
down still further, according to the current day, week, month, etc.
For groups, the categories available for analysis include:
- Calls handled and calls requested.
- Average talk and wrap-up times.
- Average and longest caller wait times.
- Calls abandoned.
- Incoming calls, when the call center is closed or when no agent is available.
- Incoming calls, when the queue is full.
For individual agents, the categories include:
- Calls handled.
- Average talk and wrap-up times.
- Not available time.
- Total logged-in time.
Another analysis measure involves PakNetX's .CSV files. These files are importable to
any database program. They log the statistics of each call, providing information such as
the time of the call and the outcome of the call (abandoned or connected). They can also
provide information about the caller, such as the caller's IP address.
Combined, these tools are extremely powerful. Properly analyzed, these are useful for
optimizing how many agents are needed and in what capacity.
Client
There are only two menus to contend with - options and help - along with a "call
context" window, which displays information found in the CGI program of whichever
button the user clicked on. For example, if the administrator had three buttons on a site
- one each for support, sales, and information - he or she could code those words into the
button for each choice.
For example, if Bob the user were to click on sales, then sales would appear in the
context window. If Bob were to click on support, that would show up instead. This way,
agents assigned to multiple categories know what to expect for individual calls.
We also liked the agent's icon. It read "available" when the agent was not in
a call. (It can also read "unavailable," if the agent toggles the available
button to the unavailable position, at the start of a break. The icon reads "in
call" when appropriate, and after the user disconnects, the icon reads
"wrap-up" until the agent finishes any bureaucratic duties.
While we admire the client's simplicity, we'd like to see it minimized as an icon on
the Windows toolbar, and we'd like it to be resizable. Also, we'd like to see more
customization options.
OPERATIONAL TESTING
We got our copy of the PNX ACD to work only after a series of false starts. We attribute
these false starts to an underlying problem: the complexity of the script portion of the
CGI program. As readers of CTI are aware, no program will work unless every feature of
every line is correct, and there are enough settings and parameters in the CGI script to
drive a normally patient programmer batty.
There are also different scripts for Microsoft and Netscape browsers, essentially
doubling the difficulties. The script pushes a certificate to Internet Explorer users, and
if they choose to "always trust" connections to the site, then the download is a
one-time procedure. For Netscape users, a download of a caller application file is
required. This download is also a one-time procedure.
When the script finally did work, we waited as the screen read "connecting."
And we waited. And waited. On average, in our ideal network laboratory configuration, the
wait time for our calls to transfer to the only user we configured was about seven
seconds. We suppose the wait would be even longer on a larger network, with the product in
actual use, under realistic loads. Whether a wait this long would pose a problem isn't
clear. In any case, we're unaware of any competitive products that would transfer calls
any faster.
ROOM FOR IMPROVEMENT
Although the user doesn't have to do much to connect to a PakNetX-enabled site, there is
still work to be done to minimize the user's effort to connect to a live agent. On most
sites, a user who clicks on "connect" is presented an intermediate page, a page
that demands the user's attention before a connection can be established. This
intermediate page usually explains the system and software requirements for the user's PC.
(Someday, a Web site may try to update or adjust the user's PC automatically to make the
site open to everyone, but we don't necessarily want a Web site to do that.)
We'd like to see resizable interfaces for both the administrator and the agents. The
server is fairly customizable, and additional features, such as streaming multimedia
(while callers are waiting), may appear in future versions. Still, other CTI packages with
the same degree of complexity are far more customizable. The client could also include
more customization options.
Finally, the documentation needs to be better organized, and it would benefit from the
addition of a few (actually, more than a few) illustrations.
CONCLUSION
What the PNX ACD does, it does well. It lets a visitor to a Web page click on an icon to
launch (free) collaboration software, initiating a live, multimedia exchange with a call
center agent. This functionality arrives at an opportune time, given the rising popularity
of multimedia PCs. As one of the first mainstream entries to the collaborative multimedia
market, the PNX ACD does a good job, and encourages us to look forward to many more (and
perhaps even better) collaborative multimedia releases in the near future, from PakNetX or
other vendors.
For now, however, PakNetX deserves to call itself the market leader. The PNX ACD is
ahead of the pack, and it provides a wealth of features. It is worth considering, however,
that much of the functionality is attributable to NetMeeting. (We assume the vast majority
of users will choose NetMeeting ahead of the Intel solution.) Thus, Microsoft deserves
some of the credit for the PNX ACD's functionality. |
Internet Telephony Magazine
Click here to read latest issue
CUSTOMER 
Cloud Computing Magazine
Click here to read latest issue
IoT EVOLUTION MAGAZINE
