Hvad er en SLA i HubSpot? Svartider, regler og priser

Sådan virker SLA-mål i HubSpot

SLA-mål hører hjemme i help desk-arbejdsområdet, ikke i conversations inbox. Den skelnen er vigtig, hvis I har læst en ældre vejledning: HubSpots dokumentation slår fast, at konti oprettet efter den 1. april 2024 ikke kan sætte SLA'er i conversations inbox, og at opsætningen i stedet foregår i help desk. Har I en ældre konto med SLA'er liggende i indbakken, virker de stadig, men al ny opsætning bør ske det nye sted, så I ikke ender med to sæt regler, der måler forskelligt.

De tre måletyper dækker hver sin del af forløbet. Time to first reply måler tiden fra ticketten oprettes til første svar går ud. Time to next reply måler tiden på hvert efterfølgende svar, og det er den, der fanger de sager, hvor første svar kom hurtigt, men sagen derefter blev liggende i fjorten dage. Time to close måler hele sagens levetid. HubSpots dokumentation for SLA-mål i help desk beskriver alle tre og de betingelser, de kan sættes på.

Reglerne matcher oppefra og ned. En regel kan gælde alle tickets, den kan gælde tickets, der matcher én property som priority, team, source eller pipeline, eller den kan kombinere flere properties, hvilket kræver Enterprise. Har I flere regler, trækker I dem i den rækkefølge, de skal evalueres i. Det betyder, at en bred regel placeret øverst spiser de tickets, jeres snævre regel var tænkt til.

Priority er den property, de fleste bygger deres regler på, og det er også her opsætningen oftest går galt. Feltet er tomt som udgangspunkt, og en ticket uden priority matcher ikke en regel, der filtrerer på priority. Enten sætter I priority automatisk med en workflow ved oprettelsen, eller også skal jeres agenter sætte den manuelt, før uret overhovedet begynder at tælle. Vi anbefaler det første, fordi det andet fejler på en travl mandag.

Uret kan sættes på pause. I kan vælge kombinationer af pipeline og ticketstatus, der midlertidigt stopper tælleren, typisk en status i stil med Venter på kunde. Når ticketten forlader den status, fortsætter uret automatisk. Uden den opsætning bliver alle jeres målinger på sager, hvor kunden selv er langsom, ubrugelige, og det er et af de få steder, hvor HubSpot faktisk giver jer den kontrol, ITSM-værktøjer plejer at have patent på.

Driftstid er næste valg. En SLA kan køre i døgndrift eller kun inden for de tider, I definerer, med tidszone. Her ligger den største enkeltbegrænsning for danske teams: HubSpots vejledning om SLA'er i indbakken skriver direkte, at helligdage ikke tælles med, når driftstiden beregnes, og den model er den samme i help desk. En ticket, der lander skærtorsdag eftermiddag, bliver målt hen over hele påsken, og det samme sker mellem jul og nytår. I kan lukke driftstiden ned for de dage manuelt, men der findes ingen dansk helligdagskalender at abonnere på.

Når reglerne er sat, opretter HubSpot fire properties på ticket-objektet: Time to Close SLA Due Date, Time to Close SLA Ticket Status, Time to First Response SLA Due Date og Time to First Response SLA Status. De er almindelige properties, hvilket er hele pointen. I kan filtrere på dem i en visning, sortere jeres kø efter dem, bygge rapporter på dem og trigge automatisering på dem. HubSpots rapportbibliotek har færdige SLA-rapporter, som I finder ved at søge på sla.

Notifikationer kommer ikke af sig selv. HubSpot viser status som aktiv, forfalder snart eller overskredet inde i help desk, men vil I have en besked ud til et menneske, skal I bygge en ticket-baseret workflow med SLA-status-propertyen som tilmeldingstrigger. Derfra kan I sende intern e-mail, en notifikation i HubSpot eller en besked i Slack. Grænsen for, hvor tidligt etiketten forfalder snart dukker op, sætter I selv.

En begrænsning, der er let at overse: en SLA gælder kun samtaler, der har en ticket knyttet til sig. Kører jeres chat eller fælles indbakke uden automatisk ticketoprettelse, måler I ingenting på de henvendelser, uanset hvor mange regler I har lavet. En ticket, som en agent selv opretter uden en samtale bag sig, har heller ikke noget første svar at måle på. Tjek den opsætning først, hvis tallene ser mistænkeligt pæne ud.

Endelig er der forskel på SLA-propertierne og HubSpots gamle standardfelter for svartid. Standardfeltet for tid til lukning tæller kalendertid fra oprettelse til lukning, og den adfærd kan I ikke ændre. Rapporterer I på det felt i stedet for på SLA-status, ser en ticket åbnet fredag kl. 17 og lukket mandag kl. 9 ud som 64 timer, også selv om jeres SLA er overholdt til punkt og prikke. Brug SLA-propertierne, når I rapporterer på aftalte svartider, og gem standardfelterne til intern nysgerrighed.

