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 og evt. per telefon. RT har vært og er fortsatt under løpende utvikling siden 1996. Den distribueres under GNU Public License (fri programvare). RT benyttes av systemadministratorer ved driftssentre, kundesupport-ansvarlige, utviklere og av markedsavdelinger på tusenvis av nettsteder rundt om i verden.

Firmaet Best Practical Solutions står som utviklere av RT. Det finnes tilgjengelige diskusjonslister (e-postlister) for RT driftsansvarlige.

RT er skrevet i objektorientert Perl, og er et portabelt, høynivå og plattform-uavhengig system. RT er et system som er utviklet for å håndtere nøkkeloppgaver som identifisering, prioritering, tildeling, løsning av saker.

RT brukes av statlige organer, utdanningsinstitusjoner, og utviklingsorganisasjoner rundt om i verden. I Norge benyttes RT f.eks. ved Universitetet i Tromsø, Uninett og Samfundet.

Hva må til ”bak kulissene” for å bli saksbehandler i RT

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@hjelp.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. Rettighetene styres ved at saksbehandlere er medlemmer av nettgruppen rt-saksbehandlere eller endre nettgruppen for saksbehandlere. Det kan ta en halvtimes tid før du får disse rettighetene tildelt.

Mer informasjon om USITs oppsett i RT finner du på følgende URL: http://intra.usit.uio.no/tj-grupper/rt/oppsett_i_rt.html

Softwaremoduler i RT ved UiO

Det benyttes en postgresSQL-database. Videre OpenSSL Apache, Perl og selve RT. Verktøyet som leveres med RT bruker Perls CPAN-system for installering av modulene.

Informasjon om installasjon og systemkrav ellers finner du i driftsdokumentasjonen.

Krav til nettleser

Ingen krav m.h.t. nettleser er nedfelt i dokumentasjonen fra Best Practical.

Vanlige oppgaver for en saksbehandler i RT

De vanligste oppgavene for saksbehandleren er:

• Logge inn
• Personifisere sin 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

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.

Tilpassing av din innloggingside: "RT at a glance"

Når du, som saksbehandler, har logget inn på RT (via f.eks. hjelp.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. Eksempel på en typisk førsteside kan være:

"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), skifte av passord, 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.

Viktige momenter omkring navigasjon (sekundær og tertiærnavigering)

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 på toppen av siden forandres hele tiden, avhengig av din posisjon i RT. Minste menyen du kan finne er:

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

Legg spesielt merke til at både fargen på linken og den lille utveksten i blått forteller deg hvilken undermeny som du nå arbeider med. Undermenyen som du arbeider i har ofte også valg, slik at mengden nye valg du kan gjøre er stor. 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 å gå tilbake vha nettleserens egen meny. Er du i tvil kan du alltid hoppe "helt hjem" vha menyvalget "Home" helt ute til venstre på hovedmenyen!

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.

Arealet til høyre kalles summary:

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.

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 "Quick search" i summary-området:

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)

Andre egenskaper som redigeres sammen med innholdet av body/summary

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.

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.

Søk etter saker

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å "Home".

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å ordene "feil" og "passord":

Du kan også benytte deg av "simple search" som er plassert rett ved siden av Home.

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.

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.

NEW SEARCH gir deg muligheten til å starte på et nytt søk

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.

I nederste del av Query builder kan du angi hvordan du ønsker resultatlisten etter søket og evt. 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.

Finne kun dine egne saker

Hvordan du finner fram til dine saker avhenger av hvilken rolle du har i RT. Denne veiledningen henvender seg til saksbehandlere. Hvis du står som saksbehandler (owner) av én spesifikk sakn 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.

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://hjelp.uio.no/######. Da åpnes saken direkte etter at du har logget deg på. Du kan også fylle inn ticketnummeret i saøkefeltet oppe til høyre i skjermbildet.

Logge en telefonsamtale

Du må først opprette en ny sak, dette gjør du ved først å angi køen og deretter menyen New Ticket. Det er også mulig å bruke Quick Ticket, men det anbefaler vi ikke fordi saken da blir registrert uten kunde (requestor) og andre viktige verdier. Se avsnittet under for hvordan feltene i nye saker fylles ut.

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"

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

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.

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.

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.

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.

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, 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

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 kvitteringer per RT-installasjon. 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.

Jobbe med egne saker (som saksbehandler)

Når en ny sak kommer inn og ingen har tatt tak i den ennå vil den ha noen basale egenskaper. De kan du se ved å klikke på saken og se på undermenyen "Display".

