Support Workflow – Internal

Now let’s explore, at a high-level at first, the workflow for a typical Support engagement. This is depicted in Figure 1, and from our point of view it’s a two-step process: 

Step 1: Self service. The first step, we hope, is for the end user to attempt to solve their problem themselves. In many cases the end user will ask their colleagues for help and will often get it, particularly when the end user has an issue that an experienced end user understands. When this doesn’t work the next thing the end user should do is take advantage of your self-service offerings, such as online help, a frequently asked questions (FAQ) knowledgebase, online videos, and so on. Hopefully your self service offerings are sufficiently robust so that they don’t have to contact your assisted support options (which are expensive).

Step 2: Assisted support (if needed). Let’s start with the more common, indirect support version of this step as shown in Figure 2. In this case an end user engages with the support desk, perhaps by calling in or via a chat system. The front-line support engineers provide “level 1” support and handle most incidents on the spot. Sometimes an issue is too complex for them to handle, or perhaps they don’t have the authority to resolve the problem, so they bump the incident up to “level 2” support, which is typically a more senior support engineer or even the support manager. Many incidents are resolved at this level. Sometimes an incident requires someone on the delivery team to address it, so it is escalated to “level 3” support (now this has evolved into direct support by the solution development team, more on this in a minute). 

Some organizations have a “touch and hold” strategy where the support engineer who accepted the initial request for help stays with it throughout any escalations. Sadly, many organizations do not take this approach and hand off the issue from one person to the next, with the potential for the incident to get routed to the wrong person or even dropped.

Now let’s explore direct support, depicted below in Figure 3. This strategy tends to occur in two situations: 

• Escalation. As described above, an incident gets escalated to the solution development team from the support team. This development team may be a sustainment team who at some point in the past has taken over responsibility for the system from the original development team.
• DevOps. It may be the case that the original solution development team took a stable, product team approach to development where the team sticks around and continues evolving and supporting their work. In other words, they’re taking a “you build it, you support it” strategy that is common with a Disciplined DevOps approach. Having developers interact with end users can be expensive, but it also has the benefit that developers directly learn about what end users are struggling with, which in turn tends to lead to them developing better solutions in the long run.