Svars- och ärendemallar

Mallar ligger under ”Settings → Templates”. Raden under rubriken säger vad de gör och vad de inte gör: ”Reply templates fill the comment editor and suggest field actions. Nothing is sent automatically.” En mall är ett förberett drag, inte en maskin — du skickar alltid själv.

Det finns två sorter och du väljer en när du skapar den: ”Add reply template” för svaret på ett öppet ärende, ”Add ticket template” för formuläret för ett nytt ärende. Sorten går inte att ändra efteråt, eftersom den avgör vilka fält formuläret över huvud taget visar. Märkningen ovanför varje mall säger vilken du tittar på: blå ”Reply template”, grön ”Ticket template”.

En svarsmall består av svarstexten (”Reply text”), kryssrutan ”Internal note” och valfritt antal åtgärder. Det finns sex åtgärder: ”Set the status”, ”Set the priority”, ”Assign to a user”, ”Remove the assignee”, ”Hand over to another team” och ”Set a follow-up”.

Listan ”Assign to a user” börjar med posten ”The agent who applies it”. Ta den när flera personer delar mallen: ärendet tillhör då den som tillämpade den, inte en fast person ur listan. ”Set a follow-up” frågar efter ett antal och en enhet (minuter, timmar, dagar, arbetsminuter, arbetstimmar, arbetsdagar) plus anteckningen som senare talar om varför ärendet är tillbaka.

Den blå rutan i slutet av varje mall skriver ned i en mening vad den kommer att göra — till exempel ”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.” Meningen byggs om medan du redigerar. Den är din motkontroll: säger den något annat än du avsåg är en inställning fel.

Text är inte obligatoriskt. ”Lämna över det här till nätverksteamet utan att skriva ett ord” är en giltig mall — meningen lyder då ”Suggests actions without a reply text”. Åtgärden ”Set the status” följer samma regler som en statusändring för hand. Tillämpad på flera ärenden på en gång hoppar mallen över låsta ärenden och anger skälet.

Fönstret ”Close ticket” erbjuder också svarsmallar, i fältet ”Template”. Där visas bara mallar vars aktiva åtgärd ”Set the status” sätter en status som räknas som löst eller stängd. Interna mallar erbjuds inte där. Om du väljer en mall tar fönstret över dess text som kommentar. Om mallen skickar e-post och fönstret erbjuder e-postutskick tar det bara över mottagaren om den är ”Requester” eller en fast adress. Mallens övriga åtgärder och dess bilagor körs inte där. Ärendet stängs som vanligt.

På ett öppet ärende sitter knappen ”Template” ovanför kommentarsredigeraren. Ett klick öppnar sökningen med förslag (”Search templates…”), och att välja en fyller kommentarsredigeraren. Inget annat händer, och raden under säger det: ”Nothing happens until you add the comment.”

Varje åtgärd i mallen blir en etikett bredvid knappen — med rena ord, inte fackspråk: ”sets status to Waiting for Service Provider Response”, ”assigns to the applying agent”, ”sets a follow-up in 3 days”. Ett klick på en etikett stryker över den: den är bortvald och kommer inte att köras. Ett klick till tar tillbaka den.

Bortvalda åtgärder stryks över, de tas inte bort. Det håller synligt vad mallen skulle ha föreslagit — och det håller beslutet omvändbart så länge du inte har skickat.

Vilka etiketter som börjar aktiva bestäms av mallen: i inställningarna bär varje åtgärd ett reglage ”Suggested”. Det reglaget är förslaget för varje fall. Etiketten på ärendet är beslutet för det här.

Krysset bakom etiketterna tar bort mallen igen. Texten stannar i redigeraren — du har säkert redan skrivit om den. Bara verkan försvinner, alltså åtgärder, e-post och bilagor.

Du skickar med den vanliga kommentarsknappen. Först då skapas kommentaren, och först därefter körs åtgärderna som fortfarande är aktiva.

Svarstexten får använda fem platshållare. Listan står under fältet: ”{requesterName}, {ticketId}, {ticketTitle}, {ticketRef}, {agentName}”. Skriv dem med klammerparenteser, exakt som de står där.

”{ticketRef}” är ärendets referens i formen ”[TICKET-8-…]”. Det är så systemet känner igen en kunds svar när det kommer tillbaka via e-post. ”{ticketId}” är däremot bara det nakna numret.

De löses upp när mallen TILLÄMPAS, inte när den sparas: inställningssidan visar fortfarande ”{requesterName}”, kommentarsredigeraren på ärendet visar det verkliga namnet. Skälet är praktiskt — att lösa upp vid sparandet skulle bränna in värdena från ETT ärende i mallen för gott.

På så sätt läser du den färdiga texten innan något lämnar företaget. Passar inte tilltalet ändrar du det i redigeraren som vilken annan text som helst.

Vem som räknas som ”anmälare” avgörs av ärendet, inte av kontot: anmälaren som registrerats på ärendet går före kontot som lämnade in det. Registrerar en agent ett ärende åt en kollega efter ett telefonsamtal hälsar svaret ändå på kollegan och inte på agenten.

