Ръководство

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

Снимките на екрана са от версия 1.3.1. Нищо на показаните екрани не се е променило до версия 1.13.3. Единственото, което изглежда различно, е номерът на версията долу в страничната лента.

Персонализиране и администриране

Тук управлявате езиковите настройки на системата и прилагате логото и цветовете на вашата фирма. Задавате формата за дата и час и уведомявате всички за планирана поддръжка и аварии. Този блок обхваща и работите, които рядко се правят и тогава наистина са нужни: обновяване, архив, предупреждение, преди дискът да се напълни. Всичко тук е част от Basic, с изключение на изпращането на съобщението по имейл.

1

Включване на езици и собствен превод

Под „Settings → Language Settings“ избирате кои езици предлага вашата фирма. На избор са 30.

Английският е винаги включен и не може да се изключи. Той е езикът, към който системата се връща, когато един текст още няма превод.

След това всеки потребител избира в собственото си меню езика, на който работи, измежду включените от вас.

Преводите не идват с обновяване. Обновяването носи нови английски текстове; превода за тях осигурявате вие.

Това става на две стъпки. С „Export JSON“ изтегляте файл, който съдържа всеки английски текст до съществуващия ви превод.

Попълвате този файл със собствено темпо и го зареждате обратно с „Import JSON“. Празните полета се пропускат, съществуващите преводи се презаписват.

Запазени места като {count} трябва да оцелеят в превода. Запис, чиито запазени места се различават от английския текст, се отхвърля, и това важи и за едно допълнително запазено място. Тогава предишният превод остава активен. Английски се появява само ако не е имало превод. Системата ви казва кой запис е бил.

Картата „State of your language packs“ ви казва за всеки език докъде сте стигнали. Там се появява всеки език, който сте включили, дори без превод. Картата показва колко текста са преведени и назовава четири случая: остаряло, непреведено, неизвестно и завършено. „Unknown“ означава, че текстовете са били внесени, преди тази проверка да съществува. Следващото внасяне го изяснява.

„Остаряло“ е случаят, който има значение. Английският текст се е променил, вашият превод още стои и вече казва нещо друго.

Готови езикови пакети за всеки език има безплатно на нашата страница „Изтегляния“. Зареждате ги с „Import JSON“ също като собствения си файл. Можете и първо да редактирате файла, за да подобрите превод.

В приложението връзката „Download language packs“ в картата „Import translations“ води направо към тази страница.

Картата „Languages“ с езиците като бутони, английският е включен завинаги.
Червената рамка стои върху немския и върху „Save languages“. Английският носи отметката „Always active“.Отваряне на изображението в пълен размер
Картата „Export translations“ с избора на целеви език.
Първо изберете целевия език, после изтеглете. Файлът съдържа английския текст и съществуващия ви превод.Отваряне на изображението в пълен размер
Картата „Import translations“ с избрания файл.
След „Select file“ името на файла се появява до него. Само „Import JSON“ го зарежда.Отваряне на изображението в пълен размер
Картата „State of your language packs“ със състоянието на немския.
В този примерен свят немският пакет е пълен. Второто число расте с всяко обновяване, което носи нови текстове.Отваряне на изображението в пълен размер
2

Лого, иконка на сайта и цветове

Под „Settings → CI Settings“ задавате вашето лого, вашата иконка на сайта и три цвята.

Логото се появява в страничната лента под логото на системата. Препоръчват се 400 на 160 пиксела като PNG или SVG с прозрачен фон, най-много 2 MB. SVG файл, който съдържа скрипт, се отхвърля при качването. Ако качването не успее, съобщението назовава причината.

Иконката на сайта е малкото изображение в раздела на браузъра. Препоръчват се SVG или 64 на 64 пиксела.

Трите цвята са „Primary color“, „Accent color“ и „Background color“. Първият оцветява важните бутони, вторият иконките и акцентите, третият фона.

Системата сама изчислява цветовете на текста и на посочването, за да остане текстът четим. Вие подавате само трите основни цвята.

Празно поле означава, че важи вграденият цвят. Квадратчето до него тогава показва черно, защото не може да покаже „без цвят“. Бележката отдолу го казва.

Прегледът под полетата показва вашите цветове преди запазването. Само „Save“ ги прилага за всички.

„Restore defaults“ връща всичко обратно. Това премахва и каченото лого и иконката на сайта.

Картата „Colors“ с два зададени цвята и прегледа отдолу.
Червената рамка стои върху двата бутона за преглед. Те веднага показват въведените от вас цветове.Отваряне на изображението в пълен размер
Логото на фирмата в страничната лента, под логото на системата.
Червената рамка стои върху каченото лого. То се появява веднага и на всяка страница.Отваряне на изображението в пълен размер
3

Светло и тъмно, и изгледът на телефон

Системата идва в тъмен и в светъл вид. Превключвате в собственото си меню долу в страничната лента.

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

Същото меню съдържа вашата достъпност, снимката ви на профила, паролата ви и езика ви.

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

Няма отделно приложение. Адресът е същият както на компютъра и влизате по същия начин.

Личното меню със записите „Light mode“ и „Dark mode“.
Червената рамка стои върху „Light mode“. Отметката до него показва кой вид е активен.Отваряне на изображението в пълен размер
Списъкът със заявки в светлия вид.
Светлият вид е фабричната настройка.Отваряне на изображението в пълен размер
Същият списък със заявки в тъмния вид.
Същата страница, същите данни. Променя се само външният вид.Отваряне на изображението в пълен размер
Същата страница в тесен прозорец, като на телефон.
На телефон списъкът е подреден един под друг. Отваряте страничната лента с иконката горе вляво.Отваряне на изображението в пълен размер
4

Дати и часове така, както ги пишете вие

Преди да започнете: Администраторите и операторите могат да променят общите настройки. Всички останали четат датите така, както са зададени там.

Под „Settings → General Settings“ намирате картата „Date and time format“. Тя стои непосредствено след часовата зона.

Четири избора съставят начина, по който се пише една дата. „Date order“ е редът на ден, месец и година.

„Date separator“ е знакът между числата. Можете да изберете точка, наклонена черта или тире.

„Clock“ е часовникът: 24 часа или 12 часа с AM и PM. „Time separator“ е знакът между час и минута.

Под четирите полета виждате „This is how it looks“. То показва резултата, преди да щракнете върху „Save“.

Настройката важи за цялата инсталация. Тя не зависи от езика, нито от отделния потребител.

Това е нарочно. Една фирма пише датите по един начин и всеки колега чете същия начин на писане.

Фабричната настройка е ден, месец, година с точка и 24-часов часовник. Ако не промените нищо, нищо не се променя.

Избраният начин на писане важи навсякъде, където системата показва дата. Това включва заявката, списъците, напомнянето и отчетеното време.

Експортите не са засегнати. Те записват датата като 2026-08-22, защото програмите за електронни таблици четат тази форма надеждно.

Полетата, в които въвеждате дата, също следват настройката. Щракване върху полето отваря календар и след това избраната дата се появява във вашия начин на писане. Празното поле гласи „Pick a date“.

Повече за това в картата: Включване на езици и собствен превод

Картата „Date and time format“ с четирите избора и прегледа.
Червената рамка стои върху реда и върху прегледа. Примерите в изборите се променят заедно с избрания ред.Отваряне на изображението в пълен размер
Подробностите на заявката във фабричната настройка: ден, месец, година и 24-часов часовник.
Това е една заявка, докато нищо не е променено. Горе стоят моменти във времето, долу дните на отчетеното време.Отваряне на изображението в пълен размер
Същите подробности след превключване на месец, ден, година с 12-часов часовник.
Същата заявка след промяната. Отчетените дни следват настройката също както моментите над тях.Отваряне на изображението в пълен размер
5

Обявяване на поддръжка и аварии

Преди да започнете: Съобщението на страницата за вход е част от Basic. Изпращането му и като имейл е част от Professional.

Страницата „Maintenance and incident notices“ стои в страничната лента. Там пишете съобщение, което всички виждат.

Съобщението се появява на страницата за вход и навсякъде в системата. Така хората го четат, преди изобщо да влязат.

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

Съставяте текста чрез щракване. Първо щракнете върху полето, което искате да попълните. То получава червена рамка и всичко, което отметнете след това, влиза в него. Махнете отметката от градивен блок и той отново напуска текста.

„Title / Subject“ се показва най-горе в съобщението. „Body“ се показва под него. Ако изпратите съобщението като имейл, едното става тема, а другото — тяло.

Готови изречения са налице като градивни блокове. Собствени можете да добавите под „Text Modules“, а вашите системи и услуги под „Systems / Services“.

С „Calendar (add date)“ и „Time (add time)“ вмъквате дата и час. Така се обявява планирана поддръжка.

Превключвателят „Turn notification on/off“ най-горе включва и изключва съобщението отново. Включването му запазва заедно с това заглавието и текста. Съобщението остава, докато не го изключите. Ако съобщението вече е включено, промяна в текста влиза в сила едва със „Save“.

До него има втори вид съобщение. Ако превърнете заявка в групов инцидент, тя също се появява на страницата за вход и изчезва сама, щом заявката бъде решена. Този превключвател не важи за нея.

С „Send as E-Mail“ изпращате същия текст и до списък с адреси. Това е частта, която принадлежи на Professional.

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

Повече за това в картата: Груповият инцидент като лента и като бележка в автоматичния отговор

Картата с текстовите блокове и вашите собствени системи.
Червените рамки стоят върху двата реда за въвеждане: един за изречения, един за вашите собствени системи. В този примерен свят системите са имейл, файлов сървър и VPN.Отваряне на изображението в пълен размер
Заглавие и тяло с отметнати градивни блокове, полето „Body“ е активно.
Червената рамка стои върху активното поле и върху „Calendar (add date)“. Под полето пише кое е активно.Отваряне на изображението в пълен размер
Страницата за вход с включено съобщение, през цялата страница.
Така го чете клиентът, преди да влезе. „Dismiss“ скрива показаните в момента съобщения, докато страницата не бъде презаредена.Отваряне на изображението в пълен размер
Същият текст с отметнато „Send as E-Mail“ и списъка с получатели.
Червената рамка стои върху списъка с получатели и върху „Send Mail“. Разделяйте няколко адреса със запетая.Отваряне на изображението в пълен размер
6

Ранно предупреждение, преди дискът да се напълни

Системата следи дисковото пространство на сървъра и се обажда, преди то да свърши.

Има два етапа. От 90 процента използвано получавате съобщение, от 95 процента — предупреждение.

Който управлява обновяванията, вижда числата и какво да направи. Обикновено старите образи от предишни обновявания са най-голямото перо.

Всички останали влезли получават кратко изречение и насока към своя администратор. Те го виждат едва от етапа на предупреждението.

Нищо от това не се показва на страницата за вход. Колко пълен е дискът на сървъра, не е ничия работа преди влизането.

Пълният диск не засяга само обновяването. Прикачените файлове, входящата поща, базата данни и резервното копие живеят на един и същ диск.

Получавате съобщение и щом свободното място падне под 10 GB. Толкова място е нужно на едно обновяване и при по-малко то не започва.

След всяко успешно обновяване системата премахва образите на по-старите версии. Предишната версия остава за връщане назад.

Лентата със съобщението, че мястото намалява.
Първият етап. В този примерен свят са използвани 93 процента и са свободни 14 от 200 GB.Отваряне на изображението в пълен размер
Същата лента с текста на етапа на предупреждението.
Вторият етап при 96 процента. Сега текстът назовава и какво може да започне да се проваля.Отваряне на изображението в пълен размер
Същото събитие в прозореца на оператор: кратко изречение без числа.
Хората, които не могат да освободят място, не получават числа. Изречението назовава последицата и насочва към администратора.Отваряне на изображението в пълен размер
7

Обновяване с натискане на бутон

Под „Settings → Updates“ виждате коя версия работи и дали има по-нова.

Ако има нова версия, отдолу е изброено какво носи тя. Списъкът показва всяка версия, която прескачате.

Преди обновяването системата проверява дали има достатъчно свободно място. Едно обновяване се нуждае едновременно от стария и от новия образ, затова изисква 10 GB. Ако няма достатъчно, системата отказва обновяването и казва защо. Това е по-добра новина от това да се откаже по средата.

След това тя сама прави шифровано резервно копие. То обхваща базата данни, прикачените файлове, архивите и ключовете. Ако базата данни работи извън SMITEY, тя не е част от това резервно копие.

Ако резервното копие не успее, обновяването спира, преди да бъде променено каквото и да е. Базата данни извън SMITEY не задържа обновяването. Запазете я със собствени инструменти.

Системата пита, преди да започне. По време на обновяването тя е недостъпна за няколко минути, затова изберете спокойно време.

Ако нещо се обърка, системата се връща към предишната версия и продължава да работи.

Ако вашият сървър не може да достигне източника на обновявания, системата казва точно това. Тогава тя не твърди, че сте с най-новата версия.

Обновяване, което премества базата данни към нова версия, не се прилага с натискане на бутон. Системата ви казва, а бележките към изданието казват какво да направите.

Картата „Version status“, която съобщава, че системата е с най-новата версия.
Червената рамка стои върху съобщението. „Check now“ пита веднага, вместо да се чака следващата проверка.Отваряне на изображението в пълен размер
Същата карта с налична версия и нейните бележки към изданието.
Червената рамка стои върху „Install update“. Над него стои какво носи новата версия.Отваряне на изображението в пълен размер
Потвърждението, което се иска, преди обновяването да започне.
Въпросът назовава версията и казва, че първо се прави резервно копие.Отваряне на изображението в пълен размер
Същата карта, когато източникът на обновявания не може да бъде достигнат.
Червената рамка стои върху съобщението. Без отговор системата казва, че не знае.Отваряне на изображението в пълен размер
8

Архивиране на затворените заявки

Преди да започнете: „Delete from live DB“ премахва заявките окончателно от работещата база данни. Първо изтеглете архива и погледнете в него.

Под „Settings → Archive“ опаковате затворените заявки от даден период в един файл. Така работният набор остава малък.

Преместват се само затворените заявки. Решена заявка се присъединява едва когато бъде затворена. Това става само 24 часа след решаването ѝ. Отворена заявка от същия период остава там, където е.

„Preview“ ви казва предварително колко заявки обхваща периодът. То не записва нищо и не променя нищо.

„Create archive“ изгражда ZIP файл. Той съдържа заявките с техните коментари, историята им, собствените им полета и прикачените им файлове.

След това файлът стои в списъка отдолу, с период, брой и размер. Възможна е подпапка, ако искате да подреждате по година.

Едва тогава решавате дали заявките да напуснат работещата база данни. Това е отделна стъпка: „Delete from live DB“ в списъка „Existing archives“. Самото създаване на архива не променя нищо.

„Restore“ връща заявките от файла. Заявките, чийто номер вече съществува, се пропускат.

Възстановяването се нуждае от екипите и работните потоци, към които се отнася една заявка. След това системата съобщава колко заявки са се върнали и колко е пропуснала, защото вече са съществували. Тя назовава и пропуснатите участия на екипи и задачите без тяхната подзаявка. Други пропуски не се съобщават. Липсващ екип, категория, потребител или статус остава празен в заявката. Коментарите без техния потребител и стойностите на изтрити собствени полета се изпускат.

„Delete archive file“ изтрива само файла. Заявките в работещата база данни остават непокътнати.

Картата „Create archive“ с двете полета за дата.
Червената рамка стои върху периода. Подпапката е по избор.Отваряне на изображението в пълен размер
Същата карта с резултата от прегледа.
Червената рамка стои върху „Preview“. Числото до него брои затворените заявки за избрания период. Прегледът не променя нищо.Отваряне на изображението в пълен размер
Списъкът с архиви с период, брой, прикачени файлове и размер.
Червената рамка стои върху двете действия, които засягат работещите данни.Отваряне на изображението в пълен размер
Въпросът, който се задава, преди заявките да напуснат работещата база данни.
Въпросът казва, че тази стъпка не може да бъде отменена.Отваряне на изображението в пълен размер
9

Попълване на падащите списъци от файл

Под „Settings → General Settings“ намирате падащите списъци на системата. Всеки списък има собствен раздел.

За отдели, длъжности и местоположения има и път през файл. Той се изплаща, когато добавяте много записи наведнъж.

„Export JSON“ изтегля списъка. При нова инсталация това ви дава празната структура, в която да впишете записите си.

Файлът съдържа пример, който показва как изглежда един запис. Той се пропуска, когато заредите файла обратно.

„Import JSON“ създава липсващото. Съществуващите записи остават непокътнати. Име, което се появява два пъти във файла, се създава веднъж.

Преименуването не става през файла. Полетата на тази страница са за това и червената бележка го казва. Запазеното място „None selected or available“ не може да бъде преименувано. Само го превеждате, на страницата за езици.

Записите превеждате след това на езиковата страница. Файлът съдържа английското име.

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

Повече за това в картата: Основните и подкатегориите се настройват свободно за всеки екип

Разделът „Department“ с бутоните за износ и внасяне.
Червената рамка стои върху двата бутона. Червеното изречение над тях предупреждава да не се преименува през файла.Отваряне на изображението в пълен размер
Изтегленият файл в браузъра, с примера и записите.
Освен кратка заглавна част и примера, файлът съдържа само имена. Затова всеки текстов редактор може да го редактира.Отваряне на изображението в пълен размер

Екипи и потребители

Един екип е отговорност, а не папка. Той има собствени категории, собствени срокове и собствени членове. Клиентът вижда точно един от тях. Всичко останало опира до това кой какъв профил има и какво може този профил.

1

Създаване и настройване на екипи

Екипите живеят под „Settings → Teams“. Списъкът е отляво, настройките на екипа, върху който сте щракнали, са отдясно. Числото след името е броят на членовете му.

Новият екип получава името си в полето „Team name“. Под него „Copy categories from“ ви позволява да изберете съществуващ екип, така че новият да започне със същите основни и подкатегории. „Create team“ го създава.

Първият екип е екипът, който виждат вашите клиенти. Всеки следващ екип е специализиран екип зад него. Да се иска от подателя сам да избере правилния отдел, е прекалено: той подава при първия екип и оттам се предава нататък.

Можете да промените това по всяко време. Картата „Customer permissions“ решава за всеки екип какво могат да правят клиентите там. Тя има два превключвателя: „Can create new tickets and see their own tickets“ и „Can see their own tickets of this team in the dashboard and in reports“. Щом един от тях е включен, клиентите виждат екипа. Само когато и двата са изключени, екипът изобщо не се показва на клиент.

Картата „Agent Permissions“ важи за операторите на този екип. Тя има три превключвателя: управление на заявки, управление на категории и преглед на отчетите на този екип. Без първия операторът не може в този екип нито да създава, редактира или коментира заявки, нито да качва прикачени файлове. Без втория записът за категориите на екипа изчезва от страничната му лента. Без третия отчетите пропускат този екип. Всяка промяна се записва в „Audit log“ на екипа.

Картата „Agents“ съдържа членовете. Въпреки заглавието, в нея са и клиентите на екипа. Изборът над нея и „Add Agent“ добавят някого, „Remove“ го изважда. Който бъде добавен или изваден, трябва веднъж да излезе и да влезе отново.

„Default e-mail language“ е езикът, на който пише този екип. Той важи, когато правило за поща избере „Team default language“.

Превключвателят „Active“ изважда екипа от употреба. Той изчезва от страничната лента и от всеки избор. С това не се изтрива.

„Delete“ премахва екип само докато няма още отворена заявка. Иначе системата назовава причината и не прави нищо.

Картата „Audit log“ записва всяка промяна по екипа, с име и час.

Basic работи с един екип. Professional няма ограничение.

Страницата „Teams“ със списъка на двата екипа отляво и настройките на Helpdesk отдясно.
Червените рамки стоят върху двата екипа. Щракването върху един променя това, което стои отдясно. Числото в края е броят на членовете.Отваряне на изображението в пълен размер
Полето „Team name“ с въведено име, под него „Copy categories from“ и бутонът „Create team“.
Въведете името, по желание поемете категориите на съществуващ екип, после „Create team“.Отваряне на изображението в пълен размер
Картите „Customer permissions“ и „Agent Permissions“ с техните превключватели.
Червените рамки стоят върху двете заглавия. Тези превключватели важат само за този един екип.Отваряне на изображението в пълен размер
Картата „Agents“ с избора, бутона „Add Agent“ и членовете отдолу.
Червената рамка стои върху „Add Agent“. Отличителният знак до всяко име е ролята, а картата съдържа и клиентите на екипа.Отваряне на изображението в пълен размер
Картата „Audit log“ с нейните записи, всеки с промяната, името и часа.
Червената рамка стои върху заглавието. Всеки ред назовава промяната, кой я е направил и кога.Отваряне на изображението в пълен размер
2

Създаване на администратори и оператори

Профилите живеят под „User management“. Списъкът показва име и име за вход, имейл адреса, екипа с отдела под него и ролята.

„New user“ отваря формуляра. Име, фамилия, име за вход и имейл адрес са задължителни. Освен това идва парола. С Professional вместо нея можете да поставите отметката „Send login details by e-mail“.

С тази отметка не задавате парола. Новият потребител получава писмо с името си за вход и времево ограничена връзка и сам си задава паролата. Системата никога не изпраща пароли.

Ролята решава всичко останало. „Admin“ и „Agent“ са и двете вътрешни и се броят от един и същ пул. Администраторът може повече още от самото начало. Почти всяко отделно право може да се промени; изключенията са на картата „Роли и концепцията за правата“. Само администратор може да дава или отнема ролята „Admin“. Това важи и за собствения му профил. „Edit user“ променя само екипа, показан във формуляра. Екипите, към които човекът е добавен с „Add Agent“, остават както са.

Basic идва с две вътрешни места. Как ги разпределяте, зависи от вас: един администратор и един оператор или двама администратори. Клиентите не се броят, те са неограничени и в двете издания.

Когато някой напусне, щракнете върху символа за архивиране в неговия ред. Профилът се заключва, така че той вече не може да влиза.

Заключеният профил преминава в изгледа „Archived“ и носи там отличителния знак „locked“. Той вече не се вижда в изгледа „Active“.

Заключеният профил вече не заема вътрешно място и не се появява в нито един избор „Assign to“. Вече възложените заявки запазват своя оператор и името му.

В изгледа „Archived“ същият бутон се казва „Restore“ и освобождава профила отново. В Basic за това пак е нужно свободно място.

Символът ключ нулира парола. Зачеркнатият щит нулира двуфакторния вход. Новата парола се показва тогава веднъж на екрана. Тя не се изпраща никъде.

Нулирането на паролата или на двуфакторния вход само вдига краткото заключване след неуспешни опити. Архивираният профил остава заключен. Той не получава нито покана, нито имейл за нулиране и само „Restore“ го връща обратно.

Архивирането може да се отмени по всяко време. Ако някой е напуснал окончателно, изтрийте допълнително профила със символа на кошче „Delete account“. Времето до автоматичното анонимизиране тече едва от изтриването.

Повече за това в картата: Анонимизиране на хора

Страницата „User management“ с всички профили, тяхната роля и действията във всеки ред.
Червените рамки стоят върху „New user“ и върху превключването между отворени и заключени профили. Бутонът показва кой от двата изгледа е отворен.Отваряне на изображението в пълен размер
Диалогът „Create new user“ с попълнени имена, потребителско име и имейл и изборите за екип, отдел, длъжност, местоположение и роля.
Червените рамки стоят върху ролята и върху поканата. Ролята е единственият избор, който трябва да се попълни.Отваряне на изображението в пълен размер
Същият диалог с поставена отметка: полето за парола е изключено и казва, че потребителят я задава през връзката.
С отметката звездичката на полето за парола изчезва. Самото поле казва кой задава паролата.Отваряне на изображението в пълен размер
Изгледът „Archived“ със заключен профил, отличителния знак „locked“ и иконата за възстановяване в края на реда.
Червените рамки стоят върху знака и върху пътя назад. И двете съществуват само в този изглед.Отваряне на изображението в пълен размер
3

Клиенти: профилите на хората, които съобщават

Клиентите са неограничени и в Basic, и в Professional. Те не заемат вътрешно място.

Клиентският профил възниква по три начина. Създавате го сами под „User management“; с Professional при това можете да поканите човека по поща. Вторият начин е самостоятелната регистрация. Третият е първото влизане през SSO или през директория, което създава профила само.

Превключвателят за това стои под „Settings → Security“ в картата „Self-registration“. Той е изключен още от началото. Включен, на страницата за вход се появява връзка „Register“.

Който се регистрира сам, винаги получава ролята „Customer“. По този път не може да се раздаде друга роля.

С Professional самостоятелно регистрираният клиент получава втори имейл след приветствието. С връзката в него той потвърждава адреса си. Дотогава профилът му носи бележката „not confirmed“ в списъка.

Можете да потвърдите адрес и сами. В Basic това е единственият начин, защото Basic не изпраща поща. Тогава редът на профила показва бутон с икона на плик: „Mark email as confirmed“. Правете това само ако знаете, че адресът принадлежи на човека.

За вътрешна служба за поддръжка е по-добре да оставите превключвателя на мира. Иначе всеки, който знае адреса, си създава профил.

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

Ако адресът му още не е потвърден, над списъка му със заявки стои известие. С „Send confirmation email“ той заявява връзката отново. Известието се появява само ако системата може да изпраща поща.

Страничната му лента е кратка: неговите заявки, нова заявка, базата знания. Той никога не вижда никакви настройки. Ако превключвателят на екипа „Can see their own tickets of this team in the dashboard and in reports“ е включен, страничната му лента съдържа също таблото и отчетите.

Какво може той в един екип, се задава на екипа. Само когато и двата клиентски превключвателя са изключени, този екип не съществува за него.

Картата „Self-registration“ с превключвателя и бележката под него.
Червената рамка стои върху превключвателя. Текстът до него казва какво прави той и какво се случва без изпращане на поща.Отваряне на изображението в пълен размер
Същата система, влезли като клиент: кратка странична лента и списък със заявки, съдържащ само нейните собствени случаи.
Колоната „User“ съдържа едно и също име във всеки ред. Клиентът не вижда нищо, което не е негово, а настройките липсват от страничната лента.Отваряне на изображението в пълен размер
4

Експорт на данните на един човек

Преди да започнете: Нужно ви е правото „Data export (data subject request)“. По подразбиране го имат само администраторите.

Човек може да ви попита какви данни пазите за него. Експортът на данни ги събира всичките в един ZIP файл.

Стартирате го в „User management“. Всеки ред има символ на файл със стрелка и подсказка „Export personal data“. Той отваря експорта за този профил.

Някои хора нямат профил. Те само са ви писали или оператор е създал заявка с техния адрес. За тях в горната част на страницата има „Export by e-mail address“. Въведете там адреса и щракнете върху „Search“. Търсенето работи с профил или адрес, никога с име.

Търсенето по адрес намира по-малко от търсенето по профил. То намира само местата, където е записан самият адрес, например като заявител на заявка или като подател на имейл. Търсенето по профил намира освен това всичко, което е свързано с профила. Ако адресът принадлежи на профил, диалогът казва това и предлага „Use this account“. След това показва името на човека и имейл адреса на профила.

Преди да изтеглите нещо, диалогът показва какво е намерил, преброено по области. Области са например заявките, записите за време, анкетите за удовлетвореност и дневника за сигурността. Ако не намери нищо, показва „No data found for this person.“ и не предлага изтегляне. Ако адресът принадлежи на профил и сам няма намерени данни, диалогът не показва намерени данни и не предлага изтегляне. Той показва полето с „Use this account“. Администраторите виждат под него и областта „Anonymize“. Тя е обяснена в картата „Анонимизиране на хора“.

„Download“ създава ZIP файла. В него има по един JSON файл за всяка област, за да могат данните да се четат машинно. Към тях се добавят файловете на всички намерени прикачени файлове. „overview.html“ показва основното съдържание в четим вид. Там при всяка заявка пише защо е включена („Why this ticket is included“). „README.txt“ е написан за човека и обяснява какво съдържа файлът.

Заявка, която засяга човека, се включва изцяло. Към нея спадат и коментарите и промените на други хора. Вътрешните бележки също са включени и са отбелязани като вътрешни. Ако човекът е отговорил по имейл на чужда заявка, тази заявка носи знака „Replied by e-mail to someone else’s ticket“. Включва се и заявка, в която човекът е направил последната промяна. На реда „Why this ticket is included“ тогава стои „Last person to change the ticket“.

Затова проверете експорта, преди да го предадете. Зачертайте данните на други хора, където е нужно. Диалогът ви напомня за това. „README.txt“ не съдържа това напомняне, защото отива при човека.

Заявките, преместени в архив, не се претърсват. Проверете архивите си отделно. И за това диалогът ви напомня.

Паролите и ключовете за двуфакторно влизане не са част от експорта.

Всяко изтегляне се записва: кой го е стартирал, за кой човек и кога. Записът не съдържа нищо от съдържанието на експорта. Търсенето преди това не се записва.

Оператор, който получи правото, има нужда и от „Users: manage accounts“. Иначе той не стига до страницата „User management“. Правото никога не може да бъде дадено на ролята „Customer“.

Областта „Survey consents and unsubscribes“ съдържа всяко съгласие и всяко отписване за проучването за удовлетвореност с дата, канал и заявка. „overview.html“ показва пълната история в отделен раздел. Ако лицето е анонимизирано след отписване, експортът по неговия адрес намира оставащото отписване. Колоната „E-mail address“ тогава съдържа „Anonymized (address removed)“.

Повече за това в картата: Анонимизиране на хора

Страницата „User management“ с бутона „Export by e-mail address“ горе и символа на файл със стрелка във всеки ред.
Червените рамки стоят върху „Export by e-mail address“ и върху символа в реда на Julia Becker. И двете отварят един и същ диалог.Отваряне на изображението в пълен размер
Диалогът „Export personal data“ за Julia Becker с нейния имейл адрес под името, списъка на намереното по области, двете напомняния за проверка и архиви, областта „Anonymize“ и бутона „Download“.
Червените рамки стоят върху списъка на намереното и върху „Download“. Списъкът назовава само областите, в които е намерено нещо.Отваряне на изображението в пълен размер
Същият диалог след търсене по адрес: назовава профила, на който принадлежи адресът, и предлага „Use this account“.
Червената рамка стои върху „Use this account“. Само по адреса търсенето тук не намира нищо. Затова диалогът не показва намерени данни и няма „Download“. Експортът за профила намира заявките на Julia Becker. Областта „Anonymize“ под него виждат само администраторите.Отваряне на изображението в пълен размер
5

Анонимизиране на хора

Преди да започнете: Само администратор може да анонимизира човек. Анонимизирането не може да се отмени.

Някои данни не бива да остават завинаги. Когато някой напусне фирмата ви или човек поиска да изтриете данните му, вие го анонимизирате. Името и имейл адресът тогава се заменят със запазено място, например „Anonymized user 3“. Заявките остават. Отчетите, сроковете, записите за време и стойностите на удовлетвореност продължават да се отчитат.

Всеки човек получава собствен номер. Два записа с един и същ номер идват от един и същ човек. Имейл адресът става „anonymized-3@anonymized.invalid“. На такъв адрес не може да се достави писмо, затова системата го пропуска при изпращане. Запазеното място се съхранява на английски и остава на английски на всички езици.

Има два пътя. Автоматичният път анонимизира изтрити профили след зададен брой месеци. Незабавният път анонимизира един човек веднага, например след искане за изтриване.

Автоматичният път се намира в „Settings → Security“, в картата „Data protection“. Превключвателят „Anonymize deleted users automatically“ по подразбиране е изключен. До „after“ въвеждате броя месеци. Разрешено е от 1 до 120, стойността по подразбиране е 36. „Save“ запазва променения брой.

Времето се брои от деня, в който профилът е изтрит. Системата проверява на всеки десет минути дали е ред на изпълнение. То се извършва веднъж на ден, при първата проверка след 03:00 в часовата зона, зададена в „Settings → General Settings“. При това изпълнение се анонимизира всеки изтрит профил, чието време е изтекло.

Когато включите превключвателя, първо се отваря прозорец. Той изброява изтритите потребители, които следващото изпълнение ще анонимизира, всеки с деня на изтриването. Въведете ANONYMIZE в полето и щракнете върху „Confirm“. Едва тогава превключвателят е включен. Ако в тази часова зона вече е след 03:00, първото изпълнение следва до около десет минути.

Същият прозорец се появява, когато скъсите броя месеци при включен превключвател. За изключване не е нужно потвърждение.

Времето започва едва когато профилът бъде изтрит. Архивирането не е достатъчно. Архивираният профил е само заключен и може да се върне по всяко време, например след родителски отпуск. За да изтриете профил, щракнете върху символа на кошче „Delete account“ в неговия ред в „User management“.

Прозорец казва предварително какво следва. Ако автоматичното анонимизиране е включено, той посочва броя месеци. Изтритият профил се показва в изгледа „Archived“ с етикета „Deleted“. Символът „Restore account“ го връща. За администратори и оператори Basic се нуждае за това от свободно място. Ако профилът по-късно бъде изтрит отново, времето започва отначало.

Собственият ви профил няма символ на кошче. Администраторски профил може да изтрие или архивира само администратор. Последният активен администратор не може нито да бъде изтрит, нито архивиран.

Затова, когато някой е напуснал окончателно, изтрийте профила, а не само го архивирайте. Профил, който е архивиран от повече от година, показва в реда си символ на календар. Подсказката му ви напомня да изтриете профила.

Незабавният път е в диалога на експорта на данни, в областта „Anonymize“ под намерените данни. Отваряте диалога от реда на профила или чрез „Export by e-mail address“ за човек без профил.

Ако адресът принадлежи на профил, първо щракнете върху „Use this account“. Само така се анонимизира и самият профил. Изпълнение само по адреса заменя адреса там, където е съхранен, и оставя профила такъв, какъвто е.

Въведете ANONYMIZE в полето и щракнете върху „Anonymize“. Активният профил първо се изтрива, а след това се анонимизира. Собственият ви профил не може да се анонимизира. Последният активен администратор също не може.

