Svar- og sagsskabeloner

Skabeloner bor under »Settings → Templates«. Linjen under overskriften siger, hvad de gør, og hvad de ikke gør: »Reply templates fill the comment editor and suggest field actions. Nothing is sent automatically.« En skabelon er et forberedt træk, ikke en maskine — du sender den altid selv.

Der findes to slags, og du vælger én, når du opretter den: »Add reply template« til svaret på en åben sag, »Add ticket template« til formularen til en ny sag. Slagsen kan ikke ændres bagefter, fordi den bestemmer, hvilke felter formularen overhovedet viser. Mærkningen over hver skabelon fortæller dig, hvilken du ser på: blå »Reply template«, grøn »Ticket template«.

En svarskabelon består af svarteksten (»Reply text«), fluebenet »Internal note« og et vilkårligt antal handlinger. Der findes 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«.

Listen »Assign to a user« begynder med posten »The agent who applies it«. Tag den, når flere deles om skabelonen: sagen tilhører så den, der anvendte den, ikke én fast person fra listen. »Set a follow-up« beder om et antal og en enhed (minutter, timer, dage, arbejdsminutter, arbejdstimer, arbejdsdage) plus den note, der senere fortæller dig, hvorfor sagen er tilbage.

Den blå boks for enden af hver skabelon skriver i én sætning ned, hvad den vil gø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.« Sætningen bygger sig selv om, mens du retter. Den er din kontrol: siger den noget andet, end du havde tænkt, er én indstilling forkert.

Tekst er ikke påkrævet. »Giv den her videre til netværksteamet uden at skrive et ord« er en gyldig skabelon — sætningen lyder så »Suggests actions without a reply text«. Handlingen »Set the status« følger de samme regler som et statusskift i hånden. Anvendt på flere sager på én gang springer skabelonen låste sager over og nævner grunden.

Vinduet »Close ticket« tilbyder også svarskabeloner, i feltet »Template«. Det viser kun skabeloner, hvis aktive handling »Set the status« sætter en status, der tæller som løst eller lukket. Interne skabeloner bliver ikke tilbudt der. Vælger du en, overtager vinduet dens tekst som kommentar. Sender skabelonen en mail, og tilbyder vinduet at sende mail, overtager det kun modtageren, hvis den er »Requester« eller en fast adresse. Skabelonens andre handlinger og dens vedhæftede filer kører ikke her. Sagen bliver lukket som sædvanlig.

På en åben sag sidder knappen »Template« over kommentarfeltet. Et klik åbner søgningen med forslag (»Search templates…«), og vælger du en, bliver kommentarfeltet udfyldt. Der sker ikke andet, og linjen nedenunder siger det: »Nothing happens until you add the comment.«

Hver af skabelonens handlinger bliver til en brik ved siden af knappen — i almindeligt sprog, ikke i fagsprog: »sets status to Waiting for Service Provider Response«, »assigns to the applying agent«, »sets a follow-up in 3 days«. Klikker du på en brik, bliver den streget over: den er fravalgt og kører ikke. Et klik til henter den tilbage.

Fravalgte handlinger bliver streget over, ikke fjernet. Det holder det synligt, hvad skabelonen ville have foreslået — og det holder beslutningen omgørlig, så længe du ikke har sendt.

Hvilke brikker der starter som aktive, bestemmer skabelonen: i indstillingerne bærer hver handling en »Suggested«-kontakt. Den kontakt er forslaget til hvert tilfælde; brikken på sagen er beslutningen for netop dette.

»×« bag brikkerne fjerner skabelonen igen. Teksten bliver i redigeringsfeltet — du har måske allerede skrevet den om; kun virkningen forsvinder, altså handlinger, mail og vedhæftede filer.

Du sender med den sædvanlige kommentarknap. Først da bliver kommentaren oprettet, og først derefter kører de handlinger, der stadig er aktive.

Svarteksten må bruge fem pladsholdere; listen står under feltet: »{requesterName}, {ticketId}, {ticketTitle}, {ticketRef}, {agentName}«. Skriv dem med krøllede parenteser, præcis som de står der.

»{ticketRef}« er sagens henvisning i formen »[TICKET-8-…]«. Det er den, systemet genkender en kundes svar på, når det kommer tilbage på e-mail. »{ticketId}« er derimod bare det nøgne nummer.

De bliver løst, når skabelonen ANVENDES, ikke når den gemmes: indstillingssiden bliver ved med at vise »{requesterName}«, kommentarfeltet på sagen viser det rigtige navn. Grunden er praktisk — at løse dem ved gemningen ville brænde ÉN sags værdier fast i skabelonen for altid.

På den måde læser du den færdige tekst, før noget forlader virksomheden. Passer tiltalen ikke, ændrer du den i redigeringsfeltet som enhver anden tekst.

Hvem der tæller som »anmelder«, bestemmer sagen, ikke kontoen: den anmelder, der er noteret på sagen, kommer før den konto, der oprettede den. Opretter en agent en sag for en kollega efter en telefonsamtale, hilser svaret stadig på kollegaen og ikke på agenten.

