Vejledning

Hver funktion trin for trin, med skærmbilleder fra et kørende system. Brugerfladen på billederne kører på engelsk — det er produktets basissprog.

Skærmbillederne er fra version 0.46.0. Intet på de viste skærme har ændret sig frem til version 1.1.6. Det eneste, der ser anderledes ud, er versionsnummeret nederst i sidemenuen.

Tilpasning og administration

Her tilpasser du systemet til din virksomhed. Sprog, logo og farver hører til her. Det samme gør de opgaver, du sjældent laver og så virkelig får brug for: en meddelelse til alle, en opdatering, et arkiv. Bortset fra at sende meddelelsen på e-mail er hele denne blok en del af Basic.

1

Slå sprog til, og oversæt dem selv

Under »Settings → Language Settings« vælger du, hvilke sprog din virksomhed tilbyder. Der er 30 at vælge imellem.

Engelsk er altid slået til og kan ikke slås fra. Det er det sprog, systemet falder tilbage på, når en tekst endnu ikke er oversat.

Derefter vælger hver bruger i sin egen menu det sprog, hun arbejder på, blandt dem du har slået til.

Oversættelser kommer ikke med en opdatering. En opdatering bringer nye engelske tekster; oversættelsen af dem leverer du selv.

Det foregår i to trin. Med »Export JSON« henter du en fil, der indeholder hver engelsk tekst ved siden af din nuværende oversættelse.

Den fil udfylder du i dit eget tempo og lægger den ind igen med »Import JSON«. Tomme felter bliver sprunget over, eksisterende oversættelser bliver overskrevet.

Pladsholdere som {count} skal overleve i oversættelsen. En post, der mister en, bliver afvist og bliver stående på engelsk. Systemet fortæller dig, hvilken det var.

Kortet »State of your language packs« fortæller dig per sprog, hvor du står. Det nævner tre tilfælde: oversat, ikke oversat og forældet.

»Forældet« er det tilfælde, der betyder noget. Den engelske tekst har ændret sig, din oversættelse står der stadig og siger nu noget andet.

Kortet »Languages« med sprogene som knapper, engelsk slået til for altid.
Den røde ramme sidder på tysk og på »Save languages«. Engelsk bærer mærkningen »Always active«.Åbn billedet i fuld størrelse
Kortet »Export translations« med valget af målsprog.
Vælg først målsproget, og hent så. Filen indeholder den engelske tekst og din nuværende oversættelse.Åbn billedet i fuld størrelse
Kortet »Import translations« med den valgte fil.
Efter »Select file« står filnavnet ved siden af. Kun »Import JSON« lægger den ind.Åbn billedet i fuld størrelse
Kortet »State of your language packs« med tilstanden for tysk.
I denne eksempelverden er den tyske pakke komplet. Tallet til venstre vokser med hver opdatering, der bringer nye tekster.Åbn billedet i fuld størrelse
2

Logo, favicon og farver

Under »Settings → CI Settings« sætter du dit logo, dit favicon og tre farver.

Logoet står i sidemenuen under systemets logo. Anbefalet er 400 gange 160 billedpunkter som PNG eller SVG med gennemsigtig baggrund, højst 2 MB.

Faviconet er det lille billede i browserfanen. Anbefalet er SVG eller 64 gange 64 billedpunkter.

De tre farver er »Primary color«, »Accent color« og »Background color«. Den første farver de vigtige knapper, den anden ikoner og fremhævelser, den tredje baggrunden.

Systemet finder selv frem til tekst- og hover-farverne, så teksten bliver ved med at være læsbar. Du leverer kun de tre grundfarver.

Et tomt felt betyder, at den indbyggede farve gælder. Firkanten ved siden af viser så sort, fordi den ikke kan vise »ingen farve«. Bemærkningen nedenunder siger det.

Forhåndsvisningen under felterne viser dine farver, før du gemmer. Kun »Save« gør dem gældende for alle.

»Restore defaults« sætter alt tilbage. Det fjerner også det uploadede logo og favicon.

Kortet »Colors« med to farver sat og forhåndsvisningen nedenunder.
Den røde ramme sidder på de to forhåndsvisningsknapper. De viser med det samme de farver, du har indtastet.Åbn billedet i fuld størrelse
Firmalogoet i sidemenuen, under systemets logo.
Den røde ramme sidder på det uploadede logo. Det står der med det samme og på hver side.Åbn billedet i fuld størrelse
3

Lyst og mørkt, og visningen på en telefon

Systemet findes i et mørkt og et lyst udseende. Du skifter i din egen menu nederst i sidemenuen.

Valget hører til hver bruger og bliver husket. Én agent kan arbejde i lyst, mens en kollega arbejder i mørkt.

Den samme menu rummer din tilgængelighed, dit profilbillede, din adgangskode og dit sprog.

På en smal skærm stiller brugerfladen sig selv om. Tabellen bliver til kort oven på hinanden, og sidemenuen folder sig ind bag ikonet øverst til venstre.

Der findes ingen særskilt app. Adressen er den samme som på computeren, og du logger ind på samme måde.

Den personlige menu med posterne »Light mode« og »Dark mode«.
Den røde ramme sidder på »Light mode«. Fluebenet ved siden af viser, hvilket udseende der er aktivt.Åbn billedet i fuld størrelse
Sagslisten i det lyse udseende.
Den samme side, de samme data. Kun farverne ændrer sig.Åbn billedet i fuld størrelse
Den samme side i et smalt vindue, som på en telefon.
På en telefon står listen oven på hinanden. Du åbner sidemenuen med ikonet øverst til venstre.Åbn billedet i fuld størrelse
4

Dato og klokkeslæt, som I skriver dem

Før du går i gang: Administratorer og agenter må ændre de generelle indstillinger. Alle andre læser datoer, som de er sat der.

Under »Settings → General Settings« finder du kortet »Date and time format«. Det står lige efter tidszonen.

Fire valg udgør måden, en dato bliver skrevet på. »Date order« er rækkefølgen af dag, måned og år.

»Date separator« er tegnet mellem tallene. Du kan vælge punktum, skråstreg eller bindestreg.

»Clock« er uret: 24 timer, eller 12 timer med AM og PM. »Time separator« er tegnet mellem time og minut.

Under de fire felter ser du »This is how it looks«. Det viser resultatet, før du klikker på »Save«.

Indstillingen gælder for hele installationen. Den afhænger ikke af sproget og ikke af den enkelte bruger.

Det er med vilje. Én virksomhed skriver datoer på én måde, og hver kollega læser den samme måde at skrive på.

Fabriksindstillingen er dag, måned, år med punktum og 24-timers-uret. Ændrer du intet, ændrer der sig intet.

Den valgte måde at skrive på gælder overalt, hvor systemet viser en dato. Det gælder sagen, listerne, påmindelsen og den registrerede tid.

Eksporter er ikke berørt. De skriver en dato som 2026-08-22, fordi regnearksprogrammer læser den form pålideligt.

Et felt, du taster en dato ind i, hører ikke med her. Det åbner din browsers kalender og beholder sin måde at skrive på.

Mere om det på kortet: Slå sprog til, og oversæt dem selv

Kortet »Date and time format« med de fire vælgere og forhåndsvisningen.
Den røde ramme sidder på rækkefølgen og på forhåndsvisningen. Eksemplerne inde i vælgerne følger den valgte rækkefølge.Åbn billedet i fuld størrelse
Sagens detaljer i fabriksindstillingen: dag, måned, år og 24-timers-uret.
Sådan ser en sag ud, så længe intet er ændret. Øverst står tidspunkter, nederst dagene for den registrerede tid.Åbn billedet i fuld størrelse
De samme detaljer efter skiftet til måned, dag, år med 12-timers-uret.
Den samme sag efter ændringen. De registrerede dage følger indstillingen præcis som tidspunkterne over dem.Åbn billedet i fuld størrelse
5

Meld vedligehold og driftsforstyrrelser ud

Før du går i gang: Meddelelsen på loginsiden er en del af Basic. At sende den som e-mail også er en del af Professional.

Siden »Maintenance / Incident-Notification« står i sidemenuen. Der skriver du en meddelelse, som alle ser.

Meddelelsen står på loginsiden og overalt i systemet. Så folk læser den, allerede før de logger ind.

Pointen er at undgå unødvendige sager. Den, der læser, at netværket er nede, anmelder det ikke igen.

Du sætter teksten sammen ved at klikke. Klik først på det felt, du vil udfylde. Det får en rød kant, og alt, hvad du sætter flueben ved bagefter, ryger derind.

»Title / Subject« står øverst i meddelelsen. »Body« står nedenunder. Sender du meddelelsen som e-mail, bliver det ene til emnet og det andet til teksten.

Færdige sætninger står klar som byggeklodser. Du kan tilføje dine egne under »Text Modules« og jeres systemer og tjenester under »Systems / Services«.

Med »Calendar (add date)« og »Time (add time)« indsætter du en dato og et klokkeslæt. Sådan melder du planlagt vedligehold ud.

Kontakten øverst slår meddelelsen til og fra igen. Den bliver stående, indtil du slår den fra.

Ved siden af findes der en anden slags meddelelse. Gør du en sag til en driftsforstyrrelse, står den også på loginsiden og forsvinder af sig selv, når sagen er løst. Denne kontakt gælder ikke for den.

Med »Send as E-Mail« sender du desuden den samme tekst til en liste af adresser. Det er den del, der hører til Professional.

Mere om det på kortet: Driftsforstyrrelsen som banner og som bemærkning i autosvaret

Kortet med tekstklodserne og jeres egne systemer.
Den røde ramme sidder på listen over systemer. I denne eksempelverden rummer den e-mail, VPN og en filserver.Åbn billedet i fuld størrelse
Titel og tekst med afkrydsede byggeklodser, feltet »Body« er aktivt.
Den røde ramme sidder på det aktive felt og på »Calendar (add date)«. Under feltet står der, hvilket der er aktivt.Åbn billedet i fuld størrelse
Loginsiden med meddelelsen slået til, hen over siden.
Sådan læser en kunde den, før hun logger ind. »Dismiss« skjuler meddelelsen for dette besøg.Åbn billedet i fuld størrelse
Den samme tekst med flueben i »Send as E-Mail« og modtagerlisten.
Den røde ramme sidder på modtagerlisten og på »Send Mail«. Adskil flere adresser med et komma.Åbn billedet i fuld størrelse
6

Tidlig advarsel, før disken fyldes op

Systemet holder øje med diskpladsen på serveren og siger til, før den slipper op.

Der er to trin. Fra 90 procent brugt får du en meddelelse, fra 95 procent en advarsel.

Den, der styrer opdateringerne, ser tallene og hvad der skal gøres. Som regel fylder gamle images fra tidligere opdateringer mest.

Alle andre, der er logget ind, får en kort sætning og en henvisning til deres administrator. De ser den først fra advarselstrinnet.

Intet af det står på loginsiden. Hvor fuld en serverdisk er, rager ingen, før de er logget ind.

En fuld disk rammer ikke kun opdateringen. Vedhæftede filer, indgående post, databasen og sikkerhedskopien ligger alle på den samme disk.

Banneret med meddelelsen om, at pladsen bliver trang.
Det første trin. I denne eksempelverden er 93 procent brugt, og 14 af 200 GB er frie.Åbn billedet i fuld størrelse
Det samme banner med ordlyden fra advarselstrinnet.
Det andet trin ved 96 procent. Nu nævner teksten også, hvad der kan begynde at svigte.Åbn billedet i fuld størrelse
Den samme hændelse i en agents vindue: en kort sætning uden tal.
De, der ikke kan frigøre plads, får ingen tal. Sætningen nævner følgen og peger på administratoren.Åbn billedet i fuld størrelse
7

Opdatering med et tryk på knappen

Under »Settings → Updates« ser du, hvilken version der kører, og om der findes en nyere.

Findes der en ny version, står det nedenunder, hvad den bringer. Listen viser hver version, du springer over.

Før opdateringen tager systemet selv en sikkerhedskopi. Den dækker databasen, de vedhæftede filer og arkiverne.

Derefter kontrollerer det, at der er plads nok. En opdatering skal bruge det gamle og det nye image samtidig, så den beder om 10 GB.

Er der ikke plads nok, afviser systemet opdateringen og siger hvorfor. Det er en bedre besked end at give op halvvejs.

Systemet spørger, før det går i gang. Under opdateringen er det utilgængeligt i nogle minutter, så vælg et roligt tidspunkt.

Går noget galt, falder systemet tilbage til den foregående version og kører videre.

Kan din server ikke nå opdateringskilden, siger systemet præcis det. Det påstår ikke i stedet, at du er opdateret.

En opdatering, der flytter databasen til en ny version, bliver ikke lagt på med et tryk på knappen. Systemet siger til, og udgivelsesnoterne fortæller, hvad der skal gøres.

Kortet »Version status«, der melder, at systemet er opdateret.
Den røde ramme sidder på beskeden. »Check now« spørger med det samme i stedet for at vente på næste kontrol.Åbn billedet i fuld størrelse
Det samme kort med en tilgængelig version og dens udgivelsesnoter.
Den røde ramme sidder på »Install update«. Ovenover står, hvad den nye version bringer.Åbn billedet i fuld størrelse
Bekræftelsen, der bliver bedt om, før opdateringen går i gang.
Spørgsmålet nævner versionen og siger, at der først bliver taget en sikkerhedskopi.Åbn billedet i fuld størrelse
Det samme kort, når opdateringskilden ikke kan nås.
Den røde ramme sidder på beskeden. Uden et svar siger systemet, at det ikke ved det.Åbn billedet i fuld størrelse
8

Arkiver lukkede sager

Før du går i gang: »Delete from live DB« fjerner sagerne fra den kørende database for altid. Hent arkivet først, og se det igennem.

Under »Settings → Archive« pakker du en periodes lukkede sager sammen i en fil. Det holder arbejdsmængden lille.

Kun lukkede sager flytter. En åben sag i den samme periode bliver, hvor den er.

»Preview« fortæller dig på forhånd, hvor mange sager perioden dækker. Den skriver intet og ændrer intet.

»Create archive« bygger en ZIP-fil. Den rummer sagerne med deres kommentarer, deres historik, deres brugerdefinerede felter og deres vedhæftede filer.

Filen står derefter i listen nedenunder med periode, antal og størrelse. En undermappe er mulig, hvis du vil arkivere efter år.

Først derefter bestemmer du, om sagerne skal forlade den kørende database. At oprette arkivet ændrer i sig selv intet.

»Restore« henter sagerne tilbage fra filen. Sager, hvis nummer allerede findes, bliver sprunget over.

En gendannelse har brug for de teams og de workflows, en sag henviser til. Mangler de, siger systemet, hvad det ikke kunne knytte sammen.

»Delete archive file« sletter kun filen. Sagerne i den kørende database bliver ikke rørt.

Kortet »Create archive« med de to datofelter.
Den røde ramme sidder på perioden. Undermappen er valgfri.Åbn billedet i fuld størrelse
Det samme kort med resultatet af forhåndsvisningen.
I denne eksempelverden dækker året to lukkede sager. Forhåndsvisningen ændrer intet.Åbn billedet i fuld størrelse
Listen over arkiver med periode, antal, vedhæftede filer og størrelse.
Den røde ramme sidder på de to handlinger, der rører ved de kørende data.Åbn billedet i fuld størrelse
Spørgsmålet, der bliver stillet, før sagerne forlader den kørende database.
Spørgsmålet siger, at dette skridt ikke kan fortrydes.Åbn billedet i fuld størrelse
9

Fyld dine rullelister fra en fil

Under »Settings → General Settings« finder du systemets rullelister. Hver liste har sit eget faneblad.

Til afdelinger, stillinger og lokationer findes der også vejen gennem en fil. Den betaler sig, når du tilføjer mange poster på én gang.

»Export JSON« henter listen. På en frisk installation giver det dig den tomme struktur, du kan skrive dine poster ind i.

Filen rummer et eksempel, der viser, hvordan en post ser ud. Det bliver sprunget over, når du lægger filen ind igen.

»Import JSON« opretter det, der mangler. Eksisterende poster bliver ladt i fred.

Omdøbning virker ikke gennem filen. Felterne på denne side er der til det, og den røde bemærkning siger det.

Posterne oversætter du bagefter på sprogsiden. Filen rummer det engelske navn.

Kategorier fungerer på samme måde. De hører til et team, så de bor på det teams kategoriside.

Mere om det på kortet: Hoved- og underkategorier kan indstilles frit per team

Fanebladet »Department« med knapperne til eksport og import.
Den røde ramme sidder på de to knapper. Den røde sætning ovenover advarer mod at omdøbe gennem filen.Åbn billedet i fuld størrelse
Den hentede fil i browseren, med eksemplet og posterne.
Der står intet andet i den end navne. Derfor kan ethvert tekstredigeringsprogram rette i den.Åbn billedet i fuld størrelse

Teams og brugere

Et team er et ansvar, ikke en mappe. Det har sine egne kategorier, sine egne frister og sine egne medlemmer. En kunde ser præcis ét af dem. Alt andet handler om, hvem der har hvilken konto, og hvad den konto må.

1

Opret og indstil teams

Teams bor under »Settings → Teams«. Listen står til venstre, indstillingerne for det team, du har klikket på, står til højre. Tallet efter navnet er antallet af medlemmer.

Et nyt team får sit navn i feltet »Team name«. Nedenunder kan du med »Copy categories from« vælge et eksisterende team, så det nye team starter med de samme hoved- og underkategorier. »Create team« opretter det.

Det første team er det team, dine kunder ser. Hvert yderligere team er et specialistteam bag det. At bede en anmelder om selv at vælge den rigtige afdeling er for meget forlangt: hun opretter sin sag hos det første team, og derfra bliver den givet videre.

Det kan du ændre når som helst. Kortet »Customer permissions« bestemmer per team, om kunder må oprette sager der og se deres egne. Uden en af de to rettigheder dukker teamet slet ikke op for en kunde.

Kortet »Agent permissions« gælder for dette teams agenter. Det bestemmer, om de må styre sager, styre kategorier og se dette teams rapporter.

Kortet »Agents« rummer medlemmerne. Trods overskriften står teamets kunder også i det. Vælgeren ovenover og »Add Agent« tilføjer nogen, »Remove« tager dem ud igen. Den, der bliver tilføjet eller fjernet, skal logge ud og ind én gang.

»Default e-mail language« er det sprog, dette team skriver på. Det gælder, når en mailregel vælger »Team default language«.

Kontakten »Active« tager et team ud af drift. Det forsvinder fra sidemenuen og fra hver vælger. Det bliver ikke slettet af det.

»Delete« fjerner kun et team, så længe der ikke er en sag åben endnu. Ellers nævner systemet grunden og gør intet.

Kortet »Audit log« noterer hver ændring på teamet, med navn og tidspunkt.

Basic kører ét team. Professional har ingen grænse.

Siden »Teams« med listen over begge teams til venstre og indstillingerne for Helpdesk til højre.
De røde rammer sidder på de to teams. Klikker du på et af dem, ændrer det, der står til højre, sig. Tallet i kanten er antallet af medlemmer.Åbn billedet i fuld størrelse
Feltet »Team name« med et navn tastet ind, nedenunder »Copy categories from« og knappen »Create team«.
Tast navnet, overtag eventuelt kategorierne fra et eksisterende team, og så »Create team«.Åbn billedet i fuld størrelse
Kortene »Customer permissions« og »Agent permissions« med deres kontakter.
De røde rammer sidder på de to overskrifter. Disse kontakter gælder kun dette ene team.Åbn billedet i fuld størrelse
Kortet »Agents« med vælgeren, knappen »Add Agent« og medlemmerne nedenunder.
Den røde ramme sidder på »Add Agent«. Mærkningen ved siden af hvert navn er rollen, og kortet rummer også teamets kunder.Åbn billedet i fuld størrelse
Kortet »Audit log« med to poster, hver med navn og tidspunkt.
Den røde ramme sidder på overskriften. Hver linje nævner ændringen, hvem der lavede den, og hvornår.Åbn billedet i fuld størrelse
2

Opret administratorer og agenter

Konti bor under »User management«. Listen viser navn og loginnavn, e-mailadressen, teamet med afdelingen nedenunder, og rollen.

»New user« åbner formularen. Fornavn, efternavn, loginnavn og e-mailadresse er påkrævet. Dertil kommer enten en adgangskode eller fluebenet »Send login details by e-mail«.

Med det flueben sætter du ingen adgangskode. Den nye bruger får en mail med sit loginnavn og et tidsbegrænset link og sætter selv sin adgangskode. Systemet sender aldrig adgangskoder.

Rollen bestemmer alt andet. »Admin« og »Agent« er begge medarbejdere og tæller mod den samme pulje. En administrator må mere som udgangspunkt, men hver eneste rettighed kan ændres.

Basic kommer med to medarbejderpladser. Hvordan du fordeler dem, bestemmer du selv: én administrator og én agent, eller to administratorer. Kunder tæller ikke med, de er ubegrænsede i begge udgaver.

Når nogen rejser, klikker du på arkivsymbolet i hendes række. Kontoen bliver låst, så hun ikke længere kan logge ind.

En låst konto flytter til visningen »Archived« og bærer mærkningen »locked« der. Den er ikke længere synlig i visningen »Active«.

En låst konto optager ikke længere en medarbejderplads, og den dukker ikke op i nogen »Assign to«-vælger. Sager, der allerede er tildelt, beholder deres agent og agentens navn.

I visningen »Archived« hedder den samme knap »Restore« og frigiver kontoen igen. I Basic kræver det igen en ledig plads.

De to symboler imellem nulstiller en adgangskode og tofaktorlogin. Den nye adgangskode bliver så vist én gang på skærmen. Den bliver ikke sendt nogen steder hen.

Siden »User management« med alle konti, deres rolle og handlingerne i hver række.
De røde rammer sidder på »New user« og på skiftet mellem åbne og låste konti. Knappen viser, hvilken af de to visninger der er åben.Åbn billedet i fuld størrelse
Dialogen »Create new user« med de påkrævede felter udfyldt og vælgerne til team, afdeling, stilling, lokation og rolle.
De røde rammer sidder på rollen og på invitationen. Rollen er den eneste vælger, der skal udfyldes.Åbn billedet i fuld størrelse
Den samme dialog med fluebenet sat: adgangskodefeltet er slået fra og siger, at brugeren sætter den via linket.
Med fluebenet forsvinder stjernen på adgangskodefeltet. Feltet siger selv, hvem der sætter adgangskoden.Åbn billedet i fuld størrelse
Visningen »Archived« med en låst konto, mærkningen »locked« og knappen »Restore«.
De røde rammer sidder på mærkningen og på vejen tilbage. Begge findes kun i denne visning.Åbn billedet i fuld størrelse
3

Kunder: kontiene for dem, der anmelder

Kunder er ubegrænsede i Basic og i Professional. De optager ingen medarbejderplads.

En kundekonto bliver til på tre måder. Du opretter den under »User management«. Du inviterer personen på mail. Eller du tillader selvregistrering.

Kontakten til det sidder under »Settings → Security« i kortet »Self-registration«. Den er slået fra som udgangspunkt. Slået til dukker et »Register«-link op på loginsiden.

Den, der registrerer sig selv, får altid rollen »Customer«. Ingen anden rolle kan uddeles ad den vej.

Uden mailafsendelse kan adressen ikke bekræftes. Sådanne konti bærer bemærkningen »not confirmed« i listen, så en agent kan se, om adressen påviseligt hører til den person, der står bag.

Til en intern helpdesk er du bedre stillet ved at lade kontakten være. Ellers opretter enhver, der kender adressen, en konto.

En kunde ser kun sine egne sager. Hendes sidemenu er kort: hendes sager, en ny sag, vidensbasen. Hun får aldrig nogen indstillinger at se.

Hvad hun må i et team, bliver sat på teamet. Uden ret til at oprette sager der findes det team ikke for hende.

Kortet »Self-registration« med kontakten og bemærkningen nedenunder.
Den røde ramme sidder på kontakten. Teksten ved siden af siger, hvad den gør, og hvad der sker uden mailafsendelse.Åbn billedet i fuld størrelse
Det samme system, logget ind som kunde: en kort sidemenu og en sagsliste med kun hendes egne sager.
Kolonnen »User« rummer det samme navn i hver række. En kunde ser intet, der ikke er hendes, og indstillingerne mangler i sidemenuen.Åbn billedet i fuld størrelse
4

Roller og rettighedskonceptet

Der findes tre roller: »Admin«, »Agent« og »Customer«. Der kan ikke oprettes flere. Til gengæld er hver eneste rettighed fri.

Du kan omdøbe og oversætte de tre, under »Settings → General Settings« på fanebladet »Role«.

Hvad en rolle må, står et andet sted: under »Settings → Security« i kortet »Permission concept«.

Hver linje er én funktion, hver kolonne én rolle. Et flueben tillader det. Under navnet står den interne nøgle; du har ikke brug for den for at arbejde med siden.

Listen er lang. Den strækker sig fra brugeradministration over adgangen til de enkelte indstillingssider og helt til tidsregistreringen.

Kolonnen »Agent Team« er specialtilfældet. Den bliver først brugbar, når fluebenet »Agent« er sat i den samme linje. Vælg et team der, og rettigheden gælder kun det teams agenter.

Ingen rettighed kan tages fra rollen »Admin«. Fluebenet er tilbage efter gemningen. På den måde kan ingen låse sig selv ude af sit eget system.

Med »Save« gælder ændringen med det samme. Den, det rammer, mærker det ved sit næste klik.

Kortet »Permission concept« med tabellen: én linje per funktion, kolonner til admin, agent, agentteam og kunde.
Den røde ramme sidder på hovedrækken. Vælgeren i kolonnen »Agent Team« er kun brugbar der, hvor fluebenet »Agent« er sat.Åbn billedet i fuld størrelse
Fanebladet »Role« med de tre roller, der hver bærer mærkningen »Mandatory«.
Den røde ramme sidder på bemærkningen. De tre roller bærer mærkningen »Mandatory«, så de kan omdøbes, men ikke slettes.Åbn billedet i fuld størrelse
5

Afdeling, stilling og lokation

Tre lister beskriver personen og ikke sagen: afdeling, stilling og lokation.

De bliver oprettet under »Settings → General Settings« i kortet »Drop-down lists«. Håndteringen er den samme for alle tre.

De bliver tildelt på kontoen. I formularen under »User management« hedder felterne »Department«, »Position« og »Location«.

I brugerlisten står afdelingen under teamet. Stilling og lokation kan ses i kontoens formular.

Lokationen har en anden anvendelse. Der er et »Location«-felt på sagen, og det henter fra den samme liste.

Hver af de tre lister har én post, du ikke kan slette. Den hedder »None selected or available« og bærer mærkningen »Mandatory«.

Sletter du en anden post, flytter alle, der bar den, over til den pladsholder. Så står ingen tilbage og peger på noget, der er væk.

Du oversætter ikke her, men i ét hug på oversættelsessiden. Det engelske navn er det anker, oversættelserne hænger på.

Dialogen »Edit user« med felterne til afdeling, stilling og lokation udfyldt.
De røde rammer sidder på de tre felter. De står ved siden af teamet, men betyder noget andet: teamet siger, hvem der arbejder med sagerne, afdelingen siger, hvor personen arbejder.Åbn billedet i fuld størrelse
Brugerlisten med kolonnen »Team«, hvor afdelingen står under teamnavnet.
Den røde ramme sidder på kolonnen. Teamet står øverst, afdelingen nedenunder. Den, der ikke er i noget team, har en streg på det sted.Åbn billedet i fuld størrelse

E-mailintegration

Ticketsystemet henter post fra en postkasse og sender selv post. Hvordan du sætter det op, står på kortet »Sager fra e-mail, svar og opfølgninger« i blokken om sagsstyring. Denne blok viser, hvad der bliver af en indgående mail, hvordan du blokerer afsendere, og hvilke beskeder systemet sender af sig selv. Hele mailkanalen er en del af Professional-udgaven.

1

Hvad der bliver af en e-mail

Kun i Professional

Når nogen skriver til en teampostkasse, bliver der oprettet en sag ud af det. Emnet bliver til titlen, teksten bliver til beskrivelsen, og afsenderadressen bliver noteret som anmelder. Kanalen på sagen siger »E-mail«.

