How should the user support decide on the priority of an issue? [closed]

Solution 1:

Start with trying to define things like :

1. Impact - how many people are affected? Just one, a group, or everyone? If it's just 1 person, are they a VIP or an already-angry customer that you want to keep?
2. Severity - how badly are they affected? Is the application down, or just slow overall, or is one piece of functionality not working properly? Is there a workaround available?

Make a matrix with these as the two dimensions, and the intersection is the priority. If Impact=max (everyone's affected) and Severity=max (application is down), it's a Priority 1. Everything else would be some degree of lower priority. How granular you want to get with that is a business decision.

/Edit - as an aside, it would be worth your while to read up on SLA, SLO, and all the other terms that go along with this. ITIL may be good background. I got certified with ITIL v2 Foundation, which is a good descriptive overview of how to deliver and support IT services. Don't read it prescriptively - treat it as knowledge that you can use to fit your situation. ITIL v3, I don't know as much about, except that it seems to have gotten more complex.

/Another edit - make sure that your dev and/or engineering teams is good at communicating with the front-line guys. If the front-line guys are given the info for how open issues are being handled, they should be able to say to a new caller: "Yes, that bug is a known issue, and we're expecting a fix next week once it passes QA", etc.

Solution 2:

I know of no such well-proven criteria.

That said, I do know what I run into with IT vendor support desks which does give a hint as to what a good set of criteria may look like. One such priority rating looks similar to this:

1. Informational -- User is curious about something, or planning for the future. No uptime/end-user impacts.
2. Low -- User has an annoyance, but can otherwise work
3. Moderate -- One user has their work impaired
4. Important -- One user can't work at all
5. Urgent -- Many users can't work at all, or are seriously degraded
6. Critical -- Whole department/office/company can't work, or are seriously degraded

Clearly, this is a scale defined by how much work is impacted. For ye olde average helpdesk, most issues will be Low/Moderate, with a healthy leaven of Important.

I know of some helpdesks that further prioritize within priority ratings by expected resolution time. That one bug in MS-Office that a user found is waiting on Microsoft to fix it, so it gets a lower sub-priority. The report of a print-driver issue by one user looks to also impact a bunch of other people and they haven't noticed yet, so that issue gets a higher sub-priority. That kind of thing.

Side-node:

Those 'Informational' questions can have a fair amount of good-will attached to them. Someone is coming to the helpdesk for expert advice, and you can make friends by responding in a timely way. If it can be answered quickly, definitely do so.

Solution 3:

This is my opinion based on observations of our help desk (which I'm not involved with):

1. Critical Severity/High Priority - User/Company Down: Any issue that prevents the user(s) from using your application in any way, shape, or form. This means they presumably cannot do their job in any sense (if their job relies on the use of your application).

2. Medium Severity/Normal Priority: User(s) able to use your application at a reduced level of functionallity or performance: These issues present an inconvenience to the user(s) but do not prevent them from using the application and the features required to do their jobs.

3. Low Severity/Low Priority: These are issues that don't prevent the user from using your application and the required features. An example might be a user who needs to know how to set a particular option or setting in the application.

Every user should get a phone call or email within your stated SLA time window to inform them that their communication/issue has been logged and that they'll recieve a response from you within the stated SLA time window. The purpose of the call/email is not to resolve the issue but to facilitate the communication between you and the customer. There's nothing worse than having a customer wait for a call/email confirming that their issue has been recieved and is being attended to.

Try not to get too crazy implementing various levels of impact, scope, severity, etc. because you'll wind up spending more time "managing" the system/procedures than you will attending to issues. Keep it simple at first and make adjustments as needed. Our help desk uses 3 levels of Severity paired with 3 levels of Priority: Critical/High, Medium/Normal, and Low/Low.

Solution 4:

From my experience working in support, we had TWO criteria: priority and severity.

Priority

• can be set by the submitter (it's their environment, after all)

Severity

• determined solely on technical merits of the case

Interaction of P and S levels

• when all cases of a given Severity are available, choose the highest Priority ones first
• from a given customer, arrange the issues based on Severity, or tell them they need to pick which is actually their "Priority 1" - they can't all be showstoppers

Example

• Customer has a non-down issue (can't figure out how to configure X), but it's important to them (boss breathing down neck, impending deadline, etc)
• customer calls and opens a panic, Priority-1 case
• Support determines it's a Severity 3 or 4 level based on technical merit
• determination of "how important" the specific customer is (all companies have their more and less needy, and their more and less important customers) - adjustment of Severity level may ensue
• Customer only sees it's a P-1 because that's their view
• Support sees both values, and works the case in accord with internal escalation/preference policies