Skal jeres svartider måles, før I lover dem væk? Vi sætter SLA-mål op i jeres help desk, bygger prioriteringen og pausereglerne, så tallene bliver retvisende, og laver de workflows, der giver besked, mens der stadig er tid til at nå det. Vi siger også til, hvis jeres volumen ikke bærer et løft fra Starter til Professional, og hvad I så kan gøre i stedet.

Hvad danske B2B-teams bruger SLA'er til

SLA-mål giver først værdi, når de er koblet til noget, I faktisk har lovet nogen. Her er de opsætninger, vi oftest bygger for danske virksomheder, og hvad de løser.

Differentierede svartider efter kundeaftale
I sætter en regel pr. serviceniveau og styrer den på en property, typisk priority eller en egen property som Supportniveau, der arves fra virksomheden. En dansk softwarevirksomhed med guld-, sølv- og bronzeaftaler giver guldkunder to timer til første svar i arbejdstiden og bronzekunder en arbejdsdag. Ingen skal slå aftalen op undervejs.

Eskalering før bruddet, ikke bagefter
Grænsen for forfalder snart sættes til for eksempel 30 minutter før fristen, og en workflow sender en Slack-besked til teamlederen på det tidspunkt. En teknisk grossist med to supportmedarbejdere bruger det som sikkerhedsnet, når den ene er ude hos en kunde: beskeden kommer, mens der stadig er tid til at handle.

Dokumentation til kontraktforhandlingen
SLA-status er en almindelig property, så den kan indgå i en rapport på et dashboard og sendes som en fast månedlig rapport. Vi bygger typisk rapporten som et fast dashboard, der følger med kvartalsrapporteringen. Så står tallet der, når kunden spørger.

Prioritering af dagens kø
I help desk kan listen sorteres på SLA-forfaldsdato, og en gemt visning kan vise alle tickets, der forfalder i dag. Et firepersoners supportteam i en produktionsvirksomhed starter dagen i den visning frem for i den nyeste ticket øverst, hvilket flytter fokus fra det, der råber højest, til det, der først bryder aftalen.

Adskilte krav på forskellige pipelines
Kører I både kundesupport og for eksempel interne IT-henvendelser i help desk, sætter I en regel pr. pipeline. En virksomhed med 120 ansatte giver eksterne kunder fire timer og interne kolleger en arbejdsdag, så de to køer ikke konkurrerer om den samme opmærksomhed på samme vilkår.

Synlighed på de sager, der går i stå
Time to next reply fanger den klassiske situation, hvor svaret kom hurtigt, og sagen så døde. Hos en af vores kunder afslørede den måletype en stak åbne tickets, der ikke havde fået svar i over ti dage, selv om alle første svar lå pænt inden for fristen.

Bemanding og vagtplan
Driftstiden i SLA-opsætningen er samtidig en beslutning om, hvad I lover. Skal svarfristen gælde fra kl. 8 eller kl. 9, og hvad sker der i uge 29, hvor halvdelen af teamet holder ferie? Flere af vores kunder kører bevidst en bredere frist i sommermånederne frem for at bryde en frist, de ikke kan holde.

Fælles for opsætningerne er, at SLA'en ikke løser bemandingen. Den gør problemet synligt hurtigere, og den flytter diskussionen fra fornemmelser til tal. Er svaret på de tal, at I mangler en medarbejder, siger SLA'en det bare tydeligere end før.

Alternativer, priser og begrænsninger

SLA-styring er ikke enestående for HubSpot. Spørgsmålet er næsten altid, om I vil have svartiderne til at bo samme sted som resten af kundedataene, eller om I vil have et dedikeret supportværktøj og leve med en integration. Fire værktøjer går igen, når danske virksomheder holder HubSpot op mod noget andet, og et femte alternativ ligger inde i HubSpot selv.

Zendesk Suite
Det mest udbredte dedikerede supportværktøj, bygget op om supportsagen frem for om kunderelationen. SLA-politikker, escalation og driftstid er kernefunktionalitet og gennemarbejdet. Til gengæld har I to systemer at holde synkroniseret, hvis salget sidder i HubSpot. Pr. september 2026 koster Zendesks prisplaner 55 USD pr. agent pr. måned for Suite Team og 115 USD for Suite Professional ved årlig betaling, mens Enterprise kræver en samtale med en sælger.

Freshdesk
Freshworks' supportplatform ligger prismæssigt under Zendesk og har flere SLA-politikker fra Pro-niveauet. Pr. september 2026 oplyser Freshdesks prisside 19 USD pr. agent pr. måned for Growth, 55 USD for Pro og 89 USD for Enterprise ved årlig betaling. Svagheden er den samme som ved Zendesk: kundedata og salgsdata ender to steder, og jeres Service Hub-rapportering bliver et sammenklip.

Jira Service Management
Atlassians ITSM-værktøj er det stærkeste af de fire på ren SLA-mekanik, med flere mål pr. sag, kalenderstyring og betingelser, der starter og stopper uret. SLA-funktionaliteten kræver Standard eller højere, mens gratisniveauet med op til tre agenter kun rækker til at teste selve ticketflowet. Pr. september 2026 lyder Atlassians prisside på 0 USD for Free, 20 USD pr. agent pr. måned for Standard og 51,42 USD for Premium. Passer dårligt, hvis jeres henvendelser er kommercielle frem for tekniske.