Bærer mailen et afsendernavn, ryger det navn ind i feltet ved siden af adressen. Gør den ikke, står der »E-Mail« i feltet. Kanalen siger allerede, at sagen kom ind på mail.

Forstavelser som »Re:« eller »Fwd:« bliver fjernet fra titlen. Sagen bærer så navnet på sagen selv og ikke på et svar til den.

Mailens formatering bliver bevaret. Fed tekst, lister og tabeller står i sagen præcis som i mailen.

Links bliver bevaret. Din agent kan klikke på dem i sagen i stedet for at skrive adressen af.

Et billede, der er indlejret i mailen, bliver stående, hvor det stod i teksten. Det bliver også gemt som vedhæftet fil på sagen.

Et billede, som mailen kun henter fra nettet, bliver fjernet. Den slags billeder melder ofte tilbage til afsenderen, hvornår og hvor en mail blev læst. Vil man have et billede frem, skal det indlejres i mailen eller vedhæftes.

Filer, der er vedhæftet mailen, bliver til vedhæftede filer på sagen. De tæller mod den samme størrelsesgrænse som en fil, en agent uploader.

Er autosvaret slået til i workflowet, får afsenderen en kvittering med det samme. Med henvisningen i emnefeltet finder hvert videre svar den samme sag igen og bliver til en kommentar på den.

Mere om det på kortet: Sager fra e-mail, svar og opfølgninger

Den afsendte mail i afsenderens mailprogram, med et indlejret billede og et link.
Dette vindue er ikke ticketsystemet, det er afsenderens mailprogram. Mailen indeholder et indlejret billede og et link.Åbn billedet i fuld størrelse
Beskrivelsen på den sag, der kom ud af det, med billedet på plads og linket.
Den samme mail som sag. De røde rammer sidder på billedet og på linket. Begge står det samme sted som i mailen, og der kan klikkes på linket.Åbn billedet i fuld størrelse
Fanebladet »Attachments« på sagen med filen inline_image_1.png.
Det indlejrede billede bliver også gemt som vedhæftet fil. På den måde kan det hentes uden at skulle trækkes ud af teksten.Åbn billedet i fuld størrelse
Kvitteringen i afsenderens indbakke, med henvisningen i emnefeltet.
Kvitteringen, som den kommer frem til afsenderen. Emnet bærer sagens henvisning. Svarer afsenderen på den, lander svaret på den samme sag.Åbn billedet i fuld størrelse
2

Bloker afsendere

Kun i Professional

Før du går i gang: Spærrelisten står allernederst på siden »E-Mail Settings«. Den gælder for alle teams på én gang.

Nogle afsendere skal ikke oprette en sag. Nyhedsbreve er ét eksempel, og postkasser, der kun sender maskinrapporter, er et andet.

Indtast en fuld adresse, når præcis én afsender er ment. På billedet er det no-reply@example.com.

Indtast domænet med et foranstillet @, når hver adresse hos én afsender er ment. På billedet er det @newsletter.example.net. Underdomæner bliver blokeret med.

En mail fra en blokeret afsender opretter ingen sag. Den bliver markeret som læst og flyttet til mappen for behandlet post. Der hober sig intet op i indbakken.

Spærringen virker også den anden vej. Systemet sender ingen mail til en blokeret adresse.

Det er den egentlige pointe ved adresser, ingen læser. Uden spærringen ville kvitteringen gå til en postkasse, der aldrig svarer.

»Add« sætter en post på listen. Skraldespandsikonet ved siden af fjerner posten igen. En ændring træder i kraft med det samme, der er intet at gemme.

Kortet »E-Mail Blacklist« med to poster: en fuld adresse og et domæne.
Den røde ramme sidder på indtastningsfeltet. Dets pladsholdertekst nævner begge tilladte former. Nedenunder står denne installations to poster.Åbn billedet i fuld størrelse
3

Hvad systemet sender af sig selv

Kun i Professional

Før du går i gang: Kontakterne på dette kort sidder per team under »Team mailboxes« på siden »E-Mail Settings«, lige under det teams postkasseadresse.

Ud over svarene til jeres kunder sender systemet sine egne beskeder. Det gælder tildelingen af en sag, en overskredet frist, en invitation, en ny adgangskode, tilfredshedsmålingen og godkendelsen af en ansøgning.

De tekster følger med færdige og er engelske til at begynde med. De ligger i sprogpakken sammen med alle brugerfladens øvrige tekster.

Når først en sprogpakke er importeret, går hver af disse beskeder ud på det sprog, der er sat på modtageren. To mennesker på den samme sag får derfor beskeden på to sprog.

Ordlyden ændrer du på sprogsiden. Der henter du ét sprogs tekster som fil, retter i den og lægger den op igen. Engelsk er kilden og bliver, som den er.

Om en tildeling overhovedet bliver meldt ud, bestemmes per team. Tre kontakter sidder under postkassen til det.

»Send assignment e-mails« sender en mail til den agent, der får en sag. Med kontakten slået fra melder dette team slet ingen tildelinger ud.

»Notify on self-assignment« bestemmer, om der også bliver sendt en mail, når nogen selv tager en sag. Denne kontakt er slået fra som udgangspunkt.

»Send mail on ticket actions« virker et andet sted. Med den slået til tilbyder dialogerne til at lukke, til at skifte status og til at give videre også at sende kommentaren som mail.

Kvitteringen til jeres kunder hører ikke til her. Dens tekst skriver du selv, i postkassens workflow.

Mere om det på kortet: Sager fra e-mail, svar og opfølgninger

Afsnittet »Assignment notifications« med tre kontakter.
De røde rammer sidder på de tre kontakter. De hører til teampostkassen ovenover. Hvert yderligere team har de samme tre kontakter for sig selv.Åbn billedet i fuld størrelse

Godkendelse og sikkerhed inkl. SSO

Hvem der kommer ind og hvordan, bliver afgjort to steder. Sikkerhedssiden styrer login med brugernavn og adgangskode. SSO-siden tilslutter et katalog eller en ekstern logintjeneste. Du kan køre begge dele samtidig.

1

Login med brugernavn og adgangskode

Før du går i gang: Indstillingerne på dette kort bor under »Settings → Security«. Kun administratorer kan se den side.

Som udgangspunkt logger alle ind med et brugernavn og en adgangskode. E-mailadressen virker i stedet for brugernavnet. Under formularen er der et link til den, der har glemt sin adgangskode.

Efter login får browseren et pas, der er gyldigt et bestemt stykke tid. Kortet »JWT token timer« bestemmer hvor længe. Værdier fra 1 til 24 timer er tilladt, 12 er anbefalingen. Derefter skal personen logge ind igen.

Kortet »Password policy« gælder for hver adgangskode, der bliver sat i systemet. Den bliver håndhævet, når en konto bliver oprettet, når en person ændrer sin egen adgangskode, og når en administrator nulstiller en.

Du sætter mindstelængden, hvilke slags tegn der skal optræde, efter hvor mange dage en adgangskode udløber, og hvor mange gamle adgangskoder der forbliver spærret. For dagene og spærrelisten betyder 0 »fra«.

Reglerne om store og små bogstaver lukker ingen sprog ude. Mange skriftsystemer har slet ikke den forskel, og et tegn fra et af dem opfylder begge regler helt alene.

Konti, der logger ind gennem SSO eller et katalog, har ingen lokal adgangskode, så udløb gælder ikke for dem. Deres regler bor hos udbyderen.

Kortet »2FA Settings« slår tofaktorlogin til. Det har to kontakter. Den øverste kræver det af administratorer og agenter, den nederste af alle inklusive kunder. Er begge slået fra, er tofaktorlogin slået fra.

Den, der logger ind næste gang uden en anden faktor, sætter en op med det samme. Systemet viser en QR-kode til en godkendelsesapp og den samme nøgle til at taste ind i hånden. Efter den første kode er faktoren aktiv.

Lige derefter dukker ti gendannelseskoder op. Hver af dem erstatter koden fra appen én gang. De bliver vist præcis én gang.

Mister nogen sin enhed og sine koder, hjælper administratoren. I brugerlisten nulstiller knappen med det overstregede skjold den persons tofaktorlogin. Hun sætter den op igen ved næste login.

Koderne afhænger af serverens ur. Går det forkert, bliver ingen kode accepteret. Knappen »Check now« på det samme kort holder servertiden op mod en offentlig tidskilde.

Logger nogen ind gennem en ekstern logintjeneste, spørger systemet ikke om en kode. Udbyderen har allerede kontrolleret den anden faktor. Katalogindlogning er anderledes: der gælder reglen ovenfor stadig.

Loginsiden med felterne »Username« og »Password« og knappen »Sign in«.
De røde rammer sidder på de to felter og knappen. Det øverste felt accepterer også e-mailadressen.Åbn billedet i fuld størrelse
Kortet »JWT token timer« med feltet til antallet af timer.
Den røde ramme sidder på feltet. Det accepterer værdier fra 1 til 24.Åbn billedet i fuld størrelse
Kortet »Password policy« med mindstelængde, tegntyper, udløb og spærreliste.
De røde rammer sidder på de tre talfelter. Fluebenene ovenover bestemmer, hvilke slags tegn der skal optræde.Åbn billedet i fuld størrelse
Kortet »2FA Settings« med begge kontakter slået fra.
De røde rammer sidder på de to kontakter. I den tilstand, der er vist her, er tofaktorlogin slået fra.Åbn billedet i fuld størrelse
Opsætningsskærmen med en QR-kode, en nøgle til at taste ind og feltet til den første kode.
Den røde ramme sidder på nøglen. Den er det samme som QR-koden ovenover og hjælper, når kameraet ikke kan læse noget.Åbn billedet i fuld størrelse
Ti gendannelseskoder i to spalter, med »Copy codes« nedenunder.
Den røde ramme sidder på koderne. De dukker op præcis én gang. Koderne på billedet kommer fra et testsystem og er værdiløse.Åbn billedet i fuld størrelse
Brugerlisten med knappen, der nulstiller tofaktorlogin.
Den røde ramme sidder på det overstregede skjold i Marco Rossis række. Ét klik tager hans app og hans gendannelseskoder fra ham.Åbn billedet i fuld størrelse
2

Beskyttelse mod gætning af adgangskoder

Beskyttelsen kører uden nogen indstilling. Der er intet at slå til. Bemærkningen om den står i kortet »2FA Settings«.

Den virker i to trin. Efter fem mislykkede forsøg på den samme konto bliver den adresse, de kom fra, sat på pause i 15 minutter. Fra hver anden adresse kan kontoen bruges med det samme.

Det er den vigtige del. Ellers kunne enhver, der kender et loginnavn, låse en kollega ude med fem forkerte adgangskoder. Hun ville aldrig behøve en adgangskode til det.

Det andet trin er kontoen selv. Den bliver låst i 15 minutter efter 20 mislykkede forsøg. Fordi en enkelt adresse højst kan bidrage med fem af dem, kræver det flere adresser.

Et vellykket login nulstiller begge tællere. Efter en genstart af serveren er pausen på adressen væk, låsningen af kontoen bliver stående.

I brugerlisten bærer en konto, der er låst på den måde, mærkningen »temporarily locked«. Den bliver stående i listen. Efter 15 minutter forsvinder mærkningen af sig selv.

Du behøver ikke at vente. I den samme række er der en knap med en åben hængelås. Den ophæver låsningen med det samme og rydder begge tællere.

Det er ikke det samme som »Archive«. Den knap lukker en konto ned for altid, og kun den optager eller frigiver en medarbejderplads.

Bemærkningen om beskyttelse mod gætning af adgangskoder i kortet »2FA Settings«.
Den røde ramme sidder på bemærkningen. Den nævner begge trin: adressen først, kontoen sidst.Åbn billedet i fuld størrelse
Brugerlisten med mærkningen »temporarily locked« og oplåsningsknappen.
De røde rammer sidder på mærkningen og på den åbne hængelås. Hængelåsen dukker kun op i den række, hvor der er noget at ophæve.Åbn billedet i fuld størrelse
3

Login gennem et katalog eller en ekstern tjeneste (SSO)

Kun i Professional

Før du går i gang: Indstillingerne bor under »Settings → SSO Settings«. Uden en opsat udbyder ændrer der sig intet på loginsiden.

Allerøverst sidder hovedkontakten »Enable single sign-on«. Så længe den er slået fra, bliver det ved brugernavn og adgangskode. Alt, hvad du sætter op nedenunder, bliver gemt og træder først i kraft, når du slår den til.

Kortet »Active Directory / LDAP« tilslutter et katalog i huset. Du indtaster serveren, søgegrundlaget, det filter der finder en person, og felterne til e-mailadressen og navnene.

Kontoen, der bruges til opslag, er valgfri. Uden den spørger systemet anonymt. En persons adgangskode bliver kun brugt til at binde mod kataloget og bliver aldrig gemt.

Et katalog bringer ingen anden faktor med sig. Kræver sikkerhedssiden tofaktorlogin, bliver disse mennesker også spurgt om det.

Kortet »Identity providers« rummer de eksterne logintjenester. Hver får sin egen flade og sin egen knap på loginsiden. »Add provider« opretter en ny.

Under »Provider type« vælger du typen. »Generic OIDC Provider« passer til tjenester som Google Workspace, Microsoft Entra ID, Okta, Keycloak, Auth0 eller Ping Identity. »SAML 2.0 Provider« passer til de samme huse, når de skal tilsluttes over SAML.

Ved siden af dem står seks regionale tjenester: LINE, Kakao, Naver, WeChat, WeCom og DingTalk. Deres adresser er udfyldt på forhånd og står som grå tekst i feltet.

Navnet under »Display name« står senere på knappen. Kontakten ved siden af gælder kun denne ene udbyder.

Til callback-adressen skal du arbejde i denne rækkefølge. Indtast først kun et navn, og klik på »Save provider«. Først da kender systemet udbyderens nummer og viser den færdige adresse under »Redirect URI«.

Den adresse kopierer du og registrerer den hos udbyderen. Den skal stemme tegn for tegn der. Til gengæld giver udbyderen dig et id og en hemmelighed, og dem indtaster du her via »Edit«.

Feltet »Allowed e-mail domains« begrænser, hvem der må komme ind gennem denne udbyder. Lades det tomt, er hvert domæne tilladt.

Mangler en udbyder stadig noget, bærer dens flade den røde mærkning »Incomplete«. Så står den ikke på loginsiden. Teksten ved siden af siger, hvilke felter dens type kræver.

Fuldt opsatte udbydere står stadig ikke der, så længe hovedkontakten er slået fra. Fladen siger det i en gul linje.

Kortet »Single sign-on« med hovedkontakten.
Den røde ramme sidder på hovedkontakten. Med den slået fra bliver kun login med brugernavn og adgangskode tilbage.Åbn billedet i fuld størrelse
Kortet »Active Directory / LDAP« med felterne udfyldt.
De røde rammer sidder på serveren, søgegrundlaget og søgefilteret. Værdierne på billedet kommer fra et testsystem.Åbn billedet i fuld størrelse
To udbyderflader, én opsat og én med mærkningen »Incomplete«.
De røde rammer sidder på begge flader. Den øverste er komplet og venter kun på hovedkontakten. Den nederste mangler sin udbyders adresse.Åbn billedet i fuld størrelse
Dialogen »Add provider« med type, visningsnavn, kontakt og udbyderens adresse.
Den røde ramme sidder på adressefeltet. Nedenunder udfylder »Quick fill« de kendte udbydere på forhånd. Det, der står i krøllede parenteser, erstatter du først.Åbn billedet i fuld størrelse
Dialogen for en gemt udbyder, der viser den færdige callback-adresse.
Den røde ramme sidder på callback-adressen. Den bliver først til ved gemningen og starter med din egen installations adresse.Åbn billedet i fuld størrelse
4

Kontoen ved første login, og loggen

Kun i Professional

Kontakten »Automatically create accounts on first sign-in« sidder i det samme kort som hovedkontakten. Den er slået til som udgangspunkt.

Når nogen logger ind gennem en udbyder for første gang, leder systemet først efter en konto, der allerede hører til den udbyder. Finder det ingen, bliver der oprettet en ny.

Den nye konto får rollen »Customer« og intet team. En kunde behøver intet medlemskab for at oprette en sag og kan derfor gå i gang med det samme.

Kunder er ubegrænsede i begge udgaver, så en konto, der er oprettet på den måde, bruger ingen medarbejderplads. Den, der skal blive agent, får rollen bagefter i brugeradministrationen.

Findes der allerede en konto med den samme e-mailadresse, bliver de to knyttet sammen. Det sker kun, når udbyderen melder adressen som bekræftet. Gør den ikke, bliver login afvist.

Slår du den fra, kommer kun folk ind, der allerede har en konto. Alle andre bliver afvist.

Kortet »Recent sign-in attempts« nederst viser de sidste 100 forsøg. Det noterer hver vej på denne side, også katalogindlogning.

Hver række nævner tidspunktet, udbyderen, resultatet og kildeadressen. Ved et mislykket forsøg står grunden ved siden af. Kolonnen »E-mail« viser adressen, når udbyderen har meldt en, ellers det navn, der blev indtastet.

Login med brugernavn og adgangskode står ikke i denne tabel. Det er ikke SSO.

Kontakten »Automatically create accounts on first sign-in«.
Den røde ramme sidder på kontakten. Teksten nedenunder nævner den rolle, sådan en konto får.Åbn billedet i fuld størrelse
Tabellen »Recent sign-in attempts« med tre mislykkede forsøg gennem kataloget.
Den røde ramme sidder på den øverste række. Den viser et mislykket forsøg med sin grund. Posterne på billedet kommer fra et testsystem, hvis katalog ikke findes.Åbn billedet i fuld størrelse

Sagsstyring

Det daglige håndværk: oprette sager, sortere dem, finde dem igen. Alt i denne blok er en del af Basic, medmindre et kort siger noget andet.

1

Opret og rediger sager

Før du går i gang: En enkelt sag kan ikke slettes — heller ikke af en administrator. Sager forlader kun databasen gennem arkivet, og kun når de er lukkede. Det er med vilje: en sag, som nogen kan fjerne uden spor, er værdiløs som dokumentation.

Du opretter en ny sag med »New Ticket« i bjælken til venstre. Formularen hedder »Create new ticket«. Som agent registrerer du også andres henvendelser med den — det er, hvad feltet »User« er til: det siger, hvem sagen er for, ikke hvem der taster den ind.

Alt med en stjerne er påkrævet: »Title«, »User«, »Main category« og »Description«. Én mere, som er let at overse: formularen gemmer ikke uden en underkategori, selv om »Subcategory« ikke bærer nogen stjerne — en hoved- og en underkategori hører sammen og bliver altid sat parvis.

Hvilke felter der overhovedet dukker op, og hvilke af dem der er påkrævede, sættes under »Settings → Ticket Settings« — hver for sig for agenter og for kunder. Derfor ser en kunde en kortere formular end dig, uden at nogen skal vedligeholde to formularer.

Bagefter kan du ændre næsten alt: til højre for sagen sidder kortet »Details« med anmelder, telefon, e-mail, lokation, kategori og referencenummer; du ændrer selve feltet og bekræfter med »Save« nedenunder. Status, prioritet, tildeling, kanal og observatører sidder et kort højere oppe under »Actions« og træder i kraft med det samme, uden en særskilt gemning.

Kun agenter og administratorer må ændre det. Anmelderen kan læse sagen, kommentere på den og vedhæfte filer — men ikke ændre den klassificering, jeres rapportering er bygget på.

En sidevirkning, det er værd at kende én gang: retter du i en sag, der endnu ikke tilhører nogen, tilhører den dig bagefter. Systemet skriver dig ind som agent og flytter statussen fra »Open« til »Assigned« — begge dele ender i historikken. Ville du ikke det, så tildel den til en anden bagefter.

Hver eneste af disse ændringer lander i sagens historik, med navn, tidspunkt, gammel værdi og ny værdi. Du behøver ikke at slå noget til for det.

Så er der spørgsmålet om, hvordan man kommer af med sager igen. Under »Settings → Archive« vælger du en periode, ser med »Preview«, hvor mange lukkede sager den indeholder, og opretter en ZIP-fil med »Create archive«: sager, kommentarer, historik, brugerdefinerede felter og vedhæftede filer, alt sammen i én fil. Først derefter forsvinder de sager fra den kørende database — og de kan gendannes fra netop den fil.

Formularen »Create new ticket« med felterne Title, Owning team, User, status, prioritet og kategorier.
Formularen bag »New Ticket«. Felterne med stjerne er påkrævede; kategorier, beskrivelse og vedhæftede filer følger længere nede.Åbn billedet i fuld størrelse
Kortet »Details« på en sag med anmelderfelterne og knappen »Save« indrammet i rødt.
At ændre noget senere: ret i feltet, tryk på »Save«. Nedenunder står det uforanderligt, hvem der oprettede sagen og hvornår.Åbn billedet i fuld størrelse
2

Redigering med formateret tekst i beskrivelse og kommentarer

Beskrivelsen og kommentarerne er ikke nøgne tekstfelter. Hver har en værktøjslinje ovenover, og knapperne siger, hvad de gør, når du peger på dem: »Bold«, »Italic«, »Underline«, »Strikethrough«, »Text color«, »Highlight color«, »Bullet list«, »Numbered list«, »Quote«, »Link« og »Clear formatting«.

Sådan laves et link: markér teksten, klik på »Link«, tast adressen ind i den lille dialog. En tom indtastning fjerner linket igen. Web- og mailadresser er tilladt (http, https, mailto) — alt andet bliver smidt væk ved gemningen, så en kommentar ikke kan liste noget forbi nogen.

Billeder kommer ind gennem udklipsholderen: tag et skærmbillede, og indsæt det direkte i redigeringsfeltet med Ctrl+V. Til at begynde med viser teksten kun en markør som »[inline-image:1]«. Når du gemmer, uploader systemet billedet og viser det præcis der — og det lander også på fanebladet »Attachments«, hvor alle sagens filer bor.

Det, du ser, er det, de andre ser: formatering, lister og links bliver bevaret i sagen, og også i mailen til anmelderen. Fremmed opmærkning — fra en kopieret webside eller en indgående e-mail for eksempel — bliver skåret tilbage til dette tilladte sæt. Intet af din tekst går tabt undervejs, kun indpakningen.

En kommentar kan markeres som intern med »Only for Admin/Agents«. Den bærer så mærkningen »Internal« og er usynlig for anmelderen — heller ikke søgningen får den frem.

Redigeringens værktøjslinje, nedenunder sætningen »The display shows ERROR 13.20 and then the paper jams.« med fejlkoden i fed.
Indrammet i rødt: »Bold«, »Bullet list« og »Link«. Bjælken står både over beskrivelsen og over kommentarfeltet.Åbn billedet i fuld størrelse
Tre kommentarer på en sag, den nederste med et fedt ord og en punktliste, den midterste med mærkningen »Internal«.
Sådan kommer det frem: fed tekst og listen bliver bevaret. Den midterste kommentar er markeret »Internal« og usynlig for anmelderen.Åbn billedet i fuld størrelse
3

Vedhæftede filer med forhåndsvisning

Før du går i gang: Tilladt er PDF, DOC, DOCX, XLS, XLSX, TXT, PNG, JPG, JPEG og GIF, op til 50 MB per fil. Grænsen står i formularen (»Max. 50 MB per file«), og større filer bliver afvist, før uploaden går i gang.

Filer hører til sagen, ikke til en enkelt kommentar. På sagen fører fanebladet »Attachments« til listen: »Upload file« lægger en til, hver række nævner filen, dens størrelse og dens dato. Alle, der er med i sagen, må vedhæfte noget — også anmelderen, så ingen behøver at maile jer sit skærmbillede.

Et klik på navnet åbner forhåndsvisningen, uden at du skal hente filen. Billeder kan du zoome ind på, zoome ud fra og dreje derinde — nyttigt ved et display, der er fotograferet skævt. En PDF bliver vist i det samme vindue, med sideoversigt, zoom og print. Tekstfiler bliver vist som tekst. Med »Open in new tab« åbner du filen i sit eget vindue.

En vedhæftet fil hører til sagen og følger med den: den står i historikken (»File uploaded: …«), overlever en overdragelse til et andet team og ender inde i arkivfilen, når sagen bliver arkiveret.

Fanebladet »Attachments« med to filer, ovenover knappen »Upload file« indrammet i rødt.
Alle en sags filer ét sted. Linjen nedenunder nævner de tilladte filtyper og størrelsesgrænsen.Åbn billedet i fuld størrelse
Forhåndsvisningen af et billede med knapperne til at zoome ind, zoome ud og dreje øverst til højre.
Forhåndsvisningen af et billede: zoom ind, zoom ud, drej — øverst til højre. Der bliver ikke hentet noget undervejs.Åbn billedet i fuld størrelse
Forhåndsvisningen af en PDF i det samme vindue, med sideoversigten til venstre og PDF-visningens værktøjslinje øverst.
En PDF åbner på samme måde — ingen download, med sideoversigt, zoom og print.Åbn billedet i fuld størrelse
4

Sagens historik

Fanebladet »History« på sagen svarer på spørgsmålet bag enhver opfølgning: hvem ændrede hvad, og hvornår? Hver række nævner personen, feltet, den gamle værdi overstreget, den nye bagefter og tidspunktet ned til sekundet. Den nyeste post står øverst.

Poster bliver skrevet uden din medvirken — ved statusskift, prioritet, tildeling, kategori, lokation, observatører, titel og beskrivelse, og ved oprettelsen (»Ticket opened«), ved hver kommentar og ved hver uploadet fil. Tallet på fanebladet fortæller dig på forhånd, hvor meget bevægelse der var i sagen.

Historikken kan ikke redigeres og ikke slås fra. Det er præcis det, der gør den nyttig: det er grunden til, at en sag ikke kan slettes enkeltvis, og den følger med ind i arkivfilen, når sagen bliver arkiveret.

En kommentar står der forkortet — den fulde ordlyd bor på fanebladet »Comments«. En intern kommentar dukker også op i historikken, men kun for agenter og administratorer.

Fanebladet »History« med denne sags poster: filer, kommentarer, statusskift, prioritet, tildeling og allernederst åbningen — med to rækker øverst skrevet af en regel.
Indrammet i rødt: fanebladet med antallet. Ved »Status« og »Priority« ser du den gamle værdi overstreget ved siden af den nye.Åbn billedet i fuld størrelse
5

Statusforløb med indstillelige statusser og overgange

Statussen siger, hvor en sag står lige nu. Tolv statusser følger med systemet — Open, Assigned, In Progress, Waiting for User Response, Resolved, Closed og flere. Du finder dem under »Settings → General Settings« i afsnittet »Drop-down lists« bag fanebladet »Status«; »+ Add status« opretter en af dine egne, »Edit status« åbner en eksisterende.

Det vigtige er forskellen på navnet og betydningen. I redigeringen af en status, under »Meaning of this status«, er der tre kontakter: »Counts as resolved«, »Counts as closed« og »Waiting for the requester«. Kun disse kontakter fortæller systemet, hvordan en status skal behandles.

Du må omdøbe hver status, også dem der følger med systemet: nederst i redigeringen, under »Translations«, er der et »Name«-felt per sprog — skriv det derind, som dine folk skal læse. Det tekniske navn bagved bliver ikke rørt, og netop derfor går intet i stykker: automatisering, rapportering og kontakterne ovenover hænger på det navn, ikke på din etiket. Så »Resolved« kan blive til »Done«.

At slette virker derimod ikke for dem alle. Seks statusser bærer mærkningen »Mandatory« i listen — Open, Assigned, In Progress, Resolved, Closed og Reopened. De kan omdøbes og flyttes i rækkefølgen, men ikke fjernes; forsøger man det, ender det med en tydelig besked. Det er ikke der for at genere dig: der hænger processer på dem, som ellers ville stoppe uden et ord — for eksempel den automatiske lukning, der har brug for en »løst«-status som udgangspunkt.

To statusser hører til systemet selv: »Waiting for approval« og »Rejected« bærer mærkningen »System only«. De kommer ud af en godkendelsesproces, og ingen skal kunne påstå i hånden, at noget blev afvist, som aldrig var oppe til beslutning.

