Improving application support

We have a standard 3 level support model with the first and second level being part of a general support organization and third level being a part of a separate development organization. In this model support requests come in and are assigned by a Day Manager to the appropriate group for that application. From there requests get escalated through the levels if the lower level cannot address the issue or satisfy the request. We have had this model for quite some time and now we are facing some issues that are impacting the quality of service we are providing to our end users. The two biggest issues that we are encountering are:

1. lack of ownership for end-to-end support: as requests bounce around from level to level and organization to organization there is not clear ownership for getting issues resolved. Finding out when issues will be addressed requires emails back and forth between teams which means delays and finger pointing which ultimately results in unhappy users.
   
2. lack of commitment to knowledge building and continuous improvement: our focus has been mainly on fighting fires and there has not been enough focus on building the knowledge of team members and improving processes over time to be able to perform more effectively and efficiently.

Here is what we are doing to address these issues:

1. lack of ownership for end-to-end support: we are going to be testing a new "touch and hold" support model. In this new model we plan to flatten out the three levels into individual groups: one for operational requests, one for issue resolution and one for requests for data and adhoc reports. Instead of requests escalating from one level to the next until it gets to somebody who can resolve it our goal is to get the request to the right person or group of people upon receipt with no need to escalate. By doing this the person that gets the request should be the right person to address the issue and therefore there is no need for escalation. If that person requires assistance there will be technical and functional advisers available to assist but the initial recipient of the request still owns the request and is responsible for coordinating a timely resolution with the advisers assistance. In this model support engineers that receive support requests are empowered to reach out to users for clarification and negotiate services and resolution times, especially for complex requests and issues
   
2. lack of knowledge building and continuous improvement: each group in the new model should have a set of key metrics that indicate performance. I expect the groups might have some of the same metrics and some unique metrics individual to the group. For instance the operational group might have a metric based on average time to closure while the issue group might have a metric based on percentage of issues resolved or operationalized. The goal would be to use the metrics to ensure that each group is focusing on the right level of improvement and knowledge building. Additionally, we plan to build capacity into these groups for these tasks. Improvement and knowledge building take time so we need to accommodate for that time.
   

Focusing on these areas should result in more timely and accurate resolution of support requests resulting in more satisfied users and reduced support costs. I'm sure it will be an interesting experience as we progress through these changes.....I'll continue to blog about individual aspects as we move ahead. In the meantime if anybody has any experience with implementing a similar model please leave a comment and let us know how it went.