Let's build a two site support setup with Atlassian Products - part 1

I currently own two websites, atlasstic.com and jimiwikman.se. and I want to set up support for both of them. I don't want to spend a lot of money doing so, as I have other things to sink my money in, like hosting for example. So I want to set up a dual support using just one license. To make this a bit trickier I want to make it so that the two setups will feel and look completely different.

So let us plan this shall we?

So I have one Jira Cloud instance and one Confluence instance. The Jira instance is a premium license, because I want to play around with Advanced Roadmaps. I have a standard Jira Service Management on top of that and my Confluence setup is also a standard setup. I want to take advantage of all the Atlassian products I can, so I also have Jira Work Management, Jira Product Discovery, Compass, Bitbucket, Status page, Trello and Beacon. So I have a pretty extensive toolbox to play around with.

My Key add-ons at the moment are Refined that I will use to split the support portals, Scriptrunner for all kind of magic and Microsoft 365 for Jira for all email/teams/Jira combinations. I am also running BigPicture Enterprise and StoryMap for planning and for making some videos.

One Support project for both sites.

The core of the support setup will be one Jira Service Management project where all tickets from both sites will aggregate. This makes sense since there are not a lot of tickets flowing in. If I want to split this later on that will not be a big problem as Refined allow us to make these changes quickly and with ease.

I want to show open incidents and tie in Status Page to show on the portal. I also want to display Confluence pages to answer common questions, but as a content block and to show when a user writes a ticket. Since I have two sites I want to have this with two sets of projects and spaces.

For support, I want to have different types of requests depending on what the person submitting a ticket for wants. I also want SLAs to measure my response and resolve times as well as timers to help count down and remind customers automatically in different time intervals. I want to automate the status transitions during conversations so I don't have to change the status manually every time.

Let us plan the project setup

The first thing we need to do is to plan the issue types so we know what kind of requests we want to handle. While you technically can use any issue types as you will define the actual ticket types, there are some nice features built into Jira Service Management that we can use.

ITSM is a pretty good standard for must use cases and in Jira Service Management we can add those under Features in the project settings. So in the Work categories section we will activate Service requests, Incidents, Problems and Changes. We will also activate post-incident reviews but mostly to try that out rather than it being anything we probably will need. As I don't have Premium I can't activate Customer Service Management, so we leave that one for now.
 

Now that we have these activated we will get extra sections in our project that act as Queue categories, which is very nice. Since we have these defined now as sections, or categories really, it makes sense to also have these as our issue types.

The next step will be to map the different request types towards these sections.

Planning Request Types

The first thing we need is something for when people email in. This will allow us to separate these from other requests as the quality of these are usually very poor compared to portal created tickets that we can control the content from. We also need an incident type, so people can report problems of course. I do get some collaboration tickets also of various types, so we need something for that. Suggestions sometimes come in as well and we want those to go to Jira Product Discovery for processing. Legal is always good to have in case we get requests or demands from legal sources.

So, let us break that down into actual request types:

• Incoming Email
• Incident
• Collaboration
• Suggestion
• Legal
• General questions

I think that will be a good start and then we can build upon that later when we see the need for it.

Asset Management

I love Jira Assets and I work extensively with it in my role as Atlassian Platform Owner at Sinch, but in order to use Assets I need the premium version of Jira Service Management. At $47 monthly for just one Agent that is a bit much, so we will settle for the very limited Services feature for now. It is not a very good feature compared to the actual Assets product, but it will work for connecting tickets to the different parts of the two websites.

Create the project

Based on this we can go ahead and create the project. We could go for the ITSM template, but it adds a lot of things that we don't need that we just have to clean up later, so we go for the blank project for IT teams instead. In the screenshot below I had to add another Key since I already have this setup. I choose company managed because I like structure and order and I do not like team based projects.

Now t

Now that we have the project it is time to tweak some things and I started with the issue types. I decided that I would change them up a bit and this is the list I can up with.

As you can see I have created a new Issue Type Scheme since I like to name things so they look good rather than having generated names. On top of the four standard issue types that comes with ITSM (Incident, Problem, Service request, change request) I also added one for Post Incident Reviews since we have the feature activated. I also added Ask a question for more open type and then Consultation for collaborative things. Finally, I added one issue type for Email request as well.

From there we can now begin creating the request types and the forms we want to go with each request type. I just add them one by one and map them to the request categories and issue types.

Most request types end up in Service Request, but we get a few in each except for Problems. This is fine as problems are internal tickets.

Building the Request Forms

I like my tickets clean without too much clutter, so when designing the request forms I go super simplistic and then I can add later if I need to. I also like to use Forms since that allow me to ask for any type of information without adding a ton of custom fields.

For the request form itself I always make sure I have the Summary field, even when I work with Forms. This is because the summary is what trigger the suggestions from Confluence and it also ensures that I get variations in the summary instead of having them all the same if you choose to hide it.

At the bottom you can see that I have added a form to this request type as well, which we will cover in a different post.

 

For the Issue View I just have the Description and Summary in the top section for this and then I add the fields I feel I want for this request type. I did add tabs for this project and I will show how I did that in another post so you can see how that looks and what you can do with it. Adding the tabs require you to go to the Screens and this article is already a bit long.

Since we do not have that many request types I will just add two Portal categories, one for General requests and one for Incidents for now. We will experiment a bit with this in Refined later so we might come back and adjust this then. As we can place individual request types in Refined rather than just display the project setup, this is not as important as if we had not used Refined.

Now that we have our issue types and request types setup we need to create the workflows and set up the automations we will use. This is the topic of the next article, so if you like this so far make sure you keep an eye out for the next chapter.

This is a rather high level article, so let me know if you want me to dive deeper into a topic in another article.