How do you handle monthly customer reporting across multiple JSM organizations?

Question

Hi everyone,

I’m looking into how teams using Jira Service Management handle reporting when they support multiple external customers.

I’ve come across a few cases where teams have 20, 50, or even 100+ customer organizations in JSM, and someone still has to prepare a separate report for each customer every month.

Things like:

* Tickets created and resolved
* Open tickets
* SLA performance
* SLA breaches
* CSAT
* Changes from the previous month

I’m curious how people are actually handling this in practice.

If you send regular reports to your customers, I’d really appreciate hearing how you do it today.

* About how many customer organizations do you support?
* Do you send monthly or quarterly reports?
* How do you create and send them?
* Does it involve much manual work?
* What part of the process is the most annoying?

I’m exploring whether it would be useful to have something that could take one setup, separate the data for each customer, let you review it if needed, and then send the right report to the right customer automatically.

I haven’t built anything yet. I’m mainly trying to find out whether this is actually a problem worth solving.

Would love to hear how other teams are dealing with it — including if you already have a good solution.

Birkan Yildiz _OBSS_ · Answer

Hi @Masa,

Preparing separate monthly reports manually for 20, 50, or 100+ customer organizations in Jira Service Management is a common challenge that takes up a massive amount of time when relying on native Jira features or manual spreadsheet exports.

If you are open to using an Atlassian Marketplace app, TicketBook - Service Time and Contract Management for Jira was built specifically to automate this kind of multi-customer tracking and reporting:

Automated Contract & Quota Tracking: You can define a service contract for each customer organization once (setting monthly ticket quotas, service hours, or SLA success rate targets). TicketBook automatically tracks real-time usage against those quotas without any manual calculations.

Self-Service Customer Portal View: Instead of manually compiling and emailing PDFs every month, customers can view their live quota consumption (e.g., tickets used, remaining hours, active contract period) directly on the JSM Customer Portal.

Exportable Reports for Reviews: When you do need formal reports for monthly or quarterly reviews, you can run and export Contract Reports and SLA Success Rate Reports (in XLSX, CSV, or PDF) grouped by customer, project, or date in a few clicks.

You can find TicketBook - Service Time and Contract Management for Jira on the Atlassian Marketplace.

Full disclosure: I'm on the team that makes TicketBook. Hope this helps.

Best,

Birkan

Levente Szabo _Midori_ · Answer

@Masa with 20+ organizations, I think the data itself is rarely the problem. The 1 to 3 days go into rebuilding, reformatting and sending the same report by hand every month. So the setup to aim for is one you build once per customer and then leave alone.

That’s the gap Midori covers with two apps:

* Better PDF Exporter turns a queue or JQL search into a formatted PDF and recognizes the JSM fields (Organizations, SLA, Satisfaction, Request Participants) without extra configuration. A per-customer SLA export then lists every request with its SLA values next to it.
* Better PDF Automation (free, runs on top of Better PDF Exporter) adds a send action to Jira Automation. A scheduled rule on the 1st of the month runs JQL like project = SUP AND Organizations = "Acme" AND resolved >= startOfMonth(-1) AND resolved < startOfMonth() and emails the PDF to that customer’s contacts.

I’d add that the review step you describe is just a choice of recipient. Point the rule at the account manager first, who checks and forwards the PDF, and switch it to the customer once you trust the output. With many organizations, you clone the rule and change only the organization and the recipients. That’s a one-time swap instead of a monthly one.

On native dashboards not looking client-ready: Better PDF Exporter also exports Jira dashboards to PDF, which covers the charts.

Here’s how the scheduled send rule is set up. I’m part of the team at Midori building these apps, so feel free to drop me a line at levente.szabo@midori-global.com if you want to compare notes on what your research turns up, we are happy to help.

Orion · Answer

Hi @Masa, with only native features, what has worked for me is building one saved filter per report metric with the Organizations field as the only variable, so each monthly run is mostly copy and swap. For example, resolved last month: project = SUP AND Organizations = "Acme" AND resolved >= startOfMonth(-1) AND resolved < startOfMonth(). Breaches in the same period: project = SUP AND Organizations = "Acme" AND resolved >= startOfMonth(-1) AND resolved < startOfMonth() AND "Time to resolution" = breached(). Open backlog: project = SUP AND Organizations = "Acme" AND statusCategory != Done. For SLA performance and CSAT, the built-in JSM reports can be filtered by series, but they are per project, so many teams end up exporting the filters to CSV and computing the month-over-month deltas in a spreadsheet. One thing to check before trusting the numbers: SLA breaches are counted per SLA cycle, so if your SLAs restart (for example on reopen), a single ticket can contribute more than one cycle. With 50+ organizations, the manual part really is the swapping and formatting, so your instinct that this is a real pain point seems right to me.