Your Support Contract Promises a Fast Response. It Doesn't Promise a Fix.

The four-hour response that doesn't mean what you think

Most maintenance contracts lead with a response-time number, because it's the easiest thing to put in a sales deck. "4-hour response" sounds like a promise that someone will fix your broken checkout page by lunch. It isn't. Response time is almost always defined as the time until a human acknowledges the ticket exists — not the time until the problem is resolved. A vendor can hit a 4-hour response SLA by replying "we're looking into it" and then taking three days to actually ship a fix, and they haven't breached anything, because the contract never promised otherwise.

This isn't a gotcha specific to shady vendors. It's the industry default, because response time is cheap for a vendor to guarantee and resolution time isn't — resolution depends on how hard the bug turns out to be, which nobody can commit to in advance. The problem is that buyers read "4-hour response" and hear "4-hour fix," and the gap between those two readings is exactly where support contracts quietly stop being worth what you're paying for them.

Response and resolution are two different promises

A contract that's actually useful to you separates these explicitly:

• Response time — how long until a qualified person looks at the issue and tells you what they think is going on.
• Resolution time (sometimes called "time to restore") — how long until the issue is actually fixed or mitigated.

If your contract only states the first, you have no enforceable expectation about the second. That's fine for low-stakes cosmetic bugs. It's not fine for "customers can't check out" or "the parent portal is down during enrollment week." Ask your vendor directly: what's the resolution target, not just the response target, for each severity level? If they can't answer without rewriting the contract, that tells you what the current one is actually worth.

Severity tiers are what make any of this mean something

A single response/resolution number across every possible issue is close to meaningless, because a typo in a footer and a payment integration failure are not the same emergency. A contract worth signing defines at least two or three severity tiers — something like:

• Critical — the system is down, or a core workflow (checkout, enrollment, login) is broken for most users.
• Major — a significant feature is broken but there's a workaround, or it affects a subset of users.
• Minor — cosmetic issues, non-blocking bugs, requests for small changes.

Each tier should carry its own response and resolution targets, with critical issues getting the fastest numbers on both. If a vendor's proposal doesn't break severity into tiers, push for it before you sign — otherwise you have no standing to escalate when something actually matters, because "it's in the queue" technically satisfies a flat, undifferentiated SLA.

What "maintenance" actually includes — ask before you need it

The word "maintenance" gets used to cover wildly different scopes, and the gap between what you assumed it meant and what's actually in the contract usually surfaces at the worst possible time. Before signing, get explicit answers on:

• Security patching. Is applying framework and dependency updates included, or billed separately as "extra work"? Unpatched dependencies are one of the most common ways small-business sites get compromised, and it's exactly the kind of maintenance that's invisible until it isn't.
• Monitoring vs. reacting. Does the vendor proactively monitor uptime and errors, or do they only find out something's broken when you tell them? A retainer that's purely reactive is support, not maintenance — know which one you're buying.
• Backups and recovery. Who owns the backup schedule, where do backups live, and has a restore ever actually been tested? A backup nobody has restored from is a hypothesis, not a safety net.
• Hours structure and rollover. If the retainer includes a bucket of hours per month, what happens to unused hours — do they roll over, expire, or convert to a credit? And what's billed against that bucket: bug fixes only, or also the small content changes and tweaks you'll inevitably ask for?
• Point of contact. Is there a named person or team who knows your system, or does every ticket start from zero with whoever's on rotation? For anything beyond a template site, context loss between tickets is a real cost.

The clause that matters most is the one about leaving

The best test of a maintenance contract isn't what it promises while things are going well — it's what happens if you want to leave. Does the contract guarantee you get your code, credentials, data, and documentation back in a usable state, without the vendor's cooperation being optional or billed as a "transition fee" they get to set unilaterally? If the exit terms are vague, the response-time number on page one doesn't matter much, because you have no real leverage to enforce any of it once the relationship turns adversarial.

The takeaway

Before signing a maintenance or support retainer, get three things in writing: separate response and resolution targets per severity tier, an explicit list of what's included versus billed separately (patching, monitoring, backups, hours rollover), and a clean exit clause covering code, data, and credentials. A contract that only gives you a response-time number is a sales pitch with a timer attached — it's the resolution target and the exit clause that tell you what you're actually buying.