Agency support SLAs: response times you can keep

A support SLA you can keep promises a fast first reply, not a fast fix, and it only counts time inside your business hours. Define three or four priorities with concrete examples, give each one a first-reply target your smallest realistic team can hit on a bad week, and treat resolution times as goals rather than guarantees. Then route every request to an owner, warn people before a target is missed, and report the results to the client every month.

#Why most agency SLAs fail

Agencies often write their first SLA during a sales call. Someone says "within an hour", and that sentence ends up in the agreement. Months later the one developer who knows the site is on holiday, a form breaks on a Saturday, and the promise is broken.

The problem is rarely effort. The SLA was written for the best week, not the normal one. A good SLA promises a little less than you usually deliver, so you deliver it every time.

#First reply vs resolution

These are two different promises, and mixing them up is the most common mistake.

• First reply is the time from the client raising a request to a real person acknowledging it, confirming what they understand, and saying what happens next. You control this almost completely.
• Resolution is the time until the problem is actually fixed. You control this only partly. It depends on the bug, on third-party hosting or plugins, and often on the client sending a login or approving a change.

Commit firmly to first reply. For resolution, use honest wording such as "we aim to resolve". A first reply also has to be useful. "Thanks, received" does not count. "I can see checkout fails on mobile Safari. I'm checking it now and will update you by 2pm" does.

#Define priorities with real examples

Priorities only work if the client and your team classify things the same way. Abstract labels invite arguments; examples settle them. Four levels are enough.

Urgent

The live site or app is down, or a core business function is broken for everyone. Examples: the website returns an error page, checkout fails for all customers, or the site has been hacked.

High

Something important is broken, but there is a workaround or only some users are affected. Examples: checkout fails on one browser, or a key landing page is broken on mobile.

Normal

A defect that is annoying but not costing the client money today. Examples: a typo on a product page, a slow image, a footer link pointing to the wrong page.

Low

Questions and small requests with no deadline. Examples: "How do I add a user to the CMS?" or "Can you send last month's analytics export?"

Agree who sets the priority. Usually the client suggests one and your team confirms or adjusts it in the first reply, with a one-line reason. That stops every request becoming urgent.

#Business hours and time zones

State your support hours explicitly, with a time zone, and say that targets are measured in business hours. "First reply within 4 business hours, Monday to Friday, 9am to 6pm UK time" is clear. "Within 4 hours" is not, because a request sent at 5:30pm on Friday would be due before most people wake up on Saturday.

Decide what happens outside those hours. Most agencies pick one of three options:

1. No out-of-hours cover. Everything waits until the next business day. Fine for brochure sites.
2. Urgent only. One person is on call for Urgent issues, with a longer target. Price this in.
3. Extended cover for a fee. A higher tier with weekend hours for clients who trade on weekends.

List public holidays too, or at least say "excluding UK public holidays".

#A sample SLA table by priority

A starting point for a small agency on a standard plan. Adjust to your team, then cut a little more.

The Urgent row promises a plan, not a fix. You cannot guarantee a hosting provider restores a server in four hours, but you can guarantee the client knows what is happening.

The Updates column matters too. Clients get anxious in silence, and regular updates prevent most "any news?" follow-ups.

#How to word it in the agreement

Put the SLA in an appendix to your support agreement, so you can update it without rewriting the contract. Keep the language plain:

Decide these before you sign:

• What happens when you miss. Some agencies offer a service credit, others commit to a review meeting. If you offer credits, cap them, and tie them to first-reply targets only.
• Client obligations. Clients should raise requests through the agreed channel, include enough detail to reproduce the issue, and provide access when asked. The clock can reasonably pause while you wait on them.
• Channel. Say where requests must go. A request sent by text to your designer at 10pm should not start the clock.

This is general guidance, not legal advice. Have a lawyer review any clause that involves credits or liability.

#Route every request to the right team

An SLA is only as fast as the time it takes a request to reach someone who can act on it. Requests in a shared inbox wait while everyone assumes someone else has them.