Salesforce Service Cloud
Salesforce løser det samme med entitlements og milestones, som er kraftigere og væsentligt tungere at sætte op. Pr. september 2026 angiver Salesforces prisside for Service Cloud 195 USD pr. bruger pr. måned for Core, 395 USD for Advanced og 550 USD for Max ved årlig betaling. Service contracts, entitlements og milestone-sporing findes i Core, Advanced og Max, men ikke i de billigere Starter Suite og Pro Suite. For en dansk mellemstor virksomhed er det typisk en overinvestering, medmindre Salesforce allerede er valgt til resten.

Workflows og egne properties i HubSpot
Det oversete alternativ, hvis I sidder på Starter og ikke vil op i tier. I opretter en datoproperty for svarfrist, sætter den med en workflow ud fra oprettelsestidspunktet og bygger en påmindelse på den. Etiketterne i help desk, pausefunktionen og de færdige rapporter følger ikke med. Men fristen står på ticketten, og nogen kan se den. Vi bygger den løsning jævnligt for teams med under 100 tickets om måneden, hvor springet til Professional ikke kan forsvares på SLA'en alene.

HubSpot vinder på sammenhængen. SLA-status er en property på ticket-objektet i det samme CRM som kontakten, virksomheden og dealen, og det betyder, at I kan rapportere på svartider sammen med omsætning, segmentere kunder efter overholdelse og trigge automatisering på tværs uden en integration. Hvor taber HubSpot? På selve SLA-motoren. Jira håndterer kalendere, helligdage og flere samtidige mål pr. sag bedre, og har I et driftsteam med kontraktbøder på spil, er det den ærlige anbefaling.

Så til pengene. SLA-mål følger Service Hub og kræver Professional eller Enterprise. Pr. september 2026 oplyser HubSpots prisside for Service Hub følgende ved årlig betaling: gratis for op til to brugere, 7 USD pr. sæde pr. måned for Starter, 90 USD for Professional og fra 150 USD for Enterprise. Bemærk, at månedlig betaling er dyrere, for eksempel 100 USD i stedet for 90 USD på Professional.

Oveni kommer to poster, der ofte glemmes i budgettet. Professional udløser et engangsgebyr for onboarding på 1.500 USD og Enterprise på 3.500 USD. Til gengæld følger der HubSpot Credits med: 500 på Starter, 3.000 på Professional og 5.000 på Enterprise pr. måned, som dækker forbrug af AI-funktioner og enkelte andre ydelser.

Sædemodellen betyder, at I kun betaler for de medarbejdere, der arbejder i sagerne. En kollega, der blot skal kunne slå en ticket op og læse med, kan sidde på et gratis view-only-sæde. Regn med et betalt sæde pr. supportmedarbejder og pr. teamleder, der selv besvarer henvendelser.

De hårde grænser er værd at kende, før I lover en kunde noget. Helligdage regnes ikke fra automatisk, så påske, pinse, juledagene og de lukkedage, I selv holder, skal styres manuelt i driftstiden. Svartidsmålene forudsætter en samtale på ticketten, så en ticket, en agent selv opretter, har intet første svar at måle på. Regler, der kombinerer flere ticket-properties, kræver Enterprise, så på Professional tænker I i én property ad gangen og løser resten med en beregnet property eller en workflow, der sætter et samlet felt.

På databeskyttelse er billedet til gengæld pænt for europæiske kunder. HubSpot driver et EU-datacenter i Tyskland, og HubSpots dokumentation om datacentre og hosting beskriver, at kontoen tildeles datacenter ud fra IP-adressens geografi ved oprettelsen, og at konti med Starter, Professional eller Enterprise kan få flyttet deres data til en anden region. Er jeres portal oprettet af et bureau eller en kollega på rejse, er det værd at tjekke, hvor den faktisk ligger, inden supportsager med persondata begynder at samle sig.

Implementeringen er sjældent selve SLA-opsætningen. Den tager en formiddag. Det, der tager tid, er at blive enige om, hvad der er høj prioritet, at få ticketstatusserne til at afspejle virkeligheden, så pausereglerne rammer rigtigt, og at få alle henvendelser til rent faktisk at blive til tickets. Springer I det forarbejde over, måler I noget andet end det, I tror.

Hvornår kan det så ikke betale sig? Har I under en håndfuld henvendelser om dagen, og sidder alle i samme rum, koster springet fra Starter til Professional mere, end SLA-målene giver tilbage. Det samme gælder, hvis I ikke har lovet nogen en svartid: så måler I mod en frist, I selv har fundet på, og ingen reagerer, når den brydes. Vi anbefaler først SLA'er, når der står et tal i en kontrakt eller på en hjemmeside, som nogen kan holde jer op på. Vil I se, hvordan det hænger sammen med resten af platformen, har vi samlet det på vores side om HubSpot.