En forkert skrevet pladsholder bliver afvist ved gemningen, og den bliver nævnt: »Reply text: unknown placeholders {requesterNam}. Available here: {requesterName}, {ticketId}, {ticketTitle}, {ticketRef}, {agentName}.« Så opdager du det, mens du skriver skabelonen, ikke på en kunde.

E-mailens emne har sin EGEN, kortere liste (»{originalSubject}, {ticketTag}, {ticketId}«) — og derfor står den trykt der en gang til. »{ticketRef}« virker også der og betyder det samme som »{ticketTag}«. »{requesterName}«, »{ticketTitle}« og »{agentName}« virker ikke i emnet og bliver afvist på samme måde.

Kontakten »Send the comment as e-mail« gør kommentaren til mailen også. Der findes bevidst intet andet tekstfelt til det: det, der står i sagen, er det, kunden læser — to tekster ville før eller siden glide fra hinanden.

Under »Recipient« vælger du mellem »Requester«, »Assignee«, »Observers« og »Fixed address«. Hvem anmelderen er, bliver løst af serveren, når skabelonen anvendes — en skabelon kender endnu ikke sagen. Selve postkassekontoen bliver der aldrig skrevet til; det ville være en besked til os selv. Står der i feltet »User« et navn uden adresse, går der ingen mail til anmelderen. Den bliver heller ikke sendt til den, der registrerede sagen, i stedet.

Emnet må bære »{originalSubject}«, »{ticketTag}« og »{ticketId}«. Behold »{ticketTag}« derinde: den henvisning er det, systemet genkender kundens svar på og føjer til den samme sag. Uden den bliver hvert svar til en ny sag.

Mailen går ud som ren tekst. Fed skrift, lister og links bliver skåret væk før afsendelsen, ellers ville kunden læse den rå opmærkning. Inde i sagen beholder kommentaren sin formatering.

På sagen er mailen endnu en brik ved siden af handlingerne (»E-mail to Requester«) og kan fravælges præcis som de andre. Så en skabelon sender aldrig noget, uden at du har set det. Brikken dukker kun op, når teamets postkasse sender mails ved sagshandlinger.

En skabelons vedhæftede filer (»Attachments«) er dens egne kopier af filerne. At anvende skabelonen lægger dem på SAGEN, med deres egen række i historikken — de er ikke en del af mailen. At bære vedhæftede filer på en skabelon kræver ingen Professional-licens; kun afsendelsen gør. En skabelon med fluebenet »Internal note« tilføjer ingen filer.

De fleste skabeloner bliver ikke født ved et tegnebræt, men i det øjeblik, du skriver det samme svar for anden gang. Derfor bærer hver kommentar på en sag et lille arkikon til højre, med teksten »Make template«. Det tager præcis den kommentar som starttekst — også en kollegas kommentar. Kun den, der må styre skabeloner, ser ikonet.

Har sagen vedhæftede filer, spørger en dialog først, hvilke der skal med: »Tick only the attachments the template should carry — one of them may be a customer's screenshot. Nothing is ticked by default.« Der er intet afkrydset på forhånd, og det er med vilje.

Derefter lander du på skabelonsiden med et udkast, der IKKE er gemt endnu. Øverst sidder det ravgule banner »Draft from ticket #… — name it and review the text (it may contain customer details), then save.« Navnet er tomt: du skal give et, ellers bliver den ikke gemt.

Det, der bliver taget med: teksten, fluebenet »Internal note«, sagens team og sagens tilstand som forslag — dens status og dens prioritet ligger allerede der som to handlinger. Det, der ikke bliver taget med: anmelder, adresse og titel. De hører til denne ene sag.

Læs teksten, før du gemmer. Den kommer fra en rigtig sag og kan rumme et menneskes navn, et ordrenummer eller et lokale. Der bliver ikke anonymiseret noget for dig — banneret siger det, men at gøre det er din opgave.

Kun »Save« opretter skabelonen; de afkrydsede filer bliver så kopieret over og bekræftet med en besked.

»Applies to« bestemmer, hvem skabelonen bliver tilbudt: ét bestemt team eller »All teams«. En ny skabelon starter med et konkret team — »All teams« er et valg, nogen skal træffe, ikke et stiltiende udgangspunkt.

På en sag bliver du tilbudt ejerteamets skabeloner plus de globale. Flytter sagen til et andet team efter en overdragelse, flytter listen med — det nye teams skabeloner er dem, du kan vælge fra.

Kontakten »Draft« gør skabelonen til dit værksted: »Only you can see this template until you publish it.« En andens udkast dukker ikke op i nogen liste og kan heller ikke nås på sin adresse — heller ikke af administratorer. En ny skabelon starter som udkast; først når du slår det fra og gemmer, ser de andre den.

To skabeloner må ikke dele navn, hvis de kan mødes: en global støder sammen med enhver skabelon af samme navn, i ethvert team. En svarskabelon og en sagsskabelon må dog gerne dele navn — de står aldrig side om side i den samme liste.

»Duplicate« laver en kopi, og kopien er altid et udkast: »Duplicated. The copy is a draft only you can see.« Det er den bekvemme vej til en variant, uden at andre bliver tilbudt den halvfærdige udgave.

