Veiledning

Dere oppretter en ny sak med «New Ticket» i bjelken til venstre. Skjemaet heter «Create new ticket». Som agent registrerer dere også andres henvendelser med det — det er det feltet «User» er til: det sier hvem saken er for, ikke hvem som taster den inn.

Alt med en stjerne er påkrevd: «Title», «User», «Main category» og «Description». Én til som er lett å overse: skjemaet lagrer ikke uten en underkategori, selv om «Subcategory» ikke bærer noen stjerne — en hoved- og en underkategori hører sammen og blir alltid satt parvis.

Hvilke felter som er påkrevde, settes under «Settings → Ticket Settings». Kortet «Admin / Agent Field Settings» har bare bryteren «Field is mandatory» til dette. Kortet «Customer Field Settings» har i tillegg «Is hidden for Customer» og «Is not editable». Derfor kan en kunde se et kortere skjema enn dere, uten at noen må vedlikeholde to skjemaer. «Title» og «Description» er alltid påkrevde. Det kan ikke slås av.

Etterpå kan dere endre nesten alt: til høyre for saken sitter kortet «Details» med innmelder, telefon, e-post, lokasjon, kategori og referansenummer; dere endrer selve feltet og bekrefter med «Save» nedenfor. Status, tildeling, prioritet, kanal og observatører sitter ett kort høyere opp under «Actions». Status og tildeling trer i kraft med én gang. Prioritet, kanal og observatører blir først lagret med «Save» i kortet «Details».

Bare agenter og administratorer kan endre dette. Innmelderen kan lese saken, kommentere på den og legge ved filer — men ikke endre den klassifiseringen rapporteringen deres er bygget på.

En sidevirkning det er verdt å kjenne én gang: retter dere i en sak som ennå ikke tilhører noen, tilhører den dere etterpå. Systemet skriver dere inn som agent og flytter statusen fra «Open» til «Assigned» — begge deler havner i historikken. Ville dere ikke det, tildel den til en annen etterpå.

Hver eneste av disse endringene havner i historikken til saken, med navn, tidspunkt, gammel verdi og ny verdi. Dere trenger ikke å slå på noe for det.

Så er det spørsmålet om hvordan man blir kvitt saker igjen. Under «Settings → Archive» velger dere en periode, ser med «Preview» hvor mange lukkede saker den inneholder, og oppretter ei ZIP-fil med «Create archive»: saker, kommentarer, historikk, egendefinerte felter og vedlegg, alt sammen i ei fil. Opprettelsen fjerner ingenting. Sakene forlater først den kjørende databasen med det separate trinnet «Delete from live DB» i lista «Existing archives» — og de kan gjenopprettes fra nettopp den fila.

Beskrivelsen og kommentarene er ikke nakne tekstfelter. Hver har ei verktøylinje ovenfor, og knappene sier hva de gjør når dere peker på dem: «Bold», «Italic», «Underline», «Strikethrough», «Text color», «Highlight color», «Bullet list», «Numbered list», «Quote», «Link» og «Clear formatting».

Slik lages ei lenke: merk teksten, klikk på «Link», tast adressen inn i den lille dialogen. Ei tom inntasting fjerner lenka igjen. Nett- og e-postadresser er tillatt (http, https, mailto) — alt annet blir kastet ved lagringen, slik at en kommentar ikke kan liste noe forbi noen.

Bilder kommer inn gjennom utklippstavla: ta et skjermbilde, og lim det rett inn i redigeringsfeltet med Ctrl+V. Til å begynne med viser teksten bare en markør som «[inline-image:1]». Når dere lagrer, laster systemet opp bildet og viser det nøyaktig der — og det havner også på fana «Attachments», der alle filene til saken bor. Innliming av bilder virker i beskrivelsen av en eksisterende sak og i en ny kommentar. Det virker ikke i skjemaet «Create new ticket» og heller ikke mens dere redigerer en kommentar.

Det dere ser, er det de andre ser: formatering, lister og lenker blir bevart i saken, og også i e-posten til innmelderen. Fremmed oppmerking — fra en kopiert nettside eller en innkommende e-post for eksempel — blir skåret tilbake til dette tillatte settet. Ingenting av teksten deres går tapt underveis, bare innpakningen.

En kommentar kan merkes som intern med «Internal note (not visible to the customer)». Den bærer da merkingen «Internal» og er usynlig for innmelderen — heller ikke søket får den fram.

Alle kan endre og slette sine egne kommentarer. Det en kunde har skrevet, kan bare den kunden eller en administrator endre eller slette. Det gjelder også e-postene hennes. Kommentarer fra kolleger kan endres og slettes av hver agent som kan arbeide på saken. Det gjelder også et team som hadde saken tidligere.

Filer hører til saken, ikke til en enkelt kommentar. På saken fører fana «Attachments» til lista: «Upload file» legger til ei, hver rad nevner fila, størrelsen og datoen. Alle som er med i saken, kan legge ved noe — også innmelderen, så ingen trenger å sende dere skjermbildet sitt på e-post. En kunde kan bare slette vedlegg hun selv har lastet opp. Når en undersak blir lukket, blir vedleggene dens kopiert til oversaken, der de bærer merkingen «Internal». Agenter ser dem; kunder verken ser eller laster ned dem.

Et klikk på navnet åpner forhåndsvisningen, uten at dere må laste ned fila. Bilder kan dere zoome inn på, zoome ut fra og dreie der inne — nyttig ved et display som er fotografert skjevt. En PDF blir vist i det samme vinduet, med sideoversikt, zoom og utskrift. Tekstfiler blir vist som tekst. Med «Open in new tab» åpner dere fila i sitt eget vindu.