Hvad de tre gør: en status, der tæller som løst, lukker sagen af sig selv efter 24 timer. En status, der tæller som lukket, er den endelige tilstand, sagen bliver flyttet ind i. Og »Waiting for the requester« betyder præcis det: vi venter på anmelderen — ikke på et andet team og ikke på en leverandør. Det er den markering, SLA-uret stopper på, hvis du sætter det op sådan.

Nedenunder sidder »Allowed transitions to new status«. Her sætter du flueben ved, hvilke statusser der kan nås fra denne. Lad alt stå tomt, og intet er begrænset; sæt flueben ved noget, og hver anden vej er lukket. Sådan bygger du et forløb, der ikke kan springes over — for eksempel: fra »Open« kan man kun komme til »In Progress« eller »Rejected«, men ikke direkte til »Closed«.

De øvrige kontakter i redigeringen er små ting med stor virkning: farven til listen, »Sort order« til rækkefølgen, »Show status in new ticket form« (skal denne status overhovedet kunne vælges, når man opretter en sag?), »Requires comment in dialog« (fremtving en begrundelse) og »System only« til statusser, som kun systemet selv må sætte.

De generelle indstillinger med fanebladet »Status« indrammet i rødt og listen over alle statusser.
»Settings → General Settings«, fanebladet »Status«: hver status med sit tekniske navn og sine markeringer.Åbn billedet i fuld størrelse
Dialogen »Edit status« med kontakterne under »Meaning of this status« og listen »Allowed transitions to new status«.
I redigeringen: udseende og opførsel øverst, betydningen i midten, de tilladte overgange nederst.Åbn billedet i fuld størrelse
7

Hoved- og underkategorier kan indstilles frit per team

Før du går i gang: Du skal bruge mindst ét team. Kategorisiden er opkaldt efter sit team, så den findes først, når du har oprettet et.

Kategorier er det, anmelderen eller agenten vælger, når en sag bliver oprettet — og det, du senere grupperer dine rapporter efter. Hvert team har sine egne: en helpdesk sorterer efter andre ting end en netværksafdeling, og ingen af dem ser det andet teams lister.

Du finder dem under »Settings« som posten »<teamnavn> Categories«. I eksemplet hedder teamet »Helpdesk«, så posten hedder »Helpdesk Categories«.

Siden har tre kort: »Main categories«, »Subcategories« og »Links«. Den hurtigste start: tast det engelske navn ind i feltet »EN (required)«, og klik på »+ New main category« eller »+ New subcategory«. Alt andet oversætter du senere i ét hug på oversættelsessiden — der er intet at forberede til det her.

Har du mange kategorier foran dig, så tag vejen gennem filen: »Export JSON« henter strukturen — på et frisk installeret system er filen tom og viser dig kun opbygningen. Du udfylder den (i hånden eller med hjælp fra en AI), gemmer den og lægger den op igen via »Import JSON«. Det er ikke en måde at omdøbe på: et navn ændrer du i den kategoris felt og bekræfter med det »Save«, der står ved siden af — det siger siden også selv.

Det tredje kort, »Links«, er der, det egentlige arbejde sker. Vælg en hovedkategori øverst, sæt flueben ved de underkategorier, der hører til den, nedenunder, og gem med »Save links«. Fidusen: én underkategori må hænge på flere hovedkategorier. Så du skal kun bruge »Malfunction« én gang og genbruger den til Printer, Network, Meeting-Room og Notebook.

Fra da af er kategorierne til rådighed i sagen. At slette kan mislykkes, så længe der stadig er sager, der bruger en kategori — det er med vilje, ellers ville gamle sager miste deres klassificering.

Giver du en sag videre til et andet team, bliver dens klassificering stående — også når det nye team slet ikke har de kategorier. Den står så i feltet sammen med sin oprindelse, for eksempel »Meeting-Room · from Helpdesk«, og er gråtonet: det nye team kan se, hvad sagen hidtil kørte som, men kan ikke selv tildele den post. For at sortere den om vælger du fra din egen liste — og systemet vil så have en hoved- og en underkategori sammen.

Den åbnede indstillingsmenu med posten »Helpdesk Categories« indrammet i rødt.
Under »Settings« er posten opkaldt efter teamet — her »Helpdesk Categories«.Åbn billedet i fuld størrelse
Siden »Settings · Manage categories« med kortene »Main categories« og »Subcategories«.
Det er siden: hovedkategorier til venstre, underkategorier til højre. Kortet »Links« sidder længere nede på den samme side — det følger om lidt.Åbn billedet i fuld størrelse
Feltet »EN (required)« med ordet »Beamer« og knappen »New main category«, begge indrammet i rødt.
Én ad gangen: engelsk navn ind i feltet »EN (required)«, så klik på »+ New main category« nedenunder. På kortet »Subcategories« hedder knappen »+ New subcategory«.Åbn billedet i fuld størrelse
Kortet »Main categories« med knapperne »Export JSON« og »Import JSON« indrammet i rødt.
Til mange på én gang: hent strukturen, udfyld den, læg den op igen. Kortet »Subcategories« ved siden af har de samme to knapper.Åbn billedet i fuld størrelse
Kortet »Links«: »Printer« er valgt, underkategorierne Consumables, Malfunction og New request har flueben.
»Printer« valgt, de passende underkategorier afkrydset, »Save links« — »Malfunction« hænger samtidig på tre andre hovedkategorier.Åbn billedet i fuld størrelse
8

Hvordan sagen kom ind

Hver sag bærer en kanal. Den står i formularen og senere på kortet »Actions« under »How the request came in«, og den svarer på et spørgsmål, der hurtigt bliver vigtigt i rapporteringen: kommer arbejdet ind gennem portalen eller over telefonen?

Du kan kun vælge det, et menneske ved, og systemet ikke ved: »Phone« og »Entered by an agent«. De to andre værdier sætter systemet selv — »Self-service«, når anmelderen oprettede sagen i portalen, og »Email«, når den voksede ud af en indgående mail.

Det er også derfor, du ikke kan skifte en systemsat kanal til »Phone« bagefter: feltet ville miste præcis den oplysning, det findes for. Den anden vej rundt må du stadig ændre alt andet på en sag, der er registreret over telefonen.

Kun en agent eller en administrator må sætte kanalen. For anmelderen ville det være en udtalelse om hendes egen sag — og rapporteringen ville afhænge af, at alle er ærlige.

»Email« kræver en tilsluttet postkasse, og den er en del af Professional-udgaven. De tre andre kanaler findes i begge udgaver.

Den del af formularen med status, prioritet og feltet »How the request came in« indrammet i rødt.
Når en sag bliver oprettet, sidder kanalen mellem prioritet og observatører. Kun »Phone« og »Entered by an agent« bliver tilbudt.Åbn billedet i fuld størrelse
Kortet »Actions« på en sag, feltet »How the request came in« står på »Phone« og er indrammet i rødt.
På sagen sidder kanalen på kortet »Actions« — her en sag, en agent registrerede efter en telefonsamtale.Åbn billedet i fuld størrelse
10

At give en sag videre til et andet team

Kun i Professional

Før du går i gang: Begge veje kræver et andet team. Kunden ser intet af det: for hende bliver det ved med at være én sag med ét nummer, uanset hvor mange teams der har arbejdet på den.

Sagen tilbyder to knapper ved siden af hinanden til det, og forskellen står med småt nedenunder. »Involve another team«: du er stadig ansvarlig, det andet team arbejder ved siden af dig i en tilknyttet sag. »Escalate to another team«: det andet team overtager.

Når du giver videre, flytter ansvaret, uden at der opstår en sag nummer to. Dit team beholder læseadgang og må stadig kommentere, men kan ikke længere ændre noget — og præcis det fortæller dialogen dig, før du bekræfter. Der vælger du modtagerteamet og kan tilføje en begrundelse.

Når du inddrager et team, bliver din sag i dine hænder og får en undersag i det andet team. Din flytter til statussen »Waiting for other team«; når det andet team lukker sin, kommer din tilbage som »Back from other team«. Så du behøver ikke at spørge, om der er sket noget derovre.

Med hensyn til klassificeringen: det afgivende teams kategorier bliver stående på sagen, også når det nye team slet ikke har dem — de dukker op der med deres oprindelse, gråtonede. På den måde kan det nye team se, hvad sagen hidtil kørte som, og sortere den om til sin egen liste, hvis der er brug for det.

Kun den, der er ansvarlig lige nu, må give en sag videre. En tidligere station ser stadig sagen, men kan ikke sende den videre en gang til.

De to knapper »Involve another team« og »Escalate to another team« indrammet i rødt, med deres forklaringer nedenunder.
To veje, synligt adskilt: lad nogen arbejde ved siden af dig, eller giv videre. Forskellen står trykt lige ved knappen.Åbn billedet i fuld størrelse
Dialogen »Escalate to another team?« med valget af modtagerteam og feltet »Reason (optional)«.
Dialogen nævner følgen, før du bekræfter: ingen sag nummer to, læseadgangen bliver, kun det nye team må ændre noget.Åbn billedet i fuld størrelse
11

Brugerdefinerede felter

Kun i Professional

Når en oplysning mangler i jeres sager — aktivnummeret, garantiens udløb, omkostningsstedet — tilføjer du den selv. Under »Settings → Ticket Settings« sidder nederst kortet »Custom fields«; knappen hedder »Add custom field«.

I dialogen giver du et navn og en felttype: »Text«, »Multiline text«, »Integer«, »Decimal«, »Date« eller »Yes / No«. Typen bestemmer, hvad der kan tastes ind — et datofelt tager ikke imod »i næste uge«, og netop derfor kan du rapportere på det senere.

Under »Scope« bestemmer du, hvor feltet gælder: »All teams (including new ones)« eller »Selected teams only«. Det første valg dækker også teams, der endnu ikke findes — den slags forskel, man først opdager et halvt år senere.

De tre kontakter under »Defaults« gælder nye sager: »Mandatory by default«, »Hidden for customer by default« og »Not editable by customer by default«. De er udgangspunkter — feltindstillingerne på den samme side er stadig det sted, hvor du sætter det præcist per rolle.

På sagen sidder de brugerdefinerede felter på deres eget kort, »Additional information«, mellem beskrivelsen og kommentarerne. Uden en skabelon viser formularen alle teamets brugerdefinerede felter. Vælger du en skabelon, når du opretter en sag, viser den præcis de felter, skabelonen nævner, i dens rækkefølge — »kun de felter, denne sag har brug for«.

En skabelon kan desuden gøre et felt påkrævet, men den kan ikke ophæve en regel: det, administratoren har skjult for kunder eller erklæret påkrævet, bliver ved med at være det, også når en skabelon siger noget andet. Ellers ville en skabelon være en måde at melde sig ud af en husregel på.

Hvor mange brugerdefinerede felter et team må have, bliver sat under »Settings → General Settings« i kortet »Custom fields limit«. Du kommer af med et felt med »Deactivate«: det forsvinder fra formularen, men dets værdier bliver stående på de gamle sager — kontakten »Show deactivated« henter det tilbage i listen.

Kortet »Custom fields« med to felter og knappen »Add custom field« indrammet i rødt.
Listen over brugerdefinerede felter bor under »Settings → Ticket Settings«, nederst på siden.Åbn billedet i fuld størrelse
Dialogen »New custom field« med navn, felttype, omfang og de tre udgangspunkter.
Navn, felttype, omfang — mere skal et felt ikke bruge. De tre kontakter nedenunder er udgangspunkter for nye sager.Åbn billedet i fuld størrelse
Kortet »Additional information« på en sag med felterne »Asset tag« og »Warranty until«.
Sådan ser agenten de brugerdefinerede felter: deres eget kort på sagen, lige under beskrivelsen.Åbn billedet i fuld størrelse
12

Observatører

Kun i Professional

Nogle gange skal nogen følge en sag uden at arbejde på den: teamlederen i en delikat sag, kollegaen der overtager i næste uge. Det er, hvad observatører er til. På sagen sidder feltet »Observers« på kortet »Actions«, knappen hedder »Add observer«; formularen »Create new ticket« har det samme felt.

Kun agenter og administratorer fra et deltagende team kan vælges. En kunde kan ikke være observatør — hun ville ellers få mail om internt arbejde.

En observatør får en e-mail, når der sker noget på sagen: en ny kommentar, en ændret status, en ny tildeling, ændrede felter. Den bliver ikke sendt med det samme, men samlet: efter den sidste ændring venter systemet et minut og sender så ÉN mail, der dækker alt, hvad der skete i den tid. Så at arbejde en sag igennem i ét stræk udløser ikke syv mails.

Hvem der observerer, er en del af historikken: en ændring bliver noteret som enhver anden, med den gamle og den nye tilstand.

Beskeden er en e-mail — så udgående post skal være sat op (Professional). Uden det kan du indtaste observatører, men der går intet ud.

Kortet »Actions« på en sag med feltet »Observers« indrammet i rødt og én agent skrevet ind i det.
Observatøren sidder på kortet »Actions«. Sagen er ikke tildelt nogen — at observere og at arbejde på en sag er to forskellige ting.Åbn billedet i fuld størrelse
13

Sager fra e-mail, svar og opfølgninger

Kun i Professional

Før du går i gang: Hos Google/Gmail skal du bruge en app-adgangskode (og den kræver tofaktorlogin); Google afviser almindelige kontooplysninger. Microsoft 365 virker slet ikke lige nu: basic authentication for IMAP er slået fra der, og app-adgangskoder hjælper heller ikke.

Mailkanalen er én vej med to retninger, og de hører sammen: en indgående mail bliver til en sag, dit svar går ud som mail, og anmelderens svar lander som kommentar på den samme sag — ikke på en nummer to.

Sammenkoblingen sker ikke på fornemmelsen: et svar lander kun på den eksisterende sag, når mailen bærer sagens henvisning i emnefeltet eller har mailprogrammets svarhoveder med sig. En mail med ingen af delene starter en ny sag — hellere én sag for meget end to sager, der intet har med hinanden at gøre, slået sammen bare fordi emnet tilfældigvis passede.

Alt til det sidder under »Settings → E-Mail Settings«. Det øverste kort, »SMTP settings«, er vejen ud: vært, port, »Use SSL«, bruger og adgangskode, dertil afsenderadressen og afsendernavnet. Med »Send test e-mail« sender du dig selv en prøve — gem først, test så, som kortet selv siger.

Kortet »IMAP settings« er vejen ind: vært, port, hentningsintervallet og de to mapper. Du behøver ikke at gætte mappenavnet: »Read from server« henter de mapper, der virkelig findes i din postkasse, »Create on server« opretter en ny. Feltet tager så den sti, din mailserver bruger til den — én server skriver »INBOX/Processed«, den næste »INBOX.Processed«, og begge dele betyder det samme.

Behandlet post flytter ind i »Processed folder«; lader du feltet stå tomt, bliver den i indbakken. Nedenunder sætter du, hvornår oprydningen kører (»Hour«, »Minute«), og hvor gammel en besked må blive (»Retention (days)«) — ellers vokser postkassen stille og roligt.

Postkasser hører til teamet, ikke til systemet: under »Team mailboxes« indtaster hvert team sin egen adresse med en adgangskode. Den adresse er samtidig afsenderen på det teams mails — så anmelderen svarer det samme sted hen, som posten bliver hentet fra.

Og nu den del, uden hvilken intet af det sker: workflowet. En opsat postkasse gør slet ingenting i sig selv. Har et team intet slået workflow til, bliver postkassen ikke engang hentet — ingen sag, ingen kvittering, mailene bliver bare liggende. Det automatiske svar til jeres kunder findes kun her, og du sætter det selv op. Det er med vilje: et system, der uopfordret skriver til hver afsenderadresse, ville være værre end et, der tier stille.

Under »E-Mail workflows« vælger du teamet øverst og opretter et workflow med »+ Add workflow«. Det får et navn (kun til dig), en »Enabled«-kontakt og to udsagn om, hvornår det gælder: »Match« bestemmer, om alle betingelser skal være opfyldt (»All conditions«), eller om én er nok, og »Stop after match« afslutter kørslen, så snart dette workflow har passet — et workflow længere nede kommer så aldrig til. Rækkefølgen ændrer du med pilene ved siden af.

Under »When?« sidder selve betingelsen. »Every e-mail in this mailbox« tager hver mail; »Only when subject or text contains« kræver et ord i emnet eller teksten. »Advanced« gør det præcist: der vælger du, hvad der bliver kigget på — »Subject or body«, »Subject«, »Body«, »Sender (From)« eller »Recipient (To/Cc)« — og hvordan der bliver sammenlignet: »Contains«, »Equals« eller »Regex«. Sådan skiller du for eksempel anmeldelser til en fælles adresse fra alt det andet.

Nedenunder sidder fem handlinger som kontakter. De er workflowets egentlige indhold — det, der ikke er slået til, sker ikke:

»Create or append ticket« gør mailen til en sag — eller føjer den som kommentar til en eksisterende, når henvisningen står i emnet. Uden denne handling bliver en mail aldrig til en sag.

»Set fields« sætter prioritet, status, hoved- og underkategori, ejerteam og sagsbehandler allerede når sagen bliver oprettet. Alt, der står på »— Keep default —«, bliver, som det ville være uden et workflow.

»Auto-reply« er kvitteringen til afsenderen — det eneste sted, hvor systemet svarer af sig selv. Med denne kontakt slået fra får din kunde aldrig et automatisk svar, uanset hvor godt alt andet er sat op.

»Send mail« sender en ekstra mail: enten til afsenderen af den indgående mail eller til udvalgte teammedlemmer og faste adresser. Den har sine egne »Send conditions« — lader du dem stå tomme, går den ud ved hver kørsel af dette workflow.

»Move to folder« lægger den behandlede mail i en mappe. Lad feltet stå tomt, og den generelle »Processed folder« fra IMAP-indstillingerne ovenover gælder.

Handlingen »Auto-reply« i detaljer: emnet bygger du af klodser. »Original subject {originalSubject}« overtager emnet fra den indgående mail, »Ticket reference {ticketTag}« indsætter sagens henvisning — sammen giver de noget i retning af »Printer problem [TICKET-99]«.

Henvisningen bliver ikke tilføjet af sig selv. Den dukker kun op, hvor du sætter {ticketTag} eller {ticketId} — og det er præcis det, systemet senere genkender din kundes svar på. Står den ikke i emnet, starter hver opfølgning en ny sag i stedet for at blive til en kommentar på den gamle.

Teksten nedenunder er din kvitteringsbesked. Skriv den på engelsk: den løber gennem den samme eksport og import som hver anden tekst, og kun på den måde kan den oversættes til de andre sprog. Lad den stå tom, og systemet sender sin egen standardbesked. De samme pladsholdere er tilladt her også.

»Reply language« bestemmer, hvilket sprog emnet og teksten går ud på: »Standard English« bruger engelsk, »Fixed language« et sprog, du vælger, »Assigned agent's language« den tildelte agents sprog, og »Team default language« teamets standard. Selve oversættelserne bliver vedligeholdt på sprogsiden.

Ét råd, som systemet også skriver over kortet: alt, der hører til én sag, hører til i ÉT workflow. Kun handlinger inden for det samme workflow kender den sag, der lige er oprettet — derfor kan kvitteringen nævne sit nummer, og en handling fra et andet workflow kan ikke.

Hele mailkanalen — ind og ud — er en del af Professional-udgaven. I Basic sender og modtager systemet ingen e-mail; sager bliver der oprettet gennem portalen, telefonen og agenten.

Kortet »SMTP settings« med vært, port, bruger, adgangskode, afsenderadresse og knappen »Send test e-mail«.
Vejen ud. Hvert felt bærer sin forklaring nedenunder — portene 587 og 465 er nævnt der udtrykkeligt.Åbn billedet i fuld størrelse
Kortet »IMAP settings« med knapperne »Read from server« og »Create on server« indrammet i rødt.
Lad være med at taste mappen, hent den: »Read from server« lister de virkelige mapper, »Create on server« opretter en ny under indbakken.Åbn billedet i fuld størrelse
Afsnittet »Team mailboxes« med Helpdesk-teamets postkasse.
Én postkasse per team. Adressen er også afsenderen — og derfor bor den her og ikke i de generelle indstillinger.Åbn billedet i fuld størrelse
Et workflow med sit navn, »Match«, »Stop after match«, betingelsen under »When?« og de fem handlingskontakter indrammet i rødt.
De fem handlinger er indrammet i rødt. I dette eksempel er »Create or append ticket«, »Auto-reply« og »Move to folder« slået til — »Set fields« og »Send mail« er slået fra. Uden et workflow som dette bliver postkassen slet ikke hentet.Åbn billedet i fuld størrelse
Handlingen »Auto-reply« med emnefeltet indrammet i rødt, byggeklodserne, den engelske tekst og valget af svarsprog.
Emnet rummer klodserne »{originalSubject} {ticketTag}« — det er det, systemet senere genkender kundens svar på. Nedenunder teksten og svarsproget, her den tildelte agents.Åbn billedet i fuld størrelse

Agentstatus (tilgængelighed)

Hver agent viser, om hun er tilgængelig lige nu, og når du tildeler en sag, står tilstanden ved siden af navnet. Alt i denne blok er en del af Basic. Den automatiske fordeling, der springer fraværende agenter over, er en selvstændig funktion og en del af Professional.

1

Tilgængelig, optaget, væk

Hver agent har en af tre tilstande og sætter den selv, i brugermenuen nederst til venstre i sidemenuen. De tre poster står under overskriften »Availability«.

En prik viser tilstanden. »Available« bærer en grøn prik, »Busy« en ravgul, »Away« en tom ring.

De tre adskiller sig ikke kun i farven, men også i fyldet, så en, der har svært ved at skelne farver, alligevel ser forskellen.

Din egen prik sidder på dit kontobillede nederst til venstre, så du ikke skal åbne menuen for at se den.

Når du tildeler en sag, står tilstanden efter navnet. Er der noteret en slutdato for fraværet, står den der også.

En agent, der ikke er tilgængelig, kan stadig vælges og bliver kun markeret som sådan. Om sagen alligevel går til hende, er din beslutning.

Du får kun agenterne fra det team, sagen hører til, tilbudt.

Kun agenter og administratorer har en tilstand. En kunde har ikke nogen.

Mere om det på kortet: Tildel flere sager til én agent på én gang

Brugermenuen i sidemenuen med de tre tilstande »Available«, »Busy« og »Away« og et flueben ved den aktuelle.
Agentens egen brugermenu. De tre tilstande står allerøverst, den gældende bærer et flueben. Den samme prik sidder på kontobilledet nedenunder.Åbn billedet i fuld størrelse
Vælgeren »Assign to« på en sag, åbnet, med teamets agenter og markeringen »Away until« på én post.
Den røde ramme sidder på Lena Chens post. Efter navnet står hendes tilstand og slutdatoen for fraværet. Hun kan stadig vælges. Kun agenterne fra det team, sagen hører til, bliver tilbudt.Åbn billedet i fuld størrelse
2

Sygdom og ferie taster en administrator ind

Den, der er syg, melder sjældent fra først. Derfor kan en administrator sætte tilstanden for en anden, i kontoens redigeringsformular under »User management«.

Formularen har to felter til det. »Availability« rummer tilstanden, »Away until« rummer slutdatoen for fraværet.

Det andet felt dukker kun op ved »Away«. Der er ingen slutdato at taste ind ved »Busy« eller »Available«.

Uden en dato varer fraværet, indtil nogen afslutter det. Med en dato slutter det af sig selv. Hjælpeteksten under feltet siger det: »Leave empty for an absence without a set end.«

En dato i fortiden bliver ikke accepteret. Den ville være udløbet med det samme, og din kollega ville stadig stå i listen som tilgængelig.

Begge felter dukker kun op for agenter og administratorer. Sætter du rollen til »Customer« i den samme formular, forsvinder de.

Ét felt bærer begge dele. En sygedag og tre ugers ferie er det samme for systemet, med en forskellig dato.

Kontoens redigeringsformular med felterne »Availability« sat til »Away« og »Away until« med en dato i.
De røde rammer sidder på de to felter. De står allernederst i formularen, og kun for agenter og administratorer.Åbn billedet i fuld størrelse
3

»Busy« nulstiller sig selv efter en time

»Busy« varer en time. Derefter er agenten tilgængelig igen uden at skulle gøre noget.

Menuen viser den resterende tid ved siden af tilstanden, for eksempel »60 min left«.

Timen ligger fast. Den er et sikkerhedsnet mod at glemme det, ikke en driftsregel. Den, der er utilgængelig længere, vælger »Away«.

Nulstillingen er et tidspunkt, ikke en opgave. Kontoen rummer det øjeblik, tilstanden slutter, og tilstanden bliver regnet ud, når nogen læser den. Var serveren slukket i den time, er agenten simpelthen tilgængelig igen bagefter. Der bliver ikke efterladt en pukkel, som en baggrundstjeneste skal indhente.

»Away« udløber kun, hvis der er noteret en slutdato. Uden en bliver den stående, indtil nogen ændrer den.

Når agenter sætter sig selv til »Away«, får tilstanden ingen slutdato. Kun en administrator uddeler en slutdato.

Brugermenuen med tilstanden »Busy«, den resterende tid »60 min left« og fluebenet ved siden af.
Den røde ramme sidder på den gældende tilstand. Fluebenet står til højre, den resterende tid ved siden af tilstanden. Prikken på kontobilledet er ravgul nu.Åbn billedet i fuld størrelse
4

Ingen historik over tilgængelighed og ingen opgørelse per person

Systemet husker kun, hvilken tilstand der gælder lige nu. Det noterer ikke, hvem der var optaget eller væk hvornår.

Derfor viser brugerlisten tilstanden som nu og intet mere. Der findes ingen kolonne med en historik og ingen rapport om tilstedeværelse.

Det er en beslutning, ikke en manglende brik. Data om tilgængelighed per person er adfærdsdata, og i mange virksomheder har samarbejdsudvalget medbestemmelse på det.

Der er heller ikke brug for en historik. Tilstanden svarer på ét spørgsmål: er denne kollega tilgængelig lige nu? »Busy« slutter af sig selv efter en time.

Hvor mange sager en agent har, ser du i sagslisten, hvor »Assigned to« filtrerer på én person. Hvor længe nogen var væk, står ingen steder skrevet.

Brugerlisten med en farvet prik foran agenternes navne og kolonnerne Name, Email, Team, Role og Actions.
De røde rammer sidder på to agenter, der ikke er tilgængelige. Listen viser tilstanden som nu. Der findes ingen kolonne med en historik.Åbn billedet i fuld størrelse

Automatisk fordeling af sager

En ny sag kan få en ejer med det samme. Systemet bruger den tilgængelighed, der er forklaret i blokken før, fordelingen bliver slået til per team, og den er slået fra som fabriksindstilling. Hele denne blok er en del af Professional.

1

Fordelingen hører til teamet

Kun i Professional

Uden en fordeling lander hver ny sag i puljen. Nogen skal tage den, eller nogen skal dele den ud, og begge dele virker, så længe nogen holder øje.

Slå fordelingen til, og hver ny sag får en ejer, mens den bliver oprettet. Det sker med det samme og ikke et par minutter senere.

Indstillingen sidder på teamet under »Settings → Teams«, og hvert team bestemmer selv. Ét team kan fordele, mens teamet ved siden af arbejder ud af puljen.

Som fabriksindstilling står hvert team på »Off«. Et bestående miljø ændrer ikke opførsel, bare fordi funktionen findes.

Sager går til teamets medlemmer. En administrator, der arbejder i køen og er medlem af det team, får sager præcis som en agent.

Afsnittet »Automatic assignment« i Helpdesk-teamets dialog, sat til »Round robin«, med to forklarende sætninger nedenunder.
Indstillingen sidder på teamet. Under feltet forklarer én sætning den valgte fremgangsmåde, og nedenunder står, hvem der bliver sprunget over.Åbn billedet i fuld størrelse
Det åbne valgfelt med sine tre poster »Off«, »Round robin« og »Least load«.
Tre poster at vælge imellem. »Off« er fabriksindstillingen.Åbn billedet i fuld størrelse
2

Rundt på skift eller mindst belastet

Kun i Professional

Der findes to fremgangsmåder, og du vælger én per team.

»Round robin« går rundt på skift. Den nye sag går til den tilgængelige agent, hvis sidste automatiske tildeling ligger længst tilbage, så en, der lige er kommet med i teamet, står forrest.

»Least load« ser på skrivebordet. Den nye sag går til den tilgængelige agent med færrest åbne sager.

