Jira Service Management

4 articles in this category

Assets - the lost potential
I remember when I first saw Insight in the Riada office and I was blown away by the potential. When Insight was split off into Mindville later I thought that Insight would take off like a rocket. And it did so well that Atlassian eventually acquired Mindville. I had no reason to think that Insight would not become a new product with Atlassian that would rock the world, but I was wrong. Very wrong.
In July 2020 Atlassian announced that they acquired Mindville and thereby took ownership of Insight as a product. Since then things have moved on for the Data Center version where things like improved UI and Auditing have been focus points, making it an even better administration tool for Jira Administrators.
For cloud... well, it has been pretty dead in the water.
Sure it has the base functions, but there are so many things missing!
Differences between Data Center and Cloud.
Import data types
Cloud: CSV, JSON, Assets Discovery
Data Center: CSV, JSON, Assets Discovery, DB, LDAP, Jira Users and Groups
Integrations
Cloud: Jira Service Management Services, Marketplace Integrations for Cloud
Data Center: Cloud providers (AWS, Azure, Google Cloud), Mobile device and software management (JAMF, SCCM, Snow), Other CMDBs (ServiceNow, Device42), Atlassian ecosystem (Jira & Bitbucket, Confluence, Tempo), Others (NVD)
REST APIs
Cloud: Public REST API, External Imports API
Data Center: Public REST API
Object schema templates
Cloud: Coming soon!
Data Center: ITSM, HR, FM
 
There is more...
While this just show the high level differences I think you can see that there is a substantial gap in high level functionalities. In addition to these changes we also miss features like the ability to upload scheme specific icons and automation. There is also no file management for CSV imports and so on.
 
