During our tenure in the IP telephony and software industries, we have been exposed to many operational models and methodologies for both implementing IPT/Call Center projects and designing related software. We noticed that while some worked very well, others only worked to a certain degree, and most didn’t work very well at all. In all cases, we attempted to take something away from the experience and locate underlying commonalities. Essentially, our lessons came down to the fact that a successful company is made up of the union of talented, high output people with a process that both enables them to execute and properly rewards them for their efforts. We noticed that successful companies didn’t just “happen” – at some level their rise to success and prosperity was planned, with plenty of upfront thought going into concrete and thought-out goals, guiding principles and operating procedures.Our Contact Center Professional Services Practice has several core principles which we believe will allow it to perform at a level above and beyond similar firms:
Principle – Selective Projects
Let’s face it: some projects are destined to be troublesome from the start. Most integrators in the field will almost blindly take on these projects, only to find it end unprofitably at best, or as a disaster at worst. Virtually all of these projects have at least one of the following properties:
– The project is a call center upgrade or migration we cannot re-produce in our labs
– The customer refuses to follow our recommended best-practice
– Unrealistic timelines
– Not following a balanced approach with the four core factors (listed below)
Principle – Pre-Delivery (Lab)
Our practice integrates a concept called pre-delivery as a phase of every project we do. This phase happens early in the project – usually beginning immediately after the initial discovery work has been done and the SoW has been signed. During the pre-delivery process, the customer’s call-flow and reporting requirements are realized in our lab environment and the customer is then lead through them.
This innovative step brings many benefits:
– Hidden requirements emerge: Despite our best efforts otherwise, once the customer experiences their call-flow and reporting functionality in action they may realize they had overlooked something or don’t like something and want it changed. By bringing this possibility up early in the project timeline, we can conquer the majority of call-flow/reporting risk earlier rather than later. This helps us to both be proactive and to keep satisfaction high.
– Any scope changes are less costly at this point: By allowing this kind of proof of concept early in the project (as stated in the previous point), we can greatly reduce the amount of effort and overhead required to enact such a change, as there are less dependencies at the time.
– Allows for positive, low-risk project add-on: Keep in mind that any customer-requested changes lead to more billable work. We should actually encourage the customer to experiment with alternative call-flow concepts during this time, as build in this experimentation as a variable cost in the SoW.
The concept behind the pre-delivery stage has its roots in “agile” software development methodologies, where the customer can provide regular input during the evolution of their software product.
The Four Core Factors for IT Projects
The recommendations outlined in this assessment attempt to strike a balance between the four central factors of all IT projects:
– Budget
– Functional Requirements
– Operational Support
– IT/Day-2 Support
Below is a general summary of each, along with the stance that CTIPathtakes with regards to how each plays into the customer’s optimal solution:
Core Factor 1 – Budget
Obviously, a project being delivered on time and within the budget is important for any customer. CTIPath’s goal in this regard is to work with the customer to deliver the solution that best fits their needs and keeps their budget in mind. At the same time, CTIPathworks to make the customer aware of and limitations of the proposed design and the impact of said limitations. Recommended hardware and software should fit the customer’s current needs and workflow while allowing for appropriate growth and scalability in the future, all at an attractive price point.
Core Factor 2 – Functional Requirements
Functional requirements are composed of the hardware, software and associated best-practices that facilitate the features and reliability the customer expects and requires from their IPCC Call Center solution. Much like a house to a foundation, a well-built Cisco Call Center is built upon on a myriad of lower-level, more fundamental technologies and practices. The ones that can impact the BoM and/or SoW are highlighted below:
– Voice and data convergence: On a converged network, IP phone traffic as well as computer traffic traverses over the same physical equipment. Doing this simplifies the overall network by not requiring separate networking equipment for voice and data. In addition, consolidating voice and data over the same equipment allows redundancy at a realistic price-point.
– Use of VLAN and Quality of Service (QoS) features: A solid converged network makes extensive use of QoS, which allows the networking equipment to give higher priority to some data than it does others. To a customer, a well-designed QoS policy means that IP phones do not experience “choppy” or “garbled” voice, mission critical applications transfer data across the network quickly and efficiently, session driven applications are more responsive with less of a delay between interactions, and that the network as a whole exhibits consistent behavior even as network utilization fluctuates.
– Use of VLAN features: In addition to QoS, a solid converged network employs VLANing, where devices on the same physical equipment may be logically separated. VLANing facilitates a solid level of network security and allows for more flexible, efficient and consistent use of the company IP address space across their network infrastructure.
– Redundant Architecture: The goal of building redundancy into a network is to eliminate the single points of failure that can cost a business most dearly. While the purchase and installations of a failover switch or router may cost a business a few thousand dollars, it is usually dwarfed by the cost incurred in lost business if this device failed. A redundant, highly-available network architecture is a good idea for any business that values their network uptime – and where lost uptime is lost money.
Core Factor 3 – Operational Support
Operation support covers the ways that an IT support team will need to interact with the platform on a day-to-day basis. New agent phones will need to be set up and configured, agents may move from one building to the next, queue names may need to be changed, and so on. The general term for this is MACD, (Moves, Adds, Changes, and Deletes). With a well-designed IPCC call-center platform, these types of operations will be as simple as possible to the extent that the functional and Day 2 requirements are still met. Another possible part of operational support is allowing and managing visibility into the platform by the operational team, so that they can determine if they are satisfying their own business requirements.
Core Factor 4 – IT / Day 2 Support
A Day 2 support plan covers what happens after the installation is completed and the platform becomes operational. The primary underlying technical requirement of a quality day 2 support plan is a manageable application platform and network infrastructure. Such a setup can automatically inform a support team of any problems and outages on both the servers and networking equipment. In this way it is proactive in that it allows the support team to query and trend the network’s health: issues may be spotted and corrected before they become problems. The support team may be composed of the company’s own employees or may be an external team retained via a support contract and given visibility into the network. In the event of sudden equipment failure, a solid Day 2 support system provides the necessary people and process to guarantee a complete recovery with minimal downtime.