Give every request three things as soon as it arrives:

• An owner. One named person responsible for the reply and for keeping the client updated, even if others do the work.
• A team. Hosting issues go to development, copy changes to content. Each team can have its own targets and working hours if, say, your developers work in another time zone.
• A priority. Confirmed by your team, not just suggested by the client.

When a request needs real work, link it to a task on the right team's board rather than copying it into a new place. The client keeps talking to the owner, the team works from their usual board, and the request can close when the linked work is done.

#Escalation that happens before the miss

Escalation should start before a target is broken, not after. A simple rule set works well:

1. Warning. When a request is close to its first-reply target, the owner gets a reminder.
2. Missed. If the target passes, the team lead is told, so they can reassign or step in.
3. Repeated misses. If the same client or team misses targets several times in a month, it goes on the agenda for your weekly operations meeting.

Give the client an escalation contact too, usually the account manager, so they know who to call if an Urgent issue feels stuck.

#Ticket or change request?

Support plans are often swallowed by work that was never support. Draw the line in writing.

A ticket is something that used to work and now does not, a question about how to use what you delivered, or a small maintenance task listed in the plan (plugin updates, minor content edits). A change request is anything new: a new page, a new feature, a redesign of a section, a new integration.

When a ticket turns out to be a change request, say so kindly and early: "This is a new feature rather than a fix, so I'll send a quick quote today." Our guide to stopping scope creep has more scripts for these conversations, and retainer vs fixed price helps you decide how ongoing work should be billed.

#Measure and report

You cannot keep a promise you do not measure. Track a few numbers per client and per team each month:

• First-reply target met, as a share of all tickets, split by priority.
• Median first-reply time, to see whether you are comfortably inside the target.
• Tickets resolved and the oldest ticket still open.
• Hours used against the plan, if the client has a support hours bundle or monthly plan.

Send the client a short monthly report: requests received, how many met the target, anything missed and why, and what you changed. Admitting one miss and explaining the fix builds more trust than a page of green ticks.

#Ask clients how it went

Speed is only half the picture. A fast answer can still frustrate a client if it was confusing. After a ticket is resolved, ask one question: how did we do? Three options (happy, okay, unhappy) are easier to answer than a long survey.

Read every unhappy rating and reply personally. Often the cause is communication: too few updates, too much jargon, or a priority that felt wrong. Those patterns tell you what to change next.

#Questions agencies ask

What is a reasonable first-reply time for a small agency?

For most small agencies, one business hour for Urgent issues and one business day for Normal ones is achievable without dedicated support staff. The right number is the one your team can hit during a week with a holiday and a launch. Start conservative and tighten it once you have a few months of data.

Should we offer 24/7 support?

Only if the client's business genuinely needs it and you price it to cover on-call time. For most marketing sites, business-hours cover with an Urgent-only exception is enough.

Does the SLA clock pause while we wait for the client?

It should, and your agreement should say so. If you need a login, approval or more detail, the resolution clock pauses until the client replies. First-reply targets are usually not paused, because you can always acknowledge a request.

Should we offer service credits for missed targets?

Credits can reassure larger clients, but they add admin and can turn small misses into disputes. If you offer them, tie them to first-reply targets, cap them and require the client to claim them.

How often should we review the SLA?

Review it with each client at renewal, and internally every quarter. If you miss a target regularly, add capacity or change the target.

#How Bitrack helps

In Bitrack, clients raise tickets from the client portal, and each ticket gets an owner, a team, a priority and a first-reply target for that priority, with a warning before the target is missed and team leads told when it is. Teams can have their own targets and working hours, tickets can be linked to tasks on any team's board and resolve when that work is done, and saved replies and internal notes keep answers fast and consistent. After a ticket is resolved, the client can rate it Happy, Okay or Unhappy, and support hours plans track bundles and monthly hours with rollover, alerts at 75%, 90% and 100% and a monthly report. Bitrack is free to start; see tickets and response targets in the help center, or how it works.

Promise a little less, deliver it every time, and show the client the numbers.