HelpDesk

Терминология
Вземете решение за структурата на проектите HelpDesk
Свързване на пощенска кутия към Easy Redmine
Как да настроите конфигурацията на проекта
Как да настроите конфигурация на проекта – подробности
Как да работите с обработката на билети
Как да конфигурирате шаблони за поща
Как да конфигурирате глобални настройки
Филтър "Нуждаете се от реакция"
Потребители на HelpDesk
Ъглов ситуации

Тези инструкции ще преминат през всички стъпки за конфигуриране на HelpDesk от потребителския интерфейс. От свързване на пощенски кутии към Easy Redmine, през настройки на проекта, до фина настройка на таблата за управление. Това не е техническо ръководство за конфигуриране на cron (или планирани задачи от страна на сървъра). Cron трябва вече да е конфигуриран, за да може HelpDesk да функционира. Инструкциите за настройка на cron са тук.

 

0 Терминология

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

Пощенска кутия - имейл адрес, свързан с Easy Redmine, от който получените имейли се обработват в билети в съответните проекти на HelpDesk
Билет - задача, създадена от получен имейл в пощенска кутия, или задача, създадена вътрешно от клиенти в проект HelpDesk
Проект HelpDesk – проект, свързан с HelpDesk, където могат да се създават билети
Домейн - втората част на имейл адрес. Например от имейл работник.Joe@client.com домейнът е просто client.com
Ключова дума - дума или низ от думи, съдържащи се в тема на пощата
SLA - съгласие за ниво на обслужване. В опростено значение, използвано в Easy Redmine, уговорено време за реакция от страна на компанията на билети, подадени от клиента. Изчислява се в часове
Оригинален имейл – Имейл изпратен до пощенска кутия на HelpDesk, от която е създаден билетът
Оператор - тези термини ще се използват за работника по поддръжката, който работи с билетите

 

1 Вземете решение за структурата на проектите HelpDesk

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

Ето възможностите:

1.1 Един проект за всички билети

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

Пример: Всички ваши клиенти изпращат заявки за поддръжка на support@mycompany.com

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

1.2 Една пощенска кутия, повече проекти на HelpDesk

Пример: Използвате пощенската кутия support@mycompany.com. Всички получени имейли влизат в общ проект. Но имате един клиент, който има специален проект и специални условия> имейлите ОТ домейн client.com се обработват в специалния проект.

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

Друг вариант е проектът HelpDesk по подразбиране да е на първо ниво и специалните проекти под него.

Друг начин, който понякога може да се използва, е структура:

> Клиент1
>> Проект за търговия
>> Проект за изпълнение
>>Проект за HelpDesk

> Клиент2
>> Проект за търговия
>> Проект за изпълнение
>>Проект за HelpDesk

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

1.3 Повече пощенски кутии, без специални клиентски проекти

Пример: Използвате mailboxes support@mycompany.com, info@mycompany.com, it@mycompany.com и имейлите са сортирани само според пощенската кутия, не според подателя.

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

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

1.4 Повече пощенски кутии, със специални клиентски проекти

Текущата функционалност Easy Redmine HelpDesk позволява да се разделят клиентите единствено от подателя, а не чрез комбинация от подател и получател.

Пример: Използвате пощенски кутии support@mycompany.com, info@mycompany.com, it@mycompany.com. Имате специален клиент, изпращащ заявки за поддръжка от домейн client.com

Препоръчителната структура е:

Когато се върнем към структурата на проекта като цяло, трябва да се направят някои допълнителни съображения. Ако се стремите да интегрирате обработката на HelpDesk с различен отдел на вашата организация (например разработка), може да помислите за поставяне на HelpDesk проекти малко по-дълбоко в структурата на проекта.

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

 

2 Свързване на пощенска кутия към Easy Redmine

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

2.1 Администриране >> HelpDesk >> Всички пощенски кутии >> Добавяне на пощенска кутия

2.2 Въведете валидни идентификационни данни за вашата пощенска кутия – щракнете върху Тест за да сте сигурни, че Easy Redmine може да достигне до пощенската кутия

Бележки за настройка:

• Активен - пощенската кутия се сканира редовно от Easy Redmine за нови непрочетени съобщения. Ако е деактивиран, Easy Redmine не проверява пощенската кутия. Но можете да запазите пощенската кутия в Easy Redmine за евентуална бъдеща употреба.
• Използвайте различен подател - когато потребителят на пощенския сървър не е същият като пощенската кутия (например HelpDesk-mail-user). Въведете тук валидния malibox, който е представен от потребителя.
• SSL - ако използвате SSL сертификат на вашия пощенски сървър
• Активирайте OAuth – Протоколът OAuth 2.0 се използва от стотици добре познати услуги като алтернативен метод за удостоверяване. Що се отнася до пощенската кутия на HelpDesk, тя може да се използва за проверка на идентификационните данни на подателя с помощта на външно приложение, поддържано в момента са Работно пространство на Google (преди G Suite) и Microsoft Exchange сметки. Трябва да прочетете документацията на OAuth 2.0 на другото приложение, за да знаете какво точно да въведете във всяко поле. Разбира се, трябва да имате администраторски достъп до другото приложение, за да намерите необходимата информация, като URL адрес на сайта, клиентски идентификатор, тайна на клиента, URL за оторизация, URL адрес на маркера, обхват и т.н.
  
• Папка - ако искате Easy Redmine да проверява само определени папки за непрочетени имейли.
• При успех преминете към – ако имейл е обработен правилно от Easy Redmine (билетът е създаден), той ще бъде преместен там
• При неуспех преминете към – ако имейл е обработен неправилно (билетът не е създаден), той ще бъде преместен там

След като тествате връзката, щракнете върху Запазване.

2.2.1 Къде да намерите идентификационни данни за OAuth 2.0 за акаунти в Microsoft и Google

