Migrating to cloud can be a challenging move for any organization: there are many moving pieces to keep track of, and with the threat of negatively affecting both internal and front-facing operations, failure is not an option! Here are some key blockers to keep in mind when migrating to Atlassian Cloud from on premise instances, so that you can review ahead of time just how prepared for a successful migration your company is:

• User Management
• Automations
• Size of Attachments
• Apps

User Management

User Management and how users are set up is a major difference when operating in Atlassian Cloud versus on premise. This is an important obstacle to understand and address, as the approaches for user management are different between cloud and on-premise. Key to this is how users are created and managed; equally important is identifying any users with missing or duplicate email addresses, since these cause problems with data integrity and users being able to use Filters and Queues in Atlassian Cloud. 

Automation

Automations are critical to research, as some automations may not be functional or even allowed in Atlassian Cloud: these will need to be identified and assessed to determine the balance between the value they bring and the level of effort of recreating them. 

Attachments

Size of Attachments becomes critical when using the Jira Cloud Migration Assistant, as this does not support migrating Jira Service Desk projects, which may require importing data via Site Import that forces attachments to be uploaded separately in 5 GB chunks, one chunk at a time. This alone will drive the migration of attachments to exceed a typical outage window, as the Site Import process must first conclude prior to uploading attachments. 

Jira Service Management utilization is tied to the size of the attachments as noted above. While JSM is used heavily it is currently not able to be migrated using the Jira Cloud Migration tool. With that being said this drives the use of site import. With this comes having to migrate the users and attachments separately. This becomes more moving parts during the migration outage and the coordination and timing will become even more critical.  

Apps

Jira Suite Utilities (JSU) / Jira Miscellaneous Workflow Extension (JMWE) / Scriptrunner are apps available in the Atlassian Marketplace that may be used in one or more of your current workflows. While these apps have helped to drive the creation of workflows and processes to automate certain transitions or enforce proper data collection, there is also no current migration pathway to Atlassian Cloud. While JSU has become part of the native cloud, JSU along with the other two apps must be manually fixed in all workflows migrated up to the cloud. You must run a query on your on premise data base to ensure you map out all transitions affected by the apps. Then once the migration to cloud is complete, they must be reviewed and recreated manually to ensure they are all working properly. Where possible utilizing the out of the box options, that mimic JSU, can help to move away from at least one app. 

Specific to Scriptrunner, one common scenario is the use of it in filters can cause them to no longer function, potentially causing boards and dashboard to render incorrectly. These filters must be rewritten using the Scriptrunner Enhanced Search functionality. One good example is any filter that contains the phrase "issueFunction not in" will need be rewritten as "NOT issueFunction in". It would be advisable, when doing the migration to Cloud, to open a ticket with the vendors for advise on how to fix scenarios with JQL that worked in Server/Data Center that no longer work "as-is" in Cloud.

Overall these key obstacles will get you on the correct path to understanding what you know will need to be done in preparation for starting the migration. This by no means is a complete list of the only obstacles that you can encounter, but we hope it will help you to be proactive in fixing obstacles before they become a blocker to the migration.

We are Atlassian experts, and understand how the move to cloud can be fraught with unpleasant surprises. If you have any questions, or are in need of professional assistance, contact us, we would love to help!

The change to remote work has forced Information Technology (IT) teams to quickly and efficiently serve their customers. Due to this, many people talk about using ITSM processes or ITIL strategies to help their teams. But what does this mean? Are they the same? Or completely different? What does an IT team implementing these practices look like? To understand this, we first have to understand ITSM and ITIL. 

What is ITSM?

Atlassian defines Information Technology Service Management (ITSM) as a way IT teams manage the end-to-end delivery of IT services to customers. This includes a defined set of processes to design, create, deliver, and support IT services. 

The core concept of ITSM is the belief that IT should be delivered as a service

I think of ITSM simply as a set of tools you can use to improve your IT team. Just like you would use a handsaw to cut a piece of wood or a screwdriver and a screw to connect two pieces of wood together, you have to think about what you would like to accomplish with your IT team and which tool would be best for the job. 

