Since 2013, Jira Service Management has been Atlassian's solution to IT Service Management for both internal and external customers alike; more than 8 years of continual development has led to countless examples of how JSM has delivered value to its users. In this 2014 video, we can see how Puppet Labs used Atlassian's Jira Service Desk, now Jira Service Management, to resolve tickets 67% faster. Take it from Atlassian's ITSM Partner of the Year three years running, we love how JSM supports your IT governance strategy. However, when defining a service desk for your organization, one of the most important decisions that you'll make is around how you define your Request Types.

What are Request Types 

In Jira Service Management, the request type defines exactly what the customer sees and how the ticket moves and is displayed after it's been submitted. 

Request types allow you to map a single issue type to different kinds of requests. For example, you may have issue types like Incidents and Service Requests. That's how your IT team understand incoming requests and they have the benefit of being able to span multiple contexts. However, as an end-user, when I'm coming to the portal I'm not thinking in ITIL terms. I'm likely thinking more along the lines of "I can't login" or "I need a new computer." 

Request types allow you to represent both sides of the equation - the foundation of your portal are the issue types, but request types let you customize how they appear to customers in the portal. So, let's see what exactly we can do with request types.

What can I do with request types

• Map a single issue type to many different request types: If there are multiple requests that follow the same workflow, you can utilize a single workflow across as many forms as you'd like!
• Group requests: You may have multiple requests that can be logically grouped together, like Software and Hardware.
• Change field display names: Even thought they're filling out the Summary field, on a request you may want it to say "What problem are you experiencing?" or "How can we help."
• Show specific Jira fields: While an agent may need to see and edit fields like Team or Priority, you probably don't want your customer to see those on Create.
• Preset fields: If certain request types have some constant information, you can preset fields without needing to modify the workflow or use any automation.
• Customize how workflow statuses are displayed: If you don't need your customer to know that an issue is being escalated to Tier 2 or Tier 3, you can mask those statuses so all the customer sees is that the issue is "In Progress" and they won't receive notifications as it moves through that internal workflow. 

With that in mind, there are some best practices to keep in mind. 

Request type best practices

• Think about the customer experience! Why are they coming to the portal?
• Don't necessarily break request types or groups down by IT org structure. While this could be useful, there are lots of ways to route request types to the right place without having it affect the customer view.
• Use hidden fields on your requests to simplify the experience - if you know a system wide outage is always urgent, don't make the user complete that field!
• Use hidden components or Team custom fields to route to the appropriate queues. 

At Praecipio Consulting, we have the experts that can help you implement ITSM best practices across your entire organization.  Contact us, we'd love to help!

When it comes to understanding the progress of work in Jira, Atlassian has some great options natively within Jira Service Management. Queues are available in each Service Management project in Jira and Dashboards are available in all Jira products. These features give users important insight into what teams are working on, but how do you know when to use which, and why? Having easy access to the progress of work in the system, as well as some of the stats that go along with the quality and completion of the work, is essential for any team's success. Below, I'll discuss the functionality of Queues and Dashboards in Jira and when one should be used over the other. 

What are queues?

Queues are groups of customer requests that appear in Jira Service Management projects. They are used by service desk agents to organize customer requests allowing the team to assign and complete customer requests quickly and efficiently. There are a few helpful queues that come with your service desk, but Jira Admins can also create custom queues if the ones in place are not the correct fit for the team. 

What are Dashboards?

A Dashboard is a page of reports and data visuals related to issues in Jira. Dashboards are customizable and can be tailored to meet the needs of various users throughout the organization. Individual users often create their own Dashboards to easily visualize what outstanding work they specifically need to get done. Teams can use them to see their overall progress of work. Management can use them to get a more high-level overview of the progress of work across the entire organization. Gadgets make up Dashboards and are often based on Jira filters or JQL. They typically come in the form of charts, tables, or lists. Dashboards are available no matter what kind of Jira project you're working in.