За да свържете Easy Redmine с акаунт в Google Workspace с помощта на протокол OAuth 2.0, трябва да създадете акаунт в Платформата Google Cloud, получете необходимите идентификационни данни, предоставени там, и ги копирайте в настройките на пощенската кутия в нашето приложение. Могат да се намерят някои полезни инструкции тук.

За да свържете Easy Redmine с акаунт в Microsoft Exchange с помощта на протокол OAuth 2.0, трябва да създадете акаунт в Microsoft Azure portal, вземете необходимите идентификационни данни, предоставени там, и ги копирайте в настройките на пощенската кутия в нашето приложение. Могат да се намерят някои полезни инструкции тук.

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

URL адрес за достъп до OAuth 2.0 във формата "/organizations/oauth2/v2.0/authorize" е валиден само ако достъпът до приложението е разрешен в рамките на организацията. В противен случай URL адресът за достъп трябва да бъде във формата "/[TENANT_ID]/organizations/oauth2/v2.0/authorize". Правилните настройки могат да бъдат намерени в раздела Крайни точки.

Когато в Microsoft Azure е настроено двуфакторно удостоверяване (2FA), всички свързани пощенски кутии трябва да бъдат обновени.

2.2.1.1 Грешка „Потребителят е удостоверен, но не е свързан“

Това е така, защото избраният потребител на Azure, чрез който е регистрирана пощенската кутия, няма разрешение за достъп до пощенската кутия. В този случай не е достатъчно потребителят да е администратор, тъй като той трябва да бъде лицензиран да използва Office 365. Ако потребителят има делегирано разрешение (не му е разрешено да добавя достъп до пощенската кутия, тъй като това изисква одобрение от напр. администратор ), той трябва да получи съответното разрешение за обхват в Azure и едновременно с това да деактивира тази опция.

Решение:

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

Друг възможен проблем е, че акаунтът е създаден като POP3 вместо IMAP. POP3 не поддържа OAUTH в системата.

Решение:

• Уверете се, че акаунтът е зададен като IMAP както в azure, така и в Easy Redmine.

2.2.1.2 Грешка: Microsoft Help Desk се свързва успешно, но спира да работи след известно време

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

2.2.1.3 Случай на използване: Много пощенски кутии, един супер потребител на Help Desk

Ако имате множество пощенски кутии на Help Desk, настроени в Microsoft Exchange и искате да делегирате права за достъп до всички тези пощенски кутии на един потребител, можете да го направите чрез Административен център на Microsoft 365 » Административни центрове » Борса.

Ще бъдете пренасочени към секцията на центъра за администриране на Exchange. Тук щракнете върху раздела Получатели » Пощенски кутии и изберете пощенската кутия, чието право на достъп искате да делегирате. Ще се отвори дясна изскачаща странична лента и щракнете върху Делегиране.

По-долу забележете знака Четене и управление (Пълен достъп) с бутон Редактиране, върху който да щракнете.

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

Потребителят, който изберете, трябва да има администраторски права на Help Desk от страната на Easy Redmine.

2.2.2 Активиране на OAuth 2.0 удостоверяване с Azure Active Directory

Когато използвате OAuth 2.0 удостоверяване, получавате достъп до уеб услуга от клиентско приложение. Начинът, по който правите това, зависи от безвъзмездната помощ, която използвате. В този урок, ще научите как да конфигурирате типа предоставяне на идентификационни данни на клиента за приложения в Azure Active Directory.

2.3 Конфигурирайте честотата на сканиране на пощенската кутия

Щракнете с десния бутон върху пощенската кутия и изберете Настройки

Сега се връщате към настройките на пощенската кутия, но с допълнителна настройка. По подразбиране е зададено на Всеки 5 минути. Но обикновено се препоръчва тази настройка да се извършва на всеки 10 минути. Ако имате много пощенски кутии, свързани към Easy Redmine, тази задача за автоматично сканиране може да отнеме повече време и да претовари сървъра ви с твърде чести сканирания, което ще забави цялото приложение.

Бележки за бутона:

• Изпълни – стартирайте ръчно сканирането на пощенската кутия
• История – преглед на минали сканирания на пощенска кутия
• Изтриване – премахване на пощенска кутия от сканирани пощенски кутии на Easy Redmine
• Деактивиране – деактивиране на автоматичното сканиране на пощенска кутия

2.4 Автоматично изключване

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

Защо? За да спестите вашите ресурси. Защо сървърът трябва да продължава да пингва нефункционираща пощенска кутия?

 

3 Конфигурация на проекта

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

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

3.1 Проект по подразбиране за пощенска кутия

В примерите от миналата глава това ще са проектите Помощно бюро по подразбиране, ИНФОРМАЦИЯ – общо, ИТ – общо, ПОДДРЪЖКА – общо, т.е. не се ограничава до определен домейн на подателя.

1. Кликнете върху „Добавяне към HelpDesk"опция на страницата за преглед на проекта на избрания проект.
   
2. Изберете пощенската кутия, за която проектът ще бъде по подразбиране
   
3. Превъртете надолу и Save

Пълно обяснение на всички настройки на проекта HelpDesk ще последва по-нататък в тази глава.

3.2 Специален клиентски проект

От примерите в глава 1 това ще са проектите: Bohemia Sun, Trains Francais, Клиент 123, Клиент ABC, Клиент XYZ, Клиент 1>>Проект за HelpDesk, Клиент 2>>Проект за HelpDesk

1. Изберете проект
2. Попълнете полетата, маркирани по-долу. Бележките за настройка са под екрана
   
3. Превъртете надолу и Запазване.

Бележки за настройка:

• По подразбиране за пощенска кутия - Не изберете всяка пощенска кутия, ако искате да зададете този проект като специален клиентски проект
• Поща, домейни, ключови думи, обработени в този проект – всички настройки в този раздел са с OR оператор, което означава това ако е изпълнено поне едно условие, в този проект се създава билет
• Попълване на имейл до от – Когато тази опция е избрана, имейлът на автора ще бъде автоматично попълнен в нов билет. Тази опция е полезна, когато имате проекти, където билетите са създадени от реални потребители, вместо чрез обработка на входящи имейли.
• Ключова дума – В този пример, ако имейл е получен в ВСЯКО Пощенската кутия на HelpDesk съдържа целия низ Аз съм от компанията Клиент ABC, билет ще бъде сортиран в този проект. Не използвайте един и същ низ за ключови думи за повече проекти, само първият запис в базата данни с низа ще използва определения низ за ключова дума
• Поща или домейн – входящите имейли се сканират за тези стойности в полето ОТ на имейла. В този пример подателят може да бъде всеки с пощенска кутия, завършваща с clientABC.com, или може да бъде конкретно лице с различен имейл, но ние искаме билетите му да бъдат сортирани в този проект

Пълното обяснение на всички настройки на проекта HelpDesk ще последва по-нататък в следващата глава.

ВАЖНО: Не е най-добрата практика един проект да бъде поставен и като По подразбиране за пощенска кутия И посочени за определена поща или домейн. Всеки подател ще създаде своите билети в този проект, така че не е необходимо да ги уточнявате. Този вид настройка може да доведе до объркване.

3.2.1 Затваряне и архивиране на специален клиентски проект

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

Същото важи и за архивираните проекти.

 

4 Конфигурация на проекта – подробности

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

• Администрация >> HelpDesk >> Всички проекти на HelpDesk >> Редактиране
  
• Настройки на проекта >> HelpDesk
  

4.1 Основни настройки

Бележки за настройка:

• Tracker – нови билети в този проект ще бъдат създадени с този тракер
• Приемник – нови билети в този проект ще бъдат присвоени на този потребител
• Колега – новите билети в този проект ще имат тези колеги (възможен е множество избор)
• Автоматично актуализиране на билети – в зависимост от вашия работен процес, може да има някои билети, които са фактически разрешени, като остават отворени. За такива случаи можете да зададете автоматично затваряне според състоянието и продължителността на неактуализация. В допълнение към затварянето на билета, последващ имейл от шаблона може да бъде изпратен автоматично, като например с цел да информира подателя, че неговият билет е затворен или да го попита за неговото удовлетворение от решението за билета.
• Договорни часове месечно – тази настройка трябва да се използва само за специални клиентски проекти, при които клиентите са предплатили определен брой часове поддръжка на месец
• Обобщени часове – договорът с клиента може да има опция за прехвърляне на неизползвани часове от предходния месец в следващия. Ако клиентът има 10 предплатени часа, но е използвал само 7 от тях през май, 3 часа ще бъдат прехвърлени към юни
• Оставащи часове – колко остава. Бутонът с молив позволява ръчно изчистване на оставащите часове – зададено на 0
• Обобщена начална дата – кога започва предплатения период; трябва да бъде избран ден, който е общ за всички календарни месеци, т.е. ден 1-28
• Обобщен период – за какъв период от време се сумират часовете, преди да бъдат нулирани до първоначалните договорни часове. Ако до края на тримесечието остават още 13 часа (краят на тримесечието се определя от обобщената начална дата), те няма да бъдат прехвърлени в новото тримесечие. Часовете ще бъдат нулирани на 10

Подходящите часове са записи за изразходвано време в проекта. Кои точни записи ще бъдат обяснени по-нататък в това ръководство.

4.2 SLA

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

4.2.1 SLA за билети, генерирани по имейл

Бележки за настройка:

• Име – Заглавие на SLA (за по-добро администриране на SLA в проекта HelpDesk)
• Ключова дума - трябва да се попълни, ако SLA се задава за билети, генерирани по имейл. В този случай има конкретна ключова дума, която ако се съдържа в темата на имейла, билетът ще получи спецификациите на SLA (часове, приоритет, тракер)
• Часове до отговор – краен срок, до който трябва да се извърши първата промяна на статуса на билета. Промяната на статуса показва, че билетът е потвърден и клиентът е уведомен за това
• Часове за решаване – краен срок за затваряне на билета >> поставете го в затворено състояние
• Приоритет – нов билет от имейл, съдържащ ключовата дума, ще има този приоритет
• Tracker – нов билет от имейл, съдържащ ключовата дума, ще има този тракер. Това е полезно например, ако клиентът е намерил дефект в продукта и иска да го съобщи директно като дефект, а не като стандартна заявка за поддръжка. Следователно клиентът ще пише с тема например Дефект - и билетът няма да трябва да бъде класифициран от мениджъра на HelpDesk.
• Бройте SLA въз основа на работното време – крайните срокове за SLA няма да бъдат определени за неработни дни или часове от деня. Някои SLA могат да бъдат ограничени само до работно време, но други могат да бъдат настроени на 24/7
• Работно време на SLA – времева рамка за SLA
• Работни дни – работен календар, в който се регистрират почивни дни, празници и други неработни дни

4.2.2 Подреждане на SLA

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

Пример: Имате договорно дефинирани ключови думи за „Критичен“ и „Критичен бъг“, всяка от тях има различен SLA. Трябва да сте сигурни, че двете теми ще бъдат разграничени, когато имейлите се обработват.

В този случай трябва да поставите SLA „Критичен бъг“ над „Критичен“. Механизмът на обработката на пощенския обект е прост:

1. Потърсете „Критичен бъг“ в темата за поща
2. Ако горният низ не е в темата, потърсете следващия, в нашия случай „Критичен“
3. Ако горният низ не е в темата, продължете да търсите допълнителни ключови думи
4. Последният SLA трябва да бъде общата ключова дума (за неуточнено ниво), използвайки маркировката * за всички обекти