ITSM processes focus on your customer's needs and services rather than the IT systems behind the scenes. These processes, when implemented properly, can help cross-department collaboration, increase control and governance, deliver and maximize asset efficiency, provide better and quicker customer support, and reduce costs across the organization. What are some of these magical processes? Glad you asked! 

1. Service Request Management
   Any incoming inquires asking for access to applications, software licenses, password resets, or new hardware is classified as Service Requests. These requests are often recurring and can be made into simple, duplicable procedures. These repeatable procedures will help IT teams provide quick service for the recurring requests. Applying well-designed practices to your Jira Service Management application can streamline the process for an organizations' customer to create Service Requests and for internal IT teams to act on the Service Requests.  

2. Knowledge Management
   The process of making, sharing, utilizing, and managing data of an organization to attain its business objectives can all be a part of Knowledge Management. Creating a Knowledge Base (KB) for IT teams to create content is crucial for teams to learn from the past and maximize productivity. Having a collaborative workspace, such as Confluence, for all teams to work within can help create one source of truth of information. KB articles can also be shared with your customers through the Jira Service Management portal to help resolve common or simple Service Request without having to contact the IT Team. 

3. IT Asset Management (ITAM)
   IT Asset Management (also known as ITAM) can help ensure valuable company resources are accounted for, deployed, maintained, upgrades, or properly disposed of. Because assets have a relatively short life-cycle, it is important to make the best use of all assets. Integrating tools such as Insight with your Jira instance can help track all valuable assets throughout your organization conveniently within Jira issues in real-time. 

4. Incident Management
   Any process that is responding to an unplanned event or downtime will fall under the Incident Management bucket. The only goal of Incident Management is to make sure that problematic services are brought back to their original operational status in the shortest time possible. For any incident to be quickly resolved, the original reporter has to be able to quickly communicate with the proper IT team asking for help and the IT team must be able to easily communicate back with the reporter to gather any relevant information needed to solve the problem. Jira Service Management can help make this crucial communication effortless.

5. Problem Management
   Taking lessons learned from an incident and determining the root cause of the problem so that future incidents can be prevented or, at minimum, limiting downtime is the basis of Problem Management. Once a root cause analysis is performed on an incident and documented within your Confluence instance, the impact of future incidents can be reduced. 

6. Change Management
   Change Management can be used to control and understand the impact of changes being made to all IT Infrastructure. The Change Advisory Board (CAB), a group of individuals tasked with evaluating, scheduling, and validating a change, can be leveraged to better maintain and ensure the stability of your IT Infrastructure. By taking advantage of Jira, employees can easily suggest changes and the CAB will be able to review the proposed changes, approving and scheduling the change as they see fit. 

To see these processes in action, let's consider a tangible example that will help bring it all together:

"Austin Snow" is a new employee at your company. As part of the onboarding process, they will need a brand new laptop. As their manager, you submit a Service Request to your IT team through the Jira Service Management Help Center. An agent in your accounting department is then assigned to this task. Using information from a KB article that has been built out in a Confluence page, the agent can see that they are supposed to put in a purchase order for the new device. From the Confluence page, the agent also knows to add this new asset in Insight and assign ownership to Austin.

Once the laptop is delivered and Austin tries to access an application and finds that they get a 404 error message. Austin reaches out to the IT team through the Help Center to create an incident with them. The IT team then proceeds to investigate this issue. They can find the root cause of the problem and fix it. Using the lessons learned from this incident, the IT team performs a root cause analysis (RCA) for the problem. As a result of the RCA, it is found that a change to the organizations' infrastructure can help prevent this problem in the future. The IT proposed the change to the Change Advisor Board (CAB) who then investigates the impact of this change, weighs pros and cons and schedules an outage window to perform this change. 

As can be seen in this example, ITSM processes can help quickly fulfill requests, transfer knowledge, keep track of assets, respond to problems, identify the cause of a problem, and implement any changes needed to prevent problems in the future. 

What is ITIL?