En sag, der venter på anmelderen, tæller halvt. En med mange åbne spørgsmål er ikke optaget på samme måde som en med en bunke friske hændelser.

En løst eller lukket sag tæller slet ikke længere med. Det gælder også en status, du selv har oprettet, så længe den er markeret som løst eller lukket.

Resultatet kan regnes ud i begge fremgangsmåder. Står to agenter lige, afgør altid den samme regel, aldrig tilfældet.

Det samme afsnit i netværksteamets dialog, sat til »Least load«, med sætningen om sager, der tæller halvt.
Det samme felt på et andet team, her på »Least load«. Sætningen nedenunder ændrer sig med indstillingen.Åbn billedet i fuld størrelse
3

Den, der ikke er der, får ingenting

Kun i Professional

Før hver tildeling spørger fordelingen efter agentens tilstand. »Busy« og »Away« bliver sprunget over.

Låste og slettede konti kommer heller ikke i betragtning, og det gør ingen, der ikke er medlem af det team, sagen hører til.

Er ingen tilgængelig, bliver sagen uden ejer, og oprettelsen går alligevel igennem som normalt.

Det er med vilje. Alle ser en sag i puljen, og ingen ser en sag, der ligger hos en, som er væk.

Sagens historik bærer grunden: der står »(nobody available)« i stedet for et navn.

Mere om det på kortet: Tilgængelig, optaget, væk

Historikken på en sag med en »Auto-assignment«-post, der nævner »(nobody available)« i stedet for en person.
Ingen var tilgængelig, og sagen blev i puljen. Den røde ramme sidder på den post, der nævner grunden.Åbn billedet i fuld størrelse
4

Hvad fordelingen rører ved, og hvad den ikke rører ved

Kun i Professional

Fordelingen virker på hver vej, en sag bliver til ad, og det gælder også sager fra e-mailindbakken.

Den virker på samme måde på en ansøgnings undersager: hver enkelt bliver fordelt inde i det team, der får den.

En sag, et menneske har tildelt, rører fordelingen aldrig. Vælger du selv en ejer, mens du opretter en sag, står dit valg ved magt.

Hver automatisk tildeling bliver noteret i sagens historik, med »Auto-assignment« som forfatter og agentens navn ved siden af.

Agenten får den samme mail som ved en tildeling i hånden. Står sagen stadig på »Open«, flytter den til »Assigned«.

Mere om det på kortet: En e-mail bliver til en sag

Historikken på en sag med to »Auto-assignment«-poster: tildelingen til en agent i teamet og statusskiftet fra »Open« til »Assigned«.
Historikken nævner automatikken. Den tildelte sagen og flyttede statussen med det samme.Åbn billedet i fuld størrelse
5

Rapporten om fordelingen

Kun i Professional

Den, der kører en automatik, skal kunne kontrollere, hvad den gør. Der findes et kort til det på rapportsiden.

To tal står øverst. Til venstre hvor mange sager automatikken delte ud, til højre hvor tit ingen var tilgængelig.

Ved siden af tallet til højre står numrene på de sager, det skete for, så ét klik fører dig hen til stedet selv.

Nedenunder står én linje per agent med hendes tal og hendes tilgængelighed. Linjerne kommer fra medlemskabet af teamet.

En linje med et nul er derfor ikke en fejl. Det er det, tabellen er til.

En, der har stået på »Away« i ugevis, har ikke fået nogen sager og står der stadig, med grunden ved siden af nullet.

Dette kort er en log over maskinen og ikke en bedømmelse af mennesker. Der findes ingen historik over tilgængelighed og ingen rapport om, hvem der var til stede hvor længe.

Mere om det på kortet: Ingen historik over tilgængelighed, ingen opgørelse per person

Rapportsiden med kortet »Automatic assignment« blandt de øvrige rapporter.
Kortet sidder på rapportsiden. Den røde ramme viser, hvor det er at finde.Åbn billedet i fuld størrelse
Boksen »Nobody available« med sit tal, en forklarende sætning og nummeret på den sag, det skete for.
Det andet tal står ved siden af det første med den samme vægt. Nedenunder står numrene på de sager, der blev i puljen.Åbn billedet i fuld størrelse
Rapporttabellen med seks agenter, deres tal og deres tilgængelighed, inklusive én linje med et nul og en »Away«-bemærkning.
Én linje per agent. Den røde ramme sidder på den linje med nullet, der bærer sin grund ved siden af.Åbn billedet i fuld størrelse

Ansøgninger med opgaver og godkendelse

Nogle henvendelser er ikke én sag. En ansøgning opretter sine opgaver, når den bliver sendt, hver som sin egen sag i det team, der håndterer den, og godkendelser er mulige, men ikke obligatoriske. Hele denne blok er en del af Professional.

1

En ansøgning opretter sine egne opgaver

Kun i Professional

»En ny kollega starter« er ikke én sag. Det er en bærbar, to konti, et telefonnummer og måske adgang udefra. Hver del hører til et forskelligt team, og du vil alligevel have én sag, der fortæller dig, hvor det står.

Det er, hvad en ansøgning er til. Den er en sag, der opretter sine opgaver i det øjeblik, den bliver sendt, og hver opgave bliver til sin egen sag i det team, der håndterer den.

En ansøgning er ikke endnu en ting at vedligeholde. Den bor på en sagsskabelon: under »Settings → Request workflows« finder du hver sagsskabelon, og du hænger opgaverne på en af dem.

For hver opgave sætter du fire ting. »Task« er det navn, anmelderen læser, »Handled by« er det team, der får den, og »Ticket title« og »What the team has to do« udfylder den sag, der kommer ud af det.

Flere opgaver må gerne pege på det samme team. Det team får så flere sager, ikke én sag med en liste inde i sig.

En opgave uden et team bliver slet ikke tilbudt. Feltet siger det selv: »Not assigned yet — this task is not offered«. På den måde kan du gemme en plan, der ikke er færdig endnu.

Over opgaverne står en sætning, der samler hele planen: hvad der bliver oprettet som fabriksindstilling, hvor meget anmelderen må ændre, og hvem der frigiver det. Ændr en indstilling, og sætningen skriver sig selv om.

Listen over sagsskabeloner under »Request workflows«, hver med sit antal opgaver og en »Edit tasks«-knap.
Hver sagsskabelon ét sted, hver med hvor mange opgaver den bærer. Den røde ramme sidder på vejen ind i planen.Åbn billedet i fuld størrelse
Planen med sin sammenfattende sætning og de første opgaver, hver med et navn, et team og en valgtilstand.
Øverst sætningen, der samler planen, nedenunder opgaverne, hver med sit team og sin valgtilstand.Åbn billedet i fuld størrelse
2

Anmelderen sætter flueben ved det, hun har brug for

Kun i Professional

Når nogen vælger skabelonen i formularen til en ny sag, dukker boksen »What is needed?« op med én linje at sætte flueben ved per opgave.

Der findes tre slags, sat per opgave. »Selectable, off by default« starter tom, »Selectable, on by default« starter med flueben og kan fravælges, og »Always — cannot be deselected« kører altid.

En opgave, der altid kører, bliver alligevel vist, markeret »(always included)«. Anmelderen bør se, hvad der sker under alle omstændigheder.

Under boksen læser du, hvad der kommer ud af det: »Each selected item becomes its own ticket for the team that handles it.«

En kunde kan også sende en ansøgning, så længe skabelonen er frigivet til kunder. Kontakten til det sidder på skabelonen.

Kunden ser så kun sin egen ansøgning. Sagerne i specialistteamene bliver skjult for hende, selv om hendes ansøgning oprettede dem — de sager bærer adgangsoplysninger og interne noter.

Mere om det på kortet: Sagsskabeloner kan frigives til kunder, én ad gangen

Boksen »What is needed?« i formularen til en ny sag med fire opgaver at sætte flueben ved.
Boksen i anmelderens formular til en ny sag. Den første linje kører altid og kan ikke fravælges, den anden har flueben som fabriksindstilling, og nedenunder står, hvad hvert flueben bliver til.Åbn billedet i fuld størrelse
3

Fremdriften på ansøgningen

Kun i Professional

På selve ansøgningen står opgaverne under »Workflow tasks«, med antallet ved siden af, for eksempel »1 of 4 done«.

Hver række viser opgavens navn, nummeret på dens sag, teamet og sagsbehandleren, og navnet er et link ind i den sag.

»Klaret« kommer fra sagens status, ikke fra et særskilt flueben. Det, der tæller som lukket i sagslisten, tæller som klaret her — to måder at tælle det samme på ville før eller siden glide fra hinanden.

Blokken dukker kun op på en ansøgning. En almindelig sag viser den ikke.

Blokken »Workflow tasks« på ansøgningen med fire opgaver, deres sagsnumre og teams.
Den røde ramme sidder på rækken med antallet. Nedenunder viser hver opgave, hvilken sag og hvilket team den sidder i; fluebenet til venstre kommer fra statussen.Åbn billedet i fuld størrelse
4

Én godkendelse til hele ansøgningen

Kun i Professional

En godkendelse dækker hele ansøgningen, ikke hver enkelt opgave. Otte programmer er én mail til lederen, ikke otte.

Det sætter du op under »Approvals« i den samme plan, og sætningen ovenover nævner reglen: »One approval covers the whole request. Add a second stage only when single tasks need their own release.« Hvert trin har tre indstillinger: »Covers« siger, hvad det gælder, »Decided by« siger, hvor godkenderen kommer fra, og »Approver« rummer personen.

Godkenderen behøver ingen konto i ticketsystemet: du indtaster en e-mailadresse, og hun beslutter over et link. En leder, der godkender to gange i kvartalet, koster derfor ingen agentplads.

Mailen indeholder præcis ét link til en side. Der er bevidst ingen godkend- eller afvis-knapper i selve mailen: en virusscanner, der åbner hvert link, ville ellers godkende.

Siden hedder »Approval request«. Den viser ansøgningens nummer og titel, anmelderen, og under »This decision covers« de opgaver, beslutningen handler om, med et kommentarfelt og de to knapper nedenunder.

Linket holder ikke evigt, og siden nævner fristen: »Please decide by …«.

En beslutning kan ikke tages tilbage, og bagefter siger siden det: »A decision cannot be changed.«

Afsnittet »Approvals« i planen med to trin, hver med et navn, en adresse og en påmindelse.
To trin på én plan: det første dækker hele ansøgningen, det andet kun de opgaver, der peger på det. Godkenderen er en adresse, ikke en konto.Åbn billedet i fuld størrelse
Godkendelsesmailen i postkassen med ét enkelt link til beslutningssiden.
Sådan når ansøgningen frem til godkenderen. Mailen rummer ét link og intet andet at klikke på; beslutningen sker på siden bagved.Åbn billedet i fuld størrelse
Siden »Approval request« med ansøgningen, anmelderen, den dækkede opgave, kommentarfeltet og knapperne »Approve« og »Reject«.
Beslutningssiden. »This decision covers« siger, hvad det handler om. Godkenderen er ikke logget ind og har ingen konto.Åbn billedet i fuld størrelse
5

Et andet trin til enkelte opgaver

Kun i Professional

Nogle opgaver kræver en frigivelse for sig. Adgang udefra er ikke det samme som en bærbar.

Til det tilføjer du et andet trin og vælger det på opgaven under »Extra approval«. Så længe der står »None — the request approval is enough«, er frigivelsen af ansøgningen alt, hvad der skal til. Begge trin bliver spurgt samtidig, ikke det ene efter det andet.

En opgave er frigivet, når hvert trin, der angår den, har sagt ja. De øvrige opgaver går i gang, så snart ansøgningen selv er godkendt.

Indtil da er opgaven låst: dens sag står på »Waiting for approval«, har ingen sagsbehandler, og statusvælgeren tilbyder ingenting.

Låsningen holder også for massehandlinger på sagslisten. Vælger du sådan en sag der, læser du grunden: »This task is waiting for approval and cannot be worked on yet.«

Sagen bliver alligevel oprettet med det samme, så specialistteamet ser, hvad der er på vej, og ingen skal holde øje med ansøgningen.

Handlingskortet på en låst opgave med statussen »Waiting for approval« og en tom statusvælger.
Opgaven, der venter på sit eget trin. Den røde ramme sidder på den aktuelle status; ovenover står en streg, fordi ingen overgang bliver tilbudt.Åbn billedet i fuld størrelse
6

En påmindelse, men ingen frigivelse på tid

Kun i Professional

Du kan sætte en påmindelse per trin, angivet i timer.

Kommer der intet svar, går den samme mail ud igen efter den tid, med det samme link som den første. Den, der gemte den første mail, kan stadig bruge den.

Uden en påmindelse venter ansøgningen simpelthen, uden at spørge igen.

Det, der ikke findes, er en frigivelse ved udløb. Under feltet står det med rene ord: »A request is never approved automatically. If nobody reacts, it keeps waiting.« En frist, der siger ja af sig selv, ville ikke være en godkendelse, den ville være en formalitet.

Ét godkendelsestrin med påmindelsesfeltet, angivet i timer, indrammet i rødt.
Påmindelsen hører til trinnet og bliver angivet i timer. Lad den stå tom, og systemet spørger ikke igen.Åbn billedet i fuld størrelse
7

Et afslag når anmelderen med sin begrundelse

Kun i Professional

Et afslag kræver en begrundelse. Uden en tekst tager siden ikke imod afslaget.

Feltet siger, hvor teksten går hen: »Comment (required when you reject — the requester will see it)«. En intern note hører ikke til her.

Anmelderen får en e-mail med begrundelsen og behøver ikke at spørge, hvorfor der ikke sker noget.

En godkendelse kræver ingen begrundelse. Det er det forventede udfald.

Er det kun et andet trin, der afviser, angår afslaget kun det trins opgaver. Resten af ansøgningen kører videre.

En afvist opgave får statussen »Rejected« og tæller som afsluttet, så ansøgningen ikke hænger for evigt på noget, der aldrig kommer.

Beslutningssiden efter afslaget, med »You rejected this request.« og bemærkningen om, at en beslutning ikke kan ændres.
Efter beslutningen: siden bekræfter, hvad godkenderen gjorde, og siger, at det står ved magt.Åbn billedet i fuld størrelse
8

Revisionssporet og godkenderen på ferie

Kun i Professional

På ansøgningen viser »Approvals« én række per trin med godkenderen, tilstanden, og ved en åben ansøgning hvor længe den har ventet.

Efter beslutningen viser rækken, hvornår den blev truffet, og med hvilken kommentar. Det er revisionssporet, og det bliver hos sagen.

Er godkenderen på ferie, flytter en administrator ansøgningen til en anden adresse. Knappen hedder »Reassign« og dukker kun op, mens ansøgningen er åben.

Kun en administrator må det. En agent, der kunne flytte den, ville kunne flytte den til sig selv og så beslutte.

En flytning laver et nyt link, og det gamle dør med det samme — også hvis nogen har sendt det videre.

Selve flytningen står i den samme liste: hvem der flyttede den, hvornår, fra hvem til hvem.

Ingen kan beslutte i en andens navn. Linket er den eneste vej, og hvem der fik det, står noteret på sagen.

Dialogen »Reassign«, der beder om den nye adresse, med feltet udfyldt.
Dialogen beder om den adresse, ansøgningen skal gå til i stedet. Du bekræfter med det samme ord, der åbnede den.Åbn billedet i fuld størrelse
Listen »Approvals« med det godkendte første trin, det afviste andet trin, begge kommentarer og bemærkningen om flytningen.
Begge trin med deres beslutning, deres tidspunkt og deres kommentar. Den røde ramme sidder på det trin, der blev flyttet, og nedenunder står, hvem der flyttede det fra hvem til hvem.Åbn billedet i fuld størrelse

Svar- og sagsskabeloner

To slags skabeloner til to øjeblikke: en svarskabelon udfylder kommentarfeltet på en åben sag, en sagsskabelon udfylder formularen til en ny sag. Begge er en del af Basic. Kun det at sende et svar som e-mail afhænger af mailkanalen og dermed af Professional — selve skabelonen gør ikke.

1

Svarskabeloner: tekst og felthandlinger (status, tildeling, prioritet …) i ét valg

Før du går i gang: At styre og at anvende er to forskellige rettigheder. Administratorer og agenter kan begge dele som fabriksindstilling. At anvende står åbent for alle, der må arbejde på sagen. Også selv om en rolle ikke må styre indstillingerne, kan den stadig anvende en skabelon.

Skabeloner bor under »Settings → Templates«. Linjen under overskriften siger, hvad de gør, og hvad de ikke gør: »Reply templates fill the comment editor and suggest field actions. Nothing is sent automatically.« En skabelon er et forberedt træk, ikke en maskine — du sender den altid selv.

Der findes to slags, og du vælger én, når du opretter den: »Add reply template« til svaret på en åben sag, »Add ticket template« til formularen til en ny sag. Slagsen kan ikke ændres bagefter, fordi den bestemmer, hvilke felter formularen overhovedet viser. Mærkningen over hver skabelon fortæller dig, hvilken du ser på: blå »Reply template«, grøn »Ticket template«.

En svarskabelon består af svarteksten (»Reply text«), fluebenet »Internal note« og et vilkårligt antal handlinger. Der findes seks handlinger: »Set the status«, »Set the priority«, »Assign to a user«, »Remove the assignee«, »Hand over to another team« og »Set a follow-up«.

Listen »Assign to a user« begynder med posten »The agent who applies it«. Tag den, når flere deles om skabelonen: sagen tilhører så den, der anvendte den, ikke én fast person fra listen. »Set a follow-up« beder om et antal og en enhed (minutter, timer, dage, arbejdsminutter, arbejdstimer, arbejdsdage) plus den note, der senere fortæller dig, hvorfor sagen er tilbage.

Den blå boks for enden af hver skabelon skriver i én sætning ned, hvad den vil gøre — for eksempel »Inserts the text as a public comment, sets status to Waiting for Service Provider Response, assigns to the applying agent, sets a follow-up in 3 days.« Sætningen bygger sig selv om, mens du retter. Den er din kontrol: siger den noget andet, end du havde tænkt, er én indstilling forkert.

Tekst er ikke påkrævet. »Giv den her videre til netværksteamet uden at skrive et ord« er en gyldig skabelon — sætningen lyder så »Suggests actions without a reply text«.

Siden »Templates« med de rødt indrammede knapper »Add reply template« og »Add ticket template«.
Slagsen vælges, når du opretter den: to knapper i stedet for en kontakt. Nedenunder ligger skabelonerne åbne — hver med sin mærkning og sit omfang.Åbn billedet i fuld størrelse
De tre handlingsrækker i en svarskabelon, indrammet i rødt, med den blå sætning i almindeligt sprog nedenunder.
Tre handlinger på én skabelon: status, tildeling til den, der anvender den, påmindelse om tre dage. Sætningen nedenunder siger det samme i ét stykke.Åbn billedet i fuld størrelse
2

Foreslåede handlinger kan fravælges enkeltvis før afsendelsen

På en åben sag sidder knappen »Template« over kommentarfeltet. Et klik åbner søgningen med forslag (»Search templates…«), og vælger du en, bliver kommentarfeltet udfyldt. Der sker ikke andet, og linjen nedenunder siger det: »Nothing happens until you add the comment.«

Hver af skabelonens handlinger bliver til en brik ved siden af knappen — i almindeligt sprog, ikke i fagsprog: »sets status to Waiting for Service Provider Response«, »assigns to the applying agent«, »sets a follow-up in 3 days«. Klikker du på en brik, bliver den streget over: den er fravalgt og kører ikke. Et klik til henter den tilbage.

Fravalgte handlinger bliver streget over, ikke fjernet. Det holder det synligt, hvad skabelonen ville have foreslået — og det holder beslutningen omgørlig, så længe du ikke har sendt.

Hvilke brikker der starter som aktive, bestemmer skabelonen: i indstillingerne bærer hver handling en »Suggested«-kontakt. Den kontakt er forslaget til hvert tilfælde; brikken på sagen er beslutningen for netop dette.

»×« bag brikkerne fjerner skabelonen igen. Teksten bliver i redigeringsfeltet — du har måske allerede skrevet den om; kun virkningen forsvinder, altså handlinger, mail og vedhæftede filer.

Du sender med den sædvanlige kommentarknap. Først da bliver kommentaren oprettet, og først derefter kører de handlinger, der stadig er aktive.

Kommentarfeltet på en sag med knappen »Template«, tre brikker ved siden af — den sidste streget over — og den indsatte tekst nedenunder.
To handlinger kommer til at køre, den tredje er fravalgt: påmindelsen om tre dage passer ikke til denne sag, resten gør. Teksten står i redigeringsfeltet og kan stadig ændres.Åbn billedet i fuld størrelse
3

Pladsholdere (anmelder, sagsnummer, titel …) – når skabelonen sættes ind, kommer de rigtige værdier ind i teksten

Svarteksten må bruge fem pladsholdere; listen står under feltet: »{requesterName}, {ticketId}, {ticketTitle}, {ticketRef}, {agentName}«. Skriv dem med krøllede parenteser, præcis som de står der.

»{ticketRef}« er sagens henvisning i formen »[TICKET-8-…]«. Det er den, systemet genkender en kundes svar på, når det kommer tilbage på e-mail. »{ticketId}« er derimod bare det nøgne nummer.

De bliver løst, når skabelonen ANVENDES, ikke når den gemmes: indstillingssiden bliver ved med at vise »{requesterName}«, kommentarfeltet på sagen viser det rigtige navn. Grunden er praktisk — at løse dem ved gemningen ville brænde ÉN sags værdier fast i skabelonen for altid.

På den måde læser du den færdige tekst, før noget forlader huset. Passer tiltalen ikke, ændrer du den i redigeringsfeltet som enhver anden tekst.

Hvem der tæller som »anmelder«, bestemmer sagen, ikke kontoen: den anmelder, der er noteret på sagen, kommer før den konto, der oprettede den. Opretter en agent en sag for en kollega efter en telefonsamtale, hilser svaret stadig på kollegaen og ikke på agenten.

En forkert skrevet pladsholder bliver afvist ved gemningen, og den bliver nævnt: »Reply text: unknown placeholders {requesterNam}. Available here: {requesterName}, {ticketId}, {ticketTitle}, {ticketRef}, {agentName}.« Så opdager du det, mens du skriver skabelonen, ikke på en kunde.

E-mailens emne har sin EGEN, kortere liste (»{originalSubject}, {ticketTag}, {ticketId}«) — og derfor står den trykt der en gang til. En pladsholder fra teksten virker ikke i emnet og bliver afvist på samme måde.

Feltet »Reply text« i en skabelon med pladsholdere i teksten, indrammet i rødt, og listen over tilladte pladsholdere nedenunder.
Sådan ser skabelonen ud i indstillingerne: med pladsholderne, ikke med værdier. Linjen nedenunder viser, hvilke der findes.Åbn billedet i fuld størrelse
Den samme skabelon anvendt på en sag: kommentarfeltet rummer navnet, titlen og sagens henvisning skrevet ud.
Den samme tekst på sagen: »Hello Amir Khan«, sagens titel, henvisningen »[TICKET-8-…]« — og som underskrift den agent, der satte skabelonen ind. Der er endnu ikke sendt noget.Åbn billedet i fuld størrelse
4

Svaret kan sendes som e-mail til anmelderen

Kun i Professional

Før du går i gang: Mailkanalen som helhed er Professional — både ind og ud. Dertil skal teamets postkasse have afsendelse ved sagshandlinger slået til. Har den ikke det, bliver mailbrikken slet ikke tilbudt på sagen; skabelonens handlinger kører som altid, kun mailen bliver droppet.

Kontakten »Send the comment as e-mail« gør kommentaren til mailen også. Der findes bevidst intet andet tekstfelt til det: det, der står i sagen, er det, kunden læser — to tekster ville før eller siden glide fra hinanden.

Under »Recipient« vælger du mellem »Requester«, »Assignee«, »Observers« og »Fixed address«. Hvem anmelderen er, bliver løst af serveren, når skabelonen anvendes — en skabelon kender endnu ikke sagen. Selve postkassekontoen bliver der aldrig skrevet til; det ville være en besked til os selv.

Emnet må bære »{originalSubject}«, »{ticketTag}« og »{ticketId}«. Behold »{ticketTag}« derinde: den henvisning er det, systemet genkender kundens svar på og føjer til den samme sag. Uden den bliver hvert svar til en ny sag.

Mailen går ud som ren tekst. Fed skrift, lister og links bliver skåret væk før afsendelsen, ellers ville kunden læse den rå opmærkning. Inde i sagen beholder kommentaren sin formatering.

På sagen er mailen endnu en brik ved siden af handlingerne (»E-mail to Requester«) og kan fravælges præcis som de andre. Så en skabelon sender aldrig noget, uden at du har set det. Brikken dukker kun op, når teamets postkasse sender mails ved sagshandlinger.

En skabelons vedhæftede filer (»Attachments«) er dens egne kopier af filerne. At anvende skabelonen lægger dem på SAGEN, med deres egen række i historikken — de er ikke en del af mailen. At bære vedhæftede filer på en skabelon kræver ingen Professional-licens; kun afsendelsen gør.

En skabelons mailblok med den rødt indrammede kontakt »Send the comment as e-mail«, modtageren og emnet.
Kontakt, modtager og emne. Emnet rummer »{ticketTag}« — den henvisning, kundens svar bliver genkendt på.Åbn billedet i fuld størrelse
5

Opret en skabelon direkte fra en eksisterende sag

De fleste skabeloner bliver ikke født ved et tegnebræt, men i det øjeblik, du skriver det samme svar for anden gang. Derfor bærer hver kommentar på en sag et lille arkikon til højre, med teksten »Make template«. Det tager præcis den kommentar som starttekst — også en kollegas kommentar.

Har sagen vedhæftede filer, spørger en dialog først, hvilke der skal med: »Tick only the attachments the template should carry — one of them may be a customer's screenshot. Nothing is ticked by default.« Der er intet afkrydset på forhånd, og det er med vilje.

Derefter lander du på skabelonsiden med et udkast, der IKKE er gemt endnu. Øverst sidder det ravgule banner »Draft from ticket #… — name it and review the text (it may contain customer details), then save.« Navnet er tomt: du skal give et, ellers bliver den ikke gemt.

Det, der bliver taget med: teksten, fluebenet »Internal note«, sagens team og sagens tilstand som forslag — dens status og dens prioritet ligger allerede der som to handlinger. Det, der ikke bliver taget med: anmelder, adresse og titel. De hører til denne ene sag.

Læs teksten, før du gemmer. Den kommer fra en rigtig sag og kan rumme et menneskes navn, et ordrenummer eller et lokale. Der bliver ikke anonymiseret noget for dig — banneret siger det, men at gøre det er din opgave.

Kun »Save« opretter skabelonen; de afkrydsede filer bliver så kopieret over og bekræftet med en besked.

En kommentar på en sag med det rødt indrammede arkikon »Make template« ved siden af knapperne til at rette og slette.
Vejen starter ved kommentaren, ikke i indstillingerne: arkikonet til højre for det svar, du vil genbruge.Åbn billedet i fuld størrelse
Dialogen »Make a template from this comment« med sagens to vedhæftede filer, ingen af dem afkrydset.
To filer hænger på denne sag, ingen af dem er afkrydset. Den ene er kundens eget skærmbillede — og det hører ikke hjemme i et bibliotek af standardsvar.Åbn billedet i fuld størrelse
6

Udkast bliver private, indtil de bliver udgivet; omfanget er per team eller globalt

»Applies to« bestemmer, hvem skabelonen bliver tilbudt: ét bestemt team eller »All teams«. En ny skabelon starter med et konkret team — »All teams« er et valg, nogen skal træffe, ikke et stiltiende udgangspunkt.

På en sag bliver du tilbudt ejerteamets skabeloner plus de globale. Flytter sagen til et andet team efter en overdragelse, flytter listen med — det nye teams skabeloner er dem, du kan vælge fra.

Kontakten »Draft« gør skabelonen til dit værksted: »Only you can see this template until you publish it.« En andens udkast dukker ikke op i nogen liste og kan heller ikke nås på sin adresse — heller ikke af administratorer. En ny skabelon starter som udkast; først når du slår det fra og gemmer, ser de andre den.

