Brukerveiledning for RT saksbehandlere

 
 

1) Innledning

Request Tracker (RT) er et system for å behandle henvendelser. Systemet gjør det mulig for en gruppe mennesker å håndtere henvendelser, forespørsler, feilmeldinger og lignende som kommer inn via et e-postsystem. Henvendelser og forespørsler som kommer per telefon, må saksbehandler selv registrere i RT. 

RT er et system som er utviklet for å håndtere nøkkeloppgaver som identifisering, prioritering, tildeling, løsning av saker.

 

2) Å være saksbehandler i RT

2.1) Oppretting av bruker

Dersom du er køsjef og ønsker å vite hvordan man melder inn en ny saksbehandler i din kø, se veiledning her.

Du må være definert som en bruker av systemet. Dette innebærer at du sender en henvendelse per e-post for å bli automatisk opprettet. Dette bør du ikke gjøre samme dagen som du ble opprettet som UiO-bruker, siden brukeren skal inn i en lang rekke automatiske systemer først. Vent ca. et døgn.

Send mail til general@rt.uio.no og be om å bli bruker. Like etter at du har sendt mailen, får du en mail tilbake med beskjed om at saken din er registrert. På dette tidspunktet har du fått en bruker i RT og kan logge inn med ditt vanlige UiO-brukernavn og -passord. Rettigheter i RT styres med nettgrupper. Køsjefer har mulighet til å melede personer inn/ut av disse gruppene. Fra en bruker er meldt inn i en nettgruppe kan det ta 30 minutter før denne får riktige rettigheter i RT.

2.2) Kunde kontra saksbehandler

En kunde som sender et spørsmål til en e-postadresse som er tilknyttet som kø i RT, får en tilbakemelding umiddelbart om at saken er kommet inn i køen. I denne meldingen får vedkommende tilbud om å følge med på sin egen sak.

Standard melding fra RT

Som nevnt er intensjonen at kundene (requestor) ikke skal behøve å ha noen bevissthet om RT. Kunden forholder seg bare til de tilhørende e-postadresser. Når saken avsluttes får kunden automatisk en kort standardmelding om dette, uten noen merknader fra saksbehandler.

Utover dette er det ikke automatikk for at RT sender annen informasjon til kunden. Likevel kan saksbehandleren i RT velge å sende kunden informasjon ved viktige milepæler underveis i saksbehandlingen, der dette kan tenkes å være relevant for kunden.

Alle kunder som sender henvendelser til RT opprettes automatisk som uprivilegerte brukere i RT. Enhver slik bruker kan logge seg på RT med vanlig UiO-brukernavn og passord (for eksterne er brukernavn e-postadressen og passordet tilsendt). Kunden kommer da til en egen del av RT som heter RT Self Service. På denne nettsiden får kunden innformasjon om det meste i alle sine saker, samt mulighet til å registrere nye saker i RT. For å kunne finne fram til sin egen sak må kunden vite saksnummeret.

Informasjonen er omtrent den samme som saksbehandleren får når han/hun velger å se på en enkelt sak i Display-modus.

 

Åpne saker i RT

 

Klikk på saken for å se saksgangen..

3) Navigasjon

3.1) Viktige momenter omkring navigasjon

RT benytter både sekundær og tertiær navigering for å gjøre det mulig å hoppe til nesten alle andre funksjoner som en saksbehandler trenger. Du vil derfor se at mengden linker som er tilgjengelig  forandres hele tiden, avhengig av din posisjon i RT. Minste menyen du kan finne er til venstre på bildet under: hovedmenyen.

 

 Hovedmenyen i RT

 

Under redigering av RT at a glance (kapitel 6) vil du oppleve at toppmenyen kan få en rekke sekundære og tertiære menyer, avhengig av hvor i RT du er plassert:

 

I eldre versjoner av RT, kunne man klikke seg frem til de neste nivåene av menyen - i den nyeste holder det å holde musepekeren over bestemt kategori. Legg merke til at RT indikerer neste nivå i menyen med en pil.

Ikke fall for fristelsen til å velge back på nettleseren når du arbeider i RT. Applikasjonen er lagt opp slik at du alltid skal kunne finne fornuftige valg på menyene uten å skulle behøve og gå tilbake vha nettleserens egen meny. Er du i tvil kan du alltid hoppe "helt hjem" vha menyvalget Homepage helt ute til venstre på hovedmenyen!

 

4) Vanlige oppgaver for en saksbehandler i RT

De vanligste oppgavene for saksbehandleren er:

  • Logge inn
  • Tilpasse egen velkomstside (RT at a glance)
  • Søke etter saker
  • Opprette nye sak
  • Besvare og kommentere saker
  • Modifisere en sak (f.eks. prioritet og tidsfrister)
  • Løse en sak
  • Endre egen brukerinformasjon (ut over det RT henter fra LDAP)
  • Logge ut

 

4.1) Innlogging

Både interne og eksterne brukere opprettes automatisk ved første henvendelse til RT. Interne brukere får vanlig UiO brukernavn og passord. Eksterne brukere får e-postadressen som brukernavn og får vanligvis tilsendt et generert passord. Eksterne brukere får ikke tilsendt passord dersom de blir opprettet ved bruk av CC på en sak.

 

Innlogging

 

4.2) Søkefunksjonen

4.2.1) Direkte søk

Søking i RT kan foregå fra mange posisjoner. Det første du møter på er søkefeltet oppe til høyre når du nettopp har logget deg på eller klikket på Homepage.

 

Hovedsiden

 

Dette er et fritekstsøk som gir deg muligheten til å finne saker hvor du bare vet f.eks. et ord som er nevnt under Subject eller du skriver sakens kønummer. Jo mer generelle ord du søker på jo flere treff blir det og jo vanskeligere er det å finne akkurat den saken du leter etter. Det er derfor en stor fordel jo flere ord du skriver inn i søket. Treffene på søket kommer opp i en liste der du også får se status, køens navn, eier av saken og sakens prioritet i RT (jo lenger det er siden den ble opprettet jo høyere prioritet har den i systemet). Her er et søk på tickets som inneholder ordet Houston:

 

Søk på ordet Houston i RT

 

4.2.2) Simple search

Du kan også benytte deg av simple search som er plassert under Search >> Tickets >> Simple Search.

 

Enkelt søk i RT

 

