What your JSM data is telling you. Systemology Customer Briefing Series - October 2026
Most service desks report three things: ticket volume by month, SLA percentage by service project, and open backlog. Leadership asks different questions. Why does this incident keep happening? What did the last outage cost? Which fix gives the best return? The default Jira Service Management (JSM) reports were not designed to answer them.
Our October customer briefing worked through two patterns that sit in most JSM data and rarely appear in a monthly report. The figures below come from a 12 month demonstration dataset we built for the session (5,928 tickets, six services and 300 change requests), with both patterns deliberately included. Treat them as a worked example. Your own numbers will differ.
Fix two data gaps first
Both patterns depend on fields that are often left empty. The first is the affected services field on incidents. Without it, an incident can’t be matched to a change on the same service.
The second gap is the link between an incident and the change that caused it. JSM records change success when the change closes, so a change followed by three incidents is still reported as successful.
In the demonstration data, 453 of 1,728 incidents (26%) had no affected service. Our rule of thumb: if more than a quarter of your incidents have no service, fix the data before you analyse it.
A five step method
Each pattern follows the same sequence: question, query, correction, finding and action. Start with a question leadership has actually asked. Rovo writes the starting SQL or JQL from that question in plain English. An analyst checks and corrects the query, the finding is tested against what happens on the desk, and only then does it go into a process change, a problem record or a business case.
The correction step carries most of the risk. In our demonstration, Rovo’s first query ran without an error and returned nothing. It had looked for services in the Assets table and for the implementing team in the standard Team field, while the site recorded services in the JSM services registry and the team in a custom field. An empty result from a clean query is easy to misread as “no problem found”.
Pattern one: incidents that follow changes
The question: which incidents are raised against a service within 72 hours of a change to that same service?
A typical case looks like this. A Normal change to the finance ERP goes in on Tuesday evening and closes as successful. Month end posting fails on Wednesday morning, and nobody links the two.
With the query corrected, 109 of 228 Highest and High priority incidents (48%) followed a change to the same service within 72 hours. The 85 changes involved had all closed as successful. Changes by one team, Applications, preceded 70% of those incidents.
The actions need no additional licensing:
• An automation rule lists changes completed on the same service in the past 72 hours on every new Highest or High incident, so agents can link the cause at triage.
• A post implementation check stops Normal changes closing until the service owner confirms the service is healthy.
• A saved filter puts Applications changes that were followed by an incident in front of the change advisory board (CAB).
The finding converts directly into a business case. At an illustrative 4 hours of handling per incident and $95 per agent hour, those 109 incidents cost $41,420 a year in handling time alone. The fix takes about 48 hours of configuration, training and CAB review ($4,560), which pays back in roughly six weeks. Outage impact on the business sits on top of that figure.
Pattern one joins change and incident data in the Atlassian Data Lake, which requires Atlassian Analytics on the Enterprise plan. On Standard or Premium, linking incidents to changes at triage builds the same evidence from today onward.
Pattern two: an average that hides a breach
The demonstration desk met its resolution target on 91.9% of requests over 12 months. Sliced by request type, team and time of day, one combination stood apart: Request access handled by the Identity team after 3pm met its target 37.5% of the time (117 of 312 requests). Every other combination was above 95%.
This analysis works on Standard and Premium plans through the JSM Reports tab and Jira dashboards. Atlassian Analytics reduces it to a single query. If you build it as a custom report, check the date range: the “past year” view counts back from today, so its totals won’t match a 12 month figure from another source. The actions are to review staffing and routing for the late afternoon window, and to report resolution targets by request type and hour of day in the monthly service review. We’d go further: an SLA average should never be reported without that slicing.
Where the AI fits
Rovo did one job in both patterns. It turned a plain English question into starting SQL. People chose the question, corrected the query, checked the finding against how the desk actually operates and decided what to do about it.
Run the self check on your own site
We’ve packaged both data quality checks as JQL queries, together with the business case template used in the session. They run on any JSM plan and show whether your data can support this kind of analysis before you invest in it.
If you’d rather we ran it on your data, our JSM data health check is a fixed fee short engagement. It produces a data quality score for the fields analysis depends on, the top three patterns in your own data, and a draft business case for the fix with the highest return.