To skabeloner må ikke dele navn, hvis de kan mødes: en global støder sammen med enhver skabelon af samme navn, i ethvert team. En svarskabelon og en sagsskabelon må dog gerne dele navn — de står aldrig side om side i den samme liste.

»Duplicate« laver en kopi, og kopien er altid et udkast: »Duplicated. The copy is a draft only you can see.« Det er den bekvemme vej til en variant, uden at andre bliver tilbudt den halvfærdige udgave.

Hovedet på en skabelon med mærkningerne »Reply template« og »Draft«, det rødt indrammede felt »Applies to« og den lige så indrammede kontakt »Draft«.
Denne skabelon hører til helpdesken og er et udkast: ingen andre end forfatteren ser den — og dens tekst er tom, fordi alt, den gør, er at give sagen videre.Åbn billedet i fuld størrelse
7

Sagsskabeloner: formularen til en ny sag udfyldt på forhånd (titel, beskrivelse, kategori, prioritet, team)

En sagsskabelon udfylder formularen »Create new ticket«. Den har ingen svartekst, ingen handlinger og ingen mail — i dette øjeblik findes der ingen sag at handle på. Formularen viser derfor andre felter end ved en svarskabelon, og den grønne ramme fortæller dig, at du ser på en sagsskabelon.

Du kan udfylde »Ticket title«, »Owning team of the new ticket«, »Main category«, »Subcategory«, »Priority« og »Ticket description« på forhånd. Hvert felt må gerne blive stående på »Not prefilled« — det, der bliver stående tomt, udfylder den senere, der bruger formularen.

Hold øje med forskellen på de to teamfelter: »Applies to« øverst siger, HVEM der ser skabelonen. »Owning team of the new ticket« siger, HVOR den nye sag går hen. Det er to forskellige spørgsmål, og de må gerne have forskellige svar.

Kategorierne er grupperet efter team, fordi en kategori hører til et team. Vælger du en fra et andet team, siger formularen til, og gemningen bliver afvist: på modtagerteamets formular til en ny sag ville den kategori slet ikke blive tilbudt, så udfyldningen ville ende i ingenting.

Der findes ingen pladsholdere her, og hjælpeteksten under teksten siger det: »No placeholders here: the template only prefills the form, nothing is resolved or sent.« Et »{requesterName}« ville ende bogstaveligt i den nye sag — og derfor bliver det afvist ved gemningen.

Den blå boks samler også her, hvad skabelonen gør: »Prefills the new ticket with title 'New notebook for a colleague' · category Notebook / New request · priority Medium · team Helpdesk · the description.«

På selve formularen vælger du skabelonen med knappen »Template«; ved siden af står »Prefills the form - nothing is created until you submit.« Alt det udfyldte kan stadig ændres, og der bliver ikke oprettet noget, før du sender.

Én eksempelskabelon følger med systemet: »Example: create accounts for a new colleague«. Den viser formen på tingen og gør intet af sig selv — byg den om, eller slet den.

Redigeringen af en sagsskabelon med de rødt indrammede felter til titel, modtagerteam, kategori og prioritet.
Fem udfyldninger plus beskrivelsen. Feltet »Owning team of the new ticket« er ikke omfanget ovenover — det siger, hvor sagen går hen.Åbn billedet i fuld størrelse
Formularen »Create new ticket« efter valget af en skabelon: knappen »Template« og den udfyldte titel er indrammet i rødt.
Den samme formular som altid, bare allerede udfyldt: titel, team og prioritet står der. Kategori og beskrivelse følger længere nede på den samme side.Åbn billedet i fuld størrelse
8

Sagsskabeloner kan frigives til kunder, én ad gangen

Kontakten »Offer this template to customers« er slået fra som fabriksindstilling. Hjælpeteksten ved siden af siger begge de ting, du skal vide: »Customers can pick this template when they create a ticket. A draft stays hidden either way.«

Hvorfor den er slået fra som udgangspunkt: en skabelon er tit navngivet i internt sprog og skrevet til kolleger. At gøre den synlig for kunder er en udtalelse udadtil — det skal nogen gøre med vilje, ikke ved et uheld.

Kunden ser den samme »Template«-knap over formularen til en ny sag, men kun de frigivne skabeloner. Et udkast bliver skjult, også med kontakten slået til — de to regler sidder efter hinanden, ikke ved siden af hinanden.

Pointen er ikke bekvemmelighed, den er den første kontakt: en henvendelse, der kommer ind komplet, sparer den runde spørgsmål, der ellers ville koste to dage. Læg de spørgsmål ind i skabelonens beskrivelse — kunden svarer på dem, mens hun opretter sagen.

Du kan gå videre med »Fields to ask for«. Skabelonen bestemmer så, hvilke brugerdefinerede felter formularen spørger om, i hvilken rækkefølge, og hvilke af dem der er påkrævede. Det udvalg ERSTATTER teamets sædvanlige felter, det lægges ikke oveni. Det er præcis meningen med det. Brugerdefinerede felter er i sig selv en del af Professional; deres kort hedder »Brugerdefinerede felter«. At frigive en skabelon til kunder virker i hver udgave.

Et felt, der er skjult for kunder, bliver skjult, også hvis en skabelon nævner det. Feltudvalget er et værktøj til orden og til tilskæring, ikke en vej uden om feltindstillingerne.

Den rødt indrammede kontakt »Offer this template to customers« med sin hjælpetekst.
Én kontakt per skabelon — her er den slået til, så denne skabelon bliver tilbudt til kunder. Hjælpeteksten siger lige ud, at et udkast bliver skjult uanset hvad. Nedenunder sidder feltudvalget.Åbn billedet i fuld størrelse
Formularen til en ny sag, som en kunde ser den, med skabelonlisten åben og de frigivne skabeloner i den.
Den samme liste på kundens side: den rummer kun de frigivne skabeloner. Denne installations øvrige sagsskabeloner står ikke her.Åbn billedet i fuld størrelse
9

Hver anvendelse kan spores i sagens historik

Hver anvendelse skriver ÉN post i historikken, under feltnavnet »Template«. Den nævner skabelonen og opregner, hvad der faktisk kørte. Uden den ville der ikke være nogen måde at forklare bagefter, hvorfor en sag pludselig hoppede til »In Progress«: de enkelte handlinger skriver ganske vist deres egne rækker, men ingen af dem nævner skabelonen.

Billedet lyder: »Template 'First reply: we have your ticket' applied: Assign: already assigned to that user; SetStatus: Assigned -> InProgress«. Den første halvdel er ikke en fejl. Afsendelsen af kommentaren havde allerede sat sagen i agentens navn, så tildelingshandlingen havde intet tilbage at gøre — og posten siger præcis det i stedet for at påstå en virkning, der aldrig fandt sted.

Fravalgte handlinger står ikke i den: de skete ikke. En fejl står i den, og den bliver nævnt som en, bag ordet »failed«.

Posten er INTERN — anmelderen ser den ikke. En skabelons navn er internt sprog (»standardafslag«), og historikken er også åben for sagens opretter. Selve feltændringerne bliver synlige for hende; kun deres oprindelse i en skabelon gør ikke.

Forfatteren er agenten, ikke »system« og ikke skabelonen. Det er med vilje: at anvende den var hendes beslutning. I modsætning til en automatiseringsregel står der her et menneske på sagen.

Historikken på en sag med den rødt indrammede »Template«-post, der nævner den anvendte skabelon og de handlinger, der kørte.
Én post per anvendelse, med agenten som forfatter. Ovenover står rækkerne for de enkelte handlinger — skabelonposten siger, hvor de kom fra.Åbn billedet i fuld størrelse

Automatisering og påmindelser

To veje til det samme mål: ingen sag bliver liggende, fordi ingen har den i tankerne længere. En påmindelse sætter du selv — det er en del af Basic. Reglerne gør det uden dig, og de er en del af Professional.

1

Påmindelse på en sag i hånden (dato + note, filtrene I dag/Denne uge/Overskredet)

Før du går i gang: Kun agenter og administratorer ser påmindelsen, og sagen siger det: »Only agents and administrators see this — the requester never does.« Anmelderen får den aldrig at se.

Påmindelsen sidder på sagen i kortet »Details« til højre, under fristerne. Så længe der ikke er sat nogen, står der »No follow-up set.« med en »Set follow-up«-knap. Du vælger en dato og et klokkeslæt (»Date and time«) og tilføjer en note (»Note (optional)«, pladsholdertekst »Why is this coming back?«). Derefter hedder knapperne »Change« og »Remove«.

Noten er der, hvor værdien ligger. Om to uger fortæller en dato alene dig ikke, hvorfor denne sag er tilbage på dit skrivebord. Det er også derfor, noten hænger på datoen: fjern datoen, og noten går med — en begrundelse uden en dato ville ingen nogensinde se igen.

Over sagslisten sidder en »Follow-up:«-række med fire knapper — »No filter«, »Today«, »This week« og »Overdue« — og listen selv har en »Follow-up«-kolonne. Den bor bevidst ikke inde i den sammenklappede filterblok: det er det spørgsmål, en agent starter dagen med.

»Overdue« tæller også dagens med. Ellers ville en påmindelse forsvinde præcis den dag, den gælder — i det øjeblik dens klokkeslæt er passeret.

Kortet »Details« på en sag med det rødt indrammede »Follow-up«-afsnit, hvor mærkningen »Overdue«, noten og knapperne »Change« og »Remove« står.
Denne sags dato ligger i fortiden, deraf den røde »Overdue«-mærkning. Noten siger, hvad gensynet handler om.Åbn billedet i fuld størrelse
Sagslisten med den rødt indrammede »Follow-up:«-række over tabellen og den lige så indrammede »Follow-up«-kolonne.
Fire sager bærer en dato: en agent satte to i hånden, en regel satte de to andre. Knapperne ovenover skærer listen ned til i dag, denne uge eller overskredne.Åbn billedet i fuld størrelse
2

Tidsstyrede regler – de reagerer på FRAVÆRET af en handling

Kun i Professional

Før du går i gang: En ny regel bliver ALTID oprettet slået fra — også hvis du forsøger at oprette den slået til gennem brugerfladen. En regel, der kører hen over hele din bunke i det øjeblik, den bliver oprettet, er det uheld, systemet her tager fra dig. Den går først i luften med det næste »Save«.

Reglerne bor under »Settings → Automation«. Linjen under overskriften siger, hvad det handler om: »Rules that act when nobody else does.« En regel hører til et team og virker på det teams sager; vælgeren »Team« øverst bestemmer, hvilke regler du ser på.

Forskellen til alt andet i systemet: disse regler reagerer ikke på en hændelse, de reagerer på dens FRAVÆR. Intet svar fra anmelderen i tre dage, ingen bevægelse i en uge, oprettet for fire timer siden og stadig ingens opgave — der findes intet klik, der udløser noget af det. Og netop derfor opdager ingen det.

Et grønt banner øverst fortæller dig, at kontrollerne kører: »The automation checks every minute. 2 of 6 rule(s) are enabled.« Er ingen regel slået til, får du advarslen »No rule is enabled. Nothing is being checked and tickets behave exactly as before.« — og så sker der virkelig ingenting.

Toppen af siden »Automation« med det rødt indrammede grønne banner om kontrolintervallet, teamfilteret og knappen »Add rule«.
Seks regler ligger gemt her, to af dem kører. De fire medfølgende eksempler sidder nedenunder på den samme side, alle slået fra.Åbn billedet i fuld størrelse
3

NÅR/HVIS/SÅ-regelbygger med en sætning i almindeligt sprog, der følger med

Kun i Professional

En regel har tre blokke. »WHEN« er det fravær, den reagerer på (»Something has not happened for a while. This is what the automation reacts to.«). »IF« skærer ned, hvilke sager det gælder (»Which tickets it applies to.«) — efter status, prioritet, team, kategori, sagsbehandler eller bedømmelse. »THEN« er det, der sker.

Over blokkene står reglen som én sætning, og den skriver sig selv om ved hver ændring: »When a ticket has seen no activity for more than 5 minutes and has the priority "High", then set a follow-up in 4 hours.« Mangler der stadig noget, siger sætningen det netop på det sted i stedet for at skjule det.

I »IF«-blokken bestemmer du også, hvordan betingelserne kombineres: »All conditions must apply« eller »Any condition is enough«. Sætningen ovenover ændrer form efter det — med et »og« ville den ellers påstå det modsatte af, hvad reglen gør.

To felter styrer, hvordan flere regler arbejder sammen: »Order« sætter rækkefølgen, og kontakten »Skip the following rules for a ticket this rule applies to« stopper hver senere regel for en sag, denne gælder for.

Mere om det på kortet: En dårlig bedømmelse som udløser

En regel med den rødt indrammede sætning i almindeligt sprog ovenover og de tre blokke WHEN, IF og THEN nedenunder.
Det samme indhold to gange: én gang som formular, én gang som sætning. Læser du sætningen, opdager du med det samme, når du har sat noget andet op, end du mente.Åbn billedet i fuld størrelse
4

Fire eksempelregler følger med (slået fra ved installationen, slå de ønskede til)

Kun i Professional

Hver installation leveres med fire regler: »Example: remind the requester after 3 business days«, »Example: close after 10 days without a reply«, »Example: raise the priority of unassigned tickets« og »Example: follow up on tickets nobody touched for a week«. De sidder under hinanden på siden »Automation«.

Alle fire er slået fra — hver bærer den grå »Off«-mærkning og »Last run: never«. De er et udgangspunkt at læse og bygge om, ikke en opførsel, nogen har listet forbi dig. Omdøb dem, ændr dem, slå dem til eller slet dem.

De gælder desuden »Every team« — det eneste sted i systemet, hvor det sker uden et udtrykkeligt valg. Så inden du slår en til, så se efter, om den virkelig er ment til alle jeres teams.

Den første af de fire eksempelregler med den rødt indrammede »Off«-mærkning, sit navn og sætningen i almindeligt sprog.
Sådan ser den første ud; de tre andre sidder nedenunder på den samme side og er også slået fra. »Every team« betyder: den ville gælde for hvert af jeres teams.Åbn billedet i fuld størrelse
5

Forhåndsvisning, før du slår den til: den viser, hvilke sager reglen ville ramme lige nu – uden at ændre noget

Kun i Professional

Under hver regel sidder knappen »Which tickets would this affect?«. Ét klik viser listen »Tickets this rule would affect right now« — de sager, reglen gælder for i dette øjeblik, med nummer og titel.

Nedenunder står, hvad forhåndsvisningen ikke gør: »The preview only reads. It changes nothing and writes no log entry. Unsaved changes are not included.« Den sidste del betyder noget: forhåndsvisningen arbejder på den gemte regel, ikke på det, der lige nu står i formularen.

Passer reglen ikke på noget i øjeblikket, siger den også det: »No ticket matches this rule right now.« Det er det svar, du vil have, før du slår den til — ikke bagefter på jeres kunders sager.

Den åbnede forhåndsvisning af en regel med overskriften »Tickets this rule would affect right now«, to sager og den rødt indrammede hjælpetekst om, at forhåndsvisningen kun læser.
Denne regel ville røre to sager lige nu. Hjælpeteksten nedenunder siger, at intet af det skete, da du klikkede på knappen.Åbn billedet i fuld størrelse
6

Handlinger: e-mail, status, prioritet, tildel, giv videre til et andet team, sæt en påmindelse

Kun i Professional

Før du går i gang: Handlingen »Send an e-mail« går ud gennem den samme mailkanal som resten af systemet. Uden opsat udgående post sker der ingenting — og en Basic-installation har slet ikke den kanal.

I »THEN«-blokken vælger du blandt syv handlinger: »Send an e-mail«, »Set the status«, »Set the priority«, »Assign to a user«, »Remove the assignee«, »Hand over to another team« og »Set a follow-up«. »Add action« lægger flere til; hver har sin egen »Active«-kontakt, så du kan sætte en enkelt på lydløs uden at slå hele reglen fra.

Ved »Send an e-mail« sætter du flueben ved modtagerne én ad gangen: »the requester«, »the assignee«, »the observers« og »a fixed address« — den sidste med sit eget felt til adressen. Ved »Set a follow-up« angiver du et tal, en enhed og den note, der senere kommer til at stå på sagen.

Ved »Hand over to another team« står hjælpeteksten lige nedenunder: »The ticket moves to that team and the current assignee is cleared. No second ticket is created.« Så der dukker ingen dublet op — den samme sag skifter bare hænder.

»THEN«-blokken i en regel med den rødt indrammede handlingsvælger og felterne til påmindelsens tal, enhed og note.
Én handling med sine detaljer: »Set a follow-up«, 4 »hours«, plus den note, agenten senere læser på sagen.Åbn billedet i fuld størrelse
7

Tidsrum kan vælges per betingelse: i arbejdstimer og arbejdsdage fra teamets kalender – eller døgnet rundt

Kun i Professional

Hver tidsbetingelse i »WHEN«-blokken har tre dele: slagsen, sammenligningen »longer than« og et tal med en enhed. Der findes fem slags: »Time since the ticket was created«, »Time without any activity«, »Time without a reply from the requester«, »Time without a public reply from an agent« og »Time without a status change«.

Enheden bestemmer, hvordan tiden bliver talt — og den gør det per betingelse: »minutes«, »hours« og »days« løber igennem, også om natten og i weekenden. »business minutes«, »business hours« og »business days« tæller mod teamets arbejdstidskalender, så kun det, der falder inden for åbningstiden, bliver talt med.

I hverdagen er forskellen stor: tre dage er tre dage, mens tre arbejdsdage talt fra en torsdag i en uge fra mandag til fredag lander på den følgende tirsdag. Det er den samme kalender, som SLA-fristerne bruger.

En tidsbetingelse i »WHEN«-blokken med tallet og enheden indrammet i rødt, ved siden af vælgeren til betingelsens slags.
Denne betingelse tæller i »business days« — tre arbejdsdage efter teamets kalender, ikke tre kalenderdage.Åbn billedet i fuld størrelse
8

Log per regel plus reglens navn som forfatter i sagens historik

Kun i Professional

Under hver regel sidder en »Log«-knap. Den åbner tabellen »What this rule did« med én række per ramt sag: »When«, »Ticket«, »Cycle«, »Result« og »Details«. »Details« rummer, hvad der præcis blev gjort — for eksempel »SetFollowUp: 2026-08-20 02:18Z«. Har en regel endnu intet gjort, siger den det: »This rule has not done anything yet.«

Kolonnen »Cycle« er grunden til, at en regel ikke råber ad dig hvert minut: den handler på en sag én gang per omgang. En omgang slutter først, når reglen ikke længere gælder for den sag — så hvis kunden svarer og derefter bliver stille igen, begynder omgang 2, og reglen handler igen.

På selve sagen står reglen som forfatter. I historikken dukker den op under sit eget navn med forstavelsen »Automation:«, for eksempel »Automation: High priority: bring it back to us«. Så på hver sag kan du slå op, om et menneske eller en regel handlede — og var det en regel, hvilken.

Hovedlinjen i hver regel bærer også »Last run:« med tidspunktet for dens sidste gennemløb, eller »never« ved en regel, der aldrig har kørt.

Den åbnede tabel »What this rule did« med tre rækker og de rødt indrammede kolonner »Cycle« og »Details«.
Tre gennemløb på to sager: på den ubesvarede sag #4 handlede reglen en anden gang — deraf »2« i kolonnen »Cycle«. »Details« rummer den påmindelsesdato, der blev sat hver gang.Åbn billedet i fuld størrelse
Historikken på en sag med to rødt indrammede rækker, hvis forfatter er »Automation: High priority: bring it back to us«.
Den samme hændelse set fra sagen: dato og note står som to rækker i historikken, med reglen som forfatter.Åbn billedet i fuld størrelse

Massehandlinger på sagslisten

Sæt flueben ved flere sager, og ændr dem i ét hug. Det hele er en del af Basic. Kun en skabelons kundemail afhænger af mailkanalen og dermed af Professional. Den egentlige pointe er ikke antallet af sager, men den ærlige håndtering af et delvist resultat: hver regel gælder den enkelte sag, så systemet siger på forhånd, hvor mange handlingen passer til, og bagefter hvilke der ikke kom med, og hvorfor.

1

Ændr statussen på flere sager på én gang

Sagslisten har en kolonne med flueben yderst til venstre. Den er der for administratorer og agenter. En kunde ser den aldrig.

Fluebenet i hovedrækken vælger hver række på den side, du står på. Det vælger ikke hele resultatmængden. Har du brug for mere end det, så skær filteret til — et filter er den mere ærlige måde at angive en mængde på end et flueben, der også dækker sager, du ikke kan se.

Valget bliver ryddet, så snart du skifter side, filtrerer, søger eller skifter team. På den måde følger der intet valg med, som ikke længere står på skærmen.

Listen på billedet viser ikke hver sag. Øverst til højre, ved siden af »Filter«, står ordet »active«, og ved siden af »Reset«: lukkede sager er skjult, fordi en massehandling er rettet mod sager, der stadig kører. Et valg dækker altid kun det, listen viser i det øjeblik.

Fra det første flueben dukker en bjælke op over listen. Den viser »20 selected«, ved siden af »Clear selection« og knapperne »Change status«, »Assign«, »Assign to me« og »Apply template«. Længere til højre sidder »Multiple report« og »Group into incident« — de to hører til dobbelte anmeldelser og bliver forklaret i den næste blok.

»Change status« åbner en lille dialog. Du vælger målstatussen, og linjen nedenunder siger med det samme, hvor mange af de valgte sager den gælder for.

Kræver målstatussen en kommentar, dukker et tekstfelt op. Nedenunder står, hvor mange sager teksten går til. Den går til hver ændret sag, ikke kun til den første.

Ikke hver status står i listen. Systemstatusser mangler, fordi ingen sætter dem i hånden. »Waiting for other team« mangler også: den status opretter en undersag til et modtagerteam, og det team vælger du per sag. I en bunke ville der kun være ét enkelt felt til det.

En sag uden sagsbehandler bliver tildelt dig, når du ændrer dens status på detaljesiden. I en bunke sker det ikke: »luk 30 sager« ville ellers stille og roligt betyde »30 sager tildelt mig« og 30 e-mails.

Denne dialog ændrer intet andet. Prioritet, kategori og alt derudover sætter du i en bunke gennem en svarskabelon.

Mere om det på kortet: Et andet trin til enkelte opgaver

Sagslisten med afkrydsede rækker og bjælken ovenover, der viser antallet af valgte sager og knapperne til massehandlinger.
Den røde ramme sidder på den bjælke, der først dukker op med det første flueben. Til venstre antallet af valgte sager, til højre handlingerne.Åbn billedet i fuld størrelse
Dialogen »Change status« med en valgt målstatus og linjen, der angiver dens rækkevidde.
Målstatussen er valgt; nedenunder rækkevidden og grunden for hver sag, der ikke kommer med. Begge dele står der, før du klikker på »Apply«.Åbn billedet i fuld størrelse
2

Tildel flere sager til én agent på én gang

»Assign« åbner listen over agenter. Agenter, der er væk, kan stadig vælges og bliver kun markeret som sådan, præcis som på en enkelt sag.

»Assign to me« er den samme dialog med dit eget navn valgt på forhånd. Det er en genvej, ikke en anden vej, og de samme regler gælder for den.

Hver tildeling sender en e-mail til agenten. Dialogen angiver antallet på forhånd: »This sends 11 e-mail(s) to the selected agent.« Elleve sager er elleve mails.

Agenten skal høre til netop den sags team. Et valg, der spænder over to teams, kan derfor ikke gives til én person i ét stykke. Det er ikke en begrænsning ved massehandlingen — den samme regel gælder på en enkelt sag.

En tildeling kan ikke sættes tilbage til »ingen«. Det findes ikke på en enkelt sag, så det findes heller ikke i en bunke.

Dialogen »Assign« med den valgte agent, rækkevidden og bemærkningen om antallet af e-mails.
Under vælgeren står rækkevidden og antallet af e-mails. Boksen nedenunder nævner hver sag, der ikke kommer med, med sin grund: fire tilhører allerede Marco Rossi, tre tilhører netværksteamet, som han ikke er en del af.Åbn billedet i fuld størrelse
3

Anvend en svarskabelon på flere sager, pladsholderne bliver løst per sag

»Apply template« anvender en svarskabelon på alle valgte sager. Hver sag får den samme kommentar, som den ville få, hvis du anvendte skabelonen i hånden.

Listen tilbyder skabelonerne fra hvert team, der optræder i valget. En skabelon dukker op, så snart den passer til mindst én valgt sag; hvor mange den virkelig passer til, siger forhåndsvisningen bagefter.

Serveren løser pladsholderne per sag, så hver kunde får sin egen tiltale og sit eget sagsnummer. Bemærkningen i dialogen siger det også.

Skabelonens felthandlinger kører med, og dens vedhæftede filer bliver kopieret til hver sag.

I en bunke kører alle skabelonens handlinger. Du kan kun fravælge enkelte på en enkelt sag; vil du ikke have en handling, så brug en skabelon uden den.

Findes der ingen skabelon til teamene i valget, siger dialogen det: »No reply template is available for the teams of the selected tickets.«

Dialogen »Apply template« med en valgt skabelon og bemærkningen om, at pladsholderne bliver løst per sag.
Den røde ramme sidder på bemærkningen om pladsholderne — det, der skiller dette fra én tekst formuleret ens til alle. Nedenunder står grunden til, at skabelonen passer til 14 af de 20 sager: seks af dem tilhører et team, den ikke bliver tilbudt til.Åbn billedet i fuld størrelse
4

Forhåndsvisning før kørslen, resultat bagefter, oversprungne sager bliver stående valgt

Alle tre dialoger viser den samme linje, før der sker noget: »Applies to 19 of 20 selected ticket(s)«.

Nedenunder står boksen »Will be skipped« med én linje per sag, der ikke kommer med, hver med sagsnummer og grund. Så du læser før klikket, hvorfor tallet er mindre end dit valg.

Efter kørslen står der »19 changed, 1 skipped«, og den samme boks bliver til »Not changed«. Indholdet er det samme; det er bare holdt op med at være en forudsigelse og blevet til en konstatering.

Grundene er dem fra den enkelte sag. En sag står allerede i målstatussen. Overgangen er ikke tilladt fra dens aktuelle status. Den tilhører et team, du ikke er ansvarlig for. Den valgte agent er ikke en del af dens team. Den venter på en godkendelse. Den er en samlesag med åbne anmeldelser. Den er en oversag med en åben undersag.

De oversprungne sager bliver stående valgt, de ændrede gør ikke. Et andet forsøg med et andet mål er derfor ét klik væk, og ingen skal gætte, hvilke der stadig er åbne.

Forhåndsvisningen er en anden mening, ikke en tilladelse. Når handlingen kører, kontrollerer serveren hver sag igen — en sag kan ændre sig mellem visningen og klikket.

Ét kald tager imod højst 200 sager. Med 20 rækker per side er det langt væk.

Dialogen efter kørslen: antallet af ændrede og oversprungne sager, og nedenunder boksen »Not changed« med grundene.
Boksen »Not changed« nævner grunden per sag. Her stod to sager allerede i målstatussen.Åbn billedet i fuld størrelse
5

E-mailen til anmelderne er slået fra som udgangspunkt

Kun i Professional

Et flueben til at sende mail dukker kun op ved skabeloner, der sender en, og kun hvis mailkanalen er åben. Det er tomt som udgangspunkt, så en massehandling skriver intet ud af huset, før du sætter flueben.

Er kanalen lukket, træder grunden i stedet for fluebenet: enten er afsendelse af e-mail slået fra, eller også sender de valgte teams postkasser ikke mails ved sagshandlinger. Det læser du før klikket, ikke bagefter i resultatet.

Så snart du sætter flueben, dukker en ravgul bemærkning op med antallet: »This sends 20 e-mail(s) to customers.« Tallet kommer fra forhåndsvisningen og er antallet af sager, skabelonen virkelig passer til.

At ændre statussen og at tildele skriver aldrig til kunder. Tildelingen sender ganske vist en e-mail, men til agenten. At anvende en skabelon i en bunke er den eneste vej, hvor der opstår en kundemail.

Afsendelsen afhænger af mailkanalen og dermed af Professional. Er den slået fra, går der ingen mail ud, og sagens historik siger hvorfor — den påstår aldrig en levering, der ikke fandt sted.