Når en saksbehandler med de rette rettigheter tar saken så vil den med en gang begynne å få en histore gjennom 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.

• 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 ikke bli slettet fra systemet, men den får status inaktiv og vil ikke komme fram i søk og lignende.
• Stalled - betyr at saken, av en eller annen grunn er stoppet/satt på vent.

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.

Modifisere/behandle en sak

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 da en ekstra meny under navnet på saken når han/hun klikker på 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.

COMMENT og/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 submit når du er ferdig med svaret eller kommentaren. 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 saken 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

EXTRACT ARTICLE = Denn funksjonen er ikke i bruk ved UiO per idag (nov 2006).

ISSPAM = hvis saksbehandleren ser at det er spam kan vedkommende sende den ut av systemet ved å trykke på IsSpam.

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.

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 requestor, cc eller AdminCC.

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 passord. 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ø.

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.

Hvordan endre eier på en sak

Hvis du endrer eier fra en person til en annen bruker du pilen til høyre i boksen Owner og blar deg ned til den nye eieren av saken. Du kan også endre owner (eier) til å bli deg selv (også kalt å stjele saken (steal) i RT) ved å klikke på menyvalget Steal når du er inne i saken.

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.

Når saken endrer status

Status kan være: new, open, stalled, resolved, rejected, deleted. I standard oppsett av RT er det ingen automatisk varsling av kunden når saken endrer status, unntatt når saken løses. Men RT kan 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.

Det skal innarbeides som fast rutine at saksbehandler sender kunden en forklarende melding fra RT ved enhver viktig endring i saken, som for eksempel ved vesentlige statusendringer. I selvbetjeningsbildet til RT kan kunden alltid se hva status på saken er.

Når saken venter på svar fra kunden, eller lignende

Når en sak har status ”stalled” har RT i utgangspunktet ikke noen direkte informasjon om hva det er man venter på. Normalt vil man forvente at siste ”svar” eller ”kommentar” i saken inneholder informasjon om hvorfor saken har tatt pause. Eventuelt kan man legge på et egendefinert datafelt til køen og bruke det til informasjon om pauser.

Når en sak havner i feil kø

UiO har idag (nov 2006) 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.

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.

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.

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.

Saksbehandling

Vi har laget en skisse som angir anbefalt saksbehandling ved UiO.

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.

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:

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.

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.

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. Rettighetene hos medlemmene i de forskjellige gruppen vedlikeholdes automatisk ved at de synkroniseres mot brukeradministrasjonssystemet LDAP. De køene hvor denne synkroniseringen fungerer styres av køsjen.

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.

Prioritering, varsling, purring og eskalering av saker

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.

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.

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.

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!

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:

*) 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.

Administrering av saker i RT 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.readme

Merk! 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

Date: Fri, 27 Aug 2004 16:27:46 +0200

Owner: mari

Status: open

Queue: test

Due: 2004-09-01

Starts: 2004-08-01

Started: 2004-07-03

Resolved: 2004-06-01

AddRequestor: mari@some.domain

AddCc: mariwan@some.domain

AddCc: mariwang@some.domain

AddAdminCc: mariwang@some.domain

Priority: 50

FinalPriority: 90

The rest of the message, lots of nice text.

Hva kan en kunde gjøre i RT?

En kunde som sender et spørsmål eller lignende til en postliste som er opprettet som kø i RT får altså en tilbakemelding umiddelbart om at saken er kommet inn i køn. I denne meldingen får vedkommende tilbud om å følge med på sin egen sak.

Som nevnt er intensjonen at kundene (requestor) ikke skal behøve å ha noen bevissthet om RT og at det postlisten som spørsmålet ble sendt til er en RT-kø. 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.

Når du klikke på den saken du er nysgjerrig på kommer saksgangen for denne saken opp.

Brukerrettigheter og grupper

RT har et stort opplegg for håndtering av brukerrettigheter. Det er totalt over 73 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.

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.

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"

Køsjefer

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

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å.

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.

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).

 

Forklaring av ord og uttrykk

Sak (Ticket)

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

Kø (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 sendt av en gruppe kunder (requestors).

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

- en CC eller flere CCer som 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.

Mer informasjon

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

lokal tilpasning for RT ved UiO - http://www.usit.uio.no/it/rt/modifications/ - et dokument som beskriver de endringene som er gjort for RT ved UiO, dette gjelder spesielt LDAP-integrasjon og mailintegrering.

---

Redaksjon: OI-gruppa, sas-oi@usit.uio.no
Dokument opprettet: 10.11.2005, endret: 02.11.2006