Ако поставите „Critical“ преди „Critical bug“, това би означавало, че имейлите с „Critical bug“ в темата ще бъдат обработени неправилно, защото те биха попаднали под „Critical“ SLA.

---

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

SLA за билет за клиент е нарушен. Какво правите, за да сте сигурни, че сте получили това под контрол? В този случай отидете на Настройки на проекти >> HelpDesk и превъртете докрай надолу

4.2.3 Нулиране на SLA за затворени билети

Също така ще забележите настройка в горната част на SLA секцията.

Когато е активирано, билетите, които веднъж са били затворени и са отворени отново от друг отговор от клиента, ще имат SLA, считани като нови – от момента на отговора на клиента, който е отворил отново билета.
Пример: Билет # 1234 беше отворен в понеделник в 16:00. SLA е 48 часа => времето за разрешаване е до сряда 16:00. Билетът беше затворен от оператор във вторник в 10:00. Клиентът отново отговори, че се нуждае от повече информация във вторник в 14:00. Билет № 1234 вече има нов SLA за четвъртък 14:00.

Когато е деактивиран, SLA винаги ще се брои от първоначалното време, когато билетът е създаден.
Пример: В сценария от първия случай. След отговора на клиента във вторник на 14: 00, SLA няма да бъде нулиран и ще остане в сряда 16: 00. Същото важи и когато клиентът отново отвори билета в четвъртък. Билетът вече ще бъде подчертан като просрочен.

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

4.2.4 SLA за вътрешно създадени билети

Както бе споменато по -рано, билетите не могат да се създават само от имейли. Easy Redmine има усъвършенстван контрол на нивото на достъп, който позволява на клиентите ви да имат директен достъп до системата с ограничени разрешения (за създаване на билети, редактиране на билети, четене на новини, ...).

Билетите, създадени като стандартни задачи от влезли в системата потребители, имат малко по-различен начин за определяне на SLA. Тъй като няма имейли, обработени, не можете да определите SLA по ключови думи. Нека обясним на изображението по-долу.

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

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

4.2.5 Събития и отчети за SLA

Отчетите за SLA се основават на отделни SLA събития. Тези събития могат да се видят за всеки билет HelpDesk, просто проверете SLA Events в долното меню на всеки билет HelpDesk. Когато билетът е отговорен/решен, можете да проверите неговото събитие SLA тук, което ви казва, наред с друга информация, колко време (в часове) всъщност е минало до първия отговор и можете директно да сравните стойността с Изпълнение на SLA отговор (т.е. време, необходимо за първия отговор) и изпълнение на SLA разрешаване (т.е. време, необходимо за разрешаване на билета) според вашите настройки на SLA за този конкретен проект HelpDesk. В допълнение към това, вие незабавно виждате кой и кога е отговорил/решил билета и към кой проект принадлежи този билет. Записите за време се показват с положителен или отрицателен символ (+/-), респ. в зелен/червен цвят, за да подчертаете дали SLA е съставен или не.

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

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

За да видите списъка (общ преглед) на всички SLA събития, отидете на /easy_sla_events или щракнете върху елемента от менюто SLA Reports в менюто на страничната лента на главното табло за управление на HelpDesk (/easy_helpdesk).

SLA събитията могат лесно да бъдат филтрирани според различни SLA, персонализирани полета или други критерии.

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

4.2.6 Доклади за SLA за билети

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

От версия 11plus.2.0 билетите имат две нови полета:

• Първо изпълнение на SLA отговор - взето от първото SLA събитие в билета
  
• Изпълнение на последното решение на SLA - взето от последното SLA събитие в билета

Как работи

Билетът е създаден -> Операторът на Помощното бюро отговаря-> SLA събитието е създадено -> стойностите от това SLA събитие се копират в гореспоменатите атрибути на билета -> клиентът отговаря обратно -> операторът отговаря на клиента -> е създадено ново събитие SLA - > стойността на SLA revolve fultilment, която копира в атрибута на билета.

Къде е стойността

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

• Процент на успех при разрешаване на билети
• Линейна диаграма на абсолютния брой билети с неуспешен отговор/разрешение на SLA във времето

4.3 Персонализирани горен и долен колонтитул

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

4.4 сигнала

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

Друг вид часовници Alerts прекарват време в проекти, при които клиентите са предплатили определено количество часове поддръжка (както е обяснено в глава 4.1).

Бележки за настройка:

• Следете крайната дата на билетите за поддръжка – за да бъдем по-точни Време според SLA. Ако е активирана, сигналите ще бъдат генерирани, когато срокът на SLA наближи. Допълнителни настройки са обяснени по-долу
• Наблюдавайте прекараното време на билетите за поддръжка – следене на прекараното време по проекти с определени предплатени месечни часове
• Списък с сигнали, които трябва да имат зададен получател – това са предварително конфигурирани сигнали, които трябва само да въведат имейл адрес, където да се изпращат известията
• Списък с конфигурирани сигнали – сигнали без липсващ параметър
• Щраквайки върху всеки сигнал, ще видите предварително конфигурираните параметри с възможност да ги редактирате
• Предупреждение / предупреждение: тежест на известието
• Поддръжка на билети навреме – предупреждение наблюдава краен срок за разрешаване на SLA (затваряне на билета)
• Поддръжка на билети часове до отговор – предупреждение следи краен срок за отговор на SLA (първа промяна на състоянието)
• Поддръжка на предплатени часове на билети – предупреждава за изразходването на предплатените месечни часове по проекта

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