Et vedlegg hører til saken og følger med den: det står i historikken («File uploaded: …»), overlever en overføring til et annet team og havner inne i arkivfila når saken blir arkivert.

Fana «History» på saken svarer på spørsmålet bak enhver oppfølging: hvem endret hva, og når? Hver rad nevner personen, feltet, den gamle verdien overstreket, den nye etterpå og tidspunktet ned til sekundet. Den nyeste posten står øverst.

Poster blir skrevet uten at dere gjør noe — ved statusbytter, prioritet, tildeling, kategori, lokasjon, observatører, tittel og beskrivelse, og ved opprettelsen («Ticket opened»), ved hver kommentar og ved hver opplastet fil. Tallet på fana forteller dere på forhånd hvor mye bevegelse det var i saken.

Historikken kan ikke redigeres og ikke slås av. Det er nettopp det som gjør den nyttig: det er grunnen til at en sak ikke kan slettes enkeltvis, og den følger med inn i arkivfila når saken blir arkivert.

For en kommentar noterer historikken bare at den er lagt til, redigert eller slettet. Ordlyden bor på fana «Comments». En intern kommentar dukker også opp i historikken, men bare for agenter og administratorer.

Statusen sier hvor en sak står akkurat nå. Tolv statuser følger med systemet — Open, Assigned, In Progress, Waiting for User Response, Resolved, Closed og flere. Dere finner dem under «Settings → General Settings» i avsnittet «Drop-down lists» bak fana «Status»; «+ Add status» oppretter en av deres egne, «Edit status» åpner en eksisterende.

Det viktige er forskjellen på navnet og betydningen. I redigeringen av en status, under «Meaning of this status», er det tre brytere: «Counts as resolved», «Counts as closed» og «Waiting for the requester». Bare disse bryterne forteller systemet hvordan en status skal behandles.

Dere kan gi hver status nytt navn, også dem som følger med systemet: nederst i redigeringen, under «Translations», er det et «Name»-felt per språk — skriv det inn der som folka deres skal lese. Det tekniske navnet bak blir ikke rørt, og nettopp derfor går ingenting i stykker: automatisering, rapportering og bryterne ovenfor henger på det navnet, ikke på etiketten deres. Så «Resolved» kan bli til «Done».

Å slette virker derimot ikke for dem alle. Åtte statuser bærer merkingen «Mandatory» i lista — Open, Assigned, In Progress, Resolved, Closed, Reopened, Waiting for approval og Rejected. De kan få nye navn og flyttes i rekkefølgen, men ikke fjernes; forsøker man det, ender det med en tydelig beskjed. Det er ikke der for å plage dere: det henger prosesser på dem som ellers ville stoppet uten et ord — for eksempel den automatiske lukkingen, som trenger en «løst»-status som utgangspunkt.

To statuser hører til systemet selv: «Waiting for approval» og «Rejected» bærer merkingen «System only». De kommer ut av en godkjenningsprosess, og ingen skal kunne påstå for hånd at noe ble avvist som aldri var oppe til beslutning.

Hva de tre gjør: en status som teller som løst, lukker saken av seg selv etter 24 timer. En status som teller som lukket, er den endelige tilstanden saken blir flyttet inn i. Og «Waiting for the requester» betyr nøyaktig det: vi venter på innmelderen — ikke på et annet team og ikke på en leverandør. Det er den markeringen SLA-klokka stopper på, hvis dere setter det opp slik.

Nedenfor sitter «Allowed transitions to new status». Her krysser dere av hvilke statuser som kan nås fra denne. La alt stå tomt, og ingenting er begrenset; kryss av noe, og hver annen vei er stengt. Slik bygger dere et forløp som ikke kan hoppes over — for eksempel: fra «Open» kan man bare komme til «In Progress» eller «Assigned», men ikke rett til «Closed».

De øvrige bryterne i redigeringen er små ting med stor virkning: fargen til lista, «Sort order» til rekkefølgen, «Show status in new ticket form» (skal denne statusen i det hele tatt kunne velges når man oppretter en sak?), «Requires comment in dialog» (tving fram en begrunnelse) og «System only» til statuser bare systemet selv kan sette.

Opptil fire statuser vises på saken som knapper under «Change Status to:». Dere velger dem i redigeringen med bryteren «Set as primary status (max. 4)». I fabrikkinnstillingen er det In Progress, Waiting for User Response, Waiting for Service Provider Response og Resolved. Alle andre statuser ligger under «More statuses».

Alt som dukker opp som ei nedtrekksliste i en sak, tilhører dere. Under «Settings → General Settings» sitter kortet «Drop-down lists» med seks faner: «Department», «Position», «Location», «Role», «Status» og «Priority». Håndteringen er forskjellig fra liste til liste.

Én om gangen: tast det engelske navnet inn i det tomme feltet, og klikk på knappen ved siden av — den er oppkalt etter lista, altså «+ Add location», «+ Add department» og så videre. Radene nedenfor er de eksisterende postene. I «Department», «Position» og «Location» er det der dere endrer et navn og bekrefter med den «Save» som står ved siden av.

Til mange poster på én gang tilbyr «Department», «Position» og «Location» også «Export JSON» og «Import JSON». På et ferskt installert system laster dere ned den tomme strukturen med «Export JSON», fyller den ut og importerer den igjen. Det er ikke en måte å gi nytt navn på — det sier kortet selv.

