Søknader med oppgaver og godkjenning

«En ny kollega starter» er ikke én sak. Det er en bærbar, to kontoer, et telefonnummer og kanskje tilgang utenfra. Hver del hører til et forskjellig team, og dere vil likevel ha én sak som forteller dere hvor det står.

Det er det en søknad er til. Den er en sak som oppretter oppgavene sine i det øyeblikket den blir sendt, og hver oppgave blir til sin egen sak i teamet som håndterer den.

En søknad er ikke enda en ting å vedlikeholde. Den bor på en saksmal: under «Settings → Request workflows» finner dere hver saksmal, og dere henger oppgavene på en av dem.

For hver oppgave fyller dere ut noen felter. «Task» er navnet innmelderen leser, «Handled by» er teamet som får den, og «Ticket title» og «What the team has to do» fyller ut saken som kommer ut av det.

Flere oppgaver kan gjerne peke på det samme teamet. Det teamet får da flere saker, ikke én sak med ei liste inni seg.

En oppgave uten et team blir ikke tilbudt i det hele tatt. Feltet sier det selv: «Not assigned yet — this task is not offered». På den måten kan dere lagre en plan som ikke er ferdig ennå.

Over oppgavene står en setning som samler hele planen: hva som blir opprettet som fabrikkinnstilling, hvor mye innmelderen kan endre, og hvem som frigir det. Endre en innstilling, og setningen skriver seg selv om.

Foran «Ticket title» står den faste teksten «Parent ticket title -». Den nye saken begynner med tittelen på søknaden, fulgt av tittelen deres, for eksempel «New colleague in accounting - Set up notebook and docking station». Slik ser spesialistteamet hvilken søknad en oppgave hører til. Lar dere feltet stå tomt, følger navnet på oppgaven i stedet.

«Main category» og «Subcategory» fyller ut kategorien til den nye saken på forhånd. Dere får bare kategoriene til teamet i «Handled by», fordi det er der saken blir opprettet. Bytter dere team, blir begge feltene tømt. Dere setter begge eller ingen av dem, og blir de stående tomme, blir saken opprettet uten kategori.

Navnet på søknaden står over oppgavene. Med blyanten ved siden av gir dere den et nytt navn. Navnet hører til saksmalen, så det endrer seg også under «Settings → Templates» og i skjemaet for ny sak.

Når noen velger malen i skjemaet for en ny sak, dukker boksen «What is needed?» opp med én linje å krysse av per oppgave.

Det finnes tre slag, satt per oppgave. «Selectable, off by default» starter tom, «Selectable, on by default» starter avkrysset og kan velges bort, og «Always — cannot be deselected» kjører alltid.

En oppgave som alltid kjører, blir likevel vist, merket «(always included)». Innmelderen bør se hva som skjer uansett.

Under boksen leser dere hva som kommer ut av det: «Each selected item becomes its own ticket for the team that handles it.»

En kunde kan også sende en søknad, så lenge malen er frigitt til kunder. Bryteren til det sitter på malen.

Kunden ser da bare sin egen søknad. Sakene i spesialistteamene blir skjult for henne, selv om søknaden hennes opprettet dem — de sakene bærer påloggingsopplysninger og interne notater. Heller ikke de interne notatene deres dukker opp i historikken til søknaden. Når et spesialistteam lukker saken sin, blir vedleggene dens kopiert til søknaden med merkingen «Internal», og kunden verken ser eller laster ned dem.

Kommer en søknad inn på e-post, blir den en vanlig sak. Arbeidsflyten starter dere da i etterkant. Det gjør knappen «Start workflow» øverst i saken.

I dialogen velger dere den passende malen under «Template». Under den får dere den samme boksen «What is needed?» som i skjemaet for en ny sak. Kryss av det søknaden ber om.

Under «Title» justerer dere tittelen på saken. Titlene på oppgavene begynner med den. Nedenfor finner dere tilleggsfeltene til malen. Før inn opplysningene fra søknaden der. Påkrevde felter er merket med en stjerne.

Med «Start» blir oppgavene opprettet akkurat som for en søknad fra skjemaet. Krever malen en godkjenning, forblir saken og oppgavene dens låst til den er gitt.

Per sak kan bare én arbeidsflyt startes. Etterpå forsvinner knappen. Den mangler også på lukkede saker og på saker som selv er en oppgave. Alle som får behandle saken, kan starte den.

På selve søknaden står oppgavene under «Workflow tasks», med antallet ved siden av, for eksempel «1 of 4 done».

Hver rad viser navnet på oppgaven, nummeret på saken dens, teamet og saksbehandleren, og navnet er ei lenke inn i den saken.

«Gjort» kommer fra statusen til saken, ikke fra et eget kryss. Det som teller som lukket i sakslista, teller som gjort her — to måter å telle det samme på ville før eller siden glidd fra hverandre.

Blokka dukker bare opp på en søknad. En vanlig sak viser den ikke.

Når et spesialistteam lukker saken sin, kommer teamets «Closing comment» inn i søknaden. Den står der som et internt notat, og den første linjen nevner nummeret og navnet på oppgaven. Kunden ser ikke dette notatet.

Påloggingsopplysninger og alt som agenten på søknaden skal gi videre, hører hjemme i avslutningskommentaren. Alle andre kommentarer fra spesialistteamet blir i teamets egen sak. Lukker teamet uten kommentar, blir det ikke opprettet noe notat.

