Silent killers of JSM - what are yours?

[#1]

Hey fellow Jira admins 👋

We’ve reviewed and rebuilt dozens of Jira instances over the years - across industries, company sizes, and use cases.

And no matter the setup, the same problems keep showing up.
Not the loud, obvious ones.

The silent killers—the ones that sneak in slowly and quietly chip away at performance, usability, and team trust in the system.

Here’s our list of 7 silent Jira killers that tend to creep into every admin’s environment over time:

❌ 1. Frankenstein Projects

Multiple teams squeezed into one project "for simplicity."
👉 Creates a nightmare of overlapping fields, workflows, SLAs, and automations. One small change = system-wide risk.

❌ 2. Wasted JSM Features

You’re paying for JSM—but key features like Change, Incident, or Problem management are turned off or unused.
👉 Your teams are working harder than they need to, and you're not getting the value out of the license.

❌ 3. Automation Spaghetti

80+ rules, half of them duplicated or outdated.
👉 No naming conventions, no ownership, lots of silent failures. Nobody wants to touch it.

❌ 4. Portal Overload

30+ request types. Duplicate forms. Vague labels.
👉 Users click the wrong thing, or skip the portal entirely. Support teams clean up the mess.

❌ 5. Email Overload

The portal exists, but everyone still emails.
👉 Agents waste time chasing details. Data quality drops. Reporting becomes a guessing game.

❌ 6. No CSAT

You’re not collecting feedback at all—or you’ve set it and forgotten it.
👉 You lose visibility into what’s working, what’s not, and how users actually feel.

❌ 7. No Virtual Agent

Knowledge base? Automated responses? Self-service?
👉 Left on the shelf. Agents spend time answering requests that could’ve resolved themselves.

Why This Matters (from an admin view):

• Makes future config changes riskier

• Slows onboarding

• Wrecks trust in Jira over time

• Kills performance reporting

• Makes scaling almost impossible

Drop a comment if you would add something to out list!

Best,

Celina

[Rosana Casilli]

@Celina !!! thanks for the tips.

I tried to access to the file but couldn't do it. I completed the data asked in the web page got the confirmation email but still I can't access to any resource. 

[Celina]

@Rosana Casilli that's odd - everything working on my end! Please type here your email and I will send it to you directly! :) 

[Julian Beyer]

Thanks for mentioning the Automation Spaghetti, gave me the push to set up a recurring audit 🤓

[Josh]

@Celina great article.

Here are some:

1. Team-Managed Projects (for so many reasons)
2. The opposite of Frankenstein projects - every small team creating unique projects and schemes when they could share projects and schemes with others
3. Portal Overload Part 2 - Vague KB article names that make it difficult for people to find relevant content

[Celina]

@Josh Team-managed - yes! So hated by admins 😆

[Erick Miranda Márquez]

Hi @Celina , great article,

I want to add another silent killer, the creation of custom fields without sense.

We need to search the custom fields to see if any can be reused. We also have the option to rename a custom field from the portal if we need a better description for the customer.

But we need to avoid creating custom fields without control.

[Rosana Casilli]

hI @Celina  

[Personal information removed as it is against  community guidelines ]

[Solomon Ecuyer]

Love this! 

[Hua Soon SIM _Akeles_]

This is a useful post that I want to share with my team mates!

However, there is a point about CSAT that I want to add on based on our experiences with Bulk Approvals for JSM.

There are some scenarios which CSAT may not applicable.
Service requests which are

• processed automatically without agent assistance
• raised for bulk approvals
• raised on a regular basis

The users are most likely to ignore the request for feedback.