v2.0

GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here!

Watch the launch videoWatch

Service Level Agreement Enforcement

Automated system that monitors telecommunication service levels, detects SLA violations, and triggers appropriate compensation and escalation responses.

Solution

This service monitoring system ensures telecom providers meet their contractual obligations by continuously tracking critical service parameters like downtime, response time, and packet loss. When performance drops below agreed thresholds, the system automatically identifies SLA breaches based on the customer's service tier and the severity of the issue.

For premium customers, the system enforces stricter SLA requirements with faster response times and lower tolerance for service disruptions. The system calculates appropriate compensation amounts based on the breach duration and customer tier, offering service credits for premium customers and account credits for standard customers. Escalation workflows are triggered based on severity levels, with critical issues receiving immediate attention from senior management while medium-severity issues are routed to support teams with appropriate response timeframes.

How it works

The service monitoring system follows a structured decision process:

  1. Parameter Validation: Captures real-time data about service status, downtime duration, response time, and packet loss.
  2. Parameter Classification: Identifies which specific parameter is triggering the evaluation (downtime, response time, or packet loss).
  3. SLA Breach Detection: Compares current parameter values against contractual thresholds based on the customer's service tier.
  4. Severity Assessment: Determines issue severity based on parameter type, breach status, and customer tier.
  5. Compensation Calculation: Computes appropriate compensation amounts and types (service credits vs. account credits).
  6. Escalation Management: Determines if escalation is required and specifies timeframe and appropriate management level.

Where teams use it

  • Telecommunications service management
  • Internet service provider operations
  • Managed service level agreements
  • Enterprise network monitoring
  • Business continuity assurance
  • Customer satisfaction management

Inside the decision model

Service Level Agreement Enforcement ships as a JDM decision graph with 7 nodes, 5 decision tables and 25 rules. Download it, load it into GoRules, and run it as-is on Zen Engine.

Decision graph7 nodes · read-only
input requestexpression validateServiceParameterstable determineParameterTypetable assessSLABreachtable determineSeveritytable calculateCompensationtable determineEscalation
01

Request

input

Incident evaluation begins with three request objects: service carries the measurements (status, downtimeDuration, responseTime, packetLoss), customer supplies the serviceTier that sets the contractual thresholds, and incident holds the report metadata.

Sample requestJSON
{
  "service": {
    "id": "internet_service_123",
    "name": "Business Fiber Internet",
    "status": "down",
    "downtimeDuration": 45,
    "responseTime": 320,
    "packetLoss": 0.8,
    "startTime": "2025-03-19T15:30:00Z"
  },
  "customer": {
    "id": "cust_789",
    "name": "Acme Corporation",
    "serviceTier": "premium",
    "contractId": "contract_456",
    "contactEmail": "[email protected]"
  },
  "incident": {
    "id": "inc_123456",
    "reportedTime": "2025-03-19T15:45:00Z",
    "reportedBy": "automated_monitoring"
  }
}
02

Validate Service Parameters

expression

Raw telemetry is normalized before any rule fires: isDowntime becomes the boolean service.status == 'down', while downtimeDuration, responseTime, and packetLoss are defaulted to 0 with the ?? operator so missing probes cannot break threshold comparisons. customerTier falls back to 'standard', which means an unknown customer is judged against the looser SLA rather than the premium one.

Expressions5 fields
isDowntimeservice.status == 'down'
downtimeDurationservice.downtimeDuration ?? 0
responseTimeservice.responseTime ?? 0
packetLossservice.packetLoss ?? 0
customerTiercustomer.serviceTier ?? 'standard'
03

Determine Parameter Type

table

One violating parameter is selected per evaluation, in priority order under a first hit policy: isDowntime == true wins first and outputs 'downtime' with the duration as parameterValue, then responseTime > 0, then packetLoss > 0, with an 'unknown' fallback carrying 0. Only the first matching row fires, so a full outage is always assessed as downtime even if latency and loss are also degraded.

Ranking downtime above the other signals reflects how NOC triage works in practice: when a service is down, response time and packet loss readings are symptoms of the same event, and double-counting them would inflate both severity and compensation. The 'unknown' row keeps the graph deterministic when monitoring sends an event with no measurable breach.

Decision tablefirst hit policy
InputParameter TypeparameterTypeParameter ValueparameterValue
isDowntime == true'downtime'downtimeDuration
responseTime > 0'responseTime'responseTime
packetLoss > 0'packetLoss'packetLoss
-'unknown'0
04

Assess Sla Breach

