Incidents happen and there isn’t anything we can do about that, short of never allowing change to occur. Obviously, that’s not realistic if you want to stay competitive. Under normal circumstances, your teams can flex and bend when significant incidents occur. However, these are not normal circumstances and your Incident Management practice has to be robust and resilient to manage the influx of requests for new and more types of access, new and more reports, new and more types of issues. Helping you ride this wave of acceleration are a pair of familiar concepts that will shift work to the left and off-load some of the pain to all levels of your organization: automation and communication.
Accelerate with Automation
A Service Desk can find itself spending a lot of time chasing and clarifying information. This is even more difficult when the teams are remote, whether that’s your business-as-usual model or not. Often when we think of “shift left” we think of pushing responsibility to the end-user making the request. But, what about also shifting left to the tools we use? Right out of the box, Jira Service Desk Automation can do some of this important work:
- Add an easy-to-understand list of components to the Requests in your Customer Portal and ask the end-user to select.
- If end users continually request the wrong thing, consider changing the name of the request to be more intuitive and then set the Summary by hiding the Summary field and defining how it needs to be set. Consistency is key to making automation work for you.
- Ensure that your Confluence Knowledge Base is connected to Jira Service Desk and that articles are labeled logically. Then, restrict some Request Types to specific Confluence articles using Labels. Request Types for password resets should see articles that are related to password resetting, and not to the articles that just happen to contain the keyword “password” – and there are probably plenty of those.
- Transition issues from Waiting for Customer to Waiting for Agent when a Customer comments a request.
- Set up a Waiting for Customer Comment SLA and then have JSD Automation close issues when Customers have not responded within the time.
Automation for Jira, now part of the Atlassian suite of products, can supercharge your service desk projects by picking up the next tier of requirements, from balanced workload assignments to linking issues mentioned in comments to linking issues raised by the same reporter and more.
To level up your automation, prioritize and categorize your services in your CMDB. Then, include custom fields for those CMDB services in your Customer Portal, and let your customer identify the service they are having difficulty using. Several additional fields could populate themselves – all before it lands with the Service Desk. Insight by Mindville custom fields are built using the relationship of the objects in your CMDB and half that battle is already met. Elements Connect can help you achieve the same objective if you use an external CMDB.
Go a step further and create custom operations using Elements Copy & Sync to create linked Incidents, Problems, and Changes on the fly using data from the ticket staring you in the face right now – and it keeps them synchronized the way you want.
Accelerate your Communication
A major incident is defined as an event that causes a disruption to, or a reduction in the quality of, a service and which requires an emergency response. Incident Management consists of four standard areas of focus: identity & communication, investigate & diagnose, resolution & recovery, and closure.
Most IT organizations are good at “Identify”, “Investigate & Diagnose” and “Resolve & Recover”. Communication is a pain point for both technical teams and stakeholders for different reasons. Many organizations never get to Closure because they are already fighting the next fire.
Jira Service Desk is known for an abundance of communication, and some would say an over-abundance of communication. Notifications for updates to tickets. Notifications for status changes. Notifications on assignments and reassignments. Notifications for organizations added, participants added, and resolutions. There are notifications for all-all-all the comments added (and edited) to a ticket. It is dizzying, the amount of notifications which are sent. Add to that the sheer volume of non-Jira email (you know: all that business-as-usual stuff, marketing, spam, your teammate’s sister’s nephew’s dog-on-a-skateboard alert) and it’s difficult to see the forest for the trees. Is it any wonder clients and end-users complain that they “didn’t see any email about a problem with that system!”
Statuspage makes a very big dent in your shift-left requirements by allowing clients and stakeholders the opportunity to self-subscribe to major incident notifications and manage how they want to be notified. SMS? Yes, thank you. Email? Yep. Twitter? You bet. Service status is communicated using the four standard categories: Investigating, Identified, Monitoring, Resolved.
In Bill’s scenario (from our previous blog post, y’all) a major piece of the cabling distribution chain stopped dead. He directed the Service Desk to send notifications to the relevant business teams.
- What they did: the Service Desk went to Confluence to look up the key stakeholder’s list for the delivery scheduling services, and then searched for the email template for the first notifications in Sharepoint. A new email was created, the email template wording was added to the body of the email, and passed to the Service Desk Manager for approval, followed by a Slack chat between the Service Desk team member and the Service Desk Manager to tweak the wording, and then the final email was sent. Fifteen minutes later, the Head of Business Delivery shoots an email to the Service Desk Manager to ask why he hasn’t received an email but his Deputy Head of Business Delivery did. Unfortunately, the stakeholder list in Confluence had not been updated with the new Head of Business Delivery, who had been on-boarded last month.If you have Jira Service Desk and you are reading this, then you have already come up with a half-dozen better ways this could have been done. But: do you have Statuspage?
- What they could have done by using Statuspage: A Service Desk team member browsed to the organization Statuspage.io space and created an Incident with status and applied a templated message regarding the scheduling services. The template contained a status message and the components affected were automatically ticked, as the operational level of the components. The Service Desk is confident that the right key stakeholders will be notified and clicks the Create button.
Why is the team so confident? Because they have actively introduced clients and stakeholders to their Statuspage space and showed them the list of services they can subscribe to. Stakeholders were shown how to subscribe to specific “components” of the service, including a “Test” service to demonstrate the kind of notification they would receive, be it SMS, Email, or Twitter. Communication is so important that the team also implemented practices for adding subscribers during on-boarding processes for new clients, key contacts, and stakeholders.
But we hear you thinking “gosh, my stakeholders are not going to want to go to yet another place to get a status – can’t we just show this in the Customer Portal?” The free Statuspage for Jira Service Desk app hooks into your Statuspage.io space and surfaces the latest update to your portal and offers a link to Statuspage. Yes, we can.
Accelerate Your Closure
Putting closure on your incidents involves research into what happened, when various actions occurred, who did what and why…in short, documentation. Who wouldn’t like some automation around this? You probably already knew Elements Copy & Sync can create Confluence pages. Did you also know that it’s not just basic blank white pages but well-formatted, templated pages can be created which include Confluence macros and details from the Incident record you are creating from? Voila, half the work of post-incident review is done and you can spend that time doing the major incident analysis.
Conclusion
It’s can be easy to disregard improvements when the shape of the world starts changing as quickly as it is. Accelerating your Jira Service Desk is critical to handle the rising volume of incidents and service requests. Automating and shifting-left, taking advantage of current tools and bringing new ones on-board, gives your team the breathing space to focus on responding and resolving. Give your stakeholders the confidence that your teams can tackle the evolving landscape, and you’ll be ready for what lies ahead.
Contact us
