SLAs and governance for managed software outsourcing

Delivery governance is how people prioritize work, approve changes, review evidence, resolve risks, and authorize releases. A support agreement defines which production services are covered, when support is available, how incidents are handled, and what commitments apply. An ongoing development team does not automatically include production incident coverage.

Start with a service boundary: applications, environments, integrations, and activities included. Name the client product owner, provider delivery lead, technical approver, and incident contacts. If infrastructure or a third-party provider sits outside scope, document who coordinates with its owner.

A service level indicator (SLI) is a measurement, such as the proportion of successful requests. A service level objective (SLO) is a target for that measurement over a defined period. A service level agreement (SLA) records agreed service commitments and consequences. The terms serve different purposes; an internal engineering target is not automatically a contractual guarantee.

Define the user journey, measurement source, window, and exclusions before discussing a percentage. A healthy server does not prove that users can complete a transaction. Google’s SRE guidance is a useful starting point for selecting indicators tied to user experience. Targets for a Salt engagement must be separately assessed and agreed.

Response time is the time to acknowledge and begin handling a reported issue under the agreed support arrangement. Restoration is when the affected service works again, potentially through a workaround. Resolution addresses the underlying issue. These should not be treated as interchangeable promises.

Define severity by business impact: which users or critical workflows are affected, whether data is at risk, and whether a workaround exists. Specify when the clock begins, support hours and time zone, the reporting channel, update expectations, escalation ownership, and dependency handling. A resolution deadline may not be credible before diagnosis.

A suggested weekly delivery review covers accepted work, upcoming priorities, decisions needed, blocked dependencies, and budget or capacity changes. A release review covers acceptance evidence, outstanding defects, deployment responsibility, and rollback readiness. The cadence should match your project; these are planning examples, not a standard Salt service promise.

Avoid treating hours logged or story points as proof of business value. Ask what users can now do, which checks support release readiness, and what remains uncertain. Where a team uses Scrum, its defined accountabilities and inspection events can inform delivery practice, but they do not replace your engagement’s responsibility agreement.

Name the operational contacts who can unblock work and the decision-makers who can authorize scope, capacity, or release changes. Record unresolved risks with an owner and next action. Explain what happens when a required client decision, test environment, or external API is unavailable.

Use a change record that states the request, impact, alternatives, and approval. If quality or reliability is below the agreed expectation, make corrective work visible and decide how it affects planned features. Do not leave escalation dependent on someone knowing a senior contact informally.

Keep the operating material current: system boundaries, repositories, environments, monitoring ownership, deployment instructions, incident records, and unresolved issues. Review whether the agreed service still matches the actual application and workload.

Before changing providers or bringing work in-house, agree documentation, access transfer, data export needs, and transition assistance. Commercial remedies, liability, and termination provisions require a separately reviewed agreement; this guide is a delivery-planning checklist, not contractual wording.