Information Technology Infrastructure Library (ITIL) is a set of best practices designed to support a company's IT operations. ITIL was introduced in the late 20th century as a series of books by a government agency in Great Britain in an attempt to help the British Government provide a better quality of IT service at a lower cost. ITIL v2 condensed all of the content in the early 2000s into nine publications. These two older versions are seldom used, most organizations currently implement ITIL v3 or ITIL 4.

ITIL v3

In 2007, ITIL v3 introduced the service lifecycle, a set of five core publications, to help organizations focus on continual improvement. The ITIL Service Lifecycle consists of five stages; Service Strategy, Service Design, Service Transition, Service Operation, and Continuous Service Improvement.

Source: AXELOS, “ITIL Foundation: ITIL 3 Edition” (2007 - Updated 2011)

The Service Strategy stage helps level set the expectations of an organization so that a service provider can meet the organization's business outcomes. The Service Design stage helps the service provider gather all the requirements and create a plan to turn an idea into reality. The Service Transition stage is when the design from the previous stage is implemented and made ready to go live as smoothly as possible. The Service Operation stage focuses on making sure the services being provided are being fulfilled as agreed upon. Finally, the Continuous Service Improvement stage focuses on service provided staying agile and keeping up with the ever-changing needs of the organization. 

ITIL 4

Most recently, ITIL 4 took into consideration the latest trends in technologies and service management to help organizations as they undergo digital transformation. ITIL 4 consists of two main components; the four dimensions model and the service value system (SVS).

Source: AXELOS, “ITIL Foundation: ITIL 4 Edition” (2019)

The four dimensions model lays out four key areas to consider to ensure a holistic approach to service management. These four dimensions are Organizations and People, Information and Technology, Partners and Suppliers, and Value Streams and Processes. The four dimensions have to work together to help ensure that any Product or Service provided to the customer is able to provide value in an effective and efficient manner.

For example, in the above Austin Snow use case, the Organizations & People would be the HR Team performing the onboarding, the IT team helping deliver the laptop, the Support team handling the outage, and Austin Snow themself. The Information & Technology would be all the tools, Jira Service Management, Insight, etc. that were used to help Austin. The Partners & Suppliers would consist of the internal IT team in charge of the service request and incident management or any other external team that as leveraged to deliver the request or fix the incident. finally, the Value Streams & Processes would consist of any well-defined procedures that were used to help deliver the service to Austin.

Source: AXELOS, “ITIL Foundation: ITIL 4 Edition” (2019)

The service value system lays out how all the components of an organization have to work together to provide maximum value. To accomplish this, 5 main elements are used produce Value from an Opportunity or Demand; Guiding Principles, Governance, Service Value Chain, Practices, Continual Improvement. 

Guiding Principles help define how an organization will respond in all circumstances. These principles should be considered when making any decisions. Governance defines how an organization is directed and controlled and always stem from Guiding Principles. The Service Value Chain is a set of inter-united processes used to deliver a product or service to a customer. Practices are resources to help perform work. Continual Improvement is how the process can be improved to help provide the most amount of Value to an organization. When all of the elements of the SVS are implemented and used properly, an organization will be able to capitalize on every Opportunity. The four dimensions must be considered with all elements of the SVS to ensure a great quality of service is provided to your customers. 

ITIL v3 and ITIL 4 are essentially guiding the same fundamental ideas of service management. ITIL 4 takes a new approach to provide this guidance. It is important to consider the inner workings of your organization to understand a set of principles that will best mesh with your organization. 

How are they related?

Now that we have laid down a foundation for ITSM and ITIL concepts, let's explore the relationship between ITSM and ITIL.

Unlike the title of this blog may suggest, these two concepts are not opposing ideas. ITIL is a framework of ITSM, meaning ITIL takes the concepts and values of ITSM and lays out a set of defined best practices that organizations can easily apply to their business to help improve IT services. In other words, ITSM processes describe the "what" while ITIL best practices describe the "how". 

ITIL is not the only ITSM framework; frameworks or processes such as DevOps, Kaizen, Lean, and Six Sigma are also implemented by organizations. ITIL is the most popular ITSM framework to help improve IT service delivery.