Dialogen »Apply template« med mailfluebenet sat og den ravgule bemærkning om antallet af kundemails.
Fluebenet er sat, og den ravgule bemærkning angiver antallet af mails. Uden fluebenet går der ingen ud.Åbn billedet i fuld størrelse
6

Hver masseændring står i den enkelte sags historik

Hver ændring, en massehandling har lavet, står i den enkelte sags historik. Den ser ud som enhver anden ændring der, med en gammel og en ny værdi.

Anmelderen ser også de rækker. For hende er et statusskift den samme hændelse, uanset om det blev udløst enkeltvis eller i en bunke — at skjule det ville ikke være mere diskret, kun værre.

En massetildeling skriver to sådanne rækker: ved siden af den nye sagsbehandler står statussen, fordi en tildelt sag flytter til »Assigned«.

Dertil kommer en intern række, der bærer kørslens henvisning. Den henvisning lader dig senere finde alle sager fra den samme kørsel. Anmelderen ser ikke den række.

Hver række nævner den person, der udløste massehandlingen.

En oversprunget sag får ingen post, heller ikke en om forsøget. Det, der ikke skete, står ikke i historikken.

Historikken på en sag med tildelingsrækken og den interne række nedenunder, der nævner massekørslen.
Den nyeste række står øverst: statussen, nedenunder tildelingen, og under den kørslens henvisning. Den røde ramme sidder på den interne række, den anmelderen ikke ser.Åbn billedet i fuld størrelse

Flere anmeldelser og driftsforstyrrelser

To situationer ligner hinanden og er det ikke. Anmelder den samme person det samme to gange, skal den ene anmeldelse forsvinde. Anmelder mange mennesker én driftsforstyrrelse, må ingen forsvinde. Hver har sin egen vej, og forskellen er anmelderen.

1

Slå to anmeldelser fra den samme person sammen

Sæt flueben ved rækkerne i sagslisten, og klik på »Multiple report«. Knappen bliver brugbar fra to afkrydsede rækker og op.

Dialogen spørger først: »Which ticket stays?« Den ældste sag er valgt på forhånd, så fristen løber fra anmelderens første kontakt i stedet for fra hendes andet forsøg. Du kan vælge en anden.

Nedenunder står retningen med begge numre: »#11 will be closed and moved into #10.« Så før klikket er det klart, hvilken sag der bliver stående.

Alt kommer med: kommentarer, vedhæftede filer og beskrivelsen fra den anden anmeldelse. Beskrivelsen bliver til en kommentar på den oprindelige, med sin oprindelige forfatter og sin dato. Dialogen angiver tallene på forhånd.

Registreret tid bliver flyttet, ikke kopieret. Ellers ville den samme indsats stå på to sager og blive faktureret to gange.

Den anden anmeldelse bliver ikke slettet. Den bliver lukket og peger fra da af på den oprindelige, og dens nummer bliver ved med at være gyldigt.

Anmelderen får ingen særskilt e-mail. Hun står på den oprindelige sag og ser alt der. Den lukkede anmeldelse bærer en kommentar, der nævner den oprindelige, og den kan hun læse.

Der findes ingen fortrydelse. Derfor står alt i dialogen, før du klikker på »Merge«.

Bagefter noterer begge sagers historik, hvem der slog hvad sammen hvornår.

Sagslisten med tre afkrydsede rækker og bjælken ovenover med knapperne »Multiple report« og »Group into incident«.
De røde rammer sidder på de to knapper. De står side om side og betyder to forskellige ting. I række 12 til 14 kan du desuden se markeringen for den kørende driftsforstyrrelse.Åbn billedet i fuld størrelse
Dialogen »Multiple report for the same issue« med valget af den sag, der bliver stående, og sammenfatningen.
Den røde ramme sidder på retningen. Den nævner begge numre, så ingen skal gætte, hvilken sag der forsvinder.Åbn billedet i fuld størrelse
Sagslisten, søgt ned til to sager: den oprindelige og den sammenlagte anmeldelse, som er lukket.
Søgningen rummer et ord fra begge titler, så den oprindelige og anmeldelsen står ved siden af hinanden. Den røde ramme sidder på den sammenlagte anmeldelse. Den er lukket og står stadig i listen, med en henvisning til den sag, den blev flyttet ind i.Åbn billedet i fuld størrelse
2

Svar på det gamle sagsnummer kommer stadig frem

Kun i Professional

Før du går i gang: Det kræver e-mailindbakken. Uden den findes der intet svar på e-mail, der skulle finde vej.

Anmelderen har det gamle sagsnummer i sin postkasse. Hun ved intet om, at to anmeldelser er slået sammen, og svarer på den mail, hun har.

Det svar lander i den oprindelige sag. Systemet følger den henvisning, den lukkede anmeldelse bærer.

Derfor bliver en sammenlagt anmeldelse aldrig slettet. Uden den ville henvisningen ikke findes, og svaret ville ikke komme nogen steder hen.

Den, der var med i den gamle anmeldelse, må også skrive på den oprindelige sag. Kontrollen sker på den sag, mailen nævner.

Den lukkede anmeldelse med henvisningen til den oprindelige sag og den kommentar, anmelderen læser der.
De røde rammer sidder på henvisningen i kortet til højre og på kommentaren. Det er den henvisning, et svar på e-mail følger.Åbn billedet i fuld størrelse
3

Anmeldelser fra forskellige mennesker kan ikke slås sammen

Vælger du sager fra forskellige mennesker, tager dialogen dem ikke med. Den nævner hver afvist række og dens grund, før du klikker.

Grunden lyder: »Different requester — this is an incident, not a multiple report.« Den fortæller dig også, hvor du skal gå hen i stedet.

Det er hele funktionens vigtigste værn. Hvis du slog tredive anmeldelser fra tredive mennesker sammen, ville niogtyve af dem miste deres sag og aldrig høre mere.

Hvem anmelderen er, kommer fra feltet »User« på sagen. Er det tomt, tæller den konto, der oprettede sagen.

Derfor holder værnet også ved telefonopkald. Registrerer en agent to opkald, blev begge sager oprettet af hende. Forskellige, der ringer, bliver stadig forskellige, fordi deres navne står i feltet.

Kan anmelderen ikke bestemmes på den ene side, bliver det også afvist. Ukendt er ikke det samme som den samme person.

Flere grunde dukker op i den samme boks. En samlesag kan ikke slås sammen. En lukket oprindelig sag tager ikke imod mere. Og en anmeldelse, der allerede selv har anmeldelser, kommer ikke med, så der ikke bliver dannet kæder.

Boksen »Cannot be merged« i dialogen, med sagsnummeret og grunden.
Den røde ramme sidder på grunden. Sag 15 tilhører en anden person, så den bliver holdt udenfor. De to andre sager bliver alligevel slået sammen.Åbn billedet i fuld størrelse
4

Saml mange anmeldelser om én driftsforstyrrelse under én samlesag

Kun i Professional

Når filserveren går ned, anmelder tyve mennesker det. Hver eneste af disse anmeldelser er en sag for sig med sin egen anmelder. At slå dem sammen ville være forkert her, for nitten mennesker ville miste deres sag.

Sæt flueben ved anmeldelserne, og klik på »Group into incident«. Dialogen tilbyder tre veje: læg dem til en samlesag, der allerede er åben, erklær en af de valgte sager for samlesagen, eller opret en ny samlesag med sin egen titel.

Har teamet allerede en åben samlesag, er den vej valgt på forhånd. Det er den mest almindelige: forstyrrelsen er længe kendt, kun nye anmeldelser bliver ved med at komme ind.

Hver tilknyttet sag beholder sin anmelder, sin status og sin egen frist. Intet forsvinder. Samlesagen samler kun svaret.

Alle anmeldelser på én samlesag skal høre til det samme team. Rammer en forstyrrelse to teams, får hvert sin egen samlesag. Ellers ville det ene teams løsning tømme det andet teams kø.

Du kan også hægte efternølere på ved den enkelte sag. Har teamet en åben samlesag, dukker en hjælpetekst op øverst med »Assign« og »Not related«. Systemet hægter aldrig noget på af sig selv: en forkert tilknyttet sag ville få en løsning, der ikke angår den, og blive lukket undervejs.

Samlesagen angiver, hvor mange anmeldelser der hænger på den. Tilknyttede sager bærer til gengæld nummeret på deres samlesag, i listen og i kortet til højre.

»Resolve incident« lukker samlesagen og besvarer alle anmeldelser på én gang. Løsningsteksten er påkrævet: den er hele pointen med funktionen, fordi den går til alle berørte.

Hver tilknyttet sag får teksten som offentlig kommentar, bliver sat til den valgte status, og dens anmelder får sin egen e-mail. Ingen fællesmail, for den ville udstille adresserne på alle berørte.

Beskeden bagefter angiver, hvor mange sager der blev lukket, og hvor mange anmeldere der fik besked. Begge tal står hver for sig, for en sag uden en adresse, der kan nås, får en kommentar og en status, men ingen e-mail.

En sag, du selv har besvaret og lukket i mellemtiden, bliver ikke rørt. Den bliver ikke lukket en gang til og ikke skrevet til igen.

Så længe der hænger åbne anmeldelser på en samlesag, kan den ikke lukkes gennem det normale statusskift. Ellers ville tyve mennesker stille og roligt stå tilbage uden et svar.

Dialogen »Group into incident« med de tre veje og den åbne samlesag inklusive dens antal tilknyttede sager.
Den røde ramme sidder på den åbne samlesag, med antallet af anmeldelser, der allerede hænger på den, til højre. Over vejene står den sætning, der skiller dette tilfælde fra at slå sammen: intet forsvinder.Åbn billedet i fuld størrelse
Hjælpebjælken på en enkelt sag med den åbne samlesag og knapperne »Assign« og »Not related«.
Den røde ramme sidder på hjælpebjælken. Den er et forslag, ikke en handling: at klikke den væk ændrer intet på sagen.Åbn billedet i fuld størrelse
Samlesagen med antallet af tilknyttede anmeldelser, knappen »Resolve incident« og fluebenet til banneret.
De røde rammer sidder på knappen, der løser, på fluebenet til banneret og på antallet af tilknyttede anmeldelser.Åbn billedet i fuld størrelse
Dialogen »Resolve incident« med lukkestatussen og løsningsteksten skrevet ind.
Den røde ramme sidder på bemærkningen over feltet. Den siger, hvor denne ene tekst går hen: til hver tilknyttet sag og til hver anmelder.Åbn billedet i fuld størrelse
En berørt persons anmeldelse efter løsningen: lukket, med løsningsteksten som offentlig kommentar.
Den røde ramme sidder på svaret. Det står på denne ene anmelders sag, med hendes nummer og hendes historik. Det samme svar står på hver anden berørt persons sag.Åbn billedet i fuld størrelse
5

Driftsforstyrrelsen som banner og som bemærkning i autosvaret

Kun i Professional

Både dialogen og samlesagen bærer fluebenet »Also show as a banner on the sign-in page«. Med det får alle at vide om forstyrrelsen, før de skriver endnu en sag.

Banneret står på loginsiden og inde i systemet, når man er logget ind. Det nævner »Known incident« og samlesagens titel, så den titel er en tekst til kunder.

Er flere meddelelser aktive, står de under hinanden. Vedligehold varslet til lørdag skubber ikke dagens forstyrrelse væk, og omvendt.

Opretter nogen alligevel en ny sag, nævner autosvaret samlesagen. Det gælder for en sag, der allerede er tilknyttet, og for hver ny sag i det team, så længe samlesagen er åben og meldt ud. Det kræver udgående e-mail.

Så snart samlesagen er løst, forsvinder banneret af sig selv. Ingen skal huske at slå det fra igen.

På siden »Maintenance / Incident-Notification« kan du se, hvilken samlesag der kører som banner lige nu. Kontakten på den side hører til planlagt vedligehold og gælder ikke for samlesager.

Samlesagen med fluebenet sat og det banner, der som følge af det dukker op nederst.
Den røde ramme sidder på fluebenet. Det træder i kraft med det samme: meddelelsen løber langs bunden, på hver side i systemet.Åbn billedet i fuld størrelse
Loginsiden med det kørende forstyrrelsesbanner nederst.
Den røde ramme sidder på banneret. Det står der, før man logger ind, så det også når den, der bare vil se efter, om hun behøver at skrive en sag.Åbn billedet i fuld størrelse
Samlesagen efter løsningen: lukket, med løsningsteksten som kommentar.
Den røde ramme sidder på løsningsteksten. Med den lukning er banneret også væk.Åbn billedet i fuld størrelse

SLA, kalender og eskaleringer

Frister, der passer til jeres åbningstider: en retningslinje siger, hvor hurtigt I skal svare og løse, en kalender siger, hvornår uret overhovedet løber. Alt i denne blok er en del af Professional.

1

SLA-retningslinjer med frister for første svar og løsning

Kun i Professional

Før du går i gang: Uden en aktiv retningslinje måler systemet ingenting — ingen frist, ingen kolonne, ingen mail. Og ure bliver oprettet, når en sag bliver OPRETTET: det, der kom ind, før du slog retningslinjen til, bliver stående uden frist. Det er med vilje — ellers ville tusind gamle sager stå der som overskredne næste morgen.

Du sætter frister op under »Settings → SLA«. Siden fortæller dig selv øverst, når ingen retningslinje er aktiv. En retningslinje har tre dele: et navn, betingelserne og målene. Nye retningslinjer bliver bevidst oprettet inaktive — så du kan gøre dem færdige, før de gør noget.

Betingelserne er »Team«, »Priority«, »Main category« og »Subcategory«. Tom betyder »Any«, altså »gælder alt« — ikke »gælder ingenting«. Passer flere retningslinjer, vinder den med det laveste tal under »Order«; derfor sidder den snævre retningslinje øverst og den generelle nedenunder.

De to kategorifelter er grupperet efter team, fordi kategorier hører til et team — men du får alle tilbudt, også dem fra andre teams. Det er med vilje: ved en overdragelse flytter sagen, kategorien gør ikke. En sag, helpdesken har givet videre til netværksteamet, bærer stadig helpdeskens klassificering, og en retningslinje må pege på netop den. Så snart du vælger en hovedkategori, tilbyder feltet nedenunder kun de underkategorier, der er knyttet til den — et par, der ikke kan findes på en sag, bliver afvist ved gemningen.

Hver retningslinje har to mål. »Time to first response« slutter med det første offentlige svar fra en agent — en automatisk kvittering og en intern note tæller udtrykkeligt ikke med. »Time to resolution« slutter, så snart sagen når en status, der tæller som løst (hvilken det er, sætter du under »Settings → General → Status«). Begge mål har deres egne minutter, deres egen kalender og deres egen reaktion på en overskridelse.

På sagen sidder fristerne til højre i kortet »Details«, nedenunder »Show deadline history«: en log, der noterer hvert skridt — startet, pause, genoptaget, overholdt, overskredet — hvert med en grund og den brugte arbejdstid. Kun agenter og administratorer ser den; for kunder kan den ikke hentes.

Ændrer nogen prioriteten eller teamet senere, skifter uret til den retningslinje, der passer da: den hidtil brugte arbejdstid bliver gjort op med den gamle kalender, derefter gælder de nye værdier. Passer ingen retningslinje længere, slutter uret uden en dom — det tæller hverken som overholdt eller som overskredet.

En SLA-retningslinje med navn, rækkefølge, aktiv-kontakt, de fire rødt indrammede betingelser Team, Priority, Main category og Subcategory og de to mål nedenunder.
Retningslinjen gælder hvert team, men kun prioriteten »High«. Nedenunder de to mål: 15 minutter til det første svar, 240 til løsningen.Åbn billedet i fuld størrelse
En sags frister: »Time to first response« med mærkningen »In time«, nedenunder »Time to resolution« med resterende tid og den åbnede fristhistorik.
Det første svar kom i tide, løsningen kører stadig. Loggen nævner grunden til hvert skridt — nedefra og op: startet mod kontortidsretningslinjen, regnet om da prioriteten steg til »High« (»ticket fields changed«), og til sidst overholdt med det første offentlige svar.Åbn billedet i fuld størrelse
2

Arbejdstidskalender per team

Kun i Professional

En kalender siger, hvornår uret løber. Den har et navn, sin egen tidszone og et vilkårligt antal vinduer per ugedag — en frokostpause er simpelthen en dag med to vinduer. Et vindue må løbe over midnat; så står der »ends next day« ved siden af.

Hvilken kalender der gælder for et team, bliver sat på teamet (»Settings → Teams«). På det enkelte mål i en retningslinje kan du tilsidesætte det: »From the team« tager teamets, eller du vælger en anden. Det er præcis det, der giver det sædvanlige tilfælde — fejl tæller døgnet rundt, alt andet kun i kontortiden.

Det, der bliver talt, er den tid, der faktisk går inde i vinduet, ikke forskellen mellem to urvisninger. Ved skiftet til og fra sommertid gør det en forskel: et døgn med 24/7 i oktober har 25 timer, en nattevagt fra 22:00 til 06:00 om foråret syv i stedet for otte. Et kontorvindue fra 09:00 til 17:00 bliver aldrig ramt, fordi skiftet i EU sker om natten.

Kan der ikke findes en kalender med åbne timer, bliver der ikke oprettet nogen frist — hellere ingen end en gættet. På sagen dukker der en bemærkning op i stedet for en dato.

Kalenderen »Helpdesk business hours« med den rødt indrammede tidszone Europe/Berlin, vinduerne mandag til fredag 09:00–17:00 og knappen »Add opening hours«.
Fem dage, ét vindue per dag. Tidszonen hører til kalenderen, ikke til serveren — en anden lokation får simpelthen en anden kalender.Åbn billedet i fuld størrelse
3

Helligdage via .ics-import eller tastet ind i hånden

Kun i Professional

Før du går i gang: Vi leverer ingen helligdagsdata. Helligdage afhænger af LOKATIONEN, ikke af sproget — 16 tyske delstater, 26 schweiziske kantoner, 50 amerikanske stater, og nye hvert år. En medleveret liste ville på et tidspunkt være forkert, uden at nogen opdagede det. Tag den officielle .ics-fil for din region; det er et minuts arbejde om året.

Under hver kalender sidder listen »Closed days«. Et klik på »Import holidays (.ics)« tager imod en kalenderfil og melder bagefter fire tal: hvor mange dage der blev overtaget, hvor mange erstattet, hvor mange ulæselige, og hvor mange der allerede var der. Du kan også taste enkelte dage ind i hånden.

Symbolet ↻ efter en dag betyder »gentages hvert år«. Det er kun rigtigt ved faste datoer: 3. oktober falder på den samme dato hvert år, langfredag og 2. pinsedag hænger på påskens dato og flytter sig. Bevægelige helligdage står derfor i listen med deres konkrete dato per år — på billedet »Good Friday« uden symbolet.

En lukkedag sluger hele den dags vindue, også den del, der rækker ind i den næste dag. Og kender en kalender slet ingen lukkedag de næste tolv måneder, siger siden det udtrykkeligt — ellers regner systemet stille og roligt hen over helligdagene og laver forkerte frister.

Den rødt indrammede knap »Import holidays (.ics)« og nedenunder den lige så indrammede liste over lukkedage.
Fem lukkedage. Fire bærer symbolet ↻ for »samme dato hvert år«, langfredag gør ikke — den flytter sig.Åbn billedet i fuld størrelse
Kalenderen »Around the clock« med den rødt indrammede ravgule bemærkning om, at den ikke kender nogen lukkedage de næste tolv måneder.
Bemærkningen er ikke en fejl, men en advarsel: denne kalender regner hen over hver helligdag. Til en vagtkalender er det præcis rigtigt.Åbn billedet i fuld størrelse
4

Uret holder pause, mens der ventes på anmelderen

Kun i Professional

Den mest almindelige diskussion om frister er denne: sagen har ventet tre dage på kundens svar, og uret løber alligevel videre. Derfor har hvert mål kontakten »Pause while waiting for the requester« — enkeltvis, ikke for hele retningslinjen.

Om der bliver ventet, afgør statussen: under »Settings → General → Status« bærer hver status en markering af, om den tæller som »venter på anmelderen«. Med kontakten slået til hviler fristen, mens sagen står i sådan en status. Vægguret løber videre — derfor viser listen »Paused« i stedet for en resterende tid, og fristhistorikken rummer »Paused« og »Resumed« med deres tidspunkter.

Til det første svar lader du som regel kontakten være slået fra: du skylder det første svar uanset hvad der ventes på. Til løsningen er den som regel slået til. Billedet viser præcis den indstilling.

En retningslinjes to mål med de rødt indrammede »Pause while waiting for the requester«-kontakter — slået fra på det første mål, slået til på det andet.
Den samme kontakt, to svar: uret til det første svar løber igennem, det til løsningen hviler, mens det er kundens tur.Åbn billedet i fuld størrelse
5

Resterende tid i sagslisten, med et filter for overskredne frister

Kun i Professional

Så snart en retningslinje er aktiv, får sagslisten kolonnen »Deadline«. Den viser den resterende tid på den næste åbne frist (»14h 53m«). Når ingen frist på sagen længere løber, står dommen der: mærkningen »In time« ved en overholdt, det røde »Breached« ved en overskredet. En sag uden noget ur får en neutral streg, og det er med vilje: en sag fra før retningslinjen er ikke en fiasko.

Er ingen retningslinje aktiv, mangler kolonnen helt — den står der ikke tom. Det samme gælder filteret: under »Filter« dukker feltet »Breached only« kun op, når der overhovedet findes frister.

En sag har to ure, men kolonnen har kun én plads — den viser den mest presserende ÅBNE frist. Blev det første svar overskredet, og løber løsningen stadig, viser kolonnen den resterende tid på løsningen med et rødt »!« ved siden af. Den markering siger: en frist på denne sag er allerede overskredet — og det er præcis sådan, filteret »Breached only« finder den, for det spørger efter enhver overskredet frist, også en, der for længst er afsluttet. Hvilken af de to det ramte, står i selve sagen.

Du kan også sortere efter den: under den samme »Deadline«-overskrift sidder et felt med »Due soonest first« og »Due latest first«. Sager uden et kørende ur ender altid sidst — de er ikke de mindst presserende, de er simpelthen ikke berørt. Sortering efter frist går forud for sortering efter »Updated at«: ingen liste kan opfylde to rækkefølger på én gang.

Sagslisten med feltet »Breached only« afkrydset, det rødt indrammede filter og den lige så indrammede »Deadline«-kolonne.
Med feltet »Breached only« afkrydset er der én enkelt sag tilbage. På sag 4 blev det første svar overskredet. Kolonnen viser stadig en kørende resterende tid, fordi den viser den næste ÅBNE frist, og her er det løsningen. Det røde »!« ved siden af nævner overskridelsen.Åbn billedet i fuld størrelse
En sag med den røde »Breached«-mærkning på det første svar og en kørende resterende tid på løsningen, nedenunder fristhistorikken.
Den samme sag, to ure, to tilstande. Loggen rummer grunden: »due date passed«, efter 16 minutters brugt arbejdstid.Åbn billedet i fuld størrelse
6

Ved overskridelse: giv besked, eller giv sagen videre til et andet team

Kun i Professional

Før du går i gang: At give videre er bevidst ikke standard. Det flytter ansvaret, rydder sagsbehandleren og nulstiller statussen — en sag, nogen arbejder på lige nu, ligger bagefter et andet sted. Vælg det kun, når præcis det er meningen.

Per mål sætter du under »When breached«, hvad der sker ved en overskridelse: »Record only« noterer det bare, »Notify assignee and observers« sender en mail til sagsbehandleren og observatørerne (ikke til hele teamet), »Hand over to another team« giver sagen videre. Til overdragelsen skal du vælge et modtagerteam — en retningslinje uden et bliver afvist ved gemningen, for den ville se opsat ud og ikke gøre noget.

Handlingen kører præcis én gang per ur. Uden den lås ville en genstart af serveren sende den samme mail igen. Markeringen »allerede gjort« bliver sat, også når afsendelsen mislykkedes — en mail, der ikke kom frem, er bedre end en løkke, der sender en ny hvert minut.

Selve overskridelsen bliver dateret til det øjeblik, den forfaldt, ikke til kontrolkørslen — ellers ville rapporteringen hænge på kontroltjenestens rytme. Og den bliver målt mod den brugte arbejdstid: et ur på pause kan ikke overskride, heller ikke når forfaldsdatoen for længst er passeret.

En inaktiv eksempelretningslinje med det rødt indrammede valg »When breached: Hand over to another team« og modtagerteamet »Network«.
Sætningen under modtagerteamet siger, hvad der sker: sagen flytter til det team, den nuværende sagsbehandler bliver ryddet. Kontakten »Active« er slået fra her — en inaktiv retningslinje gør ingenting.Åbn billedet i fuld størrelse
7

SLA-tal i rapporteringen

Kun i Professional

Under »Reports« vælger du perioden og trykker på »Generate report« — uden det klik bliver siden tom. Rapporten rummer så blokken »Service level agreements« med én række per mål: overholdt, overskredet, stadig kørende, opnået grad og den gennemsnitligt brugte tid.

Der bliver talt per mål, ikke per sag — det står også under tabellen. En sag med begge mål optræder derfor to gange, én gang i hver række.

Den opnåede grad tæller kun afgjorte ure. De kørende hører ikke til i nævneren, ellers ville hver frisk slået SLA se katastrofal ud i starten og blive bedre af sig selv. Findes der endnu ikke et eneste afgjort ur, dukker der en streg op — ikke »0 %«.

Arbejder du med samlesager, findes der desuden linjen »Achieved without group incidents«: en enkelt driftsforstyrrelse med hundrede tilknyttede sager ville ellers forvride graden i begge retninger.

Rapportblokken »Service level agreements« med kolonnerne Met, Breached, Still running, den rødt indrammede opnåede grad og den gennemsnitligt brugte tid.
Til det første svar er tre frister overholdt og én overskredet, seks kører stadig. Det giver 75 %. De to kolonner til højre for den dukker kun op, når der findes samlesager: de lader de anmeldelser ude, der blev lukket sammen med en samlesag.Åbn billedet i fuld størrelse

Tidsregistrering per sag

Agenter registrerer den indsats, en sag har kostet. Det betyder arbejdet på sagen, ikke en persons tilstedeværelse — det er udtrykkeligt ikke et stemplingssystem. Hele denne blok er en del af Professional.

1

Slå den til, før der bliver registreret noget

Kun i Professional

Tidsregistrering er slået fra som fabriksindstilling. Så længe den er slået fra, findes der intet felt, ingen kolonne og ingen flade i rapporten.

Et dødt felt ville være værre end slet intet, så funktionen forsvinder helt i stedet for at stå der gråtonet.

Kontakten sidder under »Settings → General« på kortet »Time tracking per ticket« og hedder »Enable time tracking«.

Hvert team er så med. Vil du holde et udenfor, slår du det fra på selve teamet, under »Settings → Teams« i boksen »Team details«.

En virksomhed med et internt IT-team og et kundevendt team har tit kun brug for den til det andet.

Slår du tidsregistreringen fra igen senere, bliver de eksisterende poster ved med at kunne læses og eksporteres — de er et grundlag for fakturering, ikke en bekvemmelighed. Der kan ikke registreres noget nyt.

Kortet »Time tracking per ticket« under »Settings → General« med hovedkontakten, afrundingen, hurtigknapperne og stopuret.
Hver indstilling til tidsregistrering på ét kort. Den røde ramme sidder på hovedkontakten, og nedenunder står, hvad det betyder at slå den fra.Åbn billedet i fuld størrelse
Boksen »Team details« med kontakten »Time tracking« og dens forklarende sætning.
På teamet holder du et enkelt team udenfor. Den røde ramme sidder på kontakten; poster, der allerede findes, bliver ved med at være synlige også da.Åbn billedet i fuld størrelse
2

At registrere indsats på en sag

Kun i Professional

Sagen bærer et kort, der hedder »Time spent«. »Log time« åbner indtastningen.

Hurtigknapper sidder ved siden af feltet: ét klik på »30m« registrerer tredive minutter. Hvilke knapper der dukker op, bliver sat i indstillingerne.

Feltet »Duration« tager også imod fri indtastning: »90« er halvfems minutter, »1.5h« er halvanden time, og det samme er »1h 30m«. Et tal uden enhed er altid minutter.

