Voice is Not the Path to UC
Voice is Not the Path to UC by Kevin Kieller
Two roads diverged in a yellow wood, And sorry I could not travel both… Robert Frost (The Road Not Taken)
Increasingly I am convinced that the road to unified communications does not follow a straight line from your current voice implementation.
For a long while no one really knew what unified communications or “UC” was. At first, too much time was spent trying to define UC. At one point, it seemed everything that was “VoIP” (voice over internet protocol) was simply renamed as “UC.” And yet, to the surprise of some, this re-labeling did not magically “unify” everything. Go figure. And except in the days before the dinosaurs, no one really thought you were able to claim a meaningful “UC implementation” by just moving voice onto your data network.
In the end, no matter how it is labeled, a voice system is not a unified communications system and it is somewhere between impractical and impossible to upgrade a legacy voice system to be a true unified communications system.
Voice solutions are typically “siloed” solutions. They are designed to deliver a very specific set of features (voice features) generally without regard for, and without integration (or very minimal integration) to, other existing communication systems. This is not to say voice solutions don’t deliver the voice features required – but the best-delivered voice solution does not deliver unified communications.
Some vendors would have you believe that upgrading to a high enough version number will cause your voice solution to magically transform into a UC solution. Version 1.0, 2.0, 3.0, 4.0, 5.0, *** presto chango ***, version 6.0 is now UC. But, it does not work this way. Without much work a voice system does not become a UC system. Sometimes the most direct path to UC is to build a separate, new infrastructure. While leveraging previous investments is important, sometimes leveraging the old can impose technical and financial burdens. It is not always cheaper to reuse older components.
Of course many, many (far too many!) PowerPoint slides have been created showing vendor X’s PBX at the center with arrows connecting to every other competitive communication product and every flavor of mobile device. Some seem to believe by drawing a “unified diagram” this empowers the “technical team” to simply make it work. (I hear the Star Trek character Jean-Luc Picard character saying “Make it so, Number One”.) If life were as simple as drawing a PowerPoint diagram things would be good. Unfortunately, life and the real world often are more complicated than PowerPoint, no matter how many animations you add to your slides.
Unified Communications is by definition about combining and integrating various tools so that the total is more than the sum of its parts. A key proviso, however, is that UC was never supposed to be about integrating everything. To be successful and practical, a UC solution needs to integrate the devices, applications and directories people use on a regular basis. UC does not need, nor should it, try to integrate all applications. In many organizations common requirements are to integrate Active Directory (the most common central directory), email, instant messaging, calendaring, voice, conferencing, and desktop sharing on PCs, tablets and smartphones.
Voice and UC systems also have different “philosophical” centers. While voice systems often have a “call” or increasingly a “session” at their core, UC systems most often, and most effectively, have a directory of contacts at their core. Most voice systems grew out of first deciding what you want to do (i.e., you pick up a voice device) and then choose who you want to do it to (i.e., you dial a number). Most UC systems reverse this and have you identify who then what (i.e., choose a contact, or contacts, then choose a communication modality). Two paths through the yellow wood: what-who or who-what.
Traditional Voice Sales Process
UC and voice systems by definition involve different levels of interoperability, they have different philosophical cores and most often they are sold using a different sales process. The traditional voice sales process can be quite successful working like this…
1. You choose what voice vendor solution you want to “pitch.”
2. You gather some key information: number of sites, number of users at each site, level of resiliency/redundancy required.
3. Using this basic information you use a “configurator” (an automated design tool or standard design “rules”) to “spit out” a “BoM,” bill of materials (pronounced “bomb”).
UC Sales Cycle
In contrast, the most successful UC sales cycle works like this…
1. Define and prioritize customer business requirements.
2. Inventory existing infrastructure investment.
3. Evaluate different vendor solutions and architectural options (different levels of integration, client-side integration versus server-side, etc.)
4. Provide customer with conceptual architecture, budget estimate and implementation timeline.
5. If accepted, proceed to detail design, refined budget and detailed project plan.
Sadly, but realistically, because UC often seeks to support more integration points (often involving more than one vendor) the sales and required design process is more complex. And this difference in the successful sales approach makes it difficult to “grow” a successful voice selling process to be a successful UC selling process. This is why very successful voice system resellers, telcos and large VARs, are having a challenging time transitioning to UC sales. The truth is they cannot simply do “more of the same;” but rather, they need to re-orient their entire sales process to focus on customer requirements ahead of vendor selection.
Additionally, the UC implementation process requires a different scheduling focus. Because UC is more about integration and interoperability, technical risk-based scheduling is of critical importance (where the more challenging integration elements are addressed first). Because most voice solutions involve single vendors, the order of implementation tasks does not matter as much; the vendor has already “certified” that the pieces will work together.
Also, because a UC solution needs multiple technology components to work effectively, unlike a voice solution which is often driven by telecom supported by the network team (for QoS, etc.), UC requires collaboration between networks, telecom, application and server teams.
Finally, to be successful, UC implementations also require far stronger communication, training and change management as compared to voice implementations. Elements such as unified messaging, where voice mail is now stored in an email inbox may also require new security reviews and compliance considerations.
Keys to Success in the UC Market
Given the differences between voice solutions and UC solutions, I would suggest there are several key things you need to do differently to succeed in the UC market:
As a vendor…
1. Stop drawing diagrams that show your product integrates with every other product. This simply creates unreasonable and unobtainable customer expectations.
Or, at a minimum only show these “overly optimistic” diagrams at executive briefings. Prepare a second set of “real world” diagrams that show what products have been tested and certified to integrate with your products and then make sure all of these integrations are available for demonstration in demo centers. I would argue that “telling the truth” will actually increase your sales and the sales you do make will more often yield satisfied customers.
2. Help your channel understand the differences between selling “siloed” voice and/or video solutions and selling UC. Make sure they don’t over-promise when it comes to interoperability. If they don’t know whether two things work together, instead of saying “yes,” teach them to say, “I will need look into that.”
As a reseller…
1. As per the above guidance to vendors, do not overpromise when it comes to interoperability.
2. Make sure your sales force has seen, and ideally used, the solutions they are being asked to sell.
3. Differentiate yourself by sharing the pros and cons of different solutions.
4. Ensure communication and training is included. (Most UC implementations will not be successful without strong end-user communication, a.k.a. “expectation setting,” and training.)
As a systems integrator…
1. While UC provides many opportunities to develop differentiated expertise in integrating components, you must make the investment in a lab environment to develop successful implementation methodologies before you can effectively price and deliver UC solutions to your customers.
2. For new solutions or integrations, propose and sell a “proof of concept” before committing to pricing on a large scale deployment. Even large dollar projects are problematic when costs exceed revenue (and trying to get some multi-vendor integrations working can require lots of time from your senior technical resources).
3. Offering strong communication and training services to compliment the solution can be a major differentiator and can greatly increase the overall likelihood of project success.
As a customer…
1. Do not choose a vendor before you document and prioritize your business requirements. If you need help with this, consider hiring a consultant to assist – this is often a good investment.
2. Do consider multiple platforms and compare each to your documented requirements. Once again, you may need outside expertise to do this.
3. Do ensure your vendor, reseller or SI has actual experience, and references deploying your selected UC integration.
Alternatively, for very new solutions or new integrations, first undertake a proof of concept where you can ensure a) the integration actually works as promised, and b) the user experience is suitable that actual end-users (not IT staff!) will use it. Do this before committing to any production implementation. Survey the pilot group to collect quantitative and qualitative feedback.
4. Engage internal team members that have network, telecom, desktop application and server expertise along with communications and training skills.
If politically only one team can drive your UC project, I would argue that it should be the application team that leads. Individuals who have experience deploying business applications are more likely to have the skills dealing with multiple environment considerations.
The path through the “UC woods” can be twisty and dark however there are significant benefits to making the journey successfully. To get to your specific UC end goal, often you cannot simply continue going in a straight line with your current voice vendor.
Agree? Disagree? What is UC for you? Comment here or connect with me on twitter @kkieller.