When to use queues vs. Dashboards?

Queues are great for agents and other folks who need to work on issues in a service management project. If queues are broken up by SLA's and/or priority, they help agents determine which issues are most urgent and need to be worked on ASAP. Then, agents can easily grab issues from the list and begin working on them. Queues don't give you any stats or overall status on work that's in progress or has yet to be completed. It's simply a way for those working on Jira tickets to organize them and decide what to work on.

While queues are limited to a single project, Dashboards can be used across multiple projects. They give more information on the work and can provide more details such as the time from creation to resolution, how many issues of a particular type were submitted in a given time period, and which agents completed the most issues. Dashboards are perfect for users who need to get an overview of what's going on, but don't necessarily need to work on the issues. Since Dashboards are meant for viewing Jira data, these pages are perfect to give higher-level users an insight into what's going on with the outstanding work. Using gadgets, these users can see where improvements need to be made if, for example, SLAs are continuously breached. They can also be used to see what works well for your teams. 

You have questions?  We have answers!  Contact us to schedule a call with one of our Atlassian experts.

Finding yourself in need of a solution where others can request for service, help and support without sending an email?  Do you have stakeholders constantly asking for status updates on things they emailed you 20 mins ago?  If so, you might be looking for a service desk solution, and Atlassian has a solution for you: Jira Service Management.  Here are four things you SHOULDN'T do when converting over to or just starting off with Jira Service Management:

1. Forget about the portal.  At first it might seem like extra effort because you can utilize SLAs and automation without a portal, but you will be doing your customers and yourself a disservice.  That, and you might be spending more than you should.
   1. By utilizing the customer portal through request types, you can take full advantage of quick support request with helper text, self service functionality, and customer alerting, allowing your agents to focus on resolving requests, and your customer to have a simple portal for updates and visibility.
2. Forget about approvals.  JSM makes approval auditing super simple.  Through simple query filters you are able to generate reports around approvals.  You can easily identify within the support requests, which approvals and who declined or approved.  And all of this can be done through the customer portal (see 1 above), with one click approval or denial.
3. Forget about SLAs.  When tracking performance metrics in your Service Desk, Atlassian makes it easy to configure SLAs, allowing visuals references in the support requests and well as generating reports.
4. Forget about Automation.  Through simple If..Then logic, Atlassian makes automating routine tasks a breeze.  Tired of aging support requests junking up your resolve status?  Add an auto-close automation to move them directly to Close without passing Reopen.

By taking advantage of the powerful out of the box features provided by Atlassian's Jira Service Management, you will be simplifying your life and delighting your customers. If you're wondering if it's the right fit for you organization's needs, or are looking for expert advice on all things Atlassian, contact us, we would love to help!

Customer Satisfaction, or CSAT, is a customer experience metric measuring satisfaction with a product, service or support interaction. The metric is captured through a short simple survey to enable the customer to provide their feedback.

CSAT in Jira Service Management

Did you know that your customer feedback is collected by default within Jira Service Management Projects? This means that when an issue is resolved, the customer receives an email requesting their feedback through a simple question such as "How satisfied were you with our service?". That simple question is editable, and can be defined by your project admin.

Remember, if you're utilizing next-gen projects, site administrator access is required to edit your CSAT survey question

There's a handy Satisfaction report built into Jira Service Management, visible to project administrators and agents. This report displays average customer satisfaction scores, as well as individual scores and comments for the team. You can toggle the report anywhere from the past 48 hours, all the way up to the past year by month!

It's also possible to configure your own custom report to track satisfaction trends. For example, you may want to see satisfaction by assignee, satisfaction by service request, or even a trend graph to track satisfaction changes over time.

The Pros of CSAT

CSAT, a very popular methodology, offers a quick and easy way to entice customers to give feedback. This then provides a clear metric for you to understand customer expectations, and work to exceed them. With CSAT enabled, your customers will receive a survey every time their request is resolved. This enables you to track customer satisfaction at different stages of their journey with your team, making bottlenecks and areas for improvement clear, with very little effort on your part.

