What should a business connectivity service level agreement define?

A business connectivity service level agreement (SLA) should translate a connectivity service into measurable obligations, clear ownership and an agreed method for dealing with exceptions. It should remove uncertainty about what is being supplied, how performance is judged, what happens when conditions are not met, and how the arrangement is managed throughout the contract.

1. The exact service covered

The agreement should identify every circuit, access service, network hand-off and associated support component within scope. Each service should have a unique reference, location, bandwidth description and service type, with any exclusions recorded. If the service includes equipment such as routers, firewalls or managed network devices, the SLA should distinguish between provider-owned, customer-owned and third-party equipment.

This prevents a disagreement where a connectivity provider believes it is responsible only for the access circuit while the customer assumes that local equipment, wireless distribution or internal cabling is included. The document should also state where the provider’s responsibility ends, such as at a demarcation point or customer premises equipment interface.

2. Definitions that make measurements consistent

Terms such as outage, degradation, incident, restoration, resolution, scheduled maintenance and business impact should be defined. An outage might mean a complete loss of service, whereas degradation may involve packet loss, latency or reduced throughput while the connection remains usable. These conditions should not be treated as interchangeable.

The SLA should explain when an incident clock starts and stops, whether time spent waiting for customer information is excluded, and how incidents are treated when several faults occur together. Without these definitions, two parties can report different results from the same event.

3. Performance measures and how they are calculated

Performance measures should be specific enough to verify. Depending on the service, they may cover availability, latency, packet loss, jitter, throughput, fault acknowledgement, progress updates and restoration. The SLA should state the measurement point, monitoring method, reporting interval and calculation method for each measure.

It should also identify exclusions, but these must be precise rather than broad. Examples may include customer-caused damage, unauthorised configuration changes, force majeure events, planned work carried out under the agreed process, or faults in equipment outside the provider’s control. The agreement should explain how exclusions are evidenced and whether they remove the whole event or only a defined period from the calculation.

4. Fault handling and escalation

The SLA should set out the information required to log a fault, the severity categories used to prioritise incidents and the route for escalating an unresolved issue. Severity should reflect business impact rather than simply the number of users affected. For example, a loss of connectivity to a critical site may require a different treatment from intermittent performance affecting a non-essential connection.

Escalation should cover technical ownership, operational management and commercial review where appropriate. The agreement should identify the records that will be kept, the circumstances that trigger an escalation and the information that must accompany each status update. It should also state how the provider and customer coordinate when diagnosis depends on testing at the premises.

5. Customer and provider obligations

Both sides need defined responsibilities. The provider’s obligations may include maintaining the supplied service, investigating reported faults, protecting relevant network equipment and retaining evidence from monitoring systems. The customer’s obligations may include providing safe access to equipment, maintaining power and internal cabling, approving configuration changes, protecting credentials and notifying the provider of relevant alterations.

Where another carrier, access network operator, data centre or facilities provider is involved, the SLA should explain how those dependencies affect the commitment. It should identify who communicates with the underlying supplier and who remains accountable for keeping the customer informed. This is particularly important where the customer has one contractual relationship but the technical service relies on several organisations.

6. Planned work and service changes

The agreement should define how planned maintenance, upgrades, migrations and configuration changes are requested, assessed, approved and recorded. It should specify the information supplied before work begins, including the affected service, expected impact, implementation window, rollback approach and validation checks.

There should be a clear distinction between authorised planned work and an unplanned outage. The SLA can also define how urgent changes are handled when delaying action would increase risk, while still requiring retrospective documentation and review.

7. Monitoring, evidence and reporting

A strong SLA states which monitoring data is authoritative and how either party can challenge a measurement. Useful evidence may include device logs, circuit tests, incident timelines, performance graphs, maintenance records and post-incident reports. Reports should show the period covered, services assessed, incidents included or excluded, performance against each applicable measure and outstanding corrective actions.

The agreement should address data retention and access to records, particularly where the customer needs evidence for internal governance, risk reviews or supplier management. It should also state how monitoring gaps are treated; a lack of data should not automatically be interpreted as proof that the service met its standard.

8. Remedies and corrective action

If a service level is missed, the SLA should specify the available remedy and the process for claiming it. This may involve a service credit, fee adjustment, corrective action plan or a defined contractual escalation. The agreement should state whether remedies are automatic or must be requested, the evidence required, any claim deadline and whether remedies are the customer’s sole recourse for that type of failure.

Remedies should not replace investigation. For material or repeated failures, the provider may be required to explain the cause, identify contributing factors, document corrective actions and provide a target date for completion. The SLA should distinguish between restoring service and addressing the underlying cause, as these are separate outcomes.

9. Governance and review

The agreement should define how performance is reviewed, who attends service meetings and how recurring issues are tracked. Review records should cover trends, open risks, unresolved incidents, planned work, capacity concerns and proposed changes to the service. A formal change-control process should apply when the connectivity design, service scope, performance measures or responsibilities change.

It is also sensible to connect the SLA with the wider contract by stating how disputes are raised, how amendments are approved, what happens at renewal and how service records are returned or retained when the arrangement ends. This keeps the SLA usable throughout the service lifecycle rather than treating it as a document that only matters when a fault occurs.

Before accepting an SLA, a business should test it against realistic scenarios: a complete circuit failure, poor performance without total loss, a fault involving a third party, an emergency configuration change and a missed maintenance commitment. If the document does not show who acts, what is measured, what evidence is produced and what remedy follows, it is not yet precise enough to govern the connectivity service.