Svar- og saksmaler

Maler bor under «Settings → Templates». Linja under overskriften sier hva de gjør, og hva de ikke gjør: «Reply templates fill the comment editor and suggest field actions. Nothing is sent automatically.» En mal er et forberedt trekk, ikke en maskin — dere sender den alltid selv.

Det finnes to slag, og dere velger ett når dere oppretter den: «Add reply template» til svaret på en åpen sak, «Add ticket template» til skjemaet for en ny sak. Slaget kan ikke endres etterpå, fordi det bestemmer hvilke felter skjemaet i det hele tatt viser. Merkingen over hver mal forteller dere hvilken dere ser på: blå «Reply template», grønn «Ticket template».

En svarmal består av svarteksten («Reply text»), avkryssingsboksen «Internal note» og et vilkårlig antall handlinger. Det finnes seks handlinger: «Set the status», «Set the priority», «Assign to a user», «Remove the assignee», «Hand over to another team» og «Set a follow-up».

Lista «Assign to a user» begynner med posten «The agent who applies it». Ta den når flere deler malen: saken tilhører da den som brukte den, ikke én fast person fra lista. «Set a follow-up» ber om et antall og en enhet (minutter, timer, dager, arbeidsminutter, arbeidstimer, virkedager) pluss notatet som senere forteller dere hvorfor saken er tilbake.

Den blå boksen ved enden av hver mal skriver i én setning ned hva den kommer til å gjøre — for eksempel «Inserts the text as a public comment, sets status to Waiting for Service Provider Response, assigns to the applying agent, sets a follow-up in 3 days.» Setningen bygger seg selv om mens dere retter. Den er kontrollen deres: sier den noe annet enn det dere hadde tenkt, er én innstilling feil.

Tekst er ikke påkrevd. «Gi denne videre til nettverksteamet uten å skrive et ord» er en gyldig mal — setningen lyder da «Suggests actions without a reply text». Handlingen «Set the status» følger de samme reglene som et statusbytte for hånd. Brukt på flere saker på én gang hopper malen over låste saker og nevner grunnen.

Vinduet «Close ticket» tilbyr også svarmaler, i feltet «Template». Det viser bare maler der den aktive handlingen «Set the status» setter en status som teller som løst eller lukket. Interne maler blir ikke tilbudt der. Velger dere en, tar vinduet over teksten dens som kommentar. Sender malen en e-post og vinduet tilbyr e-postutsending, tar det bare over mottakeren hvis den er «Requester» eller en fast adresse. De andre handlingene og vedleggene i malen kjøres ikke der. Saken lukkes som vanlig.

På en åpen sak sitter knappen «Template» over kommentarfeltet. Et klikk åpner søket med forslag («Search templates…»), og velger dere en, blir kommentarfeltet fylt ut. Det skjer ikke noe annet, og linja nedenfor sier det: «Nothing happens until you add the comment.»

Hver av handlingene i malen blir til ei brikke ved siden av knappen — på vanlig språk, ikke i fagspråk: «sets status to Waiting for Service Provider Response», «assigns to the applying agent», «sets a follow-up in 3 days». Klikker dere på ei brikke, blir den strøket over: den er valgt bort og kjører ikke. Enda et klikk henter den tilbake.

Bortvalgte handlinger blir strøket over, ikke fjernet. Det holder det synlig hva malen ville foreslått — og det holder beslutningen omgjørlig så lenge dere ikke har sendt.

Hvilke brikker som starter som aktive, bestemmer malen: i innstillingene bærer hver handling en «Suggested»-bryter. Den bryteren er forslaget for hvert tilfelle; brikka på saken er beslutningen for nettopp dette.

«×» bak brikkene fjerner malen igjen. Teksten blir i redigeringsfeltet — dere har kanskje allerede skrevet den om; bare virkningen forsvinner, altså handlinger, e-post og vedlegg.

Dere sender med den vanlige kommentarknappen. Først da blir kommentaren opprettet, og først deretter kjører de handlingene som fortsatt er aktive.

Svarteksten kan bruke fem plassholdere; lista står under feltet: «{requesterName}, {ticketId}, {ticketTitle}, {ticketRef}, {agentName}». Skriv dem med krøllparenteser, nøyaktig som de står der.

«{ticketRef}» er henvisningen til saken i formen «[TICKET-8-…]». Det er den systemet kjenner igjen svaret fra en kunde på når det kommer tilbake på e-post. «{ticketId}» er derimot bare det nakne nummeret.

De blir løst når malen BRUKES, ikke når den lagres: innstillingssiden fortsetter å vise «{requesterName}», kommentarfeltet på saken viser det riktige navnet. Grunnen er praktisk — å løse dem ved lagringen ville brent verdiene til ÉN sak fast i malen for alltid.

På den måten leser dere den ferdige teksten før noe forlater bedriften. Passer ikke tiltalen, endrer dere den i redigeringsfeltet som enhver annen tekst.

Hvem som teller som «innmelder», bestemmer saken, ikke kontoen: innmelderen som er notert på saken, kommer før kontoen som opprettet den. Oppretter en agent en sak for en kollega etter en telefonsamtale, hilser svaret fortsatt på kollegaen og ikke på agenten.

