7
votes

Here's the Problem:

I'm in charge of a user support hotline for a new server-based application in a large company. The application is not that good and we get a lot of calls and emails from our users. So far we're using an issue tracking tool (Jira) so manage all inquiries from our users.

Our support team processes the tickets with the highest priority first. We constantly have about 50 open tickets. So it might take a few days days until we analyse and solve a low priority ticket. Therefore a good classification of the tickets is necessary.

We're constantly improving the application and documentation, but that takes some time.

Constraints

We have to decide the priority before a detailed technical analysis. The guy at the phone is not a deep technical expert. Each user claims that his/her problem is a life-threatening show stopper. Our users must be able to understand why a certain ticket has a certain priority. Therefore will publish the criteria in our documentation.

The questions to you:

How should we decide on the priority of the tickets? Does anyone know a set of well-proven criteria for this problem?

1
  • 1
    This is a job for google prediction API! you train the model, and then your model will recognize what is important and what is not Dec 28, 2012 at 4:45

4 Answers 4

10
votes

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.

1
  • Can't say that it's mine - I've seen it in ITIL docs, and at my last few companies, it was used in exactly that way. But i'll gladly take credit for spreading the knowledge.
    – mfinni
    Aug 22, 2011 at 20:50
4
votes

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.

1
  • 1
    Also add in a ticket for issues that need to be fixed by the dev team.
    – tkrabec
    Aug 18, 2011 at 15:13
2
votes

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.

1
  • if you pair them, why not just use one value?
    – warren
    Aug 29, 2011 at 14:02
2
votes

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
2
  • That's pretty similar to the ITIL priority matrix. Not a bad implementation, sounds good.
    – mfinni
    Aug 29, 2011 at 14:14
  • @mfinni - that may be where we got it from .. all I know is that it's how it worked there :)
    – warren
    Aug 29, 2011 at 14:18

Not the answer you're looking for? Browse other questions tagged .