Шаблони за отговори и за заявки

Шаблоните живеят под „Settings → Templates“. Редът под заглавието казва какво правят и какво не: „Reply templates fill the comment editor and suggest field actions. Nothing is sent automatically.“ Шаблонът е подготвен ход, а не машина — изпращате винаги вие.

Има два вида и избирате един при създаването: „Add reply template“ за отговора в отворена заявка, „Add ticket template“ за формуляра за нова заявка. Видът не може да се променя по-късно, защото той решава кои полета изобщо показва формулярът. Знакът над всеки шаблон ви казва кой от двата гледате: син „Reply template“, зелен „Ticket template“.

Шаблонът за отговор е съставен от текста на отговора („Reply text“), отметката „Internal note“ и произволен брой действия. Действията са шест: „Set the status“, „Set the priority“, „Assign to a user“, „Remove the assignee“, „Hand over to another team“ и „Set a follow-up“.

Списъкът „Assign to a user“ започва със записа „The agent who applies it“. Вземете него, когато няколко души споделят шаблона: тогава заявката принадлежи на този, който го е приложил, а не на един постоянен човек от списъка. „Set a follow-up“ иска количество и единица (минути, часове, дни, работни минути, работни часове, работни дни) плюс бележката, която по-късно ще ви каже защо заявката се е върнала.

Синята кутия в края на всеки шаблон записва с едно изречение какво ще направи той — например „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.“ Изречението се пренаписва, докато редактирате. То е вашата насрещна проверка: ако казва нещо различно от това, което сте имали предвид, една настройка е грешна.

Текст не е задължителен. „Предай това на мрежовия екип, без да пишеш нито дума“ е валиден шаблон — тогава изречението гласи „Suggests actions without a reply text“. Действието „Set the status“ следва същите правила като ръчната смяна на статуса. Приложен към няколко заявки наведнъж, шаблонът пропуска заключените заявки и назовава причината.

Прозорецът „Close ticket“ също предлага шаблони за отговор, в полето „Template“. Той показва само шаблони, чието активно действие „Set the status“ задава статус, който се брои за решен или затворен. Вътрешните шаблони не се предлагат там. Ако изберете такъв, прозорецът взема текста му като коментар. Ако шаблонът изпраща имейл и прозорецът предлага изпращане на имейл, той взема получателя само ако това е „Requester“ или фиксиран адрес. Другите действия и прикачените файлове на шаблона не се изпълняват там. Заявката се затваря както обикновено.

В отворена заявка бутонът „Template“ стои над редактора на коментари. Щракването отваря търсенето с предсказване („Search templates…“), а изборът попълва редактора на коментари. Нищо друго не се случва и редът отдолу го казва: „Nothing happens until you add the comment.“

Всяко действие на шаблона става елемент до бутона — с прости думи, а не на жаргон: „sets status to Waiting for Service Provider Response“, „assigns to the applying agent“, „sets a follow-up in 3 days“. Щракването върху елемент го зачерква: той е размаркиран и няма да се изпълни. Ново щракване го връща.

Размаркираните действия се зачеркват, а не се премахват. Така остава видимо какво би предложил шаблонът — и решението остава обратимо, докато не сте изпратили.

Кои елементи започват активни, решава шаблонът: в настройките всяко действие носи превключвател „Suggested“. Този превключвател е предложението за всеки случай; елементът в заявката е решението за този случай.

„ד зад елементите премахва шаблона отново. Текстът остава в редактора — може вече да сте го пренаписали; изчезва само действието, тоест действията, имейлът и прикачените файлове.

Изпращате с обичайния бутон за коментар. Едва тогава се създава коментарът и едва след това се изпълняват действията, които още са активни.

Текстът на отговора може да използва пет запазени места; списъкът стои под полето: „{requesterName}, {ticketId}, {ticketTitle}, {ticketRef}, {agentName}“. Пишете ги с фигурни скоби, точно както се появяват там.

„{ticketRef}“ е означението на заявката във вида „[TICKET-8-…]“. По него системата разпознава отговора на клиента, когато се върне по имейл. „{ticketId}“ за разлика от него е само голият номер.

Те се разрешават при ПРИЛАГАНЕТО на шаблона, а не при запазването: страницата с настройки продължава да показва „{requesterName}“, а редакторът на коментари в заявката показва истинското име. Причината е практична — разрешаване при запазване би изпекло завинаги стойностите на ЕДНА заявка в шаблона.

Така прочитате готовия текст, преди нещо да напусне фирмата. Ако обръщението не подхожда, променяте го в редактора като всеки друг текст.

Кой се брои за „заявител“, решава заявката, а не профилът: записаният в заявката заявител има предимство пред профила, който я е подал. Ако оператор подаде заявка за колега след телефонен разговор, отговорът пак поздравява колегата, а не оператора.

