Providing great customer service is an important component of ITSM. To meet the demand of consumers, many IT operations are relying on automation to streamline processes, maximize efficiency, and streamline service levels. Jira Service Desk allows for many automation rules that can save your team time and resources. Technology partner and Atlassian Verified Vendor re:solution utilizes Jira Service Desk automation to service thousands of active installs and millions of users at any given time with only two employees. Join us to learn how JSD facilitates automation that can help improve customer service and preserve resources.
Note: On November 9, 2020, Atlassian announced Jira Service Management, the next generation of Jira Service Desk. Jira Service Management is an ITSM solution built on Jira to help IT, operations, development, and business teams collaborate at high velocity. It empowers teams to respond to business changes rapidly and deliver great customer and employee service experiences.Full Transcript:
Jill Cloud: Good morning from Austin, Texas y'all! We're glad you're joining us for our webinar today: Automation with Jira Service Desk. On our webinar today we have Michael Knight, senior consultant at Praecipio Consulting. Michael implements Jira software and Jira Service Desk from mid-size to enterprise companies, and he also consults clients on Best Practices for Agile methodologies and ITSM processes. Michael, thanks for taking the time today to join us for the webinar.
Michael Knight: Hey sure thing Jill! I'm really excited to be here today.
Jill Cloud: And later in the webinar we will introduce our good friend Christian from resolution he will be joining us today to share a case study where they use Jira Service Desk to automate tasks, allowing them to provide stellar customer service with only two support employees, and they have what, Michael, over a million users?
Michael Knight: Yeah I think it's actually over four million now but I'll let Christian go ahead and show the rest of those details.
Jill Cloud: Oh wow even better well let's go ahead and get started then my name is Jill Cloud I'm the marketing coordinator for Praecipio Consulting and I'll be your host today.
All right let's do some very quick housekeeping. No doubt you'll have questions and when you do use the control panel on the side of your screen to ask them. We'll get to your questions as fast as we can, and if we can't get to them all during the webinar, we'll be sure to follow up with answers as soon as possible. Also don't forget to mark your calendars for our next webinar on October 10 with Praecipio Consulting's Chief Technology Officer Christopher Pepe. He'll dive in on how to approach the DevOps journey with a more interpersonal approach.
Let me first take a moment to tell you about us here at Praecipio Consulting. We're an Atlassian Platinum Wolution Partner, one of only 14 Platinum Solution Partners in the US. Over 99% of our projects are Atlassian related, which includes DevOps, IT ops and Agile SAFe solutions. We do pretty much everything there is to do in the Atlassian world, from implementation and training to custom development licenses and upgrades, and managed hosting and services. We have hundreds of clients across the U.S. ranging from SMB's to the Fortune 5. Our clients include the world's top retailer, top media company, top automotive retailer, and the largest healthcare services company and electronics manufacturer.
All right so let's get started! Michael take us away!
Michael Knight: All right fantastic! Thanks so much Jill! So as we get started with today's webinar, I want to do just a quick overview of Jira Service Desk. What is it, how does it work and what is it used for. Jira Service Desk is a great tool for managing work within teams and across the business. It is used to model complex work and task relationships and dependencies across teams. It also helps us to enforce business rules for promoting consistent and predictable work. We can use Jira Service Desk to manage IT support processes, different SaaS, even a software development lifecycle! Basically anything with a lifecycle can be managed with Jira Service Desk.
So we can think of Jira into our life cycles in four separate phases, which are seen on this slide: first we can use request types to help the intake process and actually get information into our system. Next we can design rules and logic within Jira Service Desk to help us first categorize and then prioritize our work items. Finally we can manage our responses to customers through templates, knowledge bases and even as we'll see today, through automation.
So let me summarize it all in one sentence: Jira Service Desk is used by companies to provide fantastic service to customers inside and outside the organization. In tandem with Jira Service Desk, most of our clients will use Confluence to provide a knowledge base for customers. The knowledge base is an essential part of providing great service and integrates with Jira Service Desk brilliantly. These knowledge bases can be used to provide how to's, troubleshooting articles, and helpful tips for our customers. At the same time, we can also store articles specifically for Jira Service Desk agents to aid them in their interactions with customers.
As you can see here in this slide, the customer, assuming that they have the right permissions, can search and consume content in our knowledge base. If that doesn't answer their question or concern, they can raise a request. The agent on the other hand will work on curating content in the knowledge base based on their experiences with clients. They'll work on linking content to relevant issues and they'll work on driving customers to the knowledge base where appropriate. As we'll see later in this webinar, we can even design automation rules to serve up certain knowledge base articles based on requests from our customers. That's going to take some of the load off of our agents and free them up to work on more unique or higher priority problems.
Okay so having provided that overview on Jira Service Desk and Confluence knowledge bases, let's get into our main topic today: Automation within Jira Service Desk. The basic questions that we're looking to answer today are these: first how can we make these systems work for us? And second, how can we take some of the load off the shoulders of our agents? As it turns out, automation, and the feature is actually called automation I'm not just using that generically, automation can help us intelligently interact with customers, categorize and prioritize work for agents and perform some of those everyday tasks that before automation agents had to do manually.
So I'd like to switch over now to a screen share where I'll show where to find automation, explain the basic building blocks, and explore some helpful rules. Afterwards, we'll kick things over to Christian where he can speak to some of the automation rules that his team uses to provide legendary service. Okay, so switching over here, we could take the first look at our environment. As a lot of you will notice right off the bat, this is a cloud environment. I've chosen to demo in a cloud environment today because the automation engine looks a little bit sleeker in a server environment. Nearly everything is going to be the same, it'll just be a different UI.
So what we're looking at now is a Service Desk project which I've cleverly named Service Desk. From anywhere in this project I can get to automation by first clicking on project settings; next I'll just scroll down on the left side of my screen until I see automation. So here we'll see a number of different automation rules, the rules that you can see on your screen now actually come out of the box with Jira Service Desk, they haven't been added by anyone. A good way for us to understand the makeup of one of these rules is to dissect it, so let's click into one of these rules: Auto close. After being resolved for three business days at the top of the screen, here we can see the name of the rule followed by a brief optional description of what the rule does. Reading this description, we learned that this rule will automatically close an issue three business days after the resolution is set. Moving on through the rule we can see that there's a basic structure here: when some trigger happens, take some action.
In this case when the SLA hits a certain threshold, let's go ahead and transition the issue, these are the first two building blocks of a rule. Up top we have the trigger and down below we have the action. Of course there are plenty of other options for triggers and actions that we'll see in other rules, for instance, we can trigger a rule or run a rule when an issue is created, commented or edited, as well as a number of other scenarios. Our action can be to edit an issue, create a different issue, comment on an issue, transition an issue, as well as email a user. We can even auto approve and decline requests as well as trigger a webhook if we wanted!
To get some even deeper integrations there's one more building block that's not on this screen yet and that's the if statement, which is also known as the condition. If I navigate down to the bottom of my screen, I can add a condition into my rule. I can add a condition based on Jira query language or JQL, which allows me to identify any detail of an issue this could be used to say something like only run this action if the issue has no assignee or something along those lines we've put together there's practically unlimited potential for creating useful automations.
So let's get into some helpful rules: the first helpful rule is one meant to help agents follow up with customers. This one is named prompt customers after five days. In this rule if a request has been in the status waiting for customer for five days, the automation engine will add a comment to the issue asking the customer if more time is needed. This is a polite nudge or a reminder to the customer, letting them know that we're still engaged and available if need be. Agents and many service teams have to constantly keep track of issues that are pending customer responses with this rule. These cases are eliminated as the requests are actively followed up on and automatically closed if necessary: no manual intervention is needed. We're also able to control the messaging that goes out to customers in one central location.
Of course there are a lot of other cool variations to this rule. Perhaps it has been 10 days, let's go ahead and just close out that issue and insert a comment letting the customer know that they can always reopen this issue or raise a new one later on. We could even combine the prompting rule with the auto closed rule giving the customer a reminder on day five and then closing out on day 10 if we don't hear back. There are several ways that we can take some of the load off of the shoulders of our agents.
So as I navigate back here to my list of rules I can show another helpful rule: this is a variation of an auto approval rule. This particular rule will auto approve requests that have a cost of less than $10,000. We can see here that the rule is triggered when the status of an issue changes, the rule then does a quick check on the issue. Is it a service request? Is the current status waiting for approval? And is the cost less than $10,000? If so, the request is approved and automatically transferred to the next status. Once again, no manual intervention is needed. This is an example of the system working for us. We can also see in this rule that a user is alerted if the rule runs successfully. This gives us an ability to keep our finger on the pulse of the automation engine and know when it's running. Once again this rule can be slightly adjusted to help in several other scenarios: we could auto approve request raised by certain users or Auto reject requests that don't meet certain criteria.
I want now to introduce our guest today. This is someone I've known for a long time now and who is something of a rock star in the Atlassian ecosystem: Christian Reichert is the founder and CEO of Resolution, an add-on vendor for Atlassian products and one of our technology partners. I was lucky enough to get my hands on a presentation Christian did on the topic of providing legendary support. I was blown away by the content of the talk, the stats and figures that he presented, the passion with which it was presented and the overall philosophy that Christian and his team bring to providing great service to literally millions of users. Christian welcome to the webinar! We're so glad to have you here today.
Christian Reichert: Hello everyone! Hi Michael, hi Jill and thanks for introducing me so well!. So hardly have anything to say now, so lucky! I'm Christian Reichert I'm the co-founder and CEO of a Resolution, a small marketplace vendor in the Atlassian ecosystem, and I really like to talk about support. I'm quite passionate about it. In previous positions I've led very large support teams and a lot of that learning is something that helps me every day. Now I'm running my own business. Let me say one thing about Resolution: we provide the number one single sign-on app for Atlassian server and data center products. So if you want to integrate you Jira, your Confluence, Bamboo, whatever this serve our data center into an existing identity management infrastructure like Active Directory with ad FS or Asia ad opt Google G suite Shibboleth ping identity you name it, then we're actually the number one solution.
To do that we have about 3,800 customer installs with about 4.1 million licensed users and while single sign-on is a very simple concept from a user experience, you basically go to your Jira and you're locked in already and see your results just by the nature of you being locked into your PC or other enterprise application, it can nevertheless be protocol-wise and setup-wise quite complex. And large enterprises with multiple directories, multiple IDPs, non-matching usernames, so there's a big sort of complexity, especially during the installation, that you might have to work through.
With some of our largest enterprise customers and at the moment we only have from two people working our support queue every day obviously developers help. Once it comes to identify bugs and fixing them in the source code, but the brunt of the support work is done by two of my colleagues. If you want to see all of our apps, then just go to a marketplace Resolution and that forwards you to the Atlassian marketplace page, where you can see all the apps we have and that we developed. I said to people only on support now you, might say well yeah that's a number, that doesn't say, it doesn't say a lot people might be totally unhappy with that support they're getting, so if you just look at the customer satisfaction that we receive in Jira Service Desk I put this page middle of last week for the last two two weeks, so you can actually see it's a five out of five rating! And very good positive feedback from customer comments and that reflects what we get in the marketplace on the review of our app as well.
So whatever we're doing on support it's perceived very positive and producing very happy customers. This is usually a longer talk I hold, about an hour and a half, I go into people processes, tools and animations and other random stuff, but for this short webinar we're gonna jump straight away into tools and automation. One of the key lessons, first of all make sure that your customers have a good experience in whatever tool you use. So that's my number one rule: optimize what you've got for the customer! And the number two rule is an optimized for the agent, and then it's a close second because your agent needs to live in the tool. He needs all the information that he needs to work and work effectively at one point, so for the agent that means, for example, only show him the stuff he needs to know when he needs to know it. So customizing Jira Service Desk you show people what they need to work on what they need to work next on, but they also don't clutter them with with cases they can't do anything about it. Customize, optimize your SLA so that they are meaningful, that if people see they're being preached. if people see a percentage that it means something to them, and that they can do tangible actions based of it and optimizing for the customer.
For example I mean Jira Service Desk has a very nice customer interface already that looks good, but it also means provide links to the documentation, to your knowledge base, to your phone numbers, whatever the customer might need at their convenience. The information might be requesting a banner, if you know there's some major incident going on give them the information to to make that experience they have with your support get you Jira. Jira Service Desk and Confluence together we use all of it, and not just because we're Atlassian marketplace, when it's actually you have to pay for it, it's a very affordable solution for us to provide that stellar customer support. And also to that gives us a good level of Automation which is the next point really use automation!
The way I like to go about automation is I like to start manually with something by the agents, doing it ultimately by hand, so that they can figure out a good process, what works for them, what comes naturally to them, what gives a good customer experience. And then after 3-4 weeks, once that process has settled then really automat it and automat it as well as you can.
One of the other important things we do is templates! For me templates, and I'm going to go into knowledge bases on the next slide, for me templates are sort of snippets of text that can well be reused, and writing a template only takes a little bit more time than just writing it for an individual case. But if it can be reused, it's all the work that the team can collaborate on it, so they can improve each other's templates, and if you keep them small you can combine them. So the idea of an template is not to have a three-quarter page answer to a support case, it's a couple of lines of text that you can then where you can combine two or three or four to give the customer the answer they need. And that feels personal and targeted to the customer, yet it helped your agent to be really quick about composing it. And composing it in in a very good language helps, especially if English might not be their first language, so make it's a habit for the guys to create those templates, to keep them up to date, to help each other on those templates.
And the tools we use for that is company-wide. We use text expander for the templates that are more support focused. We actually use the built-in Kendra sponsors functionality from Jira Service Desk. If that's not enough for you then there's also kendra sponsors pro marketplace app, which even goes beyond than that. But it's a great way to have small snippets of text ready that you can easily combine into a very comprehensive and good answer for your customer.
We also make very big use of knowledge base articles. We have a linked knowledge base in Confluence and knowledge base articles for me and not templates as as I said before. I use templates that are small snippets of text and knowledge base articles for me is a bit more lengthy. Having a customer to understand, how you can detect the problem that the solution is, or if it's more FAQ style as a question about licensing it gives them a bit of a rundown how the licensing work how they can determine which licenses they need for our plugin, etc...
So it might be anything from half a page, two to three, four pages as an article, really helping them. Some have videos in it, screenshots, etc... You've seen knowledge base articles and we very often use templates to actually point to the URL of those articles so the knowledge base articles about licensing and there might be snippet. I've seen you're interested in pricing: here's one of ours which in depth explains how the licensing pricing works. Let me know if you have any more questions. That might be a template, that might be a template pointing to a knowledge base article: the main purpose of those knowledge base articles are obviously to reduce cases in the first place. If someone comes in, why the Service Desk portal that's very good to deflect those cases. And also again, make it a habit, like on templates: review close cases on a regular basis and you if you see some patterns or if you see some interesting content that might be helpful for other people market to turn into knowledge base articles. Direct their creation and Jira and then you have quite a comprehensive and good knowledge base in no time.
I'm also a big fan of tracking the article effectiveness in within Jira Service Desk you get some reports for that so you can see how many cases in the services portal a knowledge base article deflected and if you make your knowledge base publicly available outside of Jira Service Desk then you can use something like Google Analytics. For example to see which articles people are reading and reading more of it and that can give you a good insight about your platform, about your product, etc... And maybe turned it even into features or changes you want to do within your IT or product based on the results you get there.
But now let's jump to automations: Michael has shown you the Jira Service, a cloud version, these screenshots or the small screenshots I have are out of the Jira Service Desk Server version they look slightly different but ultimately it's the same thing underneath it and Jira Service Desk already comes with a very good set of automations that you can use straight away out of the box. And if that's not enough I've got some tips later on as well!
One of the first things we do by default, Jira Service Desk if you open a case it sends you a quick email or the notification: we've received your case we are on it. We turned that notification off and customized it with an automation word: when issue is created and then we have some probably 2025 different if statements based on which we then send at another comment. Which goes out by email to the customer, which it's different flavors of of the opening comment. So for example one customization we do is based on request channel. If you open in our sorter for example and pricing inquiry or a back report or something that's reflected in request types, request channels and based on that for example if you have a pricing question you might get a we received your case one of our agents will look at it shortly. I see you're looking your request has to do with pricing, here are some further links to our pricing and licensing FAQ.
Maybe you find that already and then we can point people towards more relevant articles. Yeah if someone has a bug report, we give them some troubleshooting advice and we point them to how to book a screen share session with us. If it's an urgent problem so that we can interact on the screen with them straight away. So we always try to provide them either a resolution or some next steps or some more information that can hopefully help them. Already before one of our agents actually gets to to look at the case early on, then the next one is transition on. customer comment that's an automation of probably fires at least a hundred times every day for us.
I mentioned in optimizing the tool you should only show I customize your cues that agents only see what they need to see and when they need to see it, which also means we have one status which is waiting for customer. So if we've updated the case and and waiting for customer response, or provide a possible solution, and then it goes on waiting for customer or possible solution provided, and then it's know then that case no longer shows chance work from because they can't do anything with the case, now so it shouldn't distract them. Having a lot of cases, thank you but then if a customer answers or updates the case then this automation rule is basically when a comment is added and the cases and either reopened, waiting for customer possible solution, provides that pre-release, provide their couple of stages like that it's a public comment from a user that's not an agent then move that issue into who state is called customer answered and then it's displayed in the agents queue again so they know this is one of the case they have to do something about and work on it another one is some SLA at risk or preached.
So we basically defined a set of SLA that we communicate to the customers and monitor and those isolation also are defined in Jira Service Desk and the rule I've got below here is the the one SLA time remaining there should be 15 minutes here time to first response. That means if we getting close to preaching that SLA then we add the comment for the team to see, and we alert myself and another colleague that there's a case running into trouble. Then there's another rule that we have which is if the actual SLA ever gets preached, to escalate the case and then also at the same time to flag it for review, so that when I run through those cases with a small team we can review it and see what happened. why did we preach the SLA? And how can we avoid similar cases in the future?
However SLA's can actually do a lot more with it. An SLA fundamentally is a timer! Yeah you might see that on the right of my screen, it basically says: when does the timer start? When does it get posted? And when does the timer finally stop? And how long the timer runs. For example on the bottom here you see 24 hours and 72 hours, you defined based on JQL statements, so you can have a different time or for high priority tickets or tickets in a certain status versus all other tickets. And you can also have a support time scale: in no or 24 by 7 calendar for the timer to to clock down.
So that's obviously great to track your real SLA's but you can also create something that I call automation SLA. So you can basically define SLAs just for automation and then use the is preached or closed to preach function in automation rule to kick off automation based on that time of being close to expiring, which would otherwise be very hard to do with other automation rules. So to give you some ideas, the overall of a age of a case you can easily track that based on different aspects or how much time has a case spent in certain status, and if it's running too long then kick off an automation rule to do something about that.
Another thing we like to use is update on link issue update, so updates all issue that are linked to a problem report, for example updates every feature request, that way if I have a, let's talk I talk for a second, you might have a problem record which is the underlying issue for, example a back in our software, and then you have multiple incidents that are caused by this problem and not just linked inaction of problems or user one experiencing this bug, views are to experiencing stuck user 10 customer 3 experience at, but we then link those incident reports back to the actual problem ticket and use an automation rule whenever we update the problem ticket with a public comment to update all those linked issues with it or transition it to another status. That way you can update a lot of people with just one simple entry in one of the problem records.
Or we use that for feature requests etc... as well another automation. We use to give you some ideas is around closing tickets, so where from I mentioned before we have different stages where we're waiting for customer to give us feedback, for customer for example and then we run through a three-step process: basically after a while we ask the customer nicely "we haven't heard from you for a while" then after that we'll wait another by standing at 7 days, and then we a bit more forcefully "hey could you please update the case, otherwise we assume your problem is resolved" and we close the case in 7 days and then after another 7 days it goes to a resource which closes the case with a resolution of abandoned by customer. so that we can actually track and report how many people have been in their cases and then then it gets with a final comment resolved, and all of this is achieved by automation rules.
So for every one of those transitions we have a rule which looks at if the case has been touched for not touched for 7 days or alternatively looks at the due date so if the due date is further in the future and we wait until the due date that allows us to push out those cases for longer. So if a customer, for example, once I say could you leave that open for a couple of weeks then we might put it out for 6 weeks for this automation to kick in. It adds a comment to the ticket transition set to the next phase, for example from waiting for customer to follow-up. Sets a new due date 7 days in the future and then it happens until it's resolved, or you've seen the other one where when the customer posts an update answers or does any other change, it actually gets bounced to the process step: customer answered. And it's out of this closed loop so that an agent can actually work on it.
Again so you've heard a couple of ideas, now let's just put some of the things to give you further ideas together. So how could you deal with a major incident? Basically if there's a major incident we add and update the banner to our Service Desk and that is to avoid cases in the first place, so anyone going to our Service Desk portal will see an acknowledgment: we know we have this issue at the moment we're working on it. This is the current status feel free to raise a request, watch this and you can actually also status plus page for people to subscribe to those updates. And for some public incident notification, what we also do, we update our rule with the initial incident confirmation and we add a section that acknowledges that there's a major incident in progress and what it is. And if you can specify that down to specific keywords then we just add that to the notifications for those keywords, if not we added to the general notification and then all our agent has to do during the time of a major incident is whenever case comes in that actually has that problem in it, he links it to the problem record.
We then have a link issue rule so that we can keep all incidents up to date by just updating the problem record so all the customers that actually do open I still do open a case or have opened it they get updated very simply by us keeping the major incident ticket up to date. And then once the incident is resolved we can then actually just do a issued query of all related tickets and we'll enclose those tickets or resolve those tickets with a action and a and a customer notification. That way you might be able to hundred twenty, forty, fifty hundred tickets just by keeping one up-to-date and keeping people during a major incident time really focused on what they should be doing, basically closing the major incident while keeping the customers informed very easily.
So far for the examples however you might reach if you do a lot of what I just said, you might actually at some point reach the limits of what can be done with the out-of-the-box automation. Then I can absolutely recommend looking into the app automation for Jira and there's also a lite version of that which is free GUI based very similar to the normal automation Jira and it also works in in general on Jira not just on Service Desk.
So you can automate all other to your projects as well and that's very powerful. To give you some ideas on the right you see there are a lot more triggers for Jira and use that. For example you can access information from sprints with automation for Jira, and then we use that. If a bug fix or feature request, a schedule for perforce for a certain sprint to inform the customers about it once it's in the released version, we inform customers and bounce them into different status and we do a fair amount of interaction with external systems by receiving and also by sending web books based on different studies and updates.
I hope you liked what you heard I certainly love if you if you give me feedback, like I said if you are actually interested in a much longer version of this talk then talk to Michael and chill and I'm sure they kind of facilitate something, don't hesitate to drop me a note and thanks for listening! Thanks for your attention and with that back to you Michael and Jill!
Michael Knight: Well thanks a bunch of Christian! We always love getting the chance to hear you speak about the success that Resolution is having, providing legendary support to customers. I think my biggest takeaway having seen this presentation a few times now is how simple it is to use the out-of-the-box functionality or combine two functionalities like we saw with SLAs and automation rules to create some really great customer service experiences.
Jill Cloud: Michael you're absolutely right! Customer service has become so important and the more automation we can incorporate into agents' daily tasks the better. Well Michael Christian, thank you so much for your time today!
Now let's get to some of those questions. Questions are already starting to come in, so we're gonna go ahead and get started with the first one: Can we create branch rules? Yeah, I can feel this one! So that's a good question and I think what the question is, is can we create these sort of conditional actions like if the issue contains this value for a certain field take one action contains a different value for the same field can we take a different action and the answer to that is yes we can add other conditions, other actions that fall sort of like an if-else statement.
Cool very good! The second question that we just got in is can we create a new issue as part of an automation rule action? Yep, I could take that one as well! And yes we can certainly create a new issue and we can even dictate what some of those fields are going to be, as that issue is created, so yes absolutely we can do that.
Okay very cool, so we're almost at time but we do have time for one more question: I've got one here and again like we said earlier, if we do not get to all of your questions, we'll be sure to follow up with you soon again. Michael last question: what about using certain phrases and comments to approve issues? Something like approve yes/no, reject etc.. Oh wow! Okay, yeah that's a fantastic question, yes absolutely we can do that! So we can put in some conditional logic in these rules to say I think it's if comment contains is the actual name of that condition but then we can put in some text field to take some action as long as the comment contains that piece of text. So yeah, that's actually a really good question! Just thinking here we can actually use that to leverage emails that come in so sometimes we'll have it set up to where an email that comes in on the request will add a comment to the request and that will actually allow people to approve requests via email, and you know, send it in an email that says approve and then we read it in from the backend as a comment that says approve and then we can go ahead and automatically approve that issue and maybe transition it if we need to. So yeah there's a lot of power there!
Awesome! Well Michael, thank you so much for your time today, looks like that's a wrap! But I want to make sure that you guys mark your calendars again for our next webinar on October 10th, again Christopher Pepe, Chief Technology Officer at Praecipio Consulting will take us through a more interpersonal approach to DevOps. Again think that's a wrap I hope everyone has a wonderful day thanks for joining!