CSAT also offers a fast way to compare yourself to your peers. According to the American Customer Satisfaction Index (ACSI), the average CSAT score across the nation is 76.5% - that's just over 3/4 of your customers reporting a satisfying experience. This figure differs by industry - you may not be too surprised to hear that, in 2019, Internet Service Providers and Subscription Television Services reported low CSAT benchmarks of 62%, while Breweries reported a much more favorable CSAT benchmark of 85%. But remember, while it is useful to be able to compare yourself to your competition, the true value from CSAT comes when you analyze and utilize feedback to drive continuous improvement and better your own customer experience.

Considerations of CSAT

While CSAT is a useful metric to track, there are a few considerations to take into account. The customer who takes the time to fill out their satisfaction is likely one who is happy with the service they received. Customers who are unhappy, or just moderately satisfied, are less likely to complete the survey, which can skew the data. CSAT has also been found to be a poor measure of loyalty - although poor CSAT scores can predict attrition, a high CSAT score has not been found to be a reliable predictor of repeat business. Cultural differences should also be taken into account - different standards and expectations will affect the score that customers are driven to pick, which, in part, can make it difficult to understand true customer satisfaction.

So, CSAT isn't a unicorn which can address all customer concerns with support. However, it does offer a valuable insight; one which should be paired with other tools to track and measure customer satisfaction. At Praecipio Consulting, we can help you make the most out of the benefits of collecting CSAT in Jira Service Management, and use those results along with other anecdotal evidence such as customer comments, number of tickets raised, cadence call discussions, and repeat business, to drive change, improve your customer offerings, and ultimately, reap the rewards!

How many times is the number of clicks, fields or screens having to be navigated through used as a reason that work efficiency is low?  It is a main way to discuss lack of efficiency by users of any system.  Well, Jira Service Management has automation built in for just these type of issues. And when leveraged properly, Jira Service Management automation can help drive closing out issues for users as well as ensuring customers feel engaged and informed.  

While time is a focus of most people, as it is the one thing that never stops: being able to use it effectively on things that NEED your attention is key.  Yet, the first hurdle most people have is identifying what actions do not need to be performed by someone.  Automations are things that can be based on inputs by a person, and therefore are always going to be selected the same. For example, filling in a customer based on name or filling out a number field based on selection of priority.  Once these are identified and agreed upon, you can then start to figure out the next phase: how to build the workflow around these to aid in the automation. 

One of the keys to automation is how the workflows are set up in Jira Service Management.  The workflow, when configured with either the correct transition or status or combination thereof, can facilitate the automation. Having a workflow set up to allow for automation based on a specific entry into a status or trigger of transition will helps both agents and administrators of Jira Service Management manage their work more easily.  On the administrative side, the proper set-up will allow for focused automation(s) and ensure they are easy to link without writing out complicated if-this-then-that statements.  On the Agent side of the house, the simple automation UI makes it easier for them to understand their triggers. The Agent can then move on to another issue until the need for follow-up arises. For example, transitioning a request to Pending Customer may pause the SLA, but automating the transition back to In Progress based on a customer comment alerts the Agent they've received their feedback. 

At this point you may be wondering what are some of the items that can be automated in Jira Service Management to ensure efficient flow of information.  Here is a list of some of the ways to use automation for communication:

• Customer alerts for approval
• Alerts for review of information
• Alert them to closure of ticket
• Alert to lack of response

The first part of the communication is understanding what YOUR customers will need from your team to understand what is happening with their issue.  For the most part, customers want to be appraised of receipt and communication of progress consistently.  With this mindset and communication to customers, you will inevitably save time by eliminating constant customer inquiry on what is going on with their tickets or the "do you need anything from us?" question.  While this can be a bit overwhelming at first, at Praecipio Consulting, this is one fo the many items outlined in our Accelerator for Jira Service Management implementation.  We have gathered best practices from many different implementations to put together a "starter kit" on automated communications. 