I dette søkeoppsettet foreslår RT en rekke søkekriterier som du kan søke på: 

"Search for tickets. Enter id numbers, queues by name, Owners by username and Requestors by email address. RT will look for anything else you enter in ticket bodies and attachments.
Searching the full text of every ticket can take a long time, but if you need to do it, you can search for any word in full ticket history for any word by typing fulltext:word.
RT will look for anything else you enter in ticket subjects."

 

Søket som foregår fra denne søkeruten er avhengig av syntaksen på søkekriteriene. Eksempel på dette er at hvis det forekommer en @ i søkestrengen antar RT at du søker etter en e-postlist/kø. Hvis du har et ord med små bokstaver på ca. 5-8 tegn antas det at det er et brukernavn det søkes etter osv osv.

 

4.2.3) Søketreff og lagring av søk til rutinemessig bruk

Når du har fått opp dine treff på søk har du en egen meny for valg du vil gjøre med søketreffene.

 

Søketreff

 

EDIT SEARCH sender deg til en side hvor du kan finjustere søkekriteriene. Tittelen på siden heter Query builder og kriteriene som du setter opp kan lagre til seinere. Siden antall saker og innholdet i dem øker kontinuerlig vil ett og samme søk sannsynligvis gi flere antall treff i morgen kontra idag. Det kan derfor være smart å lagre et søk som du vet du kommer til å trenge ofte. Da vil du raskt kunne finne de korrekte sakene uten å måtte tenke igjennom og bygge søket for hver gang du skal bruke det. Du kan til og med lagre søkene i egne bokser som du kan legge på din egen RT-forside (RT at a glance), slik at søketreffene kommer opp hver gang du logger deg på RT.

Query builder består hovedsaklig av to deler: Selve søket og organisering av resultater. Øverste delen hjelper deg med selve søket, og du vil se Current search feltet endre seg ettersom du oppdaterer kriteriene for søket. I nederste del av Query builder kan du angi hvordan du ønsker resultatlisten etter søket skal se ut, og spesifisere andre sorteringer enn det som er standard i din RT. Dette gjør du ved å angi hvilke kolonner som skal være med, hvilken rekkefølge og hvordan listen skal sorteres. Til slutt lønner det seg å lagre søket for senere bruk. Du kan lese mer om hvordan man oppretter enkle søk her.


Opprette søk

 

Hvis du vil finne frem til dine saker avhenger det av hvilken rolle du har i RT. Denne veiledningen henvender seg til saksbehandlere. Hvis du står som saksbehandler (owner) av én spesifikk sak kan du søke etter den ved f.eks. å angi ditt brukernavn i owner-feltet. Du får da opp alle saker hvor du er owner og kan (forhåpentligivs) bla raskt igjennom disse og kjenne igjen saken som du leter etter.

 

4.3) Gå direkte til en sak du kan ticketnummeret til

Et viktig triks å være klar over er at hvis du kan ticketnummeret (den unike koden til en enkelt sak), så kan du skrive den direkte i adressefeltet etter https://rt.uio.no/######. Da åpnes saken direkte etter at du har logget deg på. Du kan også fylle inn ticketnummeret i søkefeltet oppe til høyre i skjermbildet.

 

4.4) Opprette en ny sak inne fra RT

De fleste saker blir opprettet ved at det kommer e-post til køen fra en bruker. Du kan imidlertid, som saksbehandler, opprette nye saker mens du er inn i RT. Det gjør du ved å

  • navigere deg tilbake til din egen forside (klikk Home oppe til venstre)
  • velg hvilken kø saken skal opprettes i (øverst til høyre)
  • klikk på knappen new ticket in

 

Lag ny ticket

 

Vinduet som dukker opp ligner mye på hvordan det er så sende e-post via en nettbasert løsning.

 

Avansert bruk av lag ny ticket

Kommentarer til utfylling av new ticket in

Fyll ut feltene så nøyaktig som mulig. Hvis du bruker tid på å fylle inn korrekte og utfyllende opplysninger nå, sparer du tid senere både for deg selv og eventuelt andre som må jobbe for å få saken løst. Grensesnittet til Create a new ticket er avhengig av hvilken kø men oppretter saken i. Man vil kunne se noen små forskjeller avhengig om køen har noen custom fields eller ikke, dersom den har det - forsøk å kategorisere saken ut fra disse, så nøyaktig så mulig for å skape best mulig oversikt.

Status

Det første feltet som må fylles ut på en ny sak er status, standardverdien er new. Hvis du klikker på pilen til høyre for feltet vil du se at de alternative verdiene her er: open, stalled, resolved, rejected og deleted. Vanligvis skal du altså benytte standardverdien her. Eksempler på tilfeller hvor du skal bruke noe annet enn new som status

  • Open dersom den ikke lenger er ny, men fortsatt ikke er løst.
  • Stalled (lagt på vent eller pauset) P.g.a omstendigheter utenfor din kontroll jobbes det ikke med saken akkurat nå. Du venter kanskje på et svar eller en oppklaring fra kunden, fra en utviklingsavdeling, en driftsavdeling eller lignende.
Owner

Etter status fyller du ut Owner – her skal det stå et brukernavn for saksbehandler. Hvem har ansvar for å løse denne saken? Skriv inn hans/hennes brukernavn i feltet owner. Saker skal alltid ha en person som eier. Hvis det er vaktordninger etc. som benyttes, så skal dette styres via køene. Dersom  du har tenkt å ta saken, kan du skrive ditt brukernavn.

Merk! Hvis det ligger mange navn i Owner-listen kan det være et tips å skrive inn første bokstav i brukernavnet, så søker RT internt i listen.

Requestor

Dette feltet skal inneholde adresse til innsenderen eller kunden, altså den som skal få svaret. RT setter i dette feltet automatisk vår adresse, men ikke i alle tilfeller er det vi som spør om noe - men at vi oppretter saker på vegne av andre som f.eks har kontaktet oss personlig eller via en telefonsamtale. I slike tilfeller skal man fjerne sin egen adresse og skrive adressen til vedkommende vi har snakket med tidligere.

Viktige momenter omkring oppføring av personer i CC-feltet, og videre korrespondanse i en sak

