New · Release 2026.04, Multi-tenant audit exports & SLA dashboards now liveSee changelog →
IT service management
Incident management from first report to resolution
Track incidents from raise to resolution in a dedicated dashboard, connected to the same tickets, assets and monitoring signals the rest of the platform already keeps.
Support tickets · 23 open
7 urgent
TKT-2841 · Production DB slowSLA 2h left
Assigned to Rohan · Critical
TKT-2840 · VPN access for new hireSLA 1d left
Awaiting owner approval
TKT-2838 · Email forwarding setupResolved 14m
Auto-resolved by knowledge base
Product proof
Already live in the product
Backed by app modules
Running in production today: the incident dashboard as part of the ITSM suite.
Protected app route: /itsm
How it works
Built around real workflows
Highlights below describe capabilities already present in the protected app behind this page.
Incident intake and tracking
Severity and status views
Linked to assets and tickets
Audit trail throughout
Workflow
What teams can do here
Step 1
Raise an incident
Step 2
Assign and prioritise
Step 3
Track to resolution
Step 4
Review the trail
How it works
How it works
01
Log the incident
Incidents are tickets: each gets a unique ID, a title and description, a category (Hardware, Software, Network, Access/Permissions, Other), a priority (Low / Medium / High / Critical) and a status (Open, In Progress, Resolved, Closed). They can be raised from the web or created automatically from inbound email, which threads replies back to the same incident.
02
Assign and prioritise
Assign to a technician manually, or let category-based auto-assign rules route new incidents to the right owner. A resolution SLA due time is stamped on creation based on priority, using per-organisation SLA policies when configured and sensible code defaults otherwise.
03
Work it with full context
Link the affected IT asset, add public comments or internal technician notes, attach files, and log work time. Major incidents can be flagged (is_major_incident) and first-contact resolutions marked (is_fcr). Every status change and edit is written to a status log and an audit log.
04
Watch the SLA clock
First-response and resolution breaches are tracked separately (sla_response_breached, sla_resolution_breached) and incidents can be escalated. SLA policies can count business hours only, excluding off-hours and holidays.
05
Resolve and measure
On resolution the resolved time is captured, and end users can rate the outcome with a CSAT score (1–5). Recurring incidents can be linked upward to a Problem record for root-cause work.
Example
A worked example
Say a mail outage hits a 150-seat insurance broker mid-morning and five complaints arrive in ten minutes. The first is raised as a High-priority Network incident; the auto-assign rule routes Network tickets to the on-call engineer, and a resolution deadline is stamped from the org SLA policy. The engineer flags it as a major incident, links the mail-server asset, and logs work as they dig in. The four duplicates are linked to one Problem record so root-cause analysis happens once, not five times. Service returns within the SLA window, the incident is resolved with its timestamp captured, and the original requester leaves a CSAT rating on the fix.
FAQ
Frequently asked questions
Are incidents and helpdesk tickets the same records?
Yes — an incident is a ticket. The incident view sits over the same ticketing backend, so SLAs, comments, attachments, auto-assignment, audit logs and CSAT all apply to incidents as well.
How are SLA deadlines calculated?
A resolution SLA due time is set when the incident is created, based on its priority. If your organisation has defined SLA policies they override the built-in defaults, and a policy can be set to count business hours only so evenings and holidays do not burn the clock.
Can incidents be created automatically from email?
Yes. Incidents can originate from email as well as the web; the requester email and RFC-822 threading keys are stored so replies match back to the same incident and outbound responses thread correctly in the requester's mail client.
What is the difference between response and resolution breaches?
They are tracked independently. First-response is stamped when an admin first responds, and resolution has its own deadline, so a fast acknowledgement with a slow fix will breach resolution but not response.
How do we handle a flood of duplicate incidents for one outage?
Link the related incidents to a single Problem record. Problem Management then carries the root-cause analysis and known-error write-up once, rather than repeating it on every duplicate ticket.
Can end users tell us whether the fix actually helped?
Yes — resolved incidents support a customer-satisfaction rating (1–5) with an optional comment, so you get feedback on the resolution and not just the closure timestamp.
When something breaks, know whose clock is running
Auto-assignment, business-hours SLA policies with separate response and resolution timers, major-incident flags and CSAT on every fix — incident handling with an audit trail behind it.