The other side of the automation for Jira Service Management is automating information based on user inputs.  By filling in specific fields based on user input or spinning up linked tickets to connect to the current issue, the automation inside of Jira Service Management for tasks that, while not hard, can become tedious, is where the Agents and Customers see the benefit.  Remember, the users main complaint centers on the amount of time they take to get the issue closed and move on to another one.  So while remembering that fields can be adjusted is a good thing, spinning up another issue that is linked is even quicker, thus eliminating the time to move information and instead having it done automatically by selecting the correct workflow transition.  

Overall, the key to getting the most out of the automation in Jira Service Management is first figuring out where you can save time for the users of the system.  Second, determine how to communicate to your customers in an effective manner that can be automated, but also ensuring your customers' satisfaction.  This should be centered on letting them know what is happening with their ticket and drawing them back in to the solution when needed.  As always, anything to remove steps (clicks) from the user is going to not only get more out of Jira Service Management, but also drive a higher usage of the system, correctly, back into your organization. 

We are experts in Jira Service Management, and would love to help you make the most out of this powerful tool.  If you're curious to see if Jira Service Management is a good fit for your organization, drop us a line and one of our experts will get in touch with you.

DIY or DIE!

For those of you watching from home, I have been on a home improvement journey for quite some time. Applying an Agile mindset to home improvement (or really anything I do) is one of my passions. Even at my most recent Women in Agile meeting, we discussed applying Agile concepts to daily life and feeding these back into building a great resumé. One of the principles of the Agile Manifesto reads: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. We all know this applies to Agile development practices, but it also applies to IT Service Management. Specifically, Incident and Problem Management. For me, it applies to my recent home improvement adventure. 

Strong fences make great neighbors

My neighbor and I spent the better part of a Saturday fixing our mutual fence. You see, I have two dogs: Leonard and Howard.

oth are rescues. Leonard is eight and was "free to a good home" while Howard is four and was adopted from my county's animal shelter. Both dogs have been with us since their puppyhood and, as any dog owner will say, they are the BEST. DOGS. EVER. Except when they're not. This was not the first time my neighbor and I had to work on the fence. Observe one of the troublemakers in his natural habitat. 

This epic saga started in May of last year. I would diligently fix loose boards, prop items against the fence to "patch" holes, and monitor their outdoor activity while I was awake (awake being the key word here: 3am barking and fence-patching sessions are no fun). I supplied my neighbor with fence planks because, well, they're my dogs. We fixed the section above and let the others lapse until a series of shenanigans prompted my neighbor and I to spend our Saturday replacing three additional sections. My neighbor and I became united in making sure my two didn't escape. While my neighbor "doesn't care" that my dogs are in his yard, my (very good) boys take the opportunity to break out of his fence and wander the neighborhood. Howard usually comes back, but Leonard meanders through the streets, swims in pools or the lake, and generally causes mayhem until I can coax him in my car to come home. 

Not in my back yard...

Before this latest patch, I was determined to find the root cause. Previous to May of last year, this was not a problem. My puppers would frolic in the backyard and simply bark at other dogs in the neighborhood as they walked by. I made sure they were let out several times per day to make sure they were relieved in addition to daily walks. While I was traveling, they were also well-taken care of and monitored. What changed? 

Root cause analysis is, simply put, problem solving. While it is widely used in sciences and engineering, it is also a key element of IT Service Management Incident and Problem Management. When reacting to an incident, the team must restore functionality as quickly as possible. Upon resolution, root cause analysis helps us understand why. It then prompts us to ask, "Is there an action I can take to prevent this from happening again?" Incident Management leads to Problem management and through root cause analysis, we can move from a reactive organization to a proactive organization. 

Of the many techniques of root cause analysis, my favorite is the "Five Whys". It is the simplest technique: ask why until you've identified the root cause. Not like a petulant child, however. Asking the first why should be easy, then continuing to ask well-curated questions based on the previous answer helps you determine the root cause. I applied this to my situation: 

