Technology services organizations have typically evolved into “leveled” teams, with each subsequent level possessing a higher degree of expertise or specialization.  As cases moved through the organization, they were escalated based upon a finite set of criteria—such as Case Age, Severity, Priority, and Customer Category. Customers became sensitized to this model, and accepted it for many years. In the last few years however, enterprise and carrier-class customers have transitioned to a demand for faster results that cannot be serviced by this time-driven and hierarchical structure. Hours and days are now minutes and hours. Call-backs are now live hand-offs. Escalation has transitioned from “soon” to “real-time”. Many support centers have attempted to adjust their systems, processes, and people to adapt to these new requirements, but have not eliminated the hierarchical structure that is the foundation of their institution. This presentation will help to frame that problem, as well as provide a transition roadmap and “10 Tips” to help drive your support center to a real-time, multi-level, collaborative, problem-solving machine.

Historical Perspective

Hierarchical support teams typically organize into levels that involve Customer Service Representatives (CSR), Technical Support Engineers (TSE), Escalation Engineers (EE), and then some type of interface into the Development Engineering group.  Sometimes this team is referred to as “Level 3”, and sometimes as “Sustaining Engineering”.  Each of these levels has a definitive management structure that is wholly self-contained and focused on its own goals and objectives.  Management career paths within these teams work in numerical order, meaning that a TSE Manager aspires to be an Escalation Manager, who then strives to become a Sustaining Engineering Manager.  Frequently these “leveled” teams are geographically isolated, sometimes to the extreme of actually being located in different countries.

Cases coming into the hierarchical support model tend to move in very “linear” fashion. CSR’s do documentation and case-opening. TSE’s do technical triage and handle more basic issues. EE’s get handed the case when a timer goes off, or when a customer is angry, and the move to Engineering to handle bugs is usually the last resort. Typically, a higher level will not consider working any case that has “skipped” a level.  Most cases actually have case ownership fully transferred to the next level, where they are worked until the case is either resolved or escalated. Typically, teams are measured and metrics derived solely upon the execution of the sub-team, with macro-based metrics compiled at higher levels for more senior management.

In Search of a Better Way

The nature of this hierarchical support model is problematic in today’s fast-paced, collaborative-hungry customer environments. Probably the biggest problem is that the leveling, by its very nature, contributes to a caste system where those at higher levels feel like they are somehow “better” than the teams at lower levels. Compensation, title, prestige, awards, all tend to support this caste system.  Another problem is that the finite boundary between teams tends to have knowledge “pool” within the individuals and teams making it difficult or even discouraged to share information. Those that have the information guard it closely, because it is their value-add to the organization, and the key to their higher level. This model also creates a discontinuity in the communications path, ensuring that for the tougher cases, at least three or four engineers are involved in verbal or written communications.  An interesting phenomenon of this hierarchical support model is what I call the “Kill & Ignore” loop. This is a situation where you “kill” the customer with requests for information, and then you “ignore” them for long periods of time as you desperately hope the problem solves itself. Escalations are viewed as a “failure”, so it’s important to hold cases at your level to avoid losing that precious case-closure metric.

Enterprise customers need…

The expectations of enterprise and carrier-class customers have reached a point where they now demand access to senior-level resources much more quickly.  They expect you to know about their environment and not have to ask basic questions, and they expect the involvement of very senior engineers within a very short period of time.  Frequently, these customers have contractual Service Level Agreements that will drive alerts and escalations, and if the problem is rooted in a piece of information that was previously known but not proactively communicated, well, stand by for a good spanking or financial penalties.  The days of being able to say “Oh, that’s a known bug” are drawing to an end.  These customers now expect “systems” that enable, “processes” that expedite their issues through the support bureaucracy, and “people” that can execute flawlessly around those systems and processes.  These are hard expectations to live up to.

Case Closing Culture

Solving this problem and living up to these expectations takes a change, a shift in how the entire company thinks about customer support.  Adjusting to what I call a “Case Closing Culture” is critical to success in these high-availability, no down-time environments.  The collaboration must be in real-time vs. delayed.  Escalation needs to be over-the-shoulder instead of queued.  Systems must deliver a much deeper view of the customer’s environment, instead of simply understanding the level of service entitlement.

10 Tips for Killing Hierarchical Support

