Archive for the ‘cloud’ Category

Customer Support for Cloud Services – Expectations

December 18, 2012 Leave a comment

cloudThis is the first post of a series on how the profile of technical support is evolving with the advent of Cloud Computing.

I have worked with these kinds of services for over ten years now, starting back when a cloud on a diagram meant the internet in general, and as new providers and consumers come into the market it is worth sharing a few personal recommendations and considerations.

My hope is that support is not an after-thought and is considered as a core part of cloud service design.

Accessing applications over the internet is hardly new, but exactly what is being offered has reached a tipping point. Using just a modern web browser and a standard internet connection, it is now finally practical to access the internal business systems that were previously the reason people had to travel to an office. Evolution of I.T. security, networking capabilities, and user interface technologies has finally untethered corporate workers, not to mention allowed the delegation of their provision to expert teams, including from outside the organization.

This is all fabulous, however the reality of trying to work with Business Applications that are managed, maintained, and supported externally contains many subtle considerations that many providers seem to leave as an after-thought.

  • Transparent Processes. Often consumers of cloud services are frustrated by the fact they cannot get administrative tasks done quickly. This can be just as bad internally too, however usually someone knows someone who can help. Once you step outside the organization, the provider creates a process black-hole. As such everyone should be clear how each main category of request is raised, and who is responsible for its completion.
  • Severity Setting. If googlemail is unavailable it’s not critical but if work tasks are impossible things escalate quickly. Many people like to use the utility metaphor, inferring uninterrupted operation and consistent quality, but I think it’s more like TV service than water or power, as even a slight or temporary change in quality is obvious. Any issue that impedes task completion is inherently critical, so automatic fail-over or temporary workarounds need to be readily at hand.
  • Time To Resolution.Β  Service Level Agreements (SLA’s) are certainly good in principle, however they’re often vague commitments based on operating targets, with little negotiation available to include additional consumer requirements. A classic is the response time targets for different categories of problem, where the actual quality of the response is not-specified, meaning that it could just be an update saying thank you and they’re looking into the issue.
  • Service Administration. Like SLA’s, custom service provision is not scalable, however Business Applications require a certain amount of options. Just like website providers offer pre-built templates, utility tools, and ready-to-install components, the Application provider should consider what value-add services surround the applications use and how these can be implemented in a hands-off, totally reliable way. One example I have seen is a integration hub that allows setup and management of messages in-and-out of the application.
  • Functional Administration – Business Applications rely on extensive feature setup, and some of these items have dependencies that spill over into the technology stack. As such it should be documented exactly which features can be configured under the different levels of access available, including what might require assistance of the service provider – and how to get this completed.
  • Technical Administration – With cloud services now including Platform and Infrastructure as a Service, the provision of administrative consoles and management tools to service consumers should not be of concern. The problem is that for Applications they often run in standardized technology stack configurations that are locked-down to ensure consistency and reliability. Also multi-tenant deployments helps provider cheaper services but prevents any one consumer from changing the underlying shared technology components.
  • Configuration and Customization – In exactly the same way, messing with configurations and adding custom objects and code impacts standardization, the foundation of scalable service provision. Modern applications solutions understand the requirement and are offering ways that abstract changes away from the core instance, thereby retaining the stable base whilst offering the features demanding businesses require. More on this in future posts.
  • Troubleshooting Tools – They key here is to understand WHO is expected to do WHAT and WHEN, and WHICH tools are available to do it. Often cloud-based applications offer some diagnostic tools, however they are rarely publicized and getting solutions requires the service providers input, slowing things down considerably.

Future posts will illustrate in more detail how various features and recommendations can be used to enhance these tricky parts of Cloud support.