Predloge odgovorov in zahtevkov

Predloge so pod »Settings → Templates«. Vrstica pod naslovom pove, kaj počnejo in česa ne: »Reply templates fill the comment editor and suggest field actions. Nothing is sent automatically.« Predloga je pripravljena poteza in ne stroj — pošljete vedno sami.

Vrsti sta dve in eno izberete ob ustvarjanju: »Add reply template« za odgovor na odprtem zahtevku, »Add ticket template« za obrazec za nov zahtevek. Vrste pozneje ni mogoče spremeniti, ker določa, katera polja obrazec sploh pokaže. Oznaka nad vsako predlogo vam pove, katero gledate: modra »Reply template«, zelena »Ticket template«.

Predlogo odgovora sestavljajo besedilo odgovora (»Reply text«), potrditveno polje »Internal note« in poljubno število dejanj. Dejanj je šest: »Set the status«, »Set the priority«, »Assign to a user«, »Remove the assignee«, »Hand over to another team« in »Set a follow-up«.

Seznam »Assign to a user« se začne z vnosom »The agent who applies it«. Tega vzemite, kadar si predlogo deli več ljudi: zahtevek nato pripada tistemu, ki jo je uporabil, in ne eni stalni osebi s seznama. »Set a follow-up« vpraša po količini in enoti (minute, ure, dnevi, delovne minute, delovne ure, delovni dnevi) ter po zaznamku, ki vam bo pozneje povedal, zakaj je zahtevek nazaj.

Modri okvirček na koncu vsake predloge v enem stavku zapiše, kaj bo storila — na primer »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.« Stavek se med urejanjem sproti sestavlja znova. To je vaša protiproba: če pove kaj drugega, kot ste nameravali, je ena nastavitev napačna.

Besedilo ni obvezno. »To predaj omrežni ekipi, brez ene same besede« je veljavna predloga — stavek se takrat glasi »Suggests actions without a reply text«. Dejanje »Set the status« sledi istim pravilom kot ročna sprememba stanja. Uporabljena na več zahtevkih hkrati predloga preskoči zaklenjene zahtevke in navede razlog.

Okno »Close ticket« prav tako ponuja predloge odgovorov, v polju »Template«. Prikaže samo predloge, katerih aktivno dejanje »Set the status« nastavi stanje, ki velja za rešeno ali zaprto. Internih predlog tam ne ponuja. Če katero izberete, okno prevzame njeno besedilo kot komentar. Če predloga pošlje sporočilo in okno ponuja pošiljanje sporočila, prevzame prejemnika samo, če je to »Requester« ali stalen naslov. Druga dejanja in priloge predloge se tam ne uporabijo. Zahtevek se zapre kot običajno.

Na odprtem zahtevku je gumb »Template« nad urejevalnikom komentarja. Klik odpre iskanje s samodopolnjevanjem (»Search templates…«), izbira pa napolni urejevalnik komentarja. Nič drugega se ne zgodi, kar pove tudi vrstica spodaj: »Nothing happens until you add the comment.«

Vsako dejanje predloge postane oznaka poleg gumba — v razumljivih besedah, ne v žargonu: »sets status to Waiting for Service Provider Response«, »assigns to the applying agent«, »sets a follow-up in 3 days«. Klik na oznako jo prečrta: odznačena je in se ne bo izvedla. Nov klik jo vrne.

Odznačena dejanja so prečrtana, ne odstranjena. Tako ostane vidno, kaj bi predloga predlagala — in odločitev ostane preklicljiva, dokler niste poslali.

Katere oznake so na začetku dejavne, določa predloga: v nastavitvah vsako dejanje nosi stikalo »Suggested«. To stikalo je predlog za vsak primer; oznaka na zahtevku je odločitev za ta primer.

Znak »×« za oznakami predlogo spet odstrani. Besedilo ostane v urejevalniku — najbrž ste ga že prepisali; izgine samo učinek, torej dejanja, sporočilo in priloge.

Pošljete z običajnim gumbom za komentar. Šele takrat komentar nastane, in šele nato se izvedejo dejanja, ki so še dejavna.

