Official User Manual & Getting Started Guide
Welcome to the ITSM Financial Command Center! The platform gives IT leadership a single, executive-level view of operations. Connect your ticketing system (Zendesk, Jira, ServiceNow, or a custom REST API) and see your ticket queues, Service Level Agreement (SLA) health, and exact financial revenue at risk in one place. Premium accounts connect one ticketing platform; the free trial and Enterprise can connect several at once and see them merged into a single view.
The ITSM Financial Command Center isn't just a tool for agents. It is a strategic asset for IT leadership. By centralizing operations, the platform delivers immediate, measurable impact on your bottom line and service quality:
When you first visit the site, you will be prompted to log in or register. To create a new account:
noreply@itsmdashboard.dev.The platform supports multiple ways to connect to your existing ticketing systems securely. Go to the dashboard and look for the "ITSM Connection Settings" configuration panel.
We use an Enterprise-Grade OAuth 2.0 flow to securely connect your Zendesk environment without you handling sensitive API tokens.
mycompany if your URL is mycompany.zendesk.com).refresh_token in the background, keeping your connection alive automatically even when tokens expire.You can also connect directly to Atlassian's Jira platform.
You can also connect to your ServiceNow instance securely.
dev12345), Username, and either a Password or an API Token.Set the ServiceNow account up first. Three things are needed, and the second catches almost everybody. Whoever administers your instance will need to do them. The account needs read access to the incident table and nothing more: we only read, and we never write back.
itil role: this grants read access to incidents. On current releases it also brings snc_platform_rest_api_access with it by inheritance, so that one does not need adding separately. Without itil, ServiceNow gives the account a self service view showing only the tickets it raised, so your dashboard will look almost empty even though the connection succeeded.snc_basic_auth_api_access role directly.If you use a proprietary or in-house ticketing system, you can use our dynamic Custom REST API engine to pull in your tickets.
endpointUrl, HTTP method, and necessary headers (e.g. Bearer tokens).mappings block to tell the engine exactly how to translate your API's JSON keys into our standardized fields (e.g., map your system's "subject" to our "title").updatedAt and resolvedAt, or half the dashboard stays blank.
These two are optional in the sense that the connection works without them, and consequential in the sense that a great deal depends on them. They are pre-filled in the example configuration, so the usual job is correcting the field names rather than adding them.
resolvedAt drives MTTR, Resolution Rate, First Contact Resolution and Support Capacity per Ticket. Without it a resolved ticket has no duration, so those cards have nothing to calculate and stay empty.updatedAt drives the Stale Tickets count. Without it we treat a ticket as last touched when it was raised, which is the conservative reading rather than a guess, but it will understate how much of your queue has genuinely gone quiet.Once connected, your dashboard will populate with customizable widgets. Built on a fluid CSS Flexbox engine, you have ultimate layout control:
Use the Dark | Light toggle in the header to switch the entire portal between a light professional theme (the default) and a dark theme. Your choice is remembered on your device and applies everywhere: both dashboards, settings, and the sign-in screens.
Our platform analyzes your current queue. At the top of your screen, you will see a dynamic "Executive Insights" banner that gives you a human-readable summary of your workload.
Click "Go to Strategic View" to enter the executive console. Here, operational metrics are translated into financial impact:
Revenue at Risk (Strategic Dashboard). Every ticket that is not yet Resolved or Closed is checked against your configured capabilities. A ticket counts towards a capability when its service field matches the capability name (case-insensitive, partial matches allowed). The service field is the component field in Zendesk, component names in Jira, and the Business Service / Configuration Item in ServiceNow. Each matching ticket contributes:
Impact (£) = Capability Base Value × Priority Multiplier
| Ticket Priority | Multiplier |
|---|---|
| Critical | 1.0 (full base value) |
| High | 0.5 |
| Medium | 0.05 |
| Low | 0.01 |
Each capability's Revenue at Risk is the sum of its ticket impacts, and the headline figure is the total across all capabilities. Example: a £100,000 capability with one open Critical and two open Medium tickets shows £100,000 × 1.0 + £100,000 × 0.05 × 2 = £110,000 at risk. Tickets whose service field doesn't match any configured capability are not counted.
Est. SLA Liability (Classic Dashboard). This applies your configured penalty model to the age of open tickets. A Critical ticket starts accruing after it has been open for 4 hours; a High ticket after 24 hours. Once over its threshold, a ticket costs:
Penalty (£) = Base Penalty + (full days open × Daily Penalty), capped at your Max Cap
The KPI is the sum across all open Critical and High tickets (Medium/Low never contribute). Example: a Critical ticket open for 50 hours with a £1,000 base, £500/day and £5,000 cap costs £1,000 + (2 × £500) = £2,000. Until SLA settings are configured, this card shows an "Action Required: Configure SLA" prompt instead of a value.
Resolution times (MTTR and the category charts). Every resolution time is measured in working hours (08:00 to 18:00 UK time, Monday to Friday) over the last 90 days. A ticket raised at 17:00 on Friday and closed at 09:00 on Monday counts as 2 hours, not 64, because nobody worked the weekend. Public holidays are not excluded, since they differ by country. Days shown alongside these figures are working days of 10 hours, so “2.0d” means 20 working hours.
If a ticket’s timestamps are inconsistent (resolved before it was created, which happens with migrated tickets or clock differences between systems), it still counts towards ticket volumes, but is left out of the resolution-time averages, because its duration cannot be known. Enterprise breakdowns tell you how many were set aside.
Total SLA Breaches and SLA Health Score (Classic Dashboard). These two count breaches from two different rules added together, and the distinction matters because they cover different priorities:
So the breach count is not restricted to Critical and High. A Medium ticket your platform has flagged does appear in it, and does lower your health score. The SLA Health Score is the share of tickets not in breach, over the same set of tickets the breach count uses. Both halves of that sum always cover the same platforms and the same rules.
At Risk of SLA Breach (Classic Dashboard). Separately from the penalty model, this counter uses your ITSM platform's own SLA deadlines: it counts open tickets whose SLA target expires within the next 4 hours. Tickets that have already breached, or that carry no SLA deadline from the platform, are not counted.
Weekly figures use calendar weeks, Monday to Sunday, UK time. The Resource Planning Forecaster and the Backlog Clearance Rate both bucket by the same weeks your ITSM platform reports on, so a figure here can be checked directly against a report from Zendesk, Jira or ServiceNow. Each week is labelled by its commencing date: “3 Aug” means Monday 3 August 00:00 to Sunday 9 August 23:59.
The current week is shown but excluded from every average and from the trend line, because it holds only the days that have happened so far, and counting a Tuesday as a full week would make output look like it had collapsed. Charts also show two projected weeks, which carry a forecast only.
When a ticket counts as resolved. We use the date your platform records as the solve date. For Zendesk that is the solved timestamp from its own ticket metrics; if a ticket predates those metrics or your plan does not include them, we fall back to an estimate from the last-updated date, which can place a ticket a few days out. Reopened and re-solved tickets count on their most recent solve date.
Which platforms count towards an SLA. If you connect more than one platform, Configure SLA Parameters gains a Platforms under SLA section. Untick anything whose work carries no contractual commitment. A development backlog judged against a 4-hour response rule produces a liability figure that is arithmetically correct and entirely meaningless. Breaches, SLA Health and Est. SLA Liability are then calculated from the ticked platforms only, while total tickets, average age and stale counts continue to cover your whole queue, because those describe the work in front of you rather than a contract.
SLA liabilities only expose financial risk if you operate under contractual penalties. For internal IT organisations without penalty clauses, the dashboard measures operational friction instead, translating ticket bounces and queue drag directly into wasted payroll. This capability is available on every plan.
The cost of re-triage. Every time a ticket changes hands, a resource must re-read it, re-establish context and pick it up again. We extract those reassignment counts directly from your ITSM data. You supply the fully loaded engineer hourly cost and the estimated time lost per handover. To ensure absolute auditability, the dashboard prints its arithmetic directly on the card. For example, “94 reassignments × 15 min × £30/h”, so neither your CFO nor your board has to take the final figure on trust.
Configuring your financial baselines. Click the Financial impact settings link beneath the KPI cards on the Strategic dashboard to establish your baselines:
The preview figure updates continuously as you type, calculating directly against your live ticket data, so you can sanity-check a baseline before saving it.
Calculating hourly cost from a salary. If your organisation tracks salary bands rather than hourly contractor rates, expand the Work it out from a salary panel. For pounds, the platform pre-fills UK statutory employer costs for the 2026/27 tax year: National Insurance at 15% above £5,000, and auto-enrolment pension at 3% of earnings between £6,240 and £50,270. Rather than forcing you to accept an arbitrary multiplier, it generates the exact statutory output: a £70,000 salary yields a ~1.16× multiplier, materially leaner than the generic 1.3× often quoted by consultants. The difference represents optional benefits, equipment and training, and because only your organisation can define those, that field intentionally starts empty. Productive hours default to 1,740 (260 working days less 28 days statutory leave, at 7.5 hours per day). These statutory figures apply to UK payroll, so they are not offered when another currency is selected.
Support capacity per ticket. This metric divides your team’s paid working hours by the volume of tickets they successfully resolved. It requires two inputs: your team size, which inherits from the Support team size box on your Resource Planning Forecaster, and your hourly cost. The hours figure appears as soon as team size is set; the money follows once you add the rate.
This figure is not how long a ticket takes to resolve. It measures how much paid capacity exists for every ticket closed. If a 13-person team with 8,320 paid hours over 90 days resolves 498 tickets, the system calculates 16.7 hours of capacity per ticket. If an average ticket only takes your team one hour to resolve, then only 6% of your support payroll is visible in the ITSM. The remainder represents direct messages, project work, walk-ups and other unlogged demand. Clicking What this means on the card opens a diagnostic view of the most likely explanations, each with a check you can run.
How paid hours are calculated. Working days strictly exclude weekends and are measured from 08:00 to 18:00, aligning with the resolution-time window, so a standard 90-day period contains roughly 64 working days. Public holidays, annual leave and sickness are not deducted, as they vary by country and by contract. The card and its explanation always print the exact working days and hours used, so the calculation is reproducible.
How far back we look. Zendesk, Jira and ServiceNow connections are each queried twice: once for everything updated in the last 90 days, which drives the period figures, and once for the open queue however old it is, which drives backlog figures. An update window rather than a creation one, so a ticket raised in June and closed in August still counts towards August’s resolution figures. This is why a period figure here can be checked directly against a search in Zendesk (solved>), Jira (updated >= -90d) or ServiceNow (sys_updated_on) and should agree.
The Custom REST API is the exception, and it is worth understanding. Your endpoint is called once and we work with whatever it returns, because we cannot know how to ask your system for a date range. So the window is yours to set: if your endpoint returns every ticket you have ever raised, the period figures will cover all of it rather than the last 90 days. If it returns only open tickets, the resolution figures will have nothing to count. Scope the endpoint to roughly the last 90 days plus your open queue and the figures will line up with the other platforms.
What the re-triage figure covers. Reassignments on tickets raised in the last 90 days, matching the resolution-time window. Where a connected platform does not report reassignments (Jira does not expose them without inspecting every issue individually), the card names the platforms it can see, so a figure is never quietly presented as covering more than it does.
On the Enterprise plan, nine KPI cards across both dashboards become interactive. They show a small "View breakdown →" hint and open a detailed drill-down explaining exactly how the figure was produced:
Two charts on the Strategic dashboard have their own "View breakdown →" and "View resource planning →" links:
Both the Executive Dashboard and the Strategic Dashboard have an "Export Report" button (top right). Clicking it opens a menu with two options:
.pptx presentation of the dashboard's KPIs and charts, ideal for board packs and stakeholder updates. The Executive deck summarises your SLA KPIs (health score, breaches, ticket age, and estimated £ liability); the Strategic deck summarises business-capability risk, XLA health, team productivity (MTTR/FCR), and the resource forecast.Your account starts with a 7-Day Free Trial that includes every feature except Single Sign-On, so you can evaluate the Enterprise capabilities, not just the basics, before deciding. After 7 days your dashboard locks to protect your data streams, and you will be prompted to choose a plan to continue.
support@itsmdashboard.dev.
If you already subscribe to Premium, the Enterprise card shows Upgrade to Enterprise rather than a checkout button. This changes your existing subscription instead of creating a second one, so you are never billed twice.
Cancel at any time from Settings → Manage Billing, which opens Stripe's secure billing portal. There you can also update your card, download invoices, or renew a subscription you previously set to cancel.
We believe you should have complete control over your data. All account management tools are located in the Settings menu (accessible from the top right corner).
To request a copy of your personal data (profile, settings, and connection details) under your GDPR right to access and portability, email us at privacy@itsmdashboard.dev. We will provide it within 30 days.
If you no longer wish to use the service, you can permanently delete your account by clicking the red "Delete Account" button in Settings. If your access has lapsed and you cannot reach Settings, the same option is available as "Delete my account and data" on the screen you land on. You never need to contact us to remove your own data.
If you have an active subscription, deleting your account cancels it immediately, so you will not be billed again and you do not need to cancel separately in Stripe. Because cancellation is immediate, any days you have already paid for in the current month are not refunded. If your intention is only to stop paying, use Settings → Manage Billing instead: that keeps your access and your data until the period ends.
One thing is deliberately kept: your invoices and payment records. UK tax and company law require us to retain sales records for several years, so those remain in Stripe even after your account is erased. Your profile, credentials, connections and dashboard configuration are all permanently deleted.
The Release Notes set out what is in the current version, exactly which configuration we need from you, and the version of every component the platform runs on. If you are answering a security questionnaire or an audit, that is the document to start from.
Every dashboard has a "Contact Us" link in the footer. Clicking it opens an email to our support team. You can also write to us directly:
All service emails (welcome, password reset, trial reminders, deletion confirmations) are sent from noreply@itsmdashboard.dev, and if you reply to any of them, your reply reaches the support team automatically.
For system administrators, there is a hidden Admin Control Panel accessible by navigating directly to /admin in your browser.
Only users who have the is_admin: true flag in their Supabase authentication metadata are permitted to view this screen. Attempting to access it as a standard user will result in a 403 Forbidden error.