Details of the university's infrastructure made for a complex project
Call it the Harvard University Tower of Babel. That might be the most descriptive way to look at the institution’s network of networks that consists of 10 academic units with independent CIOs and staff who build and take care of their own environments, yet all rely on a centralized call-center infrastructure to serve users.
How do you deploy a centralized IP contact center across 10 different networks? This is the challenge that the telecom department of Harvard University faced in 2001 when undertaking a replacement for its existing system.
Last week, Michael Rowe, manager of systems and applications for Harvard’s Telecommunications Department, shared how the university overhauled the call center infrastructure to embrace IP, expand features and keep costs down.
Because of the complexity of the mission and the fact that no commercial call center was designed for such an environment, the contact center platform was installed in two years, but after seven years the project is still a work in progress, Rowe told the Association for Information Communications Technology Professionals in Higher Education, also known as ACUTA.
No Harvard unit has a call center in the traditional business sense of a roomful of agents trained to handle similar calls. Instead, the centers consist of groups of agents (as few as three but no more than 21) spread around Harvard facilities in Boston and Cambridge, Mass. The goal was to have a single call-distribution device that could handle all of them.
At the outset of the project in 2001, the phone system was centralized, delivered via Verizon Centrex over Primary Rate Interface trunks to 30,000 phones. Call-center features also were provided by Verizon, queuing up everything from help-desk calls to questions about university medical benefits.
When Verizon decided to phase out the service, Harvard went looking for a replacement that could route calls to appropriate extensions as they came in.
Even with the help of a consultant, finding the right product was difficult, Rowe says. After reviewing 16 RFPs, the telecom team chose six finalists to demonstrate their wares. The results were dismal: Only a few managed to get their systems to work in the university environment. The team chose Customer Interaction Center (CIC) from Interactive Intelligence, because it had more flexible administration and allowed for expansion to meet future demand, he says.
Still, CIC wasn’t ideal. It required adding Active Directory and Exchange servers to the network. Initially Rowe placed two servers in the Harvard data center where they could back each other up automatically, but the automatic backup never worked smoothly. The servers proved temperamental, failing over at the slightest glitch and always requiring human intervention, he says. “The software worked great, the switchover was the problem. It was not a good solution,” he says.
So, when the telecom department moved to a site served by two central offices, Rowe saw it as an opportunity to split up the CIC servers also, sacrificing redundancy but gaining diversity of routing that could keep the university supplied with service if one central office failed, he says.
CIC had other challenges. It was designed to work best when phones are plugged directly into it. Because Harvard phones were on the Centrex network, each had to be treated as a remote extension. That meant bridging incoming calls to the agent extensions, which ate up two PRI channels — one for the incoming call and one for the bridge to the right extension.
The software agents that ran on agent workstations were also a bad fit. They required upgrading periodically, and that was a logistic and administrative nightmare. The various call-center-agent clients were dispersed on machines and networks with different support policies and staff.
To overcome this problem, Harvard decided to use Citrix Systems to get the fat-client CIC software off agents’ workstations and centralize the application. That involved installing a Citrix server and learning to support it, but the effort was worth it by eliminating desktop maintenance, he says.
By 2007, maintaining PRI cards on the CIC server became unwieldly. So, the university installed AucioCodes TDM-VoIP gateways to route calls between the Centrex service and the CIC servers.
This setup let Harvard link the CIC servers in the two via IP so they again could back each other up. So, he now had redundant, backup servers placed in separate locations to improve survivability in a disaster.
About the same time the university decided it should protect the Citrix server better and make it more robust, so it expanded the deployment. Citrix servers were placed in isolated network segments between firewalls, where they provided access to the CIC servers. This improved security for the servers and allowed support for multiple Citrix versions. It also allowed room for growth.
The downside is that the expanded Citrix deployment is more expensive than the single server, and represents one more technology to manage, Rowe says.
Harvard recently installed an operator’s console on the CIC platform, enabling directory search by whoever answers the phone. The console was released about the same time Harvard was looking for a new directory assistance application, so it was a good fit, Rowe says.
With 60,000 directory listings, the database is large; search was slow, but at Harvard’s request, Interactive Intelligence has streamlined it so a seach won’t start until a full name is entered. That simplifies the search and shortens the time it takes, he says.
The network also gives Harvard the option of having staff perform as university operators while working from home. “It never appears that Harvard University is closed,” Rowe says.