Indtastning, systemet ikke forstår helt, bliver afvist. »1h om aftenen« bliver ikke til en post på én time — det bliver til en fejlmeddelelse.

I »What for (optional)« skriver du, hvad tiden gik til. Teksten følger med ind i eksporten og dukker ikke op i sagens historik.

Flere agenter registrerer tid på den samme sag. Hver post bærer sin dag, sin note og navnet på den, der udførte arbejdet.

Tid bliver registreret på en dag, ikke på et klokkeslæt. At udfylde i går er det normale tilfælde, og et klokkeslæt ville påstå en præcision, indtastningen ikke har.

Den åbne indtastning på kortet »Time spent« med feltet »Duration«, hurtigknapperne, notefeltet og fluebenet »Billable«.
Den røde ramme sidder på hurtigknapperne. Ved siden af dem tager feltet imod fri indtastning, og hjælpeteksten nedenunder nævner de formater, det accepterer.Åbn billedet i fuld størrelse
Listen over tidsposter på en sag med tre poster fra to agenter, hver med en dato, en note og et navn.
Tre poster, to agenter, én sag. Den røde ramme sidder på navnet og dagen, med noten nedenunder.Åbn billedet i fuld størrelse
3

Stopuret

Kun i Professional

Til lange forløb findes der et stopur på sagen: »Start timer« starter det, »Pause« holder det.

Stopuret opretter aldrig en post af sig selv. Det foreslår den forløbne tid, og der bliver ikke gemt noget, før du trykker på »Log«.

Det erstatter hovedregning, ikke viden. Uden det er funktionen komplet, for at taste værdien ind er den egentlige vej.

Åbner du en anden sag, holder det kørende stopur pause, og den nye sag fortæller dig, hvilken sag det hænger på.

Et skjult vindue er ikke en pause. Stopuret løber videre, hvis du bare klikker væk.

Mod et stopur, der er ladt kørende natten over, findes der en maksimal løbetid. Værdien bliver skåret til, aldrig kasseret, og agenten får det at vide.

Stopuret er slået fra som fabriksindstilling. Du finder det i indstillingerne under »Stopwatch on the ticket«.

Det kørende stopur på kortet »Time spent« med sin visning, »Pause«, »Discard« og den knap, der registrerer det.
Stopuret kører. Den røde ramme sidder på den knap, der overtager visningen; indtil da bliver der ikke gemt noget.Åbn billedet i fuld størrelse
4

Fakturerbar eller ej

Kun i Professional

Hver post bærer et »Billable«-flueben. Tiden bliver registreret én gang, og fluebenet bestemmer, om den kommer på fakturaen.

Derfor viser sagen to summer: alt det registrerede til venstre, den fakturerbare sum til højre.

Der findes ingen særskilt type til kulance. Kulance, garantiarbejde og internt efterarbejde hedder forskellige ting i hver virksomhed, og systemet kender kun den ene skelnen, der hænger penge på.

Sådan registrerer du kulance: tast tiden ind som sædvanlig, fjern fluebenet, og skriv begrundelsen i noten.

Posten bærer så synligt »not billable«. Minutterne bliver stående i den registrerede sum, for arbejdet fandt jo sted.

Den, der slet ikke registrerer tiden, mister netop det tal, der senere forklarer, hvorfor en kunde blev faktureret så lidt.

Er størstedelen af jeres arbejde ikke fakturerbart, så vend udgangspunktet om med kontakten »New entries are billable by default«.

Kortet »Time spent« med begge summer i hovedet og én post, der bærer markeringen »not billable«.
Begge summer står side om side øverst. Den røde ramme sidder på posten uden flueben: dens minutter tæller til venstre og ikke til højre.Åbn billedet i fuld størrelse
5

På minuttet eller rundet op

Kun i Professional

Som fabriksindstilling bliver alt faktureret på minuttet. Den, der fakturerer i kvarte timer, sætter to værdier.

»Rounding increment (minutes)« er trinnet. Hver post bliver rundet op til det næste multiplum.

»Minimum per entry (minutes)« er gulvet. Hver post bliver faktureret med mindst denne værdi.

De to virker efter hinanden: først gulvet, så trinnet. Med et gulv på 20 og et trin på 15 bliver fem minutter til tredive, fordi resultatet skal opfylde begge dele.

Under de to felter står en eksempelsætning med dine egne værdier. Den er regnet ud, ikke påstået.

Kun den fakturerede værdi bliver nogensinde rundet af, og kun per post — aldrig summen. To små poster bliver derfor rundet op to gange.

Den registrerede tid bliver ikke rørt. At ændre afrundingen senere forfalsker ingen gamle data, for værdien bliver regnet ud, når den bliver vist.

Du ser begge dele på posten: hvor afrundingen ændrer værdien, står resultatet ved siden af i parentes.

Felterne »Rounding increment« og »Minimum per entry« med den udregnede eksempelsætning og bemærkningen nedenunder.
Den røde ramme sidder på eksempelsætningen, regnet ud fra værdierne ovenover. Sætningen nedenunder siger, hvad afrundingen ikke rører ved.Åbn billedet i fuld størrelse
En tidspost på fem minutter med den fakturerede værdi ved siden af i parentes.
Den røde ramme sidder på den post, afrundingen ændrer. Til venstre står det registrerede, i parentes det fakturerede.Åbn billedet i fuld størrelse
6

En tidspost før lukning

Kun i Professional

En serviceleverandør vil tit ikke have nogen sag lukket uden registreret tid. Der findes en kontakt til det.

Den hedder »Require a time entry before resolving or closing« og er slået fra som fabriksindstilling.

Den gælder kun, når et menneske ændrer statussen. En agent uden en post får en besked, og sagen bliver stående åben.

Automatisk lukning, sammenlægning og massehandlinger bliver aldrig blokeret. Ellers ville der findes sager, ingen kan lukke længere.

Det er hele funktionens farligste kontakt. Slå den først til, når dit team virkelig registrerer tid hver gang.

Kontakten »Require a time entry before resolving or closing« med den sætning, der nævner undtagelserne.
Den røde ramme sidder på kontakten. Sætningen nedenunder nævner de tre tilfælde, der aldrig bliver blokeret.Åbn billedet i fuld størrelse
7

Kolonnen »Time« i sagslisten

Kun i Professional

Sagslisten får en »Time«-kolonne, der viser, hvor meget der allerede er registreret på en sag.

Du slår den ikke til. Den dukker op, så snart en sag i listen bærer tid.

På smalle vinduer er den en af de første, der falder ud igen. Listen beholder så de kolonner, uden hvilke en sag ikke kan findes.

Sagslisten med en »Time«-kolonne og værdier på de sager, der bærer registreret tid.
Den røde ramme sidder på kolonnen. Kun sagerne med registreret tid bærer en værdi.Åbn billedet i fuld størrelse
8

Rapporten

Kun i Professional

Tid, der kun står på en enkelt sag, er intet grundlag for en faktura. Derfor bærer rapportsiden et kort med navnet »Time spent«.

Fire tal står øverst: registreret, faktureret, antallet af poster og antallet af sager, der overhovedet bærer tid.

Det sidste tal er det vigtigste efter summen. Fyrre timer på tre ud af fem hundrede sager er ikke en opgørelse — det er tre agenter, der som de eneste registrerer.

Nedenunder kommer opdelingerne: efter anmelder, efter team, efter kategori og efter dag.

Dertil kommer én tabel per brugerdefineret felt. Det er vejen til at fakturere efter firma eller omkostningssted: du opretter et brugerdefineret felt, udfylder det på sagen, og rapporten grupperer efter det.

Perioden øverst på siden gælder den dag, arbejdet blev udført. Juliarbejde på en junisag står derfor i julirapporten.

En bemærkning over tallene fortjener at blive taget alvorligt: de kommer fra poster, mennesker har lavet, og fra jeres afrundingsregler. De er et arbejdsgrundlag, ikke en revideret faktura.

Rapportsiden med kortet »Time spent«, dets fire tal og tabellerne nedenunder.
Kortet sidder på rapportsiden. Den røde ramme viser, hvor det er at finde.Åbn billedet i fuld størrelse
Kortets fire flader: registreret, faktureret, poster og sager med tid.
Den røde ramme sidder på antallet af sager med tid. Det sætter summen til venstre for det i perspektiv.Åbn billedet i fuld størrelse
Tabellerne »By requester«, »By team« og »By category« med deres rækker, hver med registreret og faktureret tid.
Den røde ramme sidder på opdelingen efter kategori. Hver række nævner begge summer.Åbn billedet i fuld størrelse
Tabellen til det brugerdefinerede felt »Cost centre« med én række per omkostningssted.
Én tabel per brugerdefineret felt. Den røde ramme sidder på opdelingen efter omkostningssted.Åbn billedet i fuld størrelse
9

Eksporten til bogholderiet og til kunden

Kun i Professional

Tre knapper sidder under kortet. De leverer de enkelte poster, ikke summerne fra siden.

Det er to modtagere, ikke tre filformater. »Export entries (CSV)« og »Export entries (Excel)« går til bogholderiet: begge er komplette og bliver aldrig skåret af.

»Export entries (PDF)« er dokumentet til et menneske. Det går til kunden som bilag til fakturaen.

PDF'en er skåret ved 20.000 poster, og dokumentet siger det selv. Ingen læser alligevel en faktura med flere linjer end det.

Alle tre filer bliver bygget af den samme kilde: filtre, afrunding, kolonner og tal findes én gang, så de tre kan ikke glide fra hinanden.

En post, der ikke er fakturerbar, har en tom celle i den fakturerbare kolonne, ikke et nul. Et nul ville blive lagt sammen i en pivottabel.

De tre knapper »Export entries (CSV)«, »(Excel)« og »(PDF)« med de sætninger, der nævner forskellen.
Den røde ramme sidder på de tre knapper. Sætningerne nedenunder siger, hvilken fil der er ment til hvem.Åbn billedet i fuld størrelse
Første side i den fremstillede PDF med sit hoved, sine tal og tabellen over de enkelte poster.
Det er det dokument, kunden får. Hver linje er én post med sin dato, sag, agent, note og begge værdier.Åbn billedet i fuld størrelse
10

Kunder ser ikke den registrerede tid

Kun i Professional

En kunde ser aldrig tidsposterne, heller ikke på sin egen sag.

Det er ikke en indstilling, men en spærring i serveren. Der findes ingen kontakt, der åbner den.

Grunden ligger i posterne selv: noter bliver skrevet til teamet. De siger, hvad der gik galt, og hvor længe jagten på årsagen tog.

Andre systemer af den slags gør det samme. Hvor tid når kunden, når den hende som et dokument.

Det er det, PDF-eksporten er til: den går ud med fakturaen og ikke ind på sagen i kundeportalen.

Mere om det på kortet: Eksporten til bogholderiet og til kunden

Den samme sag, som kunden ser den: beskrivelse, kommentarer og status, men intet »Time spent«-kort.
Den samme sag, set af anmelderen. Kortet med tiden mangler helt.Åbn billedet i fuld størrelse
11

Opdelingen per agent kan slås fra

Kun i Professional

Rapporten kan desuden vise, hvem der registrerede hvor meget. Som fabriksindstilling gør den ikke.

Tid per person er præstationsdata, og i mange virksomheder har samarbejdsudvalget medbestemmelse på det.

Kontakten hedder »Per-agent evaluation« og sidder i indstillingerne.

Så længe den er slået fra, leverer serveren ikke engang tallene. Tabellen er ikke skjult — den findes ikke.

Den forskel betyder noget. En spærring, som kun visningen kender til, er ingen spærring.

Mere om det på kortet: Ingen historik over tilgængelighed, ingen opgørelse per person

Rapporten med tabellerne efter team og efter dag, uden en tabel per agent.
Sådan ser rapporten ud som fabriksindstilling. Mellem kategori og dag er der ingen tabel per agent.Åbn billedet i fuld størrelse
Det samme sted med kontakten slået til: en »By agent«-tabel med én række per agent.
Det samme sted, efter at kontakten er slået til. Mellem »By category« og »By day« er der nu en tabel per agent.Åbn billedet i fuld størrelse

Rapportering og dashboards

Dashboardet viser, hvor et team står. Rapporten svarer på et spørgsmål, du selv stiller. Begge læser kun; ingen af dem ændrer nogensinde en sag. Bortset fra dine egne felter er hele denne blok en del af Basic.

1

Dashboardet: hvor tingene står

Øverst er der én flade per status med sit antal. Nedenunder står tre tal for hele teamet: »Total tickets«, »Tickets which are not Closed« og »Avg. resolution time«.

Det midterste tal er det vigtige. Det siger, hvor meget arbejde der er åbent lige nu.

»Avg. resolution time« bliver stående tom, så længe ingen sag er løst. En streg er mere ærlig end et nul.

Kortet »Top 3 longest open tickets« nævner de tre ældste åbne sager med deres alder. Det er dem, ingen bringer op længere.

Nedenunder sidder tre diagrammer: »Tickets by status«, »Tickets by priority« og »Tickets by category«.

Dashboardet viser altid den aktuelle tilstand. Du kan ikke vælge en periode her; det er, hvad rapporten er til.

Helpdesk-teamets dashboard med statusfladerne øverst og de tre nøgletal nedenunder.
Den røde ramme sidder på de tre nøgletal. I denne eksempelverden har teamet 22 sager, 20 af dem ikke lukket.Åbn billedet i fuld størrelse
Kortet »Top 3 longest open tickets« med tre sager og deres alder.
Ét klik på en post åbner sagen.Åbn billedet i fuld størrelse
Diagrammerne »Tickets by status«, »Tickets by priority« og »Tickets by category«.
Kategorierne er teamets egne. Et andet team viser andre her.Åbn billedet i fuld størrelse
2

Hvert team har sit eget dashboard

Sidemenuen bærer én post per team. Den hedder »Dashboard« efterfulgt af teamnavnet.

Hver post viser kun sit eget teams sager. Tallene, kategorierne og de ældste sager er derfor forskellige fra team til team.

Rettigheden hænger på det enkelte dashboard. Du kan give en rolle adgang til det ene team og ikke til det andet.

Den, der ikke har ret til et dashboard, ser slet ikke posten. En spærret post, der stadig er synlig, rejser kun spørgsmål.

Helpdesk-teamets dashboard, med sidemenuposten »Dashboard · Helpdesk« fremhævet.
Den røde ramme sidder på sidemenuposten. I denne eksempelverden viser Helpdesk 22 sager.Åbn billedet i fuld størrelse
Det samme dashboard for netværksteamet med andre tal og andre kategorier.
Den samme side, et andet team. Her er det 6 sager, og kategorierne er »Wi-Fi« og »Firewall«.Åbn billedet i fuld størrelse
3

At fremstille og filtrere rapporten

Siden »Reports« er tom, når du åbner den. Kun filterboksen er der.

Først klikket på »Generate report« starter beregningen. Det tager et øjeblik, fordi hvert afsnit bliver regnet ud på én gang.

Det er med vilje. En rapport, der regner om ved hvert tastetryk, ville være ubrugelig på en stor datamængde.

Bagefter står fire nøgletal øverst og diagrammerne nedenunder.

Hvert diagram nævner sine tal. Ringene trykker antal og andel i signaturforklaringen ved siden af; søjlerne trykker antallet over søjlen.

Filterboksen ovenover er der, hvor du stiller spørgsmålet. Du kan vælge perioden gennem »From« og »To«, teamet, statussen, agenten, anmelderen, lokationen, prioriteten, hoved- og underkategori, og den kanal, sagen kom ind ad.

Sætter du flere felter, gælder de samtidig. »Perioden juli, teamet Helpdesk, prioriteten High« er ét enkelt spørgsmål.

Perioden går efter den dag, sagen blev oprettet.

Der er én undtagelse. Tidsrapporten går efter den dag, arbejdet blev udført. Juliarbejde på en junisag dukker derfor op i julirapporten.

Efter hver ændring af filteret skal du klikke på »Generate report« igen.

Denne side bærer også opgørelserne fra andre funktioner. De dukker kun op, når funktionen er slået til, og der skete noget i den valgte periode.

De bliver forklaret der, hvor de hører hjemme: frister under »SLA-tal i rapporteringen«, bedømmelser under »Rapporten om bedømmelserne«, fordeling under »Rapporten om fordelingen« og indsats under »Rapporten«.

Rapportsiden lige efter åbningen: kun filterboksen, ingen tal.
Den røde ramme sidder på »Generate report«. Indtil nogen klikker på den, bliver siden tom.Åbn billedet i fuld størrelse
Rapportsidens filterboks med periode, team, status, agent, kategorier og kanal.
Alle felter gælder samtidig. Tom betyder »alle«.Åbn billedet i fuld størrelse
Den fremstillede rapport med fire nøgletal og de første diagrammer nedenunder.
I denne eksempelverden er der 28 sager. Hver søjle bærer sit antal over sig, og ringene viser antal og andel ved siden af.Åbn billedet i fuld størrelse
4

At filtrere og gruppere efter dine egne felter

Kun i Professional

Har du oprettet dine egne felter, tilbyder rapporten dem præcis som de indbyggede.

Hvert af dine felter får et filter i boksen og sit eget diagram i rapporten.

Det svarer på spørgsmål, kun jeres virksomhed stiller. »Hvor mange sager går til hvilket omkostningssted?« er et af dem.

Diagrammernes navne er navnene på jeres felter. De bliver ikke oversat, fordi de kommer fra jeres installation.

Hvor du opretter dine egne felter, står beskrevet under »Brugerdefinerede felter«.

To diagrammer bygget af brugerdefinerede felter: »Asset tag« og »Cost centre«.
Denne eksempelverden har felterne »Asset tag« og »Cost centre«. Jeres installation viser jeres egne her.Åbn billedet i fuld størrelse
5

Hvilke kolonner rapporten viser

Under »Settings → Report Settings« bestemmer du, hvilke felter rapporten tilbyder.

Siden har tre afsnit: »Admin«, »Agent« og »Customer«. Hvert afsnit bærer den samme liste med sine egne kontakter.

Et felt, du slår fra her, forsvinder for den rolle fra filteret og fra eksporten.

Som fabriksindstilling ser administratorer og agenter alt. Kunder ser mindre, fordi de ikke har brug for agenten, lokationen eller prioriteten.

Dine egne felter står under »Custom fields« i den samme liste.

Siden »Report Settings« med de tre afsnit »Admin«, »Agent« og »Customer«.
Den røde ramme sidder på afsnittet »Customer«. Hver rolle har sin egen liste.Åbn billedet i fuld størrelse
6

Kunder henter deres egen rapport

En kunde kan åbne den samme rapport som en agent. I den ser hun kun sine egne sager.

Grænsen sidder i systemet, ikke i filteret. En kunde kommer ikke uden om den, heller ikke ved at taste adressen ind i hånden.

Du låser den op på teamet. Kontakten sidder under »Settings → Teams« og hedder »Has permission to view their own Tickets in the Dashboard and in Reports for this Team«.

Som fabriksindstilling er den slået fra. Så længe den er slået fra, finder en kunde hverken dashboardet eller rapporterne.

Hvilke kolonner kunden ser, kommer fra afsnittet »Customer« i rapportindstillingerne.

Filudlæsningen står også åben for hende. En kunde kan hente sine egne sager som CSV, Excel eller PDF.

Teamkontakten, der åbner dashboard og rapporter for en kunde.
Kontakten sidder i boksen »Team details«. Den gælder dette ene team.Åbn billedet i fuld størrelse
Rapportsiden fra en kundekonto, med færre filtre og mindre tal.
Den samme side fra Julia Beckers konto. I denne eksempelverden ser hun 8 sager i stedet for 28, og agentfilteret mangler.Åbn billedet i fuld størrelse
7

At eksportere som CSV, Excel eller PDF

Under filterboksen står tre knapper: »CSV export«, »Excel export« og »PDF export«.

Alle tre lægger det ud, der lige nu står på skærmen, så filteret gælder også.

Excel-filen har to faner. »Key figures« rummer tallene, »Tickets« rummer de enkelte sager.

Tal og diagrammer er altid med. Listen over de enkelte sager kun, når du sætter flueben i »Include ticket table in export«.

Sætter du fluebenet, dukker det rigtige antal sager og det anslåede sidetal op nedenunder.

Ved rigtig mange sager dukker der desuden en rød advarsel op. Den siger, at eksporten kan tage et stykke tid.

CSV og Excel indeholder hver række. PDF'en stopper ved 20.000 sager og skriver det ind i dokumentet.

Grænsen står allerede på siden, før du eksporterer. En grænse, man først får at vide i det færdige dokument, kommer for sent.

De tre eksportknapper og nedenunder fluebenet til sagstabellen.
Den røde ramme sidder på fluebenet. Kun når det er sat, dukker linjen med antallet af sager op. I denne eksempelverden er det 28 sager og cirka 4 sider.Åbn billedet i fuld størrelse
8

PDF'en trykker tallene ved siden af diagrammerne

PDF'en er ment til at blive givet videre. Den indeholder de samme diagrammer, der står på skærmen.

Ved siden af hvert diagram står det tal, det er bygget af, og andelen i procent.

Det er derfor, de er der. En søjle kan man se på, men ikke kontrollere.

På skærmen viser musemarkøren det samme tal. På et trykt ark findes der ingen musemarkør.

Dokumentet nævner perioden og den dag, det blev lavet, øverst.

En side i den fremstillede PDF med et diagram og dets tal ved siden af.
Dokumentet, som modtageren får det. Ved siden af hver søjle står antallet og andelen.Åbn billedet i fuld størrelse

Tilfredshedsmålinger (CSAT)

Når en sag er lukket, spørger du jeres kunder, hvordan det gik. Hele denne blok er en del af Professional.

1

Målingen efter lukningen

Kun i Professional

Før du går i gang: To ting skal være på plads, ellers sker der ingenting. Afsendelse af e-mail skal være sat op. Og under »Settings → Security« skal denne installations offentlige adresse være rigtig, fordi linket i mailen bliver bygget af den. Med den forkerte adresse gemt der sender systemet alligevel målingen, og jeres kunde ender på en side, der ikke findes.

Når en sag bliver lukket, får anmelderen en e-mail med fem stjerner. Hver stjerne er sit eget link, og ét klik er hele svaret.

Mailen går ikke ud med det samme. Systemet venter en time efter lukningen, og fra da af sender en baggrundstjeneste de målinger, der er forfaldne, hvert tiende minut. Timen er med vilje: en sag, der bliver genåbnet med det samme, skal ikke udløse en måling.

Der findes præcis én måling per sag. Også hvis en sag bliver genåbnet og lukket igen senere, spørger systemet ikke en anden gang.

Linket kræver ingen kundekonto og er gyldigt i 30 dage. Indtil da kan jeres kunde ændre bedømmelsen — et fejlklik på den forkerte stjerne er mere almindeligt end misbrug.

En kommentar er valgfri. At klikke på en stjerne er allerede en bedømmelse; den, der vil tilføje noget, finder et felt til det på siden og bekræfter med »Update rating«.

Siden viser kun sagens nummer og titel. Beskrivelse, kommentarer og historik står ikke på den: linket er en ret til at bedømme, ikke en ret til at læse — det kan blive sendt videre eller lande i en fælles postkasse.

Klikket fra mailen skriver først bedømmelsen, når siden er indlæst. Derfor bedømmer virusscannere og forhåndsvisninger ikke jeres sager: de henter adressen, men de kører ingen JavaScript. For et menneske er det stadig ét klik.

Den bedømmelse, der kommer tilbage, sidder på sagen, hvor agenter og administratorer i det ansvarlige team kan se den. Kunden ser den aldrig der, heller ikke sin egen.

Ikke hver lukket sag bliver spurgt. Uden en adresse på anmelderen går der slet ingen mail ud, og sammenlagte dobbelte anmeldelser samt de anmeldelser, der hænger på en samlesag, holdes også udenfor — at løse en samlesag lukker hver tilknyttet anmeldelse med ét klik, og uden den undtagelse ville hver anmelder blive spurgt om det samme stykke arbejde.

Målingsmailen i kundens postkasse med fem stjernelinjer og linket til målingssiden.
Sådan kommer målingen frem. Hver af de fem linjer er sit eget link, nedenunder sidder vejen til siden med kommentarfeltet. Adressen i linkene er den, du gemte under »Security«.Åbn billedet i fuld størrelse
Målingssiden med fem stjerner, bedømmelsen sat, et kommentarfelt og knappen »Update rating«.
Siden efter klikket på den femte stjerne: bedømmelsen er gemt, kommentarfeltet bliver stående åbent. Kun sagens nummer og titel bliver vist.Åbn billedet i fuld størrelse
Bedømmelsen på sagen med fem stjerner og kundens kommentar.
Det samme resultat på sagen. Den røde ramme sidder på bedømmelsen — den er her for teamet, ikke for kunden.Åbn billedet i fuld størrelse
2

At slå den til og begrænse den

Kun i Professional

Målingen har præcis ét sted at blive sat op: under »Settings → General«, i kortet »Customer Satisfaction Score (CSAT)«, med tre betjeninger på. Der findes intet indstillingsområde for sig.

»Send satisfaction surveys« slår afsendelsen til; den er slået fra som fabriksindstilling. Kun sager, der bliver lukket efter, at du har slået den til, bliver spurgt — ellers ville hele din bunke få en mail på én gang.

Slår du den fra igen, bliver de bedømmelser, du allerede har, ved med at være synlige. Der går bare ikke noget nyt ud længere.

Over kontakterne ser du den adresse, linkene bliver bygget af. Den står der for at blive kontrolleret, ikke for at blive rettet: du ændrer den det ene sted, hvor den bliver vedligeholdt, og hjælpeteksten ved siden af fører dig derhen.

Den midterste kontakt, »Per-agent evaluation«, hører til rapporten. Hvad den gør der, og hvorfor den er slået fra som fabriksindstilling, står på kortet om rapporten.

»At most one survey per requester within« begrænser, hvor tit den samme person bliver spurgt. Fabriksindstillingen er 7 dage: den, der anmelder flere sager inden for det vindue, bliver alligevel kun spurgt én gang.

Med 0 spørger du ved hver lukket sag. Til en intern helpdesk er det som regel for meget, fordi de samme mennesker anmelder igen og igen; en kundeafdeling med mange forskellige afsendere når sjældent grænsen overhovedet.

Målingen er bevidst enkel. Skalaen ligger fast på en til fem stjerner, og det samme gør timens forsinkelse og de 30 dages gyldighed. To forskellige skalaer i den samme database ville betyde, at rapporten lægger gennemsnit af ting, der ikke kan sammenlignes.

Mere om det på kortet: Rapporten om bedømmelserne

Kortet »Customer Satisfaction Score (CSAT)« med to kontakter og talfeltet til grænsen.
Hele indstillingen på ét kort. De røde rammer sidder på de to kontakter og på feltet til grænsen; ovenover står den adresse, linkene bliver bygget af.Åbn billedet i fuld størrelse
Kortet »Public address of this installation« med adressefeltet og linjen »Currently in use«.
Selve adressen bliver vedligeholdt under »Settings → Security«. Linjen nedenunder fortæller dig, hvilken adresse der er i brug lige nu, og hvor den kom fra.Åbn billedet i fuld størrelse
3

Rapporten om bedømmelserne

Kun i Professional

Under »Reports« har tilfredsheden sit eget afsnit, »Customer satisfaction (CSAT)«. Det står i den samme rapport som alt andet og følger de samme filtre — periode, team, kategori og agent.

Fem flader sidder øverst. »Average score« er gennemsnittet af stjernerne, »Satisfaction rate (4-5 stars)« fortæller dig, hvilken andel der var tilfreds, »Response rate« er, hvor mange der svarede, og »Surveys sent« tæller de målinger, der gik ud. Under begge grader finder du med småt den brøk, de blev bygget af.

»Closed without survey« er den femte flade. Den tæller de lukkede sager, der aldrig blev spurgt, med det samlede antal lukkede sager nedenunder. Uden det tal ville du tage en grad for billedet af jeres kunder, og den ville hvile på en delmængde, du ikke kan se.

Det tal, der betyder mest, er ikke gennemsnittet, det er svarprocenten. En god karakter bygget på få svar siger lidt om jeres kunder.