Besedilo odgovora lahko uporablja pet označevalnikov; seznam je pod poljem: »{requesterName}, {ticketId}, {ticketTitle}, {ticketRef}, {agentName}«. Zapišite jih z zavitimi oklepaji, natanko tako, kot so navedeni tam.

»{ticketRef}« je sklic zahtevka v obliki »[TICKET-8-…]«. Po njem sistem prepozna odgovor stranke, ko se vrne po e-pošti. »{ticketId}« pa je samo gola številka.

Razrešijo se ob UPORABI predloge, ne ob shranjevanju: stran z nastavitvami še naprej kaže »{requesterName}«, urejevalnik komentarja na zahtevku pa resnično ime. Razlog je praktičen — razreševanje ob shranjevanju bi v predlogo za vedno vžgalo vrednosti ENEGA zahtevka.

Tako končno besedilo preberete, preden gre kar koli iz podjetja. Če nagovor ne ustreza, ga v urejevalniku spremenite kot vsako drugo besedilo.

Kdo velja za »vlagatelja«, določa zahtevek in ne račun: vlagatelj, zabeležen na zahtevku, ima prednost pred računom, ki ga je oddal. Če agent po telefonskem klicu odda zahtevek za sodelavca, odgovor vseeno pozdravi sodelavca in ne agenta.

Napačno zapisan označevalnik je ob shranjevanju zavrnjen in naveden: »Reply text: unknown placeholders {requesterNam}. Available here: {requesterName}, {ticketId}, {ticketTitle}, {ticketRef}, {agentName}.« Tako to opazite med pisanjem predloge in ne pri stranki.

Zadeva e-pošte ima SVOJ, krajši seznam (»{originalSubject}, {ticketTag}, {ticketId}«) — zato je tam izpisan še drugič. »{ticketRef}« tam prav tako deluje in pomeni isto kot »{ticketTag}«. »{requesterName}«, »{ticketTitle}« in »{agentName}« v zadevi ne delujejo in so prav tako zavrnjeni.

Stikalo »Send the comment as e-mail« komentar spremeni tudi v sporočilo. Drugega polja za besedilo namenoma ni: kar stoji v zahtevku, je tisto, kar bere stranka — dve besedili bi se prej ali slej razšli.

Pod »Recipient« izbirate med »Requester«, »Assignee«, »Observers« in »Fixed address«. Kdo je vlagatelj, razreši strežnik ob uporabi predloge — predloga zahtevka še ne pozna. Samemu računu poštnega nabiralnika se nikoli ne piše; to bi bilo sporočilo samim sebi. Če je v polju »User« ime brez naslova, vlagatelju ne gre nobeno sporočilo. Namesto njemu ga ne dobi niti tisti, ki je zahtevek zabeležil.

Zadeva lahko nosi »{originalSubject}«, »{ticketTag}« in »{ticketId}«. Obdržite »{ticketTag}«: po tem sklicu sistem prepozna odgovor stranke in ga pripne istemu zahtevku. Brez njega vsak odgovor postane nov zahtevek.

Sporočilo gre ven kot golo besedilo. Krepko, seznami in povezave se pred pošiljanjem odstranijo, sicer bi stranka brala samo kodo za oblikovanje. Znotraj zahtevka komentar svoje oblikovanje ohrani.

Na zahtevku je pošta še ena oznaka poleg dejanj (»E-mail to Requester«) in jo je mogoče odznačiti prav tako kot njih. Tako predloga nikoli ne pošlje ničesar, ne da bi to videli. Oznaka se pokaže samo, kadar nabiralnik ekipe pošilja sporočila ob dejanjih na zahtevku.

Priloge predloge (»Attachments«) so njeni lastni izvodi datotek. Uporaba predloge jih doda ZAHTEVKU, s svojo vrstico v zgodovini — del sporočila niso. Za priloge na predlogi licenca Professional ni potrebna; potrebna je samo za pošiljanje. Predloga s kljukico »Internal note« ne doda datotek.

