Writing SLAs for business operations that AI helps run

A service level agreement is a contractual promise about outcomes both parties can measure. In AI-assisted operations, many of those outcomes are decided by software: whether an invoice lands on the right ledger account, whether a claim reaches the right handler, whether a reply states the policy correctly. The agreement has to describe the quality of decisions, not only the time they take.

An SLA can reasonably promise processing times, limits on backlog age, the time a person takes to pick up an item the software has set aside, quality on a defined sample, notice before material changes and named escalation contacts. It cannot promise that no single output is ever wrong, that a model behaves identically after its vendor updates it, or that targets hold when inputs the client controls arrive late.

ColdAI describes the Operate phase of its managed services as continuous delivery by dedicated teams with SLA-backed performance¹. This page explains how such an agreement should be shaped; it does not state ColdAI's own targets, which are set per process from a measured baseline.

A service level objective is the internal target the provider runs to; the SLA is the commitment it is paid against. Running to a stricter objective gives the provider room to correct a decline before it becomes a breach.

An error budget turns that gap into a working rule. Site reliability engineering treats the budget as the unreliability a service may spend in a period: while budget remains, changes ship; when it is spent, effort moves to reliability². In operations, express it as tolerated late items or critical errors per month. When it runs out, planned automation changes pause until quality recovers.

Set objectives from the baseline measured during transition rather than from a proposal, and revisit them after a full business cycle that includes month-end or the seasonal peak.

List the outputs that always go to a person before they take effect, such as payment releases above a limit, claim declines, account closures or replies to regulatory complaints. Then measure the time from the software's hand-off to a qualified person picking the item up. An overloaded human in the loop becomes a rubber stamp, and this measure is the earliest sign of it.

Commit to roles and competence rather than headcount: which decisions need a licensed or authorized reviewer, how cover works outside normal hours, and an escalation matrix naming contacts and response times at each level.

A weekly view covers queues, holds and incidents; a monthly pack covers each indicator, sampling results with root causes, credits and changes released; a quarterly review asks whether the targets still describe what the business needs. How those forums run is covered in the managed service governance checklist.