Structured Problem Resolution, as we are implementing it at Symantec, is really two things—consistent processes and communications to achieve resolution, and a standardized method to record problem resolution data.

Benefits to both the Customer and Support Staff

There are a number of benefits that we expect to derive from applying structured problem resolution in our support cases. First, for our customers, we typically see…

• Improved communication in cases; this being especially important for “electronic” cases
• Increased confidence in support by seeing their engineer apply a standard problem resolution approach
• All cases have same look and feel, regardless of the product support team or geography resolving them
• Reduced time to case resolution by solving the right problem the first time
• Reduced case review time and rework as the case is passed from engineer to engineer

Second, for our support staff, we expect the following benefits:

• A “road map” approach is provided for case problem resolution (important for new support engineers)
• All support engineers can use the approach used by the best support engineers
• It will be easier to continue work on transferred cases (easier to pick up on the case flow)
• Important data points will be easy to find within the case
• A standard resolution approach will enable automation of routine resolution aspects
• It will be easier to “mine” case details for later use (such as content creation, root cause analysis, etc.)

Designing Structured Problem Resolution: Simple is Better

We pulled together a team of our best support engineers from across numerous product teams and geographies and gave them some simple guidelines for what we wanted to see. Through a series of workshops, the team came up with and refined the series of steps they felt were most prevalent in problem resolution for their customers. There was no technological “golden nugget” or mystifying new approach that came out of these workshops. The value of structured problem resolution is in the structured steps used to solve problems, the structuring of the cases in which we document the problem resolution and in the consistent application of common sense best practices. Simple is better.

Structured Problem Resolution Steps: Support “101”

0. Detection

A customer observes an issue and initiates contact with support. This step isn’t strictly within our support processes, but we chose to keep it here as a placeholder for future proactive work that we can do on behalf of our customers, i.e., proactive problem discovery and resolution. The goal is to continually look for support capabilities that can be moved out to the customer to be used as proactive self-service.

1. Recording & Classification

Verify that the customer is entitled to receive service, classify and document the customer’s issue and then route it to the appropriate product support group or department.

We differentiate between two types of cases; “problem” cases (also known as “break/fix”) and “How To” (consultative) cases. A case can move from a “How To” case to a “Problem” case (and vice-versa) as the support engineer finds out more information during initial support efforts.

Structured Problem Resolution Flow

2. Initial support

This is the first “technical” step for support. Here is where the issue is scoped, verified and the customer’s expectations are set.

3. Investigation & Diagnosis

Support engineer collects and analyzes evidence in order to establish probable cause for the customer’s issue.

At this point in the structured problem resolution flow, the support engineer is ready to provide some “next steps” for the customer. In the situation that the customer’s issue comes as the result of an outage, the support engineer’s first responsibility may be to help the customer restore their system/solution to a working state. Resolving the root problem would then be addressed. Our approach breaks the post-Investigation and Diagnosis step up in this way. “Step 4” may actually be a two-pass effort; one to restore system/solution and one to resolve the root problem.

4a. Recover System/Service

The support engineer has determined that there is a need to restore customer systems and services to a working state and provides the customer with assistance in doing so.

4b. Resolve Problem

Here the Support engineer works to resolve the customer’s root issue.

5. Incident Closure

The support engineer confirms closure with customer, manages any knowledge content changes that come about from this problem and finalize case closure details.

Case Structures

The other part of our structured problem resolution approach is the structuring of our cases. We have defined a number of “structures” (think “templates”) that a support engineer can use as they document their problem resolution efforts. Obviously, the structures align to the defined problem resolution steps, but they also extend them to enable the capture of data points relevant to that step. For a new support engineer, the case structures can serve as a “road map” to walk them through the same steps an experienced support engineer would use. For the support organization, these structures make the cases more readable and provide the opportunity to “mine” the cases. Wouldn’t it be nice, when taking ownership of a long-running case, to be able to quickly identify the specific research that the previous owner had done. Consistent use of the structures and steps also demonstrates to customers that there is a method behind the support engineer’s efforts.

Ongoing Activities

There are case activities that can happen at almost anytime during the life of the case. We wanted to describe these activities as structures so we could use them consistently throughout our approach and so we could “mine” them also. Examples of these ongoing activities are:

• Research
• Evidence Gathering
• Collaboration
• Reproduce Issue
• Knowledgebase Search
• Communication to customer
• Internal Meeting / Internal Con Call Notes
• Next customer contact
• Manager Comment

Best Practices

In the course of defining structured problem resolution, our top support engineers identified a number of “best practices” that they felt would benefit all support engineers. If all that this program accomplishes is the broader use of these best practices, we will see improvement in our support product. This is also where a lot of the common sense comes in; these best practices really are common sense. The best practices are:

• Establish case closure criteria at the start of the problem resolution efforts to limit the scope of the case
• Validate the results of each step to prevent rework at later steps
• Collaborate with your peers and/or the next level required before case escalation (transfers are expensive, seek help to avoid transfers)
• Run scripts where they are available (use the automation that is available)
• Accountability for content (search and use existing content, update / create content as required)

Deployment Approach

Our deployment approach for Structured Problem Resolution is typical of most support process deployments (you build supporting training material, train the troops, follow up on execution, etc.). Because moving to a structured problem resolution may significantly change the way some support engineers go about resolving customer issues and because conformity in using the approach is important, we are using a more interactive training approach. To help with conformity, we will be recording web based training modules to be used to guarantee that every support engineer gets the same message. This will be complemented with “champions” (approach experts) who will review the student’s cases to correct any misuse of the approach before it becomes habit.

To further encourage conformity and to ideally make use of the methodology seamless for the support engineers, we plan to apply automation. This initially will be simple automation aimed at eliminating the support engineers need to “cut and paste” the case structures into the case. We will then move into more complex automation that pre-populates the case structures as they are applied to the case (don’t ask the support engineer to re-key data that is already available). We have a working model of this approach in place today. The ultimate automation will be when we implement structured problem resolution as a CRM workflow that will move the support engineer through the approach, enforcing compliance to steps (i.e., no Resolve Problem step if the Investigation and Diagnosis step hasn’t happened). If this is done well, the tool becomes the process.

Take Aways

• Creating a new approach to problem resolution does not need to be like writing a doctoral thesis; simplicity and common sense can be integral parts of an effective problem resolution approach
• Your best experts on problem resolution approaches already work for you
• Adding structure to your problem resolution approach and to the way you document your cases can provide tremendous benefits within your organization and, more importantly, for your customers

About Lou Reents…………………………………………………………

Lou Reents is a Program Manager at Symantec, where he oversees a number of programs focused on improving Symantec’s Enterprise Support offerings. Prior to joining Symantec, Lou worked for eight years with another large software/services company, where he held positions from technical line management to organizational management to Global Operations. Support engineer process standardization and improvement, especially related to problem resolution, has been a focus area for Lou over the past 5 years.