Most service management reporting looks impressive right up until someone asks a simple question: So what should we do differently?
If the answer is “nothing, but here’s a chart of ticket volumes,” then it isn’t reporting.
That’s the trap a lot of organisations fall into. They build dashboards full of open counts, SLA percentages, first-response times, and work type splits, then wonder why leaders still can’t see where services are struggling, where teams are overloaded, or where customers are losing patience.
The problem is not that there is no data. The problem is that most reporting is built around the workflow tool, not the service. It measures what moved through the system, not whether the service delivered value.
Bad reporting does not stay in the reporting layer, it shapes behaviour. Teams optimise for what is easiest to count. Managers defend what makes their area look green. Executives get a sense of control without any real line of sight to demand, risk, or experience.
📊 The dashboard is not the truth
A dashboard can only tell the truth about the model behind it.
If your categories are inconsistent, your services undefined, your ownership fuzzy, and your queues shaped around team boundaries instead of value streams, your reporting will faithfully reflect all that confusion back to you in full colour.
This is why reporting often feels mature long before it actually is. The charts are polished. The data refreshes automatically. There are trend lines. There are filters. There might even be an executive summary. But underneath it, the structure is still weak.
And weak structure produces misleading conclusions:
- A spike in tickets may look like service deterioration when it is really better adoption of a self-service channel.
- A fast first response may look impressive while resolution still drifts across multiple handoffs.
- A high-resolution rate may look positive while repeat contacts are quietly climbing.
The report is not lying. It is telling the story it was designed to tell.
🗂️ Report, dashboard, analytics: they are not the same thing
These three terms get used interchangeably, and that causes real problems when organisations try to improve their reporting layer.
- A report is a structured answer to a specific question, usually produced on a schedule. It is backward-looking by design. Its job is to describe what happened, how reliably, and against what standard. A monthly SLA summary is a report. A ticket volume breakdown by service is a report. Reports are most useful when the question is fixed and the audience needs consistency over time.
- A dashboard is a live or near-live view designed for monitoring and action. It surfaces current state so that someone, an agent, a manager, or a team lead, can respond. A dashboard should answer the question: what do I need to pay attention to right now? It is less about history and more about awareness. A queue backlog view is a dashboard. An open P1 incident count is a dashboard. Dashboards work best when they are narrow, role-specific, and built around operational decisions.
- Analytics is exploratory. It is used when you do not yet know the right question, or when you need to find patterns, test hypotheses, or understand why something is happening rather than simply that it is happening. Analytics is not something you build once and publish. It is an investigation capability. Atlassian Analytics, for example, lets you cross-query data across Jira projects, services, and teams to find relationships that would never appear in a standard report or dashboard.
Most organisations have too many dashboards pretending to be analytics, and too many reports that were built to answer questions no one is asking anymore.
The practical test:
Tool | Right question | Atlassian Stack Example |
|---|
Report | What happened last month against our commitments? | SLA met vs breached report |
|---|
Dashboard | What needs my attention right now? | Dashboard gadget, such as Filter Results or Workload |
|---|
Analytics | Why is demand growing in this service? | Custom cross-domain workbook using Atlassian Data Lake and AI insights to join services, change events, operations alerts and Jira releases. |
|---|
🧭 Report on demand before you report on effort
Most service management reports start too late in the story.
They begin once a ticket exists, which means they are already measuring internal effort rather than the customer need that created it. That is useful, but incomplete.
💡 Key Takeaway: A ticket is just the administrative container we use to track work, not the demand itself. Demand is the underlying customer need or friction. When reports only measure tickets, they miss deflected demand, portal abandonments, side-channel messages, and the systemic failures that generated the ticket in the first place.
Leaders need to understand demand first:
- What are people actually asking for?
- Which services generate the most avoidable demand?
- Which requests are predictable and healthy, and which incidents signal friction, failure, or poor design?
- Where is demand growing because the business is changing, and where is it growing because the service is weak?
In Jira Service Management, capturing these demand types starts with intent-based service modeling: structuring business services with offerings surfaced via your catalogue, tracking knowledge base and virtual agent deflection, monitoring reopen rates, and using failure-cause fields to flag rework.
Without that lens, reporting collapses planned consumption, avoidable failure, and operational noise into the same bucket. Everything becomes work, which makes prioritisation much harder than it should be.
A mature reporting view separates at least three things:
- Value demand: work people should be coming to you for
- Failure demand: work created because something did not work properly the first time
- Noise: duplicates, misroutes, churn, and administrative handling that add volume without adding value
Once you can see those clearly, the conversation changes. You stop asking why ticket counts are high and start asking why the service is creating so much rework.
🔬 Four layers of reporting that actually help
Useful reporting is not one dashboard. It is a stack. Demand comes first, but it is only the first layer. Each layer answers a different question, and together they give leaders a reason to act.
Layer | What it tells you | Typical measures | Why it matters |
|---|
Demand | What is coming into the service and why | Volume by service, demand type, request mix, avoidable contact rate | Turns the demand definitions above into a measurable view for service design and prioritisation |
|---|
Flow | How work moves once it enters the system | Ageing, wait time, handoffs, backlog, throughput, reopen rate | Exposes bottlenecks, queues, and structural delays that SLA reports often hide |
|---|
Performance | How reliably the service delivers its intended outcome | Time to fulfil, restoration time, P85/P95 resolution times, completion predictability, breach patterns, risk indicators | Connects operational delivery to service reliability rather than agent busyness |
|---|
Experience | How the service felt to customers and staff | CSAT, sentiment themes, effort score (CES), complaints, qualitative feedback | Prevents "green but hated" services from being mistaken for successful ones |
|---|
Experience reporting should not treat CSAT as a standalone XLA. CSAT tells you how someone felt at a point in time; an XLA becomes useful when that sentiment is connected to the operational evidence behind it, such as wait states, handoffs, reopen rates, resolution predictability, and effort.
That combination shows whether poor experience is a perception problem, a communication problem, or a structural service problem that needs redesign.
👉 Stay tuned for Dave’s upcoming article on Experience Level Agreements (XLAs), coming soon to the CSX Masters series.
Most organisations overinvest in performance slices and underinvest in demand and flow. If these four layers represent what we ought to measure, why do so many teams get stuck relying solely on performance metrics?
Because their underlying service model is fragmented.
🧱 Good reporting depends on a defined service model
Service design is the discipline that defines what a service is, who it serves, what outcomes it exists to deliver, and how it should be structured. Done well, it creates a repeatable service model rather than a loose collection of request types, queues, and team-owned workflows.
The service model is the output of that design. It gives reporting a stable unit of analysis: business portfolios, services, service offerings, owners, dependencies, and configuration items. Without that model, reporting falls back to whatever the tool can most easily count.
In Jira Service Management, this means the service model should not be reduced to a flat list of request types or disconnected queues. Leveraging Assets to structure a business portfolio, spanning business services and specific service offerings, connected to underlying technical services and CIs, gives reporting the structure it needs. It allows you to connect incoming demand directly to service ownership, cost, impacted assets, and business outcomes.
The operating model then determines how the organisation delivers against that service model: team structures, roles, accountabilities, handoffs, governance, and escalation paths. Flow is what you observe when that operating model meets real demand. If work stalls, bounces, or disappears between teams, reporting is usually exposing an operating model problem, not just a workflow problem.
If you cannot report clearly on a service, one of these is probably true:
- The service or offering is not defined in the business portfolio
- Ownership and accountability are unclear
- Demand types (value vs. failure) are mixed together
- Workflow stages reflect internal team handoffs rather than how value is delivered
- The team structure is masking the customer journey
In other words, reporting problems are often modelling problems with better formatting.
"The most useful dashboard in service management is often the one that embarrasses the design enough to force a redesign."
🛠️ Start redesigning reporting from decisions, not metrics
The easiest way to improve reporting is not to ask, What should we measure? Ask, What decisions should this help us make?
Decision we need to make | Reporting needed | What bad reporting usually does instead |
|---|
Where should we invest improvement effort? | Demand trends, repeat contacts, service pain points, customer themes | Shows total ticket count by month |
|---|
Where is work getting stuck? | Ageing, handoffs, wait states, backlog by service stage | Shows overall average resolution time |
|---|
Which services are under strain? | Volume against capacity, backlog growth, volatility, breach patterns | Shows number of tickets each team closed |
|---|
Are we delivering value consistently? | Outcome measures by service, fulfilment predictability, restoration trends, experience signals | Shows one blended SLA across unrelated work |
|---|
Why averages fail customer experience
This is where many dashboards go wrong with averages. They smooth out extremes, hide variation, and comfort people who should probably be more concerned.
Averages make ugly systems look tidy. If one customer waits ten days and another waits ten minutes, the blended average may look respectable, but the actual customer experience is completely broken. Reporting must capture percentiles (such as P85 or P95) and tail latency rather than relying on smoothed averages.
🌐 Reporting beyond IT is where the model gets tested
Reporting gets even more revealing when service management expands beyond IT.
In IT, people are used to tickets, SLAs, and operational dashboards. In HR, Finance, Procurement, or Facilities, the weakness of ticket-shaped reporting becomes obvious much faster because leaders there usually care less about workflow statistics and more about service outcomes.
They want to know things like:
- How long does it really take to get a new starter productive?
- Where are approvals slowing down procurement?
- Which employee services generate the most avoidable follow-up?
- Which facilities issues are recurring by site and affecting staff experience?
Those are service questions, not ticket questions.
That is why reporting can become one of the strongest forces pushing an organisation from ITSM habits into actual enterprise service management. The moment other business functions ask for meaningful visibility, the limits of queue-centric reporting become impossible to ignore.
📍 A practical sequence that works
If your current reporting is noisy, political, or performative, do not start by rebuilding the dashboard library. Start by tightening the service model underneath it.
- Define the service clearly enough that a leader can recognise what it exists to do.
- Separate value demand from failure demand wherever possible.
- Map the main flow of work, including waits and handoffs.
- Identify the exact decisions each audience needs the reporting to support.
- Remove vanity measures that create motion without insight.
- Add customer and employee feedback as evidence, not decoration.
- Review reporting at service level first, then team level second.
That sequence matters. If you start with visualisation, you usually end up polishing confusion.
A good service report should help three audiences at once: leaders decide, managers improve, and teams act. If it only satisfies one of those groups, it is probably incomplete.
😬 Stop describing. Start deciding.
A lot of reporting exists for reassurance, not learning.
It helps organisations feel managed. It gives governance meetings something to review. It creates the appearance of discipline. But appearance is not the same as control, and charts are not the same as understanding.
Real reporting is more demanding than that. It forces you to define the service properly. It exposes weak ownership. It reveals rework, failure demand, inconsistent triage, and delays that people have learned to live with.
That is why bad reporting survives for so long. It is easier to maintain a dashboard than to confront the operating reality underneath it.
But if your reports cannot tell you where value is being created, where friction is growing, and what should change next, then they are not informing management.
They are just documenting motion.
📚 Further reading
This is my third contribution to the CSX Masters “Beyond ITSM” series:
🧚♀️✨ About the author
Chrissy Clements is an Atlassian Community Champion and ITIL Master & Ambassador. She also helps organise the Brisbane ACE.
In her day job, she brings 💫 service management sparkles 💫 to Global Alliance Partner, Accenture.
