Release Notes
Version 1.0
Released 16 August 2026
Version 1.0 is the first formal release of the ITSM Financial Command Center. It marks the point at which every headline figure on the platform is either counted directly from your own ticketing system or calculated from a rate that you have supplied yourself.
That principle shapes the whole product: we measure, you value. The platform counts what your ITSM tools record, such as tickets resolved, reassignments, response times and queue age. It then multiplies those counts by rates that only you can know, such as your engineer hourly cost and your contractual SLA penalties. No industry benchmark, no default salary and no assumed penalty is ever substituted for a figure you have not given us. Where a rate is missing, the metric that depends on it stays blank rather than showing a number you cannot defend.
The operational picture: what is at risk today, and what it would cost.
| Measure | What it tells you |
|---|---|
| SLA Health Score | The share of in-scope tickets currently within their agreed thresholds. |
| Total SLA Breaches | Tickets already past threshold, counted only on platforms you have placed under contract. |
| Estimated SLA Liability | Those breaches priced with the penalty structure you enter. Never a default. |
| At Risk of SLA Breach | Tickets approaching a threshold while there is still time to act. |
| Active Critical Incidents | Critical and High priority work currently open. |
| Average Ticket Age and Stale Tickets | How long the queue has been waiting, and how much of it has gone untouched. |
| Total Active Tickets | The whole open queue, including work outside any SLA, so you staff what actually exists. |
| Critical and High attention table | The oldest tickets needing a decision today. |
| Drill-down breakdowns | Every financial and SLA card opens into its own workings, using exactly the same rules as the headline, so a figure and its explanation can never disagree. |
The financial picture: where the money and the effort are actually going.
| Measure | What it tells you |
|---|---|
| Support Capacity per Ticket | Your paid support capacity over 90 days divided by the tickets your team resolved in that period, in both hours and currency. A built-in explanation written for directors sets out what the figure does and does not claim, and names the three things that most often explain a large number: unlogged demand and informal channels, misaligned resource allocation, and queue idle time. |
| Cost of Re-Triage | Reassignments counted from your ticket history, priced at the minutes you say each handover costs and your hourly rate. |
| Revenue at Risk | Calculated across the business capabilities you define and value. |
| MTTR | Measured in working hours rather than wall-clock hours, so a ticket raised on Friday evening is not penalised for the weekend. |
| First Contact Resolution and Resolution Rate | Each shown with the counts behind them, so the percentage can be checked. |
| Ticket Friction | The average number of times a ticket changes hands before it is solved. |
| Average CSAT | Where your platform supplies satisfaction responses. |
| Performance Trends | Eight complete calendar weeks of throughput. |
| Resource Planning Forecaster | Projects next week's incoming volume against your team size. |
The platform counts what your tools record. What it cannot know is what any of it is worth to you, because that comes from your contracts and your payroll rather than from a ticket. These are the figures that turn a queue into a number a board will act on, and each one is yours: entered by you, changeable at any time, and defensible because you chose it.
Until a value is provided, the metrics that depend on it stay blank rather than defaulting to an assumption.
| Platform | What we need | Notes |
|---|---|---|
| Zendesk | Your Zendesk subdomain, then authorise via OAuth | You approve the connection inside Zendesk. We never ask for your Zendesk password. |
| Jira | Site domain, account email, API token | Optionally a project key or a JQL filter, if you want to limit the connection to specific projects. |
| ServiceNow | Instance name, username, and a password or API token | Reads the incident table. The account needs read access to incidents and nothing else. |
| Custom REST API | Endpoint URL, method, any authentication headers, and a field mapping | Connect a proprietary or in-house system through any JSON endpoint. Reference detail below. Only public endpoints are reachable; requests to internal addresses are refused. |
Reference detail. Skip this unless you are connecting an in-house system.
If your ticketing system can return JSON, it can be connected. You point the platform at the endpoint and say which of your fields means what. The connection screen comes pre-filled with a worked example, so in practice this is editing field names rather than writing a configuration from scratch, and it is usually a job of minutes for whoever maintains the system.
| Mapping | Required | What it drives |
|---|---|---|
id, title, status, priority | Yes | Everything. Status and priority also need a value mapping, so the platform knows that your "Urgent" means Critical. |
createdAt | Yes | Ticket age, the queue figures and SLA liability. |
updatedAt | Recommended | The stale ticket count. Without it, a ticket is treated as last touched when it was raised, which is the conservative reading rather than a guess. |
resolvedAt | Recommended | MTTR, resolution rate, first contact resolution and support capacity per ticket. These stay blank without it, because a resolution with no timestamp has no duration. |
category, businessService, slaBreached | Optional | Category analysis, revenue at risk and breach detection respectively. |
Taken from your service contract. Entered separately for Critical and for High priority tickets, because they almost always carry different terms.
| Setting | What it means |
|---|---|
| Base penalty | The amount payable the moment a ticket of that priority breaches. |
| Daily penalty | The additional amount accrued for each further day in breach. |
| Maximum cap | The ceiling on any single ticket, so one forgotten ticket cannot dominate the total. |
| Platforms under SLA | Which connected platforms carry contractual SLAs at all. Leave every platform selected unless some of your connected work sits outside any contract. |
| Setting | What it means |
|---|---|
| Reporting currency | GBP, USD or EUR. Every figure in your account is expressed in it. |
| Engineer hourly cost | The fully loaded cost of an hour of engineer time, including employer contributions and overheads, not the salary rate alone. |
| Minutes lost per handover | Your estimate of the time lost each time a ticket changes hands: re-reading history, re-establishing context, contacting the previous assignee. No ITSM tool records this, so the figure is yours and it is yours to defend. |
| Team size | The number of people funded to work on support. Drives both the resource forecaster and support capacity per ticket. |
A list of the services your team supports, each with the value you attach to it. This is what turns a degraded service into a revenue-at-risk figure. Capabilities are yours to name; the platform does not presume to know your business.
Your logo file and an accent colour. Applied to dashboards and to exported decks.
Name, company name, work email address and an explicit GDPR consent at registration. A contact telephone number is optional.
Published so that you, or your security team, can confirm the platform is not running on unsupported software. Versions are those shipped in v1.0, checked against the latest published release on 16 August 2026.
| Component | In v1.0 | Latest | Status |
|---|---|---|---|
| Next.js | 16.3.1 | 16.3.1 | Current |
| React | 19.2.8 | 19.2.8 | Current |
| React DOM | 19.2.8 | 19.2.8 | Current |
| Node.js | 22 LTS | 22 LTS | Current LTS |
| TypeScript | 5.9.3 | 7.0.2 | Major behind |
| Component | In v1.0 | Latest | Status |
|---|---|---|---|
| Supabase (PostgreSQL, auth) | 2.112.3 | 2.112.3 | Current |
| Stripe (server) | 22.5.0 | 22.5.0 | Current |
| Stripe.js (browser) | 9.13.0 | 9.13.0 | Current |
| Upstash Redis (rate limiting) | 1.38.2 | 1.38.2 | Current |
| Resend (transactional email) | 6.20.0 | 6.20.0 | Current |
| undici (HTTP client) | 8.10.0 | 8.10.0 | Current |
| Zod (input validation) | 4.4.3 | 4.4.3 | Current |
| ipaddr.js (SSRF guards) | 2.5.0 | 2.5.0 | Current |
| Component | In v1.0 | Latest | Status |
|---|---|---|---|
| Recharts (charts) | 3.10.1 | 3.10.1 | Current |
| Lucide React (icons) | 1.31.0 | 1.31.0 | Current |
| date-fns | 4.4.0 | 4.4.0 | Current |
| PptxGenJS (PowerPoint export) | 4.0.1 | 4.0.1 | Current |
| dnd kit (drag and drop) | 6.3.1 | 6.3.1 | Current |
| Component | In v1.0 | Latest | Status |
|---|---|---|---|
| Vitest (unit tests) | 4.1.10 | 4.1.10 | Current |
| Playwright (end to end tests) | 1.62.1 | 1.62.1 | Current |
| ESLint | 9.39.5 | 10.8.1 | Major behind |
| Testing Library (React) | 16.3.2 | 16.3.2 | Current |
Nothing in the stack is unsupported or end of life. Every runtime component sits on a maintained major version, and Node.js is on the current Long Term Support line.
Nineteen of the twenty-one components listed above are on the latest published release. Two are not, and in both cases the constraint is the wider ecosystem rather than a decision of ours:
Neither tool is shipped to your browser, neither runs in production, and neither can affect a figure on your dashboard. Both are checked on each release, and both will be adopted when their ecosystems support them. Everything that does run in production, including the application framework itself, is on the latest published release as of this version.
Two high severity advisories are reported against image-size, a package reached indirectly through the PowerPoint export library. They are assessed and accepted, not fixed, and we would rather say so plainly than let an audit report surprise you later.
image-size through its latest published release, so there is nothing to upgrade to.Advisory references: GHSA-w3rx-r6r6-pgpr and GHSA-5p2g-fcmc-qvqq.
This release ships with over 100 test files and more than 1,500 automated checks, all passing, plus an end to end suite covering security and data export. The full suite runs before every release.
Every test file counts towards exactly one area below, so the figures add up to the total rather than overlapping. Counts are stated as a floor and will only grow.
| Area | Checks | What the tests verify |
|---|---|---|
| Billing and entitlement | over 370 | Subscription lifecycle, upgrade proration, cancellation, plan restrictions enforced on the server, and recovery from a payment event arriving out of order or twice. |
| Interface and connection state | over 350 | What each screen shows while data is still loading, when a connection is broken, and when one platform fails while others succeed. A figure is never asserted before it is known. |
| Financial calculation | over 290 | SLA liability and penalty caps, cost of re-triage, support capacity per ticket, revenue at risk, MTTR in working hours, resolution rate and first contact resolution. Each figure is checked against its own drill-down, so a headline and its explanation cannot disagree. |
| Security | over 230 | Credential encryption, protection against server-side request forgery, rate limiting, PII stripping, administrative authorisation, and an automated scan of the shipped browser bundle for credentials of any known shape. |
| Platform adapters | over 150 | The reporting window each connection asks for, pagination limits, resolution timestamps, and the merge when one ticket appears in more than one query. Includes the case of a platform returning nothing, and of a platform failing while others succeed. |
| Shipped documents | over 80 | Specific claims in this document and in the user manual are asserted against the code they describe, including every version number in section 4. A document cannot silently go out of date. |
Data integrity is not a separate row because it is not a separate area: that missing data stays blank rather than becoming zero, and that an impossible timestamp is excluded rather than counted as a negative duration, are asserted inside the financial and adapter suites where those values are produced.
Zendesk and Jira are verified against live production instances as well as by automated tests. ServiceNow and the Custom REST API are verified against their documented API contracts, with connection validation performed against your own instance at setup, which reports any authentication or permission problem immediately rather than failing quietly.
The User Manual covers day to day use, including how each metric is calculated and what to check when a figure looks wrong. For anything not answered there, use the Contact Us link in the portal.
ITSM Financial Command Center, version 1.0, 16 August 2026.