Key elements for establishing and optimizing the relationship with your vendor and the technology.
The cloud is a strong contender for contact center technology today, and the market hype makes it look as simple as buying a mobile phone app! While it may look “fast and easy” on the surface, centers of any size or complexity need to do more than just turn on some software licenses and hope for the best. It takes effort to secure the functionality to meet customer needs and gain the peace of mind that it will perform as expected.
In last month’s article, I laid out the market and vendor landscape so those of you in hot pursuit of a solution have a good understanding of the options and considerations. This month’s article shares some insights into succeeding in implementation and ongoing vendor management. We’ll dive into three pieces of the success puzzle that may not be as effortless as the market messages would have you believe, but don’t have to be hard.
SOW Is Your First Step Toward Success
Historically, with premise solutions and early cloud (or hosted) solutions, a robust Statement of Work (SOW) outlined what was going to be done in implementation, who would do it, when things were due, etc. The SOW provided a roadmap for implementation and accountability for results.
Part of the lure of the cloud is speed and ease. Both sellers and buyers would love to sidestep the SOW and implement functionality using standard agreements and licensing, or even free trials. That may work fine to try it in a small, simple group. However, it is unlikely to be enough to help your center achieve its goals, and certainly not adequate if you are replacing an integrated, fairly robust premise solution. So while you need an SOW, it can be relatively simple, short and easy due to the reduced implementation load inherent in a cloud application that is ready to go on a shared platform.
Whether on day one or after you’ve piloted for a period of time, you need to define requirements, addressing functionality, integration, testing, training and more. Here, a little planning goes a long way (see Figure 1). The SOW serves the same purpose it has in the past—get everyone on the same page, define tasks and owners, timelines and target outcomes. If important, define onsite time for things like design, testing and training. (The default for many vendors is that these things are done remotely, and in most cases, minimally.) The sidebar provides a starting point for your SOW content.
The vendor may start with a template, but make sure the scope and deliverables address the realities of your environment. Typical hot buttons include:
- Design or redesign of call flows, IVR menus, self-service applications and desktop interfaces
- Integration with other applications, such as CRM or the core system
- Implementation of new media (e.g., email, chat) and all that goes with it, including work flows and pre-built responses
- Design and development of custom reports
- Testing and training, including expectations for onsite time and out-of-hours time, if needed
- Documentation specific to the implementation (e.g., call flow diagrams)
Increasingly, SOWs are created after initial use of the cloud solution. Many vendors push a “dip your toes” mentality and want buyers to get started with simple implementations. The professional services can be low-cost (e.g., $10,000) for basic implementation and may even be free. But if you implement large numbers of groups, pursue new functionality or media, or have any complexity with integration, routing, menus and self-service, it can be much more, even six figures. If you know your needs will drive up implementation costs, ask for a quote (or at least an estimate) prior to trying the technology to avoid getting enamored with a solution and vendor that can’t meet your needs or facing a “surprise” cost when you start to get serious. Understand the vendor or partner’s discovery process and the approach for refining, reviewing and finalizing the SOW. Include limitations on the amount of change allowed or a cap to try to get them to do enough legwork for you to have a realistic understanding of the effort, time and cost. The bottom line is everyone needs clarity on who is going to do what—internal IT and CC resources, vendor, partners and/or third parties—and how much it will cost.
SLAs Guide Performance Management and Delivery
Another key document is the Service Level Agreement (SLA), and again, increasingly, vendors will seek to make this simpler and more “standard.” You don’t necessarily want to be non-standard (more on this in vendor management), but you do want to fully understand what you are getting with the standard SLA. If you are going to deviate from the standard, make sure the mechanisms for processes and accountability are clear.
Figure 2 outlines key considerations when reviewing SLAs and understanding how the vendor operates and supports the cloud solution, and how you will interact with them. The yellow arrows highlight questions that are key to having some meat behind what may on the surface look like a great marketing story. Explore what the vendor is committing to deliver in SLAs, what they can and can’t control (and therefore can or can’t be held accountable for), how they will respond, how they will track and report on SLAs, and what the remediation is. Beware of situations such as:
- Low availability commitments (e.g., less than 99.99%)
- Elements for which they won’t take responsibility (e.g., third-party network)
- Manual failover (and how it is triggered)
- No visibility into performance
- Network Operations Center (NOC) that is not staffed 24x7
- Buyer responsibility for reporting on (and proving?) any failure of the vendor to meet SLAs
- No or weak remediation, which is typically based on price penalties (e.g., very low cap on percent discount regardless of level of performance)
Perhaps the two most important elements of an SLA are availability (also known as uptime) and response time. Historically, the availability target for contact center technology was 99.999% or “five nines” of reliability, limiting downtime to about five minutes per year. Some cloud vendors will commit to that level; it’s more likely you will see something less, such as 99.99% (53 minutes of downtime per year). The lower bar isn’t a show stopper for most, but that tolerance makes accountability and remediation that much more important. If the vendor doesn’t hit the (lower) target, they should have something substantial at risk. Dive into the response time commitments and the definitions of severity levels to know that someone will be working on resolving issues quickly (within minutes), with clear escalation and communication. Response time can also have penalties for missing the mark.
Many buyers today think that it’s easy to change if the vendor isn’t good, so why worry about this stuff? That is a dangerous mindset. First, SLAs and accountability to match show they are serious about delivering a good solution, not just a fast, easy, and/or low cost one. Further, it’s not always easy to change, especially if you’ve done the work to configure and integrate. Change impacts users in key areas including desktop interfaces and performance management tools (e.g., reporting, WFM). You don’t want to suffer through a transition and poor performance period. And if your current provider knows or suspects you are looking for replacement, the performance may actually get worse! So SLAs do matter and diligence up front is your protection against failure and the need to change again.
Active Vendor Management Delivers Ongoing Success
Many going to the cloud are excited about reducing the burden on IT and enabling the contact center to make their own changes and manage their own solution. That is all feasible, but IT still needs to be involved to help with network, integration, security and upgrades that impact other systems, and any infrastructure that is onsite or not provided by the vendor. And the contact center needs to understand the role it is taking on and the resources required to fulfill it. In all but the most basic centers, active vendor management will be a key part of ensuring a good partnership with the vendor and ongoing success for the users.
It is crucial to define the appropriate vendor management role and who will provide it, whether in the center or in IT. In a dynamic, complex, mission critical center, you are likely to need a dedicated support resource, perhaps full time (e.g., a business analyst who is also responsible for administration and configuration of system). The Vendor Manager (VM) needs some technical aptitude and great communication skills as the liaison between the business areas, IT and the vendor. Here are some examples of the important role they play:
Actively manage performance
The VM will always have a “finger on the pulse” of the system, ensuring that the solution is working end-to-end, including desktop integration and network. Part of the active management is to review invoicing to ensure a match with licenses used, performance delivered, etc. This is one reason it’s not good to deviate from “standard” SLAs—if yours aren’t standard, ensuring compliance may be very difficult as your reports and invoices won’t align or must be “one-off.”
Respond to issues
When performance isn’t meeting goals, the VM will engage in finding a remedy to the situation, and may need to help assess, plan fixes, monitor results, etc. As with any robust and integrated solution, this can lead to a dance with multiple players inside and outside the organization. During issues, the VM may submit and manage trouble tickets, facilitate vendor (and IT) communication, confirm resolution, etc. After issues, the VM may facilitate steps to debrief, analyze, review changes, ensure actions being taken will prevent future occurrences, etc. Obviously this is another time it’s good to be “standard” in processes. If you’re different, it’s more likely the vendor won’t be able to execute troubleshooting processes consistently or you’ll be depending on individuals instead of a team.
Keep advancing
The VM will need to understand new capabilities as the vendor (frequently) updates and adds functionality. The VM needs to assess how changes apply to business needs, define when and how to use them, and oversee putting them into practice. On the flip side, the VM will also respond to business needs and find ways the system can meet them through existing or future capabilities.
Easy Does It
While the cloud is exciting and vendor marketing messages enticing, contact center technology is not a simple consumer tool, and business needs can be wide-ranging and demanding. If you want to get the most out of both the functionality and performance of your cloud solution, include the SOW, SLAs and vendor management as key elements in establishing and optimizing your relationship with your vendor and the technology. A little due diligence and planning can deliver an outcome that is both easy and good!