Večina predlog se ne rodi za risalno desko, ampak v trenutku, ko isti odgovor pišete drugič. Zato ima vsak komentar na zahtevku na desni majhno ikono lista z oznako »Make template«. Ta vzame natanko ta komentar kot izhodiščno besedilo — tudi komentar sodelavca. Ikono vidijo samo tisti, ki smejo upravljati predloge.

Če ima zahtevek priloge, pogovorno okno najprej vpraša, katere naj gredo zraven: »Tick only the attachments the template should carry — one of them may be a customer’s screenshot. Nothing is ticked by default.« Nič ni vnaprej označeno, in to je namerno.

Nato pristanete na strani s predlogami z osnutkom, ki še NI shranjen. Na vrhu je oranžna pasica »Draft from ticket #… — name it and review the text (it may contain customer details), then save.« Ime je prazno: podati ga morate, sicer se ne shrani.

Kaj se prenese: besedilo, potrditveno polje »Internal note«, ekipa zahtevka in stanje zahtevka kot predlog — njegovo stanje in njegova prioriteta sta že tam kot dve dejanji. Kaj se ne prenese: vlagatelj, naslov in naziv. Ti pripadajo temu enemu primeru.

Besedilo preberite, preden shranite. Prihaja iz resničnega primera in lahko nosi ime osebe, številko naročila ali sobo. Nič ni anonimizirano namesto vas — pasica to pove, storiti pa morate sami.

Predlogo ustvari šele »Save«; označene priloge se nato prekopirajo in to potrdi sporočilo.

»Applies to« določa, komu je predloga ponujena: eni določeni ekipi ali »All teams«. Nova predloga se začne s konkretno ekipo — »All teams« je izbira, ki jo mora nekdo sprejeti, ne pa tiha privzeta vrednost.

Na zahtevku so vam ponujene predloge lastniške ekipe in globalne. Če zahtevek po predaji preide k drugi ekipi, se seznam premakne z njim — izbirate lahko med predlogami nove ekipe.

Stikalo »Draft« predlogo spremeni v vašo delavnico: »Only you can see this template until you publish it.« Tuj osnutek se ne pojavi v nobenem seznamu in tudi po naslovu ni dosegljiv — niti administratorjem. Nova predloga se začne kot osnutek; šele ko to izklopite in shranite, jo vidijo drugi.

Dve predlogi si ne smeta deliti imena, če se lahko srečata: globalna trči z vsako istoimensko predlogo v kateri koli ekipi. Predloga odgovora in predloga zahtevka pa si ime lahko delita — nikoli se ne pojavita druga ob drugi v istem seznamu.

»Duplicate« naredi kopijo, in kopija je vedno osnutek: »Duplicated. The copy is a draft only you can see.« To je udobna pot do različice, ne da bi bila komu drugemu ponujena napol dokončana.

Predloga zahtevka napolni obrazec »Create new ticket«. Nima besedila odgovora, nima dejanj in nima pošte — v tem trenutku ni zahtevka, na katerem bi se kaj izvedlo. Obrazec zato pokaže druga polja kot pri predlogi odgovora, zeleni okvir pa vam pove, da gledate predlogo zahtevka.

Vnaprej lahko izpolnite »Ticket title«, »Owning team of the new ticket«, »Main category«, »Subcategory«, »Priority« in »Ticket description«. Vsako polje lahko ostane »Not prefilled« — kar ostane prazno, pozneje izpolni tisti, ki obrazec uporabi.

Pazite na razliko med poljema za ekipo: »Applies to« zgoraj pove, KDO predlogo vidi. »Owning team of the new ticket« pove, KAM gre novi zahtevek. To sta dve različni vprašanji in lahko imata različna odgovora.

Kategorije so združene po ekipah, ker kategorija pripada ekipi. Če izberete kategorijo druge ekipe, vam obrazec to pove in shranjevanje je zavrnjeno: v obrazcu za nov zahtevek ciljne ekipe ta kategorija sploh ne bi bila ponujena, zato bi bilo vnaprejšnje izpolnjevanje brez učinka.