#1 – The upside-down org chart:  This is a very powerful concept, and a difficult one to institutionalize.  The idea is that everyone in the company is an employee of the person on the phone working the issue with the customer.  They all live to serve that individual, and there is no higher calling that to help that person get a case successfully closed.  This will be an especially difficult concept for Escalation Engineers and those that have been living at the higher levels of the support “food chain”.  You have to focus these people through rewards, compensation, and the right combination of “carrot” and “stick”.

#2 – Architect to collaborate:  Physically design your support center so that multi-level teams of Engineers can easily collaborate.  At Network Appliance we have multiple engineering levels co-located, and the entire team can easily turn around their seats and “Meet in the Middle” to help any one individual who’s having a problem.

#3 – Ask useful questions:  Everyone in this business does transactional surveys.  Very few surveys actually provide useful information.  Frequently, they ask the same question five or six different ways.  Use your surveys to understand your customer issues, and to measure the progress of your key support initiatives.

#4 – Regionalize, then Personalize:  Instead of organizing your teams horizontally along levels, consider organizing them vertically to mirror your Sales and Field Service teams.  This model increases the likelihood that a specific customer will interact multiple times with the same support engineer.  Once you’ve perfected this model, you can drive to a “personalized” support implementation where you build a one-on-one relationship between an individual and a specific customer.

#5 – Streamline your problem resolution process:  A lot of companies wake up one day and figure out that they’ve got an overly complex model for solving problems.  This usually happens when they’ve created an environment that solves corner cases by adding new groups or processes.  Odd situations are best handled by exception within the normal group, instead of getting “creative”.

#6 – Encourage knowledge creation:  Get everyone into the act, including SE’s, Sales, Engineering, and especially Support.  Make it fun and rewarding to create quality knowledge and make it especially rewarding to create knowledge that gets re-used to solve problems

#7 – Measure what matters:  Don’t overwhelm yourself with metrics.  It’s easy to do in this business.  Pick about a half a dozen key management metrics that tell the larger story about the health of your business,  People ask me if I could have only one metric, what would it be.   My answer is always “Same Day Resolution Percentage”.  I believe that metric speaks to everything that is important about the health of your service business, including recruiting, training, systems, escalation, and knowledge management.

#8 – Train the “whole” employee:  Most support center directors do a credible job ensuring that their employees get an appropriate amount of technical training in whatever technology they support.  It’s also a fact that most of them do a terrible job of satisfying their employee’s need to progress in the areas of professional development and team-building.  Think about all three areas as part of a comprehensive employee training plan.

#9 – Lead to retain:  Attrition is your mortal enemy; it can degrade any support capability faster than the most contagious winter flu.  Make sure your team leaders are working with every employee to ensure that they can answer “Yes” to these “Big Six” questions:

1. Do I understand the vision and strategy of the company, my department, and my team?
2. Do I understand how my specific job contributes materially to the accomplishment of that vision and strategy?
3. Do I trust my leaders and do I feel that I’m well-led?
4. Am I correctly and fairly compensated?
5. Am I recognized and publicly acknowledged for my results and contribution?
6. Does my manager know my career aspirations, and are we working a plan to get me to that next level?

Through years of exit interviews, I’ve evolved this simple model to drive attrition to the lowest possible levels.  Every manager should be striving to address each of these issues on a monthly or quarterly basis with every employee.  Where this is used, attrition will be minimal.

#10 – Use partners wisely:  The correct use of partners and the wise use of outsourcing can drive customer satisfaction, allow focus, and save costs.  Unfortunately, the converse is true, where unwise use of partners in the wrong situations results in problems that only exacerbate and delay your movement away from a hierarchical support model.

About the Author....................................................................................
Rusty Walther has spent over 25 years building and leading large, global, technology services teams.  Rusty spent most of a 16-year career in the US Marine Corps designing, constructing, and managing a variety of worldwide IT systems for the Department of Defense as Director of US Marine Corps West Coast LAN, WAN, and Data Center Operations.  Over the next several years, Rusty held both operational and executive service leadership positions in some very large Silicon Valley companies like Bay Networks, 3Com, and Nortel.  In the heart of the “dot-com” boom and afterwards, Rusty switched gears away from large companies and participated in two start-ups as Vice President of Customer Support.  After leading AboveNet Communications and ONI Systems through successful IPO’s and acquisitions, he took a year off to do some writing and consulting before returning to a Customer Support leadership role at Airespace, Inc., a leading provider of enterprise-class secure wireless networking products.  Rusty joined Network Appliance as Senior Vice President of Global Support, where he leads a large, complex, and diverse enterprise support operation.