Med tickets skelnes mellem "Incident" og "Request". Og tickets har en status, herunder "Open" (venter på support), "Pending" (venter på kunde), "Resolved" (closed).
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
![](projekt/service-catalog-1.png)
![](projekt/service-catalog-2.png)
### 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.
Når kunden har oprettet en ticket, bliver den automatisk assignet til en 1st level supporter (specifikt den 1st level supporter med færrest åbne sager).
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).