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 i det hele tatt dukker opp, og hvilke av dem som er påkrevde, settes under «Settings → Ticket Settings» — hver for seg for agenter og for kunder. Derfor ser en kunde et kortere skjema enn dere, uten at noen må vedlikeholde to skjemaer.

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, prioritet, tildeling, kanal og observatører sitter ett kort høyere opp under «Actions» og trer i kraft med én gang, uten en egen lagring.

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. Først deretter forsvinner de sakene fra den kjørende databasen — 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.

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 «Only for Admin/Agents». Den bærer da merkingen «Internal» og er usynlig for innmelderen — heller ikke søket får den fram.

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.

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.

En kommentar står der forkortet — den fulle 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. Seks statuser bærer merkingen «Mandatory» i lista — Open, Assigned, In Progress, Resolved, Closed og Reopened. 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 «Rejected», 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.

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», «Site», «Role», «Status» og «Priority». Bak hver av dem ligger den samme håndteringen, så dere bare må lære den én gang.

É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 site», «+ Add department» og så videre. Radene nedenfor er de eksisterende postene: det er der dere endrer et navn og bekrefter med den «Save» som står ved siden av.

Til mange poster på én gang finnes «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, seks av statusene som følger med systemet, og én plassholder i hver av listene Site, Position og Department («None selected or available»). De kan få nye navn, men ikke slettes: det henger rettigheter og prosesser på dem som ellers ville stoppet uten et ord.

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.

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 «Email» når den vokste ut av en innkommende e-post.

Det er også derfor dere ikke kan bytte en systemsatt kanal til «Phone» etterpå: feltet ville 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.

«Email» 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. 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.

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.

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.

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» gjelder nye saker: «Mandatory by default», «Hidden for customer by default» og «Not editable by customer by default». De er utgangspunkter — feltinnstillingene på den samme siden er fortsatt stedet der dere setter det presist per rolle.

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, men den kan ikke oppheve en regel: det administratoren har skjult for kunder eller erklært påkrevd, blir ved å være det, også når en mal sier noe annet. Ellers ville en mal vært en måte å melde seg ut av en husregel på.

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.

Bare agenter og administratorer fra et deltakende team 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.

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

Varselet er en e-post — så utgående post må være satt opp (Professional). Uten det kan dere taste inn observatører, men det går ingenting ut.

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.

Behandlet post flytter inn i «Processed folder»; lar dere feltet stå tomt, blir den 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 — det eneste stedet der systemet svarer av seg selv. Med denne bryteren av får kunden deres aldri et automatisk svar, uansett hvor godt alt annet er satt opp.

«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]».

Henvisningen blir ikke lagt til av seg selv. Den dukker bare opp der dere setter {ticketTag} eller {ticketId} — og det er nettopp det systemet senere kjenner igjen svaret fra kunden deres på. Står den ikke i emnet, starter hver oppfølging en ny sak i stedet for å bli til en kommentar på den gamle.

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, ingen kolonne og ingen flate i rapporten.

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.

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. Å fylle ut i går er det normale tilfellet, og 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å «Log».

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

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 et «Billable»-kryss. Tida blir registrert én gang, og krysset bestemmer om den kommer på fakturaen.

Derfor viser saken to summer: alt det registrerte til venstre, den fakturerbare summen til høyre.

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, fjern krysset, 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. 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 en sak i lista bærer tid.

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

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 over tallene fortjener å bli tatt alvorlig: de 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.

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

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.