In summary, ITSM is a defined set of processes to design, create, deliver, and support IT services. ITIL, a framework of ITSM best practices, can be used as a set of guidelines to quickly adopt ITSM principles into your organization. These guidelines can then be continuously improved to be a perfect fit for your unique IT team. 

As The Digital Transformation(ists), Praecipio Consulting can help you integrate digital technology into all areas of your business. For more information, please check out these case studies: FORTUNE 20 ELECTRONICS COMPANY OPTIMIZES JIRA AND CONFLUENCE FOR ITSM BEST PRACTICES and WORLD'S LARGEST BEVERAGE AND BREWING COMPANY MIGRATES TO ATLASSIAN ITSM PLATFORM and blogs Three Weeks to an ITIL-based Service Desk—No, Really. 

If you have questions on ITSM or ITIL, and wonder if your organization can benefit from these powerful methodologies, contact us, and one of our experts will be glad to help.

We're always looking for ways to keep track of our stuff, from old metal asset tags firmly glued to lids of the first "portable" computers to Apple's recent AirTag product release.

At work we call these "assets" because they cost money to acquire, maintain, replace, and are (hopefully) required for our organization's operation. (If assets are not being used, your digital asset management system should be highlighting that potential savings opportunity!) Keeping track of these items doesn't just make sense from a financial perspective, it's also required by law in many cases.

When it comes to asset management we're not just concerned with an item's current location. Surprisingly often, an asset's purchase price, age, vendor, warranty details, user assignment, support/maintenance contracts, service history, and any of hundreds of other details become critically important to keeping the asset—and therefore our business—running.

And we're not just talking about physical assets like desks, laptops, phones, tablets, tools, networking equipment, etc. The move to cloud means we can instantly deploy servers, licenses, and other IT infrastructure we'll never actually see or touch! How do I put an RFID tag on a cloud server?

With more devices and services being employed to operate our organizations every day, spreadsheets don't cut it. Given this amount of critical data to manage, the only way to keep up is to turn to digital transformation.

Traditional Configuration Management Databases (CMDBs)

The technology market has seen the introduction of many inflexible, expensive "solutions" to manage assets digitally. Traditional Configuration Management Databases (CMDBs) have failed to deliver the necessary transformative power:

• IT is overpaying hundreds of millions of dollars in unused features in these legacy CMDB tools
• Customization requires specialized consultants (quickly adapting to the changing needs of the business is a core tenant of digital transformation)
• Legacy tools often result in slowing down the flow of work across teams instead of enhancing collaboration between them

Praecipio Consulting is transforming organizational service delivery with an Atlassian alternative built to deliver maximum value: Insight, now built into Jira Service Management. It is a modern, flexible digital asset management solution to easily define collaborative asset tracking that best fits your organization's needs, right in Jira.

Atlassian Service Management saves companies money by retiring their legacy tools. This explains why Atlassian is ranked as a strong performer in this market, having a strong strategy, and achieving a rapidly expanding market presence.

From employee and contractor onboarding to incident management to asset intelligence, Atlassian Insight for Jira Service Management can quickly get your digital asset tracking under control and flex to meet your constantly changing business.

Digital asset management done right doesn't just require the best-in-class solution, however. It's a cultural shift in the way IT is delivered as a service. Contact Praecipio Consulting to get started on your service delivery transformation now.

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.

Both 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. 

Michael Porter, a former Harvard professor, is one of the founding fathers of business strategy. He lent credence to the field by developing several ideas, frameworks, and theories around strategy that have been utilized, debated, and taught for four decades now. You may be familiar with his 5 Forces model, which is used to analyze the competitive landscape of a given industry, or his course titled “Competition and Strategy”, a requirement for all first-year Harvard MBAs. Though his ideas and theories are certainly not perfect and have evolved over the years, they laid the groundwork for modern businesses to think about their strategy, their position in the market, and their ability to move forward.

And when you think about it, it’s weird that some consider Enterprise Service Management to be a new business process management trend. Let me explain. 

