Agency SLAs and Support Contracts: What Ongoing Work Actually Looks Like

The project launched. The client is happy. Then three weeks later, the payment gateway stops processing and they call you at 10:47pm. You fix it in 45 minutes. They don’t pay you for it, because you weren’t charging for support. The fix felt like the right thing to do. The next time it happens, you start to resent it.

This scenario plays out at most agencies that don’t have explicit support agreements in place. The work happens anyway. It just happens for free, and it creates resentment on the agency side and unrealistic expectations on the client side.

A service-level agreement (SLA) and a support contract aren’t just about getting paid for on-call work. They’re about making the ongoing relationship explicit so both sides know what to expect.

What a Support Contract Covers

A support contract defines four things: what you’re responsible for, how fast you’ll respond, how much the client pays, and what’s excluded.

Without those four things written down, every support request is a negotiation. With them, it’s a process.

Scope. Be specific about what “support” means. Does it include:

• Bug fixes for code you wrote?
• Bug fixes for third-party plugins or packages?
• Performance degradation that wasn’t present at launch?
• New feature requests disguised as bug reports?
• Infrastructure issues (hosting, DNS, SSL certificates)?
• Security patches?

Most support contracts cover bugs in the code your agency wrote and infrastructure your agency manages. Third-party integrations are typically covered at a reduced level (“best effort”), and new features are out of scope.

Response time. Different issues warrant different urgency. A severity classification handles this:

Severity	Definition	Target response
P1 – Critical	Site is down, checkout broken, data loss	1 hour, any time
P2 – High	Key feature broken, affecting significant users	4 hours, business hours
P3 – Medium	Non-critical feature broken, workaround exists	1 business day
P4 – Low	Cosmetic issue, minor improvement	3-5 business days

Response time is not resolution time. You’re committing to acknowledge the issue and start working on it within that window. Resolution time depends on complexity and should not be committed to in the SLA.

Price. Support contracts are typically priced one of three ways: monthly retainer, hourly as-used, or a hybrid.

A retainer gives you predictable revenue and the client a fixed monthly bill. It works when the client needs regular, ongoing attention: security patches, content updates, minor tweaks, monitoring. Price it based on your expected hours at a slight premium for availability.

Hourly as-used is simpler: the client pays for time when they need it. Works for clients who don’t need much support but want access when something breaks. You’ll typically charge a higher hourly rate (1.5-2x your project rate) to account for the interruption cost.

The hybrid is a low monthly retainer for monitoring and P1 response, with hours billed separately for actual work. This gives the client peace of mind without overpaying for quiet months.

Exclusions. Write these out. Common ones:

• Issues caused by client-made changes to the codebase
• Third-party API outages beyond your control
• Infrastructure issues caused by the hosting provider
• Work that exceeds a set number of hours per month (for retainer contracts, anything above rolls to the next month or is invoiced separately)
• Changes to functionality, not just restoration of existing functionality

The exclusions section is where support contracts go wrong when they’re vague. “Issues caused by client changes” needs to be defined carefully. A client who has FTP access and edits templates directly is going to cause issues you didn’t create.

What SLAs Don’t Mean

An SLA is not a guarantee of uptime. Agencies rarely control the hosting infrastructure directly. Clients use AWS, Vercel, Shopify, and managed WordPress hosts. Your SLA is about your response and your code, not the underlying platform.

If a client expects “99.9% uptime” and you’re running them on shared hosting, that’s a mismatch between expectations and infrastructure. Before signing a support contract, be clear about what you control and what the hosting provider controls.

An SLA also doesn’t mean you’re on call 24/7 unless it explicitly says so. A contract that promises 1-hour P1 response without specifying business hours vs. around the clock is asking for a phone call at 3am. Be explicit: “1-hour response during business hours; 4-hour response outside business hours for P1 issues.”

Monitoring as a Line Item

Support contracts work better when you’re not relying on the client to notice something is broken. Proactive monitoring (uptime checks, error rate alerts, SSL certificate expiry warnings) turns you from a reactive responder into someone who often knows about problems before the client does.

Basic monitoring stack that fits most support contracts:

• Uptime Robot or Better Uptime for availability checks (free tiers are fine)
• Sentry for error tracking
• Grafana/Prometheus or Datadog for server-side metrics if you’re managing the infrastructure

Price this into the retainer. An extra $50-100/month for monitoring tools is worth it if it means you catch a P1 before the client does.

Structuring the Conversation

Bring up the support contract at the end of the project, not after launch. During the final sprint, when both sides are thinking about handoff, it’s easy to open with: “We want to make sure you’re covered after we hand this over. Let me walk you through the support options.”

Most clients say yes to some level of support when asked directly at a moment when they’re thinking about post-launch risk. The clients who decline often don’t understand what they’re declining. Make it concrete: “If the payment integration breaks on a Saturday, here’s what happens with a support contract vs. without one.”

Agencies that treat support as optional and awkward to sell tend to do support work for free out of a sense of obligation. Agencies that treat it as a standard part of the engagement close the conversation cleanly and get paid for the ongoing work.

Renewal and Rate Reviews

Support contracts should include a term (typically 6 or 12 months) with a renewal provision. Add a clause that rates are subject to review at renewal. Without this, you’re locked into 2023 pricing in 2026, and the client has no expectation that it might change.

Send a renewal notice 30 days before the contract end. Include a summary of work performed, any rate changes, and the proposed new contract. Most clients renew without friction if you’ve been responsive. Those who don’t renew often had low engagement anyway, and it’s fine to let them go.

The Contract Template

For most agency support contracts, the key sections are:

1. Scope – what code/systems are covered
2. Severity levels – P1 through P4 definitions
3. Response times – per severity level, with business hours specified
4. Exclusions – what’s not covered
5. Pricing – retainer amount, any hourly overage rate
6. Term – start date, end date, auto-renewal terms
7. Escalation – who the client contacts and how
8. Change in scope – how new feature requests are handled (usually a separate SOW)

Keep it to two pages. A support contract that runs to ten pages doesn’t get signed; it gets sent to the client’s lawyer and dies there.

The goal is an agreement that both sides read before signing and then never need to consult again, because the expectations are clear and the relationship works.