Building Jira operational dashboards for 10+ support teams — and discovering that "Ready to Trade but not yet Approved" was a bigger problem than slow nominations.
The New Business Partners team at RWE processed a high volume of onboarding requests through Jira, passing through IT, Credit, Legal, Accounting, and other support functions before a counterparty became Ready to Trade. Every ticket was visible individually — but nobody could see workflow health at the team level: which requests were stuck, whose workload was piling up, or where nomination times had drifted past target.
I designed and built the JQL queries and native Jira dashboards that surfaced this, covering nomination turnaround, workload distribution, and stalled tickets across 10+ teams. The highest-impact KPI turned out not to be a speed metric at all, but one that caught tickets everyone assumed were already finished.
Jira held rich operational data — status, workflow stage, assignee, priority, Ready-to-Trade flag, approval status — but it existed at the individual-ticket level. Managers could open any single ticket, but had no standardized way to answer questions like "is this team keeping up?" or "which requests have been sitting untouched the longest?" As backlogs grew and nomination times crept upward — sometimes past 72 hours against an internal 24-hour target — the gap in visibility became an operational risk.
Requests moved through multiple support functions before reaching Ready-to-Trade status — and then needed to reach a separate, final Approved status. Many teams treated "Ready to Trade" as the finish line and didn't always complete the remaining administrative step, leaving a gap between "functionally done" and "formally closed."
Fields available per ticket: status, workflow stage, created date, updated date, assignee, support function, priority, Ready-to-Trade status, approval status, and resolution information. All the raw material for the KPIs below already existed — the gap was purely in aggregation and presentation, not data collection.
Every dashboard metric was backed by a custom JQL query — these queries were the actual analytical work; the dashboard was just the presentation layer on top. Requirements came directly from stakeholders across support functions, and dashboards were refined iteratively as feedback came in and reporting needs evolved.
Nomination times sometimes exceeded 72 hours against an internal 24-hour target — three times over, in a process where trading readiness was time-sensitive.
Workload was unevenly distributed across team members, invisible without a consolidated view — meaning some people were overloaded while others had headroom.
"Ready to Trade" wasn't the same as "done." Teams often stopped at Ready-to-Trade status and left the final Approved step outstanding — a gap that was easy to miss ticket-by-ticket but added up to real backlog and compliance exposure.
None of these three problems stemmed from Jira lacking the right data — every field needed to detect them already existed. The root cause was aggregation: no one had built the queries and views that would turn ticket-level data into team-level signal. Individual tickets aging in a stage, or sitting at Ready-to-Trade without final approval, were each easy to miss on their own and only became visible once queried in bulk.
The dashboards helped bring nomination turnaround times down toward the 24-hour target from a baseline that had sometimes exceeded 72 hours, reduced workflow backlogs, and improved workload balancing across teams. The Ready-to-Trade-vs-Approved view in particular prompted teams to finish outstanding administrative steps, reducing both backlog and the compliance risk tied to delayed formal approval.