Introduction
Incident response moves fast, and when information is scattered across tools and teams, even small delays can turn into really big problems.
Welcome to today’s SPK and Associates vlog entitled “How SPK Uses Atlassian Rovo to Accelerate Incident Response.”
Today, we’re going to take a look at how AI can help teams respond faster and smarter. I wish I had that back in my web hosting company days—to be able to respond to things quicker and smarter using AI.
But today, I’m joined by Annika, one of SPK and Associates’ Atlassian consultants.
Anakah, feel free to introduce yourself.
Annika’s Introduction
Hi, I’m Annika Hatcher. I’ve been working for SPK a little over three years now, with a primary focus in the Atlassian suite—specifically Jira and Confluence.
I’ve done all kinds of migrations, and I am in charge of administering our Jira site and Jira sites for other customers. I know all the ins and outs, and I’m really looking forward to talking about Rovo with Michael Roberts today.
Why This Conversation Matters
Anakah recently used Rovo to accelerate our own incident response here at SPK. She’s going to walk us through a little bit of what she did, what worked, and what teams may be able to learn from it.
So Anakah, first—before we implemented Rovo—what challenges were SPK’s engineers facing while managing things 24/7? In terms of Priority 1 and Priority 2 incidents, which we call P1s and P2s, what were they seeing?
Incident Response Before Rovo
I’m actually one of SPK’s engineers, so I can speak about this firsthand.
When a P1 or P2 comes in, the first thing you want to do is alert the stakeholders. The first step for that becomes finding out who the stakeholders are, so you have to go hunt that down.
Usually, Confluence—our knowledge base—is where we store all of our information about our clients and our issues.
After that, the next step is resolving the issue. Unless you’re some kind of tech wizard and you know everything, you have to go figure out how to resolve it.
Unless it’s something you’re super familiar with, you probably don’t know how to resolve it right away. I know I definitely don’t know how to resolve 99% of the tickets that come my way.
You have to go hunt that information down as well, typically in Confluence.
All of this adds up to precious minutes where you’re just looking for information. There are definitely a lot of issues, and not every issue is unique. You can get the same issues over time, so that becomes repetitive. You’re looking for the same information again and again.
We recognized that those minutes could be saved by implementing Rovo. As you mentioned earlier, even the tiniest delays can be crucial.
We implemented Rovo in the hopes of saving time and finding information for engineers so they don’t have to do that manual searching—especially when it’s the middle of the night.
At 2 a.m. or 3 a.m., you don’t want to manually look things up. Your brain is already half asleep.
The quicker you can hunt down the stakeholders and the steps to resolve the issue, it’s just a win for everybody. It’s a win for the customer because their issue gets resolved faster, and it’s a win for the engineer, who gets to go back to being productive—or back to sleep.
What Changed After Implementing Rovo
Can you give me a little more detail about what the Rovo agent does now when we get a P1 or P2 ticket? What did you implement, and how does Rovo help eliminate that extra manual time?
The key word here is manual labor. That’s where Rovo steps in. It does the busy work—finding the information for you so that you don’t have to go looking for it.
As an engineer, whenever I would get a P1, it could be really frustrating trying to find the information—not just in Confluence, but across multiple places.
I would check Confluence articles about specific alerts, which are usually the most helpful. If I couldn’t find anything there, I would turn to Jira to look for previous tickets. Sometimes I’d even check Slack for messages in our P1 channel.
With Rovo, we started with the most basic implementation. We have it check Confluence for relevant pages and documents related to the specific alert.
When the alert comes in, it takes the summary and the description of the issue and searches Confluence for keywords.
If it finds a relevant document, and that document includes stakeholders, it automatically fills in the email stakeholders field on the issue.
It also adds a comment with the steps to resolution that it finds. That’s one less manual step an engineer has to do.
I honestly wish I had this about 15 years ago. It would have saved me a lot of time across all the tickets I worked on. This has been extremely helpful.
Client Perspective and Business Impact
I want to flip the perspective a bit. You’ve explained the value for SPK engineers working on the help desk, but from a client perspective—if a P1 or P2 alert impacts parts of their infrastructure, systems, or solutions—how does this improve their experience with SPK’s 24×7 monitoring for managed services?
We’re often the first line of response when something goes wrong. If a server goes down, customers need people to step in and resolve that.
As we’ve mentioned a few times, small delays during downtime can add up to big consequences. Every minute matters.
The minutes that Rovo saves by stepping in and doing the manual work can make a difference—sometimes a big difference, sometimes a small one—but that difference matters.
It affects how fast we respond to customers and how quickly we bring their server back online, or resolve whatever issue is happening.
Reducing downtime can result in financial savings and improved productivity. End users aren’t blocked for as long, and they can resume their work sooner.
There’s always a financial impact one way or another—whether that’s internal costs or actual customer revenue—when systems are down.
Benefits for Atlassian Service Desk Teams
Last question for you, Anakah. From an Atlassian customer perspective, how does this technology—Rovo—enable better ways of working, especially for service desks or incident management during Priority 1 or Priority 2 outages?
From an engineer’s perspective, there’s less manual busy work. You can focus on the more complex work that actually needs your attention.
Work is faster. People are more productive because they’re spending less time on repetitive tasks.
From a service desk perspective, this results in faster response times. Customers are more satisfied with those faster responses.
More work gets done, and more tickets are resolved faster. It’s really a win for everybody on both sides.
Rovo is a big helper when it comes to reducing manual effort—especially when data is spread across multiple systems.
That information might be in Confluence, Google Drive, or a Slack thread. Rovo helps bring it together.
It also results in more reliable and consistent information. Different engineers might otherwise find different information and pass it along differently to customers.
If Rovo is providing that information instead, it’s more consistent and likely more reliable.
Closing
Annika, thank you for sharing a real-world, practical example of how Rovo can actually make a difference—especially when it matters most, possibly at three in the morning.
What I really love about this story is that it’s not theoretical. It’s AI being used directly in a workflow to help teams find information faster, reduce friction, and give customers more confidence that issues can be resolved quickly—with a clear understanding of the financial impact.
If you’re thinking about using tools like Rovo to support your own incident management or incident response workflows, SPK’s team is happy to help.
Please reach out to us.
Thanks for watching, and we’ll see you in the next video.
