Which Processes Need an SLA and Which Need an Operational Expectation

When every internal process is declared critical, the organization ends up with constant alerts, on-call rotations that are hard to sustain, and commitments that no one can meet. The problem is not only technical: the true priority of an outage becomes blurred, while operating applications, integrations, and data that may tolerate waiting, reprocessing, or a manual alternative becomes more expensive.

The useful decision is not to label a system as “important.” It is to agree which business consequence is unacceptable, for how long, and under what conditions. From there, some processes will require a service level agreement (SLA); others will work better with an operational expectation, a reviewable internal target, or simply sound support practices.

This framework makes it possible to justify priorities to product, business, and technology teams without choosing figures by intuition or turning every request into a permanent availability obligation.

SLA, operational target, and good practice: different commitments

An SLA is an explicit commitment for a defined service. It normally establishes scope, service hours, metrics, responsibilities, exclusions, and a review or escalation mechanism. It does not mean promising that incidents will never occur: it states the expected level of operation and how failure to meet it will be handled.

In internal operations, it is useful to distinguish it from two lighter instruments:

• Service level objective: a measurable target that guides operations, such as completing a synchronization before an agreed time. It can be reviewed without treating every deviation as a contractual breach.
• Operational expectation: a clear working standard, but a less rigid one. For example, reviewing a request queue on business days or publishing a report at the start of the working day.
• Good practice: a desirable procedure, such as monitoring errors or documenting a manual recovery. It is valuable, but should not be presented as a guarantee if there is no capacity, coverage, and ownership to sustain it.

The decisive difference is the consequence. If an interruption blocks revenue, critical operational obligations, or customer service, and there is no reasonable workaround, an SLA is usually justified. If the team can reschedule the task, use the previous day’s data, or complete the work manually, an operational expectation will often be more honest and efficient.

Do not assign an SLA because of the requester's visibility or the age of the system. Assign it based on the verifiable harm caused by failing to provide the service within a specific window.

The five questions for classifying each process

Before discussing availability percentages or response times, classify the process using the same questions across all teams. The conversation stops being an abstract negotiation and becomes a risk assessment.

1. What is the impact if it does not work? Describe the effect on orders, operations, compliance, users, or decisions. Avoid generic answers such as “it is very important.” Identify which action cannot be performed and who is blocked.
2. What is the actual usage window? A portal used to place orders throughout the day does not have the same need as an overnight data load. Define days, time slots, deadlines, and known peaks.
3. What does it depend on? List applications, APIs, providers, credentials, networks, source data, and owning teams. A commitment can cover only what the team can observe and operate.
4. Is there a manual or degraded alternative? Determine whether information can be recorded temporarily, orders accepted through another channel, a previous copy consulted, or a task retried. Also assess the alternative’s actual capacity, not merely its theoretical existence.
5. What data loss or delay is tolerable? Distinguish availability from integrity. A process may accept a two-hour delay, but not a duplicate transaction, incomplete data, or the loss of changes.

Document the answers with both a business owner and a technical owner. If there is no agreement about impact or tolerance, there is not yet a basis for setting a service level; there is a pending business decision.

A useful criticality matrix for applications and integrations

A simple matrix prevents classification from depending on who raises the request. Score each dimension as low, medium, or high: impact, sensitivity to the usage window, lack of an alternative, data risk, and dependency complexity.

• High criticality: direct and immediate impact, a narrow or continuous window, no viable alternative, and significant risk of loss or inconsistency. It requires an SLA, monitoring, defined escalation, and recovery testing.
• Medium criticality: delay affects work or important decisions, but a degraded mode or recovery margin exists. It requires measurable operational targets, error monitoring, and periodic review.
• Low criticality: the process improves efficiency but can wait, be reprocessed, or be replaced temporarily. An operational expectation, backlog prioritization, and support during agreed hours are sufficient.

The category should apply to the specific service, not the entire application. The same platform may include a critical transactional portal, a deferrable reference report, and a monthly export. A single global SLA would hide these differences and impose unnecessary costs.

