Служба поддержки

В этих инструкциях мы рассмотрим все шаги по настройке Службы поддержки из пользовательского интерфейса. От подключения почтовых ящиков к INOUT Проект, через настройки проекта, до настройки приборных панелей. Это не техническое руководство по настройке Крона (или запланированных задач на стороне сервера). Крон уже должен быть настроен для работы Службы поддержки.

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

Начнем со словаря терминов, используемых в данном руководстве.

• Почтовый ящик — адрес электронной почты, подключенный к INOUT Проект, с которого полученные электронные письма обрабатываются в саппорт-тикеты в соответствующих проектах Службы поддержки.
• Саппорт-тикет — задание, созданное из полученного письма в почтовом ящике, или задание, созданное клиентами в проекте Службы поддержки.
• Проект Службы поддержки — проект, подключенный к Службе поддержки, в котором могут быть созданы саппорт-тикеты
• Домен — вторая часть адреса электронной почты. Например, с электронной почты worker.Joe@client.com домен — это просто client.com.
• Ключевое слово — слово или строка слов, содержащаяся в теме письма
• SLA — соглашение об уровне обслуживания. В упрощенном значении, используемом в INOUT Проект, договорное время реакции компании на саппорт-тикеты, предоставленные клиентом. Рассчитывается в часах
• Оригинальный email — Email, отправленный на почтовый ящик Службы поддержки, с которого был создан саппорт-тикет.
• Оператор — этот термин будет использоваться для сотрудника службы поддержки, который работает с саппорт-тикетами.

Примите решение о структуре проектов Службы поддержки

В зависимости от того, хотите ли вы иметь один проект для всех саппорт-тикетов, или различать почтовые ящики Службы поддержки, или даже иметь специальные проекты для разных клиентов, вам необходимо принять решение о структуре проектов до начала любой конфигурации. Это решение повлияет на некоторые дальнейшие шаги, перечисленные в данном руководстве.

Ниже перечислены возможные варианты:

Единый проект для всех билетов

Если у вас будет только один проект, который собирает письма с одного почтового ящика, то нет необходимости принимать решение — все письма, отправленные на этот почтовый ящик, создают саппорт-тикеты в одном проекте.

Пример: Все ваши клиенты отправляют запросы в службу поддержки на support@mycompany.com.

Не имеет значения, на каком уровне находится этот проект, в основном он живет своей собственной жизнью в любой части структуры вашего проекта. Однако, если вы планируете начать с одного проекта и в дальнейшем продолжать расширять Службы поддержки, вам следует ознакомиться с приведенными ниже вариантами.

Один почтовый ящик, несколько проектов Службы поддержки

Пример: Вы используете почтовый ящик support@mycompany.com. Все полученные электронные письма попадают в общий проект. Но у вас есть один клиент, у которого есть специальный проект и особые условия — письма от домена client.com обрабатываются в специальном проекте.

Конечно, вы можете иметь больше клиентов, разделенных таким образом. В этом случае структура проекта может выглядеть следующим образом:

Другой вариант — иметь дефолтный проект Службы поддержки на первом уровне и специальные проекты под ним.

Другой способ, который иногда может быть использован — это структура:

>Клиент1

>>Проект для коммерции

>>Проект для реализации

>>Проект для Службы поддержки

>Клиент2

>>Проект для коммерции

>>Проект для реализации

>>Проект для Службы поддержки

Однако, это не рекомендуется, если вы планируете собирать саппорт-тикеты из различных проблем в некоторые агрегированные списки, статистику или сводки.

Больше почтовых ящиков, без специальных клиентских проектов

Пример: Вы используете почтовые ящики support@mycompany.com, info@mycompany.com, it@mycompany.com и письма сортируются только по почтовому ящику, а не по отправителю.

В таком случае вы можете иметь 3 проекта на одном уровне и, возможно, под главным проектом, охватывающим их все.

Эти проекты могут быть совершенно несвязанными и относиться к отдельным разделам вашей организации, они могут находиться в разных деревьях проектов (под разными главными проектами).

Больше почтовых ящиков, со специальными клиентскими проектами

Текущая функциональность INOUT Проект Службы поддержки позволяет разделять клиентов исключительно по отправителю, а не по комбинации почтового ящика отправителя и получателя.

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

Рекомендуемая структура такова:

Когда мы возвращаемся к структуре проекта в целом, необходимо рассмотреть еще некоторые моменты. Если вы нацелены на интеграцию обработки Службы поддержки с другим отделом вашей организации (например, с отделом разработки), вы можете рассмотреть возможность размещения проектов Службы поддержки немного глубже в структуре проекта.

Правильная структура проектов позволит вам генерировать различные отчеты, списки, статистику по большему количеству этапов вашего бизнеса.

Подключение почтового ящика к INOUT Проект

Теперь мы можем приступить к фактической настройке компонентов Службы поддержки. Чтобы INOUT Проект мог обрабатывать почтовые ящики, их необходимо подключить следующим образом.

Администрирование > Служба поддержки > Все почтовые ящики > Добавить почтовый ящик

Введите действительные учетные данные почтового ящика — нажмите «Тест», чтобы убедиться, что INOUT Проект может связаться с почтовым ящиком.

Примечания к настройкам:

• Активный — почтовый ящик регулярно сканируется INOUT Проект на наличие новых непрочитанных сообщений. Если эта настройка отключена, INOUT Проект не проверяет почтовый ящик. Но вы можете сохранить почтовый ящик в INOUT Проект для возможного использования в будущем.
• Использовать другого отправителя — когда пользователь на почтовом сервере не совпадает с почтовым ящиком (например, Службы поддержки—mail-user). Введите здесь действительный почтовый ящик, который представляет пользователь.
• SSL — если вы используете SSL-сертификат на почтовом сервере.
• Включить OAuth — протокол OAuth 2.0 используется сотнями известных сервисов в качестве альтернативного метода аутентификации. Что касается почтового ящика Службы поддержки, его можно использовать для проверки учетных данных отправителя с помощью внешнего приложения, в настоящее время поддерживаются учетные записи Google Workspace (ранее G Suite) и Microsoft Exchange. Вам необходимо прочитать документацию OAuth 2.0 другого приложения, чтобы знать, что именно вводить в каждое поле. Конечно, вы должны иметь администраторский доступ к другому приложению, чтобы найти необходимую информацию, такую как URL сайта, ID клиента, секрет клиента, авторизационный URL, URL токена, область применения и т.д.
• Папка — если вы хотите, чтобы INOUT Проект проверял только определенные папки на наличие непрочитанных писем.
• При успехе переместить в — если письмо правильно обработано INOUT Проект (создан саппорт-тикет), оно будет перемещено туда.
• В неудаче переместить в — если письмо обработано неправильно (саппорт-тикет не был создан), оно будет перемещено туда.
• После тестирования соединения нажмите «Добавить».

