Software Support and SLAs: What to Demand After Launch

Launch day gets the champagne, but the contract that determines whether your software stays alive is the one most companies barely read: the support agreement. A software support SLA is the difference between "the system went down Saturday and was fixed by Saturday night" and "we emailed our developer three times and heard back Thursday." If you are commissioning software — or already running some — this is what the agreement should contain, what the numbers should look like, and the clauses vendors hope you won’t ask about.

An analogy first. Buying software without a support agreement is like buying a delivery truck with no plan for maintenance: nothing is wrong on day one, and everything about how the next five years go is already decided. Software does not rust, but its surroundings never stop moving — operating systems update, APIs deprecate, certificates expire, traffic grows. "Finished" software running in a changing world degrades on its own schedule, not yours.

What a software support SLA actually covers

A real agreement answers four questions in writing. What counts as a problem, and how severe is each kind? How fast does the provider respond, and how fast do they fix? Who does what — and what falls outside the agreement? And what happens when the relationship ends? Everything else is decoration. Notice what is not on that list: promises like "we’ll take care of you." Warm words are free; response times with clocks attached cost discipline, which is exactly why you demand them.

Severity levels and the numbers to demand

The heart of any software support SLA is the severity table. Reasonable market terms for business software look like this:

Two traps hide in these rows. First, response is not resolution — an SLA promising one-hour response only guarantees a human acknowledges you within the hour. Demand both clocks. Second, definitions beat numbers: if the vendor decides unilaterally what counts as SEV 1, the one-hour promise means whatever they want it to mean. Write the definitions in business terms — "customers cannot check out" is SEV 1 regardless of which component caused it.

The clauses that separate good agreements from decorative ones

• Escalation path. A named human and a timeline for when things stall — "if SEV 1 is unresolved after N hours, it reaches [role]." Support that can’t escalate is a mailbox.
• Preventive maintenance included. Dependency updates, security patches, monitoring, backup verification. If the agreement only reacts to breakage, you are buying firefighting and funding the fires.
• Clear boundaries. Bug fixes are support; new features are new work. Agreements that blur this either overcharge you for fixes or underdeliver on evolution. A monthly bank of hours usable for small improvements is a healthy middle ground.
• Exit clause with knowledge transfer. You own the code, the repository, the infrastructure credentials and the documentation — and the contract obligates an orderly handover on termination. Any provider who resists this clause is telling you their retention strategy is hostage-taking. Walk away.
• Reporting. A monthly summary: incidents, response times achieved versus promised, hours consumed. An SLA nobody measures is a hope, not an agreement.

What support should cost

Sustainable support and maintenance for custom business software typically runs 10 to 20 percent of the original build cost per year, depending on criticality and pace of change. Dramatically cheaper offers usually mean one of two things: the vendor is not actually reserving capacity for you, or they plan to recover margin by billing every conversation as new work. Support economics also start long before the contract — systems built with clean code, tests and documentation are simply cheaper to keep alive, which is why we treat maintainability as a first-class requirement in custom software development rather than a virtue to hope for later.

The right comparison, by the way, is not support cost versus zero — it is support cost versus the incident it prevents. One SEV 1 outage on a revenue system can burn more in a weekend than a year of proper maintenance costs; one missed security patch can cost more than five years of it. Framed that way, 10 to 20 percent annually is not an expense line. It is the premium on an insurance policy where the claims are all but guaranteed.

Frequently asked questions

Do internal tools need an SLA too?

If the tool stopping would stop revenue or payroll, yes — the formality should match the blast radius, not the audience. A lightweight severity table beats an unwritten understanding every time.

Our current system has no support agreement. Now what?

First, an honest audit of what you are running and what depends on it; then negotiate an agreement from a position of knowledge. An independent technical review — the kind we run in technology consulting engagements — tells you what the system needs before a vendor tells you what they’d like to sell.

Same time zone — does it actually matter for support?

For SEV 1, enormously. A provider on U.S. Central Time works your business hours; "one business hour response" means this morning, not their tomorrow.

If your software is launching soon — or launched years ago with a handshake instead of an SLA — schedule a call and we will review what your agreement should say before you need it.