Szablony odpowiedzi i zgłoszeń

Szablony mieszkają pod „Settings → Templates”. Wiersz pod nagłówkiem mówi, co robią, a czego nie: „Reply templates fill the comment editor and suggest field actions. Nothing is sent automatically.” Szablon to przygotowany ruch, a nie maszyna. Wysyłasz zawsze sam.

Są dwa rodzaje i wybierasz jeden przy zakładaniu: „Add reply template” do odpowiedzi przy otwartym zgłoszeniu i „Add ticket template” do formularza nowego zgłoszenia. Rodzaju nie da się później zmienić, bo decyduje on o tym, jakie pola formularz w ogóle pokazuje. Etykieta nad każdym szablonem mówi, na który patrzysz: niebieska „Reply template”, zielona „Ticket template”.

Szablon odpowiedzi składa się z tekstu odpowiedzi („Reply text”), pola wyboru „Internal note” i dowolnej liczby działań. Działań jest sześć: „Set the status”, „Set the priority”, „Assign to a user”, „Remove the assignee”, „Hand over to another team” i „Set a follow-up”.

Lista „Assign to a user” zaczyna się wpisem „The agent who applies it”. Wybierz go, gdy szablon dzieli kilka osób: zgłoszenie należy wtedy do tego, kto go zastosował, a nie do jednej stałej osoby z listy. „Set a follow-up” pyta o liczbę i jednostkę (minuty, godziny, dni, minuty robocze, godziny robocze, dni robocze) oraz o notatkę, która powie Ci później, dlaczego zgłoszenie wróciło.

Niebieskie pole na końcu każdego szablonu zapisuje jednym zdaniem, co on zrobi, na przykład „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.” Zdanie buduje się na nowo, gdy edytujesz. To Twoja kontrola: jeśli mówi coś innego, niż zamierzałeś, jedno ustawienie jest błędne.

Tekst nie jest wymagany. „Przekaż to zespołowi sieciowemu bez pisania słowa” to poprawny szablon, a zdanie brzmi wtedy „Suggests actions without a reply text”. Działanie „Set the status” podlega tym samym zasadom co ręczna zmiana statusu. Zastosowany do kilku zgłoszeń naraz szablon pomija zablokowane zgłoszenia i podaje powód.

Okno „Close ticket” także oferuje szablony odpowiedzi, w polu „Template”. Pokazuje tylko szablony, których aktywne działanie „Set the status” ustawia status liczący się jako rozwiązany lub zamknięty. Szablony wewnętrzne nie są tam oferowane. Jeśli wybierzesz jeden z nich, okno przejmie jego tekst jako komentarz. Jeśli szablon wysyła wiadomość, a okno oferuje wysyłkę wiadomości, przejmie odbiorcę tylko wtedy, gdy jest nim „Requester” albo stały adres. Pozostałe działania i załączniki szablonu nie są tam wykonywane. Zgłoszenie zamyka się jak zwykle.

Przy otwartym zgłoszeniu przycisk „Template” stoi nad edytorem komentarza. Kliknięcie otwiera wyszukiwanie z podpowiedziami („Search templates…”), a wybór wypełnia edytor komentarza. Nic więcej się nie dzieje, i wiersz pod spodem tak mówi: „Nothing happens until you add the comment.”

Każde działanie szablonu staje się etykietą obok przycisku, zapisaną zwykłymi słowami, a nie żargonem: „sets status to Waiting for Service Provider Response”, „assigns to the applying agent”, „sets a follow-up in 3 days”. Kliknięcie etykiety przekreśla ją: jest odznaczona i nie zadziała. Kolejne kliknięcie ją przywraca.

Odznaczone działania są przekreślone, a nie usunięte. Dzięki temu widać dalej, co szablon podpowiadał, a decyzja da się cofnąć tak długo, jak długo nie wysłałeś.

To, które etykiety zaczynają jako aktywne, decyduje szablon: w ustawieniach każde działanie ma przełącznik „Suggested”. Ten przełącznik jest propozycją dla każdego przypadku, a etykieta przy zgłoszeniu jest decyzją dla tego jednego.

Znak „×” za etykietami usuwa szablon z powrotem. Tekst zostaje w edytorze, bo mogłeś go już przepisać. Znika tylko skutek, czyli działania, wiadomość i załączniki.

Wysyłasz zwykłym przyciskiem komentarza. Dopiero wtedy powstaje komentarz, a dopiero po nim wykonują się działania, które są jeszcze aktywne.

