Enhancing Client Visibility and Service Through Jira Service Management | Tiina Koivula

Hello, everyone, and welcome. I'm here to talk about Jira and the service management - and how we use the service management portal. And I thought I'd tell you about our journey with Jira so far - and how we moved towards our centralised portal. And in this presentation, I will tell you how and what we started with - and how we try to do things better, hopefully constantly, - and how we want and know our customers to use the portal, - and of course, how our service agents and their entire service function - uses the portal and provides service to our customers. And we will go through some examples of service request lifecycle, - from the customer to the development team is one of the examples, - and also what we plan for the future. So, in 2018, we knew that the Incomes Register was coming. And before that, we used to get our service request in email or phone. And we expected a large growth - in the amount of the service requests with the Incomes Register. And actually, I think that it was about three times the normal amount - in the first four months. So, a bit of a growth there. So, what we started with was a quite basic setup. We had only a few workflows there and basically almost no automation, - and one team using the service desk - and about six or seven agents in that team. So, that was our starting point. And the first year, that was very much the way we worked. And we used the first year to try to gather information, - basically how our teams wanted to use the service management. And we call it Jira Portal, by the way. And also, how our customers wanted to use it. So, we had quite a few interviews, and we went to different teams - and asked them basically. We just focused on how we could do things better, basically. We have done three major updates to our portal so far. The first one was three years ago, actually three years after we started. And with that, we brought our IT teams, - so all the specialists in their own service project in the portal - and made the entire team more customer facing. So, even the ones that make development tasks, basically, - they are still in service management, - and they are still in customer facing setup, - and hopefully, customer facing mindset. So, at this time, we also opened - all of our different service products lines to the portal. So, we have many products with different service agreements - or service level agreements, - and we opened all of them to Jira Service Management. And by spring this year, - we had increased our automation to bigger than ever. When I was making this presentation, I counted that - we have 230 different automations in our service management that run daily. And after I've done this, - our integration team asked for five new ones last week. So, we're trying to be better all the time. We have eight Atlassian products in use, 11 add-ons, - seven larger scale integrations, and over 200 different dashboards. Most of the people use the dashboards for tracking certain customers' work - or their own work, but we also have teams that have dashboards, of course. And all of the customer facing teams, integrations, project management, - consultants, IT, et cetera, is in the service management product. And all of the work that these teams do are actually tracked in the product. And they are mainly service requests. So, even for a project manager at the moment, - all the tasks involved in the project are service requests. And we've also gone from not having a single database - to having quite a few databases actually in use. And almost all of our product manuals are available in a database as well. So, like I said, we started off with very little - and started gathering information on how to do better when serving our customers. And based on this, we decided on our standards. And whenever we do something new, change things - or have a major change to our service management, - we go by these standards that are listed here. So, in the beginning we had quite a few workflows - when we started updating our system to be better, - and at the moment, we have less. We decided on less because we thought that it would be easier - for our agents to use, so you don't have to remember what I should do next. And the time is kept to minimum that way as well. And like I said, we have a lot of automation, - so about 230 automations in use. One of the examples would be that - when we get a new contract and start with our implementation project, - all of the tasks, normal tasks, are created by automation. And for example, if you buy a product A, our payroll software, - it will create all of the requests for the teams involved in that product. And then, we use different statuses in our ticketing for the service requests. I have a few examples of that as well, - but they are created so that they are informative for us and for the customer. And of course, we use them for reporting and they are part of our KPIs as well. And tracking, so all of the customer-facing teams - track how the customer uses the portal - and as well how satisfied they are with it. And one of the main ways how we do that is to get feedback from the customers. And it's asked in our surveys, - as well as customer service managers - ask our biggest clients regularly how they are feeling, - how satisfied they are with the portal and what they expect. And actually, most of the things that they ask for at the moment - are mainly about the databases, not exactly only on the portal side. And ownership, so we decided that every service request - should have an owner throughout its lifecycle. So, when the service request arrives to us, - someone has the ownership of it. And that person always checks that - the service request lifecycle is aligned with our service agreement. And of course, high quality data, so we try to help the customers, - or even if the service request is created internally, - to always put the best possible data to the request, - so we don't have to ask for additional information. And of course, to minimise the failure demand, - two big ones that I mentioned here are data banks. So, we're trying to increase the self-service to customers, - so that they know things and are easier to find basically for them. For example, manuals, like I said before. And on each one of our service requests, - there is this root cause analysis that the service agents fill us out, - and sometimes it's done by automation. It depends on what the request is like. And we like to stay on the employee polls all the time. So, one of our admins goes regularly to team meetings, for example, - or we are asked to talk about Jira and training employees - and bringing forward the joy that service management means - that we go to teams, we tell them, we train them, - we have regularly talks with them - about what possibilities service management provides. Then, we decided on some target states from the customers' point of view, - so that all of the forms basically that we have - are easy for the customers to use, - as well as provide needed information to the service agents, - meaning that we ask only the information that we think - and know that the customers already have - when they give us the information for the service request. And of course, the databanks to provide more abilities to self-service, - like I said before, that's one of the targets - and clear sections in the databanks. Like I said, some of the feedback was recording that - maybe they didn't find the information they were looking for, - that maybe our bug report was difficult to read, or they didn't understand - what our development teams were saying and stuff like that. So, we made it in clear sections so it's easier to find, - and also, we provide videos to help customers with that as well. Guide, like I said, we have videos, we have guidance there. Visibility to request in the portal, so one of the major things was - that we use the statuses, like I said. For example, the status "in a service request" for our teams - is different than what it says to a customer. So, it's maybe easier for them to track. And also, we use comments quite a lot. So, we make sure that all automation creates a comment, - or our agent does that. And we have video manuals, not only about Jira, - but also of our products in the service portal. So, there are links basically available. We have linked our databases better together, - meaning that, for example, we have our product releases - in one of the databanks and some of the product manuals in the other ones. So, they are linked together, so easier to use. Like I said, we have tried to improve the search function for the customers - because we've had some feedback that it was not so easy for them to use. Also, how-to articles on the support request, - for example, would be that - we ask for a number of incidents for the employees, - how many people are involved. And some customers had issues with that, for example. So, we added some how-to articles. And of course, we have a status page for our new products - if they're up and running. And how our service teams use the Jira portal? Like I said, all of our teams that are customer facing - are using the portal at the moment. So, they are all in the Jira Service Management. And we have done this in phases, - and our integrations and IT were the first ones to join the portal. And our project management and consultants joined in August this year. And like I said, it's used as a project management tool. And we started with Jira software, but we have moved now - or are in the process of moving to using Jira Service Management. So, a few weeks ago, we had the first projects - that were fully in the Jira Service Management. So, it's easier for us to monitor the time to value, - which is one of our KPIs as well. And basically, Jira is our tool for operational management, - meaning that we provide visibility, - transparency to everyone in our organisation. Everyone has a license, everyone can go there and check - how the process is moving along, where the project is at the moment - and, for example, if new orders for products are up and running. In the beginning, when we started with Jira, - we had a different software for our product development, - and it was difficult because we needed to ask that about a new feature, - for example, that is going to be in the next version - or the one after that, for example. And now, we can just click on Jira and see where it's going to be released. Like I said, our integrations team are in Jira, - and that was basically one of the biggest things - that we have done this year is to get our platform monitoring to Jira. So, if there were, say, an incident in our platform, - the ticket is created automatically to Jira, - and the team can start working on it. So, monitoring, too, as well. And we have our incident management in Jira. That's actually an ongoing project. So, not all of our incidents are handled in Jira at the moment, - but we are going forward to that. I said that I was going to give you an example - of how our service management is done, basically. This is an example when a customer creates a service request - that is forwarded to a project management, sorry, product teams, - and how it's basically shown to the customer and how it's shown to us. So, when the customer creates the service request to the portal, - it comes to us as a request that needs to be forwarded to product development. So, what the team does, they comment on it, - saying basically, "Thank you, and we will move this forward", - or something like that, and they will change the status. And these events are all, of course, visible to the customer. And in the user support channel, - we have this status called "product development". And under that, there are additional options - depending on the request and what it's like. So, it can be waiting for development, the actual work. It can be a work estimate, - so if a customer is ordering a new feature or something like that. Or it can be just waiting in product development, - meaning that there is something that needs to be clarified, for example, - for our team or for the customer. So, it's waiting for work to be done for clarification, for example. Then, the automation creates a cloned request to our development team. So, it's not the same request, - people in product development are not customer facing, - so they are not directly in service management, - but we use cloned requests for that. And the request arrives to the product development team after that, - and it's mainly checked by the product owners, - and they usually check for priority. And the request will be also reviewed by the team on a daily basis. It depends on the priority and is this the workload, - or is it just clarification, for example. And when the team resolves the ticket, - when they have an answer or a question that needs to go to the customer, - the support ticket will return to the state "waiting for support" - when the development ticket is resolved. So, the status will be "done" by that point. And here you can see some of the workload. It's in "finished", but... And how the customer sees the request? So, like I said, when the customer creates the service request, - it will go to status "waiting for customer support". And when we started figuring out this for the first time, - we created basically a form or a chart, - and we decided that we need to think - how the status is shown to our teams basically, - and it can be different for the service agent and the development team, - and then we decided, hey, what will the customer need to see, - so what's the status for them, and it's different. So, when the service request is in progress, - say, waiting for product development, - it changes status for the customer. And also, when the service request is in progress with the other team, - it also changes the status, - meaning that we haven't used automation - to bring the transparency to the clients all the time. We have used status for that. So, we are trying to give more information, - and actually, it has helped because clients don't need to ask us then, - "Hey, where is my ticket? Where is it going? Are you going to come back to me soon?" They can see the status that, oh it's in progress now, oh, it's done, - so it's been easier that way. And I said I was going to tell something about our future as well. So, what is the service management future for us? First of all, we have decided to start our AI project. Efima is our partner in that. And the project will start in December, so in a few weeks. And that is maybe the biggest thing that we have coming now. We are not going to forget our automation. Of course not, because that's one of the baselines that we had. But we have some requirements. And one of the requirements, because we wanted high quality data, - is that we have some cases where the information might be missing - from the request, say, some sort of classification or something like that, - we might need help with those. And also, creating self-help articles for the databases, - meaning that, at the moment, our team does that. They pin out which issues maybe get the most questions, - and we're hoping that, in the future, our team doesn't need to do that. What they do need to do is check the article - because we cannot publish anything just based on AI at the moment. So, there needs to be an actual person who checks that. And also, automatic responses to the support request, - meaning that, same thing, the response will be generated, - but an actual service agent will check it - before it's commented to the customer. And just in general, more efficient use of the Jira searches - because it's really important for us in daily life - to check for the past requests, - and maybe there's some information available there - that can help with a new request or something like that. And, of course, improving the quality and spelling of the answers. Like I said, we are excited about our service management - and hopeful that AI will bring us even more forward - in the use of that in the future. Yes, thank you. [applause] [outro music] [music ends]