Hva er service level agreement (SLA)?

SLA-bilde-bloggSLA er en avtale mellom en som tilbyr en service og kunden. Avtalen sier noe om hva som omfattes av tjenesten når det gjelder kvalitet, tilgjengelighet og ansvar. Vi har skrevet om hva vi mener skal være med når det gjelder nettsider og nettbutikk.

Hvorfor skal jeg bry meg om å ha en SLA?

La oss tenke oss at du har akkurat publisert ny nettside. Det går en måned, så oppdager du en graverende feil på nettsiden. All informasjonen om dine produkter og tjenester er borte, og du klarer ikke finne ut av det på egenhånd.

Hvis du ikke har en SLA som sier noe om:

  • hvordan skal du rapportere feil på løsningen
  • hva er grunnlaget for å si at det er en kritisk feil
  • hvor lang tid tar det å rette
  • hvem er ansvarlig for å rette
  • hvordan kan jeg være informert om progresjon av rettelsen

så har du et problem. Eller kanskje du har en leverandør som alltid er tilgjengelig og hiver seg rundt med en gang du melder et problem? Da er du i såfall heldig og antagelig i mindretall.

Hvilke krav bør du stille til en leverandør når det gjelder SLA?

Man bør skille mellom to ting:

  1. Det som påvirker kunden/brukerne direkte og som har en påvirkning på forretningen. F eks at ingen kan bestille varer hos deg, eller at nettsiden din ikke er tilgjengelig.
  2. Det som påvirker daglig drift, men ikke nødvendigvis fratar kundene/brukerne mulighet til å gjøre forretning med firmaet ditt.

Det er også vanlig å skille mellom frontend (selve nettsiden og det kunden/brukerne dine ser) og backend (det verktøyet eller plattformen du bruker for å vedlikeholde nettsiden din). Det er vanlig å definere back-office som noe som aldri kan ha en kritisk feil. Men det finnes unntak. 

Det er vanlig å dele inn feil i tre nivåer

  • Kritisk
  • Alvorlig
  • Ikke alvorlig

Kritisk

Hva er kritiske feil?
Kritiske feil medfører alltid forretningsmessige konsekvenser for deg. Kan f eks være at man ikke får gjennomført handel i nettbutikken. Eller at hele seksjonen med produkter eller tjenester er borte.

Hvordan bør de håndteres?
Feilsøking bør starte umiddelbart og løses innen samme dag. Alternativet er at man har funnet ut hva feilen er og hvordan det skal løses. Det er laget en workaround i påvente av neste release.

Alvorlig

Hva er en alvorlig feil?
Fortsatt viktig, men ingen forretningsmessig konsekvens. Kan f eks være at det ikke er mulig å se sine ordre i nettbutikken, eller at deler av innholdet ikke er tilgjengelig men man kan fortsatt utføre aktivitet som støtter forretningsdriften.

Hvordan bør de håndteres?
Feilsøking skal starte innenfor én virkedag og må løses innen to virkedager. Alternativet er at man har funnet ut hva feilen er og hvordan det skal løses. Det er laget en workaround i påvente av en nødvendig release.

Ikke alvorlig

Hva er en ikke alvorlig feil?
Har ikke stor betydning. Kan være et bilde som ikke vises, eller en tekst som er plassert utenfor rammen av der innholdet skal være.

Hvordan bør de håndteres?
Skal være løse innen fem virkedager. Alternativet er at man har funnet ut hva feilen er og hvordan det skal løses. Det er laget en workaround i påvente av en nødvendig release.

Hvor passer Back office inn i dette?

Vanligvis vil feil i Back office falle innunder Alvorlig eller Ikke alvorlig. Det er svært sjelden at problemer med Back office kan kategoriseres som Kritisk. Et eksempel hvor dette kan være unntaket er hvis det f eks ligger feil priser på produkt i nettbutikk, og du ikke får korrigert det i Back office. Da er det en feil som påvirker det forretningsmessige, og løsningen vil være å få tilgang til Back office for å publisere riktig informasjon.

Hvem er ansvarlig for å løse problemet?

I en SLA skal det alltid være definert hvem som deltar i support-rollen. Vanligvis er en support-process delt opp på følgende måte:

  1. Førstelinje support håndteres av ett team. De er ansvarlig for å sjekke at problemet eksisterer, at det samsvarer med nivået hendelsen er rapportert innunder: Kritisk, Alvorlig og Ikke alvorlig. Hvis de ikke kan løse problemet delegerer de hendelsen til neste nivå.
  2. Andrelinje support. Har gjerne litt mer teknisk kompetanse og tilgang enn førstelinje. De sjekker om de kan løse problemet. Hvis problemet krever en programvareendring i form av en ny release blir ofte hendelsen delegert til neste nivå.
  3. Tredjelinje support er ofte programmere. Disse er også ofte de samme som står for ny utvikling og er ansvarlig for releaser med testing. 

Denne prosessen kan høres omfattende ut. Men den passer veldig ofte inn. I mindre selskaper kan det være samme team som er involvert flere steder.

Hvordan kan jeg sikre meg at jeg får en SLA avtale med min leverandør?

Vi har laget en kravspesifikasjon for SLA som du kan sende til din leverandør og be om en tilbakemelding på hvordan det fungerer hos de.

Last ned vår SLA-mal helt gratis!

 

 

 

Kjersti Bakke blog-avatar

Kjersti Bakke

Jobber som senior rådgiver. Har mer enn 20 års erfaring innen webdesign, webutvikling og SEO/SEM. Sertifisert i HubSpot innen CMS, marketing, salg, service i tillegg til partner-sertifisering. Jeg er Dikom sin rådgiver innen analyse og rapportering og har sertifisering i Google Analytics og Google Ads. Har flere års erfaring fra elektrobransjen som selger, Program Deployment Manager og Network of Excellence Manager. Her med ansvar for å lede et internasjonalt nettverk med webredaktører.