Nedenunder kommer fordelingen: for hvert stjerneantal fra fem ned til én viser en søjle, hvor tit det blev givet, med tallet ved siden af. Så kommer »Trend«, én række for hver dag, hvor nogen svarede, med datoen, den dags gennemsnit som søjle og antallet af svar. Til sidst kommer »By agent« med én række per agent og »Latest comments« med det, folk faktisk skrev. En opdeling »By team« støder til, så snart mere end ét team har bedømte sager.

Du kan slå opdelingen per agent fra. »Per-agent evaluation« er slået fra som fabriksindstilling, fordi bedømmelser per person er præstationsdata — i mange virksomheder har samarbejdsudvalget medbestemmelse på det, og hos cloud-udbydere kan den opgørelse tit slet ikke slås fra.

Kontakten træder i kraft på serveren og ikke kun på skærmen: med den slået fra mangler opdelingen også i eksporten.

Den enkelte bedømmelse på en sag bliver ikke rørt af det og bliver ved med at være synlig for teamet. Kontakten styrer opgørelse på tværs af mennesker, ikke det, der bliver vist på én sag.

Filteret »Satisfaction« skærer rapporten ned til bedømmelser. »Rated only« viser bedømte sager, »Not rated« viser de ubedømte, og med »Score from« og »Score to« kan du se på hver sag med en eller to stjerner. Filteret gælder tabellen og begge eksporter.

Rapportens afsnit »Customer satisfaction (CSAT)« med fem nøgletal og fordelingen af stjernerne.
Afsnittets fem flader. Den røde ramme sidder på »Closed without survey« — det tal, der sætter svarprocenten i perspektiv.Åbn billedet i fuld størrelse
Afsnittet »Trend« med én række per dag, gennemsnittet som søjle og antallet af svar.
Forløbet over tid. For hver dag ser du datoen, gennemsnittet som søjle med tallet ved siden af, og til højre hvor mange svar der kom ind den dag. I eksemplet kom begge svar den samme dag, så der er én række.Åbn billedet i fuld størrelse
Opdelingen »By agent« med én række per agent, og de seneste kommentarer.
Opdelingen per agent, sammen med kommentarerne, som de blev skrevet. Det er den del af rapporten, du kan slå fra.Åbn billedet i fuld størrelse
4

En dårlig bedømmelse som udløser

Kun i Professional

En bedømmelse kan udløse en regel. I regelredigeringen under »Settings → Automation« findes der en betingelse til det, »Satisfaction rating (CSAT)«, og ved siden af vælger du »is at most«, »is at least«, »is« eller »is not«. Det tredje felt rummer stjernerne, fra en til fem, med tallet ved siden af.

Det sædvanlige tilfælde er »is at most 2«. Over reglen læser du så den sætning, redigeringen skriver med: »When a ticket was rated 2 stars or fewer, then send an e-mail to the assignee.«

Denne regel kræver ingen tidsbetingelse, så »WHEN«-blokken bliver stående tom. Det gør den til undtagelsen blandt reglerne: alle de andre venter på, at noget ikke er sket i et stykke tid, denne venter på en hændelse.

Som handling har du alt det, en regel alligevel kan: sende en mail, hæve prioriteten, give sagen til et andet team eller sætte en påmindelse.

Én ting virker anderledes her. Regler lader normalt lukkede sager være, men en bedømmelse kommer næsten altid ind på en lukket sag — så en regel med denne betingelse når også lukkede sager. Hver anden regel gør stadig ikke.

Betingelsen gælder aldrig en sag uden bedømmelse, og det gælder også »is not« — ellers ville »ikke fem stjerner« ramme hele din ubedømte bunke. Vil du vide, hvor mange der ikke svarede, er det svarprocenten i rapporten.

Reglen handler én gang per bedømmelse. Nedenunder åbner »Log« tabellen »What this rule did« med én række per sag, så du kan se, hvornår den kørte, og hvad den gjorde.

Regelredigeringen med betingelsen »Satisfaction rating (CSAT) is at most 2« og sætningen ovenover.
Betingelsen i redigeringen. De røde rammer sidder på betingelsen og på sætningen ovenover, og den sætning skriver sig selv om ved hver ændring.Åbn billedet i fuld størrelse
Tabellen »What this rule did« med én række til den dårligt bedømte sag.
Reglens log. Rækken viser sagen, tidspunktet og den handling, der blev udført.Åbn billedet i fuld størrelse

Vidensbase

Den del, der forhindrer sager: løsninger skrevet ned én gang, fundet igen af dit team — og foreslået anmelderen, mens hun stadig taster. Alt i denne blok er en del af Basic.

1

Emneflader med artikler og vedhæftede filer

Du når vidensbasen gennem »Knowledge Base« i bjælken til venstre. Oversigten består af flader — én per emne. Tallet øverst til højre på en flade er antallet af udgivne indlæg; nedenunder står emnets navn og beskrivelse. Et klik på fladen fører til listen over indlæg, hvert med forfatter, ændringsdato og de første linjer af sin tekst.

Emnerne opretter du ikke her, men under »Settings → Knowledge Base« (se kortet »Synlighed per emne«). Uden et eneste emne viser oversigten intet andet end en bemærkning — et indlæg skal altid have et emne.

Du skriver med »New entry« på en emneside. Redigeringen beder om tre ting: »Title«, »Topic« og »Content«. Det er den samme redigering som i en sag, med den samme værktøjslinje: »Bold«, »Italic«, »Underline«, »Strikethrough«, »Text color«, »Highlight color«, »Bullet list«, »Numbered list«, »Quote«, »Link« og »Clear formatting«. Et link laves som i en sag: markér teksten, klik på »Link«, tast adressen ind — web- og mailadresser er tilladt (http, https, mailto). »Save« bliver ved med at være grå, så længe titel eller emne mangler, og et indlæg uden tekst bliver afvist: vedhæftede filer alene er ikke et indlæg.

Billeder kommer ind i teksten gennem udklipsholderen, præcis som i en sag: tag et skærmbillede, og indsæt det i redigeringen med Ctrl+V. En markør som »[inline-image:1]« dukker op i teksten; ved gemningen uploader systemet billedet og viser det præcis det sted. Det dukker desuden op nedenunder under »Attachments« — det er der, du sletter det igen. PNG, JPEG og GIF kan indsættes.

Du vedhæfter først filer, når indlægget er gemt: nederst på indlæggets side sidder kortet »Attachments« med »Upload file«. Tilladte filtyper og størrelse er de samme som ved en sag (op til 50 MB per fil). Den, der uploadede en fil, må fjerne den igen; administratorer må fjerne dem alle.

Administratorer må altid skrive, agenter så længe kontakten i indstillingerne tillader det (se kortet »Godkendelse«). Kunder læser kun. En administrator må slette hvert indlæg; forfatteren må slette sine egne, så længe de stadig venter på godkendelse.

Vidensbasens oversigtsside med tre emneflader og menupunktet »Knowledge Base« indrammet i rødt.
Vejen ind: »Knowledge Base« i bjælken til venstre. Hver flade er et emne; tallet nævner de udgivne indlæg, den ravgule mærkning de ventende.Åbn billedet i fuld størrelse
Redigeringen »New entry« med felterne Title og Topic, redigeringens værktøjslinje og den gråtonede »Save«-knap.
Titel, emne, indhold. Så længe der ikke er valgt et emne, bliver »Save« ved med at være grå — i den røde ramme det valg, der stadig mangler her.Åbn billedet i fuld størrelse
Et indlæg i vidensbasen med formateret tekst, et indsat billede af printerens display, en nummereret liste og kortet »Attachments« med to filer.
Et færdigt indlæg: hoved med emne, forfatter og godkendelse, nedenunder teksten med et indsat billede. Nederst står begge filer — lynvejledningen til download og det indsatte billede.Åbn billedet i fuld størrelse
3

Synlighed per emne: kun internt eller vendt mod kunden

Før du går i gang: Synligheden hænger på EMNET, ikke på det enkelte indlæg. En intern note i et kundevendt emne kan læses af kunder, så snart den er udgivet — planlæg jeres emner derefter, og flyt et indlæg til et andet emne gennem »Edit«, hvis det er nødvendigt.

Emner vedligeholder du under »Settings → Knowledge Base« i kortet »Topics«. Hver række bærer et navn, en beskrivelse, et sorteringsnummer til fladernes rækkefølge, kontakten »Visible to customers« og to knapper til at gemme og slette — du gemmer per række, ikke hele kortet.

Med kontakten slået fra ser kun agenter og administratorer emnet, dets indlæg og deres vedhæftede filer — en kunde får slet ikke fladen og finder heller ikke indlæggene gennem søgningen. Med den slået til ser kunder emnet og de udgivne indlæg i det; udkast bliver usynlige under alle omstændigheder.

Et nyt emne opretter du i den stiplede række nedenunder: tast et navn ind, vælg synligheden, »Add topic«. Et emne kan kun slettes, mens det er tomt — ellers ville du slette dets indlæg med, uden at se dem.

Kortet »Topics« med tre emner; kontakten »Visible to customers« er slået til for det første emne og fra for »Internal runbooks«.
Forskellen sidder i de to røde rammer: »Printing« er frigivet til kunder, »Internal runbooks« er ikke. Du gemmer per række med den orange knap til højre.Åbn billedet i fuld størrelse
4

Foreslåede løsninger, mens en sag bliver oprettet

Så snart der står tre tegn i feltet »Title« i formularen »Create new ticket«, søger systemet i baggrunden og viser boksen »Possible solutions from the knowledge base« — op til fem indlæg, der passer til titlen. Den, der finder sit svar der, opretter ingen sag; det er hele pointen.

Kun TITLEN bliver gennemsøgt, ikke beskrivelsen. Den samme regel som i søgningen gælder: et forslag skal indeholde mindst halvdelen af titlens ord — jo mere præcis titlen er, jo færre og jo bedre passende bliver forslagene. Et klik på et forslag åbner det i en ny fane, så den halvt udfyldte formular ikke går tabt; »Open knowledge base« nederst fører til hele oversigten.

Synligheden gælder også her: en kunde får kun udgivne indlæg i kundevendte emner foreslået. Som agent ser du desuden interne emner og indlæg, der stadig venter på deres godkendelse.

Feltet »Title« i formularen til en ny sag med boksen »Possible solutions from the knowledge base« og forslagene nedenunder.
Kun titlen er tastet ind — boksen nedenunder dukker op af sig selv. Øverst står de indlæg, der passer bedst til titlen.Åbn billedet i fuld størrelse
5

At gøre en løst sag til et indlæg

Før du går i gang: ALT bliver taget med: beskrivelsen og hver kommentar, også de interne. Teksten er en kopi, ikke et link — læs den igennem, og fjern navne, telefonnumre, e-mailadresser og ordrenumre, før du gemmer. Bagefter kan alle, der må se emnet, læse den.

Øverst til højre på hver sag sidder »Add to knowledge base«. Knappen åbner redigeringen til et nyt indlæg, udfyldt på forhånd med sagens titel og hele dens forløb: beskrivelsen som første afsnit, hver kommentar nedenunder som citat.

Det alene giver dig ingenting — det er råmateriale. Pointen er, at du gør det til en vejledning: skær det ned til det, der hjælper næste gang, og skriv titlen om, hvis den lyder som en enkelt sag (»Printer on 2nd floor pulls two sheets« bliver til »At afhjælpe et papirstop«).

Der er ikke valgt noget emne på forhånd, det vælger du selv. Indlægget bliver gemt som ethvert andet: udgivet med det samme som administrator, sendt til godkendelse som agent. Bagefter bliver den interne henvisning »Source: Ticket #1« stående på indlægget — den er et spring tilbage til sagen og er ikke synlig for kunder.

En sag med den rødt indrammede knap »Add to knowledge base« øverst til højre.
Knappen sidder øverst til højre på hver sag — uanset hvilken status sagen står i lige nu. Den er ment til den sag, der er løst.Åbn billedet i fuld størrelse
Redigeringen »New entry« udfyldt på forhånd med sagens titel og forløb, ovenover den rødt indrammede bemærkning om kildesagen.
Bemærkningen i den røde ramme siger det, der betyder noget. I teksten nedenunder står den interne note med indkøbsordrenummeret — præcis det, der skal væk før gemningen.Åbn billedet i fuld størrelse
6

Godkendelse: indlæg fra en agent venter på administratoren

Om agenter overhovedet må skrive, bestemmer kontakten »Agents can create entries« under »Settings → Knowledge Base«. Den er slået til som udgangspunkt. Slået fra er den en hård grænse: knappen »New entry« forsvinder, og at kalde redigeringen direkte bliver også afvist.

Der findes præcis to tilstande — »Awaiting review« og »Published«; der findes intet udkast, du kan arbejde stille videre på, uden at nogen ser det. Hvem der skriver, bestemmer tilstanden: en administrator udgiver med det samme. En agent laver et indlæg markeret »Awaiting review« — synligt for agenter og administratorer, ikke for kunder. På emnefladen dukker den ravgule mærkning »1 awaiting review« op for det.

Administratorerne får desuden en e-mail, så snart et indlæg er til godkendelse. Det er en tilføjelse, ikke et krav: uden opsat udgående post bliver mærkningen den måde, en ventende godkendelse bliver fundet på. Du godkender på indlæggets side med »Approve & publish«; bagefter står der, hvem der godkendte det.

Ændrer en agent senere et udgivet indlæg, går det tilbage til godkendelse — ændringen bliver først synlig for kunder igen efter det næste »Approve & publish«. Den, der allerede venter og gemmer en gang til, udløser ikke en e-mail nummer to.

Vidensbasens indstillingsside med kontakten »Agents can create entries« indrammet i rødt.
Kontakten sidder allerøverst i »Settings → Knowledge Base«. Sætningen ved siden af siger, hvad der hænger på den: indlæg fra agenter venter på godkendelse.Åbn billedet i fuld størrelse
Et indlæg markeret »Awaiting review« med knappen »Approve & publish« indrammet i rødt.
Indlægget kommer fra agenten Marco Rossi og venter. Ét klik på »Approve & publish« gør det synligt for alle, der må se emnet.Åbn billedet i fuld størrelse
7

Vidensbasens ændringshistorik

Under »Settings → Knowledge Base« sidder kortet »History« allernederst. Det opregner de sidste 200 hændelser, nyeste først: hvad der skete, hvilket indlæg eller emne det ramte, hvem der gjorde det, og hvornår.

Syv hændelser bliver noteret: indlæg oprettet, opdateret, godkendt og slettet, plus emne oprettet, opdateret og slettet. Et slettet indlæg forsvinder derfor ikke sporløst — linjen bliver stående, også når indlægget er væk.

To linjer på én gang er ikke en fejl: når en administrator opretter et indlæg, står der »Entry created« og lige ovenover »Entry approved« — hun udgiver uden omvejen over godkendelsen. Ved en agent dukker først kun »Entry created« op; godkendelsen kommer senere og med administratorens navn.

Kun den, der må åbne vidensbasens indstillingsside, ser historikken — administratorer, som udgangspunkt. Det er én historik for hele vidensbasen, ikke én per indlæg.

Kortet »History« med linjer som »Entry created«, »Entry approved« og »Topic created«, hver med et navn og et tidspunkt.
Allerøverst agentens indlæg, der stadig venter på godkendelse — det har endnu ingen »Entry approved«-linje. Nedenunder administratorens indlæg, hver med begge linjer.Åbn billedet i fuld størrelse

Sikkerhedskopi og gendannelse

Sikkerhedskopier har deres eget program. Det følger med systemet, og installationen sætter det op, så der er intet at købe og intet at indstille. Denne blok viser, hvad det gemmer, hvornår det kører, og hvordan du får alt tilbage, når det gælder. Hele denne blok er en del af Basic.

1

Programmet til sikkerhedskopi og gendannelse

Programmet hedder »Ticket System Backup & Restore«. Det står ved siden af ticketsystemet og har sin egen genvej på skrivebordet.

Der findes en udgave til Windows og en til Linux. Det er det samme program, bare bygget til hvert styresystem.

Det har fem faneblade. »Restore« opregner de sikkerhedskopier, du har, »Create Backup« laver en ny, »Schedule« styrer tidspunktet, »Settings« viser stierne og »Log« protokollen.

Indstillingerne er allerede udfyldt. Ved sin første start finder programmet selv ud af, hvor ticketsystemet bor.

Mappen til sikkerhedskopierne står under »Backup directory«. Du kan ændre den, for eksempel til et andet drev.

Fanebladet »Restore« med to sikkerhedskopier, hver med tidspunkt, størrelse og type.
Den røde ramme sidder på listen. Kolonnen »Type« siger, om en sikkerhedskopi kom fra planen eller blev lavet i hånden.Åbn billedet i fuld størrelse
Fanebladet »Settings« med mappen, databasen og de tre volumener.
Den røde ramme sidder på databasens navn. Nedenunder står de volumener, der bliver gemt sammen med den.Åbn billedet i fuld størrelse
2

Planen kører fra det øjeblik, du installerer

Før du går i gang: På Windows kræver det administratorrettigheder at registrere en plan. Uden dem opretter programmet en opgave, der kun kører, mens nogen er logget ind, og det siger det til dig.

Installationen sætter selv den daglige sikkerhedskopi op. Den kører klokken 23:00 efter serverens ur.

Planen bor i styresystemet. På Windows er det Opgavestyring, på Linux cron-tjenesten. Så der kører ingen ekstra tjeneste bare til sikkerhedskopier.

Sikkerhedskopien kræver ikke, at nogen er logget ind. På en server, hvor ingen nogensinde logger på, kører den alligevel.

Linjen under knapperne fortæller dig, om opgaven virkelig findes i styresystemet. Et sat flueben siger kun, hvad der blev gemt.

Sikkerhedskopier bliver holdt i fem lag: 14 dage, 4 uger, 12 måneder, 4 kvartaler og 5 år. En sikkerhedskopi bliver stående, så længe den er den nyeste i sin periode i et af de lag.

Det, der tæller, er kalenderdage, ikke filer. To sikkerhedskopier på én dag er én dag.

Sikkerhedskopier, du laver i hånden, bliver aldrig slettet automatisk. Det er, hvad 0 ved »Keep manual« betyder.

Ændrer du planen, overlever din ændring en opdatering. Installationen sætter den kun, når der ikke er nogen endnu.

Fanebladet »Schedule« med »Daily« afkrydset og tidspunktet sat til 23:00.
De røde rammer sidder på »Daily« og på tidspunktet. Sætningen ovenover nævner begge veje: Opgavestyring og cron.Åbn billedet i fuld størrelse
Linjen »Registered with the operating system: yes (Daily)« under knapperne.
Denne linje bliver kontrolleret igen ved hver start. Står der »NO«, kører der intet af sig selv — brug så »Apply schedule« som administrator.Åbn billedet i fuld størrelse
De seks opbevaringsfelter: 14, 4, 12, 4, 5 og 0.
Den røde ramme sidder på lagene. »Keep manual (0 = keep all)« betyder, at sikkerhedskopier lavet i hånden bliver bevaret.Åbn billedet i fuld størrelse
3

Hvad en sikkerhedskopi indeholder

En sikkerhedskopi indeholder alt det, der udgør jeres systems tilstand. Det er databasen, de vedhæftede filer, arkivet og nøglerne.

Nøglerne er den del, det er let at overse. De dekrypterer gemte adgangsoplysninger, for eksempel dem til jeres mailkonto. Uden dem ville en gendannelse komme tilbage med døde adgangsoplysninger.

Hver sikkerhedskopi er én enkelt ZIP-fil. Den rummer databasen som en tekstfil, én fil per volumen og en liste over tjeksummer.

Systemet kører videre imens. Jeres agenter opdager slet ikke en sikkerhedskopi.

»Estimate size« fortæller dig på forhånd, hvor stor databasen er. Den færdige fil er mindre, fordi den bliver komprimeret.

Der bliver aldrig overskrevet noget. Hver sikkerhedskopi er sin egen fil, og kun oprydningen fjerner gamle.

Fanebladet »Create Backup« med knapperne »Estimate size« og »Create backup now«.
Den røde ramme sidder på begge knapper. Sætningen ovenover opregner, hvad der er med.Åbn billedet i fuld størrelse
Beskeden nederst med den fulde sti til den fil, der blev lavet.
Når den er lavet, dukker filnavnet op nederst i vinduet. Tidspunktet er en del af navnet.Åbn billedet i fuld størrelse
4

At få alt tilbage

Før du går i gang: En gendannelse overskriver dagens tilstand. Alt, der er oprettet siden den valgte sikkerhedskopi, er væk bagefter.

På fanebladet »Restore« vælger du den sikkerhedskopi, du vil have tilbage. Så klikker du på »Restore«.

Programmet spørger først. Det siger, hvad der kommer til at ske: dagens tilstand bliver overskrevet, og programmet genstarter containerne.

Fluebenet »Wipe target volumes before restore« tømmer volumenerne først. På den måde bliver der ingen fil tilbage, som ikke fandtes, da sikkerhedskopien blev lavet.

Skridtene dukker op på fanebladet »Log«. Der ser du ét ad gangen, hvad programmet gjorde.

Hele tilstanden kommer tilbage. Sager, kommentarer, historik, vedhæftede filer, registreret tid og vidensbasen er der alle igen, som de var på sikkerhedskopiens tidspunkt.

Derefter kan systemet bruges igen. På en lille installation tager det under et minut.

En valgt sikkerhedskopi i listen, med fluebenet og knappen »Restore« nedenunder.
De røde rammer sidder på fluebenet og på »Restore«. Uden en valgt række bliver knappen slået fra.Åbn billedet i fuld størrelse
Bekræftelsen før gendannelsen med knapperne »Yes« og »No«.
Spørgsmålet nævner begge følger: dagens tilstand bliver overskrevet, og containerne bliver genstartet.Åbn billedet i fuld størrelse
Protokollen efter gendannelsen, med beskeden »Restore complete.« nederst.
Hvert skridt står der med sit tidspunkt. Til sidst melder programmet »Restore complete.«Åbn billedet i fuld størrelse
5

På en server uden skrivebord

En server har tit intet skrivebord. Derfor virker det samme program også som en kommando.

Fem kommandoer er, hvad du skal bruge: »backup« gemmer, »list« viser de sikkerhedskopier, du har, »restore« henter en tilbage, »schedule« sætter tidspunktet og »config« viser indstillingerne.

Bag dem ligger det samme program som i vinduet. Der findes ingen anden vej, der gør noget andet.

Programmet ligger i »/opt/smitey/Backup«. Du kalder det med »sudo« og tilføjer kommandoen. Containerne kører som »root«, så sikkerhedskopien har også brug for de rettigheder.

Du kan kopiere de fire kasser nedenunder. De dækker det, der virkelig er brug for i hverdagen.

En gendannelse spørger også her. Den kører først, når du tilføjer »--yes«.

Der ligger en fil på serveren til at læse op på det hele. Den hedder »BACKUP-RESTORE.txt« og ligger i »/opt/smitey«. Den går planen, hver kommando og vejen tilbage igennem en gang til, i dit eget tempo. Den kommer på det sprog, du valgte under installationen. De andre sprog ligger under »/opt/smitey/docs«.

Vis de sikkerhedskopier, du har

sudo /opt/smitey/Backup/TicketSystemBackup list

Hver linje bærer tidspunktet, grunden, størrelsen og filnavnet. Det er den samme liste som i vinduet.

Vis planen

sudo /opt/smitey/Backup/TicketSystemBackup schedule --show

Den første linje nævner det tidspunkt, der er sat. Den sidste siger, om opgaven virkelig findes i styresystemet. Står der »NO«, kører der intet af sig selv.

Ændr planen

sudo /opt/smitey/Backup/TicketSystemBackup schedule --daily 23:00 --keep 14

Tidspunktet er serverens egen tid. »--keep« siger, hvor mange daglige sikkerhedskopier der bliver bevaret. »schedule --off« slår den daglige sikkerhedskopi fra.

Lav en sikkerhedskopi lige nu

sudo /opt/smitey/Backup/TicketSystemBackup backup

Denne sikkerhedskopi tæller som »Manual«. Sikkerhedskopier lavet i hånden bliver aldrig slettet automatisk.

En kommandolinje på en Linux-server med kørslen af »backup« og listen fra »list« nedenunder.
Øverst kører »backup« igennem: gem databasen, gem de tre volumener, komprimér. Nedenunder viser »list« den færdige fil på førstepladsen. Linjerne med pilen er de kald, programmet foretager af sig selv.Åbn billedet i fuld størrelse
6

Sikkerhedskopierne ligger på den samme maskine

Før du går i gang: En sikkerhedskopi ved siden af systemet beskytter dig ikke mod et diskhavari. Kopiér filerne til et andet sted med jævne mellemrum.

Sikkerhedskopierne er filer i den mappe, du har sat. Den mappe ligger på den samme maskine som ticketsystemet.

Til de almindelige tilfælde virker det godt. Data slettet ved en fejl, en opdatering der gik galt eller en fejl i dataene er alle dækket.

Det hjælper ikke, hvis disken går ned. Er disken væk, er sikkerhedskopierne væk med den.

Så kopiér filerne et andet sted hen. Et netværksdrev, en anden server eller lager i netværket er nok.

En kopieret fil kan lægges tilbage hvor som helst. Med »Import backup file…« henter du den ind i listen igen.

Fanebladet »Settings« med feltet »Backup directory«.
Feltet »Backup directory« siger, hvor filerne ligger. Det er den mappe, du bør kopiere et andet sted hen med jævne mellemrum.Åbn billedet i fuld størrelse
7

Før hver opdatering gemmer systemet af sig selv

En opdatering tager sin egen sikkerhedskopi først. Det sker uafhængigt af din plan og uden at du sætter flueben nogen steder.

Den gemmer det samme som altid: databasen, de vedhæftede filer, arkivet og nøglerne.

Denne sikkerhedskopi hører til opdateringen. Den ligger i sin egen mappe ved siden af systemet og dukker derfor ikke op i programmets liste.

Bemærkningen før opdateringen siger det til dig. Du behøver ikke selv at huske at gemme først.

Mere om det på kortet: Opdatering med et tryk på knappen

Bekræftelsen før opdateringen med bemærkningen om sikkerhedskopien.
Sætningen »A full backup is taken automatically beforehand« er en del af spørgsmålet. Sikkerhedskopien kører, før der bliver skiftet noget ud.Åbn billedet i fuld størrelse

Vigtige kommandoer (Linux)

Klar til at kopiere. Alt med sudo – installationsprogram og containere kræver root.

Installer forudsætningen

sudo apt install -y unzip

Uden unzip kan installationsprogrammet ikke pakke pakken ud.

Installer ticketsystemet

curl -fsSL https://files.smitey.eu/download/get-smitey.sh | sudo bash

Henter pakken og fører dig gennem spørgsmålene. Det er ufarligt at køre den igen: opsætning og data bliver bevaret.

Kontrollér HTTPS

sudo /opt/smitey/smitey-install check-https

Kun med et offentligt domæne. Fortæller dig, om certifikatet er der – og hvis ikke, grunden fra loggen. Certifikatet kan stadig komme minutter efter installationen.

Slå det første login op

sudo cat /opt/smitey/SMITEY-credentials.txt

Efter det første login: skift adgangskoden, og slet filen.

Kører containerne?

sudo podman ps

Viser hver del af systemet med sin tilstand.

Følg loggen

sudo podman logs -f container-backend-1

Viser live, hvad backenden melder. Stop med Ctrl+C.

Kontrollér supervisoren

systemctl status smitey-supervisor

Denne tjeneste holder systemet kørende og lægger de opdateringer på, du udløser inde i programmet.

Lav en supportpakke

sudo /opt/smitey/install.sh --support-bundle

Samler logge og systemtilstand i én zip-fil. Adgangskoder og nøgler bliver fjernet.

Ændr den offentlige adresse

sudo /opt/smitey/install.sh --reconfigure

Sætter et nyt domæne og genstarter, så certifikatet bliver bestilt til det nye navn.

Fjern det

sudo /opt/smitey/install.sh --uninstall

Spørger om data og om Podman hver for sig – der bliver ikke slettet noget uden at spørge.

Sikkerhedskopier klarer /opt/smitey/Backup/TicketSystemBackup (list, backup, restore); den daglige sikkerhedskopi kører af sig selv. Detaljerne står i /opt/smitey/docs/en/BACKUP-RESTORE.txt.

Tilbage til sammenligningen af funktionerBillederne er taget fra version 0.46.0.