Som du ser av skjemaet har Requestor mulighet til å skrive et navn eller en postliste i CC-feltet (kopi til). Alle som oppføres i CC-feltet blir automatisk Watcher i saken og får kopi av all videre korrespondanse. Men når det er saksbehandleren som fører opp en e-postadresse i CC-feltet vil ikke de allerede eksisterende partene i saken se at det går kopi til denne nye personen i saken. Dersom Requestor igjen sender inn en kommentar i den samme saken går det automatisk kopi til personen som saksbehandleren førte opp i CC-feltet. Requestor kan altså ikke se dette. Ved eventuelle saker som er sendt inn i RT via e-post fungerer CC-feltet tilsvarende. Vær oppmerksom på at ved saker som sendes inn via e-post blir den som står i Reply-to feltet Requestor (kunde) for saken.

Annet viktig omkring roller, saker og hvem som får se trafikken i en sak
  • Requestor og de som står angitt i CC-feltet får alle replies, men ikke comments. AdminCC får se alle replies og alle comments.
  • Det er saksbehandler som kan bestemme hvem som skal være Watcher i en sak.
  • Når man kommuniserer i RT dukker det stadig opp et CC-felt hvor du kan putte inn mottagere som du mener trenger kopi av denne ene meldingen. Dette er foregår som en enkelthendelse mottagere av disse enkeltmeldingene blir ikke fast Watcher videre i saken.
  • Subject-feltet er svært viktig. Fyll ut med beskrivende tekst og bruk små bokstaver.
  • Du ser at du også kan legge til et eller flere vedlegg. Hvis du jobber med feilhåndtering kan du for eksempel legge ved kopier av feilmeldinger som du mottar som fil som et vedlegg til saken i RT.
  • Beskrivelse av saken er også viktig og nyttig, både for saksbehandlere selv og hvis det er flere som må innom for å løse samme sak. Beskrivelsen er også viktig for mulig bruk av lukkede saker som erfaringsdata i organisasjonen. Klikk på Show details for å sette prioritet og tidsfrist på saken. Når du har fylt ut alle felt så godt du kan, klikker du på Create (langt nede til høyre) for å opprette saken. Den får nå et unikt nummer i systemet som følger saken.
  • Hver gang du sender en sak står det nederst en liste over de som får kopi av meldingen. Du kan selv fjerne en eller flere mottagere av hver eneste melding som er på vei ut.
  • Saksbehandlere kan slette mottagere av kopier i en sak for resten av saksbehandlingen
  • OBS: Saksbehandler får ikke automatisk kopi av nye meldinger i saken. RT antar at saksbehandler følger med på sine saker såpass nøye at det ikke er nødvendig med en slik melding!

 

4.5) Automatisk tilbakemelding på henvendelser

For å lage meldinger i RT som automatisk sendes ut , f.eks som en kvittering på at henvendelsen er mottatt, brukes en kombinasjon av scrips og templates i RT. Denne kvitteringen er felles for alle saker i en kø. Alle som sender inn saker får tilbake en kvittering med lenke til saken, slik at de kan følge med i saken på web. Kvitteringen sendes til den e-postadressen som står oppgitt i Requestor feltet. 

4.6) Saksgang

typisk saksgang i RT

 

 La oss ta nærmere titt på en sak. Man kan lage seg ulike oversikt over køer man har tilgang til - det hvordan f.eks RT at a glance er bygd opp er avhengig av personlige preferanser. Du kan lese mer om dette her. I skjermbilde under kan du se at helt nederst finner man sak uten eier, der står det oppført under Owner, Nobody in particular.

 

 

Etter å ha trykket på saken vi vil behandle kommer vi inn i undermenyen "Display". Denne viser sakens basale egenskaper og vi får en grei oversikt av de viktigste tingene i saken som f.eks hvem som eier saken og hvem som er innsenderen. Under metadata til saken, finner du historikken.

 

 

Nå har vi kommet stadiet hvor vi vil "ta" saken. Enkelt nok trykker man på "Take", som vist på bilde under, og saken oppdateres automatisk med deg som owner.

 

 

Når en saksbehandler med de rette rettigheter tar saken så vil den med en gang begynne å få en historikk i systemet. Saksbehandleren vil kunne skrive inn detaljer som prioritering, datofrister og lignende. Etter hvert som saken behandles og løses vil du se at f.eks. status og prioritet forandres på informasjonssiden.

  • New - Saken er ny og venter på at noen skal ta den
  • Open - Saken er tatt og venter på å bli løst
  • Resolved – saken skal bytte status til resolved når du mener den er avsluttet og lukket
  • Rejected – betyr at saken er avvist. Dette er til bruk for meldinger som ikke skal løses av saksbehandlere, f.eks spørsmål som oppfattes som usaklige eller uten relevans
  • Deleted – saken er slettet. Denne kan for eksempel brukes hvis spam-meldinger kommer inn i systemet. Saken (ticket) vil da få status inaktiv og vil ikke komme fram i søk og lignende, samt at saken vil bli slettet av en slettejobb som går jevnlig.
  • Stalled - betyr at saken, av en eller annen grunn er stoppet/satt på vent. RT har ingen direkte informasjon utover dette

Klikk på IsSpam om du er sikker på at en sak er spam. Om du er i tvil flytter du saken til køer spam-suspects og overlater resten til Houston.

RT kan også settes opp for å sende varsel om enhver statusendring automatisk. Vi har valgt å ikke bruke denne automatikken globalt, men det kan eventuelt tilføyes for de køene der det er aktuelt.

 

4.7) Endre bemanning av saker | endre eierskap til en sak

Det finnes to forskjellige fremgangsmåter for å bytte eier til en sak. Man kan enten trykke på a) Basics i saksoversikten eller b) velge Basics fra navigasjonen øverst til høyre.

 

Når man trykker på Basics vil man få opp et nytt oversikt over de grunnleggende egenskapene til saken. Derfra under Owner, vil du kunne fjerne f.eks ditt brukernavn og deretter vil du kunne skrive et annet brukernavn. Husk å lagre endringer under Save Changes.

Merk! Hvis det ligger mange navn i Owner-listen kan det være et tips å skrive inn første bokstav i brukernavnet, så søker RT internt i listen.

 

4.8) Modifisere/behandle en sak

Primært er RT er satt opp til å vise dine viktigste saker listet opp i en egen boks på førstesiden i sonen "body"

 

 

 

Klikk på den saken (ticket) du ønsker å jobbe videre med. En saksbehandler som har nok rettigheter til å jobbe med saken får opp saken og kan velge hva vedkommende vil gjøre med den.

