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.
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.
Already live in the product
Running in production today: the incident dashboard as part of the ITSM suite.
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
What teams can do here
- Step 1Raise an incident
- Step 2Assign and prioritise
- Step 3Track to resolution
- Step 4Review the trail
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.
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.
Frequently asked questions
See also: Problem management · Helpdesk & ticketing · Blog: What is a ticketing system? · Blog: Best ticketing systems compared · IT knowledge base
Book demo
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.
