---
title: 'Priorities, SLA and escalation'
description: 'Severity, priority and business impact scoring, service-level policies with calendars, timers and pause rules, and the automatic escalation engine.'
section: 'Operations Center'
weight: 7
related:
  - operational-issues
  - execution-and-queue
---

import Alert from '@/components/docs/Alert.astro';

## Priority, Severity, and Business Impact

### Severity

Severity reflects the technical seriousness of the current condition.

| Level         | Meaning                                                               |
| ------------- | --------------------------------------------------------------------- |
| Critical      | immediate risk of losing control, metering, safety, or a mass failure |
| High          | substantial disruption of function                                    |
| Medium        | degradation without an immediate critical consequence                 |
| Low           | local deviation or data shortage                                      |
| Informational | observation that requires no immediate action                         |

### Priority

Priority reflects the order in which work is performed.

| Priority | Typical deadline                                |
| -------- | ----------------------------------------------- |
| P1       | immediate response, remediation within 24 hours |
| P2       | scheduled remediation within 5 days             |
| P3       | remediation within 20 days                      |
| P4       | improvement or low-priority correction          |

Severity and Priority are not the same.

For example, an Issue may carry `Severity = High` together with `Priority = P3`.

Such a case is possible when the problem is technically serious but affects a standby asset with no current impact on the operation.

### Impact Score

An integral score may be applied for ranking:

$$
I =
w_s S +
w_b B +
w_a A +
w_r R +
w_d D
$$

where:

- $S$ — severity;
- $B$ — business impact;
- $A$ — number or criticality of affected assets;
- $R$ — safety or regulatory risk;
- $D$ — duration.

### Business Impact

OHM supports structured impact fields:

- number of affected devices;
- number of consumers or sites;
- volume of gas at risk;
- duration of degradation;
- potential data loss;
- risk of incorrect commercial metering;
- risk of a field visit;
- risk of an SLA violation;
- information security risk;
- cost of downtime;
- level of reputational impact.

<Alert type="info">
  A business impact estimate is not an accounting fact if it is built on an estimation model. The
  interface always shows the source, the method, and the confidence level.
</Alert>

## Service Level Management

OHM implements a full-fledged SLA management model.

Control extends not only to the resolution of a problem, but to its entire processing cycle.

```mermaid
flowchart TD
  A["Issue Created"] --> B["Response SLA"]
  B --> C["Acknowledgement SLA"]
  C --> D["Resolution SLA"]
  D --> E["Verification SLA"]
  E --> F["Closure SLA"]
```

Each stage has its own calculation rules.

### SLA Policy

The SLA policy defines:

- the allowed response time;
- the acknowledgement deadline;
- the resolution deadline;
- the verification deadline;
- escalation rules;
- the working calendar;
- exceptions.

The SLA is assigned automatically based on the canon, criticality, and object category.

### Working Calendars

The system supports:

- 24×7;
- 12×7;
- business days;
- regional calendars;
- public holidays;
- individual department schedules.

Time outside the working calendar is not counted unless the SLA policy requires round-the-clock response.

### SLA Timers

For each Issue, the system simultaneously calculates several independent timers.

For example:

- Time To Response;
- Time To Acknowledge;
- Time To Resolve;
- Time To Verify;
- Time To Close.

Each timer can have its own stop rules.

### Pause Conditions

The SLA clock can be paused.

For example:

- waiting for a supplier;
- waiting for access;
- waiting for authorization;
- seasonal restrictions;
- force majeure.

The reason for the pause must be recorded.

### SLA Breach

When an SLA is breached, the system automatically:

- changes the state;
- increases the risk level;
- triggers the Escalation Engine;
- creates an audit record;
- reflects the breach in the KPIs.

## Escalation Engine

The Escalation Engine automatically transfers a problem to a higher level of responsibility when defined conditions are violated.

Escalation does not depend on user actions and is performed automatically.

### Escalation Levels

A typical scenario:

```mermaid
flowchart TD
  P1["P1"] -->|"15 minutes"| L1["Shift Supervisor"]
  L1 -->|"1 hour"| L2["Regional Manager"]
  L2 -->|"4 hours"| L3["Operations Director"]
```

The specific intervals are defined by the organization's policy.

### Escalation Triggers

Escalation can be triggered by:

- a Response SLA breach;
- a Resolution SLA breach;
- the absence of an assignee;
- the absence of acknowledgement;
- reopening;
- massive scale;
- high Business Impact.

### Escalation Actions

When a condition is met, the system can:

- notify the manager;
- change the owner;
- raise the Priority;
- create a Massive Incident;
- create an external ticket;
- notify senior management;
- initiate additional analysis.

All actions are fully logged.

### Escalation History

The Issue card contains a complete log:

| Time  | Event                |
| ----- | -------------------- |
| 09:10 | Created              |
| 09:25 | Response SLA Warning |
| 09:40 | Escalation Level 1   |
| 10:30 | Escalation Level 2   |
| 13:00 | Escalation Level 3   |
| 13:10 | Assigned Director    |

The history is never deleted and is used in calculating operational KPIs.