Где найти учетные данные OAuth 2.0 для учетных записей Microsoft и Google

Чтобы соединить INOUT Проект с аккаунтом Google Workspace по протоколу OAuth 2.0, необходимо создать аккаунт на Google Cloud Platform, получить там необходимые учетные данные и скопировать их в настройки почтового ящика в нашем приложении. Некоторые полезные инструкции можно найти здесь.

Для подключения INOUT Проект к учетной записи Microsoft Exchange с использованием протокола OAuth 2.0 необходимо создать учетную запись на портале Microsoft Azure, получить там необходимые учетные данные и скопировать их в настройки почтового ящика в нашем приложении. Некоторые полезные инструкции можно найти здесь.

Настройте частоту сканирования почтового ящика

Щелкните правой кнопкой мыши на почтовом ящике и выберите Настройки

Теперь вы вернулись к настройкам почтового ящика, но с дополнительным параметром. По умолчанию она установлена на Каждые 10 минут. Но обычно рекомендуется устанавливать этот параметр примерно каждые 15 минут. Если у вас много почтовых ящиков, подключенных к INOUT Проект, эта задача автоматического сканирования может занять больше времени и перегрузить ваш сервер слишком частым сканированием, что замедлит работу всего приложения.

Примечания к кнопкам:

• Выполнить — вручную запустить сканирование почтовых ящиков.
• История — просмотр прошлых сканирований почтовых ящиков.
• Удалить — удалить почтовый ящик из списка сканируемых почтовых ящиков INOUT Проект.
• Деактивировать — деактивировать автоматическое сканирование почтовых ящиков

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

Почтовый ящик подключается и сканируется INOUT Проект, но до сих пор мы не установили, где должны создаваться саппорт-тикеты. Пока проект не подключен к Службе поддержки, саппорт-тикеты не могут быть созданы, потому что, в общем, каждая задача требует проекта.

Эта часть будет разбита на различные сценарии, в соответствии с целью каждого проекта.

Проект по умолчанию для почтового ящика

В примерах прошлой главы это будут дефолтные проекты Службы поддержки, ИНФО — общий, ИТ — общий, ПОДДЕРЖКА — общий, т.е. не ограниченные определенным доменом отправителя.

• Нажмите опцию «Добавить в Службу поддержки» на странице обзора проекта выбранного проекта.

• Выберите почтовый ящик, для которого проект будет использоваться по умолчанию 
• Прокрутите вниз и сохраните
• Полное объяснение всех настроек проекта Службы поддержки последует далее в этой главе.

Специальный клиентский проект

• Выберите проект
• Заполните поля, выделенные ниже. Примечания по настройке находятся под скриншотом 
• Прокрутите вниз и сохраните.

Примечания к настройкам:

• Почтовый ящик по умолчанию — НЕ выбирайте никакой почтовый ящик, если вы хотите установить этот проект как специальный клиентский проект.
• Письма, домены, ключевые слова, обрабатываемые в этом проекте — все настройки в этом разделе имеют оператор OR, что означает, что при выполнении хотя бы одного условия, саппорт-тикет будет создан в этом проекте.
• Ключевое слово — в данном примере, если письмо, полученное на ЛЮБОЙ почтовый ящик Службы поддержки, содержит целую строку «Клиент АБВ», саппорт-тикет будет отсортирован в этот проект. Не используйте одну и ту же строку ключевого слова для нескольких проектов, только первая запись в базе данных с этой строкой будет использовать обозначенную строку ключевого слова
• Почта или домен — входящие письма проверяются на наличие этих значений в поле «ОТ» письма. В данном примере отправителем может быть любой человек, чей почтовый ящик заканчивается на @klient.ru, или это может быть конкретный человек с другим электронным адресом, но мы хотим, чтобы его билеты были отсортированы в этом проекте.

Полное объяснение всех настроек проекта Службы поддержки последует далее в следующей главе.

ВАЖНО! Это не лучшая практика — иметь один проект, установленный по умолчанию для почтового ящика и определенный для определенной почты или домена. Саппорт-тикеты любого отправителя будут созданы в этом проекте, поэтому вам не нужно их указывать. Такая настройка может привести к путанице.

Закрытие и архивирование специального клиентского проекта

Когда такой проект закрывается (фактически становясь доступным только для чтения), в нем невозможно будет создавать саппорт-тикеты. Таким образом, этот проект перестанет быть специальным клиентским проектом, а письма, приходящие с доменов, установленных в настройках Службы поддержки, будут обрабатываться как неизвестные и попадать в общий проект Службы поддержки.

То же самое относится и к архивным проектам.

Конфигурация проекта — детали

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

• Администрирование > Службы поддержки > Все проекты Службы поддержки > Редактировать 
• Настройки проекта > Службы поддержки 

Основные настройки

Примечания к настройкам:

• Тип задания — новые саппорт-тикеты в этом проекте будут создаваться с этим типом задания
• Назначаемое лицо — новые саппорт-тикеты в этом проекте будут назначаться этому пользователю
• Коллега — новые саппорт-тикеты в этом проекте будут иметь этих коллег (возможен множественный выбор)
• Автоматическое обновление саппорт-тикетов — в зависимости от вашего рабочего процесса, могут существовать некоторые саппорт-тикеты, которые фактически решены, но остаются открытыми. Для таких случаев вы можете установить автоматическое закрытие в соответствии со статусом и продолжительностью отсутствия обновления. Помимо закрытия саппорт-тикета, может быть автоматически отправлено последующее письмо из шаблона, например, для информирования отправителя о том, что его саппорт-тикет был закрыт, или с вопросом о его удовлетворенности решением саппорт-тикета.
• Контрактные часы ежемесячно — эта настройка должна использоваться только для специальных клиентских проектов, где клиенты внесли предоплату за определенное количество часов поддержки в месяц.
• Агрегированные часы — в контракте с клиентом может быть предусмотрена возможность переноса неиспользованных часов из предыдущего месяца в следующий. Если у клиента 10 предоплаченных часов, но в течение мая он использовал только 7 из них, 3 часа будут перенесены на июнь.
• Оставшиеся часы — сколько осталось. Кнопка с карандашом позволяет вручную очистить оставшиеся часы — устанавливается на 0.
• Агрегированная дата начала — когда начинается предоплаченный период; необходимо выбрать день, общий для всех календарных месяцев, т.е. 1—28 день.
• Агрегированный период — на какой период времени агрегируются часы, прежде чем они будут возвращены к исходным договорным часам. Если к концу квартала (конец квартала определяется по дате начала Агрегированного периода) остается 13 часов, они не переносятся на новый квартал. Количество часов будет сброшено до 10.
• Оставшиеся часы — это записи о затраченном времени в проекте. Какие именно записи будут описаны далее в этом руководстве.

