How to Set Up SLAs in HubSpot Service Hub

Before you touch the SLA feature

HubSpot's Service Hub makes turning on SLAs trivially easy — a target time, a pipeline, done. That ease is exactly the trap. The feature will enforce whatever you tell it, including a badly-designed promise, just as efficiently as a good one.

A real setup starts before the feature does: with four decisions, made in order. Skip the order and the result is a well-automated guess.

Decision 1: what actually earns urgency

Before any target time exists, something has to decide which tickets deserve one hour and which deserve two days. The common shortcut — let whoever's triaging pick P1, P2 or P3 by feel — is where most SLA setups quietly fail, because that judgment call drifts by person and by day.

The fix is a single computed severity property, built from three inputs: Impact (what's affected), Scope (how much of it), and Urgency (how badly). Score each combination once, rank them highest-first, and priority stops being an opinion — it becomes an output.

If two people can look at the same ticket and reasonably disagree on its priority, the priority logic isn't finished yet.

Decision 2: two clocks, not one

A single SLA property can only track one promise. Most support teams are actually making two: how fast someone will hear back, and how fast the problem gets resolved. Blend them into one clock and you end up measuring neither accurately.

Set these up as two separate SLA properties — a first-response target (often a flat window regardless of priority, since acknowledgment shouldn't wait on triage) and a resolution target that reasonably differs by the severity computed in Decision 1: hours for the most severe tickets, days for the least.

Decision 3: where the clock actually applies

An SLA property is only enforceable once it's attached to the pipeline stages that represent real waiting time — not every stage, and not stages that represent work already handed off elsewhere. A ticket sitting in a "waiting on customer" stage shouldn't burn down the same clock as one sitting untouched in a support queue.

Get this mapping wrong and the SLA report starts lying in a specific, quiet way: breaches get logged for time nobody could have controlled, and the report stops being trusted for exactly the reason it was supposed to fix.

Decision 4: what happens before the deadline, not after

A target time and a report of misses is the minimum viable version — and also the version most teams stop at. It tells you what already went wrong. It doesn't help anyone act while there's still time to.

That's a separate, deliberate workflow — one that watches the clock and escalates before the target time is reached, not after. It's substantial enough to deserve its own walkthrough, since escalation done carelessly creates a different problem: alert fatigue that gets ignored by the third notification.

What this looks like, running

Built through these four decisions in order, a real SLA system in HubSpot ends up looking like this:

The full build, including why most SLA setups fail before they get this far, is in the case study.

Before you go live

If any of these is missing, the feature is on — the system isn't built yet.