Production Support Models To Adapt For Your Business

More and more businesses are developing their own applications to help support their business processes and to improve the customer experience. In fact, it’s not uncommon for even small to mid-sized companies to develop multiple apps of varying complexity. However, when your company deploys such apps, it must be able to provide continual support for them.

Maintenance and support of these applications can be challenging, especially as your user base grows and your apps become more complex to support user needs. Production support is incredibly important to the success of your applications. However, there are two main types of production support models that you can choose to implement.

What is Production Support?

Before exploring the two production support models that you’ll want to consider, you need to understand what production support entails and why it’s so important to your organization. The term “production support” encompasses the practice of providing support for IT systems that are currently in use.

Production support can be provided internally by a single individual or an entire team, which can consist of developers, system engineers, as well as database administrators. It can also be outsourced. Your production support team is ultimately responsible for monitoring your production servers, troubleshooting issues, scheduling jobs, and managing incident cases.

Why Is It Important?

Developing software is one thing, but actually maintaining it is a whole different matter. Support is essential to helping users troubleshoot application issues and addressing bugs or user interface problems. A lack of support can significantly hamper the user experience, hurt the customer experience on customer-facing apps, and hinder employee productivity on internal-facing apps. Good production support will also help reduce the risk of downtime and identify areas in which applications require improvement.

The Tiered Support Model

The tiered support model is the traditional model for production support. It’s a linear model that involves organizing your IT support into three different tiers that consist of three different teams: the service desk, the technical management team (also referred to as the application management team), and the development team (or the vendor). While each team is responsible for different aspects of production support, they work together to help minimize downtime, minimize outages, and ensure that users are satisfied.

Organizational Structure

Let’s take a more in-depth look into the three main tiers of a tiered support model:

  • Tier 1 – The Service Desk

The first tier is the service desk. They receive all of the support requests from users. Think of the help desk as the first line of defense. They are responsible for solving the majority of the issues that come through. Many of these will be basic issues that can be solved with general technical knowledge. The service desk should be capable of solving around 70 percent of the tickets that are submitted to them. If they aren’t capable of solving a case, they will escalate it to the next tier.

  • Tier 2 – Technical or Application Management Team

The second tier consists of the technical management team. This team consists of individuals who have more specialized knowledge and skills. Issues that are escalated to this tier tend to require more technical know-how and may take longer to solve. If the technical management team cannot solve the problem, they will escalate it to the third and last tier.

  • Tier 3 – Developer or Vendor Support

If the problem can’t be solved by the technical management team, then it goes to whoever developed the application in the first place. If the app was built internally, it will go to your development team. Since they built the app, they should be able to address whatever the problem is and find a way to solve it. If the app wasn’t built internally, the problem should be escalated to the vendor. Only very complex issues are sent to the developer or vendor in a tiered system since they will be using valuable time and effort to address the problem.

When It Makes Sense to Use This Model

The tiered production support model can be an effective one, but it depends on a variety of factors. If most of the issues your users tend to experience are simple, then a tiered support system should be able to handle your production support needs. You won’t need a great deal of support if you don’t deploy a lot of new apps or changes to existing apps, which means that a tiered support system will suffice as well. There are also a number of benefits when it comes to implementing a tiered structure. These include:

  1. Single communication channel – Users will find it easier to report their issues since there will only be a single communication channel to use, no matter what their issue might be.
  2. Easy to obtain workforce – Individuals with the technical support skills required to work at the service desk or as part of the technical management team aren’t difficult to find in the workforce, so outsourcing these positions is relatively easy.
  3. Avoid wasting resources on minor issues – A tiered model will insulate your specialist technical resources from direct contact so that you’re not wasting their time and resources unless it’s for matters of utmost importance.

Challenges To The Tiered Support Model

Although a tiered production support model might seem like a simple and effective way to implement a production support system, there are some drawbacks that you should be aware of. You might encounter some of these challenges when implementing a tiered support model:

  1. Queues can build up in the first tier – Because every ticket automatically gets submitted to the first tier, your service desk won’t be able to address every issue right away. The service desk reacts in real time, so new cases go into a queue until they’ve finished with current cases. If your users have a lot of problems all at once, many of those tickets will languish in the backlog of your help desk.
  2. Preventing issues from reaching the correct resolver – While there can be an advantage to insulating developers from every issue that gets submitted, it can also cause problems. For example, if users are having issues with an app due to a problem with the code, then the developer should address that issue. Unfortunately, a tiered system will prevent the issue from reaching the developer since it has to go through the first two tiers before it can reach them. In cases like this, a tiered model essentially puts your best resolvers at the back of the process by blocking the route of the ticket to the correct resolver.
  3. Cases often bounce back – When a case is moved in a tiered system, it means that the team that’s assigned to it is changed. A newly assigned technician sees the case ticket for the first time when it arrives in their queue. The problem is that if the technician or team requires more information to solve the problem, they’ll just bounce the case right back to where it came from. This can result in support tickets bouncing around with little communication between teams.

