How to set up Service Desk for multiple Customer Engagements

[Tony Laycock]

My company's engineering department already uses JIRA Agile Cloud to manage its software product deliveries.  We have a JIRA project per product.  Each project tracks confirmed bugs and approved feature requests for a product.

We are now considering extending our JIRA usage to cover our customer engagements.  Our products are aimed at large enterprises and are highly configurable, so it is not uncommon for our Agents to initiate a multi-month project to install, configure and UAT one of our products.

During this period we work closely with the customer and we would like to provide them with a portal to raise and track their issues.  Once issues are raised, our agents will diagnose them and either resolve directly via a configuration change or else pass it on to engineering in the case it is a product bug or feature request. 

Question: How would you recommend we set up Service Desk to support this usage?  

• We need to make sure that each Customer Engagement is confidential (i.e. we don't want customers to see each other's issues even though they are implementing the same product
• We want multiple users within a customer organization to be able share issues.  
• We need to make sure it is easy for an Agent to transfer an issue to Engineering and monitor its progress whilst it is in engineering.
• It is important that engineering works from a single backlog per product
• Once the product goes live, we can close the portal as Customer Support requests will go to a separate system. However we may reuse the customer engagement portal in future if we secure a contract for a major upgrade that requires a re-configuration. 

In terms of numbers, we have a few dozen Product Projects and each product can expect several separate customer engagements per year.

 Thanks in advance

[Mel Paisley]

Hey Tony, 

The best bet for configuring your service desk the way you described above would be to create several service desks (Noting my earlier comment about the functionality not being available at this time to implement your second bullet point). 

You could have a separate service desk for each customer project (so for example 'New Website for TravelShop' as well as 'iOS App for TravelShop'), and set the service desks to use restricted access so only your specific customer group could access it (you'll be able to provide a list of service desk customers for each service desk).

Once the project was over and the service desk was no longer needed, you'd just need to disable the service desk (see How to remove or disable a Service Desk) so that the project will be retained, but the portal will no longer be present for customers.  Similarly you can re-enable the service desk later if required. 

In relation to your Engineering requirements, the best way to manage this would probably be to create an issue status "Transfer to Engineering" or similar, once an issue was in that status you could use an Issue Filter to provide a single queue for the engineering team to collaborate on service desk issues in this state across a group of specified projects. 

I hope this helps!

Mel

[Philip Wroblewski]

Hi Melissa,

We have a fairly similar set of requirements. Do you think your answer is still the best way to manage the Service Desk configuration?

Why would you not recommend setting up a single service desk, and manage the implementation instances with separate Customers?

Thanks,

Philip

[Pauline Monroy]

Hi Tony, 

3 years later, I run into the same dilemma and have decided to go with the same solution as recommended by Melissa. We initially thought of having one internal service desk and one external. But it would expose clients to make requests for other clients - clearly an ugly situation. There is no option to segregate customers making requests in a service desk. 

Please let us know how you went about and how has the experience been.

Thanks and regards, 

Kirti Pai

[Philip Wroblewski]

I don't think it's as relevant anymore. You can create a single service desk instance, but set up multiple customer 'Organisations'. Each set of customers can only see the tickets raised by their organisation. 

https://confluence.atlassian.com/confeval/jira-service-desk-evaluator-resources/jira-service-desk-grouping-customers-into-organizations

We then create linked tickets in Jira software project for the handover to development. You can use the automation rules to keep the status of the Service Desk tickets updated automatically. 

[Deleted user]

Hello.

I already configured standard service desks that will be shared for several customer organizations. We sold this desks like a product a company adquires under predefined conditions we work.

However,  I know if a particular customer requires special configurations and conditions, like workflows, SLA, notifications, list values and so on, then a separate desk would be required.

If you have a shared work pool, a single service desk makes sense, but when customers may have different needs, separate desks are the ideal choice.

That's how I appreciate the situation.

[Mel Paisley]

Hi Tony, 

I'm in the process of putting together a longer response that will explain how to implement the functionality you're describing above, however you mentioned that: 

We want multiple users within a customer organisation to be able share issues. 

This feature is currently not available in JIRA Service Desk (there's a ticket tracking the feature at https://jira.atlassian.com/browse/JSD-270 if you'd like to watch it for updates or add feedback). 

Cheers!

Mel

[Urban Suppiger]

Hi Tony,

In my company we have very similar requirements to what you described in your post. Which setup did you choose in the end? Any experiences that you could share from having >100 service desks?

Regards,

Urban

[Tony Laycock]

OK, thanks Melissa.

In the short term we can manage the second bullet point via Collaborators.

So, you are comfortable that there will be no 'scalability' problems?  We might end up with a couple of hundred service desks, in the medium term, with this approach.

Regards

Tony