* OPEN = Et klikk på denne linken åpner saken. Det vil si at den er åpen for saksbehandling.

* TAKE = Betyr at du tar over saken og ansvaret for å løse den. Du vil se at eier (owner) skifter fra nobody til ditt brukernavn. Vær klar over at menyen som viser hva du kan gjøre videre i saken forandres, men du finner fortsatt igjen "Comment · Reply · Resolve · Extract Article · IsSpam" ute til høyre.

Etter man har tatt saken og åpnet den får man opp diverse funksjoner. Man deler funksjonene til en sak opp i to hoveddeler. Den ene tar for seg alle funksjoner som gjelder hele saken, mens den andre tar for seg funksjoner som gjelder bare for den enkelte meldingen i saken. Først skal vi se på funksjonene for hele saken:

 

 

* COMMENT eller REPLY = Det er to måter å besvare en sak på, enten reply eller comment. Hvis du bruker reply vil alle kunne lese svaret, og det sendes e-post til requestor. Hvis du bruker comment vil ingen kunder (requestor) kunne se det. Husk å klikke "Save changes" dersom du har endret listen av mottakere. Både svar (reply) og kommentarer (comments) kommer fram hvis du som saksbehandler ser på historien til en sak. Når du er ferdig med å jobbe med meldingen må du klikke på Update Ticket for at endringene skal bli lagret i databasen.

* RESOLVE = vil si at du løser saken og at du sammen med løsningen sender en beskjed til requestor om at saken er lukket

* ISSPAM = hvis saksbehandleren ser at det er spam kan vedkommende sende den ut av systemet ved å trykke på IsSpam. Etter du har trykket IsSpam knappen vil du trolig få opp en feilmelding som bare indikerer at du ikke har tilgang til køen der IsSpam blir håndtert.

* BOOKMARK = Stjernene som kan sees både på Homepage og ved lagring av de forskjellige tickets kalles for bokmerker. For eksempel kan en markere de sakene man vil jobbe med idag, og fjerne bokmerke etter man er ferdig. Det er en fin måte for seg selv å holde kontroll på diverse forskjellige saker. Disse stjernene er individuelle for hver bruker, og ikke for hver sak. Det betyr at dersom du setter et bokmerke på en sak, vil det bare synes at den er bokmerket for din bruker.

 

Hver sak har ofte flere meldinger ved bruk av comment og/eller reply. Hver av disse meldingene har igjen egne funksjoner:

 

* REPLY/COMMENT av en enkelt melding fungerer på litt annerledes måte enn å bruke reply/Comment på hele saken. Ved å bruke reply/comment på denne måten vil du 'quote' denne meldingen du jobber med. Det betyr at alt som står over "Jeg synes brukerdo er kjempe fin, men det er en ting som er uklart..." vil være det første som står i den nye meldingen du oppretter. Denne funksjonen kan være veldig lur dersom det er mange og uoversiktlige meldinger i en sak, men samtidig kan den være mye til bry ettersom all informasjonen kommer om igjen.

*FORWARD: Forward funksjonen bruker du dersom du skal sende akkurat denne meldingen du holder på med til en adresse. Du trykker forward og skriver deretter inn adressen du vil sende denne meldingen til.

*CLONE = Du tar meldingen i ticket'en du holder på nå og "kloner" den til en ny ticket. Det vil bli opprettet en ny sak hvor meldingen du holdt på med vil være den første i den nye saken. Du velger kø hvor klonen skal være og oppretter som vanlig saken der.

 

NB: Editoren fungerer ikke som den skal for alle brukere. Den er deaktivert for øyeblikket, men hver enkelt kan aktivere den på egen hånd!

Når du skriver en reply/comment, brukes samme redigeringsmåte som i Vortex. For å se editorpanelet må du trykke på den lille pilen vist på bildet under

 

 

og editoren vil poppe opp slik:

 

 

4.8.1) Oppdatere flere saker samtidig og informasjon om det å forandre på saker

Det er også mulig å oppdatere mange saker på en gang. For å gjøre dette velger du alle sakene du ønsker å oppdatere f. eks gjennom et søk, velg deretter menyen update multiple tickets. Du kommer nå inn i et skjermbilde der du kan legge inn svar eller kommentar på alle sakene på en gang. Husk å klikke Update all når du er ferdig.

 

4.8.2) Andre endringer på saker

Merk! Save Changes brukes hvis det skjer endringer i en sak som for eksempel at flere legges til i cc-feltet og skal ha kopi av saksgangen, da må du først velge Save Changes og deretter Update Ticket. Hvis du kun trykker Save Changes blir ikke saken oppdatert i databasen.

Du vil ellers kunne endre prioritet, kø, tema (subject), tidsfrist (due date) med mer. Historien for en sak kan dog ikke endres.

Hvis du vil at flere brukere skal få e-post om denne saken kan du legge til en gruppe eller en person ved å bruke add a watcher og deretter search for users og velge bruker eller search for groups og velge gruppe. Du må også tildele en rolle til brukeren eller gruppen som du velger som watcher. Rollene en watcher kan ha er cc eller AdminCC.

 

4.9) Samle saker

Hvis det finnes saker som er sendt til flere køer, blir dette duplikater i databasen. For å unngå dette bør sakene samles, bruk Merge på sakene. Det bør gjøres en vurdering av hvor samlesaken bør ligge, altså i hvilken kø. Eksempel: Søk via fellesnevner for saken, for eksempel subject inneholder ordet 'test'. Når du har fått opp alle sakene som skal samles, velg update multiple tickets, marker vekk den første av sakene i listen, og samle de følgende inn i den første og sjekk at samlesaken nå ligger i riktig kø.

 

4.10) Bytte av kø 

Det er to hovedtilfeller ved saker som skal bytte kø. Det første og mest frekvente går på saksgangen - en sak trenger hjelp fra flere personer og blir flyttet imellom køer. For eksempel hvis saken er handle i en kø hvor saksbehandler bare er kompetent til å svare på deler av problemet. UiO har idag (jun 2009) satt opp RT slik at hvis en sak flyttes til en annen kø så går det ut en melding til alle relevante parter i saken om at dette har skjedd.

Det andre tilfellet er rett og slett at saken har havnet i feil kø helt fra starten. Da er det kø-sjefens oppgave å videresende til riktig kø.