Погрешно написано запазено място се отхвърля при запазването и се назовава: „Reply text: unknown placeholders {requesterNam}. Available here: {requesterName}, {ticketId}, {ticketTitle}, {ticketRef}, {agentName}.“ Така го забелязвате, докато пишете шаблона, а не при клиент.

Темата на имейла има СОБСТВЕН, по-кратък списък („{originalSubject}, {ticketTag}, {ticketId}“) — затова той е отпечатан там втори път. „{ticketRef}“ също работи там и означава същото като „{ticketTag}“. „{requesterName}“, „{ticketTitle}“ и „{agentName}“ не работят в темата и се отхвърлят също така.

Превключвателят „Send the comment as e-mail“ превръща коментара и в имейл. Нарочно няма второ текстово поле за това: каквото стои в заявката, това чете клиентът — два текста рано или късно биха се разминали.

Под „Recipient“ избирате между „Requester“, „Assignee“, „Observers“ и „Fixed address“. Кой е заявителят, се разрешава от сървъра при прилагането на шаблона — шаблонът още не познава заявката. На самия профил на входящата поща никога не се пише; това би било съобщение до самите нас. Ако полето „User“ съдържа име без адрес, до заявителя не излиза имейл. Той не се изпраща вместо това и на този, който е записал заявката.

Темата може да носи „{originalSubject}“, „{ticketTag}“ и „{ticketId}“. Запазете „{ticketTag}“ там: по това означение системата разпознава отговора на клиента и го добавя към същата заявка. Без него всеки отговор става нова заявка.

Имейлът излиза като обикновен текст. Удебеленото, списъците и връзките отпадат преди изпращането, иначе клиентът би прочел суровото форматиране. Вътре в заявката коментарът запазва форматирането си.

В заявката имейлът е още един елемент до действията („E-mail to Requester“) и може да се размаркира също като тях. Така шаблонът никога не изпраща нищо, без вие да сте го видели. Елементът се появява само когато пощенската кутия на екипа изпраща имейли при действия по заявка.

Прикачените файлове на шаблона („Attachments“) са негови собствени копия на файловете. Прилагането на шаблона ги добавя към ЗАЯВКАТА, със собствен ред в историята — те не са част от имейла. Носенето на прикачени файлове в шаблон не изисква лиценз Professional; само изпращането изисква. Шаблон с отметката „Internal note“ не добавя файлове.

Повечето шаблони не се раждат на чертожна дъска, а в мига, в който напишете същия отговор за втори път. Затова всеки коментар в заявка носи вдясно малка иконка с лист, наречена „Make template“. Тя взема точно този коментар като начален текст — и коментар на колега също. Иконката виждат само хората, които могат да управляват шаблони.

Ако заявката има прикачени файлове, първо диалог пита кои да дойдат с нея: „Tick only the attachments the template should carry — one of them may be a customer’s screenshot. Nothing is ticked by default.“ Нищо не е предварително отметнато и това е нарочно.

След това попадате на страницата с шаблони с чернова, която ОЩЕ не е запазена. Най-горе стои кехлибарената лента „Draft from ticket #… — name it and review the text (it may contain customer details), then save.“ Името е празно: трябва да дадете такова, иначе няма да се запази.

Какво се пренася: текстът, отметката „Internal note“, екипът на заявката и състоянието на заявката като предложение — нейният статус и нейният приоритет вече седят там като две действия. Какво не се пренася: заявител, адрес и заглавие. Те принадлежат на този един случай.

Прочетете текста, преди да запазите. Той идва от истински случай и може да съдържа име на човек, номер на поръчка или стая. Нищо не се анонимизира вместо вас — лентата го казва, но самото правене е ваша работа.

Едва „Save“ създава шаблона; тогава отметнатите прикачени файлове се копират и се потвърждават със съобщение.

„Applies to“ решава на кого се предлага шаблонът: на един определен екип или на „All teams“. Новият шаблон започва с конкретен екип — „All teams“ е избор, който някой трябва да направи, а не мълчалива настройка по подразбиране.

В една заявка ви се предлагат шаблоните на отговорния екип плюс общите. Ако заявката премине към друг екип след предаване, списъкът се премества с нея — избирате от шаблоните на новия екип.

Превключвателят „Draft“ превръща шаблона във вашата работилница: „Only you can see this template until you publish it.“ Чужда чернова не се появява в нито един списък и не може да се достигне и по адреса си — дори от администратори. Новият шаблон започва като чернова; едва когато го изключите и запазите, останалите го виждат.

Два шаблона не могат да носят едно и също име, ако могат да се срещнат: общ шаблон се сблъсква с всеки шаблон със същото име, във всеки екип. Шаблон за отговор и шаблон за заявка обаче могат да носят едно и също име — те никога не се появяват един до друг в един и същ списък.