Classification example

An order portal may have high criticality if users cannot submit orders through another channel and an interruption stops operations. An overnight catalog synchronization could be medium criticality if it can be retried before opening hours or if the previous catalog enables temporary operation. An internal tracking report may be low criticality if it is consulted once a day and its data can arrive late.

This example does not determine a universal category. If the synchronization feeds mandatory prices or the report triggers a regulated decision, the assessment changes. Classification depends on the consequence and the window, not on the type of technology.

What a sustainable internal SLA should include

A useful SLA must be specific and operable. Promising “high availability” or “fast support” creates ambiguity when an incident occurs. By contrast, a brief document can define precisely what is provided and how it is measured.

• Scope: process, interfaces, users, and expected outcome. State which components are excluded.
• Service hours: committed operating window, applicable calendar, and maintenance windows.
• Metrics: process availability, detection time, time to first response, restoration time, or maximum acceptable delay. Measure outcomes, not only team activity.
• Owners: business owner, technical owner, incident response team, and owners of each dependency.
• Exclusions: source data not received, third-party outages, unapproved changes, or usage beyond planned capacity. These are not excuses: they define actual control.
• Escalation: notification channel, severities, people who decide contingency measures, and communication to affected parties.

Avoid copying targets from providers or other products. A value is defensible only if it responds to a business need and if the architecture, observability, and response capacity make it achievable. Reliability engineering practices popularized by Google distinguish between indicators, objectives, and agreements precisely to prevent an aspiration from becoming an impossible promise.

How to set metrics without choosing arbitrary figures

Start with the need, not with a percentage. Ask: “What is the latest point at which this outcome must be available to avoid the identified harm?” The answer defines an operational limit. Then compare that limit with historical data, dependencies, and recovery capability.

For availability, measure the ability to complete the relevant action, not merely whether a page responds. For an integration, measuring the percentage of completed runs and the delay of records may be more useful than measuring a server’s status. For recovery, separate two decisions:

• Recovery time objective: how long the interruption may last before restoring the service or activating an alternative.
• Recovery point objective: how much information can be lost or remain pending reconciliation after the incident.

Also define an operational error budget: the margin of non-compliance that can be tolerated over a period before reliability is prioritized over new improvements. If that margin is repeatedly exhausted, tightening the SLA is not enough; the design, external dependency, automation, support capacity, or even the need for the process must be reviewed.

Dependencies, changes, and signals to review the commitment

The most common mistake is to commit to an end-to-end outcome when several parts are not under the same control. If an external API, a data team, or a communications provider participates in the flow, document the dependency and agree on its own target. If no such agreement exists, phrase the commitment conditionally: what the team will do when it receives valid data or when the third party restores service.

Review every classification when any of these signals appears:

• The process starts being used during new hours or by more teams.
• The manual alternative disappears or is no longer viable because of volume.
• Repeated errors, reprocessing, or manual interventions increase.
• Integrations, data changes, or new failure points are added.
• An incident reveals that the actual impact was greater or less than documented.

Establish a regular review and a review after significant incidents. The outcome does not have to be a stricter commitment: it may involve reducing scope, creating a degraded mode, improving an alert, separating a critical service from a deferrable task, or lowering an SLA that no longer reflects actual use.

Checklist for making and maintaining the decision

1. Describe the business outcome delivered by the process.
2. Define impact, usage window, alternative, dependencies, and tolerance for loss or delay.
3. Classify the process by criticality, not the entire application.
4. Assign an SLA only to outcomes whose failure would cause unacceptable harm.
5. For everything else, define an operational target or a clear support expectation.
6. Verify that metrics can be observed and that owners are available to act.
7. Document exclusions and contingencies before an incident occurs.
8. Review the commitment when usage, dependencies, or impact change.

Maturity does not mean having more SLAs. It means that every commitment reflects a real need, can be measured, and has a viable operational response. That discipline protects both those who depend on the service and the teams responsible for maintaining it.