How have you shattered the service quo?

[#1]

Hey Community! 👋

Welcome to Week 2 of Shatter the Service Quo: Break Stuff, Earn Badges! This week, we're putting the spotlight on legacy processes that were begging to be broken.

⭐ The challenge

Name one legacy service process you've already shattered — or one you'd shatter tomorrow if you could.

Share a short story in the comments below telling us:

1. What the old process looked like – the pain, the friction, the "why are we still doing this?"

2. What you changed – the tool, the workflow, the shift in thinking

3. The impact it made – time saved, team sanity restored, customers unblocked

Drop your story and you'll unlock:

• 🏆 Service Trailblazer badge

• 💰 150 Kudos points

                   

Share your story below and take a scroll through the comments to see how others have broken free from the service quo. You might just find your next improvement project. 👇

[Tomislav Tobijas]

It’s not directly related to JSM, but we’re currently working on removing friction between our Sales/Presales and implementation teams. There has been quite a bit of miscommunication around who is responsible for what, so the goal is to make those responsibilities much clearer.

We’re designing a sustainable but relatively simple workflow that gives both sides visibility into what the other is doing.

Even with just the initial design and a few process standardisations, people are already much more aligned on ownership and responsibilities. The next phase will likely focus on the transition from implementation to hypercare and support - clearly defining when one phase ends, when the next begins, documenting that handover, and supporting it through the workflows in our tools. 🔄️

[Marcell Bendik]

It is interesting to step back sometimes and answer such questions. As a process expert / JIRA admin shattering can be taken "literally" and you might focus on radical updates where impact is huge and clear. However, when you speak with your users, with business, you realize they might prioritize and enjoy smaller changes that improves their life without the "shatter".

Our previous ticketing tool wasn't supporting much automation. So our change focused on automation:

• once a change request is ready for implementation it has to be announced in a channel so everybody is aware of it (even those who are not using the ticketing tool)
• Again, when the implementation finished, one more announcement
• The automation is supported with Asset, so multiple channels are supported (for different business units or for test purposes) and the solution can be easily updated without touching the workflow.

Automating this task seems like a tiny improvement. When you have thousands of changes, it clearly has an visible impact. There are many outcomes, not just saving resources:

• the change ticket makes more sense and the fields filled previously now get used (to create the announcement). The status changes makes sense as it triggers the communication. Using the ticketing tool is meaningful, so users don't try to avoid it
• As all these activities are automated, the agent can fully focus on the implementation. This improves quality
• Announcement are identical, never missing information, there are no typos, no difference from the actual change requests. This improves quality and trust

As I received feedback from our agents I realized the full impact of these updates! These updates wasn't shattering the solution in the tool, it was "shattering" the user experience and how they use it - in a good sense.

[John Funk]

Legacy processes and team functions are often siloed in their implementation. Our organization was no different in that regard than many. Different teams using different tools with isolated data resulting in duplicate entry of the same data in multiple places. This has been overcome by bringing multiple teams into both Jira and JSM. Now work flows through a process that might begin with one team and then get reassigned to another team in a subsequent step, and then a third team on down the line and so on. One process, multiple teams, smooth flow and lots of productivity gains have been the result!

[Sam Okell]

We've previously had 'pain' in maintaining access for users across the Atlassian estate. We are an organisation of approx. 1,600 accounts and so making sure the right people have access to the right thing at all times is a very difficult task, if kept manual.

Where we have changed things is with a concept of automation user groups, fed from our Assets data.

Within Assets we track many details about our staff, and so using this data we can 'bucket' people to groups and apply all of those users to a specific user group, and this can be as granular as we need it do be.

We have buckets containing IT staff, or HR staff, or everyone from a specific office, and this also stretches to the same maintenance for any 3rd party suppliers that have access to our Atlassian estate.

Some heavy automation keeps these groups 'correct' at all times. People leave the company and they are removed from their groups, people join the company and automatically get an account and it's already added to the correct groups, even people moving between teams will have their groups reviewed by the automation and reset if incorrect. It also cleanses any 'misbehaviour', so if someone adds a user to a group that they don't naturally belong to (a Finance user in the IT group) then it'll also fix itself.

This has made access management a thing of the past as these groups are utilised within Permission Schemes, ensuring that everything is structured and simple for end users, with the heavy lifting  done by the system!

[Keiran]

One process I'd happily leave in the past is the "send an email to support and wait" model.

The old process was frustrating for everyone involved. Users would email a shared inbox, support staff would manually sort requests, and important details were often missing. The first response was usually a request for more information, which added another delay before anyone could actually start working on the issue.

We replaced that approach with structured service requests and automated routing. Requests now go directly to the right team with the information needed to take action immediately.

The biggest impact wasn't just faster resolution times. It was eliminating all the back-and-forth. Users spend less time explaining their problem, and support staff spend more time solving it.

[Brita Moorus]

One legacy process I'd happily shatter is manual Atlassian access management.

The old way was: request comes in, admin checks the right groups, adds access manually, and hopefully remembers to clean it up later. Moving toward automated user/group management makes a huge difference:

• faster onboarding

• fewer manual admin tasks

• cleaner permissions

• less forgotten access

Users just want the right access at the right time. If the system can handle that quietly in the background, that’s a service quo worth breaking 🚀