By: Pierre Moncassin
Freebies can be hard to come by on budget airlines – but I recently received one in the form of a free lesson about designing service quality.
It was a hot day and I was on one of these ‘no-frills’ regional flights. This was obviously a well-run airline. But my overall perception of the service quickly changed after I asked for a glass of water from the attendant – who appeared to be serving refreshments generously to everyone on the flight. The attendant asked for my ticket and declared very publicly that I had the ‘wrong category’ of airfare: no extras allowed – not even a plastic cup filled with plain water.
Looking past the clichés about the headaches of no-frills airline travel, it did offer me a real lesson in service quality. The staff probably met all of their operational metrics – but that wasn’t enough to ensure an overall perception of a minimal acceptable quality. That impression was being impacted by how the service had been designed in the first place.
The same paradox applies directly to cloud services. When discussing newly established cloud services with customers, I often hear that quality is one of their top three concerns. However, quality of service is often equated with meeting specific service levels – what I would call the delivery ‘effort’. I want to argue, though, that you can make all the effort you like and still be perceived as offering poor service, if you don’t design the service right.
Traditional Service – Effort Trumps Architecture
Both budget airlines and cloud-based services are based on a high level of standardization and economies of scale, and consumers are generally very sensitive to price/quality ratios. But if you offer customers a ‘cheap’ product that they regret buying, all of your efforts at driving efficiencies can be wasted. Design, in other words, impacts perception.
So how do you build quality into a cloud service without jacking up the price at the same time? The traditional approach might be to add ‘effort’ – more stringent SLA’s, more operational staff, higher-capacity hardware resources. All of those will help, but they will also ‘gold-plate’ the service more than optimize its design – the equivalent of offering champagne to every passenger on the budget flight.
A Better Way
There is a more efficient approach – one that’s in line with the principles of VMware’s Cloud Operations: build quality upstream, when the service is defined and designed.
Here, then, are five recommendations that can help you Design First for Service Quality:
- From the outset, design the service end-to-end. In designing a service, we’re often tempted to focus on a narrow set of immediately important metrics (which might also be the easiest to measure) and ignore the broader perspective. But in the eyes of a consumer, quality hardly ever rests on a single metric. As you plan your initial design, combine ‘hard’ metrics (e.g. availability) with ‘soft’ metrics (e.g. customer surveys) that are likely to impact customer satisfaction down the line.
- Map your service dependencies. One common challenge with building quality in cloud services is that cloud infrastructure teams typically lack visibility into which part of the infrastructure delivers which part of the end user service. You can address this with mapping tools like VMware’s vCenter Infrastructure Navigator (part of the vCenter Operations Management Suite).
- Leverage key business-focused roles in your Cloud Center of Excellence. Designing a quality service requires close cooperation between a number of roles, including the Customer Relationship Manager, Service Owner, Service Portfolio Manager, and Service Architect (more on those roles here). In my view, Service Architects are especially key to building quality into the newly designed services, thanks to their ‘hybrid’ position between the business requirements and the technology. They’re uniquely able to evaluate the trade-offs between costs (i.e. infrastructure side) and perceived quality (business side). To go back to my airline, a good Service Architect might have decided at the design stage that a free glass of tap water is very much worth offering to ‘economy’ passengers (while Champagne, alas, is probably not).
- Plan for exceptions. As services are increasingly standardized and offered directly to consumers (for example, via VMware vCAC for self-provisioning), you’ll face an increasing need to handle exceptions. Perception of quality can be dramatically changed by how such user exceptions are handled. Exception handling can be built into the design, for example, via automated workflows (see this earlier blog about re-startable workflows); but also via automated interfaces with the service desk.
- Foster a true service culture. One major reason to setup a Cloud Center of Excellence as recommended by VMware Cloud Operations is to build a team totally dedicated to delivering high-quality services to the business. For many organizations, that requires a cultural change – moving to a truly consumer-centric perspective. From a practical point of view, the cultural change is primarily a mission for the Cloud Leader who might, for example, want to set up frequent exchanges between the other Tenant Operations roles and lines of business.
In conclusion, designing quality in cloud services relies on a precise alignment between people (organization), processes, and technologies – and on ensuring that alignment from the very start.
Of course, that’s exactly the ethos of Cloud Operations, which shifts emphasis from effort at run time (less significant, because of automation) to effort at design time (only needs to be done once). But that shift, it’s important to remember, is only possible with a cultural change.
Key Takeaways:
- Service quality is impacted by your initial design;
- Greater delivery effort might make up for design issues, but this is an expensive way to ‘fix’ a service after the fact;
- A Cloud Ops approach lets you design first for service quality;
- Follow our recommended steps for optimizing service quality;
- Never under-estimate the cultural change required to make the transition.
Follow @VMwareCloudOps and @Moncassin on Twitter for future updates, and join the conversation by using the #CloudOps and #SDDC hashtags on Twitter.