Noen poster bærer merkingen «Mandatory». De tre rollene «Admin», «Agent» og «Customer» er blant dem, åtte av statusene som følger med systemet, og én plassholder i hver av listene Location, Position og Department («None selected or available»). Ingen av dem kan slettes: det henger rettigheter og prosesser på dem som ellers ville stoppet uten et ord. Statusene kan likevel få nye navn i sin egen editor. Rollene og plassholderne kan ikke få nye navn. Hva som er tillatt, avhenger av lista. «Role» er låst: en rolle kan verken legges til eller få nytt navn. I «Priority» legger dere til og sletter poster, men det finnes ingen fil og ingen navneendring. «Status» har sin egen editor og heller ingen fil.

Dere oversetter ikke til de andre språkene her, men i én omgang på oversettelsessiden. Det engelske navnet holder her — det er ankeret oversettelsene senere henger på.

Statusen er den eneste posten med sin egen redigering, fordi det henger mer på den enn et navn; den har sitt eget kort lenger ned.

Kategorier er det innmelderen eller agenten velger når en sak blir opprettet — og det dere senere grupperer rapportene deres etter. Hvert team har sine egne: en helpdesk sorterer etter andre ting enn en nettverksavdeling, og ingen av dem ser listene til det andre teamet.

Dere finner dem under «Settings» som posten «<teamnavn> Categories». I eksemplet heter teamet «Helpdesk», så posten heter «Helpdesk Categories».

Siden har tre kort: «Main categories», «Subcategories» og «Links». Den raskeste starten: tast det engelske navnet inn i feltet «EN (required)», og klikk på «+ New main category» eller «+ New subcategory». Alt annet oversetter dere senere i én omgang på oversettelsessiden — det er ingenting å forberede til det her.

Har dere mange kategorier foran dere, ta veien gjennom fila: «Export JSON» laster ned strukturen — på et ferskt installert system er fila tom og viser dere bare oppbygningen. Dere fyller den ut (for hånd eller med hjelp fra en AI), lagrer den og laster den opp igjen via «Import JSON». Det er ikke en måte å gi nytt navn på: et navn endrer dere i feltet til den kategorien og bekrefter med den «Save» som står ved siden av — det sier siden også selv.

Det tredje kortet, «Links», er der det egentlige arbeidet skjer. Velg en hovedkategori øverst, kryss av underkategoriene som hører til den, nedenfor, og lagre med «Save links». Knepet: én underkategori kan henge på flere hovedkategorier. Så dere trenger bare «Malfunction» én gang og gjenbruker den til Printer, Network, Meeting-Room og Notebook.

Fra da av er kategoriene tilgjengelige i saken. Å slette kan mislykkes så lenge det fortsatt er saker som bruker en kategori — det er med vilje, ellers ville gamle saker mistet klassifiseringen sin. Fjerner dere en kobling, kan saker som bruker det paret, fortsatt lagres. Bare en nyvalgt kategori blir kontrollert mot koblingene.

Gir dere en sak videre til et annet team, blir klassifiseringen dens stående — også når det nye teamet ikke har de kategoriene i det hele tatt. Den står da i feltet sammen med opprinnelsen sin, for eksempel «Meeting-Room · from Helpdesk», og er gråtonet: det nye teamet kan se hva saken hittil kjørte som, men kan ikke selv tildele den posten. For å sortere den om velger dere fra deres egen liste — og systemet vil da ha en hoved- og en underkategori sammen.

Hver sak bærer en kanal. Den står i skjemaet og senere på kortet «Actions» under «How the request came in», og den svarer på et spørsmål som raskt blir viktig i rapporteringen: kommer arbeidet inn gjennom portalen eller over telefonen?

Dere kan bare velge det et menneske vet, og systemet ikke vet: «Phone» og «Entered by an agent». De to andre verdiene setter systemet selv — «Self-service» når innmelderen opprettet saken i portalen, og «E-mail» når den vokste ut av en innkommende e-post. Når en agent oppretter en sak, starter skjemaet med «Entered by an agent».

En kanal som systemet har satt, kan ingen endre etterpå. Feltet sier da «Recorded by the system. It cannot be changed.» Ellers ville feltet mistet nøyaktig den opplysningen det finnes for. Den andre veien rundt kan dere fortsatt endre alt annet på en sak som er registrert over telefonen.

Bare en agent eller en administrator kan sette kanalen. For innmelderen ville det vært en uttalelse om hennes egen sak — og rapporteringen ville vært avhengig av at alle er ærlige.

«E-mail» krever ei tilkoblet postkasse, og den er en del av Professional-utgaven. De tre andre kanalene finnes i begge utgaver.

Over hver saksliste er feltet «Search tickets…». Det søker ikke bare i titler, men i hele saken: tittel, beskrivelse, navnet til innmelderen, e-postadresse og telefonnummer, lokasjon, referansesaksnummer, alle kommentarer og tekstverdiene i deres egne egendefinerte felter.

Eksemplet viser det: «coffee» står i ingen tittel, bare i beskrivelsen på én sak — og den blir likevel funnet. Så dere trenger ikke å huske hva en sak ble kalt; ett ord fra saken holder.

