Managing the Complexity of Technical Support
Technical support personnel routinely find themselves wading through the unknown waters of increasingly complex and heterogeneous applications and hardware platforms. The promise marketed to customers is the convenience of whatever, whenever, and wherever; yet little thought is given to how we support the promise.
Technical support is drowning in choked network traffic; a sea of converging technologies, data, and media competing for system resources; and unique configuration landscapes for each customer. Positioned at the tail end of the value chain, technical support has little say in what is sold and how it is crafted and implemented.
Incident management and troubleshooting activities can become a blame game of “theirs not ours” fire-fights, personal best guesses, or problem escalations by irate customers. Problem resolution becomes a probability—not a certainty.
Using increasingly connected yet disparate technologies, customers expect their business to be supported homogenously, despite the complexity of their IT infrastructure. Organizations that are oblivious to the realities of their customers’ complex, interconnected, IT environments are at risk—as are those that think they can outsource this complexity.
A common theme that reverberates across our client landscape is that the technical support function lives on the edge. Can they be in control? We believe so.
This article discusses the weaknesses of support functions from the mission-critical support function perspective, and presents a scalable resolution process that can be applied to any product, platform and technology.
Improving Support: Approaches that fall short
While the good news is that managers and decision makers within the customer support function now realize that the support world is increasingly complex: the bad news is that the success of improvement initiatives is sporadic. Even in the best organizations, initiative success plateaus quickly and return-on-investment falls below initial promises.
Here is what has not worked well:
- Increasing technical training
- Relying on script-based support
- Bolting on more knowledge tools
- Using performance averages as a key measure of success
Ironically these seemingly ‘right steps’ follow a logical sequence that drives organizations in an endless loop of ineffective reforms and new initiatives that sap resources and frustrate customers.
1. Technical training is critically important for the effective management of the support process. Typically training accounts for 5-6% of the support center budget and support center staff average about three work-weeks per year in skill development. Most training takes place during employee orientation and new product launches. Even with the best intentions, training falls short because of the capacity of human learning. A support person can be certified in two, three, maybe four products, but that certification does not bring expertise. No technical training manual can simulate the configuration complexity and dynamics of a customer’s unique IT infrastructure, and the analyst is left to improvise. This results in inconsistent support, the leading killer of customer satisfaction scores.
Technical support folks swim expertly in known waters but when exposed to situations where they lack knowledge and experience, they sink. Ask any support analyst – the biggest job hazard analysts face today is the near certainty that the next ticket will fall outside their expertise.
Skills-based routing is a band-aid rather than a permanent fix for assignment and scheduling challenges. The routing rule typically assigns problems about a product to a defined expert. ACDs (Automatic Call Distributors) are installed to facilitate the process. This often leads to situations of feast or famine that burn out ‘good’ resources while ‘other’ resources are underutilized. Using history to schedule the right product specialists in anticipation of the next mission-critical support ticket lacks efficiency and effectiveness. Despite efforts to have technology and systems in place, the backlog of cases never comes down. And when complex problems arise, routing fails.
2. Product-based scripting is used by management to improve the performance average and is the founding principle of the outsourcing model. All one has to do to shatter management’s belief in scripts is to listen to a scripted attempt to resolve a mission-critical ticket.
Frontline folks have no problem following the script, often to a fault. Scripting works for a well-known or routine situation. However, the moment the situation deviates slightly from the script, or the customer raises a complex issue, the script falls apart. The customer, sensing the scripting and the failing logic, assumes that the issue is outside the analyst’s bandwidth and questions the veracity of the help desk. Trust is gone.
With the growing complexity of support, a script is dated the day it’s created, and its utility is diluted from then on.
An analysis of warranty costs also demonstrates the failure of scripting. The use of scripts shows near perfect correlation to the volume of service parts shipped and site services scheduled. Calls are closed at the helpdesk level, at great cost to the organization, and, in many cases, the diagnosis is wrong.
3. Knowledge management (KM) tools provide a solution when training and knowledge sharing are not working and the cost of service is escalating. Management comes under pressure to minimize the human element and install KM tools. Service technology accounts for 6-7% of support center budgets and nearly 70% of organizations undertake KM projects every year. KM seldom facilitates quantum leaps in customer satisfaction scores or reductions in mean time-to-resolve. On the contrary, more technology exposes and accelerates support failures.
Consider a typical scenario. Analyst A solves a problem and puts the solution into the KM solutions database. Analyst B comes across a similar problem (maybe matching, maybe not), but doesn’t use A’s solution or root problem because B considers his or her way the right way of troubleshooting. So, B adds a version of the solution. Or, Analyst B believes that both problems are the same, finds A’s solution, and sends the same patch, even though it’s not the right one, and consequently causes more problems for the customer.
KM tools, regardless of their sophistication, are probably the most misused pieces of technology in support organizations.
4. Mean-based performance measures disguise the failure of scripts to improve satisfaction scores and of KM tools to fill these gaps. An organization can report a reasonably good MTTR (mean time-to-resolve), but hidden under this statistic are the extreme tickets. These are the problems that drag on, devour energy and resources, and damage customer satisfaction (extreme scores that are buried in mean customer satisfaction scores.)
Mean-based reporting creates a cycle that rewards the “fix first, solve problems later” attitude. Once the ticket is open, there is hardly any emphasis on appraisal and process – the goals are to meet the SLA (Service Level Agreement) and bring down the severity of the situation, rather than troubleshoot it to a close. The case logs become endless e-mail threads of requests for log files that create wasteful dead-time when nothing is done to resolve the case.
ITIL’s incident management process has great potential, but standardizing the incident management process on top of a disjointed troubleshooting process is unlikely to yield sustainable results. The long-term solution for helpdesk and technical support functions is a defined process that is independent of technology, platform, language, or geography.
Before establishing this process, I invite you to view the support function through your customers’ eyes.
The Support Function – Why customers escalate
Customer feedback research in various industries and geographies reveals that customers have seven major problems with support.
These are:
- “My business need is not being addressed.” When a system / software / network / service fails, the customer’s business stops. You are supporting more than your product, you are supporting their business. Support your customer, not your product.
- “The quality of support is inconsistent.” Your customers demand the same high standard every time. Deliver consistently.
- “I don’t know what you’re doing on my problem.” Customers become unhappy when they don’t know what is going on, or think that you don’t know where you are going. Guide the customer.
- “My problem is not being solved.” Customers need the correct fix. Troubleshoot incisively.
- “You’re taking too long to fix it.” Customers need their business back right now. Be fast.
- “I want a permanent fix, not a workaround.” Customers need their problems to be fixed permanently. Prove it.
- “Why am I getting problems at all?” Customers would rather avoid problems: prevention is better than cure. Get ahead of the curve.
All initiatives within the customer care function must have these seven areas of concerns front and center at all times. These customer concerns are the platform on which the mission critical support process is built.
Resistance: We have a process; why do we need another?
The claim of already having a troubleshooting process is tested by the consistency of support. Plot the time-to-resolve rates by product and by support person. The normal curve will highlight the variability. The variability reveals if indeed there is a process, it is not being followed.
Often analysts do not believe in the process they have and use their own way of troubleshooting. Such rogue processes are not only invisible but frequently break down whenever there is anything out of the ordinary.
Many organizations appear to be resigned to mediocrity. They need something fundamentally different to establish customer support as the winning element of their business strategy.
An industry-wide survey conducted to self-assess support center performance reveals that many organizations appear to be resigned to mediocrity. Clearly there is room for and a need for something fundamentally different to establish customer support as the winning element of their business strategy.
On the edge and in control: The Process
Superior knowledge and understanding of customer issues and their resolution is possible by using a rational process approach. This is done by acquiring skills in structured questioning techniques, improving the capability to use these skills in real-time, and building competency through repeated use.
This structured questioning becomes integral to customer interaction. Proficiency is achieved by creating a performance system that encourages the use of rational process in any support function. Independent of platform, technology, and support system, the rational process approach can be scaled up to manage the most complex challenges of the helpdesk and customer care landscape.
The process builds on existing knowledge and prevailing practices because it improves personal and organizational effectiveness. It supports and integrates any good organizational learning, systems, and customer management practices that are in place.
A rational process approach to troubleshooting mission-critical problems begins with appraisal, an assessment of the customer’s situation. Appraisal uses logic to assemble data and define the problem. This is followed by resolution, a process of identifying possible causes, testing them against the problem specification, and then selecting and testing the most likely cause.
Driven by the urgency to seek quickest possible resolution and close the trouble ticket, appraisal is often the missing piece in a typical support environment. Yet appraisal done right can accelerate resolution by preventing these common pitfalls:
- Over generalization – Information overload in voluminous case logs and data dumps obscures the specifics needed for effectiveness of subsequent actions. Watch out for terminology that obscures intents and reality. Assuming cause/effect relationships – The urge to chain together events in wished-for relationships undermines efficiency and leads down the wrong path. Watch out for the prevalent tendency to jump to cause and statements like ‘caused by…’, ‘due to…’, ‘…is causing.’
- Reality Confusion – With support personnel working on a 24×7 follow-the-sun model with customers from anywhere on the planet, perceptions lead to confusion. Watch out for multiple versions defining the same event.
- Emotions seizing rationality – Strong feelings at each troubleshooting step cloud the way data is interpreted. Watch out for irrational statements delivered verbally and in case log e-mails, as well as pouting silence.
- Overwhelming size of the mess – An issue becomes too big to be handled by a person or even a group. Watch out for the participation count and frequency of tech-support bridges.
Appraisal is not a finished product: it is the keystone to effective troubleshooting. Appraisal is a dialogue among customers and frontline and backline support. It is a collaboration that leads tech support from a complex, often obscure reality to actionable steps. When done right, appraisal overcomes confusion at the crossroad of adaptive solutions and effective resolution.
Effective appraisal helps support personnel wade through issues with focused questions and techniques:
- “What do you mean by…?”, “What else do you mean by…?” breaks apart generalization and particularizes action.
- “How are we so certain that this is due to that?”, “What tests have been conducted to prove it?” avoids assuming cause/ effect relationships.
- “What evidence do you have…?” differentiates what actually is happening from what should be happening.
- “What else is bugging you…?” acknowledges the feeling of overload and encourages reflection.
Driven by quickest possible resolution, it is easy to jump to cause. A process approach to resolution can accelerate troubleshooting if you avoid these common pitfalls:
- Symptom or cause dilemma – Taking a stand on one or the other. Watch out for inadvertently ignoring the customers’ business priorities.
- Poor or inadequate definition of the problem – Too much irrelevant data or very few facts. Watch out for repeated and ambiguous data requests, vaguely described should and actual performance, and ever changing facts.
- Biases override troubleshooting logic – The urge to prove but not test the assumptions supporting hunches. Watch out for possible causes that have weak, fact-absent, unreasonable assumptions.
- Closure before confirmation – Allowing the MTTR metric drive closure. Watch out for closing a ticket without first proving it to the customer.
How does rational process guide escalations? Escalations usually occur when the frontline is stretched to its limit of knowledge and experience. Using a rational process approach, the frontline hands off a ticket that is structured precisely the way the backline would have structured it. This reduces repetitive interaction with customers and avoids dead time.
Customers: Logic builds understanding
Personnel identify root cause through these logic-driven questions and techniques:
- State the problem in an easily understood object / deviation format
- Specify the problem by assembling comparable facts on identification, location, time and quantification for the object experiencing the problem and similar but unaffected objects.
- Use knowledge and experience to generate the cause in a known environment. Use advanced techniques for uncharted territories.
- Test possible cause for facts before recreating the environment.
- Confirm true cause through facts, observation, research, and experimentation.
- Application of a logic-driven appraisal and resolution process has a profound impact on customer interaction.
When customers recognize that they are being listened to and not scripted, and that the analyst is asking a logical set of questions, it builds confidence and trust in the analyst and the organization.
At any time, any member of the helpdesk, not only the product specialist, can take a customer call and follow the same logic to make significant progress in the right direction.
Process Application: When, Where, How Much
The troubleshooting process can be applied full scale or in an informal, rapid-response mode.
Mission-critical support situations that are prime candidates for full-scale applications may be:
- High priority – High severity
- Reopened tickets
- Highly complex issues
- Unusual with no apparent solution
- Expensive, demanding a large investment in time and resources
Depending on industry and product maturity 5-10% of tickets fall in this category. However these tickets consume 30-50% of organization resources. Full-scale use of process can have a high impact on satisfaction, resolution, renewal, and cost metrics.
The vast majority of helpdesk situations are usually:
- High priority but familiar
- In need of an immediate response
- Easily resolved with knowledge and experience
Typically 15-50% of cases fit this category. Informal process application can result in serious improvements in satisfaction scores, consistency, and credibility building.
Results
Kepner-Tregoe provides a logical framework for troubleshooting. Through training, business process integration, and performance system improvement, the KT process has delivered stellar results in the support environment for Sun Microsystems, Dell, Cisco, EM C and others. Representative metrics include:
- 40% reduction in backlog
- 58% reduction in average time-to-close
- 41% improvement in first time fix rate
- 25 % reduction in case escalations to product development group
- 12,000 days-per-year cut from customer waiting times
- 37% reduction in incident/dispatch rates
- $10 million reduction in cost of critical account referrals.
Imagine the improvements bring to customer satisfaction.
Ready – What needs to change?
Several philosophical and structural changes need to occur to develop best-practice use of process.
Philosophically, we need a paradigm shift: the help desk should stop claiming to support a product or an application. The help desk is about supporting the customer’s business. It is about troubleshooting incisively while guiding the customer through the process, and then proving that the issue is resolved.
To realize structural change, focus on identifying and defining the critical-few areas that need improvement, not everything imaginable. A potential approach could be to focus on escalated cases that take longer to resolve; or cases that can typically be resolved faster due to their catastrophic severity but require inordinate effort on part of organization. Establish measures and causal factors specific to those areas and then map your current process. Invest time and resources in removing white spaces or gaps in the process, while continuously removing the no- and low-value steps. When the focus is on the critical few, the customer support function achieves rapid results and begins to realize lasting value.
Conclusion – It’s a journey
The end game is a journey across three dimensions:
Skill Development – To ensure that customer support team members have the skills and coaching support needed to be successful.
Process Integration – To ensure that there are clear links between skills acquired and business processes.
Performance System Integration – To ensure that the work environment (expectations, measures, tools/ resources, consequences and feedback) is conducive to using the new skills and the process.
A rational process that is independent of a specific product or technology enables customer care to cut across products, platforms, and technologies. It provides a solid framework for supporting the customer’s business by managing the growing complexity and continuous change of the technical support environment.
About Kepner-Tregoe
Kepner-Tregoe is the leader in problem-solving. For over six decades, Kepner-Tregoe has helped thousands of organizations worldwide solve millions of problems through more effective root cause analysis and decision-making skills. Kepner-Tregoe partners with organizations to significantly reduce cost and improve operational performance through
problem-solving training, technology and consulting services.