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

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

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

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

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

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

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

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

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

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

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

Статусът казва къде стои една заявка в момента. Дванадесет статуса идват със системата — 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“.

Всичко, което се показва като падащ списък в една заявка, принадлежи на вас. Под „Settings → General Settings“ стои картата „Drop-down lists“ с шест раздела: „Department“, „Position“, „Location“, „Role“, „Status“ и „Priority“. Боравенето се различава от списък на списък.

Едно по едно: въвеждате английското име в празното поле и щраквате върху бутона до него — той е кръстен на списъка, значи „+ Add location“, „+ Add department“ и така нататък. Редовете отдолу са съществуващите записи. В „Department“, „Position“ и „Location“ там променяте име и потвърждавате със „Save“ до него.

За много записи наведнъж „Department“, „Position“ и „Location“ предлагат също „Export JSON“ и „Import JSON“. При прясно инсталирана система изтегляте празната структура с „Export JSON“, попълвате я и я внасяте отново. Това не е начин за преименуване — картата сама го казва.

Някои записи носят знака „Mandatory“. Сред тях са трите роли „Admin“, „Agent“ и „Customer“, осем от статусите, които идват със системата, и по едно запазено място в списъците Location, Position и Department („None selected or available“). Никой от тях не може да бъде изтрит: на тях висят права и процеси, които иначе биха спрели без дума. Статусите все пак могат да бъдат преименувани в своя редактор. Ролите и запазените места не могат да бъдат преименувани. Какво е позволено, зависи от списъка. „Role“ е заключен: роля не може нито да се добави, нито да се преименува. В „Priority“ добавяте и изтривате записи, но няма файл и няма преименуване. „Status“ има собствен редактор и също няма файл.

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

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

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

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

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

Над всеки списък със заявки стои полето „Search tickets…“. То търси не само в заглавията, а в целия случай: заглавие, описание, име на заявителя, имейл адрес и телефонен номер, местоположение, референтен номер на заявка, всички коментари и текстовите стойности на собствените ви полета.

Примерът го показва: „coffee“ не се среща в нито едно заглавие, а само в описанието на една заявка — и въпреки това бива намерена. Затова не е нужно да помните как е било озаглавено дадена заявка; една дума от случая стига.

Главните и малките букви нямат значение. Търсенето винаги важи за списъка, в който се намирате в момента, и може да се съчетае с „Filter“ до него; „Reset“ изчиства търсенето и филтрите отново. Списъкът запомня филтрите ви, отделно за всеки списък на екип. Те са отново там, когато се върнете от заявка, презаредите страницата или влезете от друг компютър. Текстът за търсене не се запомня. За клиентите има ограничение, което не се вижда, но е добре да се знае: те не търсят във вътрешните коментари — иначе от списъка с резултати биха могли да заключат какво е обсъждано вътрешно. Не търсят и в собствени полета, които са скрити от клиентите.

Всеки сам подрежда своя списък със заявки. За целта до „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“ не са достъпни за тях. Полета, които сте скрили от клиентите, също не се появяват като колона.

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

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

Когато в заявките ви липсва някаква информация — инвентарният номер, краят на гаранцията, разходният център — я добавяте сами. Под „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“ го връща обратно в списъка.

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

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

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

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

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

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

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

Известието стои в заглавната част на заявката. „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“ и собствени полета.

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

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

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

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

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

Всичко за това стои под „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 системата нито изпраща, нито получава имейли; заявките там се създават през портала, по телефона и от оператора.