These days it seems as though everyone is talking about the pros and cons of cloud computing - from cost savings to potential security implications.
As one of Gartner's "Top 10 Strategic Technologies for 2010" it has moved from being an aspiration to become a reality, with business benefits being realised and consumers enjoying reduced costs and easy access to applications.
One aspect of cloud computing which will be vital to its long-term success and is particularly pertinent to the channel, is that of user support. When a business switches to a cloud-based model, how can it be assured of quality and timely support? And with a business's applications often residing across a combination of both private and public clouds, whose responsibility is it - the provider or the reseller?
It is widely accepted that user (often consumer-related) support can get bad press. Many of us have experienced endless toing and froing between remote call centre operatives, which leaves us feeling dissatisfied and none the wiser at best, or angry and frustrated at worst.
From a service provider's perspective, remote and home users in turn present their own challenges, often having widely differing needs and diverse levels of technical understanding and experience.
Whether they provide the support themselves or rely on a reseller or value-added distributor, it is the vendor's reputation that is at stake as users are most likely to associate a problem with the application itself rather than with how it is delivered.
For resellers, the issue is how to provide the right level of support to clients in a way that is cost-effective and practical for them to manage and deliver.
Definition and documentation
The key lies in setting realistic expectations and ensuring they are met. By establishing and documenting a clearly defined and quantifiable service level agreement (SLA) between the provider and user, resellers can ensure that their clients are satisfied and the supply chain can operate cost-effectively.
Precisely what level of service should be expected is down to the individual needs of the business and what is considered to be critical to its operation. For some that might mean guaranteeing response times to support calls, for others it might be acceptable levels of downtime for e-mail, for example.
Like any business agreement, a good SLA needs to be drawn from first-hand experience of tried and tested business practice. What might look good on paper may not work in reality. But in the case of cloud computing - a relatively new business opportunity which resellers may not have had experience of putting into practice - where can they draw that experience from?
Many resellers may be able to base SLAs on agreements relating to other outsourced services. More often, however, it is safer for a reseller to draw on the expertise of those that have first-hand experience of setting and maintaining service levels, such as their distribution partner, even if it is the reseller's responsibility to provide the support. Ultimately, an SLA must reflect what the provider can realistically achieve, not just what the client demands.
Escalation and compensation
Not only should the SLA define specific levels of service, it should also detail formal escalation paths. The client needs to know who to contact in the first instance should a problem arise and not be resolved, and also who to escalate it to should they not receive a satisfactory response.
For those rare occasions when the SLA is not met, penalties need to be clearly defined within a solid contractual agreement. These might be financial, in the form of compensation, but can prove to be contentious if not clearly documented from the outset. And to ensure that the SLA is relevant to current business practices, regular service reviews should also be built into the agreement.
So, as with any service, setting realistic expectations is key to user satisfaction. It is down to us in the channel to keep our clients happy and ensure that the reality of cloud computing delivers everything we say it will.
This was first published in February 2010