Software solutions focused on cloud environments, especially SaaS (Software as a Service) solutions, inherently demand minimal customer support intervention. Simply put, the ultimate goal for any provider of such solutions should be to operate at a level of quality, reliability, and transparency that eliminates the need for user requests for customer support. And if we do encounter user demands for customer or technical support, we will likely discuss tools such as knowledge bases, discussion forums, or community support in this context.
But what about when we operate enterprise cloud solutions? These are cloud solutions designed for demanding customers who expect the comfort of continued customer and technical support, perhaps even considering it as a special benefit within their contracts.
Let's skip the debate for now on what a service agreement entails for cloud solutions. That would undoubtedly be a topic for another article, to discuss the advantages and disadvantages of various customer contract forms and whether or not we want to define the manner in which we provide customer support to end-users. As an example, in the context of cloud environments, we can think of comprehensive documents such as EULAs or Terms and Conditions. Usually presented to us immediately upon registration, it is challenging for most users to decipher the precise support parameters offered and make a decision to agree or disagree before confirming acceptance of these terms. Let us assume, for now, that we proceed more conventionally and provide customers with a comprehensive service contract for evaluation and signature, even for SaaS solutions.
Unlike standard on-premise installations, as an operator of SaaS solutions, you assume responsibility not only for the product and its quality but also for the quality and reliability of the environment in which the solution operates. It is naturally expected that if you have control over the quality of the product and the operating environment, you would also achieve a corresponding degree of efficiency (i.e., acceleration) in resolving any customer support requests, primarily of a technical nature (such as bug fixes or configuration). If there are defined KPIs measuring the speed of resolving support cases defined for on-premise products, the expectation for a cloud or SaaS service provider would be to achieve KPIs that are, for example, half or even shorter.
Please also bear in mind that these KPIs are primarily internal and serve as goals for intra-company communication. The cloud reality has not yet brought about significant changes in defining SLAs for user or technical support in external customer agreements. Like traditional on-premise software vendors, few SaaS solution providers still want to commit to additional specific support SLAs in customer contracts (let alone in publicly available terms and conditions) beyond standard response times for customer requests, which are typically under the direct influence of the support organization.
From the user's perspective, when it comes to the offered support, they generally don't delve into such detailed procedural considerations. If a user does have access to support and the provider offers it within the framework of a contractual relationship, the user's expectations usually focus primarily on response speed and, secondarily, on the quality of problem resolution. They typically do not consider the internal escalations or installation and configuration activities that may have been necessary within the company or organization. However, all the aforementioned parameters for measuring and evaluating support processes should strongly support these two aspects. It is entirely natural that just as the shortened adoption time of a cloud service is perceived as the biggest benefit compared to on-premise software, the same applies to its technical and user support. The era of the cloud is an era of acceleration.