След това редът носи етикета „Anonymized“. Такъв профил вече не може да се редактира, възстановява или активира отново. Остава само експортът на данни. Можете да пуснете анонимизирането отново. Номерът остава същият, а данните, възстановени междувременно, също се обхващат.

Отметката „Also clear the content of tickets this person requested“ отива по-далеч. Числото в скобите е броят на тези заявки. Техните текстове се изпразват, а прикачените файлове се изтриват. Заявките на други хора, в които човекът само е отговарял, само се анонимизират.

Първо проверете задълженията си за съхранение. В Германия например търговските писма трябва да се пазят шест години. Диалогът ви напомня за това. Автоматичният път само анонимизира. Той никога не изпразва съдържание.

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

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

Анонимизирането изисква правото „Anonymize people“. По подразбиране го имат само администраторите. Само администратор може да го използва. То никога не може да бъде дадено на ролята „Customer“. Диалогът на експорта на данни изисква освен това „Data export (data subject request)“.

Повече за това в картата: Експорт на данните на един човек, Срокове за съхранение

Картата „Data protection“ с изключен превключвател, полето за месеците, „Save“ и връзката „Download list of anonymizations“.
Червените рамки стоят върху превключвателя и върху броя месеци. Превключвателят е изключен, както след всяка актуализация.Отваряне на изображението в пълен размер
Прозорецът „Who will be anonymized“ с един изтрит потребител и датата на изтриването, под него полето с ANONYMIZE и бутонът „Confirm“.
Червените рамки стоят върху списъка и върху „Confirm“. Oliver Grant е изтрит преди повече от 36 месеца. Първото изпълнение би го анонимизирало.Отваряне на изображението в пълен размер
Прозорецът „Delete account“ за Amir Khan. Текстът посочва какво следва и 36-те месеца до анонимизирането.
Червената рамка стои върху „Delete account“. Автоматичното анонимизиране тук е включено. Затова прозорецът посочва броя месеци.Отваряне на изображението в пълен размер
Изгледът „Archived“ с изтрития профил на Oliver Grant, етикета „Deleted“ и символа за възстановяването му.
Червените рамки стоят върху етикета „Deleted“ и върху „Restore account“. До анонимизирането профилът може да бъде върнат.Отваряне на изображението в пълен размер
Диалогът „Export personal data“ за Tomas Novak. Под намерените данни е областта „Anonymize“ с отметнатото поле, въведеното ANONYMIZE и бутона „Anonymize“.
Червените рамки стоят върху отметката и върху „Anonymize“. Tomas Novak е подал четири заявки. Тяхното съдържание също би било изпразнено.Отваряне на изображението в пълен размер
Областта „Anonymize“ след изпълнението: горе „Already anonymized as Anonymized user 2“, долу съобщението „Done“.
Червената рамка стои върху съобщението с номера на запазеното място. Областта позволява ново изпълнение.Отваряне на изображението в пълен размер
Изгледът „Archived“ с анонимизирани профили. Всеки ред носи име на запазено място, адреса на запазеното място и етикета „Anonymized“.
Червената рамка стои върху етикета „Anonymized“. На анонимизиран профил не остава никакво действие освен експорта на данни.Отваряне на изображението в пълен размер

Профилът

Следващите таблици посочват всяко място, където системата съхранява човек, и какво прави там анонимизирането. Можете да ги използвате, за да опишете как фирмата ви изтрива лични данни.

ДанниКакво се случва
Име и фамилия„Anonymized user“ и номерът
Имейл адрес и име за входадресът на запазеното място
Телефонен номерпремахва се
Отдел, длъжност и местоположениепремахва се
Език, светъл или тъмен изглед, достъпноствръща се към стойността по подразбиране
Парола и списъкът с предишни паролиизтрива се
Ключове за двуфакторно влизане и връзката с профил при доставчик за влизане (SSO)изтрива се
Събития по влизане в дневника за сигурносттаизтриват се. Административните действия на лицето в дневника за сигурността остават. Името му там се заменя със заместващото име.
Снимка на профилаизтрива се
Роля и членство в екипипремахват се. След това списъкът с потребители показва ролята „Customer“.
Собствен избор на колони в списъка със заявкипремахва се
Работещ хронометър на отчитането на времетоизтрива се
Самият профилостава, изтрит и заключен завинаги. Заявките, коментарите и записите за време продължават да сочат към него. Затова отчетите продължават да се отчитат.
Флагове да/не за потвърден имейл адрес, потвърден телефон и двуфакторно влизане, настройката да/не на списъка със заявки, броячът на неуспешните опити, времето на последната смяна на паролата и на деактивиранетоостават. Те не съдържат стойност на човека, само да или не, числа и дати. Самите адрес, номер, парола и ключове са заменени или изтрити.
Сведението в заявка кой я е променил последенсе премахва. След това заявката не посочва никого като последния човек, който я е променил.

Копия на името

На някои места системата съхранява името втори път. Така един запис и след промяна показва кой го е направил. И тези копия се заменят.

МястоКакво се случва
Кой е направил промяна в историята на заявкатаиме на запазено място
Име в записите за времеиме на запазено място
Кой е променил статия от базата знанияиме на запазено място
Записи в „Audit log“ на екип, включително „Added user …“ и „Removed user …“име на запазено място
Име на заявителя в заявките, подадени от човекаиме на запазено място. Телефонният номер на заявителя се премахва.
Стари и нови стойности в историята на заявката: име, адрес и телефон на заявителя, наблюдатели, възлаганезапазено място или се премахва. Това важи в заявките на човека и в заявките, в които той преди е бил заявител.

Имейл адреси

Навсякъде, където адрес на човека е съхранен като самостоятелно поле, той става адресът на запазеното място. Главните и малките букви нямат значение.

МястоКакво се случва
Адрес на заявителя в заявкитеадрес на запазено място
Получател на анкетите за удовлетвореностадрес на запазено място
Адрес на одобряващ, при одобрения и в искания със задачиадрес на запазено място
Подател на входящи имейлиадрес на запазено място
Фиксиран адрес на получател в шаблоните за отговорадрес на запазено място
Вътрешна бележка, че имейл правило вече е обработило писмотоадрес на запазено място
Адрес в записа на предишни експорти на данниадрес на запазено място. Самият запис остава като доказателство. По-късен експорт на данни за този адрес също записва само запазеното място.
Предложения за данните на заявителя при създаване на заявкаизтриват се, ако съдържат адреса
Запис в черния списък за имейлиостава. Иначе спамът от този адрес отново би минавал след изтриването.
Съгласия и отписвания за проучването за удовлетвореностизтрити. Ако последният запис е отписване, той остава като един запис без адреса. Списъкът „Survey consents and unsubscribes“ го показва като „anonymized“. Докато лицето не даде съгласие отново или не се абонира отново, до адреса не излиза проучване. Ако ключът за анонимизиране вече не може да се прочете или е бил изхвърлен, отписването вече не действа.

Адреси в текста

В текстовете анонимизирането заменя само имейл адресите на човека. Това става в заявките, които засягат човека. Това са същите заявки, които намира експортът на данни.

ТекстКакво се случва
Описание на заявкатаадресите се заменят
Коментари, включително текстът на входящи имейлиадресите се заменят
Тема на входящи имейлиадресите се заменят
Бележки към записите за времеадресите се заменят
Коментар в анкета за удовлетвореностадресите се заменят
Стари и нови стойности в историята на заявкатаадресите се заменят
Заглавие и текст на статиите от базата знания, включително в историята имадресите се заменят, във всички статии

Изпразване на съдържанието на подадените заявки

С отметката „Also clear the content of tickets this person requested“ тези заявки губят съдържанието си. Това, от което се нуждаят отчетите и сроковете, остава.

Част от заявкатаКакво се случва
Номер, дати, статус, екип, категория, приоритет, възлагане и сроковеостават
Заглавиестава „Content removed“
Описаниеизпразва се
Всички коментари, включително отговорите на операторитетекстът се изпразва. Самият коментар остава, за да са верни първият отговор и сроковете.
Тема на входящи имейлиизпразва се
Стойности на персонализирани полетаизтрива се
Бележка към напомнянето и местоположениеизпразва се
История на заявкатаВидът на всяка промяна остава. Стойностите се изпразват, освен при статус, приоритет, категория, подкатегория, канал, екип, ескалация и възлагане. Те са нужни на отчетите.
Анкета за удовлетвореностОценката остава, коментарът се изпразва.
Записи за времеЗаписаните минути остават, бележката се изпразва.
Прикачени файловеизтриват се, записът и файлът

Ограничения

Имената в обикновения текст остават, например „Поздрави, Max“ в края на писмо. Телефонните номера в обикновения текст също остават. Нито едното, нито другото може да се разпознае надеждно. За заявките на клиент има отметка за изпразване на съдържанието.

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

Много старите записи в историята на заявката, които още не сочат към профила, съдържат само името. Те не се разпознават.

Заявка, която операторът е въвел по телефона без имейл адреса на заявителя, не се разпознава. Името и телефонният номер на заявителя остават в нея.

Адресите в настройките не се променят, например в имейл правилата и правилата за автоматизация. Ако там стои адресът на човека, променете го сами.

Ако човекът пише отново след изпълнението, ново изпълнение по неговия адрес обхваща и новите имейли. Стартирате го чрез „Export by e-mail address“. Номерът остава същият. Ново изпълнение по анонимизирания профил не намира новите имейли. Профилът вече не познава стария адрес.

За архивите системата се грижи сама. Когато възстановите архив, всеки по-рано анонимизиран човек се анонимизира отново във възстановените заявки. Съобщението след възстановяването посочва колко са. Адрес, който в тези заявки се среща само в обикновения текст, не се разпознава там. Освен това нощното изпълнение след анонимизиране обновява архивните файлове. Картата „Срокове за съхранение“ обяснява това.

При резервно копие е различно. Копие, направено преди изпълнение, все още съдържа старите данни. При възстановяване „Ticket System Backup & Restore“ се грижи за това. Приложението пита дали всички, които са анонимизирани в днешното състояние, да бъдат анонимизирани отново. „Yes“ е избрано предварително. След това системата за заявки прави това при нощното изпълнение в 03:00 в зададената часова зона. Това важи и когато превключвателят е изключен. Дотогава имената им отново се виждат. Картата „Data protection“ показва бележка с броя. Резервното копие връща и тогавашната настройка на превключвателя. Затова след възстановяването проверете превключвателя.

Ако възстановите резервно копие по друг начин, отговорите с „No“ или използвате „--no-reapply“ в командния ред, това не се случва. Тогава автоматичният път отново намира изтритите профили, докато превключвателят е включен. Изпълненията, които сте стартирали ръчно, трябва да повторите. За това помага връзката „Download list of anonymizations“ в картата „Data protection“. Изтеглете списъка преди възстановяването. След това той вече не съдържа изпълненията, направени след резервното копие. Списъкът има по един ред за всеки анонимизиран човек, с колоните „Date“, „Number“, „Account ID“, „E-mail hash“ и „Content cleared“. „Date“ е моментът на първото изпълнение в UTC. „Account ID“ е попълнено само ако е анонимизиран профил. „E-mail hash“ е отпечатък на адреса, който не може да бъде обърнат. „Content cleared“ показва дали съдържанието на заявките, подадени от човека, е изпразнено. След всяко изпълнение изтегляйте списъка сами и го пазете извън системата. Копие, направено преди изпълнение, не съдържа това изпълнение.

Текст за вашата политика за поверителност

Като оператор на системата трябва да кажете на хората колко дълго пазите данните им. Можете да използвате този текст в собствената си политика за поверителност.

Примерен текст

След вашето напускане името и имейл адресът ви в системата за заявки се заменят със запазено място след [36] месеца. Заявките и показателите се запазват без връзка с вас. По ваше искане можем да анонимизираме данните ви и по-рано, доколкото това не противоречи на задължение за съхранение. Данните на външни контакти, с които от [36] месеца не е имало контакт, се анонимизират по същия начин. Събитията по влизане в дневника за сигурността се изтриват след [90] дни. Записите за административни действия се изтриват след [12] месеца.

Променете числата според собствените си настройки. Пропуснете всяко изречение, чийто превключвател е изключен. Дайте текста за проверка на собствения си консултант по защита на данните. Това ръководство не е правен съвет.

Искания за изтриване и хора, които се връщат

Изтриването и анонимизирането са две различни неща. „Delete account“ само скрива профила. „Restore account“ го връща. Дотогава имейл адресът му остава запазен за този профил. Затова искане за изтриване изпълнявате с „Anonymize“ в диалоговия прозорец за експорт на данни. Това не може да бъде отменено. Името и адресът се заменят с „Anonymized user“ и номера. Връзката с профила при доставчик на единен вход се изтрива.

Всеки имейл адрес принадлежи на точно един профил. Ако създадете профил с адрес, който вече има друг профил, системата отказва. Съобщението гласи „This e-mail address already belongs to another account.“ Същото важи, когато промените адреса на профил. Ако адресът принадлежи на изтрит профил, съобщението гласи „This e-mail address belongs to a deleted account. Restore that account instead.“ Тогава възстановете стария профил, вместо да създавате нов. Анонимизираните профили не се броят. Те имат вече само адреса на запазеното място.

Изтрит профил не може да бъде възстановен, ако междувременно друг активен профил има същия адрес. Съобщението тогава гласи „This e-mail address already belongs to another account.“ Първо променете адреса на другия профил.

От времето преди това правило може да има профили, които делят един адрес. Управлението на потребители ги отбелязва с бележката „This e-mail address belongs to more than one account. Change it so that each account has its own address.“ Дайте на всеки от тези профили собствен адрес. Дотогава входът с този адрес вместо потребителското име не работи. Имейлът за нулиране на паролата също не се изпраща.

Ако човек се върне след искане за изтриване, получава нов профил. Това важи например, когато отново влезе през Google или Microsoft със същия адрес. За това трябва „Automatically create accounts on first sign-in“ да е включено. Анонимизираният профил вече няма неговия адрес и не пречи на новия профил.

Старите анонимизации никога не засягат новите заявки на този човек. Това важи и след възстановяване на резервно копие или архив. Когато една анонимизация се приложи отново, тя обхваща само данни, създадени преди нейния момент.

Ако старият профил е бил само изтрит, а не анонимизиран, системата отказва първия вход чрез SSO с този адрес. Какво вижда човекът, зависи от доставчика. Ако доставчикът потвърждава адреса, съобщението гласи „An account with this e-mail address was deleted. Ask an administrator to restore it.“ Ако не го потвърждава, гласи „Your e-mail address is not verified with the provider.“ Така системата не издава дали за даден адрес има изтрит профил.

Като администратор тогава имате два пътя. Ако възстановите стария профил с „Restore account“, човекът продължава да работи в него със своята история. Входът чрез SSO работи, ако профилът вече е бил свързан с този доставчик или доставчикът потвърждава адреса. Ако искането за изтриване продължава да важи, анонимизирайте стария профил. След това адресът е свободен и входът създава нов профил.

Саморегистрацията в този случай отговаря неутрално: „Registration could not be completed. If you already have an account, use the password reset on the sign-in page.“ Тя не издава дали за адреса има профил.

6

Срокове за съхранение

Преди да започнете: Тези настройки може да променя само администратор. Анонимизирането не може да бъде отменено.

Системата пази лични данни само докато е необходимо. Един човек се анонимизира, когато напусне или когато поиска това. Напускане означава изтрит профил или външен контакт, с когото отдавна няма контакт. Искане обработвате в диалоговия прозорец за експорт на данни с „Anonymize“.

Самите заявки нямат срок. Съдържанието им запазва своята цел, например като история на клиента. Отчетите и записите на време продължават да се броят.

Всички срокове са в „Settings → Security“, в картата „Data protection“. Тя има три блока: „Deleted accounts“, „External contacts“ и „Security log retention“. Всеки блок има превключвател, срок и „Save“. Блокът „Security log retention“ има два превключвателя и два срока. Под тях е „Archives“. След възстановяване се добавя „Restore from a backup“, щом мине следващото изпълнение в 03:00. Дотогава картата показва бележката „… will be applied again tonight at 03:00.“ Първия блок обяснява картата „Анонимизиране на хора“. Там е и примерният текст за вашата политика за поверителност. Под описанието на картата „Data protection“ е връзката „Data protection guide for operators“. Наръчникът съдържа шаблони за регистъра на дейностите по обработване, техническите и организационните мерки и концепция за съхранение и изтриване.

Под всеки блок има ред „Last run“. Той посочва датата и часа на последното нощно изпълнение и колко хора или записи е обработило. „0 done“ означава, че не е имало какво да се прави. „Not run yet“ стои там, докато задачата няма резултат. Ако превключвателят е изключен, неговата задача не се изпълнява.

Ако редът е оранжев, задачата не е свършила всичко. При „skipped“ той посочва колко хора, записи или файлове са пропуснати. При „Archives“ това са заключени или повредени файлове. При „failed“ цялата задача е неуспешна. Изречението след това казва какво да направите. Ако гласи „Details are in the server log.“, прочетете дневника на сървъра. В Linux го показва командата „sudo podman logs container-backend-1“. Ако споменава ключа за анонимизиране, следвайте раздела „Когато ключът не може да бъде прочетен“ по-долу. Пропуснатото следващото нощно изпълнение опитва отново.

Повече за това в картата: Анонимизиране на хора, Връщане на всичко обратно

Картата „Data protection“ с блоковете „Deleted accounts“, „External contacts“ и „Security log retention“, под тях „Archives“ и „Restore from a backup“, всеки с ред „Last run“.
Червените рамки са върху редовете „Last run“. Тук и четирите превключвателя са включени. По подразбиране са включени само двата превключвателя в блока „Security log retention“.Отваряне на изображението в пълен размер
Блокът „External contacts“ с превключвателя „Anonymize external contacts automatically“ и полето „Months without contact“.
Червените рамки са върху превключвателя и броя месеци. Текстът отдолу посочва какво се брои за контакт.Отваряне на изображението в пълен размер
Прозорецът „Who will be anonymized“ с изречението „Nobody is due yet with this time limit.“, въведеното ANONYMIZE и „Confirm“.
Червените рамки са върху полето и върху „Confirm“. Тук срокът е съкратен на 24 месеца и никой не би бил засегнат. Иначе тук се появяват броят и първите хора с последния им контакт.Отваряне на изображението в пълен размер
Картата „Recent sign-in attempts“ с изречението „Entries are deleted after 90 days (Settings → Security).“ и три влизания.
Червената рамка е върху изречението за срока. Ако изтриването е изключено, там пише „Entries are kept until you delete them.“Отваряне на изображението в пълен размер
Две бележки в горната част на картата: броят на адресите, които вече не се разпознават, и анонимизации, които не са могли да бъдат пренесени.
Червената рамка е върху бележката за пренасянето. Какво да направите, е описано в раздела „Възстановяване на резервно копие“.Отваряне на изображението в пълен размер
Предупреждението „The anonymization key cannot be read“ с връзката „How to restore the key“ и бутона „Discard old key“.
Червените рамки са върху връзката към това ръководство и върху „Discard old key“. Докато предупреждението се показва, картата не показва бележка за чакащи анонимизации.Отваряне на изображението в пълен размер
Прозорецът „Discard old key“ с въведеното DISCARD в полето „Confirmation word“.
Червените рамки са върху полето и върху „Discard old key“. Едва с думата бутонът може да бъде натиснат.Отваряне на изображението в пълен размер

Външни контакти

Външните контакти са хора без служебен профил. Това са заявители без профил и клиентски профили. За системата те никога не напускат. Затова този блок брои времето от последния контакт.

Последният контакт е най-новият от тези моменти: последната промяна в заявка, поискана от човека, имейл от него, негов собствен коментар, отговор на проучване за удовлетвореност, одобрение, изпратено до него, и предложение за данните на заявителя. При клиентски профил се брои и денят на създаването му. Затова нов профил, който никога не е използван, не е засегнат веднага. Профилите, които са съществували още преди обновяването до версия 1.7.0, се смятат за създадени в деня на обновяването.

Служебните профили и техните адреси никога не са засегнати. Това важи и за общ адрес като info@, ако принадлежи на служебен профил. Който има заявка, която още не е затворена, се пропуска, докато тя не бъде затворена. Изтритите профили принадлежат на блока „Deleted accounts“.

Превключвателят „Anonymize external contacts automatically“ по подразбиране е изключен. До „Months without contact“ въвеждате броя месеци. Разрешено е от 1 до 120, стойността по подразбиране е 36.

Когато включите превключвателя, първо се отваря прозорецът „Who will be anonymized“. Той посочва колко хора са засегнати и показва първите с последния им контакт. Въведете ANONYMIZE в полето и щракнете върху „Confirm“. Същият прозорец се появява, когато при включен превключвател съкратите броя и щракнете върху „Save“.

Това се прилага при следващото нощно изпълнение. Всеки засегнат човек се анонимизира както с „Anonymize“. Съдържанието му никога не се изчиства. Остават запазеното място, заявките и показателите. Имената и телефонните номера в обикновения текст остават. Ограниченията посочва картата „Анонимизиране на хора“.

Дневник за сигурността

Дневникът за сигурността записва събития по влизане и административни действия. Събитията по влизане съдържат също IP адреса и идентификацията на браузъра. Какво точно се записва, обяснява картата „Дневникът за сигурността“.

Картата „Recent sign-in attempts“ в „Settings → SSO Settings“ показва последните 100 събития по влизане чрез SSO и директорията. Вижда я всеки, който може да отвори тази страница. По подразбиране това са само администраторите. Изречението под заглавието на картата посочва срока, например „Entries are deleted after 90 days (Settings → Security).“

По подразбиране събитията по влизане се изтриват след 90 дни, а административните действия след 12 месеца. В блока „Security log retention“ задаваш до „Days“ от 7 до 365 дни и до „Months“ от 1 до 120 месеца. Превключвателите „Delete old sign-in events“ и „Delete old administrator actions“ изключват изтриването. Тогава записите остават. Не е нужна дума за потвърждение, защото се изтриват само записи, а не хора.

Влизането с потребителско име и парола също е в дневника за сигурността. Неуспешен опит се запазва с IP адреса и браузъра. Успешно влизане се запазва само за администратори и след неуспешни опити.

Архиви

Архивният файл съдържа и хора, които са анонимизирани едва по-късно. Затова нощното изпълнение след анонимизиране обновява всеки архивен файл, в който се среща човекът. Имената и адресите там се заменят със същите запазени места като в базата данни. Ако съдържанието е изчистено, в архива липсват и прикачените файлове на тези заявки.

До следващата нощ човекът все още е в архивите в четим вид. Архивите нямат превключвател. Архивен файл, който в този момент е заключен, остава непроменен, например защото се изтегля или възстановява. Същото важи за повреден файл. Следващото нощно изпълнение опитва отново.

Час и часова зона

Всички тези задачи се изпълняват веднъж на ден в 03:00. Важи часовата зона в „Settings → General Settings“, в картата „Time Zone“. Часовникът на сървъра няма значение. Много сървъри работят по UTC. Там 03:00 би бил друг час за вас.

Системата проверява на всеки десет минути дали е ред на изпълнението. Първата проверка след 03:00 го стартира. Ако сървърът е бил изключен в 03:00, изпълнението следва при първата проверка след стартирането.

След обновяването до версия 1.7.0 първото изпълнение следва скоро след обновяването, най-късно в 03:00 следващата нощ. Това изпълнение изтрива записите в дневника на влизанията, по-стари от 90 дни.

Ако промените часовата зона, новата важи от следващата проверка. Изпълнението се извършва най-много веднъж на календарен ден. След промяна на запад то може да отпадне в този ден. Тогава следва на следващия ден.

Приложението „Ticket System Backup & Restore“ планира резервните си копия в същата часова зона. То чете зоната от системата за заявки, когато графикът се прилага. Разделът „Schedule“ и „schedule --show“ показват часа със зоната, например „02:00 (Europe/Berlin)“. Ако базата данни в този момент не е достъпна, остава досегашната зона. Ако все още няма такава, важи часовникът на компютъра и показанието гласи „(host clock)“.

Операционната система познава само собствения си часовник. Затова приложението преизчислява часа. В зависимост от часовата зона на сървъра то вписва един или два записа за график. Така резервното копие се изпълнява в правилния час през лятото и през зимата. При стартиране проверява дали наистина е ред на резервно копие. Иначе приключва без копие, а в дневника пише „No backup is due at this time in …“.

Ако промените часовата зона в системата за заявки, следващото планирано резервно копие все пак се изпълнява. След това приложението вписва графика отново. В дневника тогава има предупреждение, което започва с „The time zone in the ticket system changed“. Ако графикът не е могъл да бъде вписан отново, там пише „The schedule could not be updated.“ Тогава отворете приложението и щракнете върху „Apply schedule“.

Когато ключът не може да бъде прочетен

Системата запомня анонимизираните имейл адреси като отпечатък. За това ѝ трябва ключ. Този ключ се пази от ключодържателя на сървъра. Ключодържателят се състои от файловете key-*.xml в папката с ключове. Ако липсват или не съвпадат, картата показва предупреждението „The anonymization key cannot be read“.

Тогава не работят и запазените пароли за поща и SSO. Те зависят от същия ключодържател. Нощните изпълнения за изтрити профили и дневника за сигурността продължават. Хората, познати само по адреса си, се пропускат. „Anonymize“ отказва изпълнение само по адрес.

Ето как да върнете ключодържателя. Вземете резервно копие отпреди проблема. То съдържа папката с ключове като отделен файл. В Linux копията са в „/opt/smitey/backups“. Копирайте едно от тях в празна папка и влезте в нея. Командите по-долу записват резервното копие като обикновени файлове и извличат файловете key-*.xml. След това копират файловете в папката с ключове и рестартират сървъра на системата за заявки. Другите файлове в папката с ключове остават каквито са. След рестартирането предупреждението изчезва. После изтрийте папката „plain“. Тя съдържа пароли и лични данни. По-старо резервно копие с окончание „.zip“ не е шифровано. За него първата команда е „sudo unzip -o <файл> volumes/dataprotection_keys.tar && sudo tar -xf volumes/dataprotection_keys.tar“.

В Windows копията са в „C:\Program Files\SMITEY\backups“. Копирайте едно от тях в празна папка. Отворете там PowerShell като администратор. Въведете командата от кутията „Windows: Записване на резервното копие като нешифровани файлове и извличане на файловете с ключове“. Заменете в нея <файл>.smbk с пълното име на файла на резервното копие. След това копирайте всеки файл key-*.xml с „podman cp <файл> container-backend-1:/app/DataProtection-Keys/“. Командите за собственика и за рестарта въведете без „sudo“. После изтрийте папката „plain“.

Записване на резервното копие като нешифровани файлове и извличане на файловете с ключове

sudo /opt/smitey/Backup/TicketSystemBackup decrypt ticketsystem-backup-*.smbk --out plain && sudo tar -xf plain/volumes/dataprotection_keys.tar

В папката има точно едно резервно копие. След това там са файловете key-*.xml. Подпапката „plain“ съдържа цялото резервно копие нешифровано.

Копиране на файловете в папката с ключове

for f in key-*.xml; do sudo podman cp "$f" container-backend-1:/app/DataProtection-Keys/; done

Съществуващите файлове с друго име остават в папката с ключове.

Задаване на правилния собственик на файловете

sudo podman exec -u root container-backend-1 chown -R 1654:1654 /app/DataProtection-Keys

Системата за заявки работи в контейнера като собствен потребител. Файловете трябва да принадлежат на него.

Рестартиране на сървъра на системата за заявки

sudo podman restart container-backend-1

След рестартирането системата прочита ключодържателя отново.

Windows: Записване на резервното копие като нешифровани файлове и извличане на файловете с ключове

& "C:\Program Files\SMITEY\Backup\TicketSystemBackup.exe" decrypt <file>.smbk --out plain | Out-Host; tar -xf plain\volumes\dataprotection_keys.tar

В PowerShell като администратор, в папката с резервното копие. Заменете <file>.smbk с пълното име на файла на резервното копие. След това там са файловете key-*.xml.

Последният изход: „Discard old key“

Ако нямате резервно копие с файловете с ключове, остава „Discard old key“. Бутонът го вижда само администратор. Въведете DISCARD в полето „Confirmation word“ и щракнете върху „Discard old key“. Тогава системата създава нов ключ.

Анонимизациите чрез профил продължават да важат. Хората, анонимизирани само чрез адреса си, след това вече не се разпознават в резервни копия и архиви. Картата посочва броя им. Следователно по-старо копие може отново да направи тези хора видими. Запазените пароли за поща и SSO остават нечетими. Въведете ги отново.

Възстановяване на резервно копие

При възстановяване „Ticket System Backup & Restore“ пита дали всички, които са анонимизирани днес, да бъдат анонимизирани отново. „Yes“ е избрано предварително. Системата за заявки прави това при следващото нощно изпълнение в 03:00 в своята часова зона. Дотогава картата показва „… will be applied again tonight at 03:00.“

Копието връща и тогавашните превключватели и срокове. Затова след възстановяването проверете картата „Data protection“.

Ако при пренасянето е имало предупреждения, редът за състояние на приложението посочва броя им, например „2 warning(s) while carrying over anonymizations. See the Log tab.“ В командния ред същото стои на последния ред и препраща към „backup.log“. Там пише какво не е успяло. Ако анонимизациите не са могли да бъдат пренесени, повторете ръчно изпълненията след това копие. Помага ви списъкът, който сте изтеглили преди възстановяването.

Системата за заявки чете файла за пренасяне от приложението при следващото стартиране. Ако не може да го прочете, картата показва „A carry-over file from the backup app could not be read“. Файлът остава на сървъра и се чете отново при следващото стартиране. Тогава възстановете копието още веднъж с текущата версия на приложението.

Ако ключът на копието не съвпада, анонимизациите чрез адрес не могат да бъдат пренесени. Тогава картата показва „… could not be carried over from before the restore“. Ако познавате тези хора, анонимизирайте ги отново чрез „Export by e-mail address“.

Редът „Last run“ под „Restore from a backup“ показва колко анонимизации изпълнението е приложило отново.

7

Роли и концепцията за правата

Има три роли: „Admin“, „Agent“ и „Customer“. Други не могат да се създават. Вместо това свободно е почти всяко отделно право; изключенията са изброени по-надолу.

Тези три ще намерите под „Settings → General Settings“ в раздела „Role“. Те не могат да бъдат преименувани.

Какво може една роля, стои другаде: под „Settings → Security“ в картата „Permission concept“.

Всеки ред е една функция, всяка колона – една роля. Отметката я разрешава. Под името стои вътрешният ключ; той не ви е нужен, за да работите със страницата.

Списъкът е дълъг. Той се простира от управлението на потребители през достъпа до отделните страници с настройки чак до отчитането на времето.

Колоната „Agent Team“ е особеният случай. Тя става използваема едва когато на същия ред е поставена отметката „Agent“. Изберете там екип и правото важи само за операторите на този екип.

От ролята „Admin“ не може да се отнеме никакво право. Отметката се връща след запазването. Така никой не може да се заключи извън собствената си система. Само администратор може да променя таблицата. Това важи за всяка настройка на страницата „Security“. Всеки друг, който може да отвори страницата, я вижда само за четене. Шест права никога не могат да бъдат дадени на ролята „Customer“: „Users: manage accounts“, „Data export (data subject request)“, „Anonymize people“, „Security log“, „Settings: Security“ и „Settings: Single sign-on“.

Със „Save“ промяната важи веднага. Който е засегнат, го забелязва при следващото си щракване.

Картата „Permission concept“ с таблицата: по един ред на функция, колони за администратор, оператор, екип на оператора и клиент.
Червената рамка стои върху заглавния ред. Изборът в колоната „Agent Team“ е използваем само там, където е поставена отметката „Agent“.Отваряне на изображението в пълен размер
Разделът „Role“ с трите роли, всяка отбелязана с „Mandatory“.
Червената рамка стои върху бележката. Трите роли са отбелязани с „Mandatory“. Никоя от тях не може да бъде изтрита.Отваряне на изображението в пълен размер
8

Отдел, длъжност и местоположение

Три списъка описват човека, а не заявката: отдел, длъжност и местоположение.

Те се създават под „Settings → General Settings“ в картата „Drop-down lists“. Боравенето е еднакво и за трите.

Задават се на профила. Във формуляра под „User management“ полетата се казват „Department“, „Position“ и „Location“.

В списъка с потребители отделът стои под екипа. Длъжността и местоположението се виждат във формуляра на профила.

Местоположението има и второ приложение. В заявката има поле „Location“ и то черпи от същия списък.

Всеки от трите списъка има по един запис, който не можете да изтриете. Той се казва „None selected or available“ и носи знака „Mandatory“.

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

Тук не превеждате, а наведнъж на страницата за преводи. Английското име е котвата, на която висят преводите.

Диалогът „Edit user“ с попълнени полета за отдел, длъжност и местоположение.
Червените рамки стоят върху трите полета. Те стоят до екипа, но означават друго: екипът казва кой обработва заявките, отделът казва къде работи човекът.Отваряне на изображението в пълен размер
Списъкът с потребители с колоната „Team“, която съдържа отдела под името на екипа.
Червената рамка стои върху колоната. Екипът е отгоре, отделът под него. Който не е в екип, има тире на това място.Отваряне на изображението в пълен размер

Интеграция с имейл

Системата за заявки събира поща от пощенска кутия и сама изпраща поща. Как се настройва това, стои на картата „Заявки от имейл, отговори и продължения“ в блока за управление на заявки. Този блок показва какво става с един входящ имейл, как блокирате податели и какви съобщения изпраща системата сама. Целият пощенски канал е част от изданието Professional.

1

Какво става с един имейл

Само в Professional

Когато някой пише на пощенската кутия на екип, от това се създава заявка. Темата става заглавие, текстът става описание, а адресът на подателя се записва като заявител. Каналът в заявката казва „E-mail“.