Store og små bokstaver spiller ingen rolle. Søket gjelder alltid lista dere står i akkurat nå, og kan kombineres med «Filter» ved siden av; «Reset» tømmer søk og filtre igjen. Lista husker filtrene deres, hver teamliste for seg. De er der fortsatt når dere kommer tilbake fra en sak, laster siden på nytt eller logger inn på en annen datamaskin. Søketeksten huskes ikke. For kunder er det en grense dere ikke kan se, men bør kjenne: de søker ikke i interne kommentarer — ellers kunne de av resultatlista sluttet seg til hva som ble drøftet internt. De søker heller ikke i egendefinerte felter som er skjult for kunder.

Alle setter sammen sin egen saksliste. Til det sitter knappen «Columns» ved siden av «Filter». Den åpner dialogen «Choose columns».

I dialogen krysser dere av hver kolonne dere vil se. Pilene ved siden av bestemmer rekkefølgen. «#» og «Title» er alltid med. Bredden på en kolonne endrer dere i selve lista ved å dra i kanten av overskriften.

«Save» lagrer valget på brukerkontoen. Derfor gjelder det på hver datamaskin og blir stående når dere logger av. «Default columns» setter lista tilbake til fabrikkinnstillingen.

Når det ikke er plass til alle kolonnene, faller de lengst til høyre bort først. «#», «Title» og «Status» blir alltid stående. Så dere flytter det som betyr mest for dere, fram.

Med Professional blir de egendefinerte feltene deres også tilbudt. De står i dialogen under sitt eget navn, her for eksempel «Asset tag».

Kunder kan sette opp lista si på samme måte, men får tilbudt færre kolonner. «Team», «Created by», «Last activity», «Status changed at», «Deadline», «Follow-up» og «Time» er ikke tilgjengelige for dem. Felter dere har skjult for kunder, vises heller ikke som kolonne.

På en smarttelefon vises ikke knappen. Der viser lista de kolonnene som får plass.

Saken tilbyr to knapper ved siden av hverandre til det, og forskjellen står med liten skrift nedenfor. «Involve another team»: dere er fortsatt ansvarlige, det andre teamet arbeider ved siden av dere i en tilknyttet sak. «Escalate to another team»: det andre teamet overtar.

Når dere gir videre, flytter ansvaret uten at det oppstår en sak nummer to. Teamet deres beholder lesetilgang og kan fortsatt kommentere, men kan ikke lenger endre noe — og nettopp det forteller dialogen dere før dere bekrefter. Der velger dere mottakerteamet og kan legge til en begrunnelse.

Når dere trekker inn et team, blir saken deres i hendene deres og får en undersak i det andre teamet. Deres flytter til statusen «Waiting for other team»; når det andre teamet lukker sin, kommer deres tilbake som «Back from other team». Så dere trenger ikke å spørre om det har skjedd noe der borte. Vedleggene fra undersaken blir kopiert til saken deres med merkingen «Internal», og kunden ser dem ikke.

Når det gjelder klassifiseringen: kategoriene til teamet som gir fra seg saken, blir stående på den, også når det nye teamet ikke har dem i det hele tatt — de dukker opp der med opprinnelsen sin, gråtonet. På den måten kan det nye teamet se hva saken hittil kjørte som, og sortere den om til sin egen liste hvis det trengs.

Bare den som er ansvarlig akkurat nå, kan gi en sak videre. En tidligere stasjon ser fortsatt saken, men kan ikke sende den videre en gang til. Den kan kommentere, men den kan ikke ta saken tilbake til seg selv.

I lista til teamet deres viser saken deretter «Waiting for other team» så lenge det andre teamet arbeider med den. Krysset ved «Also show tickets this team handed over» er satt som fabrikkinnstilling, og hver brukers eget valg blir lagret. For det andre teamet starter saken som «Open».

Den som gir saken videre, blir observatør på den. Dialogen sier det før dere bekrefter. Som observatør får dere en e-post når statusen endres, saken lukkes eller noen kommenterer. Som enhver observatør fjerner dere dere selv med «Stop observing».

Når en opplysning mangler i sakene deres — utstyrsnummeret, slutten på garantien, kostnadsstedet — legger dere den til selv. Under «Settings → Ticket Settings» sitter nederst kortet «Custom fields»; knappen heter «Add custom field».

I dialogen gir dere et navn og en felttype: «Text», «Multiline text», «Integer», «Decimal», «Date» eller «Yes / No». Typen bestemmer hva som kan tastes inn — et datofelt tar ikke imot «neste uke», og nettopp derfor kan dere rapportere på det senere.

Under «Scope» bestemmer dere hvor feltet gjelder: «All teams (including new ones)» eller «Selected teams only». Det første valget dekker også team som ennå ikke finnes — den slags forskjell man først oppdager et halvt år senere.

De tre bryterne under «Defaults» er «Mandatory by default», «Hidden for customer by default» og «Not editable by customer by default». De gjelder bare for et felt så lenge det ikke er lagret noe for det feltet i feltinnstillingene på den samme siden. Så snart dere setter det der, bestemmer feltinnstillingene.

På saken sitter de egendefinerte feltene på sitt eget kort, «Additional information», mellom beskrivelsen og kommentarene. Uten en mal viser skjemaet alle de egendefinerte feltene til teamet. Velger dere en mal når dere oppretter en sak, viser den nøyaktig de feltene malen nevner, i rekkefølgen sin — «bare de feltene denne saken trenger».

En mal kan i tillegg gjøre et felt påkrevd. Det administratoren har skjult for kunder, forblir skjult, også når en mal fører det opp. Et påkrevd felt som en mal ikke fører opp, blir ikke etterspurt, så det kravet gjelder ikke for saker som blir opprettet med denne malen.

