Service Excellence Through Smooth Incident Workflow

You've taken an incoming incident, contacted the affected user and tried to troubleshoot/fix the reported issue. But you are not successful. You've determined from your incident triaging that this needs the specific application support team to look into it. You call the respective SME for the application and it feels like you're suddenly standing in front of an impenetrable wall. Try as you may, the SME is not convinced the issue falls in his area of responsibility.

If you've spent any length of time in an IT help desk environment, you can instantly identify with this scenario. A great chunk of a help desk agent's time is spent in influence and negotiation with other teams when an incident cannot be resolved at the help desk level. In some cases it can be an efficient transaction between two colleagues and the help desk agent can move on to the next customer in the queue. Many times though, it turns into a tug of war, the customer and the issue reported long forgotten by either parties.

Over the course of many such years spent in various incident management roles, I developed a "toolbox" of techniques like most of us do, all in support of one most important point of focus - getting the customer back to BAU service level in the least possible amount of time.

Incident Triaging and Logging

One of the first things I learnt as part of my training and orientation was to log events in realtime on the support ticket. This was helpful in multiple ways:

• An organised sequence of events that any other engineer working on the same incident can refer to and understand what efforts have already gone into attempting to fix the incident
• A future reference for yourself and other helpdesk agents if the same user/same issue gets reported again
• Harnessing the power of basic incident triage through some standard questions (and of course noting the responses in the incident log)

1. Are you trying to access this feature for the first time? (instantly tells you whether this is an incident or more suited to an access request workflow)
2. When did you last use this feature successfully? (helps to go back to the history of the customer incidents / service incidents and try to pinpoint what changed since last successful access)
3. Are your colleagues also impacted? (helps to determine how widespread the issue is and also narrow it down further to access issues or local issues specific only to the affected customer)
4. What is the error message, any screenshot available? (helps to further articulate the issue and also search older incidents / knowledge articles where similar errors may be reported)
5. Are other services working fine? (helps to determine if the customer has a common issue that is affecting access to more than one application, for example an expired login password or a disk space issue)

Due Diligence

When queues overflow and the number of customers overwhelms, a reality check helps to assure yourself that you've truly tried everything possible such as:

1. Referred to the available knowledge articles
2. Gone through the customers incident/request history
3. Checked the incident trends for the day in case other customers across your network are also reporting the same issue but the volumes are maybe not yet high enough and a trend hasn't yet been identified.
4. Checked if there are any existing problem tickets that indicates this is a known issue with the service. Is there a published workaround or any guidance on the problem ticket as to how to at least provide a temporary fix to get the customer back to BAU?
5. Had a quick check-in with other colleagues on shift / your team leader to see if anyone else has seen a similar issue and is aware of a solution.
6. You have a clear picture of the issue and have narrowed down to the problem statement to the best of your abilities. If you are not able to articulate your findings to the next level of support clearly, it is that much more challenging to convince them of the efforts that have gone into the incident already.

It's Not What You Say, It's How You Say It

This stands true for any human interactions, be it personal or professional. It has been one of the hardest and most rewarding lessons for me personally to learn in this space of incident management.

If your conversation comes from a place in your subconscious that just wants to be done with the incident and "pass the buck", this will come out in the tone and the words you choose to speak about the incident. It is no surprise that the conversation then becomes more confrontational, full of resistance, annoyance and somewhere in the midst of all that negativity, the customer and the service interruption they are experiencing lies forgotten to one side.

However if you're operating from a place that is actually concerned about the customer's experience and the service interruption that is not allowing them to meet their target or deliver value to their work - the right tone and words automatically follow. The conversation is customer-centric with a view to genuinely sorting the customer's issue out and that results in a team-oriented effort to focus on service excellence.

Close The Loop

Take the time to note the incident references that you had to reassign to others. On quiet days, revisit those incidents to see how the next level of support resolved it. Is there a potential for a shift-left here, where the help desk could get a little training/handover or maybe a new knowledge base article that could bridge the gap and help deliver better service to the next customer who reports a similar issue? Making it a point to go back to cases you could not resolve in the first instance opens doors for these conversations and interactions with other teams in your wider IT organisation. With a consistent approach and a willingness to bridge these knowledge gaps, and you will be more respected by these teams for your initiative. The next time you have an incident to assign to these teams, they will take you on your word that you have tried everything possible before you made that call.

Building Relationships

If you are consistent in your incident management approach and put in high quality customer service and technical troubleshooting efforts, over time you will develop a good, healthy relationship with your colleagues placed in other levels of support. The conversations become easier, you understand each other better. Over time, you pick up on trends such as what are the right questions to ask for specific scenarios, what answers do SMEs expect you to have on hand when you approach them that demonstrates the efforts you've put in to solve the issue etc. The focus firmly remains on the customer and service excellence.

I hope these insights from my personal experience working in at IT help desk environment help to improve your own game and add value to your playbook.

What techniques have you come up with, do share in the comments!