SLA

Это важная метрика любого проекта Службы поддержки, но особенно для специальных клиентских проектов, где нарушение SLA может быть санкционировано. Как уже упоминалось, саппорт-тикеты могут создаваться по электронной почте или непосредственно в системе клиентами, имеющими специально ограниченный доступ к проекту Службы поддержки. Оба случая имеют небольшие нюансы в настройке SLA.

SLA для саппорт-тикетов, созданных по электронной почте

Примечания к настройке:

• Название — название SLA (для более удобного администрирования SLA в проекте Службы поддержки).
• Ключевое слово — должно быть заполнено, если SLA устанавливается для саппорт-тикетов, генерируемых по электронной почте. В этом случае существует определенное ключевое слово, которое, если оно содержится в теме письма, саппорт-тикету будут присвоены характеристики SLA (часы, приоритет, тип задачи).
• Часы до ответа — крайний срок, до которого должно произойти первое изменение статуса саппорт-тикета. Изменение статуса означает, что саппорт-тикет был принят к рассмотрению и клиент был проинформирован о нем.
• Часы на решение — крайний срок, до которого необходимо закрыть саппорт-тикет, то есть перевести его в статус закрытого
• Приоритет — новый саппорт-тикет из письма, содержащего ключевое слово, будет иметь данный приоритет
• Тип задачи — новый саппорт-тикет из письма, содержащего ключевое слово, будет иметь данный тип задачи. Это полезно, например, если клиент обнаружил дефект в продукте и хочет сообщить о нем непосредственно как о дефекте, а не как о стандартном запросе в службу поддержки. Клиент напишет, например, «Дефект» — и саппорт-тикету не придется классифицироваться менеджером Службы поддержки.
• Рассчитывать SLA на основе рабочего времени — сроки SLA не будут устанавливаться для нерабочих дней или часов дня. Некоторые SLA могут быть ограничены только рабочим временем, но другие могут быть установлены на 24/7
• Рабочие часы SLA — временные рамки для SLA
• Рабочие дни — рабочий календарь, в котором регистрируются выходные, праздничные и другие нерабочие дни

Упорядочивание SLA

При большем количестве уровней, ключевых слов и строк ключевых слов важно правильно соблюдать порядок. Темы писем проверяются на наличие ключевых слов в соответствии с порядком в настройках «Службы поддержки».

Пример: У вас есть определенные договором ключевые слова «Критический» и «Критическая ошибка», у каждого из них свой SLA. Вам нужно убедиться, что эти две темы будут различаться при обработке писем.

В этом случае вам нужно поместить SLA «Критическая ошибка» выше «Критической». Механизм обработки темы письма прост:

• Ищем «Критическая ошибка» в теме письма.
• Если указанной строки нет в теме письма, ищем следующую, в нашем случае «Критический».
• Если вышеуказанной строки нет в теме письма, продолжайте поиск следующих ключевых слов.
• Последнее SLA должно быть общим (для неопределенного уровня) ключевым словом с использованием знака * для всех субъектов
• Если вы поставите «Критический» перед «Критической ошибкой», это будет означать, что письма с «Критической ошибкой» в теме будут обработаны неправильно, поскольку они попадут под SLA «Критический».

В целом, чем специфичнее строка ключевого слова, тем выше должна быть его позиция.

SLA по клиентскому билету было нарушено. Что вы делаете, чтобы убедиться, что все под контролем? В этом случае перейдите в Настройки проекта > Службы поддержки и прокрутите страницу вниз.

Сброс SLA для закрытых саппорт-тикетов

Вы также заметите настройку в самом верху раздела SLA.

Если эта настройка включена, то саппорт-тикеты, которые были закрыты и открыты повторным ответом клиента, будут иметь SLA, как если бы они были новыми — с момента ответа клиента, который повторно открыл саппорт-тикет.

Пример: Саппорт-тикет #1234 был открыт в понедельник в 16:00. SLA — 48 часов => время на решение — до 16:00 среды. Саппорт-тикет был закрыт оператором во вторник в 10:00. Клиент снова ответил, что ему нужна дополнительная информация во вторник в 14:00. Для билета #1234 теперь установлен новый SLA на четверг 14:00.

Если функция отключена, SLA всегда будет отсчитываться от первоначального времени создания саппорт-тикета.

Пример: В сценарии из первого примера. После ответа клиента во вторник в 14:00, SLA не будет сброшен и останется на 16:00 среды. То же самое происходит, когда клиент повторно открывает саппорт-тикет в четверг. Теперь билет будет выделен как просроченный.

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

SLA для саппорт-тикетов, созданных внутри проекта

Как было сказано ранее, саппорт-тикеты могут создаваться не только из электронных писем. INOUT Проект имеет расширенный контроль уровня доступа, который позволяет предоставлять вашим клиентам прямой доступ к системе с ограниченными правами (создавать саппорт-тикеты, редактировать саппорт-тикеты, читать новости...).

Саппорт-тикеты, созданные как стандартные задачи вошедшими в систему пользователями, имеют несколько иной способ определения SLA. Поскольку не обрабатываются электронные письма, вы не можете определить SLA по ключевым словам. Поясним это на изображении ниже.

При создании SLA для билетов, созданных внутри компании, оставьте ключевое слово пустым. SLA будет определяться комбинацией приоритета и отслеживания. Когда вы сохраните настройки, ключевое слово исчезнет, указывая на то, что этот SLA используется для билетов, созданных внутри компании. Если вы оставите трекер пустым, будут учитываться только ключевые слова.

Эффективно настроив рабочий процесс, вы можете ограничить клиентов создавать саппорт-тикеты только в определенных типах задач, даже если в проекте их больше. Например, вы можете разрешить клиентам использовать только тип задачи Службы поддержки саппорт-тикета и ошибки (бага), чтобы вы могли установить SLA только для этих типов задач. Все остальные типы задач не будут требовать установки SLA, потому что они не будут подаваться клиентами и, следовательно, не будут считаться саппорт-тикетами Службы поддержки.

События и отчеты SLA

Отчеты SLA основаны на отдельных событиях SLA. Эти события можно просмотреть в каждом саппорт-тикете Службы поддержки, просто проверьте «События SLA» в нижнем меню любого саппорт-тикета Службы поддержки. Когда саппорт-тикет отвечает/решается, вы можете проверить его SLA событие здесь, которое сообщает вам, среди прочей информации, сколько времени (в часах) прошло до первого ответа, и вы можете напрямую сравнить это значение с выполнением SLA ответа (т.е. время, необходимое для первого ответа) и SLA разрешения (т.е. время, необходимое для разрешения саппорт-тикета) в соответствии с вашими настройками SLA в этом конкретном проекте Службы поддержки. Кроме того, вы сразу же видите, кто и когда ответил/решил саппорт-тикет и к какому проекту принадлежит этот саппорт-тикет. Временные записи отображаются с положительным или отрицательным символом (+/-), а также зеленым или красным цветом, чтобы подчеркнуть, было ли SLA выполнено или нет.