Пример: Тракерът по подразбиране за проекта е HelpDesk Ticket. Някои SLA са конфигурирани за грешка на тракера. Проектът съдържа други тракери (задача, разработка на функции), които не се използват за билети. В такъв случай предплатените часове са валидни само за HelpDesk Ticket и Bug. Времето, прекарано в други тракери, не се взема предвид за този сигнал.

4.5 Актуализиране/изтриване

Актуализация – запазване на промените, направени в настройките на HelpDesk на проекта
Изтриване – премахване на проекта от HelpDesk. Това не означава заличаване на проекта като цяло, а само премахнете връзката на проекта с HelpDesk.

 

5 Обработка на билети

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

5.1 Генерирани билети по имейл

За правилното боравене с билети, създадени по имейл, трябва да проверите, че стандартните полета "имейл до"И"имейл куб"са активни. Можете да го проверите Още » Администрация » Тракери » Билет за HelpDesk » Стандартни полета. Ако тези стандартни полета липсват, те трябва да са били деактивирани от администратора.

5.1.1 Имейлът се обработва от Easy Redmine и билетът се създава в определения проект

Забележки:

• имейл до: Подателят на имейла, от който е създаден билетът
• Спецификация на пощенската кутия, от която е създадена задачата
• Стойности на SLA – ако са нарушени, те се подчертават в червено
• Анализиран имейл – Това е текстовото съдържание на имейла. Изображенията не се показват директно в този изглед поради оптимизиране на производителността (особено когато билетът има много отговори и всеки от тях съдържа подпис с логото на компанията, зареждането на билета ще отнеме болезнено много време поради нарастващия размер на всеки от следващия отговор)
• Пълният имейл е наличен като прикачен файл – ако оригиналният имейл съдържа изображения, можете да го видите директно в Easy Redmine.
  

5.1.2 Напишете отговор и актуализирайте билета

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

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

Изпратете бърз имейл на клиента от шаблон

Имате две опции да изпратите имейл до клиента. Когато актуализирате билет HelpDesk, има опция „Изпращане на бърз имейл до клиента от шаблон“, която ви позволява да изберете шаблон за имейл на вашия отговор за подателя на билета. Когато е избран шаблон, имейлът се изпраща незабавно и по този начин не се изискват повече действия. Когато не е избран шаблон, все още имате възможност да изберете шаблона и да потвърдите изпращането на имейл в следващата стъпка, както обикновено (поставете отметка в квадратчето „Изпращане на имейл до клиента (с визуализация) в долната част и запазване). Целта на това функция е главно да спестите вашето време при изпращане на имейли до клиенти.

5.1.3 Изпращане на актуализация до външен имейл (имейл до)

Като натиснете Save, ще запазите актуализациите, направени в билета, и ще стигнете до диалога за изпращане на отговора до клиента.

Забележки:

• Шаблон за имейл – ако имате конфигурирани имейл шаблони, можете да изберете един. Или шаблон ще бъде предварително зададен според състоянието. Тази функция ще бъде обяснена в следващите глави
• Подател на поща – това ще бъде показано на клиента като ОТ. Настройката на населението на това поле ще бъде обяснена в следващите глави
• Тема на пощата – персонализирана или предварително зададена според шаблона на имейла. По подразбиране той се попълва от тема на билета
• Получател на поща – подател на оригиналния имейл. Ако е имало други получатели на оригиналния имейл в CC или TO, те също ще бъдат добавени в това поле.
• Отговор на пощата – това винаги е пощенската кутия на HelpDesk, до която е изпратен оригиналният имейл
• Копие на поща – можете да добавите други получатели
• Основен текст на пощата – ако не е избран шаблон, той ще се състои от последния коментар на билета и оригиналния текст на имейла. Съдържанието може да се редактира.
• Прикачени файлове – можете да изберете прикачени файлове, които да изпратите с имейла. Може да са някои по-скорошни имейли или нови файлове, които сте качили при актуализиране на билета
• Изпращане на поща – имейлът се изпраща до всички получатели
• Не изпращайте поща – ще се върнете към детайлите на билета

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

5.1.4 Клиентът отговаря обратно – как имейлите са сдвоени с билет

Клиентът е получил вашия отговор и отговори обратно. Отговорът ще бъде добавен като коментар от анонимен потребител (потребител, който не е регистриран в системата).

Нека обясним тук как отговорът на клиента намери пътя си към правилния билет.

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

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

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

Съответно, дори ако клиентът напише нов имейл в пощенска кутия на HelpDesk и добави номера на билет (идентификатор на задачата) в темата, той пак ще бъде сдвоен. Като в следния пример.

Нов имейл до пощенска кутия на HelpDesk:

Следваща бележка в билета:

5.1.5 Последният отговор – билетът се затваря

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

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

5.1.6 Поле собственик на билета

Полето на собственика на билета е незадължително стандартно поле, предназначено за използване с билети HelpDesk. Със своя падащ списък той ви позволява да изберете един потребител от всички вече създадени вътрешни потребители и този потребител се счита за собственик на билета. Полето може да бъде активирано или деактивирано за всеки тракер, където може да се наложи да го имате (отидете на Администрация » Тракери » Билет за HelpDesk » поставете отметка в полето и запазете). По подразбиране полето за собственик на билети е деактивирано, така че мениджърите на HelpDesk трябва да отидат в Администрация, за да го активират за конкретен тракер. Въз основа на това поле за билети HelpDesk мениджърите на HelpDesk могат лесно да видят колко билета са получени, затворени/решени или актуализирани според собственика на билета. Така че това може значително да подобри/опрости прозренията на HelpDesk (табла за управление, статистика) и отчетите за определен период от време. Настройките на работния процес, както и бутоните за действие, могат да бъдат приложени към полето на собственика на билета, както всяко друго стандартно или персонализирано поле.

5.1.7 Изпратете имейл до, копие изберете от различни източници на данни

В полета Имейл да се намлява Имейл cc добавена възможност за търсене на имейли от източници на данни:

