Ansøgninger med opgaver og godkendelse

»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 udfylder du nogle få felter. »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.

Foran »Ticket title« står den faste tekst »Parent ticket title -«. Den nye sag begynder med ansøgningens titel, efterfulgt af din titel, for eksempel »New colleague in accounting - Set up notebook and docking station«. På den måde ser specialistteamet, hvilken ansøgning en opgave hører til. Lader du feltet stå tomt, følger opgavens navn i stedet.

»Main category« og »Subcategory« udfylder kategorien på den nye sag på forhånd. Du får kun kategorierne fra teamet i »Handled by«, fordi det er der, sagen bliver oprettet. Skifter du team, bliver begge felter tømt. Du sætter begge eller ingen, og forbliver de tomme, bliver sagen oprettet uden kategori.

Ansøgningens navn står over opgaverne. Med blyanten ved siden af omdøber du den. Navnet hører til sagsskabelonen, så det ændrer sig også under »Settings → Templates« og i formularen til en ny sag.

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. Deres interne noter dukker heller ikke op i ansøgningens historik. Når et specialistteam lukker sin sag, bliver dens vedhæftede filer kopieret til ansøgningen med mærkningen »Internal«, og kunden hverken ser eller downloader dem.

Kommer en ansøgning ind på e-mail, bliver den en almindelig sag. Så starter du workflowet bagefter. Det gør knappen »Start workflow« øverst på sagen.

I dialogen vælger du den passende skabelon under »Template«. Under den får du den samme boks »What is needed?« som i formularen til en ny sag. Sæt flueben ved det, ansøgningen beder om.

Under »Title« tilpasser du sagens titel. Opgavernes titler begynder med den. Nedenunder finder du skabelonens ekstra felter. Skriv oplysningerne fra ansøgningen ind der. Påkrævede felter har en stjerne.

Med »Start« bliver opgaverne oprettet præcis som ved en ansøgning fra formularen. Kræver skabelonen en godkendelse, forbliver sagen og dens opgaver låst, indtil den er givet.

Der kan kun startes ét workflow per sag. Derefter forsvinder knappen. Den mangler også på lukkede sager og på sager, der selv er en opgave. Alle, der må arbejde på sagen, kan starte det.

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.

Når et specialistteam lukker sin sag, lander teamets »Closing comment« i ansøgningen. Den står der som en intern note, og dens første linje nævner opgavens nummer og navn. Kunden ser ikke denne note.

Adgangsoplysninger og alt det, som ansøgningens agent skal give videre, hører hjemme i afslutningskommentaren. Alle andre kommentarer fra specialistteamet bliver i teamets egen sag. Lukker teamet uden en kommentar, bliver der ikke oprettet nogen note.

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 fem felter: »Name« er trinnets navn, »Covers« siger, hvad det gælder, »Decided by« siger, hvor godkenderen kommer fra, »Approver« rummer personen, og »Remind after (hours)« sætter påmindelsen.

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 bærer trinnets navn som overskrift. 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 …«. Det er gyldigt i 14 dage. Derefter siger siden kun, at linket er ugyldigt eller udløbet, og en administrator sender ansøgningen ud igen med »Reassign«.

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

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. Et trin bliver kun spurgt, hvis en af de valgte opgaver angår det. Trinnet for hele ansøgningen bliver altid spurgt.

En opgave er frigivet, når hvert trin, der angår den, har sagt ja. En opgave uden sit eget trin går i gang med det samme, medmindre trinnet for hele ansøgningen stadig venter. Så går den i gang, så snart ansøgningen er godkendt.

Indtil da er opgaven låst. Dens sag står på »Waiting for approval« og har ingen sagsbehandler. I stedet for statusknapper står der på kortet »This ticket is waiting for approval and cannot be worked on yet.« Ingen vej giver den en sagsbehandler før da.

Låsningen holder også for massehandlinger på sagslisten. Vælger du sådan en sag der, læser du grunden: »This ticket 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.

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.

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.

Når ansøgningen først er afvist, får de andre godkendere ikke flere mails. Deres link lyder så »This request has already been rejected. Your decision is no longer needed.« I listen på sagen viser deres trin »No longer needed: the request was rejected.«

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.