In 1985, Porter co-authored an article with Victor E. Millar in the Harvard Business Review titled “How Information Gives You Competitive Advantage”. In it, he laid out a central argument that said with the explosion of computer usage, companies would have access to a ton of information, flowing freely through the organization, that would allow managers to make more informed decisions faster. This, Porter argued, would fundamentally change how business was done and provide new ways for companies to stay ahead of their competitors. 

Consider this excerpt from Porter’s article:

“The value a company creates is measured by the amount that buyers are willing to pay for a product or service. A business is profitable if the value it creates exceeds the cost of performing the value activities. To gain competitive advantage over its rivals, a company must either perform these activities at a lower cost or perform them in a way that leads to differentiation and a premium price (more value).”

In other words, to gain an advantage over competitors, companies must perform their value activities at a lower cost or in a way that adds more value. Porter foresaw the drastic increase of information that would be available to businesses with the shepherding of the digital era. He logically concluded that such information, if used and communicated correctly, could be advantageous to managers looking to make decisions around the value-added activities in which their business engages.

The prediction of a sharp increase in the amount of information has certainly come true. In the era of big data, companies gather, store, process, and use more data than ever before. The problem is that typically this information is siloed, only about one particular subject, or only accessible and understandable to a few highly-skilled workers. This is the problem that enterprise service management will solve to bring Porter’s 35-year-old vision to fruition once and for all.

Enterprise Service Management (ESM) holds that the (mostly digital) processes that have been championed and used to gain efficiencies by IT teams for so long apply to the business as a whole, as seen by the adoption of similar processes and technologies in departments like HR, Facilities, and Procurement. ESM suggests that an organization should have a tool, which typically takes the form of a piece of software, that allows information to flow easily, quickly, and freely through the organization (sound familiar?). At Praecipio Consulting we have grown fond of referring to this as an operating system for business - one central piece of software that is used nearly ubiquitously in the organization, one that allows work to flow from division to division, team to team, teammate to teammate, with no loss of information and an attached, rich history.

Consider the typical lifecycle of the development of a new offering by a business - whether that be a software feature, physical product, or a new service offering. Marketing will research the market and determine where gains can be made. They will pass intel along to Product, which will develop these insights into a new product idea. The Product team will work with Development to create requirements, Dev will build it, QA will test it, and then it will be released to the market. Along the way, Marketing will generate buzz, Sales will sell, Legal will validate legality, HR will manage employees working on the offering, so on and so forth. In short - it takes a village, a coordinated effort among teams from different parts of the organization to deliver the new offering to market. 

The logic of a single system which transmits work in this lifecycle with no loss of info and rich history is apparent, as is the cost savings garnered from a single license paid to a single vendor, maintenance and training for one system instead of several, and usage of an efficient process unmarred by clunky handoffs to other systems.

To achieve this business process nirvana, we have long advocated for the usage of Atlassian’s Jira, Jira Service Management, and Confluence products. Similar to Apple, Atlassian set out to develop products that work together seamlessly, but unlike Apple, Atlassian has retained that characteristic and further developed it to the point that these three products work together in harmony. The malleable and flexible nature of these products has helped them evolve from those used exclusively by software development teams for bug tracking to those used by IT, HR, Legal, Marketing, Customer Service, and several other business units. The ability of these products to merge these disparate units within a business shows an exciting step forward and potentially a culmination in Porter’s vision of a connected and integrated business.

In the next articles that will form part of this ESM blog series, we will further explore the logic and numbers behind enterprise service management, and why and how it can help your company. 

When designing Jira Service Desk implementation for your organization, there are tons of choices that need to be made. One important decision during this process is determining how to break down your service desk - Will you have one Service Desk for all of the teams working in the organization? Or will you build out multiple service desks and use the Help Center to route users to different Portals? 

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.

This decision will dictate both user and agent experiences working in the tool - so it's in everyone's best interest to consider as many factors as possible when making this decision.

But before we jump into the pros and cons, let's talk about the Help Center a bit.

What is the Jira Service Desk Help Center?

Jira Service Desk comes with the Help Center out of the box. The Help Center is an aggregated view of all of the Service Desks in that Jira instance. Customers are able to view the Help Center to search across multiple service desks and knowledge bases, see requests they've raised across all service desks, and much more. 

