Leveraging Retrace for the Different Application Support Levels

Production support or operation support is an often neglected or underestimated area of the software lifecycle. From a business perspective, developing new features seems a bit more rewarding because it has direct impact to usage and users. However, it’s also important to realize that operation support is directly proportional to positive customer experience. From a customer relationship management stand point, operation support is equally important because it is key to keeping your users happy based from the fact that its impact to perception lingers throughout the application lifecyle. In this post I’ll share a production support model that may fit your current setup too and discuss how Retrace can help you achieve your customer relationship goals.

Support Levels

Production support has no one size fits all model. The model which a support team may operate on depends on the business model and other constraints impacting resources and requirements of the support team and the users. There are support teams which require different levels of support.

L1 support or level 1 support is the team in charge of receiving requests or reports directly from customers. Their main purpose is to be able to communicate and understand the customer on a functional level. L1 support resources are expected to be functional experts who have the ability to talk to customers using end-user level language, gather customer inputs, empathize with customers and understand business impact. They’re also responsible for setting the priority of the request based on urgency and business impact. Technical knowledge is not required for L1 support resources but they can be provided with a list of common issues with known resolutions which they can execute together with the customer. In the context of Retrace, for incident reports L1 support may be responsible for checking in Stackify the application dashboard, alerts and notifications to look for signs of deviation from expected levels of performance. In some cases, it may be mandatory to determine baseline numbers which the team can use to determine what is acceptable and what is not. This is where setting up of business-critical baselines, dashboards and alerts in Retrace becomes important because they can provide quick insights on the status of the application and effectively fast track verification and resolution of incidents. If the customer request cannot be resolved or fulfilled by L1 support, they can escalate to L2 support. L1 support must be able to articulate with L2 the request or incident report from the customer.

L2 support or level 2 support is the team in charge of keeping the lights on for the application (keeping it running - to be detailed out in another post), fulfilling technical service requests and resolving incidents which cannot be handled by L1. Since resources in this team have technical knowledge, in Retrace they should already be able to use traces, errors and logs to help determine the root cause of the problem. This team may also be responsible for identifying the conditions to replicate the incident reported. In most cases, L2 support team is given access to source codes and allowed to perform minor code changes. In this case they will have their own release stream which may be independent of the release stream of the development team. In some cases, L2 is even given ownership of the production environment and have more say of the production version more than the development team who is responsible for new features, big enhancements and major fixes. Proper guidelines must be set to help L2 and L3/development resources determine what changes should be in their respective scope. In terms of skills, L2 support is mostly composed of junior developers and testers with a couple of technical experts to guide them.

L3 support or level 3 support is the team in charge of addressing concerns which requires architecture level understanding of the application. This team can be composed of architects or senior developers who can make validated design decisions aligned to design, usability and security policies. In some cases, this team is the development team itself who is responsible for developing big changes to applications as new features, major fixes or major upgrades. In the context of Retrace, the higher the scope of the support team the more features of Retrace they usually leverage.

Rationale For Having Different Levels of Support

A software company may or may not have all three levels of support. In some companies, they merge the different responsibilities into one support team and in some they even only have the development team doing all the support and releases at the same time. It all boils down to the type of application, profile of target users and the cost structure of the company as far as operating the application is concerned. What is important is that the implications for such decisions are well understood. Like for example if there is only one team responsible for support and development, incidents and emergency customer requests will become unplanned tasks for the development team which means sudden changes to release schedules and added inefficiency due to context switching on the part of the developers which is highly discouraged in an agile development setup.

Whatever support model you’re using right now, it all boils down to it being a business decision which the leaders of the company make based on their big picture view of how things are and how they want to operate the business. One thing for sure is that leveraging automation tools such as Retrace helps an application support team be more productive and responsive to customer needs.