For å bytte kø går man inn på saken og trykker menyen "Jumbo". Som vist på bildet under trykker man på scroll-menyen og velger den køen saken skal legges inn i. Her har vi byttet kø fra rt-test til request tracker.

 

 

Vi skal innarbeide som fast rutine at saksbehandler sender kunden en forklarende melding fra RT ved enhver viktig endring i saken, som for eksempel når saken flyttes til en ny kø og dette kan anses som en vesentlig endring for kunden. I selvbetjeningsbildet til RT kan kunden alltid se hvilken kø saken tilhører.

 

4.11) Løse en sak

Sørg for at saken (ticket) får status resolved og at det står en bra beskrivelse av hvordan den ble lukket, slik at dette kan benyttes som erfaringsdata for lignende saker fremover. Som standard går det en melding til kunde (requestor) om at saken er lukket. Bruk reply under løsning av saken dersom du ønsker å holde kunden orientert om det som skjer gjennom hele saken.

 

4.12) Håndtering av spam i RT

Klikk på IsSpam om du er sikker på at en sak er spam. Om du er i tvil flytter du saken til køer spam.suspects og overlater resten til Houston. IsSpam fører til at saken flyttes til en kø der du antakelig ikke har adgang, og derfor får en kryptisk melding om at du ikke har adgang til saken. IsSpam knappen finner du øverst til høyre på skjermen:

 

 

4.13) Prioritering, varsling, purring og eskalering av saker

4.13.1) Frister

Hver kø i RT har sin egen startverdi på tidsfristen for behandling av saker. Vi har valgt å anbefale at de fleste køer i RT har 8 dager som startverdi på tidsfrist for ferdigbehandling av saker. Men køsjefene kan velge sette opp sin kø med en annen frist som startverdi.

I forbindelse med saksbehandlingen kan hver enkelt sak få satt sin egen tidsfrist, ved å sette dato og eventuelt tidspunkt for utløp av fristen. Fristen bør ligge mellom 3 dager og 3 uker, dersom opplegget for prioritering, eskalering og purring i RT skal fungere brukbart.

 

4.13.2) Prioritering

For hver kø velges en prioriteringsskala med startprioriteten og høyeste prioritet i området 1-99. I avsnittet nedenfor er det forklart hvordan prioriteten med tiden automatisk stiger fra startprioriteten til høyeste prioritet, fram til dagen før sakens tidsfrist utløper.Vi har valgt å anbefale at alle køer i RT settes opp slik at startprioriteten er 1 og høyeste prioritet er 99 for alle saker. Men køsjefene kan velge sette opp sin kø med en annen høyeste prioritet som startverdi.Når en sak åpnes skal saksbehandleren vurderer sakens prioritet og velger en ny høyeste prioritet for saken, som vist i tabellen nedenfor. Samtidig vurderes og settes vanligvis sakens tidsfrist.

 

 

 

Ikke vurdert
99
Prioritering er ikke vurdert av saksbehandler eller lignende
Lav
20
Problemet gir litt plunder og heft, men kan omgås
Middels
40
Problemet gir noe plunder og heft, men kan omgås
Høy
60
Problemet gir mye plunder og heft, men kan omgås
Kritisk
80
Problemet kan ikke omgås og stopper deler av kundens jobb
Fatal
99
Problemet kan ikke omgås og stopper kundens arbeid helt

 

 

4.13.3) Varsling

Saksbehandlere (for eksempel den som har ukevakt) og den som er ansvarlig for køen, må selv sørge for å oppdage viktige begivenheter, for eksempel at en ny sak har kommet i køen. Dette kan gjøres i RT eller eventuelt ved å sette seg selv opp som QueueWatcher (i de aktuelle ukene) for den aktuelle køen.

Vi har valgt å sette opp RT slik at saksbehandleren automatisk varsles med e-post når han/hun er satt på som owner i en sak, selv om dette fører til en del unødvendig e-post for de som bruker RT mye.

Køeier får varsel om saker i køen som er over due-date.

 

4.13.4) Purring

Vi har valgt å sette opp RT slik at det hver natt sendes purring på alle åpne saker med prioritet over 50, og alle nye saker med prioritet over 40. Purring sendes som e-post til sakens eier/saksbehandler. For saker som ikke har fått eier sendes purring til køsjefene. Vi har valgt å sette opp RT slik bare saker som er nye eller åpnet purres på denne måten. I tillegg purres saker med status ”stalled” en gang hver måned. Tabellen nedenfor viser når purring sendes på saker med ulik prioritet og tidsfrist.

At en sak har ligget over tidsfrisen, eller at en sak ikke har fått tildelt saksbehandler, fører i seg selv ikke til at RT sender purring på saken. Legg merke til at en ny (ikke åpen) sak kan ha saksbehandler, og at en sak uten saksbehandler kan være åpnet!

 

4.13.5) Hvordan eskalere en sak

Vi har satt opp RT slik at prioriteten beregnes hver time på alle saker i alle køer.

Med en sak som har startprioritet 1, sluttprioritet 99 og tidsfrist på 8 dager, vil prioriteten eskaleres med 14 hver dag, slik: 1, 15, 29, 43, 57, 71, 85 og 99, med mindre sakens prioritet endres manuelt underveis. Med forskjellige prioriteter på saken, betyr dette at purring på saken sendes ut som tabellen nedenfor viser:

Prioritet, betegnelse
Høyeste prioritet
Frist, dager
Dager til purring*)
Ikke vurdert
99
8
3 / 4
Lav
20
8
8
Middels
40
8
8
Høy
60
8
5 / 6
Kritisk
80
8
4 / 5
Fatal
99
8
3 / 4

 

 

*) For eksempel betyr 3 / 4: purring sendes etter 3 dager på nye saker og etter 4 dager for åpne saker.

Det fremgår at vi har satt opp RT slik at alle saker der prioriteten ikke er vurdert, behandles som saker med prioritet ”fatal”.

Tidsfrister på under tre dager passer dårlig med dette opplegget for prioritering, eskalering og purring. Grunnen til dette er at prioriteten da når sluttverdien dagen etter at saken er opprettet. For eksempel blir purring ved prioritet 40/50 meningsløs.

 

Eskalering av saker i linjeorganisasjonen

