Analytics
Analytics are available for each request type in the service catalog, providing key insights into catalog performance and portal usability. By identifying outdated or complex request types, you can optimize the catalog for a smoother user experience. Data-driven insights help drive continuous improvement, manage costs, and align services better, ultimately improving customer satisfaction and saving resources.
When the app is launched on a JSM project, analytics are generated for each request type based on data from the past three years.
Analytics are updated every Monday at 1:00 am (based on your Jira instance’s time zone). For the most accurate results, we recommend checking the metrics on Mondays.
The following metrics are calculated based on data from the current week:
Last request raised on
Total Requests
Total Cost
Cost per Ticket
Cost per Ticket evolution
Total Revenues
By default, analytics data from the previous week up to the current day are displayed. You can filter for more historical data using the controls on the top right.
Selecting specific days will automatically adjust the data to the relevant Monday of that week.
SCREENSHOT
Metrics Classification
The metrics are classified based on key service catalog management themes to help you focus on what matters most. These include:
Relevance – Measures if request types are still in use and meet user demand.
Accuracy – Focuses on the correctness of service categorization and request classifications.
Cost Effectiveness – Tracks service-related costs to ensure spending aligns with budget goals.
Efficiency – Evaluates how well the service request process is working, including agent and user efficiency.
Consistency – Ensures standardized, repeatable processes and uniform service delivery.
Currency – Keeps track of real-time data, providing up-to-date insights into service catalog performance.
Each metric helps optimize different aspects of your service catalog, allowing you to enhance overall efficiency, accuracy, and alignment with user needs.
Metrics explained
Last Request raised on
RELEVANCE CURRENCY
Based on live data, this metric isn’t impacted by Filters
This metric displays the date of the latest request which was created for the current request type.
This helps you assess the relevance of the request type, by checking if it has been used recently or not.
Total Requests
RELEVANCE EFFICIENCY
Calculated based on data from the current week
This metrics displays the number of request which were created for the current request type for the specific period.
This helps you assess the popularity of the request type, by checking the volume of requests raised in the define period.
Top Requesters (Organizations)
CONSISTENCY EFFICIENCY
Calculated based on data from the previous week
The Top Requesters metric provides insights into which organizations are making the most service requests for each request type of the catalog. This helps service owners understand demand patterns, optimize resource allocation, and ensure the right support is provided to high-usage teams.
How it’s calculated
The metric aggregates service requests over a defined period.
Requests are grouped by the organization of the requester.
Organizations are ranked based on the total number of requests submitted.
Only the top 10 Organizations are displayed by default. If this limit isn’t adequate for your use case, please let us know.
Total Cost
COST EFFECTIVENESS CONSISTENCY
Calculated based on data from the current week
The Total Cost metric provides visibility into the overall expense of each request type within the catalog. It helps service owners and financial teams track IT spending, optimize budget allocation, and ensure cost efficiency.
Currently, service owners are responsible for manually defining the cost per service based on their own data sources. However, future enhancements in the product will assist service owners in determining appropriate service costs based on data insights, making cost estimation more accurate and data-driven.
How it’s calculated
The cost of each request type is manually entered by service owners based on external data (e.g., operational expenses, vendor pricing, or internal cost structures).
The calculation considers the cost per service multiplied by the number of times the service was requested over a defined period.
Cost per Ticket (CPC)
COST EFFECTIVENESS EFFICIENCY
Calculated based on data from the current week
The Cost per Ticket metric provides insights into the average expense associated with each service request over a defined period. It helps service owners evaluate the efficiency and cost-effectiveness of service delivery, supporting better financial planning and resource allocation.
How it’s calculated
The Total Cost of all service requests within a defined period is calculated.
This total is then divided by the total number of tickets (service requests) in the same period.
Cost per Ticket Evolution
COST EFFECTIVENESS CURRENCY
Calculated based on data from the current week
This metric shows how the Cost per Ticket metric evolves over time.
Difference Between Total Cost and Cost per Ticket
Both Total Cost and Cost per Ticket are key financial metrics in service catalog management, but they serve different purposes and provide different insights.
1. Total Cost – Understanding Overall IT Service Expenses
✅ Helps IT and finance teams track the total spending on IT services.
✅ Identifies high-cost services, enabling cost-saving strategies.
✅ Supports budget planning and forecasting by showing how much is spent on service requests over time.
✅ Useful for chargeback/showback models to allocate costs to different departments.
2. Cost per Ticket – Evaluating Service Efficiency
✅ Provides a benchmark for service efficiency, helping teams optimize service delivery.
✅ Highlights cost trends per request, helping organizations identify whether service costs are reasonable.
✅ Helps compare costs across different services to prioritize process improvements and automation.
✅ Assists in identifying expensive services that may require cost optimization or alternative solutions.
In summary:
Total Cost is useful for understanding the big picture of IT service expenses.
Cost per Ticket helps assess the cost-effectiveness of handling individual requests.
Total Revenues
COST EFFECTIVENESS CURRENCY
Calculated based on data from the current week
The Total Revenues metric provides visibility into the overall revenue generated from service requests.
It helps with:
✅ Revenue Tracking – Helps service owners and finance teams understand how much revenue is generated from IT services.
✅ Profitability Analysis – When combined with Total Cost, it helps assess whether a service is profitable or operating at a loss.
✅ Pricing Strategy Optimization – Enables service owners to fine-tune price per ticket based on service demand and costs.
✅ Budgeting & Forecasting – Supports financial planning by identifying trends in service revenue over time.
✅ Chargeback & Showback Support – Useful for organizations that internally bill departments based on IT service consumption.
By maintaining accurate price per ticket values and monitoring Total Revenues, organizations can optimize pricing, improve financial planning, and ensure sustainable service delivery.
How it’s calculated
The price per ticket is manually entered by service owners based on external factors such as market rates, internal pricing strategies, or cost-plus models.
The total revenue is calculated by multiplying the price per ticket by the number of times the service was requested over a defined period.
Requests recategorized by Agents
ACCURACY EFFICIENCY
Calculated based on data from the previous week
This metric tracks the number of service requests where a service desk agent modified request form fields after submission.
It provides insights into the accuracy of initial request classifications and the efficiency of service categorization within the catalog.
Frequent recategorizations may indicate that users struggle to select the correct service or category, leading to additional workload for agents. By analyzing this metric, service owners can identify opportunities to improve request form design, service taxonomy, and automation, ultimately reducing manual corrections and enhancing the overall request fulfillment process.
How it’s calculated
The metric counts the number of times a service desk agent modifies request form fields after the request submission.
A modification includes:
Value added when a previously empty field is populated.
Value modified when an existing field value is changed to a different value.
Value removed when a field’s value is cleared.
Fields used in Forms are not accounted for in this metric due to Jira limitations. Only modifications to standard request fields are tracked.
Requests with a Request Type change
ACCURACY EFFICIENCY CONSISTENCY
Calculated based on data from the previous week
This metric tracks the number of service requests where a service desk agent changed the request type after submission.
It is divided into two sub-metrics to provide more precision on the nature of the change:
Request type changed to current request type
This counts the number of requests where the request type was changed to the current request type of the service request (i.e., no actual change in classification after modification).
Request type changed from current request type to another
This counts the number of requests where the request type was changed from the current request type to a different request type, indicating that the original classification was incorrect and needed adjustment.
Why this metric matters
✅ Identifies Misclassification Issues – Frequent changes to a different request type signal confusion in service categorization.
✅ Highlights Continuous Improvement Opportunities – A high number of changes to the current request type suggests misclassification of requests that need refinement across the catalog.
✅ Optimizes Agent Workflow – Helps reduce unnecessary manual reclassification and improve agent efficiency.
✅ Enhances User Experience – Provides insights to fine-tune the service catalog for easier self-service request submissions.
This metric helps streamline the request process and improve the accuracy of request type classifications over time.
How it’s calculated
The metric is calculated by counting the number of instances where a service desk agent changes the request type, either to the current one or from one type to another.
Requests cancelled by Agents
ACCURACY EFFICIENCY
Calculated based on data from the previous week
This metric tracks the number of service requests that have been cancelled by a service desk agent after submission. It helps assess the effectiveness and accuracy of the request process and provides insights into potential issues, such as unnecessary requests or incorrect submissions.
How it’s calculated
The metric counts the total number of requests that were cancelled by agents
It checks for requests in specific statuses that indicate cancellation. The following hard-coded statuses are tracked:
Cancelled
Canceled
Abandoned
Declined
Failed
Request form fields left empty
ACCURACY EFFICIENCY
Calculated based on data from the previous week
This metric tracks the number of service requests where one or more form fields were left empty by the user at the time of submission.
It helps assess the completeness of request submissions and provides insights into user behavior or potential issues with the request form.
Why This Metric Matters:
Accuracy & Completeness: Ensures that critical request information is provided, reducing back-and-forth communication.
Efficiency: Minimizes delays in request processing by identifying fields that may be unclear or unnecessary.
Form Optimization: Helps service owners refine request forms by adjusting, clarifying, or reconsidering frequently skipped fields.
By tracking empty fields, service owners can improve request form usability, enhance data accuracy, and streamline request handling.
How it’s calculated
The metric identifies fields that were left empty at the time of submission within the defined period
The top 10 most frequently empty fields are displayed, along with the number of requests in which each field was left blank