To allow or not allow a customer to set the priority of an issue?

[Robert Werner]

In this recent seminar, an Atlassian employee strongly recommends that a customer not be given the ability to set the Priority for a new issue.  But without this Priority then how can Jira Service Desk know which SLA rule to use?

Example: Say a customer submits an issue at 3am.  Maybe it's Priority 1, maybe it's Priority 3.  Either way, the customer support engineer must be woken up to examine it.  Did the customer submit it at that early hour because it's urgent or because s/he was working late?

I'm interested to learn how organizations handle the Priority issue in relation to SLAs.

Robert

[Susan Hauth _Jira Queen_]

Hi Robert,

So we took a different approach.  We ask a question on one of the first fields.  Is the system down for yourself, one client, everyone.  The answer of that I use to set the priority and the next transition step (E.g. entire system down it jumps to the highest tier for addressing).  This is all accomplished using the Service Desk Automation.  Works perfectly.

Cheers,

[Robert Werner]

Thanks, Susan.

One thing I haven't explored yet is JSD Automation but will do so this week.

One approach I've thought of already is to tailor the JSD Requests themselves in such a way that the Priority is set based on the nature of the Request.  I haven't figured this all out yet but did read somewhere that if I make Priority a hidden field, rather than selectable, then I can set the default Priority that way - ie. High, Medium, or Low.

[Susan Hauth _Jira Queen_]

Hi Robert, yes you can absolutely do that as well

[Jack Brickey]

I like the approach Susan and may look at this as well. 

[Jack Brickey]

My use case is internal but I would argue that it applies to external as well. 

1. You absolutely allow customers to select priority but...
2. You publish priority definitions as a knowledge base article and ensure customers read when they come onboard. The article needs to convey that priorities may be adjusted to align with the definitions. 
3. Anytime an agent changes the priority they must update the customer with justification. 
4. You add a custom filed called Severity that allows the customer to convey the impact on their business and you leave that alone. They need to provide details on the severity so that agents take this into consideration. 

[Robert Werner]

Thanks, Jack & Nic.  I work for a small startup that is currently now setting up Jira Service Desk (JSD) in anticipation of future customers.

Question for you two: On the assumption that there is no surcharge to a customer to specify Priority 1 help, what's stopping them from setting this priority for everything?

[Nic Brough -Adaptavist-]

Nothing technical will stop them.

Most people won't do it, but if you do find yourself getting nothing but P1 calls, then you should try education first.  "If you raise everything as P1, we're simply going to prioritise them in the order you (and other clients) raise them, and/or edit them down".

Or you could reach for a bit of coding - write a validator that checks how many P1s a client currently has open and tell them they've got too many and can't raise any more.

But that is a good reason for ignoring the customer's alleged priority and calculating or triaging for yourself.

[Nic Brough -Adaptavist-]

Generally, I see several solutions to this, but they tend to boil down into three general approaches.

1.  Let the customers set the priority, but train your agents to correct it.

2.  Work out SLAs differently, not based on priority

3.  Calculate it - offer the customer different fields and work out the priority from them.  It's usually "severity" (how bad the problem is, from a spelling mistake to dead-server) and "impact" (how many people affected).   And, yes, that's very much like risk assessment, but it's useful for SLAs too.