En sagsskabelon udfylder formularen »Create new ticket«. Den har ingen svartekst, ingen handlinger og ingen mail — i dette øjeblik findes der ingen sag at handle på. Formularen viser derfor andre felter end ved en svarskabelon, og den grønne ramme fortæller dig, at du ser på en sagsskabelon.

Du kan udfylde »Ticket title«, »Owning team of the new ticket«, »Main category«, »Subcategory«, »Priority« og »Ticket description« på forhånd. Hvert felt må gerne blive stående på »Not prefilled« — det, der bliver stående tomt, udfylder den senere, der bruger formularen.

Hold øje med forskellen på de to teamfelter: »Applies to« øverst siger, HVEM der ser skabelonen. »Owning team of the new ticket« siger, HVOR den nye sag går hen. Det er to forskellige spørgsmål, og de må gerne have forskellige svar.

Kategorierne er grupperet efter team, fordi en kategori hører til et team. Vælger du en fra et andet team, siger formularen til, og gemningen bliver afvist: på modtagerteamets formular til en ny sag ville den kategori slet ikke blive tilbudt, så udfyldningen ville ende i ingenting.

Der findes ingen pladsholdere her, og hjælpeteksten under teksten siger det: »No placeholders here: the template only prefills the form, nothing is resolved or sent.« Et »{requesterName}« ville ende bogstaveligt i den nye sag — og derfor bliver det afvist ved gemningen.

Den blå boks samler også her, hvad skabelonen gør: »Prefills the new ticket with title 'New notebook for a colleague' · category Notebook / New request · priority Medium · team Helpdesk · the description.«

På selve formularen vælger du skabelonen med knappen »Template«; ved siden af står »Prefills the form - nothing is created until you submit.« Alt det udfyldte kan stadig ændres, og der bliver ikke oprettet noget, før du sender.

Én eksempelskabelon følger med systemet: »Example: create accounts for a new colleague«. Den viser formen på tingen og gør intet af sig selv — byg den om, eller slet den.

Kontakten »Offer this template to customers« er slået fra som fabriksindstilling. Hjælpeteksten ved siden af siger begge de ting, du skal vide: »Customers can pick this template when they create a ticket. A draft stays hidden either way.«

Hvorfor den er slået fra som udgangspunkt: en skabelon er tit navngivet i internt sprog og skrevet til kolleger. At gøre den synlig for kunder er en udtalelse udadtil — det skal nogen gøre med vilje, ikke ved et uheld.

Kunden ser den samme »Template«-knap over formularen til en ny sag, men kun de frigivne skabeloner. Et udkast bliver skjult, også med kontakten slået til — de to regler sidder efter hinanden, ikke ved siden af hinanden.

Pointen er ikke bekvemmelighed, den er den første kontakt: en henvendelse, der kommer ind komplet, sparer den runde spørgsmål, der ellers ville koste to dage. Læg de spørgsmål ind i skabelonens beskrivelse — kunden svarer på dem, mens hun opretter sagen.

Du kan gå videre med »Fields to ask for«. Skabelonen bestemmer så, hvilke brugerdefinerede felter formularen spørger om, i hvilken rækkefølge, og hvilke af dem der er påkrævede. Det udvalg ERSTATTER teamets sædvanlige felter, det lægges ikke oveni. Det er præcis meningen med det. Brugerdefinerede felter er i sig selv en del af Professional; deres kort hedder »Brugerdefinerede felter«. At frigive en skabelon til kunder virker i hver udgave.

Et felt, der er skjult for kunder, bliver skjult, også hvis en skabelon nævner det. Feltudvalget er et værktøj til orden og til tilskæring, ikke en vej uden om feltindstillingerne.

Hver anvendelse, der gør mere end at indsætte tekst, skriver ÉN post i historikken, under feltnavnet »Template«. Den nævner skabelonen. De handlinger, der kørte, skriver deres egne rækker. Uden den ville der ikke være nogen måde at forklare bagefter, hvorfor en sag pludselig hoppede til »In Progress«: de enkelte handlinger skriver ganske vist deres egne rækker, men ingen af dem nævner skabelonen.

Billedet lyder: »Template 'First reply: we have your ticket' applied«. Hvad skabelonen gjorde, står i rækkerne for dens egne handlinger, for eksempel statusskiftet.

Fravalgte handlinger står ikke i den: de skete ikke. En fejl står i den, og den bliver nævnt som en, bag ordet »failed«. En ren tekstskabelon uden handlinger, mail eller vedhæftede filer efterlader ingen »Template«-post på en enkelt sag. Den har kun indsat tekst. Anvendt på flere sager på én gang bliver posten altid skrevet, sammen med den interne række »Bulk«.

Posten er INTERN — anmelderen ser den ikke. En skabelons navn er internt sprog (»standardafslag«), og historikken er også åben for sagens opretter. Selve feltændringerne bliver synlige for hende; kun deres oprindelse i en skabelon gør ikke.

Forfatteren er agenten, ikke »system« og ikke skabelonen. Det er med vilje: at anvende den var hendes beslutning. I modsætning til en automatiseringsregel står der her et menneske på sagen.