• Лични контакти (CRM)
  
• Заинтересованите страни
  
• акаунти (CRM)
  
• Потребители на HelpDesk (Помощно бюро)
  

Тази функция е деактивирана по подразбиране. За да го активирате, отидете на Администриране >> Добавки >> Автоматично попълване на имейл поле - Редактирайте и активирайте функцията Автоматично попълване на имейл поле и необходими ресурси за данни.

Без активиране на който и да е от ресурсите за данни, функцията нативно търси сред потребителите.

Как работи

Ако е активирано, полетата на задачите Изпрати имейл до и Як действат като автоматично довършване.

5.2 Вътрешно създадени билети

Ако клиентът подава билети директно във вашата система, работният поток може да бъде дефиниран така, сякаш работите с всякакви други задачи. Ще позволите на клиента да създаде HelpDesk Ticket или Bug. Първоначално те ще бъдат в състояние по подразбиране (повечето време се нарича просто Нови). След това комуникацията върви напред-назад между клиента и оператора чрез серия от актуализации на билети и от смяна на правоприемника, което е необходимо, за да поддържат всички потребители активни в комуникацията. SLAs се наблюдават като в билета, генериран по имейл Отговор: Промяна на състоянието; Решаване: Закриване на билета.

5.3 Билети, създадени чрез REST API

Има възможност задачите/билетите, създадени чрез REST API (например от уеб формуляр), да изглеждат като билети на HelpDesk, създадени от имейл. Просто изпратете "easy_helpdesk_mailbox_username"параметър чрез API, например: issue [easy_helpdesk_mailbox_username] = 'support@company.com ". Това ще накара новосъздадената задача да изглежда като билет HelpDesk от даден имейл адрес, настройките на SLA ще бъдат приложени съответно и благодарствено съобщение ще бъде изпратено до подателя.

 

6 Пощенски шаблони

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

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

Важно свойство на шаблоните за поща е това те са конфигурирани на пощенска кутия, не можете да използвате шаблон от пощенска кутия IT@mycompany.com за имейли, изпратени на support@mycompany.com.

6.1 Създаване на шаблон за имейл

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

6.1.1 Добавяне на нов шаблон

6.1.2 Основни атрибути

Бележки за настройка:

• Използвайте за пощенска кутия – коя пощенска кутия ще има наличен този шаблон
• Състояние на задачата – според това състояние шаблонът ще бъде предварително попълнен в диалога при изпращане на отговора до външна поща (вижте глава 5.1.3.)
  • За да използвате шаблона като автоматично отговор на новосъздадените билети от имейл, задайте състоянието на стандартното (както е конфигурирано в администрация >> състояния на задачите). В действителност, когато билет е създаден от имейл, автоматично отговорът съгласно този шаблон ще бъде изпратен незабавно. Може да се използва за потвърждаване на клиента, че билетът е създаден и какви ще бъдат следващите стъпки.
  • Можете да оставите състоянието празно, в този случай той никога няма да бъде предварително попълнен автоматично в диалога за изпращане на поща, но потребителите ще могат да го изберат ръчно
• Предмет – какво ще съдържа темата
• Препоръчително е да включите идентификатора на задачата в автоматичния отговор – ако имате много билети с един и същ клиент, ще можете по-добре да ги различавате, когато говорите с клиента
• Можете също така да използвате действителната тема, използвана оригиналния имейл на клиента

6.1.3 Динамични токени и тяло на пощата

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

Прост пример за автоматично отговор.

6.1.4 Важни динамични токени

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

За да добавите корпоративен подпис към изходящите имейли, използвайте маркера % User_signature%, Той ще използва HTML подписа на текущия потребител (който актуализира билета), който може да бъде зададен в потребителския профил на потребителя.

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

Ето как изглежда шаблонът.

Така операторът пише актуализацията на билета за коментар.

И това ще бъде изпратеният имейл според шаблона.

Забележка: Когато използвате шаблони за електронна поща, заедно със специални заглавия и основания на имейли за определен проект (глава 4.3.), Заглавката и долния край на проекта обвиват целия имейл, изпратен до клиента, а не само имейл шаблона или просто частта, добавена от последен коментар.

6.2 Шаблон за имейл по подразбиране

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

Поведението е следното:

Предпоставки

• един имейл шаблон може да бъде зададен по подразбиране
• всеки имейл шаблон трябва да има свързана пощенска кутия
• можете да имате повече пощенски кутии във вашата система
• Шаблонът за имейл може да бъде (но не се изисква) свързан с определен статус

ситуации

• билет се създава ръчно (не от имейл) - шаблон от a е предварително избран според състоянието; ако не бъде намерен, шаблонът по подразбиране е предварително избран
• билет се създава от различна пощенска кутия от тази, с която се използва имейл шаблонът по подразбиране – шаблонът с тази пощенска кутия е предварително избран въз основа на състоянието (същото като в момента) => нито един шаблон не се избира автоматично, ако се използва състояние, за което няма зададен шаблон
• се създава билет от пощенската кутия, с която се използва шаблонът по подразбиране – шаблонът е предварително избран въз основа на състоянието – ако не е намерен такъв шаблон, шаблонът по подразбиране е предварително избран

Скриване на SLA данни

Информация за SLA отговор и време за разрешаване на подробности за задачата може да бъде скрита за избрани типове потребители (Администриране >> Потребителски типове >> Редактиране).

SLA може да бъде скрит и за конкретни потребители (Администриране >> Потребители >> Редактиране).

Потребителят няма да вижда SLAs, ако е активирана поне една от настройките, отнасящи се до техния потребител или потребителски тип.

Горен и долен колонтитул на имейлите на HelpDesk

