What Is an Application Support SLA?

Four terms carry the contract. Severity ranks an incident as critical, high, medium or low, and every level needs an example drawn from your own application, such as customers unable to pay at checkout. Response time is the gap between a report arriving and a named engineer starting work on it, counted from the ticket timestamp rather than from a phone call. Clock disputes start here.

Restoration and resolution are different promises. Restoration means orders can be processed again, even through a workaround such as typing them into a spreadsheet kept at the front desk. Resolution means the root cause is fixed. A contract naming only one of them leaves the other undefined, and the gap can stretch to several days when a patch needs testing before release. Ask which one each target means.

Support hours say when a human answers. The options are business hours, an extended window or round-the-clock cover, and many contracts grant the round-the-clock tier to the highest severity only, leaving the rest to wait. Write hours per severity level. Otherwise nobody can say whether a Sunday night outage gets the attention of a Monday morning one, and the argument starts after the outage rather than before it.

Exclusions need the same scrutiny. Most contracts exclude third-party outages, scheduled maintenance and misuse, and a payment gateway failure may be excluded while still being yours to chase. Escalation covers the missed target. It names who is told, how soon, and who is told next if that person stays silent, so a breach never sits unnoticed.

Consider a clinic booking system used at three front desks, where a critical incident might read that patients cannot be booked or checked in anywhere. Illustrative targets might be a thirty minute response and a four hour restoration while the clinics are open, and a cosmetic report glitch waits for business days. These numbers are only illustrations.

Faster targets cost more to staff, so set each one from what an hour of downtime really costs your business, not from the number a salesperson offers first. Define severity with your own scenarios. A label like high means nothing until an example sits beside it, so test your definitions by sorting last year’s five worst incidents into them and watch for arguments.

Unmeasured SLAs are only paper. Most providers stamp every ticket at report, first response, restoration and closure, and from those four times you can count the incidents that met target each month. Ask for that report monthly. Ask also to see the raw tickets behind it, split by severity, because an average hides the one outage that hurt your customers most.

Review the numbers together every month or quarter, depending on how critical the software is, and put the missed targets and their repeat causes on the agenda first. Revisit targets as the business grows. An agreement signed once and never reopened slowly drifts away from how much you now depend on the system, until a minor clause hurts a major customer.

Not every application needs the same cover. Paying for round-the-clock critical response on an internal tool that nobody opens at night is poor value, and the saving belongs on the systems customers actually touch. Ask one question first. What happens to the business if this system is down for an hour, and what happens if it stays down for a whole day?

A customer-facing portal or a billing screen the team cannot work without justifies tight targets and wider hours, while an internal reporting page can sit on a lighter tier. Match cover to criticality, system by system. Buying the premium tier for a payroll export, a staff rota and a brochure site pays for coverage nobody will ever invoke.