En felstavad platshållare avvisas när du sparar, och den namnges: ”Reply text: unknown placeholders {requesterNam}. Available here: {requesterName}, {ticketId}, {ticketTitle}, {ticketRef}, {agentName}.” Så märker du det medan du skriver mallen, inte på en kund.

E-postens ämnesrad har sin EGEN, kortare lista (”{originalSubject}, {ticketTag}, {ticketId}”) — därför står den utskriven där en andra gång. ”{ticketRef}” fungerar också där och betyder samma sak som ”{ticketTag}”. ”{requesterName}”, ”{ticketTitle}” och ”{agentName}” fungerar inte i ämnesraden och avvisas på samma sätt.

Reglaget ”Send the comment as e-mail” gör kommentaren till meddelandet också. Det finns medvetet inget andra textfält för det: det som står i ärendet är det kunden läser — två texter skulle förr eller senare glida isär.

Under ”Recipient” väljer du mellan ”Requester”, ”Assignee”, ”Observers” och ”Fixed address”. Vem anmälaren är löser servern upp när mallen tillämpas — en mall känner ännu inte ärendet. Till själva e-postinkorgens konto skrivs det aldrig. Det vore ett meddelande till oss själva. Innehåller fältet ”User” ett namn utan adress går inget meddelande till anmälaren. Det skickas inte heller till den som registrerade ärendet i stället.

Ämnesraden får bära ”{originalSubject}”, ”{ticketTag}” och ”{ticketId}”. Behåll ”{ticketTag}” där: den referensen är hur systemet känner igen kundens svar och lägger det på samma ärende. Utan den blir varje svar ett nytt ärende.

Meddelandet går ut som ren text. Fetstil, listor och länkar tas bort före sändning, annars skulle kunden läsa den råa märkningen. Inuti ärendet behåller kommentaren sin formatering.

På ärendet är e-posten ytterligare en etikett bredvid åtgärderna (”E-mail to Requester”) och lika bortvalbar som de. Så skickar en mall aldrig något utan att du har sett det. Etiketten visas bara när teamets brevlåda skickar meddelanden vid ärendeåtgärder.

En malls bilagor (”Attachments”) är dess egna kopior av filerna. Att tillämpa mallen lägger dem till ÄRENDET, med en egen rad i historiken — de ingår inte i meddelandet. Att bära bilagor på en mall kräver ingen Professional-licens. Bara att skicka gör det. En mall med bocken ”Internal note” lägger inte till några filer.

De flesta mallar föds inte vid ett ritbord utan i ögonblicket då du skriver samma svar för andra gången. Därför bär varje kommentar på ett ärende en liten arkikon till höger, märkt ”Make template”. Den tar precis den kommentaren som utgångstext — även en kollegas kommentar. Bara den som får förvalta mallar ser ikonen.

Har ärendet bilagor frågar en dialog först vilka som ska följa med: ”Tick only the attachments the template should carry — one of them may be a customer’s screenshot. Nothing is ticked by default.” Ingenting är förbockat, och det är med avsikt.

Därefter landar du på mallsidan med ett utkast som ÄNNU inte är sparat. Överst sitter den gula bannern ”Draft from ticket #… — name it and review the text (it may contain customer details), then save.” Namnet är tomt: du måste ge ett, annars sparas den inte.

Det som följer med: texten, kryssrutan ”Internal note”, ärendets team, och ärendets läge som ett förslag — dess status och dess prioritet ligger redan där som två åtgärder. Det som inte följer med: anmälare, adress och titel. De hör till det här enda fallet.

Läs texten innan du sparar. Den kommer från ett verkligt fall och kan innehålla ett personnamn, ett ordernummer eller ett rum. Ingenting anonymiseras åt dig — bannern säger det, men att göra det är ditt jobb.

Bara ”Save” skapar mallen. De ibockade bilagorna kopieras då över och bekräftas med ett meddelande.

”Applies to” bestämmer vem mallen erbjuds: ett bestämt team eller ”All teams”. En ny mall börjar med ett konkret team — ”All teams” är ett val någon måste göra, inte ett tyst standardvärde.

På ett ärende erbjuds du det ägande teamets mallar plus de globala. Flyttar ärendet till ett annat team efter ett överlämnande flyttar listan med — det nya teamets mallar är det du kan välja bland.

Reglaget ”Draft” gör mallen till din verkstad: ”Only you can see this template until you publish it.” Någon annans utkast visas i ingen lista och går inte heller att nå via sin adress — inte ens av administratörer. En ny mall börjar som ett utkast. Först när du stänger av det och sparar ser de andra den.

Två mallar får inte dela namn om de kan mötas: en global krockar med varje mall med samma namn, i vilket team som helst. En svarsmall och en ärendemall får dock dela namn — de visas aldrig bredvid varandra i samma lista.