table

Breach detection compares parameterValue against tier-specific limits, with the premium row for each parameterType listed before the standard one. Premium contracts tolerate downtime > 10 minutes, responseTime > 200, and packetLoss > 0.5 before slaBreached flips to true; standard contracts allow > 30, > 500, and > 2 respectively, and the final row returns 'No SLA breach detected'. Each hit also writes a breachDescription such as 'Excessive downtime for premium customer' for the incident record.

Running one threshold table per tier pair is how SLA schedules are actually written into enterprise contracts: the customer buys a numeric commitment, and the 2x-4x headroom between premium and standard limits is what differentiates the products. Half a percent packet loss is a defensible premium ceiling because real-time services like VoIP degrade noticeably beyond it, while 2 percent is livable for ordinary browsing traffic.

Decision tablefirst hit policy
Parameter TypeparameterTypeService LevelcustomerTierParameter ValueparameterValueSLA BreachedslaBreachedBreach DescriptionbreachDescription
'downtime''premium'> 10true'Excessive downtime for premium customer'
'downtime''standard'> 30true'Excessive downtime for standard customer'
'responseTime''premium'> 200true'Response time exceeds premium SLA'
'responseTime''standard'> 500true'Response time exceeds standard SLA'
'packetLoss''premium'> 0.5true'Packet loss exceeds premium SLA'
'packetLoss''standard'> 2true'Packet loss exceeds standard SLA'

+1 more row in the downloadable template

05

Determine Severity

table

Severity is graded by crossing slaBreached with parameterType and customerTier under a first hit policy. A breached 'downtime' event is 'critical' (severityScore 3) for 'premium' customers and 'high' (2) for 'standard'; 'responseTime' and 'packetLoss' breaches score 'high' for premium and 'medium' (1) for standard, and anything without a breach resolves to 'none' with score 0.

Shifting every category up one notch for premium accounts encodes the commercial reality that enterprise contracts, like the fiber customer in the sample, often carry penalty clauses and reference risk, so the same outage costs the carrier more. The numeric severityScore alongside the label makes it easy for downstream systems to sort or aggregate incidents without parsing strings.

Decision tablefirst hit policy
SLA BreachedslaBreachedParameter TypeparameterTypeCustomer tiercustomerTierSeverity LevelseverityLevelSeverity ScoreseverityScore
true'downtime''premium''critical'3
true'downtime''standard''high'2
true'responseTime''premium''high'2
true'responseTime''standard''medium'1
true'packetLoss''premium''high'2
true'packetLoss''standard''medium'1

+1 more row in the downloadable template

06

Calculate Compensation

table

Payouts scale with the measured breach: when slaBreached is true, a 'premium' customer receives parameterValue * 5 as a 'service_credit', any other breached tier receives parameterValue * 2 as an 'account_credit', and non-breaches get compensationType 'none' with amount 0.

Crediting proportionally to the breach magnitude, minutes of downtime in the sample case, follows the standard SLA remedy model where compensation is a service credit rather than cash, which caps the carrier's exposure while still making the guarantee enforceable. The 5x versus 2x multiplier is a pricing decision that keeps premium credits meaningful relative to the higher fees those customers pay.

Decision tablefirst hit policy
SLA BreachedslaBreachedCustomer tiercustomerTierCompensation amountcompensationAmountCompensation typecompensationType
true'premium'parameterValue * 5'service_credit'
true-parameterValue * 2'account_credit'
--0'none'
07

Determine Escalation

table

Routing follows severityLevel directly: 'critical' escalates to 'senior_management' with an 'immediate' timeframe, 'high' goes to a 'service_manager' within '4_hours', 'medium' to the 'support_team' within '24_hours', and anything else sets requiresEscalation to false. The three output fields together form a complete dispatch instruction for the ticketing system.

Tiered response clocks like immediate/4/24 hours mirror the restoration targets telecom operators publish in support plans, where the escalation level rises with severity so management attention is reserved for incidents that threaten contract penalties. Mapping the no-breach case to 'none' keeps informational events out of the on-call queue.

Decision tablefirst hit policy
Severity levelseverityLevelRequires EscalationrequiresEscalationEscalation TimeframeescalationTimeframeEscalation LevelescalationLevel
'critical'true'immediate''senior_management'
'high'true'4_hours''service_manager'
'medium'true'24_hours''support_team'
-false'none''none'

Make this template
your own.

Load Service Level Agreement Enforcement into GoRules, adjust the rules to your policy, and ship it behind your own API.