• Why do I have to replace parts of the fence? 
  Because the dogs are chewing through the fence.
• Why are the dogs chewing through the fence?
  Because they can access the backyard whenever they need.
• Why can the dogs access the backyard whenever they need?
  Because we installed a dog door.

HA! I found it. The root cause. And it didn't even take me all five whys. 

Any root cause analysis technique does not stand alone. There exists a plethora of other techniques. Pareto charts determine that 80 percent of your problems are derived from 20 percent of the causes. An Ishikawa (fishbone) diagram looks at measurement, materials, methods, machines, management, and mother nature. Scatter plots let us look at correlation and causation. Was the dog door the root cause? The existence of a dog door doesn't change the behavior of my boys. Having access to the backyard doesn't make them chew through the fence planks. Did we ask enough questions to actually identify the root cause? Did I also consider a Pareto analysis, an Ishikawa diagram, or a scatter graph to understand why I was constantly chasing my boys through the neighborhood? 

I stopped at three whys: "I have a dog door."

What happens if I keep asking why? 

• Why did we install a dog door? 
  Because Howard wasn't fully potty trained. 
• Why wasn't Howard fully potty trained? 
  Because I didn't take the necessary time to train him. 

AHA! My Ishikawa diagram identified "management" as the issue. My Pareto identified the 80 percent as my time to train my puppers. My scatter plot showed the amount of time spent correlated to the amount of dog-induced shenanigans. I would add these to the post, but won't because...reasons. More importantly, I simply kept asking, "Why?" until I identified the root cause. 

Actions speak louder than words

Now that I have a root cause, what is it that I can do to prevent this issue from recurring? When looking at Incident and Problem Management, Atlassian products such Opsgenie and Statuspage can ingest, aggregate, correlate, and trigger the creation of Jira Service Management issues. With Confluence, we can create specific root cause analysis templates to be shared with our customers and stakeholders. However, it's up to our techniques and processes to help us determine the actions we need to take going forward. 

For me and my puppers, it's simple. 

1. Take at least 30 minutes out of my day for dedicated doggie exercise
2. Reinforce good behavior while in the yard
3. Lock the dog door overnight (no more 3AM "let me sing you the song of my people" moments)
4. Finish replacing the aged planks on the fence

By taking these actions based on my root cause analysis, I should have this solved quickly with redundancies built in. My puppers will be safer and happier, I will have a beautiful new feature of my home, and the three of us will have less stress day-to-day. Using root cause analysis techniques, and Agile mindset, and drawing from IT Problem Management, I can easily solve this problem and any additional ones around my home.

BRB, gotta run and get some more fence planks.

Setting up an email account within Jira Service Management (JSM) allows different clients to provide extensive information without using the Portal every time they have a question.  While this is a great functionality within JSM, and quite easy to set up, there are some key items to remember to ensure all works well: things that can be required, setting up the queue, and email addresses do's and don'ts.  

As you set this up, not only will you need an email address tied to an inbox, but it's just as important to have a request type set up in your JSM project. The request type should be hidden from the portal; this way it cannot be selected as an option if someone accesses the portal to create requests. This will give you control and the ability to clearly separate emailed requests from ones created through the portal by other users/customers. Once the request type is set up, you can only require the Summary and/or Description to be set.  These two fields will be pulled directly from the email, with the subject becoming the summary and body of the email becoming the description.  If you try and require any other fields, the request type will fail and the emails will not be processed into requests automatically. 

In conjunction with setting up the request type for the email is setting up the queue for this specific request type.  Remember, you are able to reference the name of a request type in JQL searches. This allows your agents to quickly identify which requests were created via email and not just lumped into the other queues.  Due to some of your requests being created through email, the communication back to the customers is critical to make them feel like the request is being seen. The queue will alert the team when there are incoming email requests, and coupling them with SLAs correctly, will focus the proper communication and solving of these issues consistently. 