Hvor mange egendefinerte felter et team kan ha, blir satt under «Settings → General Settings» i kortet «Custom fields limit». Dere blir kvitt et felt med «Deactivate»: det forsvinner fra skjemaet, men verdiene til det blir stående på de gamle sakene — bryteren «Show deactivated» henter det tilbake i lista.

Noen ganger skal noen følge en sak uten å arbeide på den: teamlederen i en delikat sak, kollegaen som overtar neste uke. Det er det observatører er til. På saken sitter feltet «Observers» på kortet «Actions», knappen heter «Add observer»; skjemaet «Create new ticket» har det samme feltet. På saken blir en endring der lagret med «Save» i kortet «Details».

Bare agenter og administratorer fra teamet saken hører til, kan velges. En kunde kan ikke være observatør — hun ville ellers fått e-post om internt arbeid.

En observatør får en e-post når det skjer noe på saken: en ny kommentar, en endret status, en ny tildeling, endrede felter. Den blir ikke sendt med én gang, men samlet: etter den siste endringen venter systemet et minutt og sender så ÉN e-post som dekker alt som skjedde i den tida. Så det å arbeide en sak gjennom i én strekk utløser ikke sju e-poster. Kommer det flere kommentarer i den tida, står alle i e-posten.

Hvem som observerer, er en del av historikken: en endring blir notert som enhver annen, med den gamle og den nye tilstanden.

Å taste inn observatører er en del av Basic. E-posten til observatører er en del av Professional, fordi den trenger utgående post. Uten det kan dere taste inn observatører, men det går ingenting ut. En observatør kan fjerne seg selv med knappen «Stop observing». Det krever ingen rett til å endre saken.

En observatør blir også lagt til automatisk: den som gir en sak videre med «Escalate to another team», blir observatør. Slik får vedkommende vite hva det andre teamet gjør med den.

Når to personer arbeider i samme sak samtidig, kan den senere lagringen overskrive den tidligere, og ingen ville merke det. Derfor viser saken hvem andre som har den åpen. I tillegg avviser den en lagring som bygger på en utdatert tilstand.

Meldingen står øverst i saken. «Marco Rossi is viewing this ticket» betyr at Marco har saken åpen. «Marco Rossi is actively editing this ticket» betyr at Marco har ulagrede inntastinger i den. Det kan være et påbegynt svar, en kommentar som holder på å bli endret, tittelen eller beskrivelsen i redigeringsmodus, en påminnelse, et egendefinert felt eller en tidsoppføring. Endrede felter på kortene «Actions» og «Details» teller også, så lenge de ikke er lagret med «Save». Et åpent vindu i saken teller også. Det er vinduene «Involve another team?», «Escalate to another team?», «Close ticket», «Resolve incident» og «Start a workflow», pluss vinduet for kommentaren ved et statusskifte. Etter to minutter uten inntasting viser meldingen «viewing» igjen, også om utkastet fortsatt står der.

Har flere kolleger saken åpen, samler meldingen dem, for eksempel «Marco Rossi and 2 more are viewing this ticket». Pek på meldingen for å se alle navnene. Så snart noen redigerer aktivt, teller linjen bare de som redigerer. Ingen ser seg selv i meldingen. Har dere saken åpen i to faner, telles dere én gang. Er saken bare åpen i en skjult fane, forsvinner dere fra de andres melding etter omtrent ett minutt.

Når en kollega lagrer en endring, står det «Marco Rossi changed this ticket», med knappen «Refresh» ved siden av. En ny kommentar fra noen andre viser «Marco Rossi added a comment». Kom endringen ikke fra en person, for eksempel fra en automatiseringsregel eller en innkommende e-post, står det «This ticket was changed». Meldingen blir stående til dere laster inn på nytt.

«Refresh» laster inn den aktuelle tilstanden til saken, for eksempel status, tildeling, felter og historikk. Hele siden lastes ikke inn på nytt. Ulagrede inntastinger blir værende. Et påbegynt svar blir stående i svarfeltet, og en åpen tittel eller beskrivelse beholder teksten. Har den lagrede teksten endret seg i mellomtida, vises «The saved text has changed in the meantime.» under feltet. Lagrer dere da, erstatter teksten deres den lagrede. Knappen «Refresh» øverst i saken gjør det samme.

Lagrer dere likevel på en utdatert tilstand, blir lagringen avvist. Vinduet «Ticket changed in the meantime» åpnes. Har en person gjort endringen, nevner vinduet navnet. Endringen er ikke lagret. Klikk på «Refresh», sjekk endringen mot den aktuelle tilstanden og lagre på nytt. Det gjelder enhver endring av selve saken, for eksempel status, tildeling, prioritet, kortet «Details» og egendefinerte felter.

Kommentarer blir aldri avvist. To svar overskriver ikke hverandre. Begge havner i saken. Det samme gjelder vedlegg og tidsoppføringer. Heller ikke massehandlinger på sakslista og automatiseringsregler blir kontrollert mot tilstanden. De endrer saken direkte. Den som har den åpen, ser meldingen etterpå.

Kundene ser ingenting av dette. De vises ikke i meldingen. De ser heller ikke hvem som arbeider med saken deres.

Hvem som har en sak åpen, finnes bare i arbeidsminnet til serveren. Omtrent ett minutt etter at personen har forlatt saken, er oppføringen borte. Ingenting av dette skrives til en logg. Saken lagrer hvem som endret den sist. Den opplysningen er en del av dataeksporten for den personen. Når personen blir anonymisert, blir den fjernet.