Ако имейлът носи име на подател, това име отива в полето до адреса. Ако не носи, полето казва „E-Mail“. Каналът вече казва, че въпросът е дошъл по поща.

Представки като „Re:“ или „Fwd:“ отпадат от заглавието. Тогава заявката носи името на въпроса, а не на отговор по него.

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

Връзките се запазват. Вашият оператор може да щракне върху тях в заявката, вместо да изписва адреса.

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

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

Файловете, прикачени към имейла, стават прикачени файлове към заявката. Поемат се само файловите типове pdf, doc, docx, xls, xlsx, txt, png, jpg, jpeg и gif. Другите файлове отпадат. Важи същото ограничение за размер като за файл, качен от оператор.

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

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

Ако заявителят отговори на заявка, която е решена или затворена, тя се връща на „Reopened“. Същото става, когато заявителят коментира в клиентския портал. Отговорите от хора в копие, от наблюдатели и от оператори не отварят нищо отново.

Повече за това в картата: Заявки от имейл, отговори и продължения

Изпратеният имейл в пощенската програма на подателя, с вградено изображение и връзка.
Този прозорец не е системата за заявки, а пощенската програма на подателя. Имейлът съдържа вградено изображение и връзка.Отваряне на изображението в пълен размер
Описанието на получената заявка с изображението на място и връзката.
Същият имейл като заявка. Червените рамки стоят върху изображението и върху връзката. И двете са на същото място както в имейла, а върху връзката може да се щракне.Отваряне на изображението в пълен размер
Разделът „Attachments“ на заявката с файла inline_image_1.png.
Вграденото изображение се запазва и като прикачен файл. Така може да бъде изтеглено, без да се вади от текста.Отваряне на изображението в пълен размер
Потвърждението във входящата поща на подателя, с означението в темата.
Потвърждението така, както пристига при подателя. Темата носи означението на случая. Ако подателят отговори на нея, отговорът попада в същата заявка.Отваряне на изображението в пълен размер
2

Блокиране на податели

Само в Professional

Преди да започнете: Списъкът с блокирани стои най-долу на страницата „E-Mail Settings“. Той важи за всички екипи наведнъж.

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

Въведете пълен адрес, когато се има предвид точно един подател. На картинката това е no-reply@example.com.

Въведете домейна с водещо @, когато се имат предвид всички адреси на един подател. На картинката това е @newsletter.example.net. Поддомейните се блокират заедно с него.

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

Блокирането действа и в другата посока. Системата не изпраща поща до блокиран адрес.

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

„Add“ поставя запис в списъка. Иконката с кошчето до него премахва записа отново. Промяната влиза в сила веднага, няма какво да се запазва.

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

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

Картата „E-Mail Blacklist“ с два записа: пълен адрес и домейн.
Червената рамка стои върху полето за въвеждане. Неговият примерен текст назовава и двете позволени форми. Под него стоят двата записа на тази инсталация.Отваряне на изображението в пълен размер
3

Какво изпраща системата сама

Само в Professional

Преди да започнете: Превключвателите на тази карта стоят за всеки екип под „Team mailboxes“ на страницата „E-Mail Settings“, непосредствено под адреса на пощенската кутия на този екип.

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

Тези текстове идват готови и в началото са на английски. Те стоят в езиковия пакет заедно с всеки друг текст на интерфейса.

След като езиковият пакет бъде внесен, всяко от тези съобщения излиза на езика, зададен на получателя. Затова двама души по един и същ въпрос получават съобщението на два езика. Получателите без профил нямат собствен език. Имейлите до тях излизат на езика, зададен на екипа под „Default e-mail language“. Това обхваща например проучването, разрешаването на групов инцидент, отказа и имейла на правило.

Формулировките променяте на езиковата страница. Там изтегляте текстовете на един език като файл, редактирате го и го качвате отново. Английският е източникът и остава какъвто е.

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

„Send assignment e-mails“ изпраща имейл до оператора, който получава заявка. При изключен превключвател този екип изобщо не съобщава за възлагания.

„Notify on self-assignment“ решава дали да се изпраща имейл и когато някой сам вземе заявка. Този превключвател е изключен по подразбиране.

„Send mail on ticket actions“ действа другаде. Когато е включен, диалозите за затваряне, за промяна на статуса и за предаване предлагат коментарът да бъде изпратен и като имейл.

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

Повече за това в картата: Заявки от имейл, отговори и продължения

Разделът „Assignment notifications“ с три превключвателя.
Червените рамки стоят върху трите превключвателя. Те принадлежат на пощенската кутия на екипа над тях. Всеки следващ екип има собствени три такива превключвателя.Отваряне на изображението в пълен размер

Удостоверяване и сигурност, включително SSO

Кой влиза и как, се решава на две места. Страницата за сигурност урежда входа с потребителско име и парола. Страницата за SSO свързва директория или външна услуга за вход. Можете да ползвате и двете едновременно.

1

Вход с потребителско име и парола

Преди да започнете: Настройките на тази карта живеят под „Settings → Security“. Само администратор може да ги променя. Всеки друг, на когото е дадена страницата, я вижда само за четене.

Още от началото всеки влиза с потребителско име и парола. Имейл адресът работи вместо потребителското име. Ако изпращането на поща е настроено, под формуляра се появява връзката „Do you need a password reset?“. Изпращането на поща е част от Professional.

След влизането браузърът получава пропуск, който е валиден за определено време. Картата „JWT token timer“ решава колко дълго. Позволени са стойности от 1 до 24 часа, препоръчва се 12. След това човекът трябва да влезе отново.

Картата „Password policy“ важи за всяка парола, задавана в системата. Тя се налага при създаване на профил, когато човек променя собствената си парола и когато администратор нулира парола.

Задавате минималната дължина, какви видове знаци трябва да се появят, след колко дни паролата изтича и колко стари пароли остават блокирани. За дните и за списъка с блокирани 0 означава „изключено“.

Правилата за главни и малки букви не изключват никой език. Много писмености изобщо нямат такова разграничение, а знак от някоя от тях сам по себе си удовлетворява и двете правила.

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

Картата „2FA Settings“ определя кой трябва да използва двуфакторен вход. Под „Two-factor requirement“ избирате едно от четири нива: „Off“, „Administrators only“, „Administrators and agents“ или „Everyone“. „Everyone“ включва и клиентите. Нова инсталация започва с „Administrators only“. Инсталация, която е съществувала и преди, запазва след обновяване досегашната си настройка.

Който влезе следващия път без втори фактор, го настройва. Системата показва QR код за приложение за удостоверяване и същия ключ за въвеждане на ръка. След първия код факторът е активен. С „Set up later“ настройката може да се отложи, а входът продължава без нея. Това става най-много 7 дни, броено от първото отлагане. Редът под бутона показва оставащите дни. След това настройката е задължителна.

Веднага след това се появяват десет кода за възстановяване. Всеки от тях замества веднъж кода от приложението. Показват се точно веднъж. Запазвате ги с „Copy“ или „Download“. „Download“ работи винаги. „Copy“ обикновено също работи.

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

Кодовете зависят от часовника на сървъра. Ако той е грешен, никой код не се приема. Бутонът „Check now“ на същата карта сверява времето на сървъра с публичен източник за време.

Ако някой влезе през външна услуга за вход, системата не иска код. Доставчикът вече е проверил втория фактор. При входа през директория е различно: там важи горното правило.

Повече за това в картата: Двуфакторен вход в собствения профил

Страницата за вход с полетата „Username“ и „Password“ и бутона „Sign in“.
Червените рамки стоят върху двете полета и бутона. Горното поле приема и имейл адреса.Отваряне на изображението в пълен размер
Картата „JWT token timer“ с полето за броя часове.
Червената рамка стои върху полето. То приема стойности от 1 до 24.Отваряне на изображението в пълен размер
Картата „Password policy“ с минимална дължина, видове знаци, изтичане и списък с блокирани.
Червените рамки стоят върху трите числови полета. Отметките между тях решават кои видове знаци трябва да се появят.Отваряне на изображението в пълен размер
Картата „2FA Settings“ с четирите нива под „Two-factor requirement“.
Червената рамка е върху четирите нива. Избрано е „Administrators only“, както при нова инсталация.Отваряне на изображението в пълен размер
Екранът за настройване с QR код, ключ за въвеждане и полето за първия код.
Горната червена рамка е върху ключа. Той е същото като QR кода над него и помага, когато камерата не разчита нищо. Долната е върху „Set up later“ и оставащите дни.Отваряне на изображението в пълен размер
Десет кода за възстановяване в две колони, под тях „Copy“ и „Download“.
Червените рамки са върху кодовете и двата бутона. Кодовете се появяват точно веднъж. Кодовете на изображението са от тестова система и нямат стойност.Отваряне на изображението в пълен размер
Списъкът с потребители с бутона, който нулира двуфакторния вход.
Червената рамка стои върху зачеркнатия щит в реда на Marco Rossi. Едно щракване му отнема приложението и кодовете за възстановяване.Отваряне на изображението в пълен размер
2

Двуфакторен вход в собствения профил

Всеки потребител може да включи двуфакторен вход за собствения си акаунт. Това важи за всяка роля, и когато картата „2FA Settings“ не го изисква. Отворете потребителското меню долу вляво в страничната лента и изберете „Profile picture“. На същата страница е и областта „Two-factor authentication“.

Областта показва дали двуфакторният вход е включен. Докато е изключен, там стои бутонът „Turn on“. Той първо пита за паролата ви. След това се появява QR код за приложението за удостоверяване и същият ключ за въвеждане на ръка. След първия код от приложението факторът е активен.

Веднага след това се появяват десет кода за възстановяване. Запазете ги с „Copy“ или „Download“. „I have saved my codes“ затваря списъка. Той се показва само този един път.

Докато двуфакторният вход е включен, областта показва колко кода за възстановяване са останали. „New recovery codes“ създава десет нови. Старите кодове тогава спират да работят. „Turn off“ отново изключва двуфакторния вход. И двата бутона искат текущия код от приложението. Код за възстановяване там не се приема.

Ако картата „2FA Settings“ изисква двуфакторен вход за вашата роля, бутонът „Turn off“ липсва. Ред в областта казва това.

Грешна парола или грешен код се брои като неуспешен вход. Защитата срещу отгатване на пароли значи важи и тук. Включването и изключването се записват в дневника за сигурността. Ако администратор изключи собствения си двуфакторен вход, дневникът вдига тревога.

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

Повече за това в картата: Вход с потребителско име и парола, Дневникът за сигурността

Областта „Two-factor authentication“ в профила със състоянието и бутона „Turn on“.
Червените рамки са върху състоянието и „Turn on“. Тук двуфакторният вход още е изключен.Отваряне на изображението в пълен размер
Първата стъпка след „Turn on“: полето „Password“ с „Continue“ и „Cancel“.
Червените рамки са върху полето за паролата и „Continue“. QR кодът се появява едва след правилната парола.Отваряне на изображението в пълен размер
3

Защита срещу отгатване на пароли

Защитата работи без никаква настройка. Няма какво да се включва. Бележката за нея стои в картата „2FA Settings“.

Тя действа на два етапа. След пет неуспешни опита за един и същ профил адресът, от който идват, се спира. Спирането приключва най-късно 15 минути след първия от тези опити. От всеки друг адрес профилът остава използваем веднага.

Това е важната част. Иначе всеки, който знае едно име за вход, би могъл да заключи колега с пет грешни пароли. За това никога не би му трябвала парола.

Вторият етап е самият профил. Той се заключва за 15 минути след 20 неуспешни опита. Тъй като един-единствен адрес може да допринесе най-много пет от тях, за това са нужни няколко адреса.

Успешното влизане нулира и двата брояча. След рестарт на сървъра спирането на адреса отпада, заключването на профила остава. Същите броячи важат и за влизането през директория. Недостъпна директория не се брои за неуспешен опит. Ако за името все още няма профил в системата за заявки, важи само спирането на адреса.

В списъка с потребители заключеният по този начин профил носи знака „temporarily locked“. Той остава в списъка. След 15 минути знакът изчезва сам.

Не е нужно да чакате. В същия ред има бутон с отворен катинар. Той вдига заключването веднага и изчиства и двата брояча.

Това не е същото като „Archive“. Онзи бутон спира профила окончателно и само той заема или освобождава вътрешно място.

Бележката за защитата срещу отгатване на пароли в картата „2FA Settings“.
Червената рамка стои върху бележката. Тя назовава и двата етапа: първо адресът, накрая профилът.Отваряне на изображението в пълен размер
Списъкът с потребители със знака „temporarily locked“ и бутона за отключване.
Червените рамки стоят върху знака и върху отворения катинар. Катинарът се появява само в реда, в който има какво да се вдига.Отваряне на изображението в пълен размер
4

Дневникът за сигурността

Преди да започнете: Дневникът е в „Settings → Security log“. По подразбиране го виждат само администраторите. На други роли го даваш с правото „Security log“ в картата „Permission concept“. На клиенти не може да се даде.

Дневникът за сигурността записва два вида събития. Областта „Sign-in“ съдържа неуспешни влизания, заключени профили, опити за влизане по време на заключване, отхвърлени двуфакторни кодове и смени на пароли. Това важи за влизане с парола, чрез директория и чрез SSO.

Областта „Administration“ показва кой какво е променил. Това обхваща профили, роли, права, настройки за сигурност и архиви. Там се записва и всеки експорт на дневника.

Успешните влизания се записват само в два случая. Първият случай е администратор. Вторият случай е влизане след неуспешни опити за същия профил. Обикновеното влизане на агент или клиент не е в дневника. Дневникът не е списък за присъствие.

Ако някой влезе с име, което не съществува, в записа пише „unknown account“. Системата не запазва въведеното име. Понякога това е парола, попаднала в грешното поле.

Събитията по влизане запазват IP адреса и браузъра. Административните действия запазват кой ги е извършил, но не и IP адрес. Пароли, кодове и съдържание на заявки или имейли никога не са в дневника.

Страницата показва първо най-новите записи, по 50 на страница. Картата „Filters“ стеснява списъка. „Area“ избира влизания или администрация, „Event“ един вид събитие. „Person“ търси в името на този, който е действал, и на засегнатия. „From“ и „To“ ограничават дните. „Failures only“ скрива всичко, което е успяло.

Филтрите действат едва след щракване върху „Apply“. „Reset“ отново ги премахва.

„Export CSV“ и „Export PDF“ изтеглят точно това, което показват филтрите. Всеки файл съдържа най-много 10 000 записа. Ако на филтрите отговарят повече записи, това се посочва в бележка до бутоните за експорт. PDF файлът е на твоя език и посочва горе филтрите и периода. Датата и часът следват формата, зададен в „Settings → General Settings“.

CSV файлът винаги остава на английски, а часовете са в UTC. Така програма може да го чете независимо от езика. Всеки експорт сам е в дневника като „Security log exported“.

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

След сигнал всеки с правото вижда жълт банер в горната част на всяка страница. Той посочва броя сигнали от последното му посещение на дневника. Връзката „Open security log“ води дотам. С отварянето на дневника банерът изчезва. Преди първото посещение той брои сигналите от последните седем дни.

Освен това всеки активен профил с правото и имейл адрес получава имейл със сигнал. Системата събира сигналите на всеки 15 минути и изпраща по един имейл на човек, а не по един на събитие. Имейлът посочва събитието, засегнатото лице и часа. Той не съдържа IP адрес. Имейлът със сигнал е част от Professional.

Нощното изпълнение изтрива старите записи. Сроковете са в „Settings → Security“, в картата „Data protection“, в блока „Security log retention“. Събитията по влизане се пазят по подразбиране 90 дни, позволени са от 7 до 365 дни. Административните действия се пазят по подразбиране 12 месеца, позволени са от 1 до 120 месеца.

Всеки срок има собствен превключвател: „Delete old sign-in events“ и „Delete old administrator actions“. Ако превключвателят е изключен, тези записи остават. Картата „Срокове за съхранение“ обяснява нощното изпълнение.

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

Бележка към теб като оператор: успешните влизания са в дневника само за администратори и след неуспешни опити. Въпреки това дневникът показва кой какво и кога е направил. Във фирма с представители на работниците той затова е въпрос на съвместно решаване.

Повече за това в картата: Защита срещу отгатване на пароли, Срокове за съхранение

Страницата „Security log“ с картата „Filters“ и списъка със записи.
Червената рамка стои върху заключването на профила на Lena Chen. Под нея са неуспешните опити, довели до него, всеки със своя IP адрес. Записите на изображението са от тестова система.Отваряне на изображението в пълен размер
Картата „Filters“ с включено „Failures only“, двата бутона за експорт и първите неуспехи.
Червените рамки стоят върху „Failures only“ и върху двата експорта. Експортите поемат зададените тук филтри.Отваряне на изображението в пълен размер
Жълтият банер над таблото с броя събития по сигурността и връзката „Open security log“.
Червената рамка стои върху връзката към дневника. Тук сигналът е задействан от заключването на профила на Lena Chen.Отваряне на изображението в пълен размер
Блокът „Security log retention“ с два превключвателя, дните и месеците.
Червените рамки стоят върху двата срока. Изображението показва настройката по подразбиране: 90 дни и 12 месеца.Отваряне на изображението в пълен размер
5

Вход през директория или външна услуга (SSO)

Само в Professional

Преди да започнете: Настройките живеят под „Settings → SSO Settings“. Без настроен доставчик на страницата за вход не се променя нищо.

Най-горе стои главният превключвател „Enable single sign-on“. Докато е изключен, остава входът с потребителско име и парола. Всичко, което настроите под него, се запазва и влиза в сила едва когато го включите.

Картата „Active Directory / LDAP“ свързва директория на място. Въвеждате сървъра, базата за търсене, филтъра, който намира човек, и полетата за имейл адреса и имената.

Профилът, използван за търсенията, е по избор. Без него системата пита анонимно. Паролата на човека се използва само за свързване с директорията и никога не се съхранява.

Директорията не носи собствен втори фактор. Ако страницата за сигурност изисква двуфакторен вход, тези хора също биват питани за него.

Картата „Identity providers“ съдържа външните услуги за вход. Всяка получава собствена плочка и собствен бутон на страницата за вход. „Add provider“ създава нова.

Под „Provider type“ избирате вида. „Generic OIDC Provider“ подхожда за услуги като Google Workspace, Microsoft Entra ID, Okta, Keycloak, Auth0 или Ping Identity. „SAML 2.0 Provider“ подхожда за същите къщи, когато трябва да се свържат през SAML.

До тях стоят шест регионални услуги: LINE, Kakao, Naver, WeChat, WeCom и DingTalk. Техните адреси са предварително попълнени и се показват като сив текст в полето.

Името под „Display name“ по-късно се показва на бутона. Превключвателят до него важи само за този един доставчик.

За адреса за връщане работете в този ред. Първо въведете само име и щракнете върху „Save provider“. Едва тогава системата знае номера на доставчика и показва готовия адрес под „Redirect URI“. Той се изгражда от публичния адрес на тази инсталация, този, който е записан под „Settings → Security“. Точно това е адресът, който системата използва, когато някой влиза.

Копирате този адрес и го регистрирате при доставчика. Там той трябва да съвпада знак по знак. В замяна доставчикът ви дава идентификатор и тайна и вие ги въвеждате тук през „Edit“.

Полето „Allowed e-mail domains“ ограничава кой може да влиза през този доставчик. Оставено празно, всеки домейн е позволен.

Ако на доставчик още липсва нещо, плочката му носи червения знак „Incomplete“. Тогава той не се показва на страницата за вход. Текстът до него казва кои полета изисква неговият вид.

Напълно настроените доставчици все още не се показват, докато главният превключвател е изключен. Плочката го казва с жълт ред.

Ако вашият лиценз се върне към Basic, влизането през SSO и през директорията продължава да работи. На тази страница тогава можете само да изключвате доставчиците и директорията. Дневникът на опитите за влизане остава четим.

Картата „Single sign-on“ с главния превключвател.
Червената рамка стои върху главния превключвател. При изключен превключвател остава само входът с потребителско име и парола.Отваряне на изображението в пълен размер
Картата „Active Directory / LDAP“ с попълнени полета.
Червените рамки стоят върху сървъра, базата за търсене и филтъра за търсене. Стойностите на картинката идват от изпитателна система.Отваряне на изображението в пълен размер
Две плочки на доставчици, едната настроена, а другата със знака „Incomplete“.
Червените рамки стоят върху двете плочки. Горната е пълна и чака само главния превключвател. На долната липсва адресът на нейния доставчик.Отваряне на изображението в пълен размер
Диалогът „Add provider“ с вид, показвано име, превключвател и адреса на доставчика.
Червената рамка стои върху полето за адрес. Под него „Quick fill“ попълва предварително добре познатите доставчици. Каквото стои във фигурни скоби, първо го заменяте.Отваряне на изображението в пълен размер
Диалогът на запазен доставчик, който показва готовия адрес за връщане.
Червената рамка стои върху адреса за връщане. Той възниква едва при запазването и започва с адреса на собствената ви инсталация.Отваряне на изображението в пълен размер
6

Профилът при първото влизане и дневникът

Само в Professional

Превключвателят „Automatically create accounts on first sign-in“ стои в същата карта като главния превключвател. Той е включен по подразбиране.

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

Новият профил получава ролята „Customer“ и никакъв екип. Клиентът няма нужда от членство, за да създаде заявка, и затова може да работи веднага.

Клиентите са неограничени и в двете издания, затова създаден по този начин профил не използва вътрешно място. Който трябва да стане оператор, получава ролята след това в управлението на потребители.

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

Ако го изключите, влизат само хора, които вече имат профил. Всички останали биват отпратени.

Картата „Recent sign-in attempts“ най-долу показва последните 100 събития по влизане чрез SSO и директорията. Те идват от дневника за сигурността. Неуспешните опити винаги са в нея. Успешно влизане е в нея само за администратори и след неуспешни опити за същия профил. Затова не всяко влизане е в списъка.

Всеки ред назовава часа, доставчика, резултата и адреса на източника. При неуспешен опит до него стои причината. Колоната „User“ показва името на профила. Ако няма профил, показва адреса, съобщен от доставчика, иначе „unknown account“. Системата не запазва въведеното име.

Входът с потребителско име и парола не се появява в тази таблица. Той не е SSO. Намираш го в дневника за сигурността.

По подразбиране записите се изтриват след 90 дни. Изречението под заглавието на картата посочва зададения срок. Картата „Срокове за съхранение“ обяснява настройката.

Повече за това в картата: Дневникът за сигурността

Превключвателят „Automatically create accounts on first sign-in“.
Червената рамка стои върху превключвателя. Текстът под него назовава ролята, която получава такъв профил.Отваряне на изображението в пълен размер
Таблицата „Recent sign-in attempts“ с три неуспешни опита през директорията.
Червената рамка стои върху най-горния ред. Той показва неуспешен опит с неговата причина. Записите на картинката идват от изпитателна система, чиято директория не съществува.Отваряне на изображението в пълен размер
7

Петте начина за достъп до системата

Преди да започнете: Начина на достъп до системата избирате в инсталатора на SMITEY на сървъра. Можете да го промените по-късно по всяко време.

След инсталирането екипът ви използва системата във всеки уеб браузър. Инсталаторът пита как да е достъпна системата. В инсталатора за Windows избирате това на страницата „Достъпност“. В Linux install.sh задава същия въпрос и номерира възможностите от 1 до 5. По-късно го променяте с „Промяна на начина на достъп до SMITEY“. Данните ви остават където са.

Възможността „Само в локалната мрежа, чрез IP адреса (HTTP) - най-прост вариант“ е настройката по подразбиране. Екипът ви отваря системата на http://, последвано от IP адреса на сървъра и порта, например http://192.168.1.20:8088. Портът е 8088, освен ако не изберете друг. Работи и порт 80. Тогава адресът няма нужда от порт. Тази възможност не изисква нито име, нито сертификат.

Възможността „В локалната мрежа със собствено име (HTTP, HTTPS е възможен по-късно) - имате вътрешен DNS“ работи като първата, но с име като ticket.company.local. Името създавате сами във вашия вътрешен DNS. То сочи към IP адреса на сървъра. Тогава екипът ви достига системата по името и продължава да я достига по IP адреса. След това инсталаторът показва адреса с това име.

При двете възможности с HTTP паролите и заявките минават през мрежата ви като четим текст. В този случай администраторите виждат съобщение горе на страницата.

