---
title: Service requests
---

## Bakgrunn

Dette dokumentet beskriver hvordan Uninett håndterer alle henvendelser, også kjent som service requests.

Uninett vedtok i et ledervedtak 17.02.2020 at Uninett Skal ha kontroll på alle henvendelser som angår våre produksjonsatte kundethjenester. Hovedtiltaket til å kunne levere dette er at alle henvendelser regsiteres i ett felles saksbehandlingsystem for Uninett, uavhengig av hvilket team som er ansvarelig for hele eller deler av håndtering av henvendelsen.
Samtidg ble det vedtatt at Incident og Change management skulle
innføres som en tverrfaglig prosess for alle kundetjenester i Uninett. Requst service baserer seg på samme modell: ITIL

Fra ITIL:
(ITIL Service Operation) Service request er formell forespørsel fra en bruker som ønsker noe levert. Dette kan være råd eller informasjon, bytte av passord, eller bestilling av en PC for en ny bruker. Tjenesteforespørsler styres gjennom prosessen request fulfilment, vanligvis gjennom service desk. Tjenesteforespørsler kan knyttes til en endringsanmodning som en del av leveransen. (db\vs bestilling av endring)

## Betingelser for Service request /henvendelser

- Servicest request er en henvendelse
- fra eksisterende kunder
- på produkssjonsatte tjenester (inkl pilot-tjenester)
- på ferdig leverte bestillinger
- omhandler ikke bestilling, oppsigelse eller feilmelding. Disse har egen kategori, henholdsvis Order, Termination og Incident
.
- Service request har kategori "Support"

## Hensikten med å utøve felles Service request

- Hensikten med Service request er primært
- å ha en sporbar logg på sakens kjerne og fremdrift
- å ha kontroll på svartider
- å kunne måle oss selv kontnuerlig på kundetilfredshet

- Sekundært gir dette også verdi for

--- *Kunden*, da registrerte henvendelser er kilde til å kunne gjøre selve tjenestene mer brukervennlig og eventuelle behov for å forbedre publiserte brukerveiledninger, ofte stilte spørsmål osv. Dette fordi vi har
- en oversikt over hvilke tjenester som "krever" ulik mengde support
- en oversikt over hvilke type henvendelser de ulike tjenstene initierer
Dette er kilde til å kunne gjøre selve tjenestene mer brukervennlig og eventuelle behov for å forbedre publiserte brukerveiledninger, ofte stilte spørsmål osv.

--- *Kunden* da registrerte henvendelser gir mulighet til kopetanseoverføring fra 2.linje til 1.linje, slik at kunden får raskere svar og 2.linje frigjøres til de "vasnekelige" prblemstillingene og produktutvikling

--- *Ressursstyring* da registrerte henvendelser gir team-lederer en god oversikt over temets arbeidsbelasning og kan sammen med teamet sette prioritet på henvendelsene

## Framgangsmåte

1. #### Loggføre service request
- Loggføre henvendelsen i felles saksbehandlingssystem, Request Tracker
- Sørge for riktig kategorisering og evt. delegering til riktig produkt-team i henhold til driftsinstruks for kundetjenesten
- Felter som må fylles ut i saken
- **kundetjeneste** = kundetjenesten henvendelsen gjelder. F. eks. (`Identitet_Feide`)
- **kategori** = **support**
- **description** = nøkkelord på hva henvendelse gjelder
- **RT- kø** = Produkt-team som skal behandle henvendelse. F. eks. (`campus-saker`)