The Swarm Model

A tiered support model has a definite structure for providing production support to users. In many cases, such a structure can work for an organization. However, there are also many potential drawbacks. If you build a lot of complex apps or routinely add features or make improvements, you may want to consider a different model. The alternative to a tiered support system is the swarm model. The swarm model contains no single definitive structure — instead, it’s a process based on collaboration.

Principles of Intelligent Swarming

The swarming model was first developed by Cisco in a white paper that they published in 2008. This model was adopted by the Consortium for Service Innovation. The principles of intelligent swarming are defined by the Consortium for Service Innovation, which further developed it:

  • The model should not be structured using tiers
  • If an issue is not resolvable at the point of customer contact, swarming should be initiated right away
  • Support tickets shouldn’t be “escalated” from one group to another
  • Whoever is assigned the case should be tasked with resolving it
  • Cases should immediately be directed to the correct resolver

Initial Triage

To “triage” is to assign a degree of severity. In a swarming model, a case that cannot be solved immediately is quickly distributed to one of two types of swarms. Each swarm consists of a small team that works on cases coming in together in real time until they are solved. The following are the three types of swarms that a swarm model consists of:

  • Severity 1 Swarm

Cases that are considered critical issues and that are designated a priority are sent to the severity 1 swarm. This team responds in the appropriate way, bringing in the right people to solve these cases as quickly as possible.

  • Dispatch Swarm

The dispatch swarm addresses cases that can be solved quickly by the right expert. They are essentially focused on cherry picking cases. In a tiered support model, cases that can be solved quickly are often buried in the queue. A case that could take five minutes to solve may end up taking days in a tiered support model. With a swarm model, this case would be identified by the dispatch swarm and solved immediately.

Cases that have not been cherry picked enter a more traditional queue for product-line focused support teams to solve. Cases that are particularly challenging will be tackled by the best support people available. Since the entire team works in collaboration with one another, communication is constant, which allows cases to be assigned to the right resolver. Typically, a dispatch swarm team will meet every 60 to 90 minutes to maintain this constant collaboration.

  • Backlog Swarm

The third swarm team is the backlog swarm. This swarm team usually consists of experienced analysts and R&D (research and development) engineers that meet on a daily basis. Their primary focus is to solve the most challenging cases brought to them by the product-line support team in the dispatch swarm who can no longer engage individual subject matter experts on the case.

Upsides Of The Swarm Model

The question is, why use a swarm model instead of the more traditional tiered production support model?  Not only are there several major advantages to using a swarm model, but they address some of the drawbacks of using a tiered structure. Consider these upsides:

  1. Solve tickets faster – One of the biggest disadvantages of a tiered model is that if there are a lot of cases, they can get backed up in the queue until the support desk is able to get to them. With a swarm model, an entire team picks through the cases to figure out which ones can be addressed right away, thereby keeping the backlog as small as possible.
  2. Collaborate more effectively – In a tiered structure, there is no collaboration. Cases just get bounced around if the person assigned to them can’t solve it. This can result in cases floating around in limbo for long periods of time. Using the swarm model, teams meet with each other and collaborate regularly to ensure that every case reaches the correct resolver right away. This way the case doesn’t bounce around and helps keep the queues light.
  3. The model is easy to implement – Because there is no rigid structure, a swarm model is easy to implement. In fact, it’s arguably much easier to set up than a tiered model due to the flexible organization of teams and the individual autonomy provided to team members as a result of the cherry picking process.

When It Makes Sense To Use This Model

If you’re constantly developing new apps or adding new functionality, you can expect to receive a lot of support tickets. A swarm model would make sense in this environment as it provides immediate attention to failures or degradation in performance. If the complexity of your apps require a lot of different skill sets to provide production support, then the swarm model makes more sense as well.

Finally, organizations with smaller teams or IT support may want to consider the swarm model. Smaller teams are more likely to be overwhelmed by cases that will linger in their backlog in a tiered model, whereas with a swarm model, they can work together to solve cases quickly.

Choosing Between The Two Models

Production support is necessary for any organization that develops and deploys apps for their customers or employees. However, the model you choose depends on your needs. A tiered production support model can work perfectly fine if a lot of your support tickets tend to be similar and you have a large IT team at your disposal. But companies with smaller teams that receive cases demanding different skill sets may be better off using a swarm model.

Need advice as to which model fits your business’ needs? Consult with our experts today.