Другите три възможности използват HTTPS: „Чрез публичен домейн с HTTPS (автоматично, чрез Let's Encrypt)“, „В локалната мрежа с HTTPS и собствен сертификат“ и „В локалната мрежа с HTTPS, сертификат, създаден от SMITEY“. Те изискват на сървъра портове 80 и 443. Следващата карта ги описва.

За първи тест първата възможност е достатъчна. Ако мрежата ви има вътрешен DNS, изберете втората. Ако системата трябва да е достъпна от интернет, изберете публичния домейн. Ако фирмата ви има собствен сертификационен орган, изберете собствения сертификат в локалната мрежа. Иначе оставете SMITEY да създаде сертификата.

Промяна на достъпа до SMITEY в Linux

sudo bash /opt/smitey/install.sh --change-access

Показва варианти от 1 до 5. Само Enter запазва текущия вариант и не променя нищо.

Повече за това в картата: Достъп до системата през HTTPS

Страницата „Достъпност“ в инсталатора за Windows с петте възможности.
Текстът над списъка номерира възможностите от 1 до 5. В Linux същите текстове се появяват с тези номера.Отваряне на изображението в пълен размер
8

Достъп до системата през HTTPS

Преди да започнете: Пътя към HTTPS избирате в инсталатора на SMITEY на сървъра, а не в браузъра.

Без HTTPS паролите и заявките минават през мрежата ви като четим текст. Нова инсталация започва с обикновен HTTP, за да работи веднага във всеки уеб браузър. Докато администратор отваря системата през обикновен HTTP, горе на страницата се появява съобщение: „This connection is not encrypted.“ Ако системата се отвори на самия сървър като „localhost“, съобщението не се появява. Операторите и клиентите никога не го виждат.

„How to switch on HTTPS“ води до тази карта. „Hide for 30 days“ скрива съобщението за вас. Настройката принадлежи на акаунта ви и затова важи и в друг браузър. След 30 дни съобщението се връща, докато връзката все още не е шифрована.

Инсталаторът на SMITEY настройва HTTPS по три начина. В инсталатора за Windows избирате на страницата „Достъпност“, а в Linux install.sh задава същия въпрос. При система, която вече работи, отворете „Промяна на начина на достъп до SMITEY“ на работния плот на Windows или в менюто Старт. В Linux същото прави командата по-долу. Данните ви остават където са.

Възможността „В локалната мрежа с HTTPS и собствен сертификат“ използва вашия собствен сертификат, например от сертификационния орган на фирмата ви. Инсталаторът пита за името на системата и за файла на сертификата с неговия ключ. Става и PFX файл с паролата му. Преди да промени каквото и да е, той проверява сертификата. Ключът трябва да съвпада, сертификатът трябва да е валиден и името трябва да е в сертификата.

Възможността „В локалната мрежа с HTTPS, сертификат, създаден от SMITEY“ не се нуждае от собствен сертификат. SMITEY създава такъв сам и сам го подновява. Основния сертификат инсталаторът записва като SMITEY-root-ca.crt в папката на инсталацията. Инсталирайте този файл на всеки компютър като доверен основен сертификат, например с групова политика. Дотогава браузърите показват предупреждение.

Възможността „Чрез публичен домейн с HTTPS (автоматично, чрез Let's Encrypt)“ взема сертификата си от Let’s Encrypt. Нужен му е публичен домейн, който сочи към сървъра. Затова сървърът трябва да е достъпен от интернет.

При двете възможности за локалната мрежа името може да е име като ticket.company.local, една дума като helpdesk или IPv4 адрес. И трите пътя изискват на сървъра портове 80 и 443. Ако ги използва друга програма, инсталаторът спира и не променя нищо. След това системата е достъпна на https:// и името, без порт.

Собственият ви сертификат някога изтича. От 30 дни преди това администраторите виждат горе на страницата съобщение с датата. От 7 дни преди това то е червено. В Professional всички администратори с имейл адрес получават освен това имейл 30 и 7 дни преди това. За подновяване отворете отново „Промяна на начина на достъп до SMITEY“, изберете възможността със собствен сертификат и посочете новите файлове.

Файлът HTTPS-GUIDE.txt, който идва с инсталацията, описва всяка стъпка. Към това спадат разпространението на основния сертификат и стъпките на ръка.

Промяна на достъпа до SMITEY в Linux

sudo bash /opt/smitey/install.sh --change-access

Показва варианти от 1 до 5. Само Enter запазва текущия вариант и не променя нищо.

Съобщението „This connection is not encrypted.“ над списъка със заявки, с връзката и „Hide for 30 days“.
Червените рамки са върху връзката към тази карта и „Hide for 30 days“. Само администраторите виждат съобщението.Отваряне на изображението в пълен размер

Управление на заявки

Ежедневният занаят: създаване на заявки, подреждане, намиране отново. Всичко в този блок е част от Basic, освен ако картата не казва друго.

1

Създаване и редактиране на заявки

Преди да започнете: Отделна заявка не може да бъде изтрита — дори от администратор. Заявките напускат базата данни само през архива и само след като са затворени. Това е нарочно: случай, който някой може да премахне без следа, е безполезен като запис.

Създавате нова заявка с „New Ticket“ в лявата лента. Формулярът се казва „Create new ticket“. Като оператор с него записвате и чужди искания — за това служи полето „User“: то казва за кого е случаят, а не кой го въвежда.

Всичко със звездичка е задължително: „Title“, „User“, „Main category“ и „Description“. Още едно, което лесно се пропуска: формулярът не се запазва без подкатегория, въпреки че „Subcategory“ няма звездичка — основната и подкатегорията вървят заедно и винаги се задават по двойка.

Кои полета са задължителни, се задава под „Settings → Ticket Settings“. Картата „Admin / Agent Field Settings“ има за това само превключвателя „Field is mandatory“. Картата „Customer Field Settings“ има освен това „Is hidden for Customer“ и „Is not editable“. Затова клиентът може да вижда по-кратък формуляр от вас, без някой да поддържа два формуляра. „Title“ и „Description“ са винаги задължителни. Това не може да се изключи.

След това можете да промените почти всичко: вдясно в заявката стои картата „Details“ със заявител, телефон, имейл, местоположение, категория и референтен номер; променяте самото поле и потвърждавате със „Save“ отдолу. Статус, възлагане, приоритет, канал и наблюдатели стоят една карта по-нагоре под „Actions“. Статусът и възлагането влизат в сила веднага. Приоритетът, каналът и наблюдателите се запазват едва със „Save“ в картата „Details“.

Само операторите и администраторите могат да променят това. Заявителят може да чете случая, да коментира по него и да прикача файлове — но не и да променя класификацията, върху която стъпват отчетите ви.

Един страничен ефект, който си струва да се знае веднъж: ако редактирате заявка, която още не принадлежи на никого, след това тя принадлежи на вас. Системата вписва вас като оператор и премества статуса от „Open“ на „Assigned“ — и двете влизат в историята. Ако не сте искали това, възложете я след това на някой друг.

Всяка от тези промени попада в историята на заявката, с име, час, стара и нова стойност. За това не е нужно да включвате нищо.

Остава въпросът как да се отървете от заявките отново. Под „Settings → Archive“ избирате период, виждате с „Preview“ колко затворени заявки съдържа той, и създавате ZIP файл с „Create archive“: заявки, коментари, история, собствени полета и прикачени файлове, всичко в един файл. Създаването не премахва нищо. Заявките напускат работещата база данни едва с отделната стъпка „Delete from live DB“ в списъка „Existing archives“ — и могат да бъдат възстановени от същия файл.

Формулярът „Create new ticket“ с полетата Title, Owning team, User, статус, приоритет, канал и наблюдатели.
Формулярът зад „New Ticket“. Полетата със звездичка са задължителни; категориите, описанието и прикачените файлове следват по-надолу.Отваряне на изображението в пълен размер
Картата „Details“ на заявка с полетата на заявителя и бутона „Save“, ограден в червено.
Промяна по-късно: редактирате полето, натискате „Save“. Отдолу стои непроменимо кой е създал заявката и кога.Отваряне на изображението в пълен размер
2

Редактор с форматиран текст за описание и коментари

Описанието и коментарите не са голи текстови полета. Всяко има лента с бутони отгоре и бутоните казват какво правят, когато посочите към тях: „Bold“, „Italic“, „Underline“, „Strikethrough“, „Text color“, „Highlight color“, „Bullet list“, „Numbered list“, „Quote“, „Link“ и „Clear formatting“.

Така се прави връзка: избирате текста, щраквате върху „Link“, въвеждате адреса в малкото поле. Празното въвеждане премахва връзката отново. Позволени са уеб и пощенски адреси (http, https, mailto) — всичко останало се изхвърля при запазването, за да не може един коментар да прокара нещо покрай някого.

Изображенията идват през клипборда: правите снимка на екрана и я поставяте направо в редактора с Ctrl+V. Отначало текстът показва само означение като „[inline-image:1]“. При запазването системата качва изображението и го показва точно там — а то попада и в раздела „Attachments“, където живеят всички файлове по случая. Поставянето на изображения работи в описанието на съществуваща заявка и в нов коментар. То не работи във формуляра „Create new ticket“, нито докато редактирате коментар.

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

Един коментар може да бъде отбелязан като вътрешен с „Internal note (not visible to the customer)“. Тогава той носи знака „Internal“ и е невидим за заявителя — дори търсенето няма да го покаже.

Всеки може да променя и изтрива собствените си коментари. Написаното от клиент може да бъде променяно или изтривано само от същия клиент или от администратор. Това включва и неговите имейли. Коментарите на колеги могат да бъдат променяни и изтривани от всеки оператор, който може да работи по заявката. Това включва и екип, който е имал заявката по-рано.

Лентата с бутони на редактора, под нея изречението „The display shows ERROR 13.20 and then the paper jams.“ с удебелен код на грешката.
Оградени в червено: „Bold“, „Bullet list“ и „Link“. Лентата стои както над описанието, така и над полето за коментар.Отваряне на изображението в пълен размер
Три коментара по една заявка, долният с удебелен термин и списък с точки, средният носи знака „Internal“.
Така пристига: удебеленият текст и списъкът се запазват. Средният коментар е отбелязан като „Internal“ и е невидим за заявителя.Отваряне на изображението в пълен размер
3

Прикачени файлове с преглед

Преди да започнете: Позволени са PDF, DOC, DOCX, XLS, XLSX, TXT, PNG, JPG, JPEG и GIF, до 50 MB на файл. Ограничението е посочено във формуляра („Max. 50 MB per file“), а по-големите файлове се отхвърлят, преди качването да започне.

Файловете принадлежат на случая, а не на отделен коментар. В заявката разделът „Attachments“ води до списъка: „Upload file“ добавя файл, всеки ред назовава файла, размера и датата му. Всеки, който участва в заявката, може да прикачи нещо — включително заявителят; така никой не трябва да ви праща снимката на екрана си по поща. Клиентът може да изтрива само прикачени файлове, които сам е качил. Когато подзаявка бъде затворена, нейните прикачени файлове се копират в основната заявка, където носят знака „Internal“. Операторите ги виждат; клиентите нито ги виждат, нито ги изтеглят.

Щракване върху името отваря прегледа, без да сваляте файла. При изображенията там можете да увеличавате, да намалявате и да завъртате — полезно при дисплей, снимкан под ъгъл. PDF файл се показва в същия прозорец, с преглед на страниците, увеличение и печат. Текстовите файлове се показват като текст. С „Open in new tab“ отваряте файла в собствен прозорец.

Прикаченият файл принадлежи на случая и пътува с него: появява се в историята („File uploaded: …“), преживява предаване на друг екип и попада в архивния файл, когато заявката бъде архивирана.

Разделът „Attachments“ с два файла, над тях бутонът „Upload file“, ограден в червено.
Всички файлове по един случай на едно място. Редът отдолу назовава позволените видове файлове и ограничението за размер.Отваряне на изображението в пълен размер
Прегледът на изображение като прикачен файл с бутоните за увеличаване, намаляване и завъртане горе вдясно.
Прегледът на изображение: увеличаване, намаляване, завъртане — горе вдясно. При това нищо не се сваля.Отваряне на изображението в пълен размер
Прегледът на PDF в същия прозорец, с преглед на страниците отляво и лентата с бутони на четеца на PDF отгоре.
PDF се отваря по същия начин — без сваляне, с преглед на страниците, увеличение и печат.Отваряне на изображението в пълен размер
4

История на заявката

Разделът „History“ в заявката отговаря на въпроса зад всяко проследяване: кой какво е променил и кога? Всеки ред назовава човека, полето, зачеркнатата стара стойност, новата зад нея и часа с точност до секундата. Най-новият запис е най-отгоре.

Записите се пишат без вашето участие — при промени на статуса, приоритета, възлагането, категорията, местоположението, наблюдателите, заглавието и описанието, както и при създаването („Ticket opened“), при всеки коментар и при всеки качен файл. Числото на раздела ви казва предварително колко движение е имало по случая.

Историята не може да се редактира и не може да се изключи. Точно това я прави полезна: тя е причината една заявка да не може да се изтрива поотделно, и тя пътува в архивния файл, когато заявката бъде архивирана.

При коментар историята записва само, че той е добавен, редактиран или изтрит. Текстът живее в раздела „Comments“. Вътрешен коментар също се показва в историята, но само за оператори и администратори.

Разделът „History“ със записите на тази заявка: файлове, коментари, промени на статуса, приоритет, възлагане и най-долу откриването — с два реда най-отгоре, написани от правило.
Ограден в червено, разделът с броя. При „Status“ и „Priority“ виждате зачеркнатата стара стойност до новата.Отваряне на изображението в пълен размер
5

Работен поток със статуси с настройваеми статуси и преходи

Статусът казва къде стои една заявка в момента. Дванадесет статуса идват със системата — Open, Assigned, In Progress, Waiting for User Response, Resolved, Closed и още. Намирате ги под „Settings → General Settings“ в раздела „Drop-down lists“ зад раздела „Status“; „+ Add status“ създава собствен, „Edit status“ отваря съществуващ.

Важната част е разликата между името и значението. В редактора на един статус, под „Meaning of this status“, има три превключвателя: „Counts as resolved“, „Counts as closed“ и „Waiting for the requester“. Само тези превключватели казват на системата как да се отнася към един статус.

Можете да преименувате всеки статус, включително тези, които идват със системата: най-долу в редактора, под „Translations“, има поле „Name“ за всеки език — впишете там това, което вашите хора трябва да четат. Техническото име зад него остава непокътнато и точно затова нищо не се чупи: автоматизацията, отчетите и превключвателите по-горе висят на това име, а не на вашия надпис. Така „Resolved“ може да стане „Done“.

Изтриването обаче не важи за всички. Осем статуса носят знака „Mandatory“ в списъка — Open, Assigned, In Progress, Resolved, Closed, Reopened, Waiting for approval и Rejected. Те могат да бъдат преименувани и пренаредени, но не и премахнати; опитът завършва с ясно съобщение. Това не е там, за да ви дразни: на тях висят процеси, които иначе биха спрели без дума — например автоматичното затваряне, което се нуждае от статус „решена“ като отправна точка.

Два статуса принадлежат на самата система: „Waiting for approval“ и „Rejected“ носят знака „System only“. Те произлизат от процес на одобрение и никой не бива да може да твърди на ръка, че е отхвърлено нещо, което никога не е било подадено за решение.

Какво правят трите: статус, който се брои за решен, затваря заявката сам след 24 часа. Статус, който се брои за затворен, е крайното състояние, в което се премества заявката. А „Waiting for the requester“ означава точно това: чакаме заявителя — не друг екип и не доставчик на услуга. Това е отметката, на която спира часовникът на SLA, ако сте го настроили така.

Под това стои „Allowed transitions to new status“. Тук отмятате кои статуси могат да бъдат достигнати от този. Оставете всичко празно и нищо не е ограничено; отметнете нещо и всеки друг път е затворен. Така се изгражда поток, който не може да бъде прескочен — например: от „Open“ може да се отиде само към „In Progress“ или „Assigned“, но не направо към „Closed“.

Останалите превключватели в редактора са дребни неща с голямо действие: цветът за списъка, „Sort order“ за реда, „Show status in new ticket form“ (да може ли изобщо този статус да се избира при създаване на заявка?), „Requires comment in dialog“ (принуждаване към причина) и „System only“ за статуси, които само самата система може да поставя.

До четири статуса се показват в заявката като бутони под „Change Status to:“. Избирате ги в редактора с превключвателя „Set as primary status (max. 4)“. По фабрична настройка това са In Progress, Waiting for User Response, Waiting for Service Provider Response и Resolved. Всички останали статуси са под „More statuses“.

Общите настройки с ограден в червено раздел „Status“ и списъка на всички статуси.
„Settings → General Settings“, раздел „Status“: всеки статус с техническото си име и отметките си.Отваряне на изображението в пълен размер
Диалогът „Edit status“ с превключвателите под „Meaning of this status“ и списъка „Allowed transitions to new status“.
В редактора: вид и поведение отгоре, значението в средата, позволените преходи най-долу.Отваряне на изображението в пълен размер
7

Основните и подкатегориите се настройват свободно за всеки екип

Преди да започнете: Нужен ви е поне един екип. Страницата с категории е кръстена на своя екип, затова тя съществува едва след като сте създали такъв.

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

Намирате ги под „Settings“ като запис „<име на екипа> Categories“. В примера екипът се казва „Helpdesk“, затова записът гласи „Helpdesk Categories“.

Страницата има три карти: „Main categories“, „Subcategories“ и „Links“. Най-бързото начало: въведете английското име в полето „EN (required)“ и щракнете върху „+ New main category“ или „+ New subcategory“. Всичко останало превеждате по-късно наведнъж на страницата за преводи — за това тук няма какво да се подготвя.

Ако ви предстоят много категории, поемете по пътя през файла: „Export JSON“ изтегля структурата — при прясно инсталирана система файлът е празен и само ви показва подредбата. Попълвате го (на ръка или с помощта на изкуствен интелект), запазвате го и го качвате отново през „Import JSON“. Това не е начин за преименуване: име променяте в полето на съответната категория и потвърждавате със „Save“ до него — страницата също го казва.

Третата карта, „Links“, е мястото, където се върши истинската работа. Изберете отгоре основна категория, отметнете отдолу подкатегориите, които спадат към нея, и запазете със „Save links“. Хитростта: една подкатегория може да виси на няколко основни категории. Така „Malfunction“ ви трябва само веднъж и я използвате повторно за принтер, мрежа, заседателна зала и лаптоп.

От този момент категориите са налични в заявката. Изтриването може да не успее, докато заявки още използват дадена категория — това е нарочно, иначе старите заявки биха загубили класификацията си. Ако премахнете връзка, заявките, които използват тази двойка, все още могат да бъдат запазени. Само новоизбрана категория се проверява спрямо връзките.

Ако предадете заявка на друг екип, класификацията ѝ остава — дори когато новият екип изобщо няма тези категории. Тогава тя стои в полето заедно с произхода си, например „Meeting-Room · from Helpdesk“, и е показана в сиво: новият екип вижда какво е било досега случаят, но не може сам да зададе този запис. За да я преподредите, избирате от собствения си списък — и тогава системата иска основна и подкатегория заедно.

Отвореното меню с настройки с ограден в червено запис „Helpdesk Categories“.
Под „Settings“ записът е кръстен на екипа — тук „Helpdesk Categories“.Отваряне на изображението в пълен размер
Страницата „Settings · Manage categories“ с картите „Main categories“ и „Subcategories“.
Това е страницата: основните категории отляво, подкатегориите отдясно. Картата „Links“ стои по-надолу на същата страница — тя следва след малко.Отваряне на изображението в пълен размер
Полето „EN (required)“ с думата „Beamer“ и бутонът „New main category“, и двете оградени в червено.
Едно по едно: английско име в полето „EN (required)“, после щракване върху „+ New main category“ под него. В картата „Subcategories“ бутонът се казва „+ New subcategory“.Отваряне на изображението в пълен размер
Картата „Main categories“ с оградените в червено бутони „Export JSON“ и „Import JSON“.
За много наведнъж: изтегляте структурата, попълвате я, качвате я отново. Картата „Subcategories“ до нея има същите два бутона.Отваряне на изображението в пълен размер
Картата „Links“: избран е „Printer“, отметнати са подкатегориите Consumables, Malfunction и New request.
„Printer“ е избран, съответните подкатегории са отметнати, „Save links“ — „Malfunction“ виси едновременно на три други основни категории.Отваряне на изображението в пълен размер
8

Как е дошла заявката

Всяка заявка носи канал. Той стои във формуляра и по-късно на картата „Actions“ под „How the request came in“ и отговаря на въпрос, който бързо става важен в отчетите: работата идва през портала или по телефона?

Можете да изберете само това, което човек знае, а системата не: „Phone“ и „Entered by an agent“. Другите две стойности се задават от самата система — „Self-service“, когато заявителят е създал заявката в портала, и „E-mail“, когато тя е израснала от входящ имейл. Когато оператор създава заявка, формулярът започва с „Entered by an agent“.

Зададен от системата канал не може да бъде променен от никого по-късно. Тогава полето гласи „Recorded by the system. It cannot be changed.“ Иначе полето би загубило точно твърдението, заради което съществува. В обратната посока, при заявка, записана по телефона, можете да променяте всичко останало.

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

„E-mail“ изисква свързана пощенска кутия, което е част от изданието Professional. Другите три канала съществуват и в двете издания.

Частта от формуляра със статус, приоритет и отворения списък на полето „How the request came in“, ограден в червено.
При създаване на заявка каналът стои между приоритета и наблюдателите. Предлагат се само „Phone“ и „Entered by an agent“.Отваряне на изображението в пълен размер
Картата „Actions“ на заявка, полето „How the request came in“ гласи „Phone“ и е оградено в червено.
В заявката каналът стои на картата „Actions“ — тук случай, който оператор е записал след телефонен разговор.Отваряне на изображението в пълен размер
10

Избор на колоните в списъка със заявки

Всеки сам подрежда своя списък със заявки. За целта до „Filter“ стои бутонът „Columns“. Той отваря диалога „Choose columns“.

В диалога отмятате всяка колона, която искате да виждате. Стрелките до нея задават реда. „#“ и „Title“ са винаги включени. Ширината на колона променяте в самия списък, като плъзнете ръба на заглавието ѝ.

„Save“ запазва избора ви във вашия потребителски профил. Затова той важи на всеки компютър и остава и след като излезете. „Default columns“ връща списъка към фабричната настройка.

Когато няма достатъчно място за всички колони, първи отпадат тези най-вдясно. „#“, „Title“ и „Status“ остават винаги. Затова преместете напред това, което е най-важно за вас.

С Professional се предлагат и собствените ви полета. Те се появяват в диалога със собственото си име, тук например „Asset tag“.

Клиентите могат да подредят списъка си по същия начин, но им се предлагат по-малко колони. „Team“, „Created by“, „Last activity“, „Status changed at“, „Deadline“, „Follow-up“ и „Time“ не са достъпни за тях. Полета, които сте скрили от клиентите, също не се появяват като колона.

На смартфон бутонът не се показва. Там списъкът показва колоните, които се побират.

Списъкът със заявки с колоните #, Title, Status, Assigned, Priority, Category и Asset tag. Бутонът „Columns“ е в червена рамка.
Тук „Assigned“ идва веднага след статуса, „Follow-up“ е изключена. „Created“ също е избрана, но вече не се побира в ширината.Отваряне на изображението в пълен размер
Диалогът „Choose columns“ с отметка и стрелки за всяка колона и бутоните „Default columns“, „Cancel“ и „Save“.
Избраните колони са най-горе в своя ред, всички останали са под тях.Отваряне на изображението в пълен размер
11

Предаване на заявка на друг екип

Само в Professional

Преди да започнете: И двата пътя изискват втори екип. Клиентът не вижда смяната в историята: за него си остава един случай с един номер, независимо колко екипа са работили по него. Новият статус „Open“ след предаването е видим за него в заглавната част на заявката.

За това заявката предлага два бутона един до друг и разликата е изписана под тях с дребен шрифт. „Involve another team“: вие оставате отговорни, другият екип работи заедно с вас в свързана заявка. „Escalate to another team“: другият екип поема.

Когато предадете, отговорността се премества, без да възниква втора заявка. Вашият екип запазва достъп за четене и може още да коментира, но вече не може да променя нищо — точно това ви казва диалогът, преди да потвърдите. Там избирате целевия екип и можете да добавите причина.

Когато привлечете екип, вашата заявка остава във вашите ръце и получава подзаявка в другия екип. Вашата преминава в статус „Waiting for other team“; щом другият екип затвори своята, вашата се връща като „Back from other team“. Така не се налага да питате дали там се е случило нещо. Прикачените файлове на подзаявката се копират във вашата заявка със знака „Internal“ и клиентът не ги вижда.

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

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

В списъка на вашия екип заявката тогава показва „Waiting for other team“, докато другият екип работи по нея. Отметката „Also show tickets this team handed over“ е включена като фабрична настройка, а изборът на всеки потребител се запазва. За другия екип заявката започва като „Open“.

Който предаде заявката, става неин наблюдател. Диалогът казва това, преди да потвърдите. Като наблюдател получавате имейл, когато статусът се промени, заявката се затвори или някой коментира. Като всеки наблюдател се премахвате с бутона „Stop observing“.

Двата оградени в червено бутона „Involve another team“ и „Escalate to another team“, с обясненията си отдолу.
Два пътя, видимо разделени: да оставите някой да работи заедно с вас или да предадете. Разликата е изписана точно на бутона.Отваряне на изображението в пълен размер
Диалогът „Escalate to another team?“ с избора на целеви екип и полето „Reason (optional)“.
Диалогът назовава последицата, преди да потвърдите: няма втора заявка, достъпът за четене остава, само новият екип може да променя нещо.Отваряне на изображението в пълен размер
12

Собствени полета

Само в Professional

Когато в заявките ви липсва някаква информация — инвентарният номер, краят на гаранцията, разходният център — я добавяте сами. Под „Settings → Ticket Settings“, най-долу, стои картата „Custom fields“; бутонът се казва „Add custom field“.

В диалога задавате име и вид на полето: „Text“, „Multiline text“, „Integer“, „Decimal“, „Date“ или „Yes / No“. Видът решава какво може да се въвежда — поле за дата няма да приеме „следващата седмица“, и точно затова по-късно можете да правите отчети по него.

Под „Scope“ решавате къде важи полето: „All teams (including new ones)“ или „Selected teams only“. Първият избор обхваща и екипи, които още не съществуват — разлика, която забелязвате едва половин година по-късно.

Трите превключвателя под „Defaults“ са „Mandatory by default“, „Hidden for customer by default“ и „Not editable by customer by default“. Те важат за едно поле само докато за това поле нищо не е запазено в настройките на полетата на същата страница. Щом го зададете там, решават настройките на полетата.

В заявката собствените полета стоят в собствена карта, „Additional information“, между описанието и коментарите. Без шаблон формулярът показва всички собствени полета на екипа. Ако при създаване на заявка изберете шаблон, той показва точно полетата, които този шаблон изброява, в неговия ред — „само полетата, които този случай изисква“.

Освен това шаблонът може да направи едно поле задължително. Това, което администраторът е скрил от клиентите, остава скрито, дори когато шаблонът го изброява. Задължително поле, което шаблонът не изброява, не се изисква, така че това изискване не важи за заявките, създадени с този шаблон.

Колко собствени полета може да има един екип, се задава под „Settings → General Settings“ в картата „Custom fields limit“. От поле се отървавате с „Deactivate“: то изчезва от формуляра, но стойностите му остават в старите заявки — превключвателят „Show deactivated“ го връща обратно в списъка.

Картата „Custom fields“ с три полета и ограденият в червено бутон „Add custom field“.
Списъкът със собствени полета живее под „Settings → Ticket Settings“, най-долу на страницата.Отваряне на изображението в пълен размер
Диалогът „New custom field“ с име, вид на полето, обхват и трите стойности по подразбиране.
Име, вид на полето, обхват — повече от това едно поле не изисква. Трите превключвателя отдолу са стойности по подразбиране.Отваряне на изображението в пълен размер
Картата „Additional information“ в заявка с полетата „Asset tag“, „Warranty until“ и „Cost centre“.
Така операторът вижда собствените полета: собствена карта в заявката, точно под описанието.Отваряне на изображението в пълен размер
13

Наблюдатели

Понякога някой трябва да следи един случай, без да работи по него: ръководителят на екипа при деликатен въпрос, колегата, който поема следващата седмица. За това служат наблюдателите. В заявката полето „Observers“ стои на картата „Actions“, бутонът се казва „Add observer“; формулярът „Create new ticket“ има същото поле. В заявката промяна там се запазва със „Save“ в картата „Details“.

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

Наблюдателят получава имейл, когато в заявката се случи нещо: нов коментар, променен статус, ново възлагане, променени полета. Той не се изпраща веднага, а събран накуп: след последната промяна системата изчаква една минута и после изпраща ЕДИН имейл за всичко, което се е случило през това време. Така обработването на една заявка наведнъж не задейства седем имейла. Ако през това време пристигнат няколко коментара, всички те са в имейла.

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

Въвеждането на наблюдатели е част от Basic. Имейлът до наблюдателите е част от Professional, защото изисква изходяща поща. Без нея можете да въвеждате наблюдатели, но нищо не излиза. Наблюдателят може да се премахне сам с бутона „Stop observing“. За това не е нужно право да променя заявката.

Наблюдател се добавя и автоматично: който предаде заявка с „Escalate to another team“, става наблюдател. Така научава какво прави другият екип с нея.

Картата „Actions“ на заявка с ограден в червено раздел „Observers“: бутонът „Add observer“ и един оператор под него.
Наблюдателят стои на картата „Actions“. Заявката не е възложена на никого — наблюдаването и работата по заявка са две различни неща.Отваряне на изображението в пълен размер
14

Едновременна работа по една и съща заявка

Когато двама души работят едновременно по една и съща заявка, по-късното запазване може да презапише по-ранното, без никой да забележи. Затова заявката показва кой друг я е отворил. Освен това тя отхвърля запазване, което се основава на остаряло състояние.

Известието стои в заглавната част на заявката. „Marco Rossi is viewing this ticket“ означава, че Marco има отворена заявката. „Marco Rossi is actively editing this ticket“ означава, че Marco има незапазени въведени данни в нея. Това може да е започнат отговор, коментар, който се променя в момента, заглавието или описанието в режим на редактиране, напомняне, собствено поле или запис за време. Броят се и променените полета в картите „Actions“ и „Details“, докато не са запазени със „Save“. Отворен прозорец в заявката също се брои. Това са прозорците „Involve another team?“, „Escalate to another team?“, „Close ticket“, „Resolve incident“ и „Start a workflow“, както и прозорецът за коментара при смяна на статуса. След две минути без въвеждане известието отново показва „viewing“, дори ако черновата още е там.

Ако няколко колеги са отворили заявката, известието ги обобщава, например „Marco Rossi and 2 more are viewing this ticket“. Посочете известието, за да видите всички имена. Щом някой редактира активно, редът брои само хората, които редактират. Себе си не виждате никога. Ако сте отворили заявката в два раздела на браузъра, се броите веднъж. Ако заявката е отворена само в скрит раздел, след около минута изчезвате от известието на другите.

Когато колега запази промяна, известието гласи „Marco Rossi changed this ticket“, а до него е бутонът „Refresh“. Нов коментар от някой друг показва „Marco Rossi added a comment“. Ако промяната не е направена от човек, например от правило за автоматизация или от входящ имейл, известието гласи „This ticket was changed“. Известието остава, докато не презаредите.

„Refresh“ зарежда текущото състояние на заявката, например статус, възлагане, полета и история. Цялата страница не се презарежда. Незапазените ви данни остават. Започнатият отговор остава в полето за отговор, а отвореното заглавие или описание запазва текста ви. Ако запазеният текст междувременно се е променил, под полето се появява „The saved text has changed in the meantime.“. Ако тогава запазите, вашият текст заменя запазения. Бутонът „Refresh“ в заглавната част на заявката прави същото.

Ако все пак запазите върху остаряло състояние, запазването се отхвърля. Отваря се прозорецът „Ticket changed in the meantime“. Ако промяната е направена от човек, прозорецът го назовава. Промяната ви не е запазена. Щракнете върху „Refresh“, сверете промяната си с текущото състояние и запазете отново. Това важи за всяка промяна в самата заявка, например статус, възлагане, приоритет, картата „Details“ и собствени полета.

Коментарите никога не се отхвърлят. Два отговора не се презаписват един друг. И двата попадат в заявката. Същото важи за прикачените файлове и записите за време. Груповите действия в списъка със заявки и правилата за автоматизация също не се проверяват спрямо състоянието. Те променят заявката директно. Който я е отворил, вижда известието след това.

Клиентите не виждат нищо от това. Те не се появяват в известието. Не виждат и кой работи по заявката им.

Кой е отворил дадена заявка, се пази само в оперативната памет на сървъра. Около минута след като човекът е напуснал заявката, записът изчезва. Нищо от това не се записва в дневник. Заявката пази кой я е променил последен. Това сведение е част от експорта на данните на този човек. Когато човекът бъде анонимизиран, то се премахва.

Повече за това в картата: Експорт на данните на един човек, Анонимизиране на хора

Заглавната част на заявка с известието „Marco Rossi is actively editing this ticket“ под заглавието, оградено в червено.
Известието стои под заглавието на заявката. Тук Marco Rossi има незапазени въведени данни.Отваряне на изображението в пълен размер
Заглавната част на заявка с известието „Marco Rossi changed this ticket“ и бутона „Refresh“ до него, ограден в червено.
Marco Rossi е запазил промяна, докато заявката е била отворена. „Refresh“ зарежда текущото състояние.Отваряне на изображението в пълен размер
Прозорецът „Ticket changed in the meantime“ с името Marco Rossi и бутона „Refresh“, ограден в червено.
Този прозорец се появява, когато запазвате върху остаряло състояние. Промяната ви не е запазена.Отваряне на изображението в пълен размер
15

Заявки от имейл, отговори и продължения

Само в Professional

Преди да започнете: При Google/Gmail ви е нужна парола за приложение (която изисква двуфакторен вход); Google отхвърля обичайните данни за профила. Microsoft 365 в момента изобщо не работи: базовото удостоверяване за IMAP там е изключено, а паролите за приложения също не помагат.

Пощенският канал е един път с две посоки и те вървят заедно: входящият имейл се превръща в заявка, вашият отговор излиза като имейл, а отговорът на заявителя попада като коментар в същата заявка — а не във втора.

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

Всичко за това стои под „Settings → E-Mail Settings“. Горната карта, „SMTP settings“, е пътят навън: хост, порт, „Use SSL“, потребител и парола, плюс адресът и името на подателя. Със „Send test e-mail“ си изпращате мостра — първо запазете, после изпробвайте, както картата сама казва.

Картата „IMAP settings“ е пътят навътре: хост, порт, интервалът на проверка и двете папки. Не е нужно да гадаете името на папката: „Read from server“ извлича папките, които наистина съществуват във вашата пощенска кутия, „Create on server“ създава нова. Тогава полето приема пътя, който вашият пощенски сървър използва за нея — един сървър пише „INBOX/Processed“, следващият „INBOX.Processed“, а и двете означават едно и също.

Папката „Processed folder“ поема имейлите, които системата отделя настрани: имейли от блокирани податели, автоматично генерирани имейли и имейли, които работен поток премества с „Move to folder“ без собствена папка. Оставете я празна и те остават във входящата поща. Отдолу задавате кога се извършва почистването („Hour“, „Minute“) и на каква възраст може да стигне едно съобщение („Retention (days)“) — иначе пощенската кутия тихо расте.

Пощенските кутии принадлежат на екипа, а не на системата: под „Team mailboxes“ всеки екип въвежда собствения си адрес с парола. Този адрес е едновременно подателят на имейлите на този екип — така заявителят отговаря на същото място, от което се събира пощата.

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

Под „E-Mail workflows“ избирате отгоре екипа и създавате работен поток с „+ Add workflow“. Той получава име (само за вас), превключвател „Enabled“ и две твърдения за това кога важи: „Match“ решава дали всички условия трябва да са изпълнени („All conditions“), или стига едно, а „Stop after match“ прекратява изпълнението веднага щом този работен поток е съвпаднал — тогава работен поток по-надолу изобщо не идва на ред. Реда променяте със стрелките до него.

Под „When?“ стои самото условие. „Every e-mail in this mailbox“ приема всеки имейл; „Only when subject or text contains“ изисква дума в темата или в текста. „Advanced“ прави нещата точни: там избирате какво се разглежда — „Subject or body“, „Subject“, „Body“, „Sender (From)“ или „Recipient (To/Cc)“ — и как се сравнява: „Contains“, „Equals“ или „Regex“. Така отделяте например сигналите до общ адрес от всичко останало.

Отдолу стоят пет действия като превключватели. Те са същинското съдържание на работния поток — каквото не е включено, не се случва:

„Create or append ticket“ превръща имейла в заявка — или го добавя като коментар към съществуваща, когато означението е в темата. Без това действие имейлът никога не става случай.

„Set fields“ задава приоритет, статус, основна и подкатегория, отговорен екип и изпълнител още при създаването на заявката. Всичко, оставено на „— Keep default —“, остава такова, каквото би било без работен поток.

„Auto-reply“ е потвърждението до подателя. При изключен превключвател вашият клиент не получава потвърждение, колкото и добре да е настроено всичко останало. „Send mail“ също може да пише на подателя, както показва следващото действие.

„Send mail“ изпраща допълнителен имейл: или до подателя на входящия имейл, или до избрани членове на екипа и постоянни адреси. Той има собствени „Send conditions“ — оставете ги празни и той излиза при всяко изпълнение на този работен поток.

„Move to folder“ подрежда обработения имейл в папка. Оставете полето празно и важи общата „Processed folder“ от IMAP настройките по-горе.

Действието „Auto-reply“ в подробности: темата съставяте от блокове. „Original subject {originalSubject}“ поема темата на входящия имейл, „Ticket reference {ticketTag}“ вмъква означението на случая — заедно те дават нещо като „Printer problem [TICKET-99-a1b2c3]“.

Означението не се добавя само. То се появява само там, където поставите {ticketTag}. {ticketId} вмъква само голия номер и системата не разпознава отговор по него. Без означението в темата отговорът все пак се свързва, ако носи заглавките за отговор на потвърждението. Само имейл без нито едно от двете става нова заявка.

Текстът отдолу е вашето съобщение за потвърждение. Напишете го на английски: то минава през същия износ и внасяне както всеки друг текст и само така може да бъде преведено на другите езици. Оставете го празно и системата изпраща собственото си съобщение по подразбиране. Тук са позволени същите запазени места.

„Reply language“ решава на кой език излизат темата и текстът: „Standard English“ използва английски, „Fixed language“ — избран от вас език, „Assigned agent's language“ — езика на възложения оператор, а „Team default language“ — езика по подразбиране на екипа. Самите преводи се поддържат на езиковата страница.

Един съвет, който системата изписва и над картата: всичко, което принадлежи на един случай, принадлежи в ЕДИН работен поток. Само действията в рамките на един и същ работен поток познават току-що създадената заявка — затова потвърждението може да назове нейния номер, а действие от втори работен поток не може.

Целият пощенски канал — входящ и изходящ — е част от изданието Professional. В Basic системата нито изпраща, нито получава имейли; заявките там се създават през портала, по телефона и от оператора.

Картата „SMTP settings“ с хост, порт, потребител, парола, адрес на подателя и бутона „Send test e-mail“.
Пътят навън. Всяко поле носи обяснението си отдолу — портовете 587 и 465 са изрично назовани там.Отваряне на изображението в пълен размер
Картата „IMAP settings“ с оградените в червено бутони „Read from server“ и „Create on server“.
Не въвеждайте папката, а я извлечете: „Read from server“ изброява истинските папки, „Create on server“ създава нова под входящата поща.Отваряне на изображението в пълен размер
Разделът „Team mailboxes“ с пощенските кутии на екипите Helpdesk и Network, адресите оградени в червено.
По една пощенска кутия за екип. Адресът е и подателят — затова той живее тук, а не в общите настройки.Отваряне на изображението в пълен размер
Работен поток с името си, „Match“, „Stop after match“, условието под „When?“ и оградените в червено пет превключвателя за действия.
Петте действия са оградени в червено. В този пример „Create or append ticket“, „Auto-reply“ и „Move to folder“ са включени — „Set fields“ и „Send mail“ са изключени. Без такъв работен поток пощенската кутия изобщо не се проверява.Отваряне на изображението в пълен размер
Действието „Auto-reply“ с ограденото в червено поле за тема, градивните блокове, английския текст и избора на език за отговор.
Темата съдържа блоковете „{originalSubject} {ticketTag}“ — точно по тях системата разпознава по-късно отговора на клиента. Отдолу текстът и езикът за отговор, тук този на възложения оператор.Отваряне на изображението в пълен размер

Статус на оператора (достъпност)

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

1

На разположение, зает, отсъстващ

Всеки оператор има едно от три състояния и сам си го задава, в потребителското меню долу вляво в страничната лента. Трите записа стоят под заглавието „Availability“.

Точка показва състоянието. „Available“ носи зелена точка, „Busy“ — кехлибарена, „Away“ — празен пръстен.

Трите се различават не само по цвят, но и по запълване, така че и човек, който трудно различава цветове, вижда разликата.

Вашата собствена точка стои върху снимката на профила ви долу вляво, така че не е нужно да отваряте менюто, за да я видите.

Когато възлагате заявка, състоянието стои след името. Ако е записан край на отсъствието, и той стои там.

Оператор, който не е на разположение, остава избираем и само е отбелязан като такъв. Дали заявката все пак да отиде при него, е ваше решение.

Винаги ви се предлагат само операторите на екипа, на който принадлежи заявката.

Само операторите и администраторите имат състояние. Клиентът няма такова.

Повече за това в картата: Възлагане на няколко заявки на един оператор наведнъж

Потребителското меню в страничната лента с трите състояния „Available“, „Busy“ и „Away“ и отметка на текущото.
Собственото потребителско меню на оператора. Трите състояния стоят най-отгоре, действащото носи отметка. Същата точка стои върху снимката на профила отдолу.Отваряне на изображението в пълен размер
Отвореният избор „Assign to“ в една заявка, с операторите на екипа и бележката „Away until“ на един запис.
Червената рамка стои върху записа на Lena Chen. След името стоят нейното състояние и краят на отсъствието. Тя остава избираема. Предлагат се само операторите на екипа, на който принадлежи заявката.Отваряне на изображението в пълен размер
2

Болничните и отпуските се въвеждат от администратор

Който е болен, рядко се отписва предварително. Затова администраторът може да зададе състоянието за друг човек, във формуляра за редактиране на профила под „User management“.

Формулярът има две полета за това. „Availability“ съдържа състоянието, „Away until“ съдържа края на отсъствието.

Второто поле се появява само при „Away“. За „Busy“ или „Available“ няма край за въвеждане.

Без дата отсъствието продължава, докато някой не го прекрати. С дата то приключва само. Указанието под полето го казва: „Leave empty for an absence without a set end.“

Дата в миналото не се приема. Тя би изтекла веднага и колегата ви пак би стоял в списъка като на разположение.

И двете полета се появяват само за оператори и администратори. Ако в същия формуляр зададете ролята „Customer“, те изчезват.

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

Формулярът за редактиране на профил с полето „Availability“, зададено на „Away“, и полето „Away until“ с дата.
Червените рамки стоят върху двете полета. Те стоят най-долу във формуляра и само за оператори и администратори.Отваряне на изображението в пълен размер
3

„Busy“ се нулира само след един час

„Busy“ трае един час. След това операторът е отново на разположение, без да прави каквото и да е. Запазването на формуляра на потребителя не удължава „Busy“.

Менюто показва оставащото време до състоянието, например „60 min left“.

Часът е неизменен. Той е предпазна мрежа срещу забравяне, а не работно правило. Който е недостъпен по-дълго, избира „Away“.

Нулирането е момент във времето, а не задача. Профилът съдържа мига, в който състоянието приключва, а самото състояние се изчислява, когато някой го прочете. Ако сървърът е бил изключен през този час, операторът просто след това е отново на разположение. Не остава натрупване, което фонова услуга да наваксва.

„Away“ изтича само ако е записан край. Без такъв то остава, докато някой не го промени.

Когато операторите сами се поставят на „Away“, те не могат да въведат край. Само администратор раздава крайна дата. Ако такава вече е зададена, тя остава, когато операторът отново избере „Away“.

Потребителското меню със състоянието „Busy“, оставащото време „60 min left“ и отметката до него.
Червената рамка стои върху действащото състояние. Отметката стои вдясно, оставащото време до състоянието. Точката върху снимката на профила сега е кехлибарена.Отваряне на изображението в пълен размер
4

Няма история на достъпността и няма оценяване по човек

Системата помни само кое състояние действа в момента. Тя не записва кой кога е бил зает или отсъстващ.

Затова списъкът с потребители показва състоянието към момента и нищо повече. Няма колона с история и няма отчет за присъствието.

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

История и не е нужна. Състоянието отговаря на един-единствен въпрос: на разположение ли е този колега в момента? „Busy“ приключва само след един час.

Колко заявки има един оператор, виждате в списъка със заявки, където „Assigned to“ филтрира по един човек. Колко дълго някой е отсъствал, не е записано никъде.

Списъкът с потребители със състоянието на всеки оператор веднага след името и колоните Name, Email, Team, Role и Actions.
Червените рамки стоят върху двама от тримата оператори, които не са на разположение. Списъкът показва състоянието към момента. Няма колона с история.Отваряне на изображението в пълен размер

Автоматично възлагане на заявки

Новата заявка може да получи отговорник веднага. Системата използва достъпността, обяснена в предишния блок, разпределението се включва за всеки екип поотделно и по фабрична настройка е изключено. Целият този блок е част от Professional.

1

Разпределението принадлежи на екипа

Само в Professional

Без разпределение всяка нова заявка попада в общия куп. Някой трябва да я вземе или някой трябва да я раздаде, и двете работят, докато някой гледа.

Включете разпределението и всяка нова заявка получава отговорник още при създаването си. Това става веднага, а не няколко минути по-късно. Заявка, която е създадена направо като решена или затворена, не се разпределя.

Настройката стои на екипа под „Settings → Teams“ и всеки екип решава сам за себе си. Един екип може да разпределя, докато съседният екип работи от общия куп.

По фабрична настройка всеки екип стои на „Off“. Съществуващата среда не променя поведението си само защото функцията съществува.

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

Разделът „Automatic assignment“ в диалога на екипа Helpdesk, зададен на „Round robin“, с две обясняващи изречения отдолу.
Настройката стои на екипа. Под полето едно изречение обяснява избраната процедура, а под него стои кой бива прескачан.Отваряне на изображението в пълен размер
Отвореното поле за избор с трите му записа „Off“, „Round robin“ и „Least load“.
Три записа за избор. „Off“ е фабричната настройка.Отваряне на изображението в пълен размер
2

Последователно или по най-малко натоварване

Само в Professional

Има две процедури и вие избирате една за всеки екип.

„Round robin“ обикаля поред. Новата заявка отива при онзи оператор на разположение, чието последно автоматично възлагане е най-отдавна, така че който току-що се е присъединил към екипа, е първи на ред.

„Least load“ гледа бюрото. Новата заявка отива при онзи оператор на разположение с най-малко отворени заявки.

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

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

Резултатът може да се пресметне и при двете процедури. Когато двама оператори са наравно, винаги решава едно и също правило, никога случайността.

Същият раздел в диалога на мрежовия екип, зададен на „Least load“, с изречението за заявките, които се броят наполовина.
Същото поле при друг екип, тук на „Least load“. Изречението отдолу се променя заедно с настройката.Отваряне на изображението в пълен размер
3

Който го няма, не получава нищо

Само в Professional

Преди всяко възлагане разпределението пита за състоянието на оператора. „Busy“ и „Away“ се прескачат.

Заключените и изтритите профили също отпадат, както и всеки, който не е член на екипа, на който принадлежи заявката.

Ако никой не е на разположение, заявката остава без отговорник, а създаването ѝ въпреки това минава нормално.

Това е нарочно. Всички виждат заявка в общия куп, а никой не вижда заявка, която стои при отсъстващ човек.

Историята на заявката носи причината: там пише „Nobody available“ вместо име.

Повече за това в картата: На разположение, зает или отсъстващ

Историята на заявка със запис „Auto-assignment“, който вместо човек назовава „Nobody available“.
Никой не е бил на разположение и заявката е останала в общия куп. Червената рамка стои върху записа, който назовава причината.Отваряне на изображението в пълен размер
4

Какво засяга разпределението и какво не

Само в Professional

Разпределението работи по всеки път, по който възниква заявка, а това включва и заявките от входящата поща. Изключението е груповият инцидент: той остава при този, който го е създал.

То работи по същия начин и по подзаявките на едно искане: всяка се разпределя вътре в екипа, който я получава.

Заявка, която човек е възложил, разпределението никога не докосва. Ако при създаването сами изберете отговорник, вашият избор остава.

Всяко автоматично възлагане се записва в историята на заявката, с „Auto-assignment“ като автор и името на оператора до него.

Операторът получава същия имейл както при възлагане на ръка. Ако заявката още стои на „Open“, тя преминава на „Assigned“.

Повече за това в картата: Имейлът става заявка

Историята на заявка с два записа „Auto-assignment“: възлагането на оператор от екипа и промяната на статуса от „Open“ на „Assigned“.
Историята назовава автоматиката. Тя е възложила заявката и е преместила статуса заедно с това.Отваряне на изображението в пълен размер
5

Отчетът за разпределението

Само в Professional

Който пуска автоматика, трябва да може да провери какво прави тя. За това на страницата с отчети има собствена карта.

Отгоре стоят две числа. Отляво колко заявки е раздала автоматиката, отдясно колко пъти никой не е бил на разположение.

Под „Nobody available“, след „Most recent:“, стоят до 20 заявки, при които се е случило последно, и едно щракване ви отвежда там.

Отдолу стои по един ред за всеки оператор с неговото число и неговата достъпност. Редовете идват от членството в екипа.

Ред с нула следователно не е грешка. Точно за това служи таблицата.

Който седмици наред е стоял на „Away“, не е получил заявки и въпреки това е изброен, с причината до нулата.

Тази карта е дневник на машината, а не оценка на хора. Няма история на достъпността и няма отчет за това кой колко дълго е присъствал.

Операторите виждат тук само собствените си екипи и само тези, чиито „Agent Permissions“ позволяват преглед на отчетите. Без филтър по екип те виждат първия от тези екипи.

Повече за това в картата: Няма история на достъпността, няма оценяване по човек

Страницата с отчети с картата „Automatic assignment“ сред другите отчети.
Картата стои на страницата с отчети. Червената рамка показва къде да я намерите.Отваряне на изображението в пълен размер
Кутията „Nobody available“ с нейното число, обясняващо изречение и най-новата заявка, при която се е случило.
Второто число стои до първото с еднаква тежест. Отдолу стои най-новата заявка, която е останала в общия куп.Отваряне на изображението в пълен размер
Таблицата на отчета с шест оператори, техните числа и достъпността им, включително един ред с нула и бележка „Away“.
По един ред за всеки оператор. Червената рамка стои върху реда с нулата, който носи причината си до себе си.Отваряне на изображението в пълен размер

Искания със задачи и одобрение

Някои искания не са една заявка. Едно искане създава задачите си при подаването, всяка като собствена заявка в екипа, който я обработва, а одобренията са възможни, но не задължителни. Целият този блок е част от Professional.

1

Едно искане създава собствените си задачи

Само в Professional

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

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

Искането не е второ нещо за поддържане. То живее върху шаблон за заявка: под „Settings → Request workflows“ намирате всеки шаблон за заявка и закачате задачите към един от тях.

За всяка задача попълвате няколко полета. „Task“ е името, което чете заявителят, „Handled by“ е екипът, който я получава, а „Ticket title“ и „What the team has to do“ попълват заявката, която излиза от нея.

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

Задача без екип изобщо не се предлага. Полето само го казва: „Not assigned yet — this task is not offered“. Така можете да запазите план, който още не е завършен.

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

Пред „Ticket title“ стои фиксираният текст „Parent ticket title -“. Новата заявка започва със заглавието на искането, последвано от вашето заглавие, например „New colleague in accounting - Set up notebook and docking station“. Така специализираният екип вижда към кое искане принадлежи дадена задача. Ако оставите полето празно, вместо това следва името на задачата.

„Main category“ и „Subcategory“ попълват предварително категорията на новата заявка. Получавате само категориите на екипа в „Handled by“, защото заявката се създава там. Ако смените екипа, двете полета се изчистват. Задавате или двете, или нито едно, а ако останат празни, заявката се създава без категория.

Името на искането стои над задачите. С моливчето до него го преименувате. Името принадлежи на шаблона за заявка, затова се променя и под „Settings → Templates“, и във формуляра за нова заявка.

Списъкът с шаблони за заявки под „Request workflows“, всеки с броя си задачи и бутон „Edit tasks“.
Всеки шаблон за заявка на едно място, всеки показва колко задачи носи. Червената рамка стои върху пътя към плана.Отваряне на изображението в пълен размер
Планът с името на искането, моливчето за преименуване, обобщаващото изречение и първата задача.
Отгоре името на искането, с червената рамка върху моливчето за преименуване. Под него стои изречението, което обобщава плана, а след това следват задачите.Отваряне на изображението в пълен размер
Първата задача с „Handled by“, зададено на Helpdesk, категорията Notebook и New request и фиксирания текст „Parent ticket title -“ пред заглавието на заявката.
Категориите идват от екипа в „Handled by“. Заглавието на искането винаги стои пред заглавието на заявката.Отваряне на изображението в пълен размер
2

Заявителят отмята това, което му трябва

Само в Professional

Когато някой избере шаблона във формуляра за нова заявка, се появява кутията „What is needed?“ с по един ред за отмятане на всяка задача.

Има три вида, задавани за всяка задача. „Selectable, off by default“ започва празна, „Selectable, on by default“ започва отметната и може да бъде размаркирана, а „Always — cannot be deselected“ винаги се изпълнява.

Задача, която винаги се изпълнява, пак се показва, отбелязана с „(always included)“. Заявителят трябва да вижда какво се случва така или иначе.

Под кутията четете какво ще излезе от това: „Each selected item becomes its own ticket for the team that handles it.“

Клиентът също може да подаде искане, стига шаблонът да е освободен за клиенти. Превключвателят за това стои на шаблона.

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

Ако искане пристигне по имейл, то става обикновена заявка. Тогава стартирате работния поток допълнително. Това прави бутонът „Start workflow“ в заглавната част на заявката.

В диалога избирате подходящия шаблон под „Template“. Под него получавате същата кутия „What is needed?“ като във формуляра за нова заявка. Отметнете това, което искането изисква.

Под „Title“ коригирате заглавието на заявката. Заглавията на задачите започват с него. Отдолу намирате допълнителните полета на шаблона. Въведете там данните от искането. Задължителните полета носят звездичка.

С „Start“ задачите се създават точно както при искане от формуляра. Ако шаблонът изисква одобрение, заявката и нейните задачи остават заключени, докато то бъде дадено.

За всяка заявка може да се стартира само един работен поток. След това бутонът изчезва. Той липсва и при затворените заявки, и при заявките, които сами са задача. Всеки, който може да работи по заявката, може да го стартира.

Повече за това в картата: Шаблоните за заявки могат да се освобождават за клиенти поотделно

Кутията „What is needed?“ във формуляра за нова заявка с четири задачи за отмятане.
Кутията във формуляра за нова заявка на заявителя. Първият ред винаги се изпълнява и не може да бъде размаркиран, вторият е отметнат по фабрична настройка, а под тях стои в какво ще се превърне всяко отмятане.Отваряне на изображението в пълен размер
Диалогът „Start a workflow“ в заявка с шаблона, задачите за отмятане и полето за заглавие.
Диалогът в заявка. Първата задача винаги се изпълнява. Под полето за заглавие четете как ще се казват задачите.Отваряне на изображението в пълен размер
3

Напредък по искането

Само в Professional

В самото искане задачите са изброени под „Workflow tasks“, с броя до тях, например „1 of 4 done“.

Всеки ред показва името на задачата, номера на нейната заявка, екипа и изпълнителя, а името е връзка към тази заявка.

„Готово“ идва от статуса на заявката, а не от отделна отметка. Каквото се брои за затворено в списъка със заявки, се брои за готово и тук — два начина за броене на едно и също рано или късно биха се разминали.

Блокът се появява само в искане. Обикновена заявка не го показва.

Когато специализиран екип затвори своята заявка, неговият „Closing comment“ пристига в искането. Там той стои като вътрешна бележка, а първият му ред посочва номера и името на задачата. Клиентът не вижда тази бележка.

Данните за достъп и всичко, което операторът на искането трябва да предаде нататък, принадлежат в заключителния коментар. Всички останали коментари на специализирания екип остават в неговата собствена заявка. Ако екипът затвори без коментар, не се създава бележка.

Блокът „Workflow tasks“ в искането с четири задачи, номерата на заявките им и екипите.
Червената рамка стои върху реда с броя. Отдолу всяка задача показва в коя заявка и в кой екип седи; отметката отляво идва от статуса.Отваряне на изображението в пълен размер
Вътрешна бележка в искането: заглавният ред „Task #… (Notebook and docking station) was closed with this note:“ и под него заключителният коментар на специализирания екип.
Екипът Helpdesk затвори задачата със заключителен коментар. В искането той стои като вътрешна бележка със знака „Internal“.Отваряне на изображението в пълен размер
4

Едно одобрение за цялото искане

Само в Professional

Едно одобрение обхваща цялото искане, а не всяка отделна задача. Осем заявления са един имейл до ръководителя, а не осем.

Това настройвате под „Approvals“ в същия план, а изречението над него казва правилото: „One approval covers the whole request. Add a second stage only when single tasks need their own release.“ Всеки етап има пет полета: „Name“ е името на етапа, „Covers“ казва за какво важи, „Decided by“ казва откъде идва одобряващият, „Approver“ съдържа човека, а „Remind after (hours)“ задава напомнянето.

Одобряващият няма нужда от профил в системата за заявки: въвеждате имейл адрес и той решава през връзка. Затова ръководител, който одобрява два пъти на тримесечие, не струва място за оператор.

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

Страницата носи името на етапа като заглавие. Тя показва номера и заглавието на искането, заявителя, а под „This decision covers“ задачите, за които е решението, с поле за коментар и двата бутона отдолу.

Връзката не трае вечно и страницата назовава срока: „Please decide by …“. Тя е валидна 14 дни. След това страницата казва само, че връзката е невалидна или е изтекла, и администратор изпраща искането отново с „Reassign“.

Решение не може да бъде оттеглено и след това страницата го казва: „A decision cannot be changed.“

Разделът „Approvals“ на плана с два етапа, всеки с име, адрес и напомняне.
Два етапа в един план: първият обхваща цялото искане, вторият само задачите, които сочат към него. Одобряващият е адрес, а не профил.Отваряне на изображението в пълен размер
Имейлът за одобрение в пощенската кутия с една-единствена връзка към страницата за решение.
Така искането стига до одобряващия. Имейлът съдържа една връзка и нищо друго за щракване; решението се случва на страницата зад нея.Отваряне на изображението в пълен размер
Страницата за решение за етапа „Head of IT“ с искането, заявителя, обхванатата задача, полето за коментар и бутоните „Approve“ и „Reject“.
Страницата за решение. „This decision covers“ казва за какво става дума. Одобряващият не е влязъл и няма профил.Отваряне на изображението в пълен размер
5

Втори етап за отделни задачи

Само в Professional

Някои задачи изискват собствено разрешение. Достъпът отвън не е същото като един лаптоп.

За това добавяте втори етап и го избирате на задачата под „Extra approval“. Докато там пише „None — the request approval is enough“, разрешението на искането е достатъчно. Двата етапа се питат едновременно, а не един след друг. Един етап се пита само ако някоя от избраните задачи го засяга. Етапът за цялото искане се пита винаги.

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

Дотогава задачата е заключена. Нейната заявка стои на „Waiting for approval“ и няма изпълнител. Вместо бутони за статус на картата пише „This ticket is waiting for approval and cannot be worked on yet.“ Никой път не ѝ дава изпълнител преди това.

Заключването важи и за груповите действия в списъка със заявки. Изберете там такава заявка и прочитате причината: „This ticket is waiting for approval and cannot be worked on yet.“

Заявката все пак се създава веднага, за да вижда специализираният екип какво предстои и никой да не следи искането.

Картата с действия на заключена задача със статус „Waiting for approval“ и бележката, че по задачата още не може да се работи.
Задачата, която чака своя етап. Червената рамка стои върху текущия статус. Над него картата казва защо не може да се избере статус.Отваряне на изображението в пълен размер
6

Напомняне, но без разрешение по време

Само в Professional

За всеки етап можете да зададете напомняне, посочено в часове.

Ако не дойде отговор, след това време същият имейл излиза отново, носейки същата връзка като първия. Който е запазил първия имейл, все още може да го използва.

Без напомняне искането просто чака, без да пита отново.

Това, което не съществува, е разрешение по изтичане на срок. Под полето пише точно това: „A request is never approved automatically. If nobody reacts, it keeps waiting.“ Срок, който сам дава съгласие, не би бил одобрение, а формалност.

Един етап на одобрение с ограденото в червено поле за напомняне, посочено в часове.
Напомнянето принадлежи на етапа и се посочва в часове. Оставете го празно и системата не пита отново.Отваряне на изображението в пълен размер
7

Отказът стига до заявителя заедно с причината си

Само в Professional

Отказът изисква причина. Без текст страницата не приема отказа.

Полето казва къде отива текстът: „Comment (required when you reject — the requester will see it)“. Вътрешна бележка не спада тук.

Заявителят получава имейл с причината и не трябва да пита защо нищо не се движи.

Одобрението не изисква причина. То е очакваният изход.

Ако откаже само вторият етап, отказът засяга само задачите на този етап. Останалата част от искането продължава.

Отказаната задача получава статус „Rejected“ и се брои за приключена, така че искането да не виси вечно на нещо, което никога няма да пристигне.

Щом искането бъде отхвърлено, другите одобряващи не получават повече имейли. Тогава тяхната връзка гласи „This request has already been rejected. Your decision is no longer needed.“ В списъка в заявката техният етап показва „No longer needed: the request was rejected.“

Страницата за решение след отказа, с „You rejected this request.“ и бележката, че решение не може да бъде променено.
След решението: страницата потвърждава какво е направил одобряващият и казва, че то остава.Отваряне на изображението в пълен размер
8

Одитната следа и одобряващият в отпуск

Само в Professional

В искането „Approvals“ показва по един ред за етап с одобряващия, състоянието, а при открито искане и колко дълго вече чака.

След решението редът показва кога е взето и с какъв коментар. Това е одитната следа и тя остава при случая.

Ако одобряващият е в отпуск, администратор премества искането към друг адрес. Бутонът се казва „Reassign“ и се появява само докато искането е открито.

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

Преразпределянето създава нова връзка, а старата умира веднага — дори ако някой я е препратил.

Самото преместване се появява в същия списък: кой го е преместил, кога, от кого към кого.

Никой не може да реши от чуждо име. Връзката е единственият път, а кой я е получил, е записано при случая.

Диалогът „Reassign“, който пита за новия адрес, с попълнено поле.
Диалогът пита за адреса, към който да отиде искането вместо това. Потвърждавате със същата дума, която го е отворила.Отваряне на изображението в пълен размер
Списъкът „Approvals“ с одобрения първи етап, отказания втори етап, двата коментара и бележката за преразпределянето.
Двата етапа с решението, часа и коментара си. Червената рамка стои върху етапа, който е бил преместен, а под него стои кой го е преместил от кого към кого.Отваряне на изображението в пълен размер

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

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

1

Шаблони за отговори: текст и действия по полета (статус, възлагане, приоритет …) с един избор

Преди да започнете: Управлението и прилагането са две различни права. Администраторите и операторите могат и двете още от началото. Прилагането е отворено за всеки, който може да работи по заявката. Действията на шаблона изискват и правото да се управлява заявката, затова екип, който е имал заявката по-рано, може да коментира, но не може да изпълнява действия. Дори когато една роля не може да управлява настройките, тя пак може да приложи шаблон.

Шаблоните живеят под „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“ или фиксиран адрес. Другите действия и прикачените файлове на шаблона не се изпълняват там. Заявката се затваря както обикновено.

Страницата „Templates“ с оградените в червено бутони „Add reply template“ и „Add ticket template“.
Видът се избира при създаването: два бутона вместо превключвател. Под тях шаблоните лежат отворени — всеки със своя знак и своя обхват.Отваряне на изображението в пълен размер
Трите реда с действия на един шаблон за отговор, оградени в червено, с обясняващото изречение в синьо отдолу.
Три действия в един шаблон: статус, възлагане на този, който го прилага, напомняне след три дни. Изречението отдолу казва същото наведнъж.Отваряне на изображението в пълен размер
2

Предложените действия могат да се размаркират поотделно преди изпращане

В отворена заявка бутонът „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“. Този превключвател е предложението за всеки случай; елементът в заявката е решението за този случай.

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

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

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

Запазени места (заявител, номер на заявка, заглавие …) – вмъкването на шаблона поставя истинските стойности в текста

Текстът на отговора може да използва пет запазени места; списъкът стои под полето: „{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}“ не работят в темата и се отхвърлят също така.

Полето „Reply text“ на шаблон със запазени места в текста, оградено в червено, и списъкът с позволените запазени места отдолу.
Така изглежда шаблонът в настройките: със запазените места, а не със стойности. Редът отдолу изброява кои съществуват.Отваряне на изображението в пълен размер
Същият шаблон, приложен в заявка: редакторът на коментари съдържа изписани името, заглавието и означението на заявката.
Същият текст в заявката: „Hello Amir Khan“, заглавието на заявката, означението „[TICKET-8-…]“ — и като подпис операторът, който е вмъкнал шаблона. Още нищо не е изпратено.Отваряне на изображението в пълен размер
4

Отговорът по избор се изпраща като имейл до заявителя

Само в Professional

Преди да започнете: Пощенският канал като цяло е Professional — както входящият, така и изходящият. Освен това пощенската кутия на екипа трябва да има включено изпращане при действия по заявка. Ако няма, елементът за имейл изобщо не се предлага в заявката; действията на шаблона се изпълняват както винаги, само имейлът отпада. За това няма и предупреждение.

Превключвателят „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“ не добавя файлове.

Пощенският блок на шаблон с ограден в червено превключвател „Send the comment as e-mail“, получателя и темата.
Превключвател, получател и тема. Темата съдържа „{ticketTag}“ — означението, по което се разпознава отговорът на клиента.Отваряне на изображението в пълен размер
5

Създаване на шаблон направо от съществуваща заявка

Повечето шаблони не се раждат на чертожна дъска, а в мига, в който напишете същия отговор за втори път. Затова всеки коментар в заявка носи вдясно малка иконка с лист, наречена „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“ създава шаблона; тогава отметнатите прикачени файлове се копират и се потвърждават със съобщение.

Коментар в заявка с оградената в червено иконка с лист „Make template“ до бутоните за редактиране и изтриване.
Пътят започва при коментара, а не в настройките: иконката с лист вдясно от отговора, който искате да използвате повторно.Отваряне на изображението в пълен размер
Диалогът „Make a template from this comment“ с двата прикачени файла на заявката, нито един от които не е отметнат.
На тази заявка висят два прикачени файла, нито един не е отметнат. Единият от тях е собствената снимка на екрана на клиента — тя не спада в библиотека със стандартни отговори.Отваряне на изображението в пълен размер
6

Черновите остават лични, докато не бъдат публикувани; обхват за екип или общ

„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.“ Това е удобният път към вариант, без на другите да се предлага полуготовата версия.

Главата на шаблон със знаците „Reply template“ и „Draft“, ограденото в червено поле „Applies to“ и също ограденият превключвател „Draft“.
Този шаблон принадлежи на службата за поддръжка и е чернова. Никой освен автора му не го вижда.Отваряне на изображението в пълен размер
7

Шаблони за заявки: предварително попълнен формуляр за нова заявка (заглавие, описание, категория, приоритет, екип)

Шаблонът за заявка попълва формуляра „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“. Той показва формата на нещата и сам по себе си не прави нищо — преправете го или го изтрийте.

Редакторът на шаблон за заявка с оградените в червено полета за заглавие, целеви екип, категория и приоритет.
Пет предварителни попълвания плюс описанието. Полето „Owning team of the new ticket“ не е обхватът над него — то казва къде отива заявката.Отваряне на изображението в пълен размер
Формулярът „Create new ticket“ след избор на шаблон: бутонът „Template“ и предварително попълненото заглавие са оградени в червено.
Същият формуляр както винаги, само че вече попълнен: заглавие, екип и приоритет са налице. Категорията и описанието следват по-надолу на същата страница.Отваряне на изображението в пълен размер
8

Шаблоните за заявки могат да се освобождават за клиенти поотделно

Превключвателят „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; тяхната карта се казва „Собствени полета“. Освобождаването на шаблон за клиенти работи във всяко издание.

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

Ограденият в червено превключвател „Offer this template to customers“ с указателния си текст.
По един превключвател на шаблон — тук той е включен, така че този шаблон се предлага на клиентите. Указанието казва направо, че черновата остава скрита независимо от това. Отдолу стои изборът на полета.Отваряне на изображението в пълен размер
Формулярът за нова заявка, както го вижда клиентът, с отворен списък с шаблони и освободените шаблони в него.
Същият списък от страната на клиента: той съдържа само освободените шаблони. Другите шаблони за заявки на тази инсталация не се появяват тук.Отваряне на изображението в пълен размер
9

Всяко използване е проследимо в историята на заявката

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

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

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

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

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

Историята на заявка с ограден в червено запис „Template“, който назовава приложения шаблон, и редовете на неговите действия.
По един запис на използване, с оператора като негов автор. Всяко изпълнено действие записва свой собствен ред. Записът за шаблона казва откъде идват те.Отваряне на изображението в пълен размер

Автоматизация и напомняния

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

1

Ръчно напомняне в заявка (дата + бележка, филтри Today/This week/Overdue)

Преди да започнете: Само операторите и администраторите виждат напомнянето и заявката го казва: „Only agents and administrators see this — the requester never does.“ Заявителят никога не го вижда.

Напомнянето стои в заявката, в картата „Details“ вдясно, под сроковете. Докато не е зададено, пише „No follow-up set.“ с бутон „Set follow-up“. Избирате дата и час („Date and time“) и добавяте бележка („Note (optional)“, примерен текст „Why is this coming back?“). След това бутоните гласят „Change“ и „Remove“.

Стойността е в бележката. След две седмици само датата няма да ви каже защо тази заявка е отново на бюрото ви. Затова и бележката виси на датата: премахнете датата и бележката си отива с нея — причина без дата е нещо, което никой никога повече не би видял.

Над списъка със заявки стои ред „Follow-up:“ с четири бутона — „No filter“, „Today“, „This week“ и „Overdue“ — а самият списък има колона „Follow-up“. Той нарочно не живее в свития блок с филтри: това е въпросът, с който операторът започва деня.

„Overdue“ включва и днешните. Иначе едно напомняне би изчезнало точно в деня, в който има значение — в мига, в който часът му е минал.

Картата „Details“ на заявка с ограден в червено раздел „Follow-up“, който съдържа знака „Overdue“, бележката и бутоните „Change“ и „Remove“.
Датата на тази заявка е в миналото, оттам и червеният знак „Overdue“. Бележката казва защо заявката се връща.Отваряне на изображението в пълен размер
Списъкът със заявки с ограден в червено ред „Follow-up:“ над таблицата и също оградената колона „Follow-up“.
Три заявки на тази страница носят дата. Бутоните отгоре стесняват списъка до днес, тази седмица или просрочените.Отваряне на изображението в пълен размер
2

Правила по време – реакция на ЛИПСАТА на действие

Само в Professional

Преди да започнете: Новото правило се създава ВИНАГИ изключено — дори ако през интерфейса се опитате да го създадете включено. Правило, което минава през целия ви натрупан списък в мига на създаването, е точно произшествието, което системата ви спестява тук. То влиза в действие едва при следващото „Save“.

Правилата живеят под „Settings → Automation“. Редът под заглавието казва за какво става дума: „Rules that act when nobody else does.“ Едно правило принадлежи на екип и работи по заявките на този екип; изборът „Team“ най-горе решава кои правила гледате.

Разликата с всичко останало в системата: тези правила не реагират на събитие, а на неговата ЛИПСА. Няма отговор от заявителя три дни, няма движение цяла седмица, създадена преди четири часа и още ничия работа — за нищо от това няма щракване, което да го задейства. Точно затова никой не го забелязва.

Съобщение със зелена отметка най-горе ви казва, че проверките текат: „The automation checks every minute. 2 of 6 rule(s) are enabled.“ Без включено правило получавате предупреждението „No rule is enabled. Nothing is being checked and tickets behave exactly as before.“ — и тогава наистина не се случва нищо.

Едно правило гледа всички заявки на своя екип, колкото и да са те. При едно минаване то действа върху най-много 500 от тях. Останалите следват при следващото минаване.

Правило, което е било изключено, не наваксва. Когато го включите отново, то не действа върху това, което е станало дължимо по време на паузата. Изключение са правилата без времево условие: те наваксват. Първия път, когато едно правило бъде включено, то действа върху всичко, което показва неговият преглед.

Горната част на страницата „Automation“ с ограденото в червено съобщение за интервала на проверка, филтъра по екип и бутона „Add rule“.
Тук са запазени шест правила, две от тях работят. Четирите приложени примера стоят по-долу на същата страница, всички изключени.Отваряне на изображението в пълен размер
3

Конструктор на правила КОГА/АКО/ТОГАВА с живо изречение на прост език

Само в Professional

Едно правило има три блока. „WHEN“ е липсата, на която реагира („Something has not happened for a while. This is what the automation reacts to.“). „IF“ стеснява за кои заявки важи това („Which tickets it applies to.“) — по статус, приоритет, екип, категория, изпълнител или оценка. „THEN“ е това, което се случва.

Над блоковете правилото стои като едно изречение и то се пренаписва при всяка промяна: „When a ticket has seen no activity for more than 5 minutes and has the priority “High”, then set a follow-up in 4 hours.“ Ако нещо още липсва, изречението го казва точно на това място, вместо да го скрие.

В блока „IF“ решавате и как се съчетават условията: „All conditions must apply“ или „Any condition is enough“. Изречението отгоре променя формата си съответно — с едно „и“ то иначе би твърдяло обратното на това, което прави правилото.

Две полета управляват как няколко правила работят заедно: „Order“ задава последователността, а превключвателят „Skip the following rules for a ticket this rule applies to“ спира всяко следващо правило за заявка, за която важи това.

Новото правило започва с времевото условие „Time without any activity“ „longer than“ 3 „days“ в блока „WHEN“. Променете го или го премахнете, ако вашето правило се нуждае от нещо друго.

Повече за това в картата: Лоша оценка като спусък

Правило с ограденото в червено изречение на прост език над него и трите блока WHEN, IF и THEN отдолу.
Едно и също съдържание два пъти: веднъж като формуляр, веднъж като изречение. Четейки изречението, веднага забелязвате, когато сте настроили нещо различно от това, което сте имали предвид.Отваряне на изображението в пълен размер
4

Приложени са четири примерни правила (изключени при инсталиране, включете които пожелаете)

Само в Professional

Всяка инсталация идва с четири правила: „Example: remind the requester after 3 business days“, „Example: close after 10 days without a reply“, „Example: raise the priority of unassigned tickets“ и „Example: follow up on tickets nobody touched for a week“. Те стоят едно под друго на страницата „Automation“.

И четирите са изключени — всяко носи знака „Off“ и „Last run: never“. Те са отправна точка за четене и преправяне, а не поведение, което някой ви е промъкнал. Преименувайте ги, променете ги, включете ги или ги изтрийте.

Освен това те важат за „Every team“ — единственото място в системата, където това се случва без изричен избор. Затова, преди да включите някое, проверете дали то наистина е предназначено за всички ваши екипи.

Първото от четирите примерни правила с ограден в червено знак „Off“, името си и изречението на прост език.
Така изглежда първото; другите три стоят по-долу на същата страница и също са изключени. „Every team“ означава: то би важало за всеки ваш екип.Отваряне на изображението в пълен размер
5

Преглед, преди да го включите: показва кои заявки правилото би засегнало в момента – без да променя нищо

Само в Professional

Под всяко правило стои бутонът „Which tickets would this affect?“ Едно щракване показва списъка „Tickets this rule would affect right now“ — заявките, за които правилото важи в този момент, с номер и заглавие.

Отдолу пише какво прегледът не прави: „The preview only reads. It changes nothing and writes no log entry. Unsaved changes are not included.“ Последната част има значение: прегледът работи по запазеното правило, а не по това, което в момента е във формуляра.

Ако правилото в момента не съвпада с нищо, то също го казва: „No ticket matches this rule right now.“ Това е отговорът, който искате, преди да го включите — а не после, върху заявките на клиентите ви.

Отвореният преглед на правило със заглавие „Tickets this rule would affect right now“, две заявки и ограденото в червено указание, че прегледът само чете.
Това правило би засегнало в момента две заявки. Указанието отдолу казва, че нищо от това не се е случило при щракването върху бутона.Отваряне на изображението в пълен размер
6

Действия: имейл, статус, приоритет, възлагане, предаване на друг екип, задаване на напомняне

Само в Professional

Преди да започнете: Действието „Send an e-mail“ излиза през същия пощенски канал както останалата част от системата. Без настроена изходяща поща не се случва нищо — а инсталация с Basic изобщо няма този канал. Историята записва имейла само когато той наистина е излязъл. Иначе изпълнението показва „Failed“ в дневника на правилото, заедно с причината.

В блока „THEN“ избирате измежду седем действия: „Send an e-mail“, „Set the status“, „Set the priority“, „Assign to a user“, „Remove the assignee“, „Hand over to another team“ и „Set a follow-up“. „Add action“ добавя още; всяко има собствен превключвател „Active“, така че можете да заглушите отделно действие, без да изключвате цялото правило.

За „Send an e-mail“ отмятате получателите един по един: „the requester“, „the assignee“, „the observers“ и „a fixed address“ — последният със собствено поле за адреса. За „Set a follow-up“ задавате число, единица и бележката, която по-късно ще стои в заявката.

За „Hand over to another team“ указанието стои точно отдолу: „The ticket moves to that team and the current assignee is cleared. No second ticket is created.“ Така не се появява дубликат — същият случай просто сменя ръцете.

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

Блокът „THEN“ на правило с ограден в червено избор на действие и полетата за число, единица и бележка на напомнянето.
Едно действие с добавките му: „Set a follow-up“, 4 „hours“, плюс бележката, която операторът по-късно ще прочете в заявката.Отваряне на изображението в пълен размер
7

Времевите интервали се избират за всяко условие: в работни часове и работни дни по календара на екипа – или в денонощен ход

Само в Professional

Всяко времево условие в блока „WHEN“ има три части: вида, сравнението „longer than“ и число с единица. Видовете са пет: „Time since the ticket was created“, „Time without any activity“, „Time without a reply from the requester“, „Time without a public reply from an agent“ и „Time without a status change“.

Единицата решава как се брои времето — и то за всяко условие поотделно: „minutes“, „hours“ и „days“ текат непрекъснато, включително нощем и през почивните дни. „business minutes“, „business hours“ и „business days“ се броят по календара на работното време на екипа, така че се брои само това, което попада в работните часове.

В ежедневието разликата е голяма: три дни са три дни, докато три работни дни, броени от четвъртък в седмица от понеделник до петък, стигат до следващия вторник. Работен ден е работен ден в календара на екипа, към който принадлежи заявката, дори при правило за „Every team“. Официалните празници не се броят. Ако времето започва извън работното време, то се брои от следващото начало на работа. Действието „Set a follow-up“ брои „business days“ по същия начин.

Времево условие в блока „WHEN“ с оградени в червено число и единица, до избора на вида условие.
Това условие брои в „business days“ — три работни дни по календара на екипа, а не три календарни дни.Отваряне на изображението в пълен размер
8

Дневник за всяко правило и името на правилото като автор в историята на заявката

Само в Professional

Под всяко правило стои бутон „Log“. Той отваря таблицата „What this rule did“ с по един ред за всяка засегната заявка: „When“, „Ticket“, „Cycle“, „Result“ и „Details“. „Details“ съдържа какво точно е направено, например „Set a follow-up: 01.10.2026 22:36“. Ако едно правило още не е направило нищо, то го казва: „This rule has not done anything yet.“

Колоната „Cycle“ е причината едно правило да не ви вика всяка минута: то действа по една заявка веднъж на цикъл. Цикълът приключва едва когато правилото вече не важи за тази заявка — така че ако клиентът отговори и после отново замълчи, започва цикъл 2 и правилото действа отново.

В самата заявка правилото се появява като автор. В историята то се показва под собственото си име с представка „Automation:“, например „Automation: High priority: bring it back to us“. Така при всеки случай можете да проверите дали е действал човек или правило — и ако е било правило, кое. Клиентите виждат като автор „System“ вместо името на правилото.

Заглавният ред на всяко правило носи и „Last run:“ с часа на последното му минаване или „never“ за правило, което никога не е работило.

Отворената таблица „What this rule did“ с три реда и оградените в червено колони „Cycle“ и „Details“.
Три минавания по две заявки: по неотговорената заявка #4 правилото е действало втори път — оттам и „2“ в колоната „Cycle“. „Details“ съдържа датата на напомнянето, зададена всеки път.Отваряне на изображението в пълен размер
Историята на заявка с два оградени в червено реда, чийто автор е „Automation: High priority: bring it back to us“.
Същото събитие, погледнато от заявката: датата и бележката се появяват като два реда в историята, с правилото като техен автор.Отваряне на изображението в пълен размер

Групови действия в списъка със заявки

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

1

Промяна на статуса на няколко заявки наведнъж

Списъкът със заявки има колона с отметки най-вляво. Тя е там за администраторите и операторите. Клиентът никога не я вижда.

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

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

Списъкът на картинката не показва всички заявки. Горе вдясно, до „Filter“, стои думата „active“, а до нея „Reset“: затворените заявки са скрити, защото груповото действие е насочено към случаи, които още текат. Изборът винаги обхваща само това, което списъкът показва в този момент.

От първата отметка нататък над списъка се появява лента. Тя показва „20 selected“, до нея „Clear selection“ и бутоните „Change status“, „Assign“, „Assign to me“ и „Apply template“. По-надясно стоят „Multiple report“ и „Group into incident“ — тези двете спадат към многократното съобщаване и са обяснени в следващия блок.

„Change status“ отваря малък диалог. Избирате целевия статус, а редът отдолу веднага казва за колко от избраните заявки той важи.

Ако целевият статус изисква коментар, се появява текстово поле. Под него стои за колко заявки отива текстът. Той отива при всяка променена заявка, а не само при първата.

Не всеки статус се появява в списъка. Системните статуси липсват, защото никой не ги задава на ръка. Липсва и „Waiting for other team“: този статус създава подзаявка за целеви екип, а този екип избирате за всяка заявка поотделно. В група за това би имало само едно-единствено въвеждане.

Заявка без изпълнител се възлага на вас, когато промените статуса ѝ на страницата с подробности. В група това не се случва: „затвори 30 заявки“ иначе тихо би означавало „30 заявки, възложени на мен“ и 30 имейла.

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

Повече за това в картата: Втори етап за отделни задачи

Списъкът със заявки с отметнати редове и лентата над него, която показва броя избрани заявки и бутоните за групови действия.
Червената рамка стои върху лентата, която се появява едва с първата отметка. Отляво броят на избраните заявки, отдясно действията.Отваряне на изображението в пълен размер
Диалогът „Change status“ с избран целеви статус и реда, който посочва обхвата му.
Целевият статус е избран; отдолу стоят обхватът и причината за всяка заявка, която няма да дойде. И двете стоят там, преди да щракнете върху „Apply“.Отваряне на изображението в пълен размер
2

Възлагане на няколко заявки на един оператор наведнъж

„Assign“ отваря списъка с оператори. Отсъстващите оператори остават избираеми и само са отбелязани като такива, точно както при отделна заявка.

„Assign to me“ е същият диалог с предварително избрано ваше име. Той е пряк път, а не втори маршрут, и за него важат същите правила.

Възлагането може да изпрати имейл до оператора. За това са нужни Professional и превключвателят на екипа „Send assignment e-mails“. Имейлите при самовъзлагане са изключени по подразбиране. Диалогът посочва броя предварително: „This sends 11 e-mail(s) to the selected agent.“ Единадесет заявки са единадесет имейла.

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

Възлагането не може да бъде върнато на „никого“. Това не съществува при отделна заявка, значи не съществува и в група.

Диалогът „Assign“ с избрания оператор, обхвата и бележката за броя имейли.
Под избора стоят обхватът и броят имейли. Кутията отдолу назовава всяка заявка, която няма да дойде, с причината си. Някои вече принадлежат на Marco Rossi, останалите принадлежат на екип, от който той не е част.Отваряне на изображението в пълен размер
3

Прилагане на шаблон за отговор върху няколко заявки, със запазени места, разрешени за всяка заявка

„Apply template“ прилага шаблон за отговор върху всички избрани заявки. Всяка заявка получава същия коментар, който би получила, ако приложите шаблона на ръка.

Списъкът предлага шаблоните на всеки екип, който се среща в избора. Шаблонът се появява веднага щом подхожда поне на една избрана заявка; за колко наистина подхожда, казва прегледът след това.

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

Действията по полетата на шаблона се изпълняват заедно с това, а прикачените му файлове се копират във всяка заявка.

В група се изпълняват всички действия на шаблона. Отделни можете да размаркирате само при единична заявка; ако не искате дадено действие, използвайте шаблон без него.

Ако за екипите в избора няма шаблон, диалогът го казва: „No reply template is available for the teams of the selected tickets.“

Диалогът „Apply template“ с избран шаблон и бележката, че запазените места се разрешават за всяка заявка.
Червената рамка стои върху бележката за запазените места — това, което отличава случая от един текст, формулиран еднакво за всички. Отдолу стои причината шаблонът да подхожда на 14 от 20-те заявки: шест от тях принадлежат на екип, за който той не се предлага.Отваряне на изображението в пълен размер
4

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

И трите диалога показват един и същ ред, преди да се случи каквото и да е: „Applies to 19 of 20 selected ticket(s)“.

Отдолу стои кутията „Will be skipped“ с по един ред за всяка заявка, която няма да дойде, като всеки назовава номера на заявката и причината. Така прочитате преди щракването защо числото е по-малко от избора ви.

След изпълнението пише „19 changed, 1 skipped“, а същата кутия се превръща в „Not changed“. Съдържанието е същото; то само е престанало да бъде прогноза и е станало констатация.

Причините са тези на отделната заявка. Заявката вече е в целевия статус. Преходът не е позволен от текущия ѝ статус. Тя принадлежи на екип, за който не отговаряте. Избраният оператор не е част от нейния екип. Тя чака одобрение. Тя е групов инцидент с отворени сигнали. Тя е основна заявка с отворена подзаявка.

Прескочените заявки остават избрани, променените — не. Затова втори опит с друга цел е на едно щракване разстояние и никой не трябва да гадае кои още са отворени.

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

Едно извикване приема най-много 200 заявки. При 20 реда на страница това е далеч.

Диалогът след изпълнението: броят на променените и на прескочените заявки, а отдолу кутията „Not changed“ с причините.
Кутията „Not changed“ назовава причината за всяка заявка. Тук една заявка още чака одобрение.Отваряне на изображението в пълен размер
5

Имейлът до заявителите е изключен по подразбиране

Само в Professional

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

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

Щом я отметнете, се появява кехлибарена бележка с броя: „This sends 20 e-mail(s) to customers.“ Числото идва от прегледа и е броят заявки, на които шаблонът наистина подхожда.

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

Изпращането зависи от пощенския канал и следователно от Professional. Ако е изключено, не излиза никакъв имейл и историята също не споменава имейл — тя никога не твърди доставка, която не е станала.

Диалогът „Apply template“ с отметната отметка за поща и кехлибарената бележка за броя имейли до клиенти.
Отметката е поставена, а кехлибарената бележка посочва броя имейли. Без отметката не излиза нито един.Отваряне на изображението в пълен размер
6

Всяка групова промяна се появява в историята на отделната заявка

Всяка промяна, направена от групово действие, се появява в историята на отделната заявка. Там тя изглежда като всяка друга промяна, със стара и нова стойност.

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

Груповото възлагане записва реда с новия изпълнител. За заявка, която е стояла на „Open“, следва втори ред със статуса, защото възложената заявка тогава преминава на „Assigned“.

Освен това идва вътрешен ред, който носи означението на изпълнението. По това означение по-късно намирате всички заявки от същото изпълнение. Заявителят не вижда този ред.

Всеки ред назовава човека, който е задействал груповото действие.

Прескочена заявка не получава запис, дори за опита. Каквото не се е случило, не се появява в историята.

Историята на заявка с реда за възлагането и вътрешния ред под него, който назовава груповото изпълнение.
Най-новият ред е най-отгоре. Под редовете за времето и разходния център стоят статусът, възлагането и означението на изпълнението. Червената рамка стои върху вътрешния ред, този, който заявителят не вижда.Отваряне на изображението в пълен размер

Многократно съобщаване и групови инциденти

Две ситуации си приличат и не са едно и също. Ако един и същ човек съобщи едно и също два пъти, единият сигнал трябва да изчезне. Ако много хора съобщят една авария, нито един не бива да изчезне. Всяка има свой път, а разликата е заявителят.

1

Сливане на два сигнала от един и същ човек

Отметнете редовете в списъка със заявки и щракнете върху „Multiple report“. Бутонът става използваем от два отметнати реда нататък.

Диалогът пита първо: „Which ticket stays?“ Най-старата заявка е избрана предварително, за да тече срокът от първия контакт на заявителя, а не от втория му опит. Можете да изберете друга.

Отдолу стои посоката с двата номера: „#11 will be closed and moved into #10.“ Така преди щракването е ясно коя заявка остава.

Всичко идва с нея: коментари, прикачени файлове и описанието на втория сигнал. Описанието става коментар в оригинала, със своя първоначален автор и своята дата. Диалогът посочва числата предварително.

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

Вторият сигнал не се изтрива. Той се затваря и оттогава сочи към оригинала, а номерът му остава валиден.

Заявителят не получава отделен имейл. Той е в оригинала и вижда всичко там. Затвореният сигнал носи коментар, който назовава оригинала и който той може да прочете.

Няма връщане назад. Затова всичко стои в диалога, преди да щракнете върху „Merge“.

След това историята на двете заявки записва кой какво е слял и кога.

Списъкът със заявки с три отметнати реда и лентата над него с бутоните „Multiple report“ и „Group into incident“.
Червените рамки стоят върху двата бутона. Те стоят един до друг и означават две различни неща. В редове от 12 до 14 се вижда и отбелязването на текущия групов инцидент.Отваряне на изображението в пълен размер
Диалогът „Multiple report for the same issue“ с избора на заявката, която остава, и обобщението.
Червената рамка стои върху посоката. Тя назовава и двата номера, така че никой да не гадае коя заявка изчезва.Отваряне на изображението в пълен размер
Списъкът със заявки, стеснен чрез търсене до две заявки: оригинала и слетия сигнал, който е затворен.
Търсенето съдържа дума от двете заглавия, така че оригиналът и сигналът стоят един до друг. Червената рамка стои върху слетия сигнал. Той е затворен и въпреки това стои в списъка, с препратка към заявката, в която е бил преместен.Отваряне на изображението в пълен размер
2

Отговорите до стария номер на заявка пак пристигат

Само в Professional

Преди да започнете: За това е нужна входящата поща. Без нея няма отговор по имейл, който да трябва да се насочва.

Заявителят има стария номер на заявката в пощенската си кутия. Той не знае нищо за слети сигнали и отговаря на имейла, който има.

Този отговор попада в оригинала. Системата следва препратката, която носи затвореният сигнал.

Затова слят сигнал никога не се изтрива. Без него препратката не би съществувала и отговорът не би пристигнал никъде.

Който е участвал в стария сигнал, може да пише и в оригинала. Проверката става по заявката, назована в имейла.

Затвореният сигнал с препратката към оригинала и коментара, който заявителят чете там.
Червените рамки стоят върху препратката в картата вдясно и върху коментара. Точно тази препратка следва отговорът по имейл.Отваряне на изображението в пълен размер
3

Сигнали от различни хора не могат да се сливат

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

Причината гласи: „Different requester — this is an incident, not a multiple report.“ Тя ви казва и накъде да отидете вместо това.

Това е най-важният предпазител на цялата функция. Ако слеете тридесет сигнала от тридесет души, двадесет и девет от тях биха загубили заявката си и никога не биха чули отговор.

Кой е заявителят, се решава първо от имейл адреса в заявката. Ако няма такъв, решава чуждо име в полето „User“, като едно и също име се брои за един и същ човек. Иначе се брои профилът, създал заявката.

Затова предпазителят важи и при телефонни обаждания. Ако оператор запише две обаждания, и двете заявки са създадени от него. Различните обаждащи се обаче си остават различни, защото имената им са в полето.

Ако от едната страна заявителят не може да се установи, също се отхвърля. Неизвестен не е същото като същия човек.

В същата кутия се появяват и още причини. Групов инцидент не може да се слива. Затворен оригинал вече не приема нищо. А сигнал, който вече има собствени сигнали, не идва със себе си, за да не се образуват вериги.

Кутията „Cannot be merged“ в диалога, с номера на заявката и причината.
Червената рамка стои върху причината. Заявка 15 принадлежи на друг човек, затова остава извън. Другите две заявки въпреки това се сливат.Отваряне на изображението в пълен размер
4

Обединяване на много сигнали за една авария под един групов инцидент

Само в Professional

Когато файловият сървър падне, двадесет души съобщават за това. Всеки от тези сигнали е отделен случай със собствен заявител. Сливането тук би било грешно, защото деветнадесет души биха загубили заявката си.

Отметнете сигналите и щракнете върху „Group into incident“. Диалогът предлага три пътя: да ги добавите към вече открит групов инцидент, да обявите една от избраните заявки за групов инцидент или да създадете нов групов инцидент със собствено заглавие.

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

Всяка свързана заявка запазва своя заявител, своя статус и собствен срок. Нищо не изчезва. Груповият инцидент обединява само отговора.

Всички сигнали за един групов инцидент трябва да принадлежат на един и същ екип. Ако авария засегне два екипа, всеки получава собствен групов инцидент. Иначе решението на единия екип би изпразнило опашката на другия.

Закъснелите можете да прикачите и в отделната заявка. Ако екипът има открит групов инцидент, най-горе се появява указание с „Assign“ и „Not related“. Системата никога не прикача нищо сама: погрешно прикачена заявка би получила решение, което не я засяга, и покрай това би била затворена.

Заявката за групов инцидент посочва колко сигнала са прикачени към нея. Свързаните заявки на свой ред носят номера на своя групов инцидент, в списъка и в картата вдясно.

„Resolve incident“ затваря груповия инцидент и отговаря на всички сигнали наведнъж. Текстът на решението е задължителен: той е цялата същина на функцията, защото отива при всички засегнати.

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

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

Заявка, на която междувременно сами сте отговорили и която сте затворили, остава недокосната. Тя не се затваря втори път и не ѝ се пише отново.

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

Диалогът „Group into incident“ с трите пътя и откритият групов инцидент, включително броя му свързани заявки.
Червената рамка стои върху открития групов инцидент, а вдясно е броят на вече прикачените към него сигнали. Над пътищата стои изречението, което отделя този случай от сливането: нищо не изчезва.Отваряне на изображението в пълен размер
Лентата с указание в отделна заявка с открития групов инцидент и бутоните „Assign“ и „Not related“.
Червената рамка стои върху лентата с указанието. Тя е предложение, а не действие: щракването, с което я премахвате, не променя нищо в заявката.Отваряне на изображението в пълен размер
Заявката за групов инцидент с броя свързани сигнали, бутона „Resolve incident“ и отметката за лентата.
Червените рамки стоят върху бутона, който решава, върху отметката за лентата и върху броя свързани сигнали.Отваряне на изображението в пълен размер
Диалогът „Resolve incident“ със статуса за затваряне и въведения текст на решението.
Червената рамка стои върху бележката над полето. Тя казва къде отива този един текст: във всяка свързана заявка и до всеки заявител.Отваряне на изображението в пълен размер
Сигналът на един засегнат човек след решаването: решен, с текста на решението като публичен коментар.
Червената рамка стои върху отговора. Той стои в заявката на този един заявител, с неговия номер и неговата история. Същият отговор стои в заявката на всеки друг засегнат.Отваряне на изображението в пълен размер
5

Груповият инцидент като лента и като бележка в автоматичния отговор

Само в Professional

Диалогът и заявката за групов инцидент носят отметката „Also show as a banner on the sign-in page“. С нея всички научават за аварията, преди да напишат още една заявка.

Лентата стои на страницата за вход и вътре в системата след влизане. Тя назовава „Known incident“ и заглавието на груповия инцидент, така че това заглавие е текст за клиенти.

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

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

След като груповият инцидент бъде решен, лентата изчезва сама. Никой не трябва да помни да я изключи отново.

На страницата „Maintenance and incident notices“ виждате кой групов инцидент в момента върви като лента. Превключвателят на тази страница принадлежи на планираната поддръжка и не важи за груповите инциденти.

Заявката за групов инцидент с поставена отметка и лентата, която се появява отдолу в резултат.
Червената рамка стои върху отметката. Тя влиза в сила веднага: съобщението върви най-долу, на всяка страница на системата.Отваряне на изображението в пълен размер
Страницата за вход с течащата лента за групов инцидент между логото и формуляра за вход.
Червената рамка стои върху лентата. Тя е там още преди влизане, така че стига и до онзи, който само иска да провери дали трябва да пише заявка.Отваряне на изображението в пълен размер
Заявката за групов инцидент след решаването: решена, с текста на решението като коментар.
Червената рамка стои върху текста на решението. С това затваряне и лентата я няма.Отваряне на изображението в пълен размер

SLA, календар и ескалации

Срокове, които съответстват на работното ви време: политиката казва колко бързо трябва да отговорите и да решите, а календарът казва кога изобщо тече часовникът. Всичко в този блок е част от Professional.

1

Политики за SLA със срокове за първи отговор и за решаване

Само в Professional

Преди да започнете: Без активна политика системата не измерва нищо — няма срок, няма колона, няма имейл. А часовниците се създават при СЪЗДАВАНЕТО на заявка: каквото е дошло, преди да включите политиката, не получава срок със задна дата. Това е нарочно — иначе на следващата сутрин хиляда стари заявки биха стояли като просрочени.

Сроковете настройвате под „Settings → SLA“. Самата страница ви казва най-горе, когато никоя политика не е активна. Политиката има три части: име, условия и цели. Новите политики нарочно се създават неактивни — за да можете да ги довършите, преди да направят каквото и да е.

Условията са „Team“, „Priority“, „Main category“ и „Subcategory“. Празно означава „всяко“, тоест „важи за всичко“ — а не „не важи за нищо“. Ако съвпаднат няколко политики, печели тази с най-малкото число под „Order“; затова тясната политика стои най-горе, а общата под нея.

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

Всяка политика има две цели. „Time to first response“ приключва с първия публичен отговор на оператор — автоматично потвърждение и вътрешна бележка изрично не се броят. „Time to resolution“ приключва веднага щом заявката достигне статус, който се брои за решен (кой е той, задавате под „Settings → General → Status“). И двете цели имат собствени минути, собствен календар и собствена реакция при просрочване.

В заявката сроковете стоят вдясно в картата „Details“, под тях „Show deadline history“: дневник, който записва всяка стъпка — стартиран, поставен на пауза, продължен, спазен, пропуснат — всяка с причина и с използваното работно време. Виждат го само операторите и администраторите; за клиентите той не може да бъде извикан.

Ако някой по-късно промени приоритета или екипа, часовникът преминава към политиката, която съвпада тогава: използваното досега работно време се приключва по стария календар, след това важат новите стойности. Ако вече не съвпада никоя политика, часовникът приключва без присъда — той не се брои нито за спазен, нито за просрочен.

Ако при създаването на заявката не е съвпаднала никоя политика, часовникът стартира първия път, когато след промяна съвпадне политика, например при по-висок приоритет. Той брои от този момент. Часовникът за първия отговор стартира само ако още никой не е отговорил.

Нови часовници възникват само когато заявка бъде отворена отново. Другите смени на статуса не създават нови часовници.

Политика за SLA с име, ред, превключвател за активност, четирите оградени в червено условия Team, Priority, Main category и Subcategory и двете цели отдолу.
Политиката важи за всеки екип, но само за приоритет „High“. Отдолу двете цели: 15 минути до първия отговор, 240 до решаването.Отваряне на изображението в пълен размер
Сроковете на една заявка: „Time to first response“ със знака „In time“, под него „Time to resolution“ с оставащо време и отворената история на срока.
Първият отговор е дошъл навреме, решаването още тече. Дневникът назовава причината за всяка стъпка. Четете отдолу нагоре: стартиран, преизчислен с „ticket fields changed“ и накрая спазен с първия публичен отговор.Отваряне на изображението в пълен размер
2

Календар на работното време за всеки екип

Само в Professional

Календарът казва кога тече часовникът. Той има име, собствена часова зона и произволен брой прозорци за всеки ден от седмицата — обедната почивка е просто ден с два прозореца. Прозорецът може да преминава през полунощ; тогава до него се появява „ends next day“.

Кой календар важи за един екип, се задава на екипа („Settings → Teams“). В отделната цел на политика можете да го замените: „From the team“ взема този на екипа или избирате друг. Точно това дава обичайния случай — авариите се броят денонощно, всичко останало само в работно време.

Брои се времето, което наистина изтича вътре в прозореца, а не разликата между показанията на часовника. При смяната на лятното часово време това има значение: денонощен ден през октомври има 25 часа, а нощна смяна от 22:00 до 06:00 през пролетта — седем вместо осем. Работен прозорец от 09:00 до 17:00 никога не е засегнат, защото в ЕС смяната става през нощта.

Ако не може да се намери календар с работни часове, не се създава срок — по-добре никакъв, отколкото предполагаем. В заявката вместо дата се появява бележка.

Календарът „Helpdesk business hours“ с оградената в червено часова зона Europe/Berlin, прозорците от понеделник до петък 09:00–17:00 и бутона „Add opening hours“.
Пет дни, по един прозорец на ден. Часовата зона принадлежи на календара, а не на сървъра — второ местоположение просто получава втори календар.Отваряне на изображението в пълен размер
3

Официални празници чрез внасяне на .ics или въведени на ръка

Само в Professional

Преди да започнете: Ние не доставяме никакви данни за празници. Официалните празници зависят от МЕСТОПОЛОЖЕНИЕТО, а не от езика — 16 германски провинции, 26 швейцарски кантона, 50 щата в САЩ, и всяка година нови. Доставен списък някога би бил грешен, без никой да го забележи. Вземете официалния .ics файл на вашия регион; това е работа за една минута годишно.

Под всеки календар стои списъкът „Closed days“. Щракването върху „Import holidays (.ics)“ приема календарен файл и след това съобщава четири числа: колко дни са поети, колко са заменени, колко са нечетими и колко вече са били налице. Можете да въвеждате и отделни дни на ръка.

Символът ↻ зад един ден означава „повтаря се всяка година“. Той е правилен само за постоянни дати: 3 октомври се пада на една и съща дата всяка година, а Разпети петък и Духовден висят на датата на Великден и се местят. Затова подвижните празници стоят в списъка с конкретната си дата за всяка година — на картинката „Good Friday“ без символа.

Неработният ден поглъща целия прозорец на този ден, включително частта, която стига до следващия ден. А когато един календар изобщо не познава неработен ден за следващите дванадесет месеца, страницата го казва изрично — иначе системата тихо брои през официалните празници и произвежда грешни срокове.

Ограденият в червено бутон „Import holidays (.ics)“, а под него също ограденият списък с неработни дни.
Пет неработни дни. Четири носят символа ↻ за „една и съща дата всяка година“, Разпети петък — не: той се мести.Отваряне на изображението в пълен размер
Календарът „Around the clock“ с оградената в червено кехлибарена бележка, че той не познава неработни дни за следващите дванадесет месеца.
Бележката не е грешка, а предупреждение: този календар брои през всеки официален празник. За календар на дежурство това е точно правилното.Отваряне на изображението в пълен размер
4

Часовникът спира, докато се чака заявителят

Само в Professional

Най-честият спор около сроковете е този: заявката чака три дни отговора на клиента, а часовникът въпреки това тече. Затова всяка цел има превключвател „Pause while waiting for the requester“ — поотделно, а не за цялата политика.

Дали чакате, решава статусът: под „Settings → General → Status“ всеки статус носи отметка за това дали се брои за „чакане на заявителя“. При включен превключвател срокът почива, докато заявката стои в такъв статус. Стенният часовник продължава да тече — затова списъкът показва „Paused“ вместо оставащо време, а историята на срока съдържа „Paused“ и „Resumed“ с часовете им. Времето на чакане не се брои и ако заявката бъде решена направо от такъв статус.

За първия отговор обикновено оставяте превключвателя изключен: първият отговор дължите независимо от това какво се чака. За решаването той обикновено е включен. Картинката показва точно тази настройка.

Двете цели на една политика с оградените в червено превключватели „Pause while waiting for the requester“ — изключен при първата цел, включен при втората.
Един и същ превключвател, два отговора: часовникът за първия отговор тече непрекъснато, този за решаването почива, докато е ред на клиента.Отваряне на изображението в пълен размер
5

Оставащо време в списъка със заявки, с филтър за просрочените срокове

Само в Professional

Веднага щом една политика е активна, списъкът със заявки получава колоната „Deadline“. Тя показва оставащото време на следващия открит срок („14h 53m“). Щом в заявката вече не тече никакъв срок, там стои присъдата: знакът „In time“ за спазен, червеното „Breached“ за пропуснат. Заявка без никакъв часовник получава неутрално тире и това е нарочно: заявка отпреди политиката не е провал.

Ако никоя политика не е активна, колоната изобщо липсва — тя не стои там празна. Същото важи и за филтъра: под „Filter“ отметката „Breached only“ се появява само когато изобщо има срокове.

Заявката има два часовника, но колоната има само едно място — тя показва най-спешния ОТКРИТ срок. Ако първият отговор е пропуснат, а решаването още тече, колоната показва оставащото време за решаването с червен „!“ до него. Този знак казва: срок в тази заявка вече е бил просрочен — и точно така филтърът „Breached only“ я намира, защото той пита за всеки просрочен срок, включително отдавна приключил. Кой от двата е бил, е записано в самата заявка.

Можете и да подреждате по нея: под същото заглавие „Deadline“ стои поле с „Due soonest first“ и „Due latest first“. Заявките без течащ часовник винаги отиват накрая — те не са най-малко спешни, а просто не са засегнати. Подреждането по срок има предимство пред подреждането по „Updated at“: никой списък не може да изпълни два реда наведнъж.

Списъкът със заявки с отметната кутия „Breached only“, ограденият в червено филтър и също оградената колона „Deadline“.
С отметната кутия „Breached only“ остава една-единствена заявка. При заявка 4 първият отговор е пропуснат. Колоната въпреки това показва течащо оставащо време, защото показва следващия ОТКРИТ срок, а тук това е решаването. Червеният „!“ до него назовава просрочването.Отваряне на изображението в пълен размер
Заявка с червения знак „Breached“ при първия отговор и течащо оставащо време при решаването, а отдолу историята на срока.
Същата заявка, два часовника, две състояния. Дневникът съдържа причината: „due date passed“, след 16 минути използвано работно време.Отваряне на изображението в пълен размер
6

При просрочване: уведомяване или предаване на заявката на друг екип

Само в Professional

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

За всяка цел задавате под „When breached“ какво се случва при просрочване: „Record only“ само го записва, „Notify assignee and observers“ изпраща имейл до изпълнителя и наблюдателите (не до целия екип), „Hand over to another team“ предава заявката. За предаването трябва да изберете целеви екип — политика без такъв се отхвърля при запазването, защото би изглеждала настроена и не би правила нищо.

Действието се изпълнява точно веднъж на часовник. Без това резе рестарт на сървъра би изпратил същия имейл отново. Отметката „вече направено“ се поставя дори когато изпращането е било неуспешно — имейл, който не е пристигнал, е по-добър от цикъл, който изпраща нов всяка минута.

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

Предаването връща статуса на „Open“. Редовете в историята за него са вътрешни; клиентът вижда в заявката само новия статус и новия екип.

Неактивна примерна политика с ограден в червено избор „When breached: Hand over to another team“ и целевия екип „Network“.
Изречението под целевия екип казва какво се случва: заявката се премества в този екип, текущият изпълнител се изчиства. Превключвателят „Active“ тук е изключен — неактивна политика не прави нищо.Отваряне на изображението в пълен размер
7

Показатели за SLA в отчетите

Само в Professional

Под „Reports“ избирате периода и натискате „Generate report“ — без това щракване страницата остава празна. Тогава отчетът съдържа блока „Service level agreements“ с по един ред за всяка цел: спазени, просрочени, още течащи, постигнат дял и средно използвано време.

Броенето става за всяка цел, а не за всяка заявка — това пише и под таблицата. Затова заявка с двете цели се появява два пъти, по веднъж във всеки ред.

Постигнатият дял брои само приключилите часовници. Течащите не спадат в знаменателя, иначе всяко току-що включено SLA първо би изглеждало катастрофално и после би се подобрявало само. Ако още няма нито един приключил часовник, се появява тире — а не „0 %“.

Ако работите с групови инциденти, има допълнителен ред „Achieved without group incidents“: един-единствен групов инцидент със сто прикачени заявки иначе би изкривил дела и в двете посоки. Той изключва всяка заявка, която е свързана с групов инцидент.

Операторите виждат в този блок само собствените си екипи. Без Professional блокът се появява само ако има данни за срокове отпреди; тогава той остава четим.

Блокът от отчета „Service level agreements“ с колоните Met, Breached, Still running, оградената в червено колона „Achieved“ и средно използваното време.
За първия отговор три срока са спазени и един е просрочен, десет още текат. Това прави 75 %. Двете колони вдясно от него се появяват само когато има групови инциденти: те изключват всяка заявка, която е свързана с групов инцидент.Отваряне на изображението в пълен размер

Отчитане на времето за всяка заявка

Операторите отчитат времето, което е струвал един случай. Става дума за работата по заявката, а не за присъствието на човек — това изрично не е система за отчитане на присъствие. Целият този блок е част от Professional.

1

Включете го, преди да се отчита каквото и да е

Само в Professional

Отчитането на времето е изключено по фабрична настройка. Докато е изключено, няма поле и няма колона. Картата „Time spent“ в отчета тогава се появява само ако в избрания период е отчетено време.

Мъртво поле би било по-лошо от никакво, затова функцията изчезва напълно, вместо да стои там в сиво.

Превключвателят стои под „Settings → General“ на картата „Time tracking per ticket“ и се казва „Enable time tracking“.

Тогава всеки екип участва. За да изключите някой, го изключвате на самия екип, под „Settings → Teams“ в кутията „Team details“.

Фирма с вътрешен ИТ екип и екип, обърнат към клиента, често има нужда от него само за втория.

Ако по-късно изключите отчитането на времето отново, съществуващите записи остават четими и могат да се изнасят — те са основа за фактуриране, а не удобство. Нови записи не могат да се правят. Съществуващите записи тогава също не могат да бъдат променяни или изтривани.

Картата „Time tracking per ticket“ под „Settings → General“ с главния превключвател, закръглянето, бързите бутони и хронометъра.
Всяка настройка за отчитането на времето на една карта. Червената рамка стои върху главния превключвател, а отдолу стои какво означава изключването му.Отваряне на изображението в пълен размер
Кутията „Team details“ с превключвателя „Time tracking“ и обясняващото му изречение.
На екипа изключвате отделен екип. Червената рамка стои върху превключвателя; вече съществуващите записи остават видими и тогава.Отваряне на изображението в пълен размер
2

Отчитане на вложено време в заявка

Само в Professional

Заявката носи карта, наречена „Time spent“. „Log time“ отваря въвеждането.

До полето стоят бързи бутони: едно щракване върху „30m“ отчита тридесет минути. Кои бутони се появяват, се задава в настройките.

Полето „Duration“ приема и свободно въвеждане: „90“ са деветдесет минути, „1.5h“ е час и половина, също и „1h 30m“. Число без единица винаги са минути.

Въвеждане, което системата не разбира напълно, се отхвърля. „1h in the evening“ не става запис от един час — става съобщение за грешка.

В „What for (optional)“ пишете за какво е било времето. Текстът пътува в експорта и не се появява в историята на заявката.

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

Времето се отчита към ден, а не към час. За това въвеждането има поле за дата, което започва с днешния ден; за да попълните вчерашния ден, избирате там предишния ден. Ден в бъдещето не се приема. Часът би претендирал за точност, каквато въвеждането няма.

Отвореното въвеждане на картата „Time spent“ с бързите бутони, полето за продължителност, датата, превключвателя „Billable“ и полето за бележка.
Червената рамка стои върху бързите бутони. До тях полето приема свободно въвеждане. Подсказката в него показва форматите, които приема.Отваряне на изображението в пълен размер
Списъкът със записи за време в една заявка с три записа от двама оператори, всеки с дата, бележка и име.
Три записа, двама оператори, една заявка. Червената рамка стои върху един запис: продължителност, ден и име отгоре, бележката отдолу.Отваряне на изображението в пълен размер
3

Хронометърът

Само в Professional

За дълги сесии в заявката има хронометър: „Start timer“ го стартира, „Pause“ го спира.

Хронометърът никога не създава запис сам. Той предлага изтеклото време и нищо не се запазва, докато не натиснете бутона „Log …“, който назовава времето. Отчита се времето, което действително е изтекло.

Той замества смятането наум, а не знанието. И без него функцията е пълна, защото въвеждането на стойността е същинският път.

Отварянето на друга заявка поставя течащия хронометър на пауза, а новата заявка ви казва към коя заявка е закачен той. Ако на друга заявка още чака неотчетено време и стартирате хронометъра тук, приложението първо пита. Въпросът „Start timer“ предлага „Log …“ за времето на другата заявка, „Discard“ и „Cancel“. Той се появява от една минута изтекло време нататък.

Скритият прозорец не е почивка. Хронометърът продължава да тече, ако само щракнете настрани.

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

Хронометърът е изключен по фабрична настройка. Намирате го в настройките под „Stopwatch on the ticket“.

Течащият хронометър на картата „Time spent“ с показанието си, „Pause“, „Discard“ и бутона, който го отчита.
Хронометърът тече. Червената рамка стои върху бутона, който поема показанието; дотогава нищо не се запазва.Отваряне на изображението в пълен размер
4

За фактуриране или не

Само в Professional

Всеки запис носи превключвател „Billable“. Времето се отчита веднъж, а превключвателят решава дали то влиза във фактурата.

Затова заявката може да показва две суми: отляво всичко отчетено, отдясно сумата за фактуриране. Втората сума се появява само когато се различава от първата.

Няма отделен вид за жест на добра воля. Жестът, гаранционната работа и вътрешната преработка се наричат различно във всяка фирма, а системата познава само едно разграничение, на което висят пари.

Ето как отчитате жест на добра воля: въведете времето както обикновено, изключете „Billable“ и напишете причината в бележката.

Тогава записът видимо носи „not billable“. Минутите остават в отчетената сума, защото работата наистина е свършена.

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

Ако по-голямата част от работата ви не се фактурира, обърнете настройката по подразбиране с превключвателя „New entries are billable by default“.

Картата „Time spent“ с двете суми в заглавието си и един запис, който носи отбелязването „not billable“.
Двете суми стоят една до друга най-горе. Червената рамка стои върху записа без отметка: неговите минути се броят отляво, а не отдясно.Отваряне на изображението в пълен размер
5

До минута или закръглено нагоре

Само в Professional

По фабрична настройка всичко се фактурира до минута. Който фактурира на четвърт часове, задава две стойности.

„Rounding increment (minutes)“ е стъпката. Всеки запис се закръгля нагоре до следващото кратно.

„Minimum per entry (minutes)“ е долната граница. Всеки запис се фактурира най-малко с тази стойност.

Двете действат едно след друго: първо долната граница, после стъпката. При долна граница 20 и стъпка 15 пет минути стават тридесет, защото резултатът трябва да удовлетвори и двете.

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

Закръглява се само фактурираната стойност и само за всеки запис поотделно — никога общата сума. Затова два малки записа се закръглят нагоре два пъти.

Отчетеното време остава непокътнато. Промяната на закръглянето по-късно не изкривява стари данни, защото стойността се изчислява при показването.

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

Полетата „Rounding increment“ и „Minimum per entry“ с изчисленото примерно изречение и бележката отдолу.
Червената рамка стои върху примерното изречение, изчислено от стойностите над него. Изречението отдолу казва какво закръглянето не докосва.Отваряне на изображението в пълен размер
Запис за време от пет минути с фактурираната стойност до него в скоби.
Червената рамка стои върху записа, който закръглянето променя. Отляво стои отчетеното, в скоби — фактурираното.Отваряне на изображението в пълен размер
6

Запис за време преди затваряне

Само в Professional

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

Той се казва „Require a time entry before resolving or closing“ и е изключен по фабрична настройка.

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

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

Това е най-опасният превключвател на цялата функция. Включете го едва когато екипът ви наистина отчита време всеки път.

Превключвателят „Require a time entry before resolving or closing“ с изречението, което назовава изключенията.
Червената рамка стои върху превключвателя. Изречението отдолу назовава трите случая, които никога не се блокират.Отваряне на изображението в пълен размер
7

Колоната „Time“ в списъка със заявки

Само в Professional

Списъкът със заявки получава колона „Time“, която показва колко вече е отчетено по един случай.

Не я включвате вие. Тя се появява веднага щом отчитането на времето е включено. Виждат я само операторите и администраторите. Можете да я премахнете от списъка си с „Columns“.

При тесни прозорци тя е една от първите, които отпадат отново. Тогава списъкът запазва колоните, без които заявка не може да бъде намерена.

Списъкът със заявки с колона „Time“ и стойности при заявките, които носят отчетено време.
Червената рамка стои върху колоната. Само заявките с отчетено време носят стойност.Отваряне на изображението в пълен размер
8

Отчетът

Само в Professional

Време, което стои само в отделна заявка, не е основа за фактура. Затова страницата с отчети носи карта „Time spent“. Картата виждат само хората с правото „Time tracking: see the report“.

Отгоре стоят четири числа: отчетено, фактурирано, броят записи и броят заявки, които изобщо носят време.

Последното число е най-важното след общата сума. Четиридесет часа по три от петстотин заявки не са оценка — това са трима оператори, които единствени отчитат.

Отдолу идват разбивките: по заявител, по екип, по категория и по ден.

Освен това идва по една таблица за всяко собствено поле. Това е пътят към фактуриране по фирма или разходен център: създавате собствено поле, попълвате го в заявката и отчетът групира по него.

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

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

Страницата с отчети с картата „Time spent“, четирите ѝ числа и таблиците отдолу.
Картата стои на страницата с отчети. Червената рамка показва къде да я намерите.Отваряне на изображението в пълен размер
Четирите плочки на картата: отчетено, фактурирано, записи и заявки с време.
Червената рамка стои върху броя заявки с време. Той поставя общата сума отляво в перспектива.Отваряне на изображението в пълен размер
Таблиците по заявител, по собствено поле, по екип и по категория, всяка с отчетено и фактурирано време.
Червената рамка стои върху разбивката по категория. Всеки ред назовава и двете суми.Отваряне на изображението в пълен размер
Таблицата за собственото поле „Cost centre“ с по един ред за всеки разходен център.
По една таблица за всяко собствено поле. Червената рамка стои върху разбивката по разходен център.Отваряне на изображението в пълен размер
9

Експортът за счетоводството и за клиента

Само в Professional

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

Това са двама получатели, а не три файлови формата. „Export entries (CSV)“ и „Export entries (Excel)“ отиват при счетоводството: и двата са пълни и никога не се съкращават.

„Export entries (PDF)“ е документът за човек. Той отива при клиента като прикачен файл към фактурата. PDF файлът няма колона за бележката.

PDF файлът е ограничен до 20 000 записа и документът сам го казва. Фактура с повече редове от това така или иначе никой не чете.

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

Запис, който не се фактурира, има празна клетка в колоната за фактуриране, а не нула. Нулата би била сумирана в обобщаваща таблица.

Ако „Per-agent evaluation“ на отчитането на времето е изключено, колоната „Agent“ липсва и в трите файла. Ако вашият лиценз се върне към Basic, съществуващите записи остават четими и могат да се изнасят.

Трите бутона „Export entries (CSV)“, „(Excel)“ и „(PDF)“ с изреченията, които назовават разликата.
Червената рамка стои върху трите бутона. Изреченията отдолу казват кой файл за кого е предназначен.Отваряне на изображението в пълен размер
Страница от създадения PDF с таблицата с отделните записи. Сумите стоят на страница 1.
Това е документът, който получава клиентът. Всеки ред е един запис с датата, заявката, оператора, бележката и двете стойности.Отваряне на изображението в пълен размер
10

Клиентите не виждат отчетеното време

Само в Professional

Клиентът никога не вижда записите за време, дори в собствената си заявка.

Това не е настройка, а заключване в сървъра. Няма превключвател, който да го отваря.

Причината е в самите записи: бележките са написани за екипа. Те казват какво се е объркало и колко е отнело търсенето на причината.

Другите системи от този вид правят същото. Където времето стига до клиента, то стига до него като документ.

За това служи експортът в PDF: той излиза с фактурата, а не в заявката в клиентския портал.

Повече за това в картата: Експортът за счетоводството и за клиента

Същата заявка, както я вижда клиентът: описание, коментари и статус, но без карта „Time spent“.
Същата заявка, погледната от заявителя. Картата с времето изобщо липсва.Отваряне на изображението в пълен размер
11

Разбивката по оператор може да се изключи

Само в Professional

Отчетът може допълнително да показва кой колко е отчел. По фабрична настройка не го прави.

Времето за отделен човек е данни за резултати, а в много фирми работническият съвет има думата по тях.

Превключвателят се казва „Per-agent evaluation“ и стои в настройките.

Докато е изключен, сървърът дори не доставя числата. Таблицата не е скрита — тя не съществува.

Тази разлика има значение. Заключване, за което знае само изгледът, не е заключване.

Повече за това в картата: Няма история на достъпността, няма оценяване по човек

Отчетът с таблиците по екип и по ден, без таблица за оператор.
Така изглежда отчетът по фабрична настройка. Между категорията и деня няма таблица за оператор.Отваряне на изображението в пълен размер
Същото място с включен превключвател: таблица „By agent“ с по един ред за всеки оператор.
Същото място, след като превключвателят е включен. Между „By category“ и „By day“ сега има таблица за оператор.Отваряне на изображението в пълен размер

Отчети и табла

Таблото показва докъде е стигнал един екип. Отчетът отговаря на въпрос, който сами си задавате. И двете само четат; нито едното променя заявка. Извън собствените ви полета целият този блок е част от Basic.

1

Таблото: докъде са нещата

Най-горе има по една плочка за всеки статус с броя си. Под тях стоят три числа за целия екип: „Total tickets“, „Tickets which are not Closed“ и „Avg. resolution time“.

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

„Avg. resolution time“ остава празно, докато няма решена заявка. Тирето е по-честно от нулата.

Картата „Top 3 longest open tickets“ назовава трите най-стари отворени случая с възрастта им. Това са тези, които никой вече не споменава. Картата „Top agents closed tickets“ брои заявките, които всеки оператор е затворил. Изборът на картата задава колко дни назад гледа тя.

Отдолу стоят три диаграми: „Tickets by status“, „Tickets by priority“ и „Tickets by category“.

Таблото показва текущото състояние. Тук не можете да изберете период за цялото табло; за това служи отчетът.

Таблото на екипа Helpdesk със статус плочките отгоре и трите ключови числа отдолу.
Червената рамка стои върху общия брой. В този примерен свят екипът има 22 заявки, 18 от тях не са затворени.Отваряне на изображението в пълен размер
Картата „Top 3 longest open tickets“ с три случая и възрастта им.
Едно щракване върху запис отваря заявката.Отваряне на изображението в пълен размер
Диаграмите „Tickets by status“, „Tickets by priority“ и „Tickets by category“.
Категориите са собствените на екипа. Друг екип показва тук други.Отваряне на изображението в пълен размер
2

Всеки екип има собствено табло

Страничната лента носи по един запис за всеки екип. Той се казва „Dashboard“, следван от името на екипа.

Всеки запис показва само заявките на собствения си екип. Затова числата, категориите и най-старите случаи са различни за всеки екип.

Няма право за отделно табло. Операторите виждат таблата на всеки екип, към който принадлежат, администраторите виждат всички. Клиентите виждат таблото на един екип само ако превключвателят на екипа „Can see their own tickets of this team in the dashboard and in reports“ е включен.

Който няма право на дадено табло, изобщо не вижда записа. Блокиран запис, който все пак се вижда, само поражда въпроси.

Таблото на екипа Helpdesk, с осветен запис „Dashboard · Helpdesk“ в страничната лента.
Червената рамка стои върху записа в страничната лента. В този примерен свят Helpdesk показва 22 заявки.Отваряне на изображението в пълен размер
Същото табло за екипа Network с други числа и други категории.
Същата страница, друг екип. Тук са 6 заявки, а категориите са „Wi-Fi“ и „Firewall“.Отваряне на изображението в пълен размер
3

Създаване и филтриране на отчета

Страницата „Reports“ е празна, когато я отворите. Там е само кутията с филтри.

Едва щракването върху „Generate report“ стартира изчислението. То отнема момент, защото всеки раздел се изчислява наведнъж.

Това е нарочно. Отчет, който преизчислява при всяко натискане на клавиш, би бил неизползваем при голям набор от данни.

След това най-горе стоят четири ключови числа, а под тях диаграмите.

Всяка диаграма назовава числата си. Пръстените отпечатват броя и дела в легендата до тях; стълбовете отпечатват броя над стълба.

Кутията с филтри отгоре е мястото, където задавате въпроса. Можете да изберете периода чрез „From“ и „To“, екипа, статуса, оператора, заявителя, местоположението, приоритета, основната и подкатегорията и канала, през който е дошла заявката.

Ако зададете няколко полета, те важат едновременно. „Период юли, екип Helpdesk, приоритет High“ е един-единствен въпрос.

Периодът се води по деня, в който е създадена заявката.

Има едно изключение. Отчетът за времето се води по деня, в който е свършена работата. Затова юлска работа по юнска заявка се появява в юлския отчет.

След всяка промяна на филтъра трябва отново да щракнете върху „Generate report“.

Тази страница носи и оценките на други функции. Те се появяват само когато функцията е включена и в избрания период се е случило нещо.

Те са обяснени там, където им е мястото: сроковете под „Показатели за SLA в отчетите“, оценките под „Отчетът за оценките“, разпределението под „Отчетът за разпределението“ и вложеното време под „Отчетът“.

Страницата с отчети веднага след отваряне: само кутията с филтри, без числа.
Червената рамка стои върху „Generate report“. Докато някой не щракне върху него, страницата остава празна.Отваряне на изображението в пълен размер
Кутията с филтри на страницата с отчети с период, екип, статус, оператор, категории и канал.
Всички полета важат едновременно. Празно означава „всички“.Отваряне на изображението в пълен размер
Създаденият отчет с четири ключови числа и първите диаграми отдолу.
В този примерен свят има 28 заявки. Всеки стълб носи броя си над себе си, а пръстените показват броя и дела до тях.Отваряне на изображението в пълен размер
4

Филтриране и групиране по собствени полета

Само в Professional

Ако сте създали собствени полета, отчетът ги предлага също като вградените. Това важи за всеки вид поле, включително „Integer“, „Decimal“, „Date“ и „Yes / No“.

Всяко от вашите полета получава филтър в кутията и собствена диаграма в отчета.

Това отговаря на въпроси, които задава само вашата фирма. „Колко заявки отиват при кой разходен център?“ е един от тях.

Имената на диаграмите са имената на вашите полета. Те не се превеждат, защото идват от вашата инсталация.

Къде създавате собствени полета, е описано под „Собствени полета“.

Две диаграми, изградени от собствени полета: „Asset tag“ и „Cost centre“.
Този примерен свят има полетата „Asset tag“ и „Cost centre“. Вашата инсталация показва тук вашите собствени.Отваряне на изображението в пълен размер
5

Кои колони показва отчетът

Под „Settings → Report Settings“ решавате кои полета предлага отчетът.

Страницата има три раздела: „Admin“, „Agent“ и „Customer“. Всеки раздел носи същия списък със собствени превключватели.

Поле, което изключите тук, изчезва за тази роля от филтъра и от експорта. Това включва и файловете CSV и Excel.

По фабрична настройка администраторите и операторите виждат всичко. Клиентите виждат по-малко, защото нямат нужда от оператора, местоположението или приоритета.

Собствените ви полета се появяват под „Custom fields“ в същия списък.

Страницата „Report Settings“ с трите раздела „Admin“, „Agent“ и „Customer“.
Червената рамка стои върху раздела „Customer“. Всяка роля има собствен списък.Отваряне на изображението в пълен размер
6

Клиентите извличат собствен отчет

Клиентът може да отвори същия отчет като оператор. В него той вижда само собствените си заявки.

Ограничението е в системата, а не във филтъра. Клиентът не може да го заобиколи дори като въведе адреса на ръка.

Отключвате го на екипа. Превключвателят стои под „Settings → Teams“ и се казва „Can see their own tickets of this team in the dashboard and in reports“.

По фабрична настройка той е изключен. Докато е изключен, клиентът не намира нито таблото, нито отчетите.

Кои колони вижда клиентът, идва от раздела „Customer“ в настройките на отчета.

Изходът във файл също е отворен за него. Клиентът може да изтегли собствените си заявки като CSV, Excel или PDF.

Превключвателят на екипа, който отваря таблото и отчетите за клиент.
Превключвателят стои в кутията „Customer permissions“. Той важи за този един екип.Отваряне на изображението в пълен размер
Страницата с отчети от клиентски профил, с по-малко филтри и по-малки числа.
Същата страница от профила на Julia Becker. В този примерен свят тя вижда 8 заявки вместо 28, а филтърът по оператор липсва.Отваряне на изображението в пълен размер
7

Експорт като CSV, Excel или PDF

Под кутията с филтри стоят три бутона: „CSV export“, „Excel export“ и „PDF export“.

И трите използват филтрите такива, каквито са в момента, в който щракнете.

Файлът на Excel има листа „Key figures“ с числата. Листът „Tickets“ с отделните случаи се добавя само когато отметнете „Include ticket table in export“.

Числата и диаграмите винаги са включени. Списъкът с отделните заявки — само когато отметнете „Include ticket table in export“.

Щом я отметнете, отдолу се появяват истинският брой заявки и очакваният брой страници.

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

CSV и Excel съдържат всеки ред. PDF спира при 20 000 заявки и го записва в документа.

Ограничението се появява още на страницата, преди да изнесете. Ограничение, за което научавате едва в готовия документ, идва твърде късно.

Трите бутона за експорт, а под тях отметката за таблицата със заявки.
Червената рамка стои върху отметката. Само когато е поставена, се появява редът с броя заявки. В този примерен свят това са 28 заявки и около 4 страници.Отваряне на изображението в пълен размер
8

PDF отпечатва числата до диаграмите

PDF е предназначен да се предава нататък. Той съдържа същите диаграми, които стоят на екрана.

Под всяка диаграма стоят числото, от което е изградена, и делът в проценти.

Затова са там. Един стълб може да се погледне, но не и да се провери.

На екрана показалецът на мишката показва същото число. На отпечатан лист няма показалец на мишката.

Документът назовава най-горе периода и деня, в който е създаден. Без дата във филтъра няма период, който да бъде назован.

Страница от създадения PDF с диаграми и числата им под тях.
Документът така, както го получава получателят. Под всяка диаграма стоят броят и делът.Отваряне на изображението в пълен размер

Проучвания на удовлетвореността (CSAT)

След като една заявка е затворена, питате клиентите си как е минало. Целият този блок е част от Professional.

1

Проучването след затварянето

Само в Professional

Преди да започнете: Две неща трябва да са налице, иначе не се случва нищо. Изпращането на имейли трябва да е настроено. И под „Settings → Security“ публичният адрес на тази инсталация трябва да е правилен, защото връзката в имейла се изгражда от него. При погрешен адрес системата пак изпраща проучването, а клиентът ви попада на страница, която не съществува.

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

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

Има точно по едно проучване на заявка. Дори ако заявка бъде отворена отново и по-късно затворена пак, системата не пита втори път.

Връзката не изисква клиентски профил и е валидна 30 дни. Дотогава клиентът ви може да променя оценката — погрешното щракване върху грешната звезда е по-често от злоупотребата.

Коментарът е по избор. Щракването върху звезда вече е оценка; който иска да добави нещо, намира поле за това на страницата и потвърждава с „Update rating“.

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

Щракването от имейла записва оценката едва след като страницата се зареди. Затова антивирусните програми и извличащите преглед услуги не оценяват заявките ви: те извличат адреса, но не изпълняват JavaScript. За човек това пак е едно щракване.

Върнатата оценка стои в заявката, където операторите и администраторите на отговорния екип могат да я видят. Клиентът никога не я вижда там, дори собствената си.

Не се пита за всяка затворена заявка. Без адрес на заявителя изобщо не излиза имейл. Проучване не излиза и ако заявителят сам е затворил заявката или ако адресът му е в списъка с блокирани. Слетите многократни сигнали, както и сигналите, прикачени към групов инцидент, също остават извън — решаването на групов инцидент затваря всеки прикачен сигнал с едно щракване и без това изключение всеки подател би бил питан за една и съща свършена работа. Външните лица също получават проучването едва след като дадат съгласие. Картата „Кой получава проучването“ обяснява кой се брои за външно лице.

Всеки имейл с проучването завършва с връзка за отписване. След оценка страницата на проучването показва и връзката „Stop receiving surveys“. Картата „Съгласие и отписване“ обяснява и двете.

Повече за това в картата: Кой получава проучването, Съгласие и отписване

Имейлът с проучването в пощенската кутия на клиента с пет номерирани връзки за оценка и връзката към страницата на проучването.
Така пристига проучването. Всеки от петте реда е отделна връзка, а под тях стои пътят към страницата с полето за коментар. Адресът във връзките е този, който сте задали под „Security“.Отваряне на изображението в пълен размер
Страницата на проучването с пет звезди, поставена оценка, коментара и благодарственото съобщение.
Страницата след щракването върху петата звезда: оценката е запазена, полето за коментар остава отворено. Показват се само номерът и заглавието на заявката.Отваряне на изображението в пълен размер
Оценката в заявката с пет звезди и коментара на клиента.
Същият резултат в заявката. Червената рамка стои върху оценката — тя е тук за екипа, а не за клиента.Отваряне на изображението в пълен размер
2

Включване и ограничаване

Само в Professional

Проучването има точно едно място за настройване: под „Settings → General“, в картата „Customer Satisfaction Score (CSAT)“. Тази карта обяснява трите органа за управление на изпращането. Полето „Own e-mail domains“ на същата карта е обяснено в картата „Кой получава проучването“.

„Send satisfaction surveys“ включва изпращането; по фабрична настройка е изключено. Питат се само заявките, затворени след включването — иначе целият ви натрупан списък би получил имейл наведнъж.

Ако го изключите отново, вече наличните оценки остават видими. Само нищо ново вече не излиза.

Над превключвателите виждате адреса, от който се изграждат връзките. Той е там, за да се провери, а не за да се редактира: променяте го на единственото място, където се поддържа, и указанието до него ви отвежда там.

Средният превключвател, „Per-agent evaluation“, принадлежи на отчета. Какво прави той там и защо е изключен по фабрична настройка, стои на картата за отчета. Той остава използваем дори докато проучването е изключено.

„At most one survey per requester within“ ограничава колко често се пита един и същ човек. Фабричната настройка е 7 дни: който съобщи няколко заявки в този прозорец, пак се пита само веднъж.

С 0 питате при всяка затворена заявка. За вътрешна служба за поддръжка това обикновено е твърде много, защото едни и същи хора съобщават отново и отново; обслужване на клиенти с много различни податели рядко изобщо достига границата.

Проучването е нарочно просто. Скалата е фиксирана на от една до пет звезди, също и забавянето от един час и валидността от 30 дни. Две различни скали в една и съща база данни биха означавали, че отчетът осреднява неща, които не могат да се сравняват.

Повече за това в картата: Отчетът за оценките, Кой получава проучването

Картата „Customer Satisfaction Score (CSAT)“ с два превключвателя и числовото поле за границата.
Цялата настройка на една карта. Червените рамки стоят върху двата превключвателя и върху полето за границата; над тях стои адресът, от който се изграждат връзките.Отваряне на изображението в пълен размер
Картата „Public address of this installation“ с полето за адрес и реда „Currently in use“.
Самият адрес се поддържа под „Settings → Security“. Редът отдолу ви казва кой адрес се използва в момента и откъде идва той.Отваряне на изображението в пълен размер
3

Кой получава проучването

Само в Professional

Преди да започнете: След обновяването до 1.11.0 външните лица получават проучването само след съгласие. Затова въведете имейл домейните на вашата фирма. Иначе служителите ви също се броят за външни лица и вече не получават проучване.

Проучването разграничава две групи получатели. Служителите на вашата фирма го получават, без да бъдат питани предварително. Всички останали се броят за външни лица. Външните лица получават проучването едва след като са дали съгласие.

Служителите могат да се отпишат по всяко време. Външните лица могат да оттеглят съгласието си по всяко време. Картата „Съгласие и отписване“ обяснява как.

Кой се брои за служител, решавате в полето „Own e-mail domains“. То е под „Settings → General“ в картата „Customer Satisfaction Score (CSAT)“. Полето се вижда и се променя само от администратори. Въведете там домейните на вашата фирма, разделени със запетаи. После щракнете върху „Save domains“.

Адрес се брои за служител, ако домейнът му е в списъка. Записът обхваща и поддомейните си. Така „example.com“ важи и за „it.example.com“, но не и за „myexample.com“.

При запазване системата подрежда списъка. Главните букви стават малки, „@“ в началото се отстранява, а повтарящите се записи изчезват. Ако запис не е валиден домейн, се появява съобщението „These entries are not valid domains:“ с този запис. В такъв случай нищо не се запазва.

Ако полето е празно, всеки адрес се брои за външен. Това е фабричната настройка.

За отделен профил можете да замените домейна. Отворете профила под „User management“ с „Edit“. В полето „Satisfaction survey“ избирате „Automatic by domain“, „Employee“ или „External“. Фабричната настройка е „Automatic by domain“. До него „Result: …“ показва какво означава списъкът с домейни за този профил.

Изборът в профила важи за имейл адреса на този профил. Помага например при служител, чийто адрес е с друг домейн.

След обновяването до 1.11.0 полето съдържа разрешените домейни на вашите доставчици за единно влизане. Ако не използвате единно влизане, полето е празно.

Докато проучването е включено и никой не е запазил полето, картата показва кутия: „Since version 1.11.0, external people receive the survey only after giving consent. Enter your company's e-mail domains so that your employees keep receiving the survey.“ Кутията я виждат само администраторите.

Администраторите виждат същото изречение и като банер най-горе на всяка страница. Докато кутията е показана, банерът се появява, щом поне едно проучване не е било изпратено през последните 30 дни. „Open the survey settings“ води до картата. „Hide for 30 days“ го скрива за вашия профил за 30 дни.

Остава да направите едно нещо: въведете домейните и щракнете върху „Save domains“. Това важи и ако списъкът вече е правилен или трябва да остане празен. След това кутията и банерът изчезват.

Под полето един ред брои проучванията, които не са били изпратени през последните 30 дни, например „Surveys not sent in the last 30 days: 2 without consent, 1 after unsubscribing.“ Всяка заявка се брои веднъж. Други причини, като списъка с блокирани, не се броят. Връзката „Show consents and unsubscribes“ до него отваря списъка от картата „Съгласие и отписване“. Реда и връзката ги виждат само администраторите.

Правилото важи само за проучването за удовлетвореност. Всички други имейли излизат както преди, например отговорите на операторите.

Повече за това в картата: Съгласие и отписване

Картата „Customer Satisfaction Score (CSAT)“ с кутията за обновяването, полето „Own e-mail domains“, „Save domains“ и реда с броя.
Червените рамки са върху полето „Own e-mail domains“ и върху „Save domains“. Най-горе стои кутията, която остава, докато полето не бъде запазено за първи път.Отваряне на изображението в пълен размер
Диалогът „Edit user“ с полето „Satisfaction survey“ и реда „Result: …“ до него.
Червената рамка е върху полето „Satisfaction survey“. До него се вижда какво означава списъкът с домейни за този профил.Отваряне на изображението в пълен размер
5

Отчетът за оценките

Само в Professional

Под „Reports“ удовлетвореността има собствен раздел, „Customer satisfaction (CSAT)“. Той се появява в същия отчет както всичко останало, но следва само два от филтрите: периода и екипа. Без дата той обхваща последните 30 дни.

Най-горе стоят пет плочки. „Average score“ е средната стойност на звездите, „Satisfaction rate (4-5 stars)“ ви казва какъв дял е бил доволен, „Response rate“ е колко са отговорили, а „Surveys sent“ брои изпратените проучвания. Под двата дела намирате с дребен шрифт дробта, от която са изградени.

„Closed without survey“ е петата плочка. Тя брои затворените заявки, за които изобщо не е питано, а отдолу стои общият брой затворени заявки. Без това число бихте приели един дял за картината на клиентите си, а той почива на подмножество, което не виждате.

Числото, което има най-голямо значение, не е средната стойност, а делът на отговорилите. Добра оценка, изградена от малко отговори, казва малко за клиентите ви.

Отдолу идва разпределението: за всеки брой звезди от пет надолу до една един стълб показва колко често е даден, с числото до него. После идва „Trend“, по един ред за всеки ден, в който някой е отговорил, с датата, средната стойност за този ден като стълб и броя отговори. Накрая идват „By agent“ с по един ред за всеки оператор и „Latest comments“ с това, което хората наистина са написали. Разбивка „By team“ се присъединява веднага щом повече от един екип има оценени заявки.

Разбивката по оператор можете да изключите. „Per-agent evaluation“ е изключено по фабрична настройка, защото оценките за отделен човек са данни за резултати — в много фирми работническият съвет има думата по това, а при облачните доставчици това оценяване често изобщо не може да се изключи.

Превключвателят действа на сървъра, а не само на екрана: при изключен превключвател сървърът изобщо не доставя разбивката.

Отделната оценка в една заявка не е засегната от това и остава видима за екипа. Превключвателят урежда оценяването между хора, а не показаното по един случай. Отделен експорт на раздела за CSAT няма. Операторите виждат тук само екипи, чиито „Agent Permissions“ позволяват преглед на отчетите.

Филтърът „Satisfaction“ стеснява отчета до оценките. „Rated only“ показва оценените заявки, „Not rated“ показва неоценените, а с „Score from“ и „Score to“ можете да разгледате всяка заявка с една или две звезди. Филтърът важи за таблицата и за двата експорта.

Разделът „Customer satisfaction (CSAT)“ от отчета с пет ключови числа и разпределението на звездите.
Петте плочки на раздела. Червената рамка стои върху „Closed without survey“ — числото, което поставя дела на отговорилите в перспектива.Отваряне на изображението в пълен размер
Разделът „Trend“ с по един ред за всеки ден, средната стойност като стълб и броя отговори.
Ходът във времето. За всеки ден виждате датата, средната стойност като стълб с числото до нея и вдясно колко отговора са дошли този ден. В примера и двата отговора са пристигнали в един и същ ден, затова има един ред.Отваряне на изображението в пълен размер
Разбивката „By agent“ с по един ред за всеки оператор и последните коментари.
Разбивката по оператор, заедно с коментарите така, както са написани. Точно тази част от отчета може да се изключи.Отваряне на изображението в пълен размер
6

Лоша оценка като спусък

Само в Professional

Оценката може да задейства правило. В редактора на правила под „Settings → Automation“ има условие за това, „Satisfaction rating (CSAT)“, а до него избирате „is at most“, „is at least“, „is“ или „is not“. Третото поле съдържа звездите, от една до пет, с числото до тях.

Обичайният случай е „is at most 2“. Над правилото тогава четете изречението, което редакторът пише заедно с това: „When a ticket was rated 2 stars or fewer, then send an e-mail to the assignee.“

Това правило не се нуждае от времево условие. Новото правило идва с условието „Time without any activity“ „longer than“ 3 „days“ в блока „WHEN“; премахнете го, така че блокът да остане празен. Това го прави изключението сред правилата: всички останали чакат нещо да не се е случило от известно време, а това чака събитие.

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

Едно нещо тук работи различно. Обикновено правилата не докосват затворените заявки, но оценката почти винаги пристига по затворена заявка — затова правило с това условие достига и затворени заявки. Всяко друго правило все така не го прави.

Условието никога не важи за заявка без оценка, включително при „is not“ — иначе „не пет звезди“ би засегнало целия ви неоценен натрупан списък. Ако искате да знаете колко не са отговорили, това е делът на отговорилите в отчета.

Правилото действа веднъж на оценка. Под него „Log“ отваря таблицата „What this rule did“ с по един ред за всяка заявка, така че виждате кога е работило и какво е направило.

Редакторът на правила с условието „Satisfaction rating (CSAT) is at most 2“ и изречението над него.
Условието в редактора. Червените рамки стоят върху условието и върху изречението над него, а това изречение се пренаписва при всяка промяна.Отваряне на изображението в пълен размер
Таблицата „What this rule did“ с един ред за лошо оценената заявка.
Дневникът на правилото. Редът показва заявката, часа и изпълненото действие.Отваряне на изображението в пълен размер

База знания

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

1

Тематични плочки със статии и прикачени файлове

Достигате базата знания през „Knowledge Base“ в лявата лента. Обзорът се състои от плочки — по една за всяка тема. Числото горе вдясно в плочката е броят публикувани записи; под него стоят името и описанието на темата. Щракването върху плочката води до списъка със записи, всеки с автор, дата на промяна и първите редове от текста си.

Темите не създавате тук, а под „Settings → Knowledge Base“ (вижте картата „Видимост за всяка тема“). Без нито една тема обзорът не показва нищо освен бележка — записът винаги се нуждае от тема.

Пишете с „New entry“ на страницата на дадена тема. Редакторът иска три неща: „Title“, „Topic“ и „Content“. Това е същият редактор както в заявка, със същата лента с бутони: „Bold“, „Italic“, „Underline“, „Strikethrough“, „Text color“, „Highlight color“, „Bullet list“, „Numbered list“, „Quote“, „Link“ и „Clear formatting“. Връзка се прави както в заявка: избирате текста, щраквате върху „Link“, въвеждате адреса — позволени са уеб и пощенски адреси (http, https, mailto). „Save“ остава сив, докато липсват заглавие или тема, а запис без текст се отхвърля: само прикачени файлове не са запис.

Изображенията влизат в текста през клипборда, точно както в заявка: правите снимка на екрана и я поставяте в редактора с Ctrl+V. В текста се появява означение като „[inline-image:1]“; при запазването системата качва изображението и го показва точно на това място. То допълнително се появява отдолу под „Attachments“ — оттам го изтривате отново. Могат да се поставят PNG, JPEG и GIF.

Файлове прикачвате едва след като записът е запазен: най-долу на страницата на записа стои картата „Attachments“ с „Upload file“. Позволените видове файлове и размерът са същите както при заявка (до 50 MB на файл). Който е качил файл, може да го премахне отново; администраторите могат да премахват всеки от тях.

Администраторите винаги могат да пишат, операторите — докато превключвателят в настройките го позволява (вижте картата „Одобрение“). Клиентите само четат. Администраторът може да изтрие всеки запис; операторът може да изтрие само собствените си записи, които никога не са били публикувани.

Обзорната страница на базата знания с три тематични плочки и ограден в червено запис „Knowledge Base“ в менюто.
Пътят навътре: „Knowledge Base“ в лявата лента. Всяка плочка е тема; числото назовава публикуваните записи, кехлибареният знак — чакащите.Отваряне на изображението в пълен размер
Редакторът „New entry“ с полетата Title и Topic, лентата с бутони на редактора и посивелия бутон „Save“.
Заглавие, тема, съдържание. Докато не е избрана тема, „Save“ остава сив — в червената рамка е изборът, който още липсва тук.Отваряне на изображението в пълен размер
Запис от базата знания с форматиран текст, поставено изображение на дисплея на принтера, номериран списък и картата „Attachments“ с два файла.
Готов запис: заглавна част с тема, автор и одобрение, отдолу текстът с поставено изображение. Най-долу стоят двата файла — краткото ръководство за изтегляне и поставеното изображение.Отваряне на изображението в пълен размер
3

Видимост за всяка тема: само вътрешно или за клиенти

Преди да започнете: Видимостта виси на ТЕМАТА, а не на отделния запис. Вътрешна бележка в тема за клиенти е четима от клиентите веднага щом бъде публикувана — планирайте темите си съответно и при нужда преместете запис в друга тема през „Edit“.

Темите поддържате под „Settings → Knowledge Base“ в картата „Topics“. Всеки ред носи име, описание, номер за подреждане на плочките, превключвателя „Visible to customers“ и два бутона за запазване и изтриване — запазвате за всеки ред, а не цялата карта.

При изключен превключвател темата, нейните записи и прикачените им файлове се виждат само от оператори и администратори — клиентът дори не получава плочката и не намира записите и чрез търсенето. При включен превключвател клиентите виждат темата и публикуваните записи в нея; черновите така или иначе остават невидими.

Нова тема създавате в пунктирания ред отдолу: въвеждате име, избирате видимостта, „Add topic“. Темата може да се изтрие само докато е празна — иначе бихте изтрили и записите в нея, без да ги видите.

Картата „Topics“ с три теми; превключвателят „Visible to customers“ е включен за първата тема и изключен за „Internal runbooks“.
Разликата е в двете червени рамки: „Printing“ е освободена за клиенти, „Internal runbooks“ — не. Запазвате за всеки ред със синия бутон вдясно.Отваряне на изображението в пълен размер
4

Предложени решения при създаване на заявка

Веднага щом в полето „Title“ на формуляра „Create new ticket“ стоят три знака, системата търси на заден план и показва кутията „Possible solutions from the knowledge base“ — до пет записа, съответстващи на заглавието. Който намери отговора си там, не създава заявка; това е цялата същина.

Търси се само ЗАГЛАВИЕТО, а не описанието. Важи същото правило както при търсенето: предложението трябва да съдържа поне половината от думите на заглавието — колкото по-точно е заглавието, толкова по-малко и по-подходящи са предложенията. Щракването върху предложение го отваря в нов раздел, за да не се загуби наполовина попълненият формуляр; „Open knowledge base“ най-долу води към пълния обзор.

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

Полето „Title“ на формуляра за нова заявка с кутията „Possible solutions from the knowledge base“ и предложенията отдолу.
Въведено е само заглавието — кутията отдолу се появява сама. Най-горе стоят записите, които най-добре съответстват на заглавието.Отваряне на изображението в пълен размер
5

Превръщане на решена заявка в запис

Преди да започнете: Пренася се ВСИЧКО: описанието и всеки коментар, включително вътрешните. Текстът е копие, а не връзка — прочетете го и премахнете имена, телефонни номера, имейл адреси и номера на поръчки, преди да запазите. След това всеки, който може да вижда темата, може да го прочете.

Горе вдясно във всяка заявка стои „Add to knowledge base“. Бутонът отваря редактора за нов запис, предварително попълнен със заглавието на заявката и целия ѝ ход: описанието като първи абзац, всеки коментар под него като цитат.

Само това не ви носи нищо — то е суровина. Смисълът е да го превърнете в ръководство: съкратете го до това, което ще помогне следващия път, и пренапишете заглавието, ако звучи като отделен случай („Принтерът на 2-ри етаж дърпа по два листа“ става „Отстраняване на задръстване с хартия“).

Не е избрана тема предварително, нея избирате вие. Записът се запазва като всеки друг: като администратор — публикуван веднага, като оператор — изпратен за одобрение. След това в записа остава вътрешната препратка „Source: Ticket #1“ — тя е скок обратно към случая и не се вижда от клиентите.

Заявка с ограден в червено бутон „Add to knowledge base“ горе вдясно.
Бутонът стои горе вдясно във всяка заявка — независимо в кой статус е тя в момента. Той е предназначен за решения случай.Отваряне на изображението в пълен размер
Редакторът „New entry“, предварително попълнен със заглавието и хода на заявката, а над него ограденото в червено указание за изходната заявка.
Указанието в червената рамка казва това, което има значение. В текста отдолу стои вътрешната бележка с номера на поръчката — точно това, което трябва да изчезне преди запазването.Отваряне на изображението в пълен размер
6

Одобрение: записите на оператор чакат администратора

Дали операторите изобщо могат да пишат, решава превключвателят „Agents can create entries“ под „Settings → Knowledge Base“. По подразбиране той е включен. Изключен, той е твърда граница: бутонът „New entry“ и бутонът „Add to knowledge base“ в заявката изчезват, а прякото извикване на редактора също се отказва.

Има точно две състояния — „Awaiting review“ и „Published“; няма чернова, по която да работите тихо, без никой да вижда. Кой пише, определя състоянието: администраторът публикува веднага. Операторът произвежда запис, отбелязан с „Awaiting review“ — видим за оператори и администратори, не за клиенти. Върху тематичната плочка за него се появява кехлибареният знак „1 awaiting review“.

Администраторите допълнително получават имейл веднага щом запис чака одобрение. Този имейл е част от Professional. Това е добавка, а не изискване: без настроена изходяща поща знакът остава начинът, по който се намира чакащо одобрение. Одобрявате на страницата на записа с „Approve & publish“; след това там пише кой го е одобрил.

Ако оператор по-късно промени публикуван запис, той отива обратно за одобрение — промяната се вижда от клиентите отново едва след следващото „Approve & publish“. Който вече чака и запази още веднъж, не задейства втори имейл. Същото важи, когато оператор добави или премахне прикачен файл.

Страницата с настройки на базата знания с ограден в червено превключвател „Agents can create entries“.
Превключвателят стои най-горе в „Settings → Knowledge Base“. Изречението до него казва какво зависи от него: записите на оператори чакат одобрение.Отваряне на изображението в пълен размер
Запис, отбелязан с „Awaiting review“, с ограден в червено бутон „Approve & publish“.
Записът идва от оператора Marco Rossi и чака. Едно щракване върху „Approve & publish“ го прави видим за всички, които могат да виждат темата.Отваряне на изображението в пълен размер
7

История на промените в базата знания

Под „Settings → Knowledge Base“ картата „History“ стои най-долу. Тя изброява последните 200 събития, най-новите първо: какво се е случило, кой запис или коя тема е засегната, кой го е направил и кога.

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

Два реда наведнъж не са грешка: когато администратор създаде запис, там стои „Entry created“, а точно над него „Entry approved“ — той публикува без отклонението през одобрението. При оператор първо се появява само „Entry created“; одобрението идва по-късно и с името на администратора.

Историята вижда само този, на когото е позволено да отваря страницата с настройки на базата знания — по подразбиране администраторите. Това е една история за цялата база знания, а не по една за всеки запис.

Картата „History“ с редове като „Entry created“, „Entry approved“ и „Topic created“, всеки с име и час.
Най-отгоре записът на оператора, който още чака одобрение — той още няма ред „Entry approved“. Отдолу записите на администратора, всеки с двата реда.Отваряне на изображението в пълен размер

Резервно копие и възстановяване

Резервните копия имат собствено приложение. То идва със системата и инсталацията го настройва, така че няма какво да се купува и няма какво да се конфигурира. Този блок показва какво се запазва, кога се изпълнява и как връщате всичко обратно, когато има значение. Целият този блок е част от Basic.

1

Приложението за резервно копие и възстановяване

Приложението се казва „Ticket System Backup & Restore“. То стои до системата за заявки и има собствена икона на работния плот.

Има версия за Windows и версия за Linux. Това е едно и също приложение, само построено за всяка операционна система.

То има шест раздела. „Restore“ изброява наличните резервни копия, „Create Backup“ прави ново, „Schedule“ урежда времето, „Encryption“ показва ключа за възстановяване, „Settings“ показва пътищата, а „Log“ — протокола.

Настройките вече са попълнени. При първото си стартиране приложението само установява къде живее системата за заявки.

Папката за резервните копия стои под „Backup directory“. Можете да я промените, например към друго устройство.

На Windows приложението иска администраторски права, когато се стартира. Настройките му важат за всеки администратор на компютъра и живеят в „%ProgramData%\SMITEY\backup-app“.

Разделът „Restore“ с пет резервни копия, всяко с час, размер, вид и шифроване.
Червената рамка стои върху колоната „Encryption“. Новите резервни копия завършват на „.smbk“ и са „Encrypted“. По-старите резервни копия във формат ZIP показват „Not encrypted“. Колоната „Type“ казва дали резервното копие идва от графика, дали е направено на ръка, или е взето преди обновяване.Отваряне на изображението в пълен размер
Разделът „Settings“ с папката за резервните копия и данните за базата данни.
Червената рамка стои върху името на контейнера с PostgreSQL. По-надолу са томовете, които също се запазват.Отваряне на изображението в пълен размер
2

Графикът работи от момента на инсталирането

Преди да започнете: На Windows приложението винаги се стартира с администраторски права и регистрира графика с тези права. Ако Windows не позволява задачата да се изпълнява без влязъл потребител, тя остава обвързана с влизане и приложението ви го казва.

Инсталацията сама настройва ежедневното резервно копие. То се изпълнява в 23:00 в часовата зона на системата за заявки.

Графикът живее в операционната система. На Windows това е Task Scheduler, на Linux — услугата cron. Затова не работи допълнителна услуга само заради резервните копия.

Резервното копие не изисква някой да е влязъл. На сървър, на който никой никога не влиза, то пак се изпълнява.

Редът под бутоните ви казва дали задачата наистина съществува в операционната система. Поставената отметка казва само какво е било запазено.

Резервните копия се пазят на пет степени: 14 дни, 4 седмици, 12 месеца, 4 тримесечия и 5 години. Едно резервно копие остава, докато е най-новото за своя период в някоя от тези степени.

Броят се календарни дни, а не файлове. Две резервни копия в един ден са един ден.

Резервните копия, които създавате на ръка, никога не се изтриват автоматично. Точно това означава 0 при „Keep manual“.

Ако промените графика, промяната ви преживява обновяване. Инсталацията го задава само ако никога не сте задавали график. Ако сте изключили резервното копиране, то остава изключено. „Remove all scheduled tasks“ също трае: след това обновяването не настройва графика отново.

Разделът „Schedule“ с отметнато „Daily“ и час, зададен на 23:00.
Червените рамки стоят върху „Daily“ и върху часа. Изречението отгоре назовава и двата пътя: Task Scheduler и cron.Отваряне на изображението в пълен размер
Редът „Registered with the operating system: yes (Daily)“ под бутоните.
Този ред се проверява отново при всяко стартиране. Ако пише „NO“, нищо не се изпълнява само — тогава използвайте „Apply schedule“ като администратор.Отваряне на изображението в пълен размер
Шестте полета за срок на пазене: 14, 4, 12, 4, 5 и 0.
Червената рамка стои върху степените. „Keep manual (0 = keep all)“ означава, че направените на ръка резервни копия се пазят.Отваряне на изображението в пълен размер
Разделът „Schedule“ след „Apply schedule“, отдолу стоят „02:00 (America/New_York)“ и „Registered with the operating system: yes (Daily)“.
Червените рамки са върху „Apply schedule“ и върху редовете под него. В скобите стои часовата зона на системата за заявки. Часът важи в тази зона, а не в часовата зона на компютъра.Отваряне на изображението в пълен размер
3

Какво съдържа едно резервно копие

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

Ключовете са частта, която лесно се пропуска. Те разшифроват запазените данни за достъп, например тези на вашия пощенски профил. Без тях възстановяването би се върнало с мъртви данни за достъп.

Всяко ново резервно копие е един-единствен шифрован файл с окончание „.smbk“. Той съдържа по един файл за всеки том, списък на съдържанието си и базата данни като текстов файл, ако е включена.

Системата продължава да работи, докато това се случва. Вашите оператори изобщо не забелязват резервното копие.

„Estimate size“ ви казва предварително колко голяма е базата данни. Томовете с прикачените файлове се добавят към нея. Резервното копие не се компресира.

Нищо никога не се презаписва. Всяко резервно копие е отделен файл и само почистването премахва старите.

Само администратори могат да четат резервните копия. Същото важи за конфигурационния файл и за файла с първия вход в папката на инсталацията. Инсталаторът и всяко обновяване задават тези права сами.

Ако базата ви данни работи на собствен сървър, а не в контейнера на SMITEY, приложението не може да я запази. Запазете я тогава със собствени инструменти. В този случай резервното копие съдържа само прикачените файлове, архивите и ключовете, шифровани както обикновено. Обновяването открива такава база данни само и превключва приложението. Дотогава ежедневното резервно копие при такава инсталация не успява, освен ако първо не превключите на ръка. В командния ред можете да го направите и на ръка с „config --database external“. С „config --database bundled“ превключвате обратно.

Повече за това в картата: Шифроване и ключ за възстановяване

Разделът „Create Backup“ с бутоните „Estimate size“ и „Create backup now“.
Червената рамка стои върху двата бутона. Изречението отгоре изброява какво е включено.Отваряне на изображението в пълен размер
Съобщението най-долу с пълния път на създадения файл.
След създаването името на файла се появява най-долу в прозореца. Часът е част от името.Отваряне на изображението в пълен размер
4

Шифроване и ключ за възстановяване

Преди да започнете: Пазете ключа за възстановяване извън сървъра. Без него никое резервно копие не може да се отвори, след като сървърът е загубен. Никой не може да го възстанови вместо вас.

Всяко ново резервно копие е шифровано. Това важи за копията по график, за ръчно направените и за копията преди обновяване. Не е нужно да включвате нищо.

Резервните копия се шифроват с AES-256. Инсталацията създава ключа сама. При съществуваща инсталация той се създава с първото обновяване до версия с шифроване. Съхранява се защитен на сървъра. Само администраторите могат да го прочетат.

Това защитава копията извън сървъра. Който намери резервно копие на мрежов диск, на USB стик или в онлайн хранилище, не може да го прочете без ключа. Който контролира самия сървър, има и ключа.

Ключът за възстановяване е същият ключ във вид, който можете да запишете. Започва с „SMBK-“. Ще го намерите в раздела „Encryption“ и във файла „SMITEY-credentials.txt“ в папката на инсталацията. Ако сте изтрили този файл, ключът пак е в раздела „Encryption“.

„Copy“ слага ключа в клипборда. „Save to file...“ го записва с идентификатора на ключа и датата в текстов файл. Съхранете го например в мениджър на пароли или на хартия в сейф.

Докато не потвърдите, че ключът е запазен, приложението показва жълта лента най-горе. За да потвърдите, щракнете „I stored the key outside this server“ и отговорете на въпроса с „Yes“. Лентата изчезва. След това разделът показва кога сте потвърдили.

Идентификаторът на ключа показва към кой сървър принадлежи резервното копие. Ако резервно копие не принадлежи към този сървър, приложението назовава идентификатора на неговия ключ. След това иска подходящия ключ за възстановяване.

Ако приложението не може да прочете ключа, не прави резервно копие. Не прави и нешифровано. В този случай разделът „Encryption“ казва, че ключът не може да се прочете. Ако файлът с ключа липсва изцяло, следващото резервно копие създава нов ключ. Жълтата лента се появява отново, защото и новият ключ трябва да се съхрани. По-старите резервни копия могат да се отварят само със стария ключ за възстановяване.

По-старите резервни копия във формат ZIP не са шифровани. Все още можете да ги възстановите. Разделът показва колко са. Почистването ги премахва по същите правила като всяко друго резервно копие.

На сървър без работен плот „key --show“ показва същото в командния ред.

Повече за това в картата: Връщане на всичко, На сървър без работен плот

Разделът „Encryption“ с ключа за възстановяване, идентификатора на ключа и три бутона. Жълтата лента с известие е най-горе.
Червените рамки стоят върху лентата с известие, върху ключа и идентификатора на ключа и върху „I stored the key outside this server“. Ключът на снимката е от тестова среда.Отваряне на изображението в пълен размер
Същият раздел след потвърждението, без лентата с известие.
Горната рамка стои върху часа на потвърждението. Долната показва колко резервни копия още не са шифровани.Отваряне на изображението в пълен размер
5

Връщане на всичко обратно

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

В раздела „Restore“ избирате резервното копие, което искате обратно. После щраквате върху „Restore“.

Приложението първо пита. То казва какво ще стане: днешното състояние се презаписва, а приложението рестартира контейнерите. Ако в днешното състояние има анонимизирани хора, следва втори въпрос. Той посочва броя им и пита дали да бъдат анонимизирани отново след възстановяването. „Yes“ е избрано предварително. С „No“ копието се възстановява без тази стъпка. Ако вместо това затворите прозореца, нищо не се възстановява.

Отметката „Wipe target volumes before restore“ първо изпразва томовете. Така не остава файл, който не е съществувал при създаването на резервното копие.

Стъпките се появяват в раздела „Log“. Там виждате една по една какво е направило приложението. Ако сте отговорили с „Yes“ на втория въпрос, ред в края казва колко анонимизации системата за заявки ще приложи отново през следващата нощ. Ако те не могат да бъдат пренесени, вместо това дневникът показва предупреждение. Ако е имало предупреждения, редът за състояние в долната част на прозореца посочва броя им.

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

След това системата отново е използваема. При малка инсталация това отнема по-малко от минута.

Ако резервното копие съдържа базата данни, тя се връща изцяло или изобщо не. Томовете следват след нея. Ако някой том не успее, базата данни вече е върната, но може да липсват файлове; разделът „Log“ показва коя стъпка не е успяла. Във всеки случай приложението след това стартира контейнерите отново, дори ако възстановяването не е успяло.

Резервно копие от по-стара версия може да бъде възстановено в по-нова. При следващото си стартиране системата привежда базата данни до своята версия.

Съгласията и отписванията за проучването за удовлетвореност се пренасят без въпрос. Това важи и ако отговорите „No“ на втория въпрос. Приложението ги чете от работещата инсталация преди възстановяването. След това ред в раздела „Log“ дава броя, например „12 consent and unsubscribe record(s) were carried over.“ Системата за заявки ги поема при първото си стартиране. Съгласие или отписване, направено след резервното копие, затова остава валидно. Ако пренасянето не успее, журналът показва предупреждение. Възстановяването все пак се брои за успешно.

Приложението първо проверява напълно шифрованото резервно копие. През това време редът за състоянието показва „Checking the encrypted backup before anything is changed...“. Едва след това спира контейнерите. Ако файлът е повреден или е променян, то спира и съобщава „The backup file is damaged. Nothing was changed.“

Ако резервното копие идва от друг сървър, приложението иска ключа за възстановяване на този сървър. Това става след въпросите. Прозорецът „Recovery key needed“ назовава идентификатора на ключа на резервното копие. Същият прозорец се появява, ако ключът на този сървър липсва.

Грешка при въвеждането се забелязва, преди да е променено каквото и да е. Тогава редът за състоянието съобщава „The recovery key has a typing error. Check each character.“ След това прозорецът пита отново. Ако ключът принадлежи на друго резервно копие, редът за състоянието съобщава „This recovery key does not belong to this backup.“ С „Cancel“ приложението спира и съобщава „Restore cancelled. Nothing was changed.“

Приложението не приема въведения от вас ключ. То запазва своя. Новите резервни копия все още се правят с ключа на този сървър. Ако възстановявате на нов сървър, запазете и ключа за възстановяване на този сървър.

Резервно копие без база данни възстановява само прикачените файлове, архивите и ключовете. Съществуващите ключове се запазват. Базата данни остава каквато е. Приложението го казва преди възстановяването и пита. С „No“ нищо не се променя.

Ако инсталацията е настроена на собствена база данни, приложението пропуска частта с базата данни дори когато резервното копие съдържа база данни. Това се отнася например за по-старо резервно копие. Приложението пита предварително. С „No“ нищо не се променя.

Избрано резервно копие в списъка, с отметката и бутона „Restore“ отдолу.
Червените рамки стоят върху отметката и върху „Restore“. Без избран ред бутонът остава изключен.Отваряне на изображението в пълен размер
Потвърждението преди възстановяването с бутоните „Yes“ и „No“.
Въпросът назовава и двете последици: днешното състояние се презаписва и контейнерите се рестартират.Отваряне на изображението в пълен размер
Протоколът след възстановяването, със съобщението „Restore complete.“ най-долу.
Всяка стъпка е там с часа си. Накрая приложението съобщава „Restore complete.“Отваряне на изображението в пълен размер
Вторият въпрос „6 person(s) were anonymized in the current system.“ с бутоните „Yes“ и „No“.
Червените рамки са върху въпроса и върху „Yes“. „Yes“ е избрано предварително. Числото брои хората, които са анонимизирани в днешното състояние.Отваряне на изображението в пълен размер
Редът за състояние след възстановяването: „1 warning(s) while carrying over anonymizations and survey consents. See the Log tab.“
Червената рамка е върху реда за състояние. Той посочва само броя на предупрежденията. Какво точно се е случило, има в раздела „Log“.Отваряне на изображението в пълен размер
Заявката за ключа за възстановяване с идентификатора на ключа на резервното копие, поле за въвеждане и бутоните „OK“ и „Cancel“.
Червените рамки стоят върху въпроса с идентификатора на ключа и върху полето за въвеждане. Тирета, интервали и главни или малки букви нямат значение при въвеждането на ключа. Ключът на снимката е от тестова среда.Отваряне на изображението в пълен размер
6

На сървър без работен плот

Сървърът често няма работен плот. Затова същото приложение работи и като команда.

Пет команди са ви нужни всеки ден: „backup“ запазва, „list“ показва наличните резервни копия, „restore“ връща едно обратно, „schedule“ задава времето, а „config“ показва настройките. За ключа се добавят „key“ и „decrypt“.

Зад тях стои същото приложение както в прозореца. Няма втори път, който да прави нещо друго.

Приложението стои в „/opt/smitey/Backup“. Извиквате го със „sudo“ и добавяте командата. Контейнерите работят като „root“, затова и резервното копие се нуждае от тези права.

Можете да копирате шестте кутии отдолу. Те покриват това, което наистина е нужно в ежедневието.

Възстановяването и тук пита. То се изпълнява само когато добавите „--yes“. Тогава то пренася и анонимизациите от днешното състояние, както „Yes“ в прозореца. С „--no-reapply“ то се изпълнява без тази стъпка.

На сървъра има файл, в който можете да прочетете всичко това. Той се казва „BACKUP-RESTORE.txt“ и стои в „/opt/smitey“. Той минава още веднъж през графика, всяка команда и пътя назад, със собствено темпо. Той съществува на немски и на английски: ако при инсталирането сте избрали немски, получавате немския, иначе английския. И двете версии стоят също под „/opt/smitey/docs“.

„key --show“ показва ключа за възстановяване, идентификатора на ключа и броя на нешифрованите резервни копия. Щом ключът е запазен извън сървъра, го потвърждавате с „key --confirm-stored“.

Резервно копие от друг сървър възстановявате с „--key-file“. Файлът, който посочвате, съдържа ключа за възстановяване. Файлът от „Save to file...“ също върши работа. Вместо файла можете да ползвате и променливата на средата „SMITEY_BACKUP_KEY“. С „sudo“ я поставяте директно пред програмата, тоест „sudo SMITEY_BACKUP_KEY=<ключ> /opt/smitey/Backup/TicketSystemBackup restore …“. Тогава ключът попада в историята на обвивката. Ако ключът не пасва, нищо не се променя.

„decrypt“ записва съдържанието на резервно копие като нешифровани файлове в празна папка. Тези файлове не са шифровани. Те съдържат пароли и лични данни. Изтрийте ги, щом приключите.

Показване на наличните резервни копия

sudo /opt/smitey/Backup/TicketSystemBackup list

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

Показване на графика

sudo /opt/smitey/Backup/TicketSystemBackup schedule --show

Първият ред назовава зададения час заедно с часовата зона. Последният казва дали задачата наистина съществува в операционната система. Ако пише „NO“, нищо не се изпълнява само.

Промяна на графика

sudo /opt/smitey/Backup/TicketSystemBackup schedule --daily 23:00 --keep 14

Часът важи в часовата зона на системата за заявки. „--keep“ казва колко ежедневни резервни копия се пазят. „schedule --off“ изключва ежедневното резервно копие.

Създаване на резервно копие веднага

sudo /opt/smitey/Backup/TicketSystemBackup backup

Това резервно копие се брои за „Manual“. Направените на ръка резервни копия никога не се изтриват автоматично.

Показване на ключа за възстановяване

sudo /opt/smitey/Backup/TicketSystemBackup key --show

Последният ред казва дали вече сте потвърдили, че ключът е запазен. Командата не създава ключ.

Възстановяване на резервно копие от друг сървър

sudo /opt/smitey/Backup/TicketSystemBackup restore <file>.smbk --yes --key-file /root/recovery-key.txt

Заменете <file> с името или пътя на резервното копие. Файлът „/root/recovery-key.txt“ създавате предварително. Той съдържа ключа за възстановяване. Файлът от „Save to file...“ също върши работа.

Команден ред на Linux сървър със списъка от „list“ и отдолу изхода на „key --show“.
Отгоре „list“ показва резервните копия. По-старите резервни копия във формат ZIP носят бележката „(Not encrypted)“. Отдолу „key --show“ дава ключа за възстановяване, идентификатора на ключа и броя на нешифрованите резервни копия. Ключът на снимката е от тестова среда.Отваряне на изображението в пълен размер
7

Резервните копия стоят на същата машина

Преди да започнете: Резервно копие до системата не ви пази от отказ на диска. Копирайте файловете редовно на друго място.

Резервните копия са файлове в папката, която сте задали. Тази папка е на същата машина като системата за заявки.

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

То не помага срещу отказ на диска. Ако дискът го няма, резервните копия ги няма заедно с него.

Затова копирайте файловете другаде. Мрежов диск, втори сървър или хранилище в мрежата са достатъчни.

Копиран файл може да бъде зареден обратно на всеки сървър. На друг сървър за това ви трябва ключът за възстановяване. С „Import backup file…“ връщате файла в списъка.

Копията са шифровани. Никой не може да ги прочете без ключа за възстановяване. Затова не пазете ключа до копията. По-старите резервни копия с окончание „.zip“ не са шифровани.

Разделът „Settings“ с полето „Backup directory“.
Полето „Backup directory“ казва къде са файловете. Това е папката, която трябва редовно да копирате другаде.Отваряне на изображението в пълен размер
8

Преди всяко обновяване системата запазва сама

Обновяването прави собствено резервно копие предварително. Това става независимо от вашия график и без вие да отмятате нищо.

То запазва същото както винаги: базата данни, прикачените файлове, архивите и ключовете. Ако базата данни работи извън SMITEY, обновяването запазва само прикачените файлове, архивите и ключовете.

Това резервно копие се прави от приложението „Ticket System Backup & Restore“. То е шифровано като всяко друго и стои в същата папка. В списъка видът му е „Update“. Трите най-нови такива резервни копия се пазят. По-старите приложението изтрива само.

Съобщението преди обновяването ви го казва. Не е нужно сами да помните да запазите първо.

Ако това резервно копие не успее, обновяването спира, преди да бъде заменено каквото и да е. Базата данни извън SMITEY не задържа обновяването. Тогава обновяването превключва приложението така, че ежедневното резервно копие също да пропуска базата данни. Запазете тази база данни със собствени инструменти.

Повече за това в картата: Обновяване с натискане на бутон

Потвърждението преди обновяването с бележката за резервното копие.
Изречението „A full backup is taken automatically beforehand“ е част от въпроса. Резервното копие се изпълнява, преди да бъде заменено каквото и да е.Отваряне на изображението в пълен размер

Важни команди (Linux)

Готови за копиране. Всичко със sudo – инсталаторът и контейнерите се нуждаят от root.

Инсталиране на предпоставката

sudo apt install -y unzip

Без unzip инсталаторът не може да разопакова пакета.

Инсталиране на системата за заявки

curl -fsSL https://files.smitey.eu/download/get-smitey.sh | sudo bash

Изтегля пакета и ви води през въпросите. Повторното изпълнение е безопасно: конфигурацията и данните се запазват.

Проверка на HTTPS

sudo /opt/smitey/smitey-install check-https

За всеки вариант с HTTPS. При публичен домейн командата ви казва дали сертификатът е налице. Ако липсва, тя назовава причината от дневника. Сертификатът може да пристигне и минути след инсталирането. В собствената ви мрежа тя проверява връзката със съответния основен сертификат.

Справка за първия вход

sudo cat /opt/smitey/SMITEY-credentials.txt

След първия вход сменете паролата и изтрийте файла.

Работят ли контейнерите?

sudo podman ps

Показва всяка част от системата със състоянието ѝ.

Проследяване на дневника

sudo podman logs -f container-backend-1

Показва на живо какво съобщава бекендът. Спира се с Ctrl+C.

Проверка на надзорника

systemctl status smitey-supervisor

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

Създаване на пакет за поддръжка

sudo bash /opt/smitey/install.sh --support-bundle

Събира дневниците и състоянието на системата в един zip файл. Паролите и ключовете се премахват.

Промяна на публичния адрес

sudo bash /opt/smitey/install.sh --reconfigure

Задава нов домейн и рестартира, така че сертификатът да бъде поискан за новото име.

Промяна на начина на достъп до SMITEY

sudo bash /opt/smitey/install.sh --change-access

Превключва между петте варианта, например от HTTP към HTTPS. Само Enter запазва текущия вариант. Данните ви остават.

Премахване

sudo bash /opt/smitey/install.sh --uninstall

Пита отделно за данните и за Podman – нищо не се изтрива, без да попита.

Резервните копия се обработват от /opt/smitey/Backup/TicketSystemBackup (list, backup, restore); ежедневното резервно копие се изпълнява само. Подробности има в /opt/smitey/docs/en/BACKUP-RESTORE.txt.

Обратно към сравнението на функциитеИзображенията са от версия 1.3.1.