# How to set support SLAs for a small B2B SaaS team (with starting numbers)

A support SLA for a small B2B SaaS team only needs three numbers per priority: how fast the first reply goes out, how fast each later reply follows, and how long until the problem is solved. Set them in working hours for replies and calendar time for resolution, keep them internal until they have held for a few months, and only then promise a looser version to customers.

Below are starting numbers you can copy, the reasoning behind each, and where SLA policies sit on common helpdesk plans.

## The three clocks worth setting

**First response.** Time from a new ticket arriving to the first human reply. This is the number customers notice first, because it tells them someone has picked it up. An automatic acknowledgement is useful, but it shouldn't stop this clock (more on that below).

**Next response.** Time from the customer's latest message to your next reply. This is the clock that catches tickets which got a quick first answer and then went quiet for three days. Without it, a first-response target can look healthy while customers wait.

**Resolution.** Time from the ticket opening to the problem being fixed or answered. Customers live in calendar time, so measure this one in calendar time too. A ticket opened on Friday afternoon and fixed on Monday morning took three days from the customer's side, whatever the rota said.

### Auto-acknowledgements don't count as a first response

An automatic "we've got your ticket" message is worth sending. It tells the customer the message arrived and sets expectations. But it isn't a response, and your first-response clock shouldn't treat it as one:

- **The customer still hasn't heard from a person.** A receipt doesn't answer their question or show anyone has read it. If the clock stops at the acknowledgement, your report says "answered in 30 seconds" while the customer is still waiting.
- **It hides the number you need.** Every ticket gets an instant auto-reply, so a first-response target measured that way is always met, and it stops telling you anything about how the team is doing.
- **How to set it up:** check what your helpdesk counts as a first response. Exclude automated messages, whether rule-based or AI, and stop the clock only on the first reply a person on your team sends. If your tool can't tell the two apart, turn off the auto-reply's effect on SLAs or track first response manually for a month to see the real figure.
- **Say what happens next in the acknowledgement.** A line like "a person on the team will reply within one working day" turns the receipt into a promise you're measuring.

Both response clocks should pause while you are waiting on the customer, for example after you have asked for a log file. Keep the real elapsed time visible alongside the paused figure, so a ticket that sat in "waiting on customer" for a week still shows up as old.

## Starting targets by priority

These are our suggested starting points for a team of a few people covering one region's working hours. They are not an industry benchmark. Adjust them after a month of real tickets.

| Priority | What it means | First response | Next response | Resolution |
| --- | --- | --- | --- | --- |
| Urgent | The product is down or a customer is blocked from their core job | 1 working hour | 2 working hours | Linked to the incident; no separate target |
| High | Something important is broken and there's no workaround | 4 working hours | 8 working hours | 3 calendar days |
| Normal | A bug with a workaround, or a how-to question | 1 working day | 1 working day | 7 calendar days |
| Low | Feature requests, feedback, nice-to-haves | 2 working days | 2 working days | No target; close or move to the roadmap |

A few notes on the table:

- **Urgent tickets usually belong to an incident.** If the product is down for one customer, it's often down for several. Link the ticket to the incident and let the incident's update cadence drive the replies, rather than racing a separate ticket clock.
- **Low has no resolution target on purpose.** A feature request isn't late because it hasn't shipped. Reply, log it where customers can follow it, and close the ticket.
- **Fewer priorities beat more.** Four levels are enough to start. Each extra level is another judgement call on every ticket.

## Working hours or the full clock?

Response targets should count the hours your team actually keeps. A "4-hour first response" that keeps counting overnight just means every ticket that arrives at 6pm breaches by morning, and the target stops meaning anything.

Write the hours down: which days, which hours, which timezone. If your customers are spread across timezones and you only cover one, say so in your support policy rather than letting the target imply round-the-clock cover.

Resolution is different. Count it on the full clock, because that is how the customer experiences the wait.

## Internal targets first, contract promises later

Start with internal targets only. Track them for two or three months, see which ones you hit, then decide what to publish.

When you do publish, or when a prospect asks for a support SLA in a contract or security questionnaire, promise something looser than your internal target. If you aim for a first response in 4 working hours, a written commitment of 1 working day for high-priority tickets leaves room for a bad week without breaching a contract.

This guide isn't a legal template. If an SLA goes into a contract with service credits attached, have it reviewed like any other contract term.

## Per-plan and per-customer targets

B2B customers are companies, and a larger account may reasonably expect tighter targets than a small one. Two patterns work for a small team:

- **Per plan:** one set of targets for each pricing tier, published on the pricing page.
- **Per customer:** a default for everyone, with tighter targets for named accounts that negotiated them.

Start with one default policy. Add exceptions only when a customer asks and is paying for it, because every exception is something someone on the team has to remember.

## Where SLA policies sit on common helpdesk plans

Checked on 18 October 2026 on each vendor's pricing page. Per-seat prices are per person per month.

| Tool | SLA policies | Plan and price |
| --- | --- | --- |
| Help Scout | One basic policy on Standard; two advanced on Plus; unlimited on Pro | Standard $25 a user annually ($30 monthly); Plus $45 annually ($54 monthly) |
| Freshdesk | Multiple SLA policies from Pro | Pro $55 an agent, billed annually |
| Intercom | SLAs on Expert | Expert $132 a seat annually ($139 monthly), plus $0.99 per Fin outcome |
| StayUpfront | SLAs on every plan, including Starter (every plan gets every feature); optional and off by default, with per-customer targets | Priced by customer contacts, every teammate included; Starter from £49 a month at founding prices (£79 standard) |

SLAs are one row in choosing a helpdesk. For prices at five people and the cases where each tool is the better buy, see [the best support tool for small B2B SaaS teams, compared](https://stayupfront.com/compare/best-support-tool-small-b2b-saas).

## How StayUpfront handles SLAs

In StayUpfront, SLAs are optional and off by default, and they are an internal guardrail that customers never see. Response clocks pause when the ball is in the customer's court, and both clocks show real elapsed time alongside the credited time, so a paused clock can't hide a stale ticket. Resolution is measured on the wall clock. Una, the built-in AI, sends customers an automatic acknowledgement, but that doesn't count as the first response: the first-response clock keeps running until someone on your team replies. Targets can be set per customer account, and a ticket raised during an incident is linked to it both ways, so the reply can say what the team already knows.

SLAs come with every plan, including Starter. Every plan gets every feature, with nothing gated by tier. Every teammate is included too, so the engineer who helps with the odd ticket doesn't add a seat. [Start your free trial](https://stayupfront.com/signup) or see [how support works in StayUpfront](https://stayupfront.com/support).

## FAQ

**What is a good first response time for B2B SaaS support?**  
For a small team, 4 working hours for high-priority tickets and 1 working day for normal ones is a sensible place to start. Tighten it once you're hitting it comfortably.

**What's the difference between first response and next response?**  
First response measures the wait for the first human reply. Next response measures the wait after each customer message after that. You need both, or a ticket can get a fast first reply and then stall.

**Should an automatic acknowledgement count as the first response?**  
No. Send one, but stop the first-response clock only when a person on your team replies. Otherwise the target is always met and tells you nothing.

**Should SLA clocks pause while waiting on the customer?**  
Response clocks, yes. Keep the real elapsed time visible too, so long-paused tickets still stand out.

**Should a small team publish its support SLA?**  
Not straight away. Track internal targets for a few months, then publish a looser version you're confident of hitting.

**Do I need an SLA if we're a team of two?**  
You don't need a contract term, but an internal target helps two people agree on what "we'll get back to you soon" means.