W tekście odpowiedzi można użyć pięciu zmiennych, a lista stoi pod polem: „{requesterName}, {ticketId}, {ticketTitle}, {ticketRef}, {agentName}”. Pisz je w nawiasach klamrowych, dokładnie tak, jak tam stoją.

„{ticketRef}” to oznaczenie zgłoszenia w postaci „[TICKET-8-…]”. Po nim system rozpoznaje odpowiedź klienta, gdy wraca ona pocztą. „{ticketId}” to za to sam numer.

Rozwiązywane są przy ZASTOSOWANIU szablonu, a nie przy zapisie: strona ustawień dalej pokazuje „{requesterName}”, a edytor komentarza przy zgłoszeniu pokazuje prawdziwe nazwisko. Powód jest praktyczny: rozwiązanie przy zapisie wypaliłoby w szablonie na stałe wartości JEDNEGO zgłoszenia.

Dzięki temu czytasz gotowy tekst, zanim cokolwiek wyjdzie z firmy. Jeśli powitanie nie pasuje, zmieniasz je w edytorze jak każdy inny tekst.

Kto liczy się jako „zgłaszający”, decyduje zgłoszenie, a nie konto: zgłaszający zapisany przy zgłoszeniu ma pierwszeństwo przed kontem, które je założyło. Jeśli agent zakłada zgłoszenie za kolegę po rozmowie telefonicznej, odpowiedź i tak wita kolegę, a nie agenta.

Błędnie wpisana zmienna zostaje odrzucona przy zapisie i nazwana: „Reply text: unknown placeholders {requesterNam}. Available here: {requesterName}, {ticketId}, {ticketTitle}, {ticketRef}, {agentName}.” Zauważysz to więc przy pisaniu szablonu, a nie na kliencie.

Temat wiadomości ma WŁASNĄ, krótszą listę („{originalSubject}, {ticketTag}, {ticketId}”) i dlatego jest ona wypisana tam drugi raz. „{ticketRef}” też tam działa i oznacza to samo co „{ticketTag}”. „{requesterName}”, „{ticketTitle}” i „{agentName}” nie działają w temacie i są tak samo odrzucane.

Przełącznik „Send the comment as e-mail” zamienia komentarz również w wiadomość. Celowo nie ma do tego drugiego pola tekstowego: klient czyta to, co stoi w zgłoszeniu, bo dwa teksty prędzej czy później by się rozjechały.

Pod „Recipient” wybierasz między „Requester”, „Assignee”, „Observers” i „Fixed address”. To, kto jest zgłaszającym, ustala serwer przy zastosowaniu szablonu, bo szablon nie zna jeszcze zgłoszenia. Do samego konta skrzynki pocztowej nigdy nie jest pisane, bo byłaby to wiadomość do nas samych. Jeśli pole „User” zawiera nazwę bez adresu, do zgłaszającego nie wychodzi żadna wiadomość. Nie trafia ona też zamiast tego do osoby, która przyjęła zgłoszenie.

Temat może nieść „{originalSubject}”, „{ticketTag}” i „{ticketId}”. Zostaw w nim „{ticketTag}”: po tym oznaczeniu system rozpoznaje odpowiedź klienta i dopisuje ją do tego samego zgłoszenia. Bez niego każda odpowiedź staje się nowym zgłoszeniem.

Wiadomość wychodzi jako czysty tekst. Pogrubienia, listy i odnośniki są usuwane przed wysyłką, bo inaczej klient czytałby surowy kod. W samym zgłoszeniu komentarz zachowuje formatowanie.

Przy zgłoszeniu wiadomość jest jeszcze jedną etykietą obok działań („E-mail to Requester”) i da się ją odznaczyć tak samo jak je. Dlatego szablon nigdy nie wysyła niczego, czego nie widziałeś. Etykieta pojawia się tylko wtedy, gdy skrzynka zespołu wysyła wiadomości przy działaniach na zgłoszeniu.

Załączniki szablonu („Attachments”) to jego własne kopie plików. Zastosowanie szablonu dodaje je do ZGŁOSZENIA, z własnym wierszem w historii. Nie są one częścią wiadomości. Trzymanie załączników przy szablonie nie wymaga licencji Professional, wymaga jej tylko wysyłka. Szablon z zaznaczeniem „Internal note” nie dodaje plików.