Событие SLA создается только тогда, когда на саппорт-тикет поддержки действительно ответили, отправив электронное письмо клиенту, а не раньше. Добавление комментария к саппорт-тикету не приводит к созданию события SLA, поскольку неясно, является ли такой комментарий просто внутренним сообщением или ответом на запрос клиента.

Когда саппорт-тикет поддержки перемещается из одного проекта в другой, событие SLA не пересчитывается. SLA саппорт-тикета остается от исходного проекта, в котором был создан саппорт-тикет. Пересчет SLA инициируется только при изменении типа или приоритета задачи.

Чтобы просмотреть список (обзор) всех SLA событий, нажмите на пункт меню Отчёты SLA в боковом меню главной панели Службы поддержки.

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

Все события SLA, суммированные в общую статистику SLA, можно найти на панели отчетов SLA. По умолчанию эта панель доступна в верхнем меню главной панели Службы поддержки. Используя эту панель, вы можете мгновенно увидеть общий процент неудачных ответов SLA, неудачных разрешений SLA и средний первый ответ. Поскольку приборная панель является стандартной персонализированной страницей, как и многие другие, вы можете настроить все модули, отображаемые на приборной панели, чтобы они лучше соответствовали вашим потребностям.

Отчеты по SLA саппорт-тикетам

В дополнение к вышесказанному, можно также делать SLA-отчеты по саппорт-тикетам.

Саппорт-тикеты имеют два новых поля:

• Выполнение первого ответа SLA — берется из первого события SLA в саппорт-тикете.
• Выполнение последнего разрешения SLA — берется из последнего события SLA в саппорт-тикете.

Как это работает

Создается саппорт-тикет -> оператор службы поддержки отвечает -> создается SLA событие -> значения из этого SLA события копируются в вышеупомянутые атрибуты саппорт-тикета -> клиент отвечает -> оператор отвечает клиенту -> создается новое SLA событие -> значение SLA выполнение операции копируется в атрибут саппорт-тикета.

Где находится значение

Поскольку саппорт-тикет сам по себе содержит наиболее важные данные SLA отчетности, вы можете делать отчеты об удовлетворении SLA непосредственно над саппорт-тикетами.

Некоторые примеры:

• Коэффициент успешного разрешения саппорт-тикетов
• Линейная диаграмма абсолютного количества саппорт-тикетов с неудачным ответом/решением SLA в срок

Пользовательский верхний и нижний колонтитул

Эта настройка касается общения Службы поддержки по электронной почте, т.е. общения в саппорт-тикетах, сгенерированных по электронной почте. Вы можете настраивать электронные письма из различных проектов Службы поддержки, будь то использование корпоративного стиля, спецификации условий или даже раскрытие конфиденциальности.

Оповещения

Для того чтобы предотвратить нарушение SLA, существует возможность использовать автоматические оповещения, которые уведомляют соответствующий персонал о надвигающихся проблемах в виде отложенных саппорт-тикетов.

Другой тип оповещений отслеживает затраченное время в проектах, где клиенты предварительно оплатили определенное количество часов поддержки.

Примечания по настройке:

• Следить за сроками выполнения саппорт-тикетов поддержки — точнее, за временем выполнения в соответствии с SLA. Если эта функция включена, будут генерироваться предупреждения, когда приближается срок выполнения SLA. Дальнейшие настройки описаны ниже
• Контроль сроков выполнения заявок на поддержку — просмотр потраченного времени на проекты с указанными предоплаченными месячными часами.
• Список оповещений, для которых необходимо установить получателя — это предварительно настроенные оповещения, для которых необходимо только ввести адрес электронной почты, на который должны быть отправлены уведомления
• Список настроенных оповещений — оповещения без отсутствующего параметра
• Нажав на каждое оповещение, вы увидите предварительно настроенные параметры с возможностью их редактирования
• Предупреждение/оповещение — серьезность уведомления
• Время выполнения заявок на поддержку — оповещение следит за сроком выполнения SLA (закрытие заявки)
• Время ответа на саппорт-тикеты поддержки — предупреждение следит за сроком ответа по SLA (первое изменение статуса)
• Предоплаченные часы по саппорт-тикетам поддержки — предупреждение следит за расходованием предоплаченных месячных часов на проект.
• Часы, просмотренные в последнем оповещении — это те часы, которые зарегистрированы в саппорт-тикетах, которые находятся в типах задач, указанных в настройках Службы поддержки проекта.

Пример: Тип задачи по умолчанию для проекта — Службы поддержки саппорт-тикета. Для типа задачи «Ошибка» настроен некоторый SLA. Проект содержит другие типы задач (Задача, разработка функции), которые не используются в саппорт-тикетах. В этом случае предоплаченные часы действительны только для Службы поддержки саппорт-тикета и ошибки. Время, затраченное на другие типы задач, не учитывается в данном оповещении.

Сохранить/удалить

• Обновить — сохранить изменения, сделанные в настройках Службы поддержки проекта
• Удалить — удалить проект из Службы поддержки. Это не означает удаление проекта в целом, а только удаление связи проекта с Службы поддержки.

Обработка саппорт-тикетов

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

Саппорт-тикеты, созданные по электронной почте

Для корректной обработки саппорт-тикетов, созданных по электронной почте, вам необходимо проверить, что стандартные поля «Адресат» (email to) и «Дополнительные адресаты» (email cc) активны. Вы можете проверить это в разделе Подробнее > Администрирование > Тип задачи > Саппорт-тикеты службы поддержки > Стандартные поля. Если эти стандартные поля отсутствуют, они должны быть отключены администратором.

Электронное письмо обрабатывается INOUT Проект, а саппорт-тикет создается в определенном проекте

Примечания:

• Адресат (email to) —отправитель электронной почты, из которой был создан саппорт-тикет
• Спецификация почтового ящика, из которого было создано задание
• Значения SLA — если они нарушены, они выделяются красным цветом
• Разобранное письмо — это текстовое содержимое письма. Изображения не отображаются непосредственно в этом представлении в целях оптимизации производительности (особенно если в саппорт-тикете много ответов и каждый из них содержит подпись с логотипом компании, саппорт-тикет будет загружаться очень долго из—за увеличения размера каждого следующего ответа).
• Полное письмо доступно как вложение — если оригинальное письмо содержит изображения, вы можете просмотреть его прямо в INOUT Project. 