E-postkanalen er én vei med to retninger, og de hører sammen: en innkommende e-post blir til en sak, svaret deres går ut som e-post, og svaret fra innmelderen havner som kommentar på den samme saken — ikke på en nummer to.

Sammenkoblingen skjer ikke på følelsen: et svar havner bare på den eksisterende saken når e-posten bærer henvisningen til saken i emnefeltet eller har svarhodene fra e-postprogrammet med seg. En e-post med ingen av delene starter en ny sak — heller én sak for mye enn to saker som ikke har noe med hverandre å gjøre, slått sammen bare fordi emnet tilfeldigvis passet.

Alt til det sitter under «Settings → E-Mail Settings». Det øverste kortet, «SMTP settings», er veien ut: vert, port, «Use SSL», bruker og passord, i tillegg avsenderadressen og avsendernavnet. Med «Send test e-mail» sender dere dere selv en prøve — lagre først, test så, slik kortet selv sier.

Kortet «IMAP settings» er veien inn: vert, port, hentingsintervallet og de to mappene. Dere trenger ikke å gjette mappenavnet: «Read from server» henter mappene som virkelig finnes i postkassa deres, «Create on server» oppretter ei ny. Feltet tar da den stien e-postserveren deres bruker til den — én server skriver «INBOX/Processed», den neste «INBOX.Processed», og begge deler betyr det samme.

«Processed folder» tar imot e-postene som systemet legger til side: e-post fra blokkerte avsendere, automatisk generert e-post og e-post som en arbeidsflyt flytter med «Move to folder» uten sin egen mappe. Lar dere feltet stå tomt, blir de i innboksen. Nedenfor setter dere når oppryddingen kjører («Hour», «Minute»), og hvor gammel en melding kan bli («Retention (days)») — ellers vokser postkassa stille og rolig.

Postkasser hører til teamet, ikke til systemet: under «Team mailboxes» taster hvert team inn sin egen adresse med et passord. Den adressen er samtidig avsenderen på e-postene til det teamet — så innmelderen svarer til det samme stedet som posten blir hentet fra.

Og nå den delen som ingenting av dette skjer uten: arbeidsflyten. Ei oppsatt postkasse gjør ingenting i det hele tatt av seg selv. Har et team ingen arbeidsflyt slått på, blir postkassa ikke engang hentet — ingen sak, ingen kvittering, e-postene blir bare liggende. Det automatiske svaret til kundene deres finnes bare her, og dere setter det opp selv. Det er med vilje: et system som uoppfordret skriver til hver avsenderadresse, ville vært verre enn ett som tier stille.

Under «E-Mail workflows» velger dere teamet øverst og oppretter en arbeidsflyt med «+ Add workflow». Den får et navn (bare til dere), en «Enabled»-bryter og to utsagn om når den gjelder: «Match» bestemmer om alle betingelsene må være oppfylt («All conditions»), eller om én holder, og «Stop after match» avslutter kjøringen så snart denne arbeidsflyten har passet — en arbeidsflyt lenger ned kommer da aldri til. Rekkefølgen endrer dere med pilene ved siden av.

Under «When?» sitter selve betingelsen. «Every e-mail in this mailbox» tar hver e-post; «Only when subject or text contains» krever et ord i emnet eller teksten. «Advanced» gjør det presist: der velger dere hva det blir sett på — «Subject or body», «Subject», «Body», «Sender (From)» eller «Recipient (To/Cc)» — og hvordan det blir sammenlignet: «Contains», «Equals» eller «Regex». Slik skiller dere for eksempel meldinger til en felles adresse fra alt det andre.

Nedenfor sitter fem handlinger som brytere. De er det egentlige innholdet i arbeidsflyten — det som ikke er slått på, skjer ikke:

«Create or append ticket» gjør e-posten til en sak — eller føyer den til som kommentar på en eksisterende når henvisningen står i emnet. Uten denne handlingen blir en e-post aldri til en sak.

«Set fields» setter prioritet, status, hoved- og underkategori, eierteam og saksbehandler allerede når saken blir opprettet. Alt som står på «— Keep default —», blir som det ville vært uten en arbeidsflyt.

«Auto-reply» er kvitteringen til avsenderen. Med denne bryteren av får kunden deres ingen kvittering, uansett hvor godt alt annet er satt opp. «Send mail» kan også skrive til avsenderen, som den neste handlingen viser.

«Send mail» sender en ekstra e-post: enten til avsenderen av den innkommende e-posten eller til utvalgte teammedlemmer og faste adresser. Den har sine egne «Send conditions» — lar dere dem stå tomme, går den ut ved hver kjøring av denne arbeidsflyten.

«Move to folder» legger den behandlede e-posten i ei mappe. La feltet stå tomt, og den generelle «Processed folder» fra IMAP-innstillingene ovenfor gjelder.

Handlingen «Auto-reply» i detalj: emnet bygger dere av klosser. «Original subject {originalSubject}» overtar emnet fra den innkommende e-posten, «Ticket reference {ticketTag}» setter inn henvisningen til saken — sammen gir de noe i retning av «Printer problem [TICKET-99-a1b2c3]».

Henvisningen blir ikke lagt til av seg selv. Den dukker bare opp der dere setter {ticketTag}. {ticketId} setter bare inn det nakne nummeret, og på det kjenner ikke systemet igjen et svar. Står ikke henvisningen i emnet, blir et svar likevel koblet til saken hvis det har svarhodene fra kvitteringen med seg. Bare en e-post med ingen av delene blir til en ny sak.