RT har ikke noen hjelpemidler på dette området. Det kan være aktuelt å eskalere en sak i linjeorganisasjonen for eksempel dersom saken har ligget langt over tidsfristen, dersom kunden har klaget på saksbehandlingen eller dersom kunden ønsker å anke saken. Alt slikt må håndteres uten bistand fra RT.

 

4.14) Logge ut

Av sikkerhetsmessige hensyn er det viktig at du logger ut når du ikke skal bruke RT lenger. Velg menyen Logout øverst i høyre hjørne i skjermbildet, denne menyen er alltid tilgjengelig uansett hvilke oppgaver du jobber med.

 

5) Avanserte funksjoner for saksbehandler

5.1)  Relasjoner i RT

Relasjoner (Relationships) inkluderer depends on, depended on by, parents, children, refers to og referred to by. Relasjonene kalles ofte for links i RT. Det er satt opp relasjoner for hver sak, og for å se hvilke relasjoner som gjelder for den aktuelle sak klikker du på Links på venstre side i saksskjermbildet. Du kan legge til relasjoner, fjerne relasjoner eller duplikater i dette skjermbildet. Husk å klikke på Save Changes for å få lagret endringene.

På bildet under er vi inne på en sak og har allerede gjort den avhengig av en annen sak ved å bruke "Depends on" under New Links. Her skrev man inn ticket nummeret til saken man ville gjøre den saken vi jobber med avhengig av.

 

 

 

5.2) Hvordan generere rapporter fra RT

Du kan lage rapporter i RT ved å søke på ulike felt. For eksempel kan du få ut oversikter over alle saker som har en bestemt saksbehandler, alle saker som har en type status, alle saker som ikke er lukket innenfor en gitt tidsangivelse med mer, alle saker innenfor en bestemt kategori eller tema med mer. Disse rapportene kan tas ut ved bruk av søkemulighetene i RT.

 

5.3) Hvordan hente ut statistikk fra RT

Det finne to vidt forskjellige måter å gjøre dette på.

  1. Du kan som saksbehandler, hente ut rapporter. Denne funksjonaliteten ligger under Tools>Reports.
  2. For hvert søk som du utfører, enten det er et manuelt eller autmatisk (lagret) søk kan du hente ut statistikk på resultatene (se bunnen av nettsiden når du sitter og ser på resultatet av søket).

 

5.4) Administrering av saker ved bruk av e-post

Dette er en tilpasning som er laget for UiO og som gjør det mulig å oppdatere saksattributter ved bruk av e-post. Det kan for eksempel benyttes til å oppdatere eiere av saker eller endring av kø. Dette kan benyttes når en ny sak opprettes eller endres.

Informasjonen som følger baserer seg på den til nå (primo desember 2006) nyeste publiseringen av hvilke funksjoner som er implementert i RT. Noen av de siste funksjoner som har vært etterspurt er opprettelsen av "link" og "custom fields". Informasjonen som er limt inn under her, kommer fra: http://www.cpan.org/authors/id/J/JE/JESSE/RT-Extension-CommandByMail-0.05.readmeMerk! Det er ingen kontroll på feil ved bruk av e-post, e-posten blir ignorert hvis den inneholder feil i ett eller flere felt. Slik e-post kan ikke ha vedlegg.Implementeringen baserer seg på bruk av pseudo-felt. Her er en oversikt som viser hva som kan benyttes. Felt i parentes er ikke implementert i løsningen foreløpig.****

  COMMANDS
   Basic
    Queue: <name>
        Set new queue for the ticket

    Subject: <string>
        Set new subject to the given string

    Status: <status>
        Set new status, one of new, open, stalled, resolved, rejected or
        deleted

    Owner: <username>
        Set new owner using the given username

    Priority: <#>
        Set new priority to the given value

    FinalPriority: <#>
        Set new final priority to the given value

   Dates
    Set new date/timestamp, or 0 to unset:

        Due: <new timestamp>
        Starts: <new timestamp>
        Started: <new timestamp>

   Time
    Set new times to the given value in minutes. Note that on
    correspond/comment "TimeWorked" add time to the current value.

        TimeWorked: <minutes>
        TimeEstimated: <minutes>
        TimeLeft: <minutes>

   Watchers
    Manage watchers: requestors, ccs and admin ccs. This commands can be
    used several times and/or with "Add" and "Del" prefixes, for example
    "Requestor" comand set requestor(s) and the current requestors would be
    deleted, but "AddRequestor" command adds to the current list.

        Requestor: <address> Set requestor(s) using the email address
        AddRequestor: <address> Add new requestor using the email address
        DelRequestor: <address> Remove email address as requestor
        Cc: <address> Set Cc watcher(s) using the email address
        AddCc: <address> Add new Cc watcher using the email address
        DelCc: <address> Remove email address as Cc watcher
        AdminCc: <address> Set AdminCc watcher(s) using the email address
        AddAdminCc: <address> Add new AdminCc watcher using the email address
        DelAdminCc: <address> Remove email address as AdminCc watcher

   Links
    Manage links. These commands are also could be used several times in one
    message.

        DependsOn: <ticket id>
        DependedOnBy: <ticket id>
        RefersTo: <ticket id>
        ReferredToBy: <ticket id>
        Members: <ticket id>
        MemberOf: <ticket id>

   Custom field values
    Manage custom field values. Could be used multiple times.

        CustomField.{C<CFName>}: <custom field value>
        AddCustomField.{C<CFName>}: <custom field value>
        DelCustomField.{C<CFName>}: <custom field value>

    Short forms:

        CF.{C<CFName>}: <custom field value>
        AddCF.{C<CFName>}: <custom field value>
        DelCF.{C<CFName>}: <custom field value>

****
 

Eksempel på en e-post der disse pseudofeltene er benyttet:

From: Mari Wang

To: test@rt-dev.uio.no

Subject: Testing pseudo headers
Owner: mari
Status: open
Due: 2022-09-01
Starts: 2022-08-01
Started: 2022-07-03
AddRequestor: mari@some.domain
AddCc: mariwan@some.domain
AddCc: mariwang@some.domain
AddAdminCc: mariwang@some.domain
Priority: 50
FinalPriority: 90

6) Oppsett av RT - RT at a glance

6.1) Tilpassing av din innloggingside: "RT at a glance"

