New Mission of Technical Support

The mission of Technical Support has traditionally been stepping in when things go wrong (incident management) or assisting clients when they need something (service requests). I started my IT career as a Technical Support Engineer many years ago and still remember the days of the heavy focus on the reactive work and the entire organization, starting with hiring practices all the way to performance KPIs, being built around it.

Things have shifted quite drastically within the last few years, and it seems the Service Providers are finally waking up as well.

As I work with organizations to uplift their Technical Support operations I’m always excited to hear the objectives of employee empowerment, internal and external brand advocates development and culture of proactivity and ownership being identified. There is no doubt we need to change the way we have been servicing clients for so many years, and it is not an easy task. Here are facts shared by Roy Atkinson HDI’s senior writer/analyst:
• Incident management is the most widely adopted ITSM process
• The majority (54 %) of contacts to the support center are for incidents
• First Contact Resolution is a top metric
• The volume of incidents continues to increase year over year

The majority of contacts to the support center are for incidents.

The fundamental problem is that we are still looking at how good and fast we are at fixing things. Unfortunately things still break and at times more then ever. I’m not suggesting that nothing should go wrong, and I have no doubt that incidents will continue to happen. With that said, however, the primary mission of every Technical Support leader today should be influence expansion and problems being addressed at the root.

The HDI research published last year, discovered that

  • 73% of support teams are dissatisfied with their current level of involvement with development process.
  • 32% do not share knowledge articles between the support and development teams.
  • While 89% of organizations have a change management process implemented, only 49% of organizations have one that works.

Couple more staggering facts form the research:

  • Only 74% of support teams are notified when the software is operationalized.
  • 22% are involved in prioritizing development sprints
  • 37% included in discussions about requirements, needs, or use stories

“Support teams need to be engaged much sooner… Too much work in a vacuum— too many silos.” says the report. It would be fair to say that Technical Support is in the reactive mode from the very beginning, being blindsided by the changes from the start.
As a person who managed Support Centers for many years, I can tell you that it has generally been an uphill battle to get involved in producing, operationalizing, testing, updating, and releasing new technologies into the production environment. But when it did happen, it made a world of a difference not only driving support towards the mission of being proactive, but also empowering the frontline to “own” the technology customer-facing on every call we took and every email we answered.

As we are to change the way we think about everything we do, I’d say set a new mission for your Support Organization of higher influence and aim to build a strong partnerships across the company starting with the Development team.