2. #### Respondere på service request (request fulfilment)
- Alle henvendelser til 1.linje gir automatisk initiell respons med saksnummer [se autosvar her](https://interndocs.uninett.no/docs/servicecenter/request-tracker#autosvarmanuelt-svar-til-k%C3%B8-orakeldrifthostmaster)
- All kommunikasjon med kunde skal loggføres som en "oppdatering" i saken. Skriftlig kommunikasjon skal skje via saken. Benytt funksjonen "Svar" i siste mottatte mail fra innmelder
- Dersom man avventer mer informasjon fra innmelder, sett status= stoppet opp, og noter i description hva man venter på og når man igjen følger opp denne saken
- Forespørsel om endringer som godkjennes, leveres i undersak(er) via 1 eller flere saker med kategori change. [Les om Change](https://interndocs.uninett.no/docs/change-control/index)

3. #### Lukke service request
Når man sender endelig svar i saken
- **Status** = **løst**
- **Solution** = **Oppsummer svar/løsning gitt til innmelder**. Denne skal gir en riktig og presis oppsummering på hva som ble svart ut /sent til innmelder. Legger alltid inn v den som svarer ut saken, umiddelbart etter at saken er besvart. informasjon presenteres i ulike rapporter til prduktansvarlig og ledere og benyttes til kunnskapsoverføring og kunnskapsheving fra 2. linje til 1.linje

MERK: Dette er viktig at dette utføres umiddelbart av den som løser saken, slik at USC kan sende ut invitasjon til kontinuerlig feedback ca maks 2 timer etter at svaret er gitt innmelder

## Roller og ansvar

### 1. linje - Uninett Servicesenteret
- Minimum "punkt 1 Loggføre" under "Fremmgangsmåte"
- Dersom punkt 2 "Respondere" er delegert fra 2 .linje til USC, er dette beskrevet i [https://interndocs.uninett.no/docs/servicecenter/](https://interndocs.uninett.no/docs/servicecenter/)

### 2. linje - Produkt-team
2-linje inkluderer både systemeksperter for tjenesten, salgs-teamet og økonomi-teamet

- Dersom punkt 2 "Respondere" under "Fremmgangsmåte/Loggføre" ikke er delegert fra 2 .linje til USC, dvs er IKKE beskrevet i [https://interndocs.uninett.no/docs/servicecenter/](https://interndocs.uninett.no/docs/servicecenter/), har 2 linje ansvar for punkt 2 og 3
- MERK: **Dersom 2 linje er den som først mottar henvendelsen** har de også ansvar for "punkt 1 Loggføre" under "Fremmgangsmåte"
Regsiter saken manuelt i Request Tracker, husk å legg til rett innmelder. Må alltid utføres ved telefonhenvendelser.
E-poster kan videresendes den til [e-mail], merk da e-posten med at dette er en videresending slik at USC oppdaterer med rett "innmelder" og sender saksnummer til "innmelder"

## Oversikt over registrerte- og pågående supportsaker siste 100 dager
[Link til dashboard i RT](https://rt.uninett.no/Dashboards/147426/%C3%85pne%20Supportsaker%20mottatt%20de%20siste%20100%20dager)
Sakene du ser her er gruppert på kundetjeneste og tidspunkt de ble opprettet
- Kategori=support
- Status= open, ny og stoppet opp

Hvert team har eller bør i tillegg ha eget dashboard for å følge de henvendelser som er delegert til sitt team. Dashboard må opprettes sammen med team USC slik at de opprettes "rett" med tanke på hvordan 1 .linje registererer sakene.
Hvert team bør ha en daglig gjennomgang av sitt Dashboard for å sikre at kunder får svar så raskt som mulig. Saker deleres til ansvarlig ved å sette navn i feltet "owner".

Mottatt sak som ditt team ikke ikke har ansvar for?
- Sakssansvarlig/owner må tilhøre den RT-kø som er satt. Om det er et annet team som skal ha saken, skal saken settes tilbake til RT-kø "Orakel". Dette fordi 1.linje skal kunne oppdatere sine rutiner og sette tilsvarende saker rett neste gang.

## Spørsmål eller innspill til servicest request /support ?

Ta kontakt med prosessansvarlige i [felles teamskanal](https://teams.microsoft.com/l/channel/19%3a4e467098c1434856894a148b362cf8a8%40thread.tacv2/Change%252C%2520Incident%252C%2520Problem%2520og%2520Request?groupId=fb37d29c-82e3-4a39-996f-16cbdefcfec6&tenantId=68763e3d-4615-4222-988f-90ba13e351e9)