Lastly, think critically about the email address you select.  First, the email needs to be specifically used to receive issues from customers; this means it should not be used for mass communication where you also get NoReply email addresses, or mass communication that will cause false tickets to be created.  While you can add certain automation into JSM to look for specific emails and not respond to them, the point of JSM is to allow for ease of administration of a Service Desk of which customer communication is the most critical item. 

Overall, the email request creation for JSM is a great option, which is at times easier for users/customers to use versus going onto a portal.  With the proper configuration and use of the recommendations in this article, the email will function and you can maximize the effectiveness of JSM email requests.  Always keep in mind it is better to have a purposed email address than to reuse one and wonder why some emails work, some do not, and there are loops of comment(s) being sent due to NoReply. 

For any help with this issue, or anything else Atlassian, drop us a line, we live and breathe Atlassian, and would love to help!

As companies grow either organically or inorganically, many are faced with the decision of whether they should consolidate or keep their Jira instances separate. Today I'm going to address one specific flavor of this conundrum that I am often asked about, specifically with regards to separate instances of Jira Software and Jira Service Management. Some organizations choose to have separate instances for Jira Service Management and Jira Software, but I am here to tell you that is probably not necessary!

Although Jira Software and Jira Service Management are different products, there is no need to keep them separate. The most efficient companies use both in a single instance, so that teams can collaborate much more easily. As organizations adopt DevOps or start to think about it, one of the first things that is looked at is how IT interacts with the development organization. If these two groups are working in separate Jira instances, collaboration and clear understanding of ownership and handoffs is much more difficult. For example, It is much easier to link an incident that was submitted to the service desk to an associated bug if all of those tickets live in the same instance. While you can link to tickets in other instances, that requires users be licensed in both and have a clear understanding of where the work lives. Working in a single instance removes the need for potential duplicate licenses and ensures teams can communicate clearly. 

Occasionally teams use separate instances due to security considerations. However, in almost all situations your security concerns can be addressed by project permissions, application access, and issue security. There are few cases that Jira's native security features won't account for. 

Finally, let's look at this from a user experience perspective. One of the most prominent complaints that we see as organizations undertake their digital transformations are that users have to keep track of too many tools, a pain that I've felt in my career as well. Trying to remember where to log in for a specific subset of your work can be a headache. If your Jira Service Management and Jira Software instances are separate, they'll have two separate URLs that users have to navigate to. Signing into multiple locations and using different URLs adds an extra step where there need not be one.

Since you've already made the great decision to use both Jira Software and Jira Service Management, you might as well reap the benefits of the easy connection between the two so your teams can focus on what matters, rather than managing their tools. 

Are you looking to merge your Jira instances? Contact us, we know all about how to do that, and would love to help.

When using Jira Service Management to manage your team's service desk, it's extremely important to ensure that your end-users have a good experience. Otherwise, they may become frustrated with the tool and stop using it to submit requests. With the broad range of clients we serve at Praecipio Consulting, we've found one of the biggest keys to a successful service desk is clearly setting customer expectations and meeting those expectations consistently. Jira Service Management comes with Service-Level Agreements (SLAs) that teams can use to set those expectations and give customers transparency around them. It's important to set reasonable goals for your SLAs, and with automation you can make it easier for your agents to stay on top of those goals so your customers are satisfied.

Here's how:

Automate alerts to agents when SLAs are about to be breached

For your SLAs, it's important to be consistent with meeting the expected goals assigned to them. This allows your agents to build trust with customers and encourages customers to continuously use the service desk for their requests. With automation, agents can be alerted when time is running out on an SLA. For the automation rule, there's a trigger titled "SLA Threshold Breached" that works perfectly in this scenario. This trigger allows you to set when an alert should send to the assignee of the request based on how much time is left on the particular SLA. The assignee is then made aware that they need to make progress on the issue and can stay on top of the SLA goal. This, in turn, leads to a happier customer and an increased sense of trust in your agents. 

