HelpSpotted

A common need of many help desks is to create a priority structure for incoming requests. While this is common, it is very often done wrong. Unfortunately technology is often to blame. Most help desk software defaults to having a 1-5 list of priorities with 1 being High and 5 being low priority.

A generic list like this can cause confusion and often makes the help desk less efficient. The reason is that there’s no clear definietion of which type of requests are high and which are low. This is especially true when trying to figure out if a request is a 2 or a 3, a 3 or a 4.

HelpSpot by default takes a simpler approach. Requests are either urgent or not urgent. For many help desks this is all you truly need. It also has the side benefit of being extremely simple to determine for help desk staff. It’s usually very easy to tell if something is urgent or not. It’s much harder to determine the proper place on a 5 point scale.

That said, in larger or more structured help desks having a priority system can be very effective. The key is to properly construct the priorities. In HelpSpot, it’s easy to do the technical aspect of this using custom fields. What takes proper planning and consideration is the priority scale, what it is and why it is.

A generic 1-5 scale with no reasoning behind it and no clear definition of what each point on the scale means is a recipe for chaos as each staffer makes their own determination as to what a 3 is.

The key to defining priorities is in understanding the business impact of a request. To do this you need to know how important the technology/product/person (a component) is and how severe an event is occurring. Some people are more important to a business than others, some technology is more important than others.

For example, in a small business where the president (component) handles most sales meetings, their email being offline (severity) is a top priority issue. A large company where an Accountant II (component) has occasional (severity) browser crash issues would be a lower priority issue.

There’s no universal formula here though, it’s very dependent on the organization that’s being supported. Is the support for internal IT or external customers and so on. The key thing is to analyze the type of systems that can be affected and what severity types those systems can go through.

If you’re unsure where to begin I recommend starting with a big list. List all the components you support, with each component list the severity levels that component can go through. Here’s a partial sample list:

• Email Server
  • Down, no email in or out
  • Intermittent connection error for all users
  • Individual user having connection issues
• VOIP Phone System
  • Down, no phone calls in our out
  • Inbound calls only, all users affected
  • One workstation has no phone connectivity
• Intranet
  • Down, unable to access
  • One module is unavailable to all users
  • One user is unable to login
• …

Once you have this information you can start to sort and prioritize into common and more manageable groups. It’s also good to keep this list available and updated so that it can be reviewed and priorities re-aligned quickly as needed.

Once analyzed create a scale. I personally think refining down to the minimum number you can is always best. 3 is much easier for staff to choose from than 5 so use the least possible while still capture the data you need. Here’s some examples of priority scales with useful definitions.

A standard 5 point scale.

3 Level scale based on severity and breadth of issue

These are just a couple of examples, coming up with your own based on your organization is the key. In addition, the logic and thought that went into each priority level should be documented (perhaps in a HelpSpot knowledge book) and available to staff as well as part of the training regiment for new staff. This helps ensure that all staff prioritize requests based on the same set of conditions and ideals.