Глобално зададените горен и долен колонтитул на имейл известия (Администрация >> Настройки >> Уведомления по имейл) вече няма да бъдат част от имейлите, изпращани от HelpDesk.

За да добавите горен и долен колонтитул за имейли на HelpDesk, отидете на настройките на HelpDesk на конкретен проект (Проект >> Настройки >> HelpDesk).

Проверете конфигурацията на базата данни

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

Уверете се, че и сървърът на базата данни и config / database.yml имат еднакъв (препоръчителен) набор utf8mb4.

1) и т.н. / my.cnf

character_set_server = utf8mb4
collation_server = utf8mb4_unicode_ci

2) config / database.yml

производство:
  адаптер: mysql2
  база данни: лесно
  хост: 127.0.0.1
  потребителско име: лесно
  парола: „EASY_STRONG_PASSWORD“
  кодираща: utf8mb4

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

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

за DB във YOUR_DB_NAME; правя
  за TABLE в "mysql -e" използвайте $ {DB}; покажете таблици; " --batch --skip-колони-имена | xargs`; правя
    ехо "Конвертиране на $ {DB}. $ {TABLE}"
    mysql -e "променете таблицата $ {DB}. $ {TABLE} ПОДКРЕПЕТЕ НА набор от символи utf8mb4 съпоставете utf8mb4_unicode_ci;"
  направен
направен

Вместо YOUR_DB_NAME въведете името на вашата база данни.

Забележка: Правилната конфигурация на база данни е общо изискване за безупречно стартиране на всяко уеб приложение. Това не е само специфично изискване на тази нова версия на Easy Redmine.

Прекъсвания на персонализиран дизайн (без CSS)

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

Отидете на страница / easy_theme_desings >> намерете своя дизайн >> прекомпилирайте >> заредете отново. Той ще поправи дизайна и ще зареди стиловете.

 

7 Глобални настройки

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

Бележки за настройка:

• Подател – кой имейл е посочен като ОТ в отговорите на билета до клиента (във връзка с глава 5.1.3.)
  • Текущ регистриран потребител – потребител, който актуализира билета
  • По подразбиране от известия по пощата – имейл, който се използва за изпращане на стандартни известия от системата до потребителите. Настройва се Администриране >> настройки >> известия по имейл
  • Адрес на пощенска кутия – имейл, който е получил оригиналната поща от клиента
  • Тази настройка е слабо свързана с последното квадратче за отметка Разрешаване на потребителски подател – ако е активирано, можете да зададете персонализиран имейл като подател в настройките на HelpDesk на проекта. Ако даден проект има имейл, попълнен в настройката, той ще отмени настройката на Sender
• Активиране на актуализиране на атрибутите на задачата – ако е активирано, е възможно да промените определени атрибути на билета по имейл. Например чрез писане приоритет: Високо в тялото на пощата, съответно бихте променили приоритета. Това е доста напреднала функция и не се препоръчва да се използва с клиенти
• Приемайте автоматично генерирани имейли – например бюлетини
• Игнориране на CC на получените имейли – ако е активирано, имейлите в CC не се обработват и използват в полето "имейл до"на билета (глава 5.1.3. забележка за получателя на пощата)
• Промяна на състоянието след отговор на клиента на – всеки път, когато клиент напише отговор, който актуализира билета, състоянието ще бъде съответно променено. Това е особено полезно, когато билетите са поставени в затворено състояние след изпращане на отговор от оператора. Освен ако клиентът не отговори с допълнителен въпрос, билетът ще остане затворен и скрит от активните обяви. Когато клиентът отговори, билетът ще бъде отворен отново и ще се върне към активната опашка от отворени билети
• Суспендиране на SLA за билет, когато статус е – това са статуси, когато срокът на SLA не е определен, тъй като билетът чака въвеждане от клиента, без което операторът няма шанс да осигури поддръжка
• Бройте SLA за билет, когато състоянието е – когато SLA се измерва нормално. С тези функции можете добре да настроите цикъла на билета. Например, операторът иска от клиента повече информация, поставя състоянието на pasive и SLA е на пауза. След отговора на клиента състоянието се променя на консултация и SLA се преизчислява според оставащото време до крайния срок на SLA, когато билетът е бил отговорен

Във версия 12 бюрото за помощ получи още една интересна метрика - Билетите са разрешени от поддръжката. Ще можете да докладвате общ брой или съотношение на билети, които никога не са напускали екипа за поддръжка.

Как работи

1. Първо трябва да определите кои потребители са членове на поддръжката в Help desk >> Настройки на Help desk - Разрешено от поддръжката настройки
   
   
   
2. Настройките за подзадачи/свързани задачи ще определят дали билетите, разрешени от поддръжката, могат или не могат да съдържат подзадачи или свързани задачи
3. Сега препоръчваме да натиснете бутона в менюто на бюрото за помощ - Преизчисли
   
   Това ще оцени билетите от последните 90 дни
4. Накрая отидете в списъка със задачи и намерете филтъра Разрешено от поддръжката
   
   

Този филтър ще покаже билети, които са били присвоени само на членове на поддръжката (съгласно настройката в точка 1). Въз основа на настройките в точка 2, билетите, които съдържат подзадачи или свързани задачи, могат или не могат да бъдат отчетени като разрешени от поддръжката.

 

8 Филтър „Необходима е реакция“

„Необходима е реакция“ е атрибут на билетите за HelpDesk и CRM случаите. По подразбиране този атрибут е зададен на "Не". Той ще се промени на „Да“, когато билет / казус бъде определен за лице, което отговаря на него чрез изпращане на имейл съобщение вместо да го присвоите на изпращача в Клиентска зона или Easy Redmine, В такъв случай правоприемникът на билета / делото остава непроменен и затова планираният получател може да не забележи, че актуализацията е извършена. За да предотврати това, получателят трябва редовно да проверява всички елементи с атрибут „Нуждаете се от реакция“, зададен на „Да“, така че лесно да разбере, че има нещо ново, което трябва да провери или да отговори, дори да не му е възложено. Или можете да го използвате, когато имате нужда да "маркирате" някой клиентски билет, на който вече сте отговорили, но все още има някаква работа по него и трябва да информирате клиента по-късно отново. Използвайки "Задачи от филтъра", можете просто да създадете поле на началната си страница, преглед на CRM или преглед на HelpDesk като този по-долу.

 