„Duplicate“ прави копие, а копието винаги е чернова: „Duplicated. The copy is a draft only you can see.“ Това е удобният път към вариант, без на другите да се предлага полуготовата версия.

Шаблонът за заявка попълва формуляра „Create new ticket“. Той няма текст на отговор, няма действия и няма имейл — в този момент не съществува заявка, върху която да се действа. Затова формулярът показва други полета, отколкото при шаблон за отговор, а зелената рамка ви казва, че гледате шаблон за заявка.

Можете да попълните предварително „Ticket title“, „Owning team of the new ticket“, „Main category“, „Subcategory“, „Priority“ и „Ticket description“. Всяко поле може да остане „Not prefilled“ — каквото остане празно, се попълва по-късно от този, който използва формуляра.

Внимавайте за разликата между двете полета за екип: „Applies to“ най-горе казва КОЙ вижда шаблона. „Owning team of the new ticket“ казва КЪДЕ отива новата заявка. Това са два различни въпроса и те могат да имат различни отговори.

Категориите са групирани по екип, защото категорията принадлежи на екип. Ако изберете такава от друг екип, формулярът ви го казва и запазването се отказва: във формуляра за нова заявка на целевия екип тази категория изобщо не би се предлагала, така че предварителното попълване би останало без резултат.

Тук няма запазени места и указанието под текста го казва: „No placeholders here: the template only prefills the form, nothing is resolved or sent.“ Едно „{requesterName}“ би попаднало буквално в новата заявка — затова се отхвърля при запазването.

Синята кутия обобщава какво прави шаблонът и тук: „Prefills the new ticket with title ‘New notebook for a colleague’ · category Notebook / New request · priority Medium · team Helpdesk · the description.“

В самия формуляр избирате шаблона с бутона „Template“; до него стои „Prefills the form - nothing is created until you submit.“ Всичко предварително попълнено още може да се промени и нищо не се създава, докато не подадете.

Със системата идва един примерен шаблон: „Example: create accounts for a new colleague“. Той показва формата на нещата и сам по себе си не прави нищо — преправете го или го изтрийте.

Превключвателят „Offer this template to customers“ е изключен още от началото. Указанието до него казва и двете неща, които трябва да знаете: „Customers can pick this template when they create a ticket. A draft stays hidden either way.“

Защо е изключен по подразбиране: шаблонът често е кръстен на вътрешен език и е написан за колеги. Да го направите видим за клиентите е изявление навън — някой трябва да го направи нарочно, а не случайно.

Клиентът вижда същия бутон „Template“ над формуляра за нова заявка, но само освободените шаблони. Черновата остава скрита дори при включен превключвател — двете правила стоят едно зад друго, а не едно до друго.

Смисълът не е удобството, а първият контакт: искане, което пристига пълно, спестява кръга от въпроси, който иначе би струвал два дни. Сложете тези въпроси в описанието на шаблона — клиентът отговаря на тях, докато създава заявката.

Можете да отидете и по-далеч с „Fields to ask for“. Тогава шаблонът решава кои собствени полета изисква формулярът, в какъв ред и кои от тях са задължителни. Този избор ЗАМЕСТВА обичайните полета на екипа, а не се добавя към тях. Точно това е предназначението му. Самите собствени полета са част от Professional; тяхната карта се казва „Собствени полета“. Освобождаването на шаблон за клиенти работи във всяко издание.

Поле, което е скрито от клиентите, остава скрито, дори ако шаблонът го изброява. Изборът на полета е средство за ред и за отрязване, а не начин да се заобиколят настройките на полетата.

Всяко използване, което прави повече от вмъкване на текст, записва ЕДИН запис в историята, под името на полето „Template“. Той назовава шаблона. Изпълнените действия записват собствени редове. Без него по-късно нямаше да има начин да се обясни защо една заявка изведнъж е скочила на „In Progress“: отделните действия наистина пишат собствени редове, но нито един от тях не назовава шаблона.

Картинката гласи: „Template ‘First reply: we have your ticket’ applied“. Какво е направил шаблонът, стои в редовете на собствените му действия, като например смяната на статуса.

Размаркираните действия не са в него: те не са се случили. Неуспехът е в него и е назован като такъв, зад думата „failed“. Обикновен текстов шаблон без действия, имейл или прикачени файлове не оставя запис „Template“ в отделна заявка. Той само е вмъкнал текст. При прилагане към няколко заявки наведнъж записът се прави винаги, заедно с вътрешния ред „Bulk“.

Записът е ВЪТРЕШЕН — заявителят не го вижда. Името на шаблона е вътрешен език („стандартен отказ“), а историята е отворена и за създателя на заявката. Самите промени по полетата остават видими за него; само произходът им от шаблон — не.

Авторът е операторът, а не „системата“ и не шаблонът. Това е нарочно: прилагането е било негово решение. За разлика от правило за автоматизация, тук в заявката стои човек.