Пощенският канал е един път с две посоки и те вървят заедно: входящият имейл се превръща в заявка, вашият отговор излиза като имейл, а отговорът на заявителя попада като коментар в същата заявка — а не във втора.
Свързването не става по усет: отговорът попада в съществуващата заявка само когато имейлът носи означението на случая в темата си или носи заглавките за отговор на пощенската програма. Имейл без нито едно от двете започва нов случай — по-добре една заявка в повече, отколкото два несвързани случая, слети само защото темата случайно е съвпаднала.
Всичко за това стои под „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“; оставете я празна и те остават във входящата поща. Отдолу задавате кога се извършва почистването („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 conditions“ — оставете ги празни и той излиза при всяко изпълнение на този работен поток.
„Move to folder“ подрежда обработения имейл в папка. Оставете полето празно и важи общата „Processed folder“ от IMAP настройките по-горе.
Действието „Auto-reply“ в подробности: темата съставяте от блокове. „Original subject {originalSubject}“ поема темата на входящия имейл, „Ticket reference {ticketTag}“ вмъква означението на случая — заедно те дават нещо като „Printer problem [TICKET-99]“.
Означението не се добавя само. То се появява само там, където поставите {ticketTag} или {ticketId} — и точно по него системата разпознава по-късно отговора на вашия клиент. Без него в темата всяко продължение започва нова заявка, вместо да стане коментар към старата.
Текстът отдолу е вашето съобщение за потвърждение. Напишете го на английски: то минава през същия износ и внасяне както всеки друг текст и само така може да бъде преведено на другите езици. Оставете го празно и системата изпраща собственото си съобщение по подразбиране. Тук са позволени същите запазени места.
„Reply language“ решава на кой език излизат темата и текстът: „Standard English“ използва английски, „Fixed language“ — избран от вас език, „Assigned agent's language“ — езика на възложения оператор, а „Team default language“ — езика по подразбиране на екипа. Самите преводи се поддържат на езиковата страница.
Един съвет, който системата изписва и над картата: всичко, което принадлежи на един случай, принадлежи в ЕДИН работен поток. Само действията в рамките на един и същ работен поток познават току-що създадената заявка — затова потвърждението може да назове нейния номер, а действие от втори работен поток не може.
Целият пощенски канал — входящ и изходящ — е част от изданието Professional. В Basic системата нито изпраща, нито получава имейли; заявките там се създават през портала, по телефона и от оператора.