9 потребители на HelpDesk (от версия 11+)

Сред най-големите допълнения към HelpDesk през последните години са така наречените потребители на HelpDesk. Тяхната цел е да опростят управлението на клиентския достъп до вашия Easy Redmine. Освен това много по-лесно за самите клиенти да подават билети и да общуват с вашите оператори директно в приложението.

9.1 Предпоставки

Управлението на потребителите на HelpDesk е с разрешения Преглеждайте/управлявайте потребителите на HelpDesk в раздела HelpDesk в Администрация >> Роли и разрешения.

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

Потребителската страница на HelpDesk съдържа 3 типа модули:

• Нов формуляр за билет – Той няма настройки, просто го поставете за максимално удобство на вашите клиенти.
• HelpDesk билети – списък с билети, създаден от потребителя на HelpDesk. Всеки потребител може да види само билети, които сам е създал. Този модул е ​​конфигурируем, като всички други модули "списък" в приложението. Той съдържа полета, видими за потребителите на HelpDesk в билетите. Ако възнамерявате да покажете както отворени, така и затворени билети за потребителите на HelpDesk, препоръчваме да ги показвате в отделни модули.
• Табло за обяви – само в случай, че искате да споделите персонализирана информация с клиентите.

9.2 Управление на потребителите на HelpDesk

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

Изискват се всички атрибути:

• Име
• Фамилия
• Имейл = Вход
• Език
• Проект – това е проектът, в който ще бъдат създадени билети от този потребител. Тук могат да бъдат избрани само отворени проекти, които са свързани към HelpDesk.
• Парола – по време на създаването на потребител трябва да въведете парола с опция за генериране на токен за парола, така че потребителят да може да зададе своя собствена парола чрез връзка в имейл. По време на редактирането на потребителя очевидно не е необходима промяна на паролата.

Допълнителни разрешения:

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

Вижте всички задачи = Позволява на потребителя на бюрото за помощ да вижда всички създадени билети в рамките на един и същи проект

Управлявайте всички задачи = Позволява на потребителя на бюрото за помощ да редактира конкретни полета от вече създадени билети (Заглавие, Описание и също така да добавя нов прикачен файл; но не и да редактира стария).

Случай за употреба

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

9.2.1 Импортиране на CSV

От версия 11plus.2.0 е възможно да се импортират потребители на бюрото за помощ чрез CSV. Моля, свържете се с вашия консултант относно тази опция.

9.3 Влизане като потребител на HelpDesk

Потребителите на HelpDesk влизат през различна входна точка от обикновените потребители. На екрана за вход под бутона за вход можете да намерите превключвател. За да насочите клиентите си към влизане в HelpDesk, използвайте URL /helpdesk/вход. Както бе споменато по -горе, имейл се използва като име за вход.

ВАЖНО: Потребителите на HelpDesk са технически независими от редовните потребители. Можете да използвате един и същ имейл за един обикновен потребител и един потребител на HelpDesk.
Въпреки това практиката подсказва, че това не трябва да е така. Вие или създавате потребителски акаунт в HelpDesk, или решавате, че потребителят се нуждае от пълен акаунт. И двата типа акаунти за едно лице трябва да се използват само за тестови цели.

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

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

9.3.1 LDAP удостоверяване за потребители на HelpDesk

От версия 11plus.2.0 потребителите на бюрото за помощ могат да бъдат удостоверени чрез LDAP.

Конфигурацията е в Администратор >> Плъгини >> Потребители на Помощното бюро >> Редактиране - Нов режим на удостоверяване.

Формулярът е идентичен с обикновената LDAP конфигурация, като единствената разлика е, че се прилага за потребители на бюрото за помощ => на страница /helpdesk/login

9.4 Работа с билети

От гледна точка на клиента

Потребителят на HelpDesk създава билет чрез формуляра за нов билет на началната си страница. Единствените налични атрибути са Тема, Описание и прикачени файлове. Философията е, че клиентите не трябва да се тревожат за организационни въпроси, когато се нуждаят от помощ от вашата грижа за клиентите. Те просто заявяват проблема си и очакват решение. Без избор на проект, без категории, без персонализирани полета, без избор на приоритет – всичко това е отговорност на вашия екип за поддръжка.

Билетът ще бъде създаден в проект, който се задава директно на потребителя на HelpDesk. Поле Email за в билета се попълва по имейл на потребителя на HelpDesk. Този потребител също ще бъде зададен като Автор на HelpDesk на билета, който е скрит атрибут (несвързан с автор, което е общ атрибут на всички задачи в Easy Project). Това гарантира, че те винаги ще виждат билета, дори ако го преместите на

Ъглов ситуации

• Ситуацията, когато даден синдик не е член на проекта, може да възникне в следните случаи:
  • цесионерът е отстранен от проекта, но задачите остават възложени на него,
  • процесът на автоматично актуализиране на билети се задава в модула HelpDesk по такъв начин, че някои билети автоматично се присвояват на бивш член на проекта.
• Информация за SLA Response се появява в детайла на задачата само когато задачата е в състояние по подразбиране, което е дефинирано в съответния тракер.
• Силно препоръчваме да не променяте приоритета на билет, когато билетът е спрял SLA, тъй като подобно действие би повлияло неблагоприятно на правилното изчисляване на SLA на този билет.