Automate alerts to customers if a ticket is pending their response 

It's good practice in a service desk to configure so that if a ticket is pending a response from the customer, a "Waiting for Customer SLA" is set to give them time to respond. If the time passes on that SLA (we don't receive a response from the customer after a certain amount of days), the ticket is automatically resolved. Before we automate this though, it can be helpful to send out an alert to the customer to remind them that the ticket is waiting on their response. I've seen customers become frustrated when a ticket is resolved without alerting them that it was waiting on their response, as they simply forgot about their pending request. Sending out reminders sets clear expectations with the customer that the ticket has not made further progress due to inaction on their end and gives them the chance to interact with the request before it's automatically resolved. Other times, you may not receive a response from the customer because they no longer need your assistance. In these situations, the automation to resolve tickets pending customer action after the "Waiting for Customer SLA" is breached can save your agents time and effort, as they don't have to keep track of the time pending a customer response and manually resolve the ticket themselves.

We've seen so many clients reap the benefits of using automation to help their teams stay on top of their SLAs. Not only does it build trust with customers and in your organization; it also fortifies your service desk and improves your the experiences of your end users and agents! If you need help with SLAs, or anything else Atlassian, reach out and one of our experts will contact you ASAP!

In November of 2020, Atlassian rebranded Jira Service Desk to Jira Service Management. With this rebranding, Atlassian sought to make one thing clear: JSM isn’t just for IT. In fact, any team who receives requests from others, whether from external or internal customers, can utilize JSM.

Similarly, IT Service Management (ITSM) doesn’t have to be just for IT either. IT organizations around the world benefit daily from applying ITSM principles and processes to their own organizations. Enterprise Service Management (ESM) sees this success and seeks to take it a step further, contending that ITSM practices can be applied even outside of IT teams, which allows for similar successes in other departments. JSM agrees, and it even has quick-starts in Atlassian Cloud for some business teams, including HR.

By now, you may have already read about the ITSM capabilities that can be leveraged by your HR department. You may even already have a few use cases in mind. At Praecipio Consulting, one of the most frequent JSM use cases that we encounter for HR is onboarding and offboarding. 

To start, you’ll want to be sure that you have one request form for onboarding and another for offboarding. One of the things that makes JSM great for non-tech teams is the ability to change display names for fields and add help text to forms, making it even easier for people who aren’t familiar with Jira to submit requests.

As onboarding and offboarding are typically handled by multiple teams and individuals, you can also utilize an app to auto-generate subtasks for each Request or Issue Type on issue creation. This is also possible in Jira Core and Jira Software, of course, but having this driven by a request created through the portal means that a user can set it in motion with more ease than they would be able to otherwise.

Queues are another JSM feature that will be helpful for your HR team once a request is submitted. You could set queues up for just onboarding and offboarding, or you could even go deeper, having queues that differentiate between full-time employees, part-time employees, and contractors, as an example. Queues can be set to run on anything you’re collecting in your form.

Once a request comes in, you’ll benefit from the Service Level Agreements, or SLAs, that JSM can apply. SLAs can be set based on any number of criteria, so your HR team can easily track if they’re meeting expected targets, as well as have another way to prioritize their work. For example, a high-priority offboarding will need more attention than onboarding that’s more than a week out, so the SLAs can be set accordingly, with more time afforded to less pressing tasks.

Onboarding and offboarding are common needs in every HR department, but these same features can be applied to most HR tasks you can think of, like PTO requests, asking for assistance with benefits, or even recognizing a colleague.

The rebranding of JSM is a message to all teams, in all companies, that service tools are not just for IT. They can be a huge benefit to many teams, and HR is a great place to start. 

At Praecipio Consulting, we offer a wide range of services for HR teams (or any team, for that matter) looking to use best-in-class ITSM tools. Reach out today and let us know how we can help you make the most out of JSM.