Selling Outcomes Versus Items

If you are a reseller, do you know if you are selling items or outcomes?

If you are a customer, do you know if you are buying outcomes or items?

When unified communications started getting traction and mindshare several years ago, there was a strong focus on defining exactly what unified communications meant. Was putting voice and data on the same network UC? Was UC really just unified messaging? Was UC about connecting traditional desktop applications with core telephony?

I have always tried to reframe and refocus the discussion from “what is UC?” to “what can UC do for me?” That is to say, what specific, measurable business objectives are you expecting as a customer or promising as a reseller or vendor.

One of the reasons I believe the industry has shifted from the terms “VOIP” to “UC” and is now perhaps moving on to “Collaboration” and “Social,” and sometimes “CEBP” (communication enabled business process), is not because VOIP and UC failed but rather because customers were inferring outcomes and vendors were selling items.

With VOIP, the implication was that combining voice and data on one network would save money. And yet, after the network upgrades required to support Power Over Ethernet (PoE), and Class of Service/Quality of Service (CoS/Qos) on the LAN and WAN, after the additional training and migration costs, many VOIP projects, while “successful” in terms of being technically completed, did not provide the benefits inferred by the customer and/or implied by the reseller or vendor. Did any company really think weather apps or stock quotes on fancy and expensive VOIP phones would improve their business? And when the “bloom was off VOIP rose,” instead of focusing on understanding the desired outcomes, many vendors simply re-labeled VOIP solutions as UC.

With the UC moniker, the implication was that by combining different technologies both business effectiveness would go up and costs would go down, an even better proposition than with VOIP. Seemingly the more systems you could “mash together” the better the results. Additionally, UC systems were going to be so exciting that they were going to help companies attract and retain key talent. The story was told as though salary and benefits made little difference to these new “Gen-Y” or “Millenial” candidates as long as they could click to call and send IMs from their laptops and mobile phones.

Customers issued, and continue to issue, UC RFPs asking for a laundry list of features. Vendors and resellers “play the RFP game” and wordsmith responses in order to “comply” with all the mandatory requirements and then do their best to make it impossible to compare one response to another by focusing on very specific attributes unique to their solution. This is like the mattress game where each mattress retailer offers an exclusive, uniquely named, model of mattress even though the products may have identical specifications.

The typical RFP process focuses on acquiring items. It works well if all you expect is the item and not any implied outcomes. I order a beer; receive my beer; drink my beer and feel satisfied even though the beautiful people shown in the beer commercials fail to materialize and join me.

As a specific example, SIP trunking (for PSTN connectivity) is one current technology where the item versus outcome “expectation gap” is large. SIP trunking provides new and interesting architectural options for highly centralized communication solutions. SIP trunking also provides a potential opportunity to reduce costs. This is a potential cost reduction opportunity and not a guaranteed outcome for all customers. If you are selling SIP trunks, it is important to understand what the customer is intending to buy and what you are promising to sell.

Are you selling items or outcomes?

I have talked with many resellers and consultants who position themselves as “trusted advisors.” When I hear this phrase I always think in my head, “to be trusted you need to be trustworthy.” This is not to suggest that most resellers or consultants are untrustworthy; but rather, to suggest that in order to deliver an appropriate solution, you need to work with your customer to determine their specific objectives. If you do not have clear, documented, prioritized business objectives from a customer it is impossible to do anything more than sell them items. How can you recommend the best solution when you are not clear as to what problem the solution is supposed to solve?

You may sell beautiful, shiny items. The customer may be infatuated with these items but underlying this “love at first sight”, if the customer expected a specific business outcome and if either the outcome is not achieved or if it becomes impossible or impractical to measure the outcome then the customer will eventually be disappointed. When the customer is disappointed they lose trust in the consultant or reseller. When trust is lost a profitable business relationship is also often lost.

So what to do?

As a customer:

1. Make sure if you are buying only items that you (and your boss) are not expecting a specific outcome (e.g. reduced costs, increased sales).
2. If you expect outcomes then include a list of these outcomes in any discussions with potential solution providers or in any RFP documents.
3. If you need help defining, prioritizing and documenting outcomes or need to better understand what outcomes are reasonable to expect, consider working with a reputable industry consultant.

As a reseller:

1. Decide if you are going to sell your solutions as items or outcomes and then position and market them accordingly.
2. If your customer is looking for an explicit or implied outcome make sure you understand, and document, what these outcomes are. Meeting expected outcomes is critical if you plan to have an ongoing business relationship or get a good reference from the customer.
3. Where you decide to sell items, try to avoid implying specific guaranteed outcomes.

As a consultant:

1. Help your customers understand the difference between the “what” (the business benefits) and the “how” (the technology selection). Resist discussing “how” before the “what” is defined.
2. Work to define the mechanism that will be used to measure the overall success of a UC or Collaboration project.
3. After implementation of a UC solution, measure the outcome to prove the project was a success.
4. If you do measure your projects outcomes, consider sharing this information as a case study. (The May issue of Internet Telephony contains an article entitled “Measuring the Success of UC” where I explore this topic in more detail.)

Understanding whether you are selling items or outcomes to each specific customer can greatly improve your overall business success as a reseller.

The upcoming UC Summit will provide a great opportunity to continue the item versus outcome discussion with other consultants, resellers, vendors and industry experts. If you are interested in how the distinction can improve your business please consider applying to attend. If you are unable to attend, please consider continuing this discussion online by commenting on this article.

1 Responses to "Selling Outcomes Versus Items" - Add Yours

Art Rosenberg 4/16/2012 8:50:29 AM

Kevin,

Very insightful view for identifying and evaluating UC enabling technologies. I would suggest that when it gets down to specific business processes and applications that will benefit from UC enablement, the "what" and the "how" have to be aligned with the "who" of a specific business process, i.e., which individual users or types of users will be involved and benefit from the "how."

This consideration is becoming particularly important as Mobile UC gains increasing traction with smartphones and tablets, as compared to any desktop user benefits. Mobility is a big driver for individual end user adoption, but, as you point out, the solutions not only have to work functionally, but also have to be acceptable at the end user application interface levels. So, its not just infrastructure (that end users could care less about) that is important, but how well designed the end user interfaces are for a variety of different UC enabled applications.

That suggests, as you recommend, an even greater opportunity for consultants and solution providers to support UC planning and implementation by helping design, trialing, and evaluating UC-enabled business process applications. With the increasing role of "cloud'' based services, that opportunity is becoming increasingly easier and more cost-efficient to implement.

In addition, inasmuch as UC enabled applications are primarily software based, means that they will be constantly evolving and changing and thus open to being supported and managed on an ongoing basis by the third-party expertise that originally developed those applications, rather than by internal IT resources.