En godkjenning dekker hele søknaden, ikke hver enkelt oppgave. Åtte programmer er én e-post til lederen, ikke åtte.

Det setter dere opp under «Approvals» i den samme planen, og setningen ovenfor nevner regelen: «One approval covers the whole request. Add a second stage only when single tasks need their own release.» Hvert trinn har fem felter: «Name» er navnet på trinnet, «Covers» sier hva det gjelder, «Decided by» sier hvor godkjenneren kommer fra, «Approver» rommer personen, og «Remind after (hours)» setter påminnelsen.

Godkjenneren trenger ingen konto i ticketsystemet: dere taster inn en e-postadresse, og hun bestemmer over ei lenke. En leder som godkjenner to ganger i kvartalet, koster derfor ingen agentplass.

E-posten inneholder nøyaktig ei lenke til ei side. Det er bevisst ingen godkjenn- eller avvis-knapper i selve e-posten: en virusskanner som åpner hver lenke, ville ellers godkjent.

Siden bærer navnet på trinnet som overskrift. Den viser nummeret og tittelen til søknaden, innmelderen, og under «This decision covers» de oppgavene beslutningen handler om, med et kommentarfelt og de to knappene nedenfor.

Lenka varer ikke evig, og siden nevner fristen: «Please decide by …». Den er gyldig i 14 dager. Etter det sier siden bare at lenka er ugyldig eller utløpt, og en administrator sender søknaden ut igjen med «Reassign».

En beslutning kan ikke tas tilbake, og etterpå sier siden det: «A decision cannot be changed.»

Noen oppgaver krever en frigivelse for seg. Tilgang utenfra er ikke det samme som en bærbar.

Til det legger dere til et andre trinn og velger det på oppgaven under «Extra approval». Så lenge det står «None — the request approval is enough», er frigivelsen av søknaden alt som skal til. Begge trinn blir spurt samtidig, ikke det ene etter det andre. Et trinn blir bare spurt hvis en av de valgte oppgavene angår det. Trinnet for hele søknaden blir alltid spurt.

En oppgave er frigitt når hvert trinn som angår den, har sagt ja. En oppgave uten eget trinn setter i gang med én gang, med mindre trinnet for hele søknaden fortsatt venter. Da setter den i gang så snart søknaden er godkjent.

Fram til da er oppgaven låst. Saken dens står på «Waiting for approval» og har ingen saksbehandler. I stedet for statusknapper står det på kortet: «This ticket is waiting for approval and cannot be worked on yet.» Ingen vei gir den en saksbehandler før det.

Låsingen holder også for massehandlinger på sakslista. Velger dere en slik sak der, leser dere grunnen: «This ticket is waiting for approval and cannot be worked on yet.»

Saken blir likevel opprettet med én gang, slik at spesialistteamet ser hva som er på vei, og ingen må følge med på søknaden.

Dere kan sette en påminnelse per trinn, oppgitt i timer.

Kommer det ikke noe svar, går den samme e-posten ut igjen etter den tida, med den samme lenka som den første. Den som tok vare på den første e-posten, kan fortsatt bruke den.

Uten en påminnelse venter søknaden rett og slett, uten å spørre igjen.

Det som ikke finnes, er en frigivelse ved utløp. Under feltet står det med rene ord: «A request is never approved automatically. If nobody reacts, it keeps waiting.» En frist som sier ja av seg selv, ville ikke vært en godkjenning, den ville vært en formalitet.

Et avslag krever en begrunnelse. Uten en tekst tar siden ikke imot avslaget.

Feltet sier hvor teksten går: «Comment (required when you reject — the requester will see it)». Et internt notat hører ikke hjemme her.

Innmelderen får en e-post med begrunnelsen og trenger ikke å spørre hvorfor det ikke skjer noe.

En godkjenning krever ingen begrunnelse. Det er det ventede utfallet.

Er det bare et andre trinn som avviser, angår avslaget bare oppgavene til det trinnet. Resten av søknaden går videre.

En avvist oppgave får statusen «Rejected» og teller som avsluttet, slik at søknaden ikke henger for alltid på noe som aldri kommer.

Når søknaden først er avslått, får de andre godkjennerne ikke flere e-poster. Lenka deres lyder da «This request has already been rejected. Your decision is no longer needed.» I lista på saken viser trinnet deres «No longer needed: the request was rejected.»

På søknaden viser «Approvals» én rad per trinn med godkjenneren, tilstanden, og ved en åpen søknad hvor lenge den har ventet.

Etter beslutningen viser raden når den ble tatt, og med hvilken kommentar. Det er revisjonssporet, og det blir hos saken.

Er godkjenneren på ferie, flytter en administrator søknaden til en annen adresse. Knappen heter «Reassign» og dukker bare opp mens søknaden er åpen.

Bare en administrator kan det. En agent som kunne flytte den, ville kunne flytte den til seg selv og så bestemme.

En flytting lager ei ny lenke, og den gamle dør med én gang — også hvis noen har sendt den videre.

Selve flyttingen står i den samme lista: hvem som flyttet den, når, fra hvem til hvem.

Ingen kan bestemme i en annens navn. Lenka er den eneste veien, og hvem som fikk den, står notert på saken.