A member tells how to prioritize help desk tickets with the concepts used in banking for automating the credit approval process. These tips could help you free up technicians and improve help desk response time for users.
Several years ago, after having worked as a financial manager for several banks, I made a career move to IT manager. Though I’d previously designed, developed, and managed financial information systems for these banks, this was my first enterprise IT manager role.
After being on the job a short time, it became clear to me that I had to make some procedural improvements, particularly in the area of the IT Help Desk. At that time, the Help Desk was plagued by the usual problems—high call volume and technicians and users who were frustrated with the prioritization of service requests or tickets.
We bought a new CRM system that included a Help Desk module that prioritized tickets based on the user’s request or according to the best guesses of the technician. This wasn’t acceptable. I needed a way to systematically prioritize responses in an objective and timely manner and in a way that allowed me to centralize the rules, monitor how things were working, and then easily change the rules in the system, if needed.
The idea was that technicians would work off a prioritized queue and really not be concerned about the reasoning behind the prioritization. If we could automate the call logging and priority setting, we could use the customer support operators to log IT requests instead of using technicians, whose time would be better spent serving the users.
Putting an old trick to use
We struggled with several approaches in the development of a centralized set of rules. That’s where my bank experience came in handy, and I proposed using the “credit scoring” method to prioritize our service. For some time, banks have been using the older concept of "expert systems" for credit scoring. The idea is to systemize the routine, high-volume credit approval process in a way that is fair and will stand up to all regulatory requirements. Basically, it’s a mechanism that provides points for attributes like having a job, amount of existing debt, years living at the same location, past payment history, etc. The points are then totaled for an overall score. The attributes and points are assigned based upon human decision rules (those of the lending officer), but the process allows the computer to add the scores and report them to the lender or systematically approve or reject the application.
If I could create a way for IT user tickets to reflect the correct weightings of attributes and then have them sorted in descending order inside the queue of the right technician, I could make a new technician immediately productive. I could also make a change in the rules without initiating a whole series of training meetings.
My team was pretty skeptical that we could pull this off, but they were willing to go along. We purchased a good system, and I had a very good MIS developer who was confident he understood my goals and objectives and had the knowledge and skills to implement them.
Setting our priorities
I called a meeting to discuss my ideas with those who were servicing the requests and their managers. We brainstormed and classified the types of requests into the common attributes needed in the system. Every company is different, but I started with the old “Who, What, When, Where, and Why” approach.
- Who: This attribute looked at the relative importance of who or how many people were affected. The bigger the impact, the higher the points. Higher points were also provided to special cases like traveling users because we would have limited access to their computers. Some examples of the value picks we came up with were: Entire Company, Sales Office, Department, User, Traveling User, Lost Sale, and Executive.
- What: Here we would look at the service affected, for example e-mail, fax, phone, or billing system. Each of the services was mapped to a person or a team that facilitated automatic routing. For example, an e-mail problem would be routed to the communications team queue and a CRM request would be routed to the MIS queue.
- When: This characterizes the type of response needed. These value picks ranged from Immediate to Same Day, Next Day, Next Week, or No Hurry.
- Where: This attribute included Departments, Airport, Hotel, and Home. A traveling user in an airport, working on a sale, would be allowed an immediate response, for instance.
- Why: This attribute clarified the nature of the problem with value picks such as Not Working, Intermittent Problem, Research, Question, or Workaround.
After we agreed upon the attributes, we decided on the number of points each value pick would be worth. This is where it got sort of fun. This type of thing can only be done by trial and error. The method we used was to score some history, look at the results, and make adjustments until we felt comfortable with the resulting order of the service tickets. Then, with ongoing input and good management reporting, we would be able to monitor the results and make appropriate changes.
Let’s follow a scripted scenario of three new service requests being added to the queue. In this example, the points range from 0 to 500 per attribute. As Figure A shows, when the new service requests are added to the queue, they’re prioritized by score along with any other items already in the queue.
As we can see from this example, three new tickets were inserted into the queue, and the president is placed in the proper priority. But you should keep in mind that this is a simple example. You can add other refinements, such as adding points dynamically to certain situations when the needed response time has passed.
Benefits of this system
This point-value system makes prioritization simple and goes a long way toward reducing frustrations on the part of both users and technicians.
- Service requests are objectively scored according to established rules.
- Technicians need only to work on requests in the order presented by the system in their queues and do not need to assign a priority.
- New requests are dynamically inserted in the proper order within existing queues.
- Service requests can be systematically placed with the right technician and in the proper priority.
- Training time for new technicians is reduced because they don’t have to understand the company’s or IT management’s priorities.
- Technicians have management support. When they’re confronted by irate users, they can justify asking them to wait.
- Support call logging can be done via a centralized help desk or Web site or via e-mail because the system will do the routing and setting of the priorities.