The Business Imperatives Behind Quality of Experience (QoE)

There are many terms circulating across the industry for managing customer experience. Some of the more technical focus on more established metrics such as quality of service (QoS), and for VoIP, mean opinion score or MOS. However, there are also a growing number of metrics targeted at accurately capturing the real experience of IT’s consumers (both internal and external), such as real user monitoring (RUM) and quality of experience (QoE).

I personally prefer QoE, as it suggests the open-endedness of actual “experience,” when it comes to IT services, which can be affected by everything from response time and availability, to navigability, security, consistency—even aesthetics. It is significant that QoE-related initiatives are typically driven by the business, with strong executive involvement. But this makes sense given that QoE isn’t centered in technology, but in the flesh-and-blood experience of the person consuming IT services.

This focus is a lot like MOS was originally intended as it applied to telecommunications services. Like it or not, how IT customers “feel” about their services is, in the end, how they’re going to spend their money. And, since QoE resides in the hearts and minds of IT consumers, the dimensions of understanding QoE can be as complex and differentiated as one might expect once you combine human “sensibilities” with a wide range of IT services.

For some users, mobility might be more important than super quick response time. Security may be “the” value (and often is when critical records or financial transactions are at play). Or poorly designed applications can present issues of navigability. “Ugly” applications can cost you and your business revenue dollars and brand loyalty. But the heart of the problem is most often centered around response times.

In some research on QoE adoption conducted in Q4 of 2008, we saw that 79% of our respondents viewed QoE as becoming more important to their organizations. Only two percent viewed it as less important. And the vast majority (71%) viewed QoE as both a business and a technology concern. Employee productivity was the core driver, followed closely by business competitiveness and revenue. And, when investing in solutions to support QoE, most respondents expected that their investments would not only alert to a problem with user experience, but help to point to where and what the problem is. This is what I like to call “triage.” I associate “triage” with QoE versus “diagnostics”, which are often done with more domain-specific investments or point solutions.

Pulling QoE Together

So, who should you include in your QoE teams? Based on our experience, you really need a mix of cross-domain expertise, from application managers and application developers, to network and systems managers, to service desk professionals. Some IT organizations actually have a “User Experience Management” group already in place that bears that name.

On the business side, you may be working with line of business executives. These are the people who feel the pain the most when, say, a salesmen at a home improvement store can’t effectively use a custom-built application to help customers see the value and impact of store’s products in their home environments. Or when medical users struggle in life and death situation because of slow response times. Or when a retail operation loses sales to competitors because of website navigation issues.

Other executives might come from online operations, or ebusiness initiatives, or service managers for business services beyond IT. There is no bureaucracy yet on the business side for QoE so executives tend to be most directly involved. Don’t forget trainers and process professionals. This group is 100%
dependent upon QoE information to make sure that, say, a new SAP rollout is effective from both an application design and a user productivity perspective.