Support and SLAs

Setting customer expectations of support and SLAs

In the previous lesson, we looked at how large volumes of customer feedback are handled using tools to operate a support model. It is also vital that we communicate our support offering to customers so that they have a clear understanding of what level of support they can expect. This is where our concepts of API maturity are instrumental. For experimental APIs, we can control the exposure to a limited set of customers because it is natural that the product and documentation are not thorough at this point and there is more support needed for customers to use such APIs.

It is standard practice for API product documentation to have a page dedicated to maturity. This maps each maturity level to the level of support provided. This allows customers to have an understanding of what to expect when they reach out to support for help. This mapping also involves expectations of how frequently APIs may change or whether any APIs are on the path to deprecation. Customers look at these pages to plan development and manage dependencies on their end to make sure their integration is stable and their customers are not impacted by changes to the underlying APIs.

For large customers, there are complex contracts in place that ensure a high level of support, along with a dedicated technical solution architecture team and technical support. Occasionally, product managers are also involved in advising large customers when high-impact features are released to make sure those customers have appropriate SLAs as part of their contract with the API producer. In the following section, we'll dive deeper into the operations details of support requests and learn how customer support requests flow through support queues, get escalated when needed, and flow back into product priorities to enable a continuous customer feedback loop across the product development life cycle.

Scale-based support models

For internal APIs, internal developers have the luxury of reaching out directly to the product and development teams supporting those APIs, but for partner and public APIs, the support channels are more formal. In this section, we'll look at support flows for public and partner APIs.

Earlier, we learned how API maturity is presented to and perceived by customers. API maturity is closely tied to customers’ expectations of the quality of the product and the maturity of any associated features or services. In the following diagram, we can see the operating model for a maturity-based support flow for large-scale API products.