Teksten nedenfor er kvitteringsmeldingen deres. Skriv den på engelsk: den løper gjennom den samme eksporten og importen som hver annen tekst, og bare på den måten kan den oversettes til de andre språkene. La den stå tom, og systemet sender sin egen standardmelding. De samme plassholderne er tillatt her også.

«Reply language» bestemmer hvilket språk emnet og teksten går ut på: «Standard English» bruker engelsk, «Fixed language» et språk dere velger, «Assigned agent's language» språket til den tildelte agenten, og «Team default language» standarden til teamet. Selve oversettelsene blir vedlikeholdt på språksiden.

Ett råd som systemet også skriver over kortet: alt som hører til én sak, hører hjemme i ÉN arbeidsflyt. Bare handlinger inne i den samme arbeidsflyten kjenner saken som nettopp er opprettet — derfor kan kvitteringen nevne nummeret sitt, og en handling fra en annen arbeidsflyt kan det ikke.

Hele e-postkanalen — inn og ut — er en del av Professional-utgaven. I Basic sender og mottar systemet ingen e-post; saker blir der opprettet gjennom portalen, telefonen og agenten.

Tidsregistrering er slått av som fabrikkinnstilling. Så lenge den er av, finnes det ikke noe felt og ingen kolonne. Kortet «Time spent» i rapporten dukker da bare opp hvis det er registrert tid i den valgte perioden.

Et dødt felt ville vært verre enn ingenting, så funksjonen forsvinner helt i stedet for å stå der gråtonet.

Bryteren sitter under «Settings → General» på kortet «Time tracking per ticket» og heter «Enable time tracking».

Hvert team er da med. Vil dere holde ett utenfor, slår dere det av på selve teamet, under «Settings → Teams» i boksen «Team details».

En bedrift med et internt IT-team og et kundevendt team trenger den ofte bare til det andre.

Slår dere tidsregistreringen av igjen senere, fortsetter de eksisterende postene å kunne leses og eksporteres — de er et grunnlag for fakturering, ikke en bekvemmelighet. Det kan ikke registreres noe nytt. Eksisterende poster kan da heller ikke lenger endres eller slettes.

Saken bærer et kort som heter «Time spent». «Log time» åpner inntastingen.

Hurtigknapper sitter ved siden av feltet: ett klikk på «30m» registrerer tretti minutter. Hvilke knapper som dukker opp, blir satt i innstillingene.

Feltet «Duration» tar også imot fri inntasting: «90» er nitti minutter, «1.5h» er halvannen time, og det samme er «1h 30m». Et tall uten enhet er alltid minutter.

Inntasting systemet ikke forstår helt, blir avvist. «1t på kvelden» blir ikke til en post på én time — det blir til en feilmelding.

I «What for (optional)» skriver dere hva tida gikk til. Teksten følger med inn i eksporten og dukker ikke opp i sakshistorikken.

Flere agenter registrerer tid på den samme saken. Hver post bærer dagen sin, notatet sitt og navnet til den som utførte arbeidet.

Tid blir registrert på en dag, ikke på et klokkeslett. Inntastingen har til dette et datofelt som starter med i dag; for å fylle ut i går velger dere dagen før der. En dag i framtida blir ikke godtatt. Et klokkeslett ville påstått en presisjon inntastingen ikke har.

Til lange økter finnes det ei stoppeklokke på saken: «Start timer» starter den, «Pause» holder den.

Stoppeklokka oppretter aldri en post av seg selv. Den foreslår den forløpte tida, og det blir ikke lagret noe før dere trykker på knappen «Log …» som nevner tida. Det som blir registrert, er tida som faktisk har gått.

Den erstatter hoderegning, ikke kunnskap. Uten den er funksjonen komplett, for å taste inn verdien er den egentlige veien.

Åpner dere en annen sak, står den gående stoppeklokka stille, og den nye saken forteller dere hvilken sak den henger på. Venter det fortsatt tid som ikke er registrert, på en annen sak, og dere starter stoppeklokka her, spør programmet først. Spørsmålet «Start timer» tilbyr «Log …» for tida på den andre saken, «Discard» og «Cancel». Det dukker opp fra ett minutts forløpt tid.

Et skjult vindu er ikke en pause. Stoppeklokka går videre hvis dere bare klikker bort.

Mot ei stoppeklokke som er latt gående natta over, finnes det en maksimal løpetid. Verdien blir skåret til, aldri kastet, og agenten får det å vite.

Stoppeklokka er slått av som fabrikkinnstilling. Dere finner den i innstillingene under «Stopwatch on the ticket».

Hver post bærer en «Billable»-bryter. Tida blir registrert én gang, og bryteren bestemmer om den kommer på fakturaen.

Derfor kan saken vise to summer: alt det registrerte til venstre, den fakturerbare summen til høyre. Den andre summen dukker bare opp når den avviker fra den første.

Det finnes ingen egen type for kulanse. Kulanse, garantiarbeid og internt etterarbeid heter forskjellige ting i hver bedrift, og systemet kjenner bare den ene forskjellen det henger penger på.

Slik registrerer dere kulanse: tast inn tida som vanlig, slå av «Billable», og skriv begrunnelsen i notatet.

Posten bærer da synlig «not billable». Minuttene blir stående i den registrerte summen, for arbeidet fant jo sted.

Den som ikke registrerer tida i det hele tatt, mister nettopp det tallet som senere forklarer hvorfor en kunde ble fakturert så lite.