Написание ответа и обновление саппорт-тикета

Чтобы выполнить SLA, нам необходимо изменить статус и написать ответ клиенту в первый раз. В следующих примерах не забывайте о коммуникации по саппорт-тикету, это просто для демонстрации того, как технически работает коммуникация.

Менеджер написал ответ клиенту о получении саппорт-тикета, назначил его оператору и изменил статус. Ответ будет отправлен клиенту (email to), когда вы установите флажок.

Отправка быстрого электронного письма клиенту из шаблона

У вас есть два варианта отправки электронного письма клиенту. При обновлении саппорт-тикета Службы поддержки есть опция «Отправить быстрое письмо клиенту из шаблона», позволяющая выбрать шаблон электронного письма с ответом для отправителя саппорт-тикета. При выборе шаблона электронное письмо отправляется мгновенно, поэтому больше никаких действий не требуется. Если шаблон не выбран, у вас остается возможность выбрать шаблон и подтвердить отправку письма на следующем шаге, как обычно (поставьте галочку «Отправить письмо клиенту (с предварительным просмотром)» в нижней части и сохраните). Эта функция предназначена в основном для экономии вашего времени при отправке писем клиентам.

Отправка обновления на внешнюю электронную почту (email to)

Нажав кнопку «Сохранить», вы сохраните обновления, сделанные в саппорт-тикете, и перейдете к диалогу отправки ответа клиенту.

Примечания:

• Шаблон почты — если у вас настроены шаблоны электронной почты, вы можете выбрать один из них. Или же шаблон будет предустановлен в зависимости от статуса. Эта функция будет описана в следующих главах
• Отправитель письма — это поле будет показано клиенту как «От» (From). Настройка населенности этого поля будет описана в следующих главах
• Тема письма — пользовательская или заданная в соответствии с шаблоном письма. По умолчанию оно заполнено темой билета.
• Получатель письма — отправитель исходного письма. Если в «Cс» или «To» были другие получатели исходного письма, они также будут добавлены в это поле.
• Ответ по почте — это всегда почтовый ящик Службы поддержки, на который было отправлено оригинальное письмо.
• Копия письма — вы можете добавить других получателей
• Тело письма — если шаблон не был выбран, оно будет состоять из последнего комментария к саппорт-тикету и текста оригинального письма. Содержимое можно редактировать.
• Вложения — вы можете выбрать вложения для отправки вместе с письмом. Это могут быть несколько последних писем или новые файлы, которые вы загрузили при обновлении саппорт-тикета.
• Отправить письмо — письмо будет отправлено всем получателям
• Не отправлять письмо — вы вернетесь к деталям саппорт-тикета

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

Ответ клиента — как электронные письма связываются с саппорт-тикетом

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

Давайте объясним, как ответ клиента попал в нужный саппорт-тикет.

Когда на предыдущем этапе менеджер отправил электронное письмо клиенту, оно содержало скрытый заголовок (как и все электронные письма) с идентификатором саппорт-тикета. При ответе на письмо этот заголовок содержался и в ответе клиента, поэтому Службы поддержки определил его и добавил ответ к билету с тем же ID.

Вот все способы сопряжения полученных электронных писем с саппорт-тикетами в системе.

Скрытый заголовок письма, где сохраняется идентификатор задания

Тема письма, где ищется комбинация «#» и ID задания.

Если это не найдено, тема письма ищется только по номеру.

Соответственно, даже если клиент напишет новое письмо на почтовый ящик Службы поддержки и добавит в тему номер саппорт-тикета (ID задачи), оно все равно будет сопряжено.

Последний ответ — саппорт-тикет закрывается

Последний ответ от оператора, с которым саппорт-тикет закрывается. После закрытия саппорт-тикета, SLA для решения также исчезнет из детализации саппорт-тикета.

Если клиент ответит снова, саппорт-тикет будет снова открыт в определенном статусе (эта настройка будет описана далее).

Поле владельца билета

Поле «Владелец саппорт-тикета» — это необязательное стандартное поле, предназначенное для использования в саппорт-тикетах Службы поддержки. С помощью выпадающего списка оно позволяет выбрать одного пользователя из всех уже созданных внутренних пользователей, и этот пользователь будет считаться владельцем саппорт-тикета. Поле может быть включено или отключено для любого типа задач, где оно может понадобиться (перейдите в Администрирование > Типы задач > Саппорт-тикет Службы поддержки > отметьте поле и сохраните). По умолчанию поле «Владелец саппорт-тикета» отключено, поэтому менеджеры Службы поддержки должны зайти в Администрирование, чтобы включить его для определенного типа задачи. На основании этого поля в саппорт-тикетах Службы поддержки менеджеры Службы поддержки могут легко увидеть, сколько саппорт-тикетов было получено, закрыто/решено или обновлено в соответствии с владельцем саппорт-тикета. Таким образом, это может значительно улучшить/упростить аналитику Службы поддержки (информационные панели, статистику) и отчеты за определенный период времени. Настройки рабочего процесса, а также кнопки действий могут быть применены к полю «Владелец саппорт-тикета» так же, как и к любому другому стандартному или пользовательскому полю.

Внутренне созданные саппорт-тикеты

Если клиент отправляет саппорт-тикеты непосредственно в вашей системе, рабочий процесс может быть определен так же, как если бы вы работали с любыми другими задачами. Вы позволите клиенту создать Службы поддержки саппорт-тикет или ошибку (баг). Изначально они будут находиться в статусе по умолчанию (чаще всего он называется просто «Новый»). Затем связь идет туда и обратно между клиентом и оператором путем серии обновлений саппорт-тикетов и смены назначенного лица, что необходимо для того, чтобы все пользователи были активны в общении. SLA отслеживаются, как в сгенерированном по электронной почте саппорт-тикет Ответ: Изменение статуса; Разрешение: Закрытие саппорт-тикета.

Саппорт-тикеты, созданные через REST API

Существует возможность для задач/саппорт-тикетов, созданных через REST API (например, из веб-формы), выглядеть как саппорт-тикеты Службы поддержки, созданные по электронной почте. Просто отправьте параметр «easy_helpdesk_mailbox_username» через API, например: issue[easy_helpdesk_mailbox_username] = 'support@company.com'. Это приведет к тому, что вновь созданное задание будет выглядеть как саппорт-тикет Службы поддержки с указанного адреса электронной почты, настройки SLA будут применены соответствующим образом, а отправителю будет отправлено благодарственное сообщение.

Почтовые шаблоны

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

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

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

Создание почтового шаблона

Существует два типа почтовых шаблонов: автоответчик и стандартный шаблон. Поскольку они не отличаются по конфигурации, мы объясним оба случая сразу.