En feilskrevet plassholder blir avvist ved lagringen, og den blir nevnt: «Reply text: unknown placeholders {requesterNam}. Available here: {requesterName}, {ticketId}, {ticketTitle}, {ticketRef}, {agentName}.» Så oppdager dere det mens dere skriver malen, ikke på en kunde.

Emnet i e-posten har sin EGEN, kortere liste («{originalSubject}, {ticketTag}, {ticketId}») — og derfor står den trykt der en gang til. «{ticketRef}» virker også der og betyr det samme som «{ticketTag}». «{requesterName}», «{ticketTitle}» og «{agentName}» virker ikke i emnet og blir avvist på samme måte.

Bryteren «Send the comment as e-mail» gjør kommentaren til e-posten også. Det finnes bevisst ikke noe annet tekstfelt til det: det som står i saken, er det kunden leser — to tekster ville før eller siden glidd fra hverandre.

Under «Recipient» velger dere mellom «Requester», «Assignee», «Observers» og «Fixed address». Hvem innmelderen er, blir løst av serveren når malen brukes — en mal kjenner ennå ikke saken. Selve postkassekontoen blir det aldri skrevet til; det ville vært en melding til oss selv. Står det et navn uten adresse i feltet «User», går det ingen e-post til innmelderen. Den blir heller ikke sendt til den som registrerte saken, i stedet.

Emnet kan bære «{originalSubject}», «{ticketTag}» og «{ticketId}». Behold «{ticketTag}» der inne: den henvisningen er det systemet kjenner igjen svaret fra kunden på og føyer det til den samme saken. Uten den blir hvert svar til en ny sak.

E-posten går ut som ren tekst. Fet skrift, lister og lenker blir skåret bort før sendingen, ellers ville kunden lest den rå oppmerkingen. Inne i saken beholder kommentaren formateringen sin.

På saken er e-posten enda ei brikke ved siden av handlingene («E-mail to Requester») og kan velges bort nøyaktig som de andre. Så en mal sender aldri noe uten at dere har sett det. Brikka dukker bare opp når postkassa til teamet sender e-poster ved sakshandlinger.

Vedleggene til en mal («Attachments») er dens egne kopier av filene. Å bruke malen legger dem på SAKEN, med sin egen rad i historikken — de er ikke en del av e-posten. Å bære vedlegg på en mal krever ingen Professional-lisens; bare sendingen gjør det. En mal med krysset «Internal note» legger ikke til noen filer.

De fleste maler blir ikke født ved et tegnebord, men i det øyeblikket dere skriver det samme svaret for andre gang. Derfor bærer hver kommentar på en sak et lite arkikon til høyre, med teksten «Make template». Det tar nøyaktig den kommentaren som starttekst — også kommentaren til en kollega. Bare de som kan styre maler, ser ikonet.

Har saken vedlegg, spør en dialog først hvilke som skal bli med: «Tick only the attachments the template should carry — one of them may be a customer's screenshot. Nothing is ticked by default.» Det er ingenting avkrysset på forhånd, og det er med vilje.

Deretter havner dere på malsiden med et utkast som IKKE er lagret ennå. Øverst sitter det ravgule banneret «Draft from ticket #… — name it and review the text (it may contain customer details), then save.» Navnet er tomt: dere må gi ett, ellers blir den ikke lagret.

Det som blir tatt med: teksten, avkryssingsboksen «Internal note», teamet til saken og tilstanden til saken som forslag — statusen og prioriteten dens ligger allerede der som to handlinger. Det som ikke blir tatt med: innmelder, adresse og tittel. De hører til denne ene saken.

Les teksten før dere lagrer. Den kommer fra en ekte sak og kan romme navnet til et menneske, et ordrenummer eller et rom. Det blir ikke anonymisert noe for dere — banneret sier det, men å gjøre det er deres oppgave.

Bare «Save» oppretter malen; de avkryssede filene blir da kopiert over og bekreftet med en beskjed.

«Applies to» bestemmer hvem malen blir tilbudt: ett bestemt team eller «All teams». En ny mal starter med et konkret team — «All teams» er et valg noen må ta, ikke et stilltiende utgangspunkt.

På en sak blir dere tilbudt malene til eierteamet pluss de globale. Flytter saken til et annet team etter en overføring, flytter lista med — malene til det nye teamet er dem dere kan velge fra.

Bryteren «Draft» gjør malen til verkstedet deres: «Only you can see this template until you publish it.» Utkastet til en annen dukker ikke opp i noen liste og kan heller ikke nås på adressen sin — heller ikke av administratorer. En ny mal starter som utkast; først når dere slår det av og lagrer, ser de andre den.

To maler kan ikke dele navn hvis de kan møtes: en global støter sammen med enhver mal med samme navn, i ethvert team. En svarmal og en saksmal kan derimot gjerne dele navn — de står aldri side om side i den samme lista.

«Duplicate» lager en kopi, og kopien er alltid et utkast: «Duplicated. The copy is a draft only you can see.» Det er den behagelige veien til en variant uten at andre blir tilbudt den halvferdige utgaven.