Większość szablonów nie rodzi się przy desce kreślarskiej, tylko w chwili, gdy piszesz tę samą odpowiedź drugi raz. Dlatego każdy komentarz przy zgłoszeniu niesie po prawej mały symbol kartki, opisany „Make template”. Bierze on dokładnie ten komentarz jako tekst wyjściowy, także komentarz kolegi. Symbol widzą tylko osoby, które mogą zarządzać szablonami.

Jeśli zgłoszenie ma załączniki, najpierw pyta okno, które mają pójść razem: „Tick only the attachments the template should carry — one of them may be a customer’s screenshot. Nothing is ticked by default.” Nic nie jest zaznaczone z góry i jest to zamierzone.

Potem lądujesz na stronie szablonów z wersją roboczą, która NIE jest jeszcze zapisana. Na górze stoi bursztynowy baner „Draft from ticket #… — name it and review the text (it may contain customer details), then save.” Nazwa jest pusta: musisz ją nadać, inaczej szablon się nie zapisze.

Co jest przenoszone: tekst, pole wyboru „Internal note”, zespół zgłoszenia i stan zgłoszenia jako podpowiedź, bo jego status i priorytet stoją już tam jako dwa działania. Czego nie ma: zgłaszającego, adresu i tytułu. To należy do tej jednej sprawy.

Przeczytaj tekst, zanim zapiszesz. Pochodzi on z prawdziwej sprawy i może zawierać czyjeś nazwisko, numer zamówienia albo salę. Nic nie jest za Ciebie anonimizowane. Baner o tym mówi, ale zrobienie tego należy do Ciebie.

Dopiero „Save” tworzy szablon, a zaznaczone załączniki są wtedy kopiowane i potwierdzane komunikatem.

„Applies to” decyduje, komu szablon jest oferowany: jednemu wybranemu zespołowi albo „All teams”. Nowy szablon zaczyna od konkretnego zespołu, bo „All teams” to wybór, który ktoś musi podjąć, a nie ciche ustawienie domyślne.

Przy zgłoszeniu oferowane są szablony zespołu prowadzącego oraz szablony globalne. Jeśli zgłoszenie po przekazaniu trafia do innego zespołu, lista idzie razem z nim i wybierasz spośród szablonów nowego zespołu.

Przełącznik „Draft” zamienia szablon w Twój warsztat: „Only you can see this template until you publish it.” Cudza wersja robocza nie pojawia się na żadnej liście i nie da się do niej dojść po adresie, nawet administratorom. Nowy szablon zaczyna jako wersja robocza. Dopiero gdy to wyłączysz i zapiszesz, zobaczą go inni.

Dwa szablony nie mogą nosić tej samej nazwy, jeśli mogą się spotkać: szablon globalny zderza się z każdym szablonem o tej samej nazwie, w każdym zespole. Szablon odpowiedzi i szablon zgłoszenia mogą jednak dzielić nazwę, bo nigdy nie stają obok siebie na tej samej liście.

„Duplicate” robi kopię, a kopia jest zawsze wersją roboczą: „Duplicated. The copy is a draft only you can see.” To wygodna droga do wariantu bez oferowania komukolwiek niedokończonej wersji.

Szablon zgłoszenia wypełnia formularz „Create new ticket”. Nie ma tekstu odpowiedzi, działań ani wiadomości, bo w tej chwili nie ma zgłoszenia, na którym cokolwiek mogłoby zadziałać. Formularz pokazuje więc inne pola niż przy szablonie odpowiedzi, a zielona ramka mówi, że patrzysz na szablon zgłoszenia.

Możesz wypełnić z góry „Ticket title”, „Owning team of the new ticket”, „Main category”, „Subcategory”, „Priority” i „Ticket description”. Każde pole może zostać na „Not prefilled”, a co zostanie puste, wypełni później ten, kto korzysta z formularza.

Uważaj na różnicę między dwoma polami zespołu: „Applies to” na górze mówi, KTO widzi szablon. „Owning team of the new ticket” mówi, DOKĄD trafia nowe zgłoszenie. To dwa różne pytania i mogą mieć różne odpowiedzi.

Kategorie są pogrupowane według zespołów, bo kategoria należy do zespołu. Jeśli wybierzesz kategorię z innego zespołu, formularz to zgłosi i odmówi zapisu: w formularzu nowego zgłoszenia zespołu docelowego ta kategoria nie byłaby w ogóle do wyboru, więc wypełnienie z góry spełzłoby na niczym.