Примечания к настройке:

• Использовать для почтового ящика — для какого почтового ящика будет доступен данный шаблон
• Статус задачи — в соответствии с этим статусом шаблон будет заполнен в диалоге при отправке ответа на внешнее письмо
• Чтобы использовать шаблон в качестве автоответчика на вновь созданные саппорт-тикеты из электронной почты, установите статус по умолчанию (как настроено в Администрировании > Статусы задач). В результате, когда саппорт-тикет будет создан из электронного письма, автоответ в соответствии с этим шаблоном будет отправлен немедленно. Его можно использовать для подтверждения клиенту, что саппорт-тикет был создан и каковы будут дальнейшие шаги
• Вы можете оставить статус пустым, в этом случае он никогда не будет заполняться автоматически в диалоге отправки письма, но пользователи смогут выбрать его вручную
• Тема — что будет содержать тема письма
• Рекомендуется включить ID задачи в автоответ — если у вас много саппорт-тикетов с одним и тем же клиентом, вы сможете лучше различать их при разговоре с клиентом.

Вы также можете использовать фактическую тему, использованную в исходном письме клиента.

Динамические маркеры и тело письма

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

Простой пример автоответа.

Важные динамические маркеры

Если вы собираетесь эффективно использовать почтовые шаблоны, необходимо включить в шаблон маркер %task_note%. Он будет использовать комментарий, который вы в последний раз добавили к саппорт-тикету, и окружать его другим текстом в шаблоне.

Чтобы добавить корпоративную подпись в исходящие электронные письма, используйте маркер %user_signature%. Он будет использовать HTML-подпись текущего пользователя (который обновляет саппорт-тикет), которая может быть установлена в профиле пользователя.

Примечание: При использовании шаблонов писем вместе со специальными заголовками и колонтитулами писем по определенному проекту, заголовки и колонтитулы проекта обволакивают все письмо, отправляемое клиенту, а не только шаблон письма, или только ту часть, которая добавлена последним комментарием.

Шаблон письма по умолчанию

Можно выбрать шаблон электронной почты Службы поддержки в качестве шаблона по умолчанию. Это означает, что когда вы отправляете комментарий клиенту, есть большая вероятность того, что шаблон уже выбран (оставляя меньше ручной работы для агента поддержки).

Поведение выглядит следующим образом:

Необходимые условия

• Один шаблон электронной почты может быть установлен по умолчанию
• Каждый шаблон электронной почты должен иметь связанный почтовый ящик
• В вашей системе может быть больше почтовых ящиков
• Почтовый шаблон может быть (но не обязательно) связан с определенным статусом.

Ситуации

• Саппорт-тикет создается вручную (не из электронной почты) — шаблон предварительно выбирается в соответствии со статусом; если он не найден, выбирается шаблон по умолчанию
• Саппорт-тикет создается из почтового ящика, отличного от того, с которым используется почтовый шаблон по умолчанию — шаблон из этого ящика предварительно выбирается на основе статуса (как и в настоящее время) => шаблон автоматически не выбирается, если используется статус, для которого нет назначенного шаблона
• Саппорт-тикет создается из почтового ящика, с которым используется шаблон по умолчанию — шаблон предварительно выбирается на основе статуса — если такой шаблон не найден, то предварительно выбирается шаблон по умолчанию

Скрыть данные SLA

Информация о SLA ответах и времени решения в деталях задачи может быть скрыта для выбранных типов пользователей (Администрирование > Типы пользователей > Редактировать).

SLA также можно скрыть для определенных пользователей (Администрирование > Пользователи > Редактировать).

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

Верхний и нижний колонтитулы электронных писем Службы поддержки

Глобально установленные заголовок и колонтитул уведомлений электронной почты (Администрирование > Настройки > Уведомления электронной почты) больше не будут частью писем, отправляемых из Службы поддержки.

Чтобы добавить верхний и нижний колонтитул для писем Службы поддержки, перейдите в настройки Службы поддержки конкретного проекта (Проект > Настройки > Службы поддержки).

Глобальные настройки

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

Примечания к настройкам:

• Отправитель — какой email указан как FROM в ответах на саппорт-тикет клиенту
  • Текущий зарегистрированный пользователь — пользователь, который обновляет саппорт-тикет
  • Почтовое уведомление по умолчанию — email, который используется для отправки стандартных уведомлений от системы пользователям. Устанавливается в разделе Администрирование > Настройки > Почтовые уведомления
  • Адрес почтового ящика — электронная почта, на которую пришло оригинальное письмо от клиента.
  • Эта настройка связана с последним чекбоксом «Разрешить пользовательского отправителя» — если он включен, вы можете установить пользовательский email в качестве отправителя в настройках Службы поддержки проекта. Если в настройках проекта есть заполненный email, он будет переопределять настройку отправителя
• Включить обновление атрибутов задачи — если включено, можно изменить определенные атрибуты в саппорт-тикете по электронной почте. Например, написав в теле письма приоритет «Высокий», вы соответствующим образом измените приоритет. Это довольно сложная функция, и ее не рекомендуется использовать с клиентами
• Принимать автогенерируемые письма — например, информационные бюллетени
• Игнорировать CC полученных писем — если включено, письма в CC не обрабатываются и не используются в поле «Получатель электронного письма» саппорт-тикета.
• Изменять статус после ответа клиента — каждый раз, когда клиент пишет ответ, который обновляет саппорт-тикет, статус будет изменен соответствующим образом. Это особенно полезно, когда саппорт-тикеты переходят в статус закрытых после того, как оператор отправил ответ. До тех пор, пока клиент не ответит на него каким-либо дополнительным вопросом, билет будет оставаться закрытым и скрытым из активных объявлений. Когда клиент ответит, саппорт-тикет будет снова открыт и возвращен в активную очередь открытых саппорт-тикетов
• Приостановить SLA для саппорт-тикета при статусе — это статусы, когда срок выполнения SLA не определен, так как саппорт-тикет ожидает ответа от клиента, без которого у оператора нет шансов оказать поддержку
• Подсчет SLA для саппорт-тикета, когда статус — когда SLA обычно измеряется. С помощью этих функций можно красиво настроить цикл саппорт-тикета. Например, оператор запрашивает у клиента дополнительную информацию, переводит статус в пассивный и SLA приостанавливается. После ответа клиента статус меняется на консультацию и SLA пересчитывается в соответствии с оставшимся временем до дедлайна SLA, когда был дан ответ на саппорт-тикет.

Фильтр «Нужная реакция»

