Service Desk & Software crossover

[Mike Hibbert]

Hello

We're looking to implement Jira Service Desk as a replacement for an existing SD, and to use Jira Software for managing projects. 

I'm happy with what each do, and that I can have a Service Desk tickets that can then be moved to a work item in a project for delivery. I just can't quite get my head round the licencing. 

I have 150 users, 4or 5 Service Desk folk, and an IT dept of 20. 

I get that I don't need licences for the 150 users, and that the IT dept will be software users. The 4 or 5 Service desk people will all have to have a SD licence, but not a software licence? Is that correct? 

Some of the Software Users will sometimes need to triage tickets, so will need a view of them, will they need SD licences? Or is there another way round this?

Any ideas will be appreciated!

[Mike Rathwell · Accepted solution]

Hi @Mike Hibbert 

Ok... I am going to take a shot at this and... I could be a bit off... so here we go:

• The SD licenses basically let the SD agents see the queues and the normal Jira-ish detail view of the tickets in there. 
• I think they get Jira software by default at that point. So... they can see both JSD and normal projects
• Assuming permissions are set to allow it, the Software users will be able to see the portal view of a Service Desk ticket and comment on it. Note, however, that comments via that portal are viewable by all as opposed to commenting from within JSD where SD agents can make internal comments not exposed externally. 

As such, it basically comes down to all the humans will have Software licenses. The few you need to act on JSD tickets (edit, update, transition, close, etc) will need SD licenses. 

Hope this helps

[Mike Hibbert]

Thanks, that's a real help. 

What about things like access to MI - will "management" need access to JSD too? 

It's not a huge difference, but software is $7pcm whereas JSD is $20, so I'm just trying to work out my business case.

[Mike Rathwell]

Therein lies a rub. IF you want to give them access to a link to get status/performance/etc, (something I am hugely in favor of because lazy and hate writing status reports) the answer is yes.

What we have done in our shop is that our group TPM, who has access to JSD, will suck out the status reports I built in Confluence pulling from JSD to a PPT to submit to leadership. It saves us the cost of licenses for them, almost none of them will ever click a link to get a status report regardless, and it adds a sometimes needed layer of obfuscation. If you make your reports all relative using queries, at worst it ends up being a copy/paste effort. 

[Mike Hibbert]

Ok, thank you, so if I'm reading you right, I need enough JSD licences for the people in the service desk, and we can "work out" a way of doing reports if needed?

[Nic Brough -Adaptavist-]

I'm sorry, but that's not quite right.  To correct Mike's post:

• The SD licenses basically let the SD agents see the queues and the normal Jira-ish detail view of the tickets in there.  They also allow the Agents to work within the SD projects (Core users only get view, comment and participate)
• They get Jira Core by default at that point. So... they can see JSD, Software and Core projects, as Core is providing the project and issues that live behind JSD and Software
• Jira Software users also have Core access
• Assuming permissions are set to allow it, the Core users will be able to see the portal view of a Service Desk ticket and comment on it.

[Mike Rathwell]

Thanks @Nic Brough -Adaptavist- ; that was why I had "think" both present and italicized. I don't own any Core users because all the humans in my shop tend to use softwarish features. I was hoping someone rather smarter than I would correct if needed. 

Yes, @Mike Hibbert , that was what we did. Basically work around the restrictions for reporting

[Mike Hibbert]

It's complicated isn't it!

I want the JSD agents to be able to triage tickets and move them around as you'd expect, but I'd also need a Triage Team to review the tickets and then move them into a Fix Cycle Project if needed. 

Will that be possible in the scenario?

[Mike Rathwell]

I do have a few situations where I do that little thing, @Mike Hibbert . These include:

• Workflow transfers to another project (usually using JMWE create/clone issue post function) with a JSD ticket result of either closing it since it is not extant in there OR leaving open until the external project ticket is complete. A couple of things I do there:
  • Make a link between the two tickets
  • Add the reporter of the JSD ticket to watchers on the SW ticket
  • Post function to drop a comment in the JSD ticket so the reporter knows what is going on
• Use the portal as a capture function for other SW projects. I have one scenario where the project owners do NOT want external humans directly creating tickets for them in their project. Their ticket field requirements are also voluminous. 
  • JSD lets the humans in that group charged with managing ticket ingress to the SW project have JSD licenses to review and correct as necessary
  •  JSD has a great approval mechanism which is used for this and other projects. A huge advantage there is that a single my approvals link shows you all of them across all JSD projects
  • When ingress is ready to go, it creates the SW ticket automagically and links them with a comment showing where to go find the actionable SW ticket.