Home
 > Research and Reports > TEC Blog > A Suggested Workflow to Complement Issue Management Syste...

A Suggested Workflow to Complement Issue Management Systems

Written By: Raluca Druta
Published On: October 16 2012

When companies buy software tools what do they expect from them? Guided by common sense, one might think that a software tool is expected to render clunky manual methods gracefully automated. As a result, information and knowledge would be diligently arranged in databases and easily searched, found, and accessed.

Let’s imagine, for instance, a customer relationship management (CRM) system and further look at its issue management component. What can it do? It can store cases as reported by clients (title, description, etc.). The software automatically assigns case numbers to make things easy. A priority can be ascribed to each case. Cases can be placed in queues or assigned directly to a person. Processes such as supervision or escalation can be embedded in the system as well.

So, once the system is installed and in place, no more manual tracking of issues, no more Excel, no more confusion!

But let’s not fool ourselves. Remember David Knights’ invitation to “challenge and question the ‘taken for granted’ in order to expose the dangers immanent to ‘commonsense’ (link opens PDF).” Organizations do not expect an issue management system or any software tool only to turn the manual into automatic. The phantasm that a software solution is the hero that will solve all business problems is so strong that people forget the fundamentals of machine functioning. As Kipling’s poem goes:
But remember, please, the Law by which we live,
We are not built to comprehend a lie,
We can neither love nor pity nor forgive.

And while we’re still imagining, let’s think of a human resources (HR) software vendor acquiring a CRM system, specifically to facilitate the work of client services consultants (CSCs). One day, John, a CSC, receives a phone call reporting a bug. John goes straight to the issue management system and opens a case. Remembering the calm voice of the client, John decides the priority of the case is “low.”

But, the phone rings again and John receives another customer complaint. Another case is opened. During that same day, John also hears about installation and integration problems customers are encountering when they deploy the latest version of the software on a server. More cases accumulate in the newly acquired CRM.

A week later, the case with the lowest priority has not been addressed and the phone keeps ringing.

Customer support employees are overwhelmed. There’s no secret in that. But, can a tool that tracks customer support issues help them single-handedly?

I propose a workflow that can complement an issue management system. However, this is not definitive advice. What I’m attempting here is to re-think how a workflow can accommodate the continuously changing human-machine interaction. Also, I recognize that in a world that is hungry to ascribe meaning to everything, a software tool fulfills its expected purpose predominantly within planned processes.

Rewind. Suppose the client services team designs a flexible workflow to address the issue management process. The workflow does not revolve around the issue management software. The workflow is harmonized with the CRM system to prop the team, because it makes sense.

The team thought it might be useful to organize tickets by category (i.e., training, development, IT, product development, other). So as soon as a CSC enters an issue into the system, he or she will ascribe a category to it.

So when John receives a phone call reporting a bug, he enters the issue and assigns a category. The next step would be for John to check the client services knowledge base, according to the category, to see if the solution already exists. If it exists, John can close the case. If not, the system will automatically assign the ticket to the right department (based on the category that it belongs to).

To ensure that the system is not cluttered unnecessarily, an experienced CSC verifies that each case received the appropriate level of priority and was placed in an appropriate category. He or she will also set the response latency. For example, one day for high-priority cases, two days for medium-priority cases, and 4 days for low-priority cases.

Another important thing that the team decided was to set reminders before deadlines are reached. If deadlines are not met or cases exceed a CSC’s ability to handle them, they can be automatically escalated to a supervisor. He or she can either form a team of consultants to tackle the cases or resolve them him or herself.

Once an issue is solved, the ticket is closed. In addition, the ticket can be transferred into a knowledge base after it has been clarified and edited.

Finally, John and his colleagues are empowered by the issue management tool by integrating it into their work processes, as opposed to relying on it to do the job on its own.
 
comments powered by Disqus
Popular Searches

Recent Searches
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Others

©2014 Technology Evaluation Centers Inc. All rights reserved.