Readout

A service report for Jira Service Management customers in the portal: their own and their organization's requests, resolution times and the SLAs a project chooses to publish.

Comment

The problem

Customers of an IT or support team keep asking the same thing: how are my requests going? Jira Service Management gives them a list of requests and nothing else: no counts, no resolution times, no service levels, and no view of their organization's requests as a whole. Showing SLAs to customers (JSDCLOUD-325) and reports in the portal (JSDCLOUD-2736) are among the oldest open requests in Atlassian's tracker. Teams end up exporting to spreadsheets and emailing monthly reports by hand.

What Readout does

  1. A Service report in the portal. Customers open it from their profile menu. It shows open requests, the ones waiting on them, how many were created and resolved in the period (last 30 days, 90 days, 12 months or all time), the typical (median) resolution time, the time within which 9 in 10 were resolved, and each service level the project publishes as a share met, with met and breached counts.
  2. Organization tabs. A customer who belongs to an organization gets a tab for it, built from the requests shared with that organization, which its members can already open in the portal. Projects can limit tabs to chosen organizations and decide whether requester names show.
  3. Charts, a table and a CSV. Created against resolved per week, month or year; open requests by status; requests by type; and a table of every request with its status, created date, resolution time and the result of each published SLA (Met, Breached, or time left). Export CSV downloads the same rows.
  4. Service levels on every request. A panel on each request's page in the portal shows the published SLAs with their goal and the time left, met, breached or paused.
  5. The project decides. Nothing shows until a project administrator turns it on under Project settings > Customer reports, picks which SLAs to publish and the label customers see, and chooses whether satisfaction (as an average) and hours spent appear.

How it is built

Forge only, no egress, and nothing about people is stored. Every customer read runs as that customer (asUser) through the JSM customer request API with requestOwnership OWNED, PARTICIPATED or ORGANIZATION, so the app only ever lists requests the portal already shows them. For those request keys only, the app reads the resolution date and the published fields (SLA cycles, satisfaction, time spent) with one asApp issue/bulkfetch per 100 requests. Request and project keys come from the Forge context, never from the screen, and an organization tab is accepted only if the customer's own call listed that organization. Metrics are pure functions (median and nearest-rank 90th percentile, period scoping, weekly, monthly or yearly buckets, SLA state from ongoing and completed cycles, CSV with formula cells neutralised) covered by unit tests. Modules: jiraServiceManagement:portalUserMenuAction and portalRequestDetailPanel with unlicensedAccess for customers, and a jira:projectSettingsPage. Forge storage holds only each project's settings.

Built With

Share this project:

Updates

Submission history