En saksmal fyller ut skjemaet «Create new ticket». Den har ingen svartekst, ingen handlinger og ingen e-post — i dette øyeblikket finnes det ingen sak å handle på. Skjemaet viser derfor andre felter enn ved en svarmal, og den grønne ramma forteller dere at dere ser på en saksmal.

Dere kan fylle ut «Ticket title», «Owning team of the new ticket», «Main category», «Subcategory», «Priority» og «Ticket description» på forhånd. Hvert felt kan gjerne bli stående på «Not prefilled» — det som blir stående tomt, fyller den ut senere som bruker skjemaet.

Følg med på forskjellen mellom de to teamfeltene: «Applies to» øverst sier HVEM som ser malen. «Owning team of the new ticket» sier HVOR den nye saken går. Det er to forskjellige spørsmål, og de kan gjerne ha forskjellige svar.

Kategoriene er gruppert etter team, fordi en kategori hører til et team. Velger dere en fra et annet team, sier skjemaet fra, og lagringen blir avvist: på skjemaet for en ny sak hos mottakerteamet ville den kategorien ikke blitt tilbudt i det hele tatt, så utfyllingen ville endt i ingenting.

Det finnes ingen plassholdere her, og hjelpeteksten under teksten sier det: «No placeholders here: the template only prefills the form, nothing is resolved or sent.» En «{requesterName}» ville endt bokstavelig i den nye saken — og derfor blir det avvist ved lagringen.

Den blå boksen samler også her hva malen gjør: «Prefills the new ticket with title 'New notebook for a colleague' · category Notebook / New request · priority Medium · team Helpdesk · the description.»

På selve skjemaet velger dere malen med knappen «Template»; ved siden av står «Prefills the form - nothing is created until you submit.» Alt som er fylt ut, kan fortsatt endres, og det blir ikke opprettet noe før dere sender.

Én eksempelmal følger med systemet: «Example: create accounts for a new colleague». Den viser formen på tingen og gjør ingenting av seg selv — bygg den om, eller slett den.

Bryteren «Offer this template to customers» er slått av som fabrikkinnstilling. Hjelpeteksten ved siden av sier begge tingene dere må vite: «Customers can pick this template when they create a ticket. A draft stays hidden either way.»

Hvorfor den er av som utgangspunkt: en mal er ofte navngitt i internt språk og skrevet til kolleger. Å gjøre den synlig for kunder er en uttalelse utad — det skal noen gjøre med vilje, ikke ved et uhell.

Kunden ser den samme «Template»-knappen over skjemaet for en ny sak, men bare de frigitte malene. Et utkast blir skjult også med bryteren på — de to reglene sitter etter hverandre, ikke ved siden av hverandre.

Poenget er ikke bekvemmelighet, det er den første kontakten: en henvendelse som kommer inn komplett, sparer den runden med spørsmål som ellers ville kostet to dager. Legg de spørsmålene inn i beskrivelsen til malen — kunden svarer på dem mens hun oppretter saken.

Dere kan gå videre med «Fields to ask for». Malen bestemmer da hvilke egendefinerte felter skjemaet spør om, i hvilken rekkefølge, og hvilke av dem som er påkrevde. Det utvalget ERSTATTER de vanlige feltene til teamet, det kommer ikke i tillegg. Det er nettopp meningen med det. Egendefinerte felter er i seg selv en del av Professional; kortet deres heter «Egendefinerte felter». Å frigi en mal til kunder virker i hver utgave.

Et felt som er skjult for kunder, blir skjult, også hvis en mal nevner det. Feltutvalget er et verktøy for orden og for tilskjæring, ikke en vei utenom feltinnstillingene.

Hver bruk som gjør mer enn å sette inn tekst, skriver ÉN post i historikken, under feltnavnet «Template». Den nevner malen. Handlingene som kjørte, skriver egne rader. Uten den ville det ikke vært noen måte å forklare etterpå hvorfor en sak plutselig hoppet til «In Progress»: de enkelte handlingene skriver riktignok sine egne rader, men ingen av dem nevner malen.

Bildet lyder: «Template 'First reply: we have your ticket' applied». Hva malen gjorde, står i radene for dens egne handlinger, som statusendringen.

Bortvalgte handlinger står ikke i den: de skjedde ikke. En feil står i den, og den blir nevnt som en, bak ordet «failed». En ren tekstmal uten handlinger, e-post eller vedlegg etterlater ingen «Template»-post på en enkelt sak. Den har bare satt inn tekst. Brukt på flere saker på én gang blir posten alltid skrevet, sammen med den interne raden «Bulk».

Posten er INTERN — innmelderen ser den ikke. Navnet til en mal er internt språk («standardavslag»), og historikken er også åpen for den som opprettet saken. Selve feltendringene er synlige for henne; bare opprinnelsen deres i en mal er det ikke.

Forfatteren er agenten, ikke «system» og ikke malen. Det er med vilje: å bruke den var hennes beslutning. I motsetning til en automatiseringsregel står det her et menneske på saken.