«Нужна реакция» — это атрибут саппорт-тикетов Службы поддержки и кейсов CRM. По умолчанию этот атрибут имеет значение «Нет». Он изменится на «Да», когда саппорт-тикет/дело будет назначен человеку, который ответит на него, отправив сообщение по электронной почте, вместо того, чтобы назначить его обратно отправителю в Клиентскую зону или INOUT Проект. В этом случае получатель билета/дела остается неизменным, поэтому адресат может не заметить, что обновление было произведено. Чтобы предотвратить это, получатель должен регулярно проверять все элементы с атрибутом «Нужна реакция», установленным на «Да», так он легко узнает, что есть что-то новое, что он должен проверить или ответить, даже если это не назначено на него. Или вы можете использовать его, когда вам нужно отметить какой-то саппорт-тикет клиента, на который вы уже ответили, но над ним еще есть работа, и вам нужно проинформировать клиента позже еще раз. Используя модуль «Задачи из фильтра», вы можете просто создать поле на главной странице, в обзоре CRM или в обзоре Службы поддержки.

Пользователи Службы поддержки

Одним из самых больших дополнений к Службы поддержки за последние годы стали так называемые пользователи Службы поддержки. Их цель — упростить управление доступом клиентов к вашему проекту INOUT Проект. Кроме того, это значительно облегчает самим клиентам отправку саппорт-тикетов и общение с вашими операторами прямо в приложении.

Необходимые условия

Управление пользователями Службы поддержки находится в Службе поддержки в Администрирование > Роли и разрешения.

Другая настройка, которую необходимо проверить перед началом создания пользователей Службы поддержки — это Администрирование > Настройка страницы > Службы поддержки пользователей > Обзор шаблонов. В базовой стартовой конфигурации должен быть существующий шаблон страницы. Важно, чтобы шаблон был установлен по умолчанию — этот шаблон будет автоматически применяться к новым пользователям Службы поддержки. В противном случае у пользователей Службы поддержки будет пустая страница после входа в систему.

Страница пользователя Службы поддержки содержит 3 типа модулей:

• Форма нового саппорт-тикета — она не имеет никаких настроек, просто разместите ее для максимального удобства ваших клиентов.
• Саппорт-тикеты Службы поддержки — список саппорт-тикетов, созданных пользователем Службы поддержки. Каждый пользователь может видеть только те саппорт-тикеты, которые он сам создал. Этот модуль настраивается, как и все остальные модули списка в приложении. Он содержит поля, видимые для пользователей Службы поддержки в саппорт-тикетах. Если вы собираетесь показывать открытые и закрытые саппорт-тикеты для пользователей Службы поддержки, мы рекомендуем показывать их в отдельных модулях.
• Доска объявлений — на случай, если вы хотите поделиться с клиентами какой-то пользовательской информацией.

Управление пользователями Службы поддержки

Список пользователей Службы поддержки доступен как отдельный элемент в кнопках управления на панели Службы поддержки.

Все атрибуты являются обязательными:

• Имя
• Фамилия
• Электронная почта = Логин
• Язык
• Проект — это проект, в котором будут создаваться саппорт-тикеты от данного пользователя. Здесь могут быть выбраны только открытые проекты, подключенные к Службы поддержки.
• Пароль — при создании пользователя необходимо ввести пароль. При редактировании пользователя изменение пароля, очевидно, не требуется.

Импорт CSV

Возможен импорт пользователей службы поддержки через CSV. Пожалуйста, свяжитесь с вашим консультантом по поводу этой опции.

Вход в систему в качестве пользователя Службы поддержки

Пользователи Службы поддержки входят в систему через другую точку входа, чем обычные пользователи. На экране входа в систему под кнопкой входа в систему находится переключатель. Чтобы направить своих клиентов на вход в Службу поддержки, используйте URL /helpdesk/login. Как упоминалось выше, в качестве имени входа используется электронная почта.

ВАЖНО: Пользователи Службы поддержки технически независимы от обычных пользователей. Вы можете использовать один и тот же email для одного обычного пользователя и одного пользователя Службы поддержки. 

Хотя, как показывает практика, этого делать не следует. Вы либо создаете учетную запись пользователя Службы поддержки, либо решаете, что она не будет использоваться. Оба типа учетных записей для одного человека должны использоваться только в целях тестирования.

После входа в систему сам портал состоит из главной страницы, которая была настроена администратором, но не может быть настроена самим пользователем Службы поддержки. В правом верхнем углу находится доступ к профилю, включая режим редактирования. Рядом с ним — кнопка выхода из системы. Нажав на существующий билет или создав новый билет, пользователь будет перенаправлен в детали билета, где он может добавить комментарии или вложения. Чтобы вернуться на главную страницу, просто нажмите на логотип в левом верхнем углу.

У пользователя Службы поддержки нет настроек ролей и разрешений, и вы не можете предоставить ему дополнительный доступ к определенным областям. Приведенный выше список — это все, к чему они могут получить доступ. Вы не должны отправлять им ссылки на элементы в вашем приложении. Это приведет только к сообщению об отказе в доступе.

Аутентификация LDAP для пользователей Службы поддержки

Пользователи службы поддержки могут быть аутентифицированы через LDAP.

Конфигурация находится в Администратор > Плагины > Пользователи справочной службы > Редактировать > Новый режим аутентификации.

Форма идентична обычной конфигурации LDAP, с той лишь разницей, что она применяется к пользователям справочной службы => на странице /Служба поддержки/Вход.

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

С точки зрения клиента

Пользователь Службы поддержки создает саппорт-тикет через форму «Новый саппорт-тикет» на своей домашней странице. Единственными доступными атрибутами являются: Тема, Описание и Вложения. Философия заключается в том, что клиенты не должны беспокоиться об организационных вопросах, когда им нужна помощь вашей службы поддержки. Они просто излагают свою проблему и ожидают решения. Никакого выбора проекта, никаких категорий, никаких пользовательских полей, никакого выбора приоритета — за все это отвечает ваша служба поддержки.

Саппорт-тикет будет создан в проекте, который задается непосредственно пользователем Службы поддержки. Поле «Получатель» в саппорт-тикете заполняется электронной почтой пользователя Службы поддержки. Этот пользователь также будет установлен как автор Службы поддержки саппорт-тикета, что является скрытым атрибутом (не связанным с Автор, который является общим атрибутом всех задач в INOUT Проект). Это гарантирует, что он всегда будет видеть саппорт-тикет, даже если вы переместите его в другой проект.

Детали саппорт-тикета, видимые пользователю Службы поддержки:

• Тема
• Описание
• Вложения
• Статус
• ID
• Последнее обновление (время и дата)
• Создан (время и дата)
• Неприватные комментарии в истории

ВАЖНО! Ограниченный вид билета для пользователя Службы поддержки находится под другим URL, чем обычный вид билета. Например, билет #123 показывается пользователю Службы поддержки под URL /easy_helpdesk_issues/123. Обычная ссылка /issues/123 недоступна для пользователей Службы поддержки.

