Vi har forsøgt at lave systemet, som vi forestiller os et ticket management system ud fra undervisningen.
Der er 3 roller i vores system: Kunde, Supporter og Admin. (Supporter dækker over og systemet skelner mellel 1st, 2nd og 3rd level)-
Kunder kan oprette tickets. Tickets assignes automatisk til 1st level.
Supportere kan se og håndtere tickets assignet dem individuelle supportere.
Systemet facilitere kommunikation mellem kunder og supportere, og logger alt interaktion. Kommunikation foregår med kommentarer på tickets.
Tickets kan re-assignes og eskaleres.
Med tickets skelnes mellem "Incident" og "Request". Og tickets har en status, herunder "Open" (venter på support), "Pending" (venter på kunde), "Reslved" (closed).
System facilitere en knowledge base, via. dokumenter man interne (supporter og admins) kan oprette, læse og redigere i.
Man kan markere 2 dokumenter, som man vil bruge som **SLA** og **Service catalog**. Disse 2 dokumenter kan alle tilgå.
### Noter
Kunden vælger selv om en ticket er "Incident" eller "Request".
Det burde være en 1st level, som træffer den beslutning.
Nuværende kan 1st level ændre det efterfølgende.
### Features vi har
#### Service catalog
### Manglende features
#### Større incidents
I tilfælde af at mange brugere laver den samme slags incident ticket,
ville det være smart hvis system kunne genkende større incidents,
for så at prioritere den højere eller hvad man ellers kunne finde på.
#### Prioritering af tickets
Vores nuværende system kan ikke skelne mellem små incidents (f.eks. printer der ikke virker) og store incidents (f.eks. kontor mangler internet).
Prioritering af tickets er yderst vigtigt, så man kan prioritere arbejdskraften.
#### Standardiserede ticket skabeloner
En måde at automatisere tickets på er ved at lave en standardiseret "creation guide", som går igennem de hyppigste problemer, (f.eks. er skærmen slukket, stikket sat i,...).
Dette kan reducere mængden af nødvendig arbejdskraft, og afslå tickets som ikke er dækket af Service Cataloge eller SLA'en
#### Notifikationer
Manglen på notifikationer eller email opdateringer gør at det er svært for en kunde at vide hvornår en ticket er "Pending" (venter på brugeren).
#### Automatisk lukning af tickets
Hvis tickets ikke bliver svaret af en bruger i en længere periode, f.eks. 7 dage, ville det være smart hvis en blev lukket automatisk.
## Sammenligning med Gruppe 1
Vi sammenlignede Gruppe 1's system med vores med et brugseksempel.
De brugte Jira.
Problem: En kunde kan ikke printe.
Årsag: John har trådt på kablet og stikket er faldet ud.
Løsning: Sæt stikket i igen.
### Skabelse af ticket
I vores system har kunden kunde-adgang til system og kan selv lave en ticket, hvor kunden giver ticket'en en tittel og beskrivelse.
Når kunden har oprettet en ticket, bliver den automatisk assignet til en 1st level supporter (specifict den 1st level supporter med færrest åbne sager).
I deres Jira system har kunden ikke adgang, så en ticket skal laves af en intern supporter.
Når supporteren har lavet ticket'et, kommer den i en backlog, og så er det op til 1st level supporterne, selv at tage ticket'en.
### Kunde kontakt
I vores system foregår alt kontakt med kunden (ideelt) i system, så det hele er dokumenteret.
Siden kunden ikke er oprettet i deres system,
kommer supporteren til at kommunikere med kunden udenfor systemet.
Det gør at kommunikationen ikke nødvendigvis er logget og dokumenteret.
1st level vil nu samle information nok fra kunden, så de kan lave en beslutning om de kan løse problemet, skal eskalere eller skal lukke den af andre årsager.
1st level har nu vurderet at de ikke kan løse problemet, og eskalere derfor ticket'en til en bestemt 2nd level supporter (LevelTwoAhmed i dette tilfælde).