Er størstedelen av arbeidet deres ikke fakturerbart, snu utgangspunktet med bryteren «New entries are billable by default».

Som fabrikkinnstilling blir alt fakturert på minuttet. Den som fakturerer i kvarte timer, setter to verdier.

«Rounding increment (minutes)» er trinnet. Hver post blir rundet opp til det neste multiplumet.

«Minimum per entry (minutes)» er golvet. Hver post blir fakturert med minst denne verdien.

De to virker etter hverandre: først golvet, så trinnet. Med et golv på 20 og et trinn på 15 blir fem minutter til tretti, fordi resultatet må oppfylle begge deler.

Under de to feltene står en eksempelsetning med deres egne verdier. Den er regnet ut, ikke påstått.

Bare den fakturerte verdien blir noen gang rundet av, og bare per post — aldri summen. To små poster blir derfor rundet opp to ganger.

Den registrerte tida blir ikke rørt. Å endre avrundingen senere forfalsker ingen gamle data, for verdien blir regnet ut når den blir vist.

Dere ser begge deler på posten: der avrundingen endrer verdien, står resultatet ved siden av i parentes.

En tjenesteleverandør vil ofte ikke ha noen sak lukket uten registrert tid. Det finnes en bryter til det.

Den heter «Require a time entry before resolving or closing» og er slått av som fabrikkinnstilling.

Den gjelder bare når et menneske endrer statusen, og bare for personer som kan registrere tid. Den gjelder også når en svarmal setter statusen på en enkelt sak. En agent uten en post får en beskjed, og saken blir stående åpen.

Automatisk lukking, sammenslåing og massehandlinger blir aldri blokkert. Ellers ville det finnes saker ingen kan lukke lenger.

Det er hele funksjonens farligste bryter. Slå den først på når teamet deres virkelig registrerer tid hver gang.

Sakslista får en «Time»-kolonne som viser hvor mye som allerede er registrert på en sak.

Dere slår den ikke på. Den dukker opp så snart tidsregistreringen er på. Bare agenter og administratorer ser den. Dere kan fjerne den fra lista deres med «Columns».

På smale vinduer er den en av de første som faller ut igjen. Lista beholder da de kolonnene en sak ikke kan finnes uten.

Tid som bare står på en enkelt sak, er ikke noe grunnlag for en faktura. Derfor bærer rapportsiden et kort som heter «Time spent». Bare personer med rettigheten «Time tracking: see the report» ser kortet.

Fire tall står øverst: registrert, fakturert, antallet poster og antallet saker som i det hele tatt bærer tid.

Det siste tallet er det viktigste etter summen. Førti timer på tre av fem hundre saker er ikke en oppsummering — det er tre agenter som er de eneste som registrerer.

Nedenfor kommer oppdelingene: etter innmelder, etter team, etter kategori og etter dag.

I tillegg kommer én tabell per egendefinert felt. Det er veien til å fakturere etter firma eller kostnadssted: dere oppretter et egendefinert felt, fyller det ut på saken, og rapporten grupperer etter det.

Perioden øverst på siden gjelder dagen arbeidet ble utført. Juliarbeid på en junisak står derfor i julirapporten.

En merknad under eksportknappene fortjener å bli tatt alvorlig: tallene kommer fra poster mennesker har laget, og fra avrundingsreglene deres. De er et arbeidsgrunnlag, ikke en revidert faktura.

Tre knapper sitter under kortet. De leverer de enkelte postene, ikke summene fra siden. De inneholder nøyaktig de postene som passer til filtrene deres.

Det er to mottakere, ikke tre filformater. «Export entries (CSV)» og «Export entries (Excel)» går til regnskapet: begge er komplette og blir aldri kuttet.

«Export entries (PDF)» er dokumentet til et menneske. Det går til kunden som vedlegg til fakturaen. PDF-en har ingen kolonne for notatet.

PDF-en er kuttet ved 20 000 poster, og dokumentet sier det selv. Ingen leser uansett en faktura med flere linjer enn det.

Alle tre filene blir bygget av den samme kilden: filtre, avrunding, kolonner og tall finnes én gang, så de tre kan ikke gli fra hverandre.

En post som ikke er fakturerbar, har ei tom celle i den fakturerbare kolonnen, ikke en null. En null ville blitt lagt sammen i en pivottabell.

Er «Per-agent evaluation» for tidsregistreringen av, mangler kolonnen «Agent» i alle tre filene. Faller lisensen deres tilbake til Basic, kan de eksisterende postene fortsatt leses og eksporteres.

En kunde ser aldri tidspostene, heller ikke på sin egen sak.

Det er ikke en innstilling, men en sperre i serveren. Det finnes ingen bryter som åpner den.

Grunnen ligger i postene selv: notater blir skrevet til teamet. De sier hva som gikk galt, og hvor lenge jakten på årsaken tok.

Andre systemer av det slaget gjør det samme. Der tid når kunden, når den henne som et dokument.

Det er det PDF-eksporten er til: den går ut med fakturaen og ikke inn på saken i kundeportalen.

Rapporten kan i tillegg vise hvem som registrerte hvor mye. Som fabrikkinnstilling gjør den ikke det.

Tid per person er ytelsesdata, og i mange bedrifter har de tillitsvalgte medbestemmelse på det.

Bryteren heter «Per-agent evaluation» og sitter i innstillingene.

Så lenge den er av, leverer serveren ikke engang tallene. Tabellen er ikke skjult — den finnes ikke.

Den forskjellen betyr noe. En sperre som bare visningen kjenner til, er ingen sperre.