Helping IT get out of the way with reusable solution and fulfillment plans

A job well done is worth repeating. Or is it?

 

A central theme in the coming of age of IT in the era of social media and consumerization is the need for the Service Desk to offer better multi-channel means for delivering services and support. We have come to expect instant access to information and live real-time solutions. We do not care if the support comes from IT, because we quickly turn to friends or the web for the support we need. As one of my colleagues wrote in a recent post, IT can sometimes be of most help by getting out of the way and allowing users to help themselves.

 

It turns out that “getting out of the way” is a theme worth expanding.

 

More than Just Ticket Volumes

The fact remains that IT must still provide support for a very large volume of support tickets. It is typical for an organization with 25,000 employees to handle 30,000 support requests per month. The most effective way to save time and resources is to deflect as many of those requests as possible so they can be solved before a ticket is ever logged. But the next level of opportunity comes by making the handling of the remaining large volume of requests as streamlined and efficient as possible.

 

As expected, Service Desk agents today want productive ITSM tools that help them solve issues as quickly as possible. Their success is measured by how many requests they resolve each day—their performance is judged by KPIs such as mean time to resolution or total resolution volumes. To maximize these KPIs an agent who has become good at solving a certain type of problem will be rewarded for solving it again, and again, and again …

 

But is that what we really want? A better way lies in rewarding the service desk by measuring how many tickets no longer need to be resolved again tomorrow due to creative and reusable solutions found today. There are a few ways of accomplishing this. The approach I discuss here is the automation of solutions and fulfillment so that work can be done with minimal or no agent intervention in the future. (Another approach deals with the higher root level causes – drying up the support request flow at the very source. This is an important strategy that will be the subject of a future post.)

 

Automating Solutions

To illustrate the power of solution automation, I will share a recent experience we had supporting connectivity to a newly defined Application Service. We provided Intranet access to authorized employees and external access to named partners. Soon after launch, our service desk was inundated with connectivity access support requests as many users were not able to reach or login to the application. After a week of support, the following pattern emerged:

 

  • For employees unable to access the system, the problem pointed to one of two possibilities:
  • They were attempting access from home without using a VPN connection
  • They were VPN but needed to properly set one of the VPN protocol parameters
  • For partners, access issues were sourced in missing account registration information

We were happy that after gaining experience with the problem, the service desk was able to solve connectivity support requests rather quickly. A new access support request could be solved in ten minutes or so once an agent read the ticket and analyzed the situation.

 

Great job! Well … not exactly.

 

In reality, the problem remained that manual handling of these requests was still required. Tickets could sit in a queue for too long waiting to be handled. The agent still had to do the following:

 

  1. Monitor a support queue looking for connectivity tickets
  2. Manually run through a problem/solution script to test the various possibilities
  3. Apply necessary changes (such as changing a user’s VPN protocol or activating a partner account)

After doing the above a few times, things get boring. And expensive …

A better way lies in automating the “Application Access Support” request so that most of the above can be done with little or no manual agent activity. In the automated scenario, agents get out of the way and do less. Instead:

 

  1. End users request Application Service connectivity support from a predefined Support Offering. The resulting ticket is pre-categorized and assigned an automation flow.
  2. The automation flow checks the problem/solution paths:
  • When a VPN settings change is needed, an automatic response is sent to the end user with instructions
  • When a new account needs to be setup, this is done via an automated script

All of the above is done via an easy to define task flow that is associated to a reusable support offering defined against the Application Service. The following illustrates the core automation elements of this task flow:

 

 automation.png

 

In the end, manual agent handling of the support request is needed only in exception cases when the above fails to provide a solution.

 

Making it all work: It all depends on where you put your rewards

Are all support types candidates for automation? Probably not. However, analysis may show that a good portion of them can be fully automated, while most can at least be partially assisted by automation. A good automation solution starts by taking care of categorization, assignment and problem decision path analysis. When appropriate, further tasks can take care of sending notifications, running remediation scripts, updating accounts or executing more complex request fulfillment flows. Of course, when necessary, manual task assignments can invoke the help of a real expert.

 

Yet in the end, to make automation happen, IT must start by recognizing the value of automation and rewarding its implementation. It is time to consider applying new KPIs that measure Service Desk performance. The focus should not be on how much was done in the last reporting period, but how much was no longer needed to be done.

 

Comments
chuck_darst | ‎11-01-2013 10:00 AM

David,

 

A couple of thoughts -

 

First, I like your pragmatic example of (simple) automation. This is a good balance to the use of more orchestrated workflows in triage, remediation, change task, or request task execution. As automation becomes more pervasive within the service desk organization, it will need to play at multiple different levels.

 

Second and more philosophically, first call resolution is another common KPI that comes into play here. I like your post as it is a good illustration that high FCR's are not always desirable. As you illustrate, it is better to not have a service desk agent have to deal with the above scenario. Once the cause and effects were understood, they could handle the above fairly quickly and resolve the "ticket" on first touch. This is great for FCR on a percentage basis, but less desirable for the organization overall.

 

Chuck

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
David has led a career in Enterprise Software for over 20 years and has brought to market numerous successful IT management products and inn...


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation