Forums

Articles
Create
cancel
Showing results forΒ 
Search instead forΒ 
Did you mean:Β 

How have you shattered the service quo?

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

                   CCSD-26101 - 850 x 850 - badge 2.png

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. πŸ‘‡

3 comments

Tomislav Tobijas
Community Champion
June 30, 2026
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. πŸ”„οΈ
Like β€’ Tori Kaulins likes this
Marcell Bendik
Contributor
June 30, 2026

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.

Like β€’ Tori Kaulins likes this
John Funk
Community Champion
June 30, 2026

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!

 

Comment

Log in or Sign up to comment
TAGS
AUG Leaders

Atlassian Community Events