The Help Center may or may not make sense for your organization. Below are some things to consider when designing your organization's Jira Service Desk. 

Benefits of Using One Service Desk

Jira Service Desk comes with a ton of out of the box functionality that can help you group work in logical ways. 

• The customer can never go to the wrong place - the experience is simplified because there’s just one portal.

• Since all agents are working in the same place, there is clear visibility across teams, preventing silos. 

• Requests, queues and SLAs are customizable based on teams or org lines - making it easy to determine who needs to work on the request.

• All of your work is in one location, which means that finding issues in Jira is simplified.

• Although all agents are working out of the same project, you can use issue security to lock down sensitive requests. 

• JSD Reports are straightforward - because they are project specific, you can access them in one place to easily compare metrics. 

• As an admin, everyone is using the same schemes - which means less effort to set up and less overhead to maintain. 

Benefits of Using the Help Center

If you decide that breaking up the service desk makes sense - you're able to customize the underlying schemes in each project, so teams can have different workflows, issue types, issue security etc. 

• Schemes are customizable - so different teams can follow different workflows, permissions, etc. if needed. 

• Each service desk can have no more than 50 queues - so if you've got a lot of teams working on separate work, you'll likely run into this limitation (but run into a fairly confusing service desk first)

• Each service desk can have one set of customers who can see all of the requests - so the Help Center does the job if you need to restrict which requests customers can see.

• With the integration between JSD and Confluence, you have the ability to connect knowledge bases to your portal. Each service desk can have only one knowledge base, and the Help Center allows customers to search across them all to find the relevant articles, while also viewing only the relevant articles when viewing from a specific service desk. 

Designing your Service Desk Implementation

As you can see, there are quite a few things to think about here. Designing your service desk implementation may be an overwhelming idea, so a good starting place is to consider the end-users. Knowing what you know now, think about who will be using the service desk (agent and customer), and what would make sense to them. Are there agents who will be working in multiple service desks - how would they manage their work? Is it clear to a customer which project they should go to, or which request they need to use? For more information on customizing your help center, read this article from Atlassian. If you're in the research stage of your Jira Service Desk implementation, read Praecipio Consulting's advice on Accelerator vs. Custom Implementation. 

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.

While service desk agents do everything they can to avoid firefighting, they are often focused on extinguishing one fire and moving to the next. This usually causes tickets to smolder in some status of "not quite done" until months later when they will finally be closed out (thanks bulk edit!). The good news: there is a way to keep things moving using out-of-the-box functionality. No longer will your metrics be inaccurate because people aren't "moving their tickets through the system." Jira Service Desk can help do the moving for you with automation.

Putting out Smoldering tickets

Many workflows offer customers a chance to review the ticket before closing. But, replying to the work request isn't always the top priority of the customer, which in turn, leaves the ticket to smolder in an almost done state. Instead, Jira Service Desk can help you do a fully extinguish the request by doing a couple of things, messaging the customer on impending closure and auto closing the ticket with no response. Just follow these steps below.

Step 1: Create SLAs

While this may seem odd, SLAs can be used for more than just metrics, they are a great trigger for automations due to the extended functionality SLAs bring in Jira Service Desk. Start by creating two SLAs, call them Time in Resolved - Customer Notification and Time in Resolved. Set Time in Resolved - Customer Notification to the parameters shown in the screenshot below. Note, the SLA time can be changed depending on the amount of time you want to elapse before notifying the customer that their ticket will be closed. The SLA for Time in Resolved will have the same start and stop conditions, but put the goal time to be more than the goal of the notification trigger (for example, if the notification is set to send 120 hours after entering the status, than set the goal for the auto close to be 168 hours as this will give 48 hours for the customer to respond).

Step 2: Create Jira Service Desk Automations

Great, now that these SLAs are in place, let's use them to trigger Jira Service Desk Automations.  

Step 2a: Time in Resolved - Customer Notification

