How do you structure your Service Desk portal?

Question

Hey community!

A general question, which I believe has many answers but would love to hear some thoughts on it.

How do you guys structure your Service Desk portal in your companies? How do you decide if you will use few or many SD projects on the backend?

For example if you have a service catalog of, say 20 services which your company provides, do you structure your service portal like:

Q1: do you have a SD project for each Service so that they can leverage self-service and monitor their own queues, email intake addresses, freeze periods, service portals?

Q2: if you have multiple SD projects (say each service has one), how do you deal with the case in which a ticket has to be reassigned from one service support group (projectA) to another (projectB)? Do you move issues between projects?

Q3: if you are running a common project for many services, how do you deal with:

- single failure and freeze doman

- single email intake address

- delegating administration of the project in the groups (how do you make sure noone is touching other services stuff - example: queues)

This still is a very foundational and very interesting question to me, as I believe that the segmentation gives you more flexibility. However, as it seems other opinions are on the table, I would like to hear some corporate 'street wisdom' here:) Thank you in advance, smart people!

Larry at Isos · Answer

Hi Dimitar,

Before I get into my “short answers” here’s what I’m inferring from your question in terms of

Assumptions

Customers are creating requests so the primary question relates to these topics:

* Jira Service Desk Portal features
* Confluence Knowledge Base integration
* Confluence Product documentation

Further, we can agree that these two approaches are preferred:

* Integrating Problem Management and Change Management activities with an understanding of how your product development teams are prioritizing long term remedies to incidents and creating new features (implying Agile Release Trains/ARTS or similar context also exists)
* it’s better to notify customers, rather than waiting for them to report via a request, when* high impact incidents are disrupting customers
* new features and capabilities will be available to customers

You are talking about a complex product / services model here (just based on your 3 questions I think that’s a safe assumption):

* Jira Service Desk addresses the “customer’s proactively reports things they need help with” part of customer support, but there’s other tools in play for the total solution
* Jira Service Desk’s Help Center (Portal) collects multiple Service Desk Teams (JSD Projects) and so you probably need at least three different ways those teams work based on the kinds of customers they assist: Any and all customers, “Premium” Customers an Internal Stakeholders/Key Partner Customers.

My answers:

Q1: do you have a SD project for each Service so that they can leverage self-service and monitor their own queues

Yes and No, but really yes.

Unique Jira Service Desks are required to segment the interactions with the customers based on how the support team(s) are configured to work with those customers. In the broadest operational context for a complex product these three different support teams work, those being (at least):

* All customers
* “Premium” Customers
* Internal Stakeholders / Key Partners

The Help Center portal page collects all the different Jira Service Desk projects based on the permissions of each customer to open requests in one or more of these contexts.

I don’t like to do a huge constellation of Jira Service Desk projects as they tend to be very long lived projects so I start with “what kind of customer are they” and then build around these big three contexts to see if we can get by with just these three.

how do you handle email intake addresses, freeze periods, service portals?

Answering this part under Q3 below.

Q2: if you have multiple SD projects (say each service has one), how do you deal with the case in which a ticket has to be reassigned from one service support group (projectA) to another (projectB)? Do you move issues between projects?

Yes, if:

The customer is able to open requests in that project

AND

The team that works that part of the service catalog will always be responsible for resolving this kind of request from this kind of customer

Oh and don’t forget to “remap” the moved issue with an appropriate request type in the “other” JSD project so the customer can still see the request in the portal and the links to the old ID continue to resolve to the new ID.

But No IF

the requesting customer either shouldn’t have the ability to open these kinds of requests

OR

our support capabilities do not include the ability to resolve them, at least not at an SLA level…

You can/should @mention other subject matter expertise in the organization to come up with a solution for these kinds of requests on a case by case basis.

Document your process for these hand offs

I like to start with the Clean Escalations Atlassian Team Playbook to get this documentation started.

Q3: if you are running a common project for many services, how do you deal with:

3A single failure

Highly visible/impactful incidents are reported TO customers ideally.

It’s helpful to add an announcement in Jira Service desk (either on the Help Center or in one of the Jira Service Desk portals). Status Page is wonderful in this regard, but there are many ways to do this.

and freeze domain

I’m not sure what you mean by “freeze domain”. If you mean we’re in a feature freeze context and the ultimate solution (a new feature or improved service capability) will be many months away, you’re probably dealing with a request that should be resolved quickly even if that means telling the customer “here’s a workaround” or “yeah we can’t help you with that kind of request”. If it’s a new idea that we should put on the roadmap then do so and let the customer know where you make new feature announcements and provide external visibility into your roadmap(s).

3B single email intake address

Mail server rules that redirect to the specific JSD portal email address based on analyzing the reporting customer’s email address and / or keywords in the email

Email this Issue and Jira Automation are both quite useful if you want to do more sophisticated mail rules right within Jira.

3C Delegating administration of the JSD project in the groups (how do you make sure no-one is touching other services stuff - example: queues)

Document your process, use role account based permissions, make sure that the team that’s responsible / accountable for resolving the issue are the only ones in the Service-Desk-Agent Team role in their Jira Service Desk project. If a Jira user is not in that role in the JSD project, they will not interact directly with the Customer.

My “default” 100k foot view model for mapping tools to all the customer support activities

This is my common top level view that orients all these ideas in terms of process, team hand offs and ultimately tools. I include it because your question seems to imply this is all entirely within Jira Service Desk. Jira Service Desk is the part customers use to interact with us directly, but there are other parts, and other tools, in play.

Why does “It depend”?

I’m not going to spend a lot of time on this part, but it’s actually a totally valid answer.

Everything in Jira (and really any Atlassian tool) is team-centric, the massive flexibility of the solution turns into concrete recommendations as soon as you start specifying how the teams currently best (or should in the future best) do the work. IMHO Atlassian’s tools are fantastic at stitching all these team driven configurations together, but they are also open enough that not all parts have to be within Atlassian’s tools.

Larry at Isos · Answer

(this posted twice for some reason so i've removed this answer, as it was a dupe.)

Dimitar I_ Dimitrov · Answer

Hey community:) few years passed and I am still uncertain of the answer to my original question.... talking about an enterprise implementation with multiple teams and groups and services, and a mix of some central teams, and others dedicated.

So - same thing I wonder - what is Atlassian's guidance of the condition which calls for a separate JSD project? Is there such a thing? The answer 'it depends' does no justice for me:) I am basically looking for an advise from someone who has implemented JSD in a large (large) scale with many cross-team activities and dynamic and flexible work reassignments, and has figured it out which is better - consolidation or segmentation of JSD projects.

Anyone?