Time to Isolate (TTi) – “What takes you so long?”

I’ve been in high tech now for nearly 20 years, and I’ve spent the majority of those managing remote support delivery teams. You may know us as, technical support. The guys and gals with the headsets that assist you in resolving technical problem(s) once you get past the administrivia of our phone tree, websites or self-help systems. We’re also the folks that from time to time say things like, “we’ve never seen this before,” or, “let me check on that and get back to you.” Hopefully those messages are delivered in a way that leaves you with a sense of urgency and our desire to resolve your problem as quickly as possible.

The intent of this article is to briefly touch upon a less commonly discussed measure of the problem resolution lifecycle called, time to isolate (TTi). TTi is a sub-element of the traditionally measured time to resolve (TTR). However, TTi is the more important measure of the two given fault isolation is a prerequisite to providing a fix. What’s even more interesting, the fault isolation process can account for more than 30% of the overall TTR number. So you can see how important it is to measure.

TTi also has dramatic effects on cost of service and customer satisfaction in terms of product quality impressions. Point being, while TTR maintains its relevance from an overall perspective, more time and effort should be given to fault isolation and more specifically those things that enhance and constrain your organizations ability to quickly identify source problems.

So, why does it take so long to resolve technical problems? Aren’t products smarter now? Can’t they self-heal, or tell us more about why they’re sick? Don’t “Knowledge Management” systems provide easy to find fix paths that reduce the time to resolve (TTR) a problem? Don’t companies today track “TTR” and provide case and product quality trending data back to development and serviceability teams for inclusion in next generation products? If the answer to the questions is, yes, then again, why does it take so long to resolve technical problems?

For a perspective on “why,” let’s take a moment to review the anatomy of the problem resolution lifecycle. I’ll list the high level lifecycle elements, and include a few examples that will help provide context for each.

Problem Resolution Lifecycle (simple view)

What’s important to note about the model above is the following: a) we have a problem resolution lifecycle, b) a portion of our lifecycle is spent in fault isolation, and c) the objective is to reduce the time spent in orange chevrons notwithstanding complexities like a client’s environment, the product itself, or the market segment being served.

How often do we think about the fault isolation process? Do we clearly understand what constrains our teams from separating code defects from network environment deficiencies and or from performance related problems? Do we consider how the TTi components of the problem resolution lifecycle drive support costs? If not, you should because you’ll never achieve real gains in TTR reduction without understanding what’s constraining fault isolation. And, more likely than not the solution to TTR reduction “isn’t,” more training.

So, if more training for my organization isn’t the answer, what is? Fortunately or unfortunately, it’s typically a portfolio of things with training being one. Here are some of the areas I think about when considering the efficiencies of our fault isolation process:

A. Organizational Talenta. Does our current bench strength (technical skill set from L1-L3)) align with our

products, technologies, and market segments?b. Are we developing our talent to match the pace at which technology turns?

Problem Discovery

Initial Customer DiscoveryAlerts, System(s) unavailable Symptom Trending..etc...

Vendor Contact

Open case processSelf help systemsCall back

Fault

Isolatio

n

Logs, traces, dumps..tasksAnalysis, ..repeat data collectionHypothesis of problem

Problem

Resolution

Communication of "Plan of action (POA)"Fix plan and expectations are set

Fix Deploy

Monitor Customer acceptance of fix

Case

Closure

Problem resolvedCustomer acknowledgement of resolution

Case Open

This is “TTi”

Identification

Time to fix

“TTR”

The goal is to identify TTi constraints and reduce this time range

Note: The elements in your lifecycle may differ from those in the model above.

B. Knowledge Management a. Do we have a strategy, and are the benefits known at all levels of the support

chain?b. Are we commoditizing problems by turning “unknowns” into “knowns” for a

scaled-out standardized solution approach?c. Have we established “knowledge maturity index” measures (KMI) for each of

our support teams? (In general terms, KMI measures the percent of cases resolved with content linked and marked as solved.)

C. Serviceabilitya. Are we driving serviceability metrics back into product development teams?

i. Cost of serviceii. Product quality trends from KM system and other product alert

systems such as “Dial-homes.” b. Have we established key “interlocks” between our support, field and

development engineering teams to more quickly mitigate product quality trends?

c. Do we have serviceability tools embedded in our products that proactively identify code defects?

D. Organizational Alignmenta. Are we silo’d in vertical support teams, or do we have an end-to-end

solutions-based support approach?b. Do we have a clear collaboration methodology that’s supported by agile

systems or processes? (Right problem to the right person and the right time)c. Do we have strong and trusted relationships with key “fix” constituencies such

as product development?

Given the influence TTi has on TTR, the question becomes, should TTi and TTR be measured and tracked separately? The short answer is, yes. TTR (measured as the total time from case open to case close) is affected by internal and external forces in addition to those forces within the fault isolations process. So as a standalone metric, TTR fails to tell the real story. My recommendation is to partner with your business intelligence team (assuming that’s not you ) and begin sketching how best to capture TTi within your support systems. Once you have the data visualized within reports or dashboards, you’ll have a lot of attention and interest in improving the numbers.

If you’re not sure where to begin, start by hosting informal meetings with your support teams with the objective of characterizing your fault isolation process. Once you have the constraints nailed down, consider who or whom is likely best positioned to help alleviate those constraints and go from there. Be open and listen carefully as its likely going to be a number of issues driving TTi. The good news is with the right business intelligence data supporting your findings, most organizations are willing and excited to improve customer impressions of their products so finding teams to partner shouldn’t be difficult.

So there you have it. I hope this brief discussion at a minimum causes you to consider TTi if you haven’t before. Lots of companies implement objectives that target TTR, but they’re often too high level,

targeted at an improvement in number only, and rarely spend enough time truly characterizing the constraints that prevent aggressive fault isolation. If you’re really interested in driving down support costs while improving customer satisfaction, consider investing time in what’s driving your TTi, you’ll be glad you did.

Neil Fulton

Customer Service