Tutaj nie ma zmiennych i podpowiedź pod tekstem tak mówi: „No placeholders here: the template only prefills the form, nothing is resolved or sent.” Zapis „{requesterName}” trafiłby do nowego zgłoszenia dosłownie i dlatego jest odrzucany przy zapisie.

Niebieskie pole podsumowuje także tutaj, co robi szablon: „Prefills the new ticket with title ‘New notebook for a colleague’ · category Notebook / New request · priority Medium · team Helpdesk · the description.”

W samym formularzu wybierasz szablon przyciskiem „Template”, a obok stoi „Prefills the form - nothing is created until you submit.” Wszystko wypełnione z góry da się jeszcze zmienić, a nic nie powstaje, dopóki nie wyślesz.

Z systemem przychodzi jeden przykładowy szablon: „Example: create accounts for a new colleague”. Pokazuje on kształt takiej rzeczy i sam z siebie nic nie robi. Przebuduj go albo usuń.

Przełącznik „Offer this template to customers” jest fabrycznie wyłączony. Podpowiedź obok mówi obie rzeczy, które trzeba wiedzieć: „Customers can pick this template when they create a ticket. A draft stays hidden either way.”

Dlaczego jest domyślnie wyłączony: szablon często nosi nazwę w słownictwie wewnętrznym i jest pisany dla współpracowników. Pokazanie go klientom to wypowiedź na zewnątrz, a taką ktoś powinien wygłosić świadomie, a nie przypadkiem.

Klient widzi ten sam przycisk „Template” nad formularzem nowego zgłoszenia, ale tylko udostępnione szablony. Wersja robocza zostaje ukryta nawet przy włączonym przełączniku, bo obie zasady stoją jedna za drugą, a nie obok siebie.

Nie chodzi o wygodę, tylko o pierwszy kontakt: zgłoszenie, które przychodzi kompletne, oszczędza rundę pytań kosztującą inaczej dwa dni. Włóż te pytania do opisu szablonu, a klient odpowie na nie przy zakładaniu zgłoszenia.

Możesz pójść dalej z „Fields to ask for”. Szablon decyduje wtedy, o które pola własne pyta formularz, w jakiej kolejności i które z nich są wymagane. Ten wybór ZASTĘPUJE zwykłe pola zespołu, a nie dokłada się do nich. Dokładnie po to jest. Same pola własne należą do Professional, a ich karta nazywa się „Pola własne”. Udostępnianie szablonu klientom działa w każdej edycji.

Pole ukryte przed klientami zostaje ukryte, nawet jeśli szablon je wymienia. Wybór pól to narzędzie do porządku i do zawężenia, a nie droga obok ustawień pól.

Każde użycie, które robi coś więcej niż wstawienie tekstu, zapisuje JEDEN wpis w historii, pod nazwą pola „Template”. Nazywa on szablon. Działania, które się wykonały, zapisują własne wiersze. Bez niego nie dałoby się później wyjaśnić, dlaczego zgłoszenie nagle skoczyło na „In Progress”: pojedyncze działania zapisują własne wiersze, ale żaden z nich nie nazywa szablonu.

Na obrazku stoi: „Template ‘First reply: we have your ticket’ applied”. To, co zrobił szablon, stoi w wierszach jego własnych działań, takich jak zmiana statusu.

Odznaczonych działań w nim nie ma, bo się nie wydarzyły. Niepowodzenie jest w nim i jest nazwane niepowodzeniem, za słowem „failed”. Czysty szablon tekstowy bez działań, wiadomości i załączników nie zostawia przy pojedynczym zgłoszeniu wpisu „Template”. Wstawił tylko tekst. Przy zastosowaniu do kilku zgłoszeń naraz wpis jest zapisywany zawsze, razem z wewnętrznym wierszem „Bulk”.

Wpis jest WEWNĘTRZNY, zgłaszający go nie widzi. Nazwa szablonu to słownictwo wewnętrzne („standardowa odmowa”), a historia jest otwarta także dla twórcy zgłoszenia. Same zmiany pól zostają dla niego widoczne, tylko ich pochodzenie z szablonu już nie.

Autorem jest agent, a nie „system” i nie szablon. Jest to zamierzone: zastosowanie było jego decyzją. Inaczej niż przy regule automatyzacji, przy zgłoszeniu stoi tutaj człowiek.