The Gap is not the worst part...
While having a big gap between Data Center and Cloud is bad, there are other things that in my opinion are even worse and that is accessibility. I don't mean the UI, but the fact that on Data Center Assets is available for free, while on Cloud you have to double your annual cost and go premium to get your hands on it.
The fact that a single agent license cost a whooping $47 (compared to Jira Software's $15 per license) is cause for many mid-sized to large companies to immediately regret trying out Assets in Data Center.
This cost and the fact that you can not even try it out in a limited capacity make Assets something that only those willing to buy on a leap of faith, or people that already have experience with the product, to actually experience it. This is the same problem that Atlassian have with Jira Align and I think it is also why both Jira Align and Assets are growing a lot slower than they should.
Assets as a Jira System Administration tool is amazing
If you have used Assets on Data Center or Server, then you probably already know what an amazing tool it is to keep track of your Jira system. The Jira environment import not only spider though your system and keep you updated on changes, it is also a very nice one stop database for all your administration needs.
It will allow you to keep track of all integrations, service accounts and anything else that you have that is not directly included in the import. If you have a messy system with a lot of technical debt from migrations and things like that, then it is an amazing tool to keep track of what you need to clean up and what you should consolidate.
It also provides a very useful tool for your support desk where you can connect all tickets to existing configurations. For example, you can connect all configuration requests and automatically assign an approval to the project lead. This speed things up and you can simply ignore tickets that are not approved, seriously reducing time you spend on tickets.
If used correctly you can also connect all tickets to the configurations involved. This type of historical documentation really help to maintain your system well-kept and organized.
I hope to see much more development on Assets Cloud
I really, really like Assets. It is one of my favorite features for Jira Service Management and as such I really, really hope we will see a lot of improvements when it comes to the Cloud version. The Jira environment import is a must I would say, but also AWS and Azure import is really, really important. I think many will also miss both Tenant and Yamf imports.
When it comes to the Jira environment import it has some areas where it should absolutely be adjusted. For example, you should be able to follow the full chain of configurations regardless of starting point and there is no Permission schema, which is odd on Data Center.
The road forward is I was in charge
I am no fan of the forced Premium features that Atlassian have. I think it goes against their core values and I think you should be able to explore all products regardless of subscription level. So what I would do is either break out Assets as its own product or add it for free with limitations in the free subscription tier.
If you can make 3 schemes and only have 1000 items in each for free, then more people will want to try it out. More people trying it out means that more people will see how useful it is, and more people will want to get the full version. More people means that more companies will build more apps for it... and so on.
--
Well, for now I will continue to enjoy the amazing features that Jira environment import provides on Data Center. I hope that one day I will not only consider moving to Cloud, but actually yearn for it!
Let's get Assets on Cloud Amazing!!

Written by: 💫 Jimi Wikman
Category: Jira Service Management
September 21
0 comments
10 views

There is a problem with Jira Service Management escalations...
If you have worked in a larger company you probably have noticed that escalation between the different support tiers cause a lot of problems. Perhaps you even notice this in medium or even small companies as well. The reason for this is that Jira Service Management is missing functionality that is needed for escalation to work properly. For a tool that claim to be an ITSM tool, this is quite strange, but well in line with the way Atlassian thinks about their products.
If you are unfamiliar with ITSM and support tiers, then I suggest this nice article as a starting point: https://www.bmc.com/blogs/support-levels-level-1-level-2-level-3/. If you don't want to read all that, then the short summary is that in ITSM support is set in multiple levels of technical expertise.
It starts with a basic support, which is to answer the most obvious questions and to make sure the tickets have enough information. Then the tickets Tier1 can not solve goes to Tier 2 which have more technical knowledge and so on. You can have as many tiers as you want, but most models have 3 or 4 where the last tier is outside help towards vendors for example.
Jira Service Management does not support collaboration
This might be a strong statement, but in this case I feel it is actually true. Maybe we should say handovers, which is what we are actually talking about, but since communication has to remain constant towards the customer I feel that this is still true.
So what am I talking about?
In Jira Service Management today there are hard boundaries around the projects that can not be bridged without harming customer experience. What I mean by that is that in order for me to hand over a ticket to another team I am restricted to 4 options:
Have everyone working in one giant monolith project. Move the ticket to another project. Clone the ticket to another project. Create a linked ticket to another project. Before we dive into what these 4 options mean, let us first define what our customers expect from the interaction with support. From a customer perspective they have a problem, or a request of some sort and they have done their job by submitting a ticket to support. They now expect support to handle their request and solve their problem in that ticket. This is a fair expectation and if we break this expectation they will experience frustration.
1. One Monolith to ruin it for all
This is by far the most common way to work in small companies and it is how Atlassian envision us using Jira Service Management. One box where everyone that needs to be involved have a role. The problem with this setup however becomes very apparent when you start to grow as an organization, or when you start to have multiple products and services with shared resources.
Not only will there be a lot of people in the project, perhaps several hundred people or thousands even if the organization is large, internationally distributed or need to handle multiple companies setup because of company structure or acquisitions. To be able to make sense of a large instance with many teams you need to make a lot of queues and this is where the first problem is with Jira Service Management today: There is no nesting of queues. You have to get an add-on to handle that, which add cost to your already quite expensive platform.
The second problem is that when you mix many teams in one project, you will start to add complexity as the various teams want to customize their experience. You will start to build automations with multiple exceptions, you need to start adding local groups with all the problems that come from that and you will have subsets of screens connected to customized issue types and... well you get the idea. It quickly becomes messy and soon you will have manuals for how to work based on what type of request for which team you are working for to navigate all those custom fields that confuse everyone.
This is a horrible way of working.
If we instead work with Jira Service Management where we have an IT Support desk for first line support (Tier1) and dedicated projects for Tier 2 and Tier 3 teams, then we are in a much better place. But there are still issues...
2. Move ticket to another project
Our first option when not working in a monolith when we want to hand over a ticket to second or third tier teams is to move the ticket to their project. It makes sense technically because the tier 1 team will have no more involvement with this ticket and it should not be handled by another team.
From a customer service perspective it is a terrible option, however. Not only do you break all old communication because by moving you are now changing the URL and the ticket ID. This will make all old communication useless because links will not work and the poor customer no longer can reference the ticked ID as they now have a new one.
Technically you also have permissions to consider and if you do not have the same setup the customer can lose access to their ticket all together. The information in the ticket can also vanish if you do not use Forms and the custom fields are not the same in the projects.
Any SLA you have will also be ruined since each project have their own SLA and when you move a ticket the SLAs will be reset as they are counted again with the new SLA in the project they are being moved to.
In short: Never move support tickets if you can avoid it.
3. Clone the ticket to another project
This is an even worse solution than moving the ticket. Not only do you get all the negatives from moving the ticket, you also duplicate the information. This means that the customer now have two identical requests, but you also have different statuses and different communication. If you for example clone the ticket and then close the initial ticket, the customer will get a notification that their request has been closed, which will confuse the heck out of them when they then get a reply in a ticket that look identical, but with a different ID and different URL.
In short: Never clone a support ticket unless you REALLY want to frustrate your customers.
4. Create a linked ticket to another project
This is very similar to cloning the ticket if you are doing it wrong. That would be that you create a linked ticket and assign it to the customer. Then it would just be a cloned ticket you have linked.
Used correctly however that creates a separate conversation between the two teams. This is how it should be used in Incident Management for example where we need activities to be performed in development or Infra teams for example.
This will not help us in our scenario where we want to make a handover, however as the customer conversation still will be in the original ticket. We could build an automation that sync the conversation between the original ticket and the linked ticket, but since that will be posted as the actor in the automation communication will look very bad on both sides.
We will also still have to keep the original ticket open in the project for the Tier 1 team, even though they no longer have any involvement. The customer experience might be ok, but the setup will clutter up the queues for the Tier 1 team. The Tier 1 team will also be responsible for the SLA, which means that they might unfairly get bad SLA results because of the Tier 2 team activities.
In short:  this is probably the best option, but it is not very good.
 
How do we solve this then?
Without knowing the architecture of Jira Service Management the suggestions here might be more or less difficult to accomplish, but I will make the suggestions based on the customer experience and UX rather than architecture.
1. Change Queues to allow tickets from any project
I can not for the life of me understand the architectural decision to restrict this when boards have had this functionality forever. Just this small change alone will make Queues so much more useful and it will allow teams to work with multiple requests from one area. Queues for Jira Service Management have the right idea, but they focus on local groups, which any sane Jira Administrator avoid like the plague, especially if they already sync users with the AD.
Make Queues like boards so they can be attached to projects or a user. Not only will that allow teams to work cross projects, but it will also open up for different views that can lead to add-ons or native improvements to how support in general can be designed.
2. Add account sync to automation
It would be very nice, not just for thise scenario, to be able to synch comments WITH the account that made the comment rather than using the automation agent as the author. This will allow for a better customer experience and it will make many types of setups feel more seamless than it does today.
3. Build a native handover function
While we can work with custom fields to handover ticket between queues if we get the change to queues to allow data from any project, I would much rather see a native function in Jira Service Management. The reason for that is that it would allow extending that function with more innovation and standard functionality.
The way I envision it a customer agent would just click on a handover link or button and then get a screen like the move screen. There they can select what project they want to hand over to and possibly what team. A comment field can be there by default if they want to add an internal comment as well.
When the support agent submits the ticket is flagged as handover and in their project it will no longer be visible by default in the original project (as it has been handed over). There should be a way to set up a queue to see all handover tickets however if that is wanted. This action will also trigger a new ticket in the project the support agent handed over the ticket to.
What makes this different from just a linked ticket then?
The first change is that the handover ticket work like a cloned ticket with the same information as the original ticket. This means that reporter for example is the customer and not the support agent as when you create a linked ticket.
The second change is that all comments are synced between both ticket with the account information on who made the comment. This way the communication is seamless from the customer perspective and the support agents. It also means that everything is synced toward the original ticket, making that the master regardless if the ticket has been handedover due to escalation.
If the handover ticket is handed over, then the same steps should happen, but the sync should now be done twice, once for each of the tickets in the chain.
What about the workflows?
This is a problem as many teams what to have their own workflows. As we can not, or want to, force people to have the same workflows, we need to figure out what status we will show to the customer. Each ticket will of course show whatever status the team put it in so they can follow their workflow in Jira Service Management, we just need to consider what to show to the customer in the portal.
I can think of several ways to solve this.
The first solution is to just add a label instead of using the workflow. This label can just say Escalated for example and the label stays until the ticket is closed. It is simple, but perhaps not the best from a customer experience perspective since the status actually is communication.
The second solution is to choose either the original ticket workflow or the handover ticket workflow. This can cause some strange scenarios if there are many different statuses between the original ticket and the handover ticket. Having status change from in progress to Open or New for example might be a little weird. While that can be fixed with not changing status from the original ticket to the handover ticket until it has moved at least one transition, it is not fool proof and can be confusing.
The third option is to treat this as some form of integration so we setup a mapping between different projects. This would be a massive thing to build and a pain to manage, but if done well it could probably be used for other things as well. This require you to do a lot of work also every time a new project is added that you might want to handover to.
The fourth option would be to present a choice when you transition a hand over ticket with the combined list of statuses from the original ticket or the handover ticket. It is messy and pretty much the same as #2, but less useful.
There are of course more solution to this, so if you have a good suggestion, please add it in the comments.
Communication must be taken seriously
Regardless how we look at support and what solution we prefer for escalating to other teams, we must remember that communication is key. No matter how good we are at solving problems it means nothing if we agitate the customers by not communicating while we solve their problems.
By breaking communication in any solution we have today, or forcing teams to be suboptimal by working in monolith projects we are limiting the potential of providing exceptional support to our customers.
I think we should take this seriously.
What do you think?

Written by: 💫 Jimi Wikman
Category: Jira Service Management
September 21
0 comments
10 views

Insight free with JSM Premium - Jira Service Management just got a lot better!
Yesterday I got a mail announcing that Insight, the powerful CMDB tool from Mindville that was recently acquired by Atlassian is going to be included in the Jira Service Management Premium & Enterprise plans. This is a huge announcement and I very much look forward to seeing this rolled out in the coming weeks.
If you don't know what Mindville Insight is then you can check it out here. In short, it is a tool that allow you to manage all your assets and configuration items in an easy to overview database. With the connection to Jira Service Management and Jira Software Insight give you all the information you need in one overview.
We will write more about Insight later to show you it's many features.

Written by: 💫 Jimi Wikman
Category: Jira Service Management
April 1, 2021
0 comments
840 views
• 

Jira Service Management merges several products into one jira service management
Today Atlassian announced the new package for their ITSM solution. The new package is called Jira Service Management and it is a bundle of Jira Service Desk, Opsgenie. This is a pretty sweet package and it is quite powerful for anyone who want to combine Agile and ITIL4 as a power combo for the future.
This is quite the change for Atlassian and it is probably to compete with ServiceNow that has had a stronger ITSM solution as their main selling point. This new service package, and especially the new name for it, will probably pave way for more companies to look at Atlassian even for their ITSM solutions.
This new package, combined with Jira Software, Confluence and Bitbucket now means that you get a complete package for ITSM and Agile methodologies. There will be improved integrations with Insight, the asset management solution Atlassian purchased from Mindville earlier this year. This will greatly improve the usefulness of the Atlassian ITSM package.
This comes at a pretty good time as I am building this for several clients, and they will be very happy about these new changes.
 

Written by: 💫 Jimi Wikman
Category: Jira Service Management
November 9, 2020
0 comments
913 views
•