Når du, som saksbehandler, har logget inn på RT (via f.eks. rt.uio.no) kommer du inn til din personlige hjemmeside i RT. Hva som skal komme til syne på denne innloggingssiden bestemmer du selv og den heter "RT at a glance". Ikke bare bestemmer du hvilke innholdsbokser som skal komme fram, men innholdet i boksene kan altså være resultatet av søk som du selv har laget. Poenget er at du raskt skal få tak i den informasjonen som du trenger i din hverdag som saksbehandler. TIPS: sett av noen minutter og gjør deg kjent med det som beskrives under. Du vil da spare tid i din fremtidige bruk av RT.  

 

6.2) "Mine preferanser"

Alle saksbehandlere som logger seg på RT har muligheten til å stille inn sine egen preferanser. Du finner linken til disse innstillingene enten på den øverste linkraden i navigasjonspaletten eller helt oppe til høyre i vinduet.

 

 

Dine innstillinger handler om egenskaper ved din bruker som kommer til syne i forskjellige settinger i RT. Det finnes 5 valg innen preferences hvor vi skal se spesielt på ABOUT ME og SEARCH OPTIONS.

 

 

ABOUT ME: Ditt ekte navn, kallenavn (nickname), ytterligere telefonnumre, adresse, signatur på meldinger fra deg. Deler av dette hentes automatisk fra LDAP og kan ikke endres av brukeren. Hvis du prøver å overstyre informasjonen vil den returnere til det som kommer fra LDAP ved neste oppdatering, så det har ingenting for seg å fylle ut denne informasjonen.

 

SEARCH OPTIONS er svært viktig.

 

 

De innstillingene du gjør her blir til standardvalgene dine for hvordan du ønsker å fremstille resultater på søk i hele RT. Så hvis du har sterke ønsker for om korrekt sortering av saker er at de nyeste skal først eller de gamle skal først, så er dette definitivt stedet å si ifra om dette. Når du seinere lagrer automatiske søk som skal komme tilsyne i f.eks. din egen RT at a glance så vil standardvalget ta utgangspunkt i det du har satt opp her under PREFERENCES>SEARCH OPTIONS.

PERSONAL GROUPS og DELEGATION er foreløpig ikke tatt i bruk i vår løsning for UiO.

RT AT A GLANCE er det samme som å trykke på edit for å redigere sin egen forside. Se "redigering av body og summary" rett nedenfor.

 

6.3) Redigering av skjermarealene Body og Summary

Det største arealet kalles body og er et ubegrenset bokser under hverandre som dekker nesten hele bredden på skjermen.

 

 

Både i body og summary kan du altså bestemme hvilke vinduer som skal vises. I tillegg blir du best om å bestemme omfanget av disse arealene.

Klikk på Edit som står i blått ut til høyre for menyen til RT at a glance.

 

 

Da åpnes muligheten til å slette eller bytte innholdet i body og summary. I firkanten som heter available ligger alle varianter av bokser som du kan ha opp i body. Klikk på de(n) du vil ha framme på din førsteside. Deretter klikker du på den høyrerettede pilen mellom available og listen over de du allerede har valgt. Gjør det samme for summary.

 

 

NB: Vår anbefaling er at du fjerner Quick create siden denne funksjonen ikke passer inn i UiOs nåværende løsning og derfor kun tar opp viktig plass på din egen RT at a glance.

Helt nederst på siden velger du hvor mange saker som skal komme til syne f.eks. innen samme kø. Du kan selv skrive inn det tallet som passer deg.

 

 

6.4) Direkte redigering av hver enkelt boks på førstesiden

Den oppmerksomme ser at det er en egen editknapp på mange av boksene som finnes på førstesiden "RT at a glance". Når du klikker på denne kommer du rett til visningsegenskapene for akkurat denne boksen. F.eks. visning av "Alle saker jeg jobber med" under body-delen vist på bilde under.

 

 |

Når du klikker på denne knapper kommer du altså tilbake til innstillingene som kun gjelder visning av køene (se forklaring på dette litt lenger ned)

 

6.5) Andre egenskaper som redigeres(My Tickets, Unnowned tickets og  Quick Search)

 

 

1) My Tickets

"My Tickets" under Customize RT at a glance vil si å redigere hvilke av sakens egenskaper som skal komme til syne dersom den skal vises i body/symmary. Når du åpner selve saken vil du selvfølgelig se alle egenskaper til saken, men det er ikke plass til det på kortlistene som skal gi deg et kjapt overblikk. Derfor blir du bedt om å velge hva som skal være med i kortoversikten, samt hvilke egenskaper sakene skal sorteres etter, osv osv. Du kan for eksempel velge p vise bokmerker i en egen kolonne.

 

 

2) Unowned Tickets

Når du skal velge hvordan "Unowned tickets" skal komme til syne får du de samme valgene som under My Tickets. Et tips kan f.eks. være å velge bort en del egenskaper på saker som ikke er dine.

3) Quick search

I denne kolonnen velger du hvilke køer som skal komme tilsyne i listen over køer. Denne listen er ofte en natulig del av "at a glance" siden, og hjelper deg å hoppe raskt fra kø til kø, dersom du er saksbehandler i flere køer. Benytt sjansen til å fjerne køer du ikke har noe med å gjøre.

 

 

6.6) Brukerrettigheter og grupper

RT har et stort opplegg for håndtering av brukerrettigheter. Det er totalt over 81 ulike rettigheter som kan gjelde enten for hele RT (global), for en gitt kø eller en gitt gruppe av brukere. Dette opplegget overgår langt det UiO har behov for.

6.6.1) Kunder

Til hver kø skal det med enkelte unntak være en gruppe av brukere som kan sende saker til køen. Normalt vil vi for dette formålet bruke systemgruppen ”Everyone”, dersom køen skal være åpen for alle brukes.

6.6.2) Saksbehandlere

Til hver kø skal det være en gruppe av saksbehandlere. For mange av køene til USIT er det per idag (nov 2006) én felles gruppe av saksbehandlere: "rt-saksbehandler"

6.6.3) Køsjefer

Som tidligere nevnt skal hver kø ha minst to køsjefer.

6.6.4) Watchers

Både brukere (uprivilegerte) og saksbehandlere (privilegerte) kan opptre som Watchers, på en utvalgt sak eller på en utvalgt kø i sin helhet. RT har to typer Watchers som heter Cc og AdminCc. Sistnevnte får kopi av all e-post som gjelder den aktuelle saken, eller alle sakene i den aktuelle køen. Cc får i likhet med kunden (Requestor) kopi av all e-post unntatt kommentarene.

