[object Object]

A support team hits 98 percent on first-response SLA and the customer is still complaining. Resolution averages four days, but the SLA report does not measure resolution. The number on the dashboard is technically true and operationally meaningless. HubSpot supports better SLA modeling than most teams use.

Two clocks, not one

HubSpot tracks first response and resolution as separate SLA timers. Most setups only configure response. Configure both, even if your resolution target is generous. A 4-hour first response with a 5-business-day resolution gives reps a quick handshake target and customers a ceiling on how long they wait.

Priority: High
  First response: 1 hour
  Resolution: 1 business day
Priority: Medium
  First response: 4 hours
  Resolution: 3 business days
Priority: Low
  First response: 1 business day
  Resolution: 5 business days

Business hours that match the customer, not you

A 9am-to-5pm Boston business hours calendar applied to a global SaaS product breaks the SLA the moment a Sydney customer files at 8pm Sydney. Set business hours per team or per customer segment:

  • Global product, regional teams: business hours follow the assigned team
  • Enterprise plan: 24x7 calendar, separate priority levels
  • SMB plan: 24x5 calendar covering business days across regions

Configure under Settings > Objects > Tickets > SLA & business hours. Apply via ticket pipeline or via routing logic that picks the right calendar.

Pause reasons matter

A ticket waiting on customer reply should not burn SLA time. HubSpot supports SLA pause when a ticket status enters a configured “waiting on customer” state. Without pause logic, your resolution SLA includes time you cannot control and you optimize for the wrong thing.

Status: Waiting on customer  -> SLA paused
Status: Waiting on engineering -> SLA paused (configurable)
Status: In progress           -> SLA running
Status: Resolved              -> SLA stopped

Configure status mapping under SLA settings. Audit pause usage monthly so reps do not mark tickets “waiting on customer” to game the metric.

Escalation ladders that reach a human

A breach notification in Slack to a channel nobody watches is not an escalation. Build a ladder:

// Workflow custom code on SLA breach
const ticket = event.inputFields;
const breachLevel = ticket.sla_breach_count || 0;
const escalation = [
  { delay: 0, target: ticket.owner_email, channel: "email" },
  { delay: 30, target: ticket.team_lead_email, channel: "slack_dm" },
  { delay: 60, target: ticket.manager_email, channel: "slack_dm" },
  { delay: 120, target: "[email protected]", channel: "page" }
][breachLevel];
await sendEscalation(escalation, ticket.id);
return { outputFields: { escalated: true } };

Pages the right person at each tier and stops escalating once a human has acknowledged.

Report on what customers feel, not what fires

A “SLA met” report at 95 percent feels great but hides the worst tickets. Add two complementary reports:

  • Time-to-resolution histogram (p50, p90, p99)
  • Customer-effort score on resolved tickets, joined with SLA breach flag

A breach correlated with high effort is the ticket your CSM hears about first. Surface those weekly to the team lead, not just the breach count.

Multi-touch tickets

A ticket bouncing between three teams burns first-response SLA at the first touch and resolution SLA across the full path. Add a last_team_response_at custom property and report on team-level handoff times. The bottleneck team is rarely the team that owns the ticket at close.

What to do this week

Audit your current SLA configuration for response-only setups, add resolution timers per priority, validate business hours match where customers actually live, and confirm pause-reason logic before next month’s customer review.

[object Object]
Share