For this Automation, you will want to set the When to trigger off of the Time in Resolved - Customer Notification SLA when the SLA has been breached. Feel free to add an optional If statement should there be situations in which the SLA should not be executed. Lastly use the Public Comment option for the Then statement to send a message that the customer will receive. Included is a screenshot of this automation.

Step 2b: Auto Close Resolved Ticket

For this Automation, you will want to set the When to trigger off of the Time in Resolved SLA when the SLA has been breached. Feel free to add an optional If statement should there be situations in which the SLA should not be executed. Lastly use the Transition Issue option for the Then statement to move the issue to the final status. Note that it is best to use a hidden transition which does not require any fields or info as this is done through an automation. Included is a screenshot of this automation.

Step 3: Find other small fires to put out using automations

This is just one example of how automations can be used to keep customers engaged on the ticket and closing out issues that have been resolved. This same logic can be applied to many different areas in Jira Service Desk and can keep your front line firefighters focused on the hot spots and less time doing clean up!

If you still want to learn more about Jira Service Desk automations in action, join us for our next webinar on September 12, 11 a.m. CST: Automation with Jira Service Desk.

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.

Over the years, Praecipio Consulting has developed and implemented service desk solutions for a range of clients using Jira's powerful out-of-the-box capabilities and a few key add-ons; however, there was always something missing. When Jira Service Desk was first introduced, we were excited to see Atlassian embracing their customer (and partner) feedback. Over the few short years it has been in the market, Jira Service Desk has revolutionized the way teams serve their customers both internal and external. If you couldn't tell, we're in love with Jira Service Desk. Here are five things to make you fall in love with it too. 

Customer Portals make requesting help easy

Jira Service Desk provides customer-friendly portals to assist your customers in creating Requests. The portal can be configured to speak your customer's language while providing Agents pre-set information describing the customers' issues. Give your request types custom names and icons while mapping them to existing Jira issues. Add your company's branding, color schemes, and flair to personalize your Portals. These customizations look great and are a great way to automatically triage and resolve your customers' requests.

Approval tracking and visibility

Visibility is key when it comes to approvals. By assigning an Approver to an issue, Agents can see who needs to approve Requests at each step. Approvers will be listed on the Agent view as well as the Portal along with the details of what they're approving. Once the Request has been approved, this decision will be recorded with the ticket and can be referenced at any point during the lifecycle of the work. This helps everyone keep track of the official stamp of approval.

Handy Automation

Jira Service Desk has many out-of-the-box automations to trigger different steps in your workflows. Using automation to facilitate interaction between Customers and Agents stops support Requests from getting lost. Since a Request can almost always be 'Waiting on Customer' or 'Waiting on Support', you can use automation to transition between these two statuses when someone comments on the Request. When the ticket is 'Waiting on Support' and the support team asks a question in a comment, this Request can automatically move to 'Waiting on Customer'. Never worry about tickets being forgotten again! If you don't see what you need, create a custom automation rule using simple When, If, Else, Then logic to automate everything from a Notification to a Workflow Transition. 

SLAs that work for you

Service Level Agreements (SLAs) should help increase visibility into how a team can best work together, not something that adds pressure to situations outside of your control. Configure SLAs so that they are paused when a ticket is 'Waiting on Customer' or 'Blocked'. This lets you understand how your team is working while measuring performance in a fair, practical way. Using Jira Query Language (JQL), tune your SLAs to a specific Customer, Request type, even Priority or Severity to ensure your team meets or exceeds your Customer agreements. 

Confluence Knowledge-Base Integration

Integrate your Confluence knowledge base to help your customers fix their problems before they're submitted to the team. While a customer is typing in a request name, Confluence uses SmartGraph (tm) to suggest articles that relate to the request. The suggestions could be articles with similar words in the title or articles that other Customers have clicked on while submitting similar requests. Customers can self-serve and ultimately finish what might have gone through the entire support process. This saves the support team time and helps the customer get their problem fixed right away.

While there are many more reasons we love Jira Service Desk, these five things make us here at Praecipio Consulting fall in love with it even more every day. If you haven't experienced this for yourself, contact us for a demo or visit our collection of ITSM with Jira Service Desk Webinars here. We're more than happy to share the love.