Označevalnikov tukaj ni, kar pove namig pod besedilom: »No placeholders here: the template only prefills the form, nothing is resolved or sent.« »{requesterName}« bi v novem zahtevku pristal dobesedno — zato je ob shranjevanju zavrnjen.

Modri okvirček tudi tukaj povzame, kaj predloga počne: »Prefills the new ticket with title ‘New notebook for a colleague’ · category Notebook / New request · priority Medium · team Helpdesk · the description.«

V samem obrazcu predlogo izberete z gumbom »Template«; poleg njega piše »Prefills the form - nothing is created until you submit.« Vse vnaprej izpolnjeno je še mogoče spremeniti, in dokler ne oddate, ne nastane nič.

S sistemom pride ena vzorčna predloga: »Example: create accounts for a new colleague«. Pokaže obliko stvari in sama po sebi ne počne ničesar — predelajte jo ali izbrišite.

Stikalo »Offer this template to customers« je v izhodišču izklopljeno. Namig poleg pove obe stvari, ki ju morate vedeti: »Customers can pick this template when they create a ticket. A draft stays hidden either way.«

Zakaj je privzeto izklopljeno: predloga je pogosto poimenovana v internem besednjaku in napisana za sodelavce. Narediti jo vidno strankam je izjava navzven — nekdo naj to stori namerno, ne po nesreči.

Stranka vidi isti gumb »Template« nad obrazcem za nov zahtevek, vendar samo sproščene predloge. Osnutek ostane skrit tudi z vklopljenim stikalom — pravili stojita ena za drugo, ne druga ob drugi.

Bistvo ni udobje, ampak prvi stik: zahtevek, ki prispe popoln, prihrani krog vprašanj, ki bi sicer stal dva dni. Ta vprašanja postavite v opis predloge — stranka nanje odgovori med ustvarjanjem zahtevka.

Z »Fields to ask for« lahko greste še dlje. Predloga takrat določi, katera polja po meri obrazec zahteva, v kakšnem vrstnem redu in katera od njih so obvezna. Ta izbor NADOMESTI običajna polja ekipe, ne doda se jim. Prav to je njegov namen. Polja po meri sama so del izdaje Professional; njihova kartica se imenuje »Custom fields«. Sprostitev predloge strankam deluje v vsaki izdaji.

Polje, ki je pred strankami skrito, ostane skrito, tudi če ga predloga navaja. Izbor polj je orodje za red in za zamejitev, ne pot mimo nastavitev polj.

Vsaka uporaba, ki naredi več kot le vstavi besedilo, zapiše EN vnos v zgodovino, pod imenom polja »Template«. Ta navede predlogo. Dejanja, ki so se izvedla, zapišejo svoje vrstice. Brez tega pozneje ne bi bilo mogoče pojasniti, zakaj je zahtevek nenadoma skočil na »In Progress«: posamezna dejanja sicer zapišejo svoje vrstice, nobeno od njih pa ne navede predloge.

Na sliki piše: »Template ‘First reply: we have your ticket’ applied«. Kaj je predloga storila, stoji v vrsticah njenih lastnih dejanj, na primer sprememba stanja.

Odznačenih dejanj v njem ni: niso se zgodila. Neuspeh je v njem in je tudi imenovan kot tak, za besedo »failed«. Čista besedilna predloga brez dejanj, pošte ali prilog na posameznem zahtevku ne pusti vnosa »Template«. Le vstavila je besedilo. Pri uporabi na več zahtevkih hkrati se vnos zapiše vedno, skupaj z interno vrstico »Bulk«.

Vnos je INTEREN — vlagatelj ga ne vidi. Ime predloge je interni besednjak (»standardna zavrnitev«), zgodovina pa je odprta tudi ustvarjalcu zahtevka. Spremembe polj same zanj ostanejo vidne; nevidno ostane samo, da izvirajo iz predloge.

Avtor je agent, ne »system« in ne predloga. To je namerno: uporaba je bila njegova odločitev. Za razliko od pravila avtomatizacije na zahtevku tukaj stoji človek.