Обновление саппорт-тикета со стороны пользователя Службы поддержки заключается, опять же, очень просто, в добавлении комментария и/или вложения.

Что происходит с саппорт-тикетом, когда клиент добавляет комментарий?

Статус автоматически изменяется в соответствии с настройками в Службы поддержки > Настройки Службы поддержки > Изменение статуса после ответа клиента.

Флаг «Нужна реакция» устанавливается автоматически.

Эта логика была основана на существующем поведении коммуникации саппорт-тикет <-> электронное письмо, когда Клиент просто пишет письмо и не беспокоится о том, как оно будет обработано на стороне системы Службы поддержки. Только теперь клиент может получить доступ и просмотреть саппорт-тикет в более читаемой структуре, вместо того, чтобы расшифровывать его в своем почтовом ящике.

С точки зрения оператора

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

Самое важное, что нужно помнить, это то, что пользователи Службы поддержки имеют ограниченный просмотр каждого саппорт-тикета. Это ограниченное представление находится под URL /easy_helpdesk_issues/123 => вы не можете использовать обычный URL (/issues), чтобы поделиться ссылкой на саппорт-тикет с пользователями Службы поддержки. Кнопка для копирования ссылки на саппорт-тикет Службы поддержки доступна в правом верхнем углу детализации саппорт-тикета (выделена на скриншоте выше).

Помните, что пользователь Службы поддержки может видеть только неприватные комментарии. Если вы пишете комментарий для пользователя Службы поддержки, убедитесь, что вы сняли флажок приватный.

Клиент видит все вложения в саппорт-тикете, если вам нужно поделиться конфиденциальными файлами с коллегами, не загружайте их в саппорт-тикет Службы поддержки.

Как уведомить клиента о вашем сообщении? Для пользователей Службы поддержки не существует жестко заданных уведомлений по электронной почте. Чтобы отправить электронное сообщение пользователям Службы поддержки, просто продолжайте работать как с саппорт-тикетами, сгенерированными исключительно по электронной почте.

Как просматривать саппорт-тикеты, на которые ответили пользователи Службы поддержки? Опять же, без изменений, саппорт-тикеты автоматически устанавливаются в статус на основе уже существующих настроек. В то же время, включена функция Need reaction, так что вы точно не пропустите саппорт-тикет.

Что насчет исполнителя? Получателем должен быть тот, кто в данный момент работает с саппорт-тикетом. Вы не можете назначить саппорт-тикет пользователю Службы поддержки, потому что, как уже говорилось, они не являются обычными пользователями. По сути, это ничем не отличается от обычных саппорт-тикетов по электронной почте, где автор анонимный, и вы не присваиваете их обратно Клиенту. Чтобы информировать пользователей службы поддержки о саппорт-тикетах, на которые был дан ответ и которые, возможно, нуждаются в некотором участии Клиента, используйте четкий понятный статус.

Назначение существующих саппорт-тикетов пользователям службы поддержки

История очень распространенная: вы пользуетесь службой поддержки уже некоторое время. Теперь вы решаете предоставить своим клиентам доступ в качестве пользователей справочной службы. Главный вопрос заключается в том, как предоставить им доступ к существующим саппорт-тикетам?

Ответ приходит с помощью простого инструмента, который связывает пользователя справочной службы с уже существующими саппорт-тикетами. Работает он просто:

Перейдите к списку пользователей справочной службы

• Нажмите на «Наполнение автора службы поддержки»
• Выберите фильтр — какие задания должны быть доступны
• Выберите пользователя справочной службы
• Подтвердите

Если вы ошиблись, всегда можно удалить доступ к этим саппорт-тикетам, выбрав пользователя справочной службы «Никто».

Наши рекомендации

В функциональности пользователей Службы поддержки можно настроить относительно много, поэтому мы хотели бы поделиться некоторыми примерами хорошей практики для вашего вдохновения.

Называйте интуитивно понятно статусы ваших саппорт-тикетов

— Особенно статус, в котором вы передаете саппорт-тикет клиенту. Должно быть понятно, что ход за ними, если вам нужен от них какой-то ответ, или что саппорт-тикет передан и будет закрыт автоматически, и никаких действий предпринимать не нужно.

— Пользователь Службы поддержки может видеть статус, для него должно быть понятно, что происходит с саппорт-тикетом, даже без явного комментария оператора.

Сохраняйте главную страницу понятной для пользователей Службы поддержки

— Само собой разумеется, разместите на странице только один модуль для нового саппорт-тикета

— Разделяйте списки саппорт-тикетов в зависимости от их использования. Один из примеров — Разделение открытых и закрытых саппорт-тикетов на разные модули. Другой подход — разделить саппорт-тикеты, требующие действий от клиента, и остальные саппорт-тикеты (независимо от открытого/закрытого статуса). Только не переусердствуйте с количеством различных списков

— Списки саппорт-тикетов имеют настраиваемые заголовки — используйте их в интересах ваших Клиентов

— Разумно сортируйте список саппорт-тикетов

Добавьте ссылку на саппорт-тикет в шаблоны электронной почты

— Вы, вероятно, будете продолжать использовать шаблоны электронной почты для отправки уведомлений Клиентам об обновлении саппорт-тикетов. Будет удобно добавить ссылку на саппорт-тикет, по которой клиент сможет получить к нему доступ. Ссылка имеет вид: https://[your_application_URL]/easy_helpdesk_issues/%task_id_without_hash% 

— Когда клиент нажимает на ссылку и не вошел в систему, он будет направлен на страницу /Службы поддержки/login.

Отчеты над саппорт-тикетами, созданными пользователями Службы поддержки?

— На приборных панелях (например, приборная панель Службы поддержки), вы можете добавить список модулей, отчет, диаграмму, тенденции, общий показатель, временной ряд, и выбрать саппорт-тикеты сущности Службы поддержки для различных типов отчетов.

Установите один шаблон электронной почты по умолчанию

— Поскольку саппорт-тикеты, созданные пользователями Службы поддержки, не привязаны автоматически к почтовому ящику, операторы будут иметь потенциально много шаблонов электронной почты для выбора при отправке письма. Облегчите им задачу и установите один шаблон по умолчанию.

Проблемные ситуации

Ситуация, когда получатель задания не является участником проекта, может возникнуть в следующих случаях:

• получатель был удален из проекта, но задачи остаются назначенными ему
• в модуле Службы поддержки установлен процесс автоматического обновления саппорт-тикетов таким образом, что некоторые саппорт-тикеты автоматически назначаются на бывшего члена проекта.

Информация о SLA Response появляется в детализации задачи только тогда, когда задача находится в статусе по умолчанию, который определен на соответствующем трекере.