”Duplicate” gör en kopia, och kopian är alltid ett utkast: ”Duplicated. The copy is a draft only you can see.” Det är den bekväma vägen till en variant utan att någon annan erbjuds den halvfärdiga versionen.

En ärendemall fyller formuläret ”Create new ticket”. Den har ingen svarstext, inga åtgärder och ingen e-post — i det ögonblicket finns inget ärende att verka på. Formuläret visar därför andra fält än för en svarsmall, och den gröna ramen säger dig att du tittar på en ärendemall.

Du kan förifylla ”Ticket title”, ”Owning team of the new ticket”, ”Main category”, ”Subcategory”, ”Priority” och ”Ticket description”. Varje fält får stå kvar på ”Not prefilled” — det som lämnas tomt fylls i senare av den som använder formuläret.

Se upp med skillnaden mellan de två teamfälten: ”Applies to” överst säger VEM som ser mallen. ”Owning team of the new ticket” säger VART det nya ärendet går. Det är två olika frågor, och de får ha olika svar.

Kategorierna är grupperade per team, eftersom en kategori hör till ett team. Väljer du en från ett annat team säger formuläret till och sparandet avvisas: på målteamets formulär för nytt ärende skulle den kategorin inte ens erbjudas, så förifyllningen skulle bli om intet.

Här finns inga platshållare, och tipset under texten säger det: ”No placeholders here: the template only prefills the form, nothing is resolved or sent.” Ett ”{requesterName}” skulle hamna bokstavligt i det nya ärendet — därför avvisas det vid sparandet.

Den blå rutan sammanfattar vad mallen gör även här: ”Prefills the new ticket with title ‘New notebook for a colleague’ · category Notebook / New request · priority Medium · team Helpdesk · the description.”

På själva formuläret väljer du mallen med knappen ”Template”. Bredvid står ”Prefills the form - nothing is created until you submit.” Allt som är förifyllt går fortfarande att ändra, och ingenting skapas förrän du skickar in.

En exempelmall följer med systemet: ”Example: create accounts for a new colleague”. Den visar sakens form och gör ingenting av sig själv — bygg om den eller radera den.

Reglaget ”Offer this template to customers” är av som standard. Tipset bredvid säger båda sakerna du behöver veta: ”Customers can pick this template when they create a ticket. A draft stays hidden either way.”

Varför det är av som standard: en mall är ofta namngiven på internt språk och skriven för kollegor. Att göra den synlig för kunder är ett besked utåt — någon bör göra det med avsikt, inte av misstag.

Kunden ser samma knapp ”Template” ovanför formuläret för ett nytt ärende, men bara de frisläppta mallarna. Ett utkast förblir dolt även med reglaget på — de två reglerna sitter efter varandra, inte bredvid varandra.

Poängen är inte bekvämlighet, utan den första kontakten: en förfrågan som kommer in komplett sparar frågerundan som annars skulle kosta två dagar. Lägg de frågorna i mallens beskrivning — kunden svarar på dem medan ärendet skapas.

Du kan gå längre med ”Fields to ask for”. Mallen bestämmer då vilka anpassade fält formuläret frågar efter, i vilken ordning, och vilka av dem som är obligatoriska. Det urvalet ERSÄTTER teamets vanliga fält, det läggs inte till dem. Det är precis dess syfte. Anpassade fält i sig ingår i Professional. Deras kort heter ”Custom fields”. Att frisläppa en mall för kunder fungerar i varje utgåva.

Ett fält som är dolt för kunder förblir dolt, även om en mall listar det. Fälturvalet är ett verktyg för ordning och för snitt, inte en väg runt fältinställningarna.

Varje användning som gör mer än att infoga text skriver EN post i historiken, under fältnamnet ”Template”. Den nämner mallen. De åtgärder som kördes skriver egna rader. Utan den fanns ingen väg att i efterhand förklara varför ett ärende plötsligt hoppade till ”In Progress”: de enskilda åtgärderna skriver visserligen egna rader, men ingen av dem nämner mallen.

Bilden lyder: ”Template ‘First reply: we have your ticket’ applied”. Vad mallen gjorde står i raderna för dess egna åtgärder, till exempel statusbytet.

Bortvalda åtgärder finns inte med: de hände inte. Ett misslyckande finns med, och det namnges som ett, bakom ordet ”failed”. En ren textmall utan åtgärder, e-post eller bilagor lämnar ingen post ”Template” på ett enskilt ärende. Den har bara infogat text. Tillämpad på flera ärenden på en gång skrivs posten alltid, tillsammans med den interna raden ”Bulk”.

Posten är INTERN — anmälaren ser den inte. En malls namn är internt språk (”standardavslag”), och historiken är öppen även för den som skapade ärendet. Fältändringarna själva förblir synliga för dem. Bara deras ursprung i en mall gör det inte.

Författaren är agenten, inte ”system” och inte mallen. Det är avsiktligt: att tillämpa den var deras beslut. Till skillnad från en automatiseringsregel står det en människa på ärendet här.