Det er bare saksbehandlere på den aktuelle køen som kan sette opp eller fjerne noen som Watcher på enkeltsaker i køen. En Watcher som er privilegert kan i RT hente opp de sakene han/hun er Watcher på, samt alle saker som hører til køer han/hun er Watcher på. Hun kan ikke hente noen andre saker i RT, eller se noen kø i sin helhet, med mindre han/hun er saksbehandler på den aktuelle køen.

En Watcher som er uprivilegert får bare se selvbetjeningsbildet i RT, og kan der hente opp de sakene han eller hun er Watcher på, samt alle saker som hører til køer hun er Watcher på. Hun kan ikke hente noen andre saker, eller se noen kø i sin helhet, og sakene kan bare hentes ved å oppgi saksnummeret. Det er ingen søkemuligheter. Det er bare Requestor som får en liste av sine egne saker i selvbetjeningsbildet, mens andre uprivilegerte må oppgi sakens nummer for å få se saken de er Watcher på.

 

7) Rutiner i RT

7.1) Fordeling av saker på saksbehandlere

Det understrekes at hver kø skal ha minst to køsjefer (selv om det ikke etableres en egen gruppe av køsjefer i RT). Det er køsjefenes ansvar å sørge for at det skjer en fordeling av saker til saksbehandlerne. Det er også køsjefenes ansvar å sørge for at rutinene for saksfordeling er velkjent blant saksbehandlerne. Slike rutiner kan utformes på forskjellige måter, her er to alternativer:

7.1.1) Alternativ 1, ukevaktordning

 (eller lignende): Køen har en ordning med rullerende ukevakter. Fungerende ukevakter har ansvaret for å behandle alle innkomne saker, eller fordele utvalgte saker til andre dersom hun ikke kan ta alle sakene selv. Køsjefene har ansvar for å sette opp vaktliste og følge opp at alle saker blir fordelt og behandlet i tide.

7.1.2) Alternativ 2, køsjefer:

Køen har to eller flere sjefer som har ansvaret for å fordele saker på saksbehandlerne. Køsjefer og ukevakter vil normalt ha RT oppe hele tiden for å følge med på hva som kommer av nye saker og lignende. De som ikke ønsker dette kan få tilsendt all e-post for den aktuelle køen ved å sette seg opp som QueueWatcher (i de aktuelle ukene), for den aktuelle køen.

7.2) Ansvar for vedlikehold av brukergrupper

Det er etablert ulike brukergrupper i RT, avhengig av hvilken funksjon som skal utføres i systemet. Gruppene er køsjefer, saksbehandlere og gruppe med lesetilgang.
*Noen brukergrupper vedlikeholdes i RT
*Noen brukergrupper vedlikeholdes ved at de synkroniseres mot nettgrupper

7.3) Flytting av saker mellom køer

Det kan hende du som saksbehandler har behov for å flytte saker til andre køer.

  • Er du saksbehandler i den nye køen som saken blir flyttet til kan du bare ta over saken i denne køen
  • Har du ikke adgang til køen som du flytter saken til må du la saksbehandlerne i den nye køen ta over saken som om den kom som en ekstern henvendelse

I det saken kommer over i køen der saksbehandleren ikke har adgang blir saken borte fra skjermen og det kommer en melding som sier at man ikke lenger har adgang til saken

8) Forklaring av ord og uttrykk

Sak (Ticket)

Sentralt objekt i RT som har metadata som eier, status, kø, osv. tilknyttet seg.

 

(Queue)

Den sentrale administrative enheten i RT som holder ting organisert. En kø er en organisert rekke med saker som står for tur til å bli løst av en saksbehandler.

 

Sakshistorikk (Ticket's history)

Kommentarer om en sak (lagret permanent), dvs. alt som skjer om en sak.

 

Saksoppdateringer (Ticket updates)

Består av to varianter:

  • Svar (Reply) - Offentlig notat som kunden kan se
  • Kommentar (Comment) - En privat notat kun synlig for administratorer/saksbehandlere

 

Prioritet (Priority)

Hvor viktig en sak er - representert i en skala fra 0-99 (høyeste). Policy må lages.

 

Status listemeny (Status Drop-Down Meny)

For å klassifisere en sak:

Ny (New)

- urørt sak

Åpen (Open)

- saken er under arbeid

Lagt på vent (Stalled)

- Eksempel: sakens kunde er på ferie

Lukket (Resolved)

Forkastet (Rejected)

- ikke relevante saker, men ligger i basen som erfaringsdata

Slettet (Deleted)

- spam, skulle aldri vært i systemet i det hele tatt

Overvåker (Watcher)

En som er interessert i en sak, og en overvåker har flere typer roller:

Saksbehandler (Owner)

- den som har ansvaret for saken og at den blir løst og lukket

 

Kunde (Requestor)

- den som har opprettet saken

Cc

noen som bør få en kopi av besvarelser (replies) som går til kunden

 

Privilegert bruker (saksbehandler og lignende) – (Staff user)

 

Uprivilegert bruker (kunde) – (Non-staff user)

 

AdminCC

- får kopier av alle kommentarer og generelt sett har tillatelse til å jobbe med en sak

 

Relasjoner (Relationship)

I RT er dette sak-til-sak, men det kan også være lenker til eksterne ting som URLer eller f.eks. fraktnummer osv.

 

Avhenger av (depends on)

- Saken kan ikke løses hvis ikke en annen sak blir løst og lukket først, motsatt er saker som har avhengigheter til (depended on by)

 

Refererer til (refers to)

- en sak trenger ikke en annen sak, men det er lurt/nyttig å se på en annen sak som denne refererer til, motsatt er (referred to by)

 

Fleksifelter (Custom Fields)

Databasefelter som din organisasjon kan få satt opp etter behov.

 

Scripts

Skreddersydde meldinger som automatisk vil gjøre en handling X som respons til en handling Y. Innebygd i RT er det åtte globale scrips, disse må tilpasses UiOs installasjon. Det er også mulig å definere egne scrips. Scrips håndteres ved UiO av de som drifter og administrerer systemet.

 

9) Mer informasjon

Hjemmesiden til Best practical: http://www.bestpractical.com/

 


 

Publisert 21. juni 2010 09:52 - Sist endret 31. mars 2022 14:09