- Severity describes business impact, not how annoyed you are — impact plus urgency is the standard way to set it.
- A ticket that names the site, tag, timestamp and last known-good state usually resolves in one pass.
- After-hours paging is reserved for Critical: a safety risk or a site that is down.
A support ticket is a piece of evidence, not a message. The faster it tells an engineer what changed, where, and when, the faster the loop closes. Service-management practice has converged on the same small set of fields for exactly that reason.[1]
Severity is impact × urgency
Priority in ISO/IEC 20000-1 and in ITIL practice is derived from two independent questions: how much of the service is affected (impact), and how quickly the situation degrades if nobody acts (urgency).[1][2] Set severity from the table below rather than from how the day feels — an over-escalated ticket displaces a genuine outage on the same queue.
| Severity | First response | Qualifies when |
|---|---|---|
| Critical | 1 hour, 24/7 | Safety risk, plant down, or telemetry blind across a site |
| High | 4 hours | Production impact with a workaround in place |
| Normal | 1 working day | Standard change, configuration or reporting request |
| Low | 2 working days | Question, cosmetic issue or documentation gap |
A Critical ticket wakes an on-call engineer. Sustained out-of-hours paging is a known driver of responder fatigue and slower recovery over time, so the class is deliberately narrow.[3]
What to put in the ticket
The five fields that decide your response time
Name the site and, where you have it, the exact tag or device identifier. A tag resolves to one series in the catalogue; 'the inverter' resolves to several.
What happens after you submit
You get a reference immediately. Triage confirms or corrects the severity — a correction is not a judgement, it is how the queue stays honest. Work then proceeds through detection, analysis, containment and recovery, with a written closure note, which is the lifecycle the NIST incident-handling guide describes and the one we follow for platform incidents.[5] For events touching industrial control systems, the same incident-response expectation is embedded in IEC 62443-2-1 as part of the security programme.[6]
Pre-flight before you hit send
Common questions
What makes a support ticket Critical?
Critical means business impact, not frustration: a safety risk, or a site that is down. Only Critical pages the on-call engineer after hours. Everything else is triaged on impact plus urgency during working hours.
What information should I include in a support ticket?
Five fields decide your response time: the site and asset, a timestamp with its UTC offset, the observed value against the expected one, the last known-good state, and what changed. A ticket carrying all five usually resolves in a single pass.
Why does the timestamp need a UTC offset?
Logs, historians and brokers each keep their own clock. An ISO 8601 timestamp with an explicit offset is the only form that can be lined up against them without guessing which local time you meant.
How does after-hours paging work?
After-hours paging is reserved for Critical tickets. Lower severities queue to the next working day, which is why an over-stated severity slows the queue for everyone rather than speeding up your own ticket.
Sources for every claim above
Each footnote in the article links here. Standards are cited by designation so you can verify the current edition with the issuing body.
- [1]ISO/IEC 20000-1:2018 — Information technology — Service management — Part 1: Service management system requirementsISO/IEC · International Organization for Standardization · 2018View source
- [2]ITIL 4: Incident management practice guidePeopleCert / AXELOS · PeopleCert International · 2023View source
- [3]Site Reliability Engineering, Chapter 11: Being On-CallBeyer, B., Jones, C., Petoff, J., Murphy, N. R. (eds.) · O'Reilly Media / Google · 2016View source
- [4]ISO 8601-1:2019 — Date and time — Representations for information interchangeISO · International Organization for Standardization · 2019View source
- [5]NIST SP 800-61 Rev. 2 — Computer Security Incident Handling GuideCichonski, P., Millar, T., Grance, T., Scarfone, K. · US National Institute of Standards and Technology · 2012View source
- [6]IEC 62443-2-1 — Security for industrial automation and control systems: Security programme requirements for IACS asset ownersIEC · International Electrotechnical Commission · 2024View source