Enterprise Software Support and SLAs: What You Get at Each Tier and What It Costs

Prices are in US dollars. Euro and pound figures in parentheses are approximate, rounded conversions. Quotes are issued in the currency of your contract.

The system goes live, the project team moves on, and the question nobody asked during the build arrives in week two: who do we call, how fast will they answer, and what does that cost. Support is the part of enterprise software that runs for ten years and is discussed for ten minutes. This post explains what a support contract covers, what the tiers mean in response times and money, what the 15 to 25 percent rule is, and how to read a service level agreement before you sign it. It belongs to our buyer's guide to enterprise software development, and it assumes you have read, or will read, what the build itself costs.

What does support actually cover?

A support and maintenance contract covers keeping the system you paid for working as specified. In practice that means five things.

• Incident response. Something is broken or down, and someone diagnoses and fixes it within the agreed time.
• Bug fixes. Defects in delivered functionality, found after the warranty period, are corrected.
• Security patches. The operating system, frameworks, libraries and dependencies are kept current, and vulnerabilities are patched when disclosed.
• Upgrades and compatibility. When a browser, a mobile operating system, a cloud service or an integrated system changes, the application is adjusted to keep working.
• Monitoring and housekeeping. Uptime monitoring, error tracking, backup verification, certificate renewals, log rotation, database maintenance.

What support does not cover is change. A new report, a new user role, a new integration, a redesigned screen: these are enhancements, priced separately as small projects or drawn from a retained bucket of hours. The line between a fix and an enhancement is the most argued clause in any support contract, so the contract should define it. A fix restores specified behaviour. An enhancement changes it.

What are the support tiers?

The jump from Standard to Premium is large because 24/7 one-hour response means a rota of engineers who know your system, paid to be available. It is not a switch the vendor flips. If only one component of your system is revenue-critical, ask for Premium on that component and Standard on the rest. Good vendors will do it.

What is the 15 to 25 percent rule?

Over a year, the support, maintenance and housekeeping of a custom system costs 15 to 25 percent of what the system cost to build. A platform built for $400,000 (€350,000, £295,000) costs $60,000 to $100,000 (€50,000 to €85,000, £44,000 to £75,000) per year to keep running well, which is where the Standard tier range comes from. The low end applies to a stable system with few integrations and infrequent change. The high end applies to a system with many integrations, each of which changes on someone else's schedule, or to a system that is still evolving quickly. Below 15 percent, something is being skipped, usually dependency upgrades, which show up two years later as a security finding or a framework that can no longer be updated. What is technical debt describes the compounding. How much app maintenance costs covers the smaller-product version of the same rule.

What should an SLA define?

An SLA is a list of promises with measurements attached. Read it for the following, and if any is missing, ask for it.

1. Severity definitions. What counts as critical, high, medium and low, in terms of business impact, not technical symptoms. "The system is unavailable to all users" is critical. "A report is slow" is not. Both sides should be able to classify an incident in a minute.
2. Response versus resolution. Response is when a qualified person starts working. Resolution is when the issue is fixed or a workaround is in place. Many SLAs promise only response. Ask for resolution targets, even if they are targets rather than guarantees.
3. Coverage hours and time zone. Business hours in whose business and whose time zone. A vendor in Athens with a client in New York must say what 9am means.
4. Uptime measurement. Measured how, over what period, and excluding what. Planned maintenance windows are normally excluded, but they should be bounded and announced.
5. Escalation path. Who you call when the first line is not solving it, with names and numbers, not a ticket portal.
6. Service credits. What happens when the SLA is missed. Credits are usually a percentage of the monthly fee. They are an incentive, not compensation, so do not over-negotiate them. Negotiate the response times instead.
7. Included hours. How many engineering hours per month are inside the fee, what happens to unused hours, and the rate for hours beyond them, typically $45 to $90 per hour (€40 to €80 per hour, £35 to £65 per hour) nearshore and $120 to $220 per hour (€105 to €190 per hour, £90 to £165 per hour) onshore.
8. Reporting. A monthly report of incidents, response times, uptime, hours used and patches applied. If the vendor cannot report it, they are not measuring it.
9. Exit. Notice period, handover obligations, and confirmation that documentation, credentials and infrastructure are yours. MSA, SOW and change requests covers how the support schedule fits with the rest of the contract.

What are the common traps?

• Warranty confused with support. Most builds include a warranty period of 30 to 90 days for defects. That is not support. Monitoring, patches and incidents outside working hours start when the support contract does.
• Support with no monitoring. A vendor who waits for you to report an outage is not supporting the system. Monitoring with alerting to the vendor's on-call should be in every tier above Basic.
• Hours that vanish. Included hours that expire monthly and cannot be pooled turn into a fee for nothing in quiet months. Ask for quarterly pooling.
• Enhancements that drain support. Small change requests consume the included hours, and then an incident has no hours left. Keep enhancements on a separate budget.
• No upgrade plan. Patches without a yearly plan for major framework and platform upgrades means the system drifts until an upgrade becomes a project. Ask for an annual upgrade roadmap inside the fee.
• Single point of knowledge. One engineer at the vendor knows the system. Ask how many people are trained on it and how handover happens when they leave.

How do you choose the tier?

Price the hour of downtime. If the system is down for a working day, what does it cost in lost orders, idle staff, penalties and reputation. If that figure is under $10,000 (€8,500, £7,500), Basic is adequate. If a day of downtime costs $10,000 to $100,000 (€8,500 to €85,000, £7,500 to £75,000), Standard. Above that, or if you have uptime obligations to your own customers, Premium. Then check the integrations: a system that depends on five external systems will see more incidents than one that depends on none, and the tier should reflect the incident rate as well as the impact. Finally, consider the hours: a system used in three continents needs coverage in three continents regardless of the impact figure.

How 7L runs support

7L International is a custom software development and digital transformation firm with business hubs in New York, London and Athens, which is why our support rotas can cover European and American business hours without a night shift. We offer the three tiers above, we monitor every production system we support and alert ourselves before the client notices, and our monthly report lists incidents, response times, uptime, patches and hours. Enhancements run on a separate retained budget so support hours are there when an incident needs them. Support is one of the seven things end-to-end has to mean. If you have a system that is live and under-supported, or a build that is approaching go-live without a support plan, talk to us about which tier fits.