Использование OTRS

Оглавление

Использование OTRS.. 1

Введение или что это такое. 1

Почему нельзя обойтись просто почтой. 2

Аналогия. 3

Базовые операции. 4

Действующие лица для примеров. 5

Сценарии. 6

Универсальный сценарий. 6

Письмо от клиента-чаво. 6

Согласование/консультация. 6

Консультация с внешним специалистом.. 6

Обработка "плохих" заявок. 7

Введение или что это такое

• OTRS — это система обработки инцидентов/заявок от участников/пользователей/заявителей, т.е. от людей с ролью:
• Клиент(Customer) — человек, у которого Проблема (иначе зачем ему писать письмо, звонить, …).
• Проблема — что-то, что хочет Клиент (зарегистрироваться, чтобы мы что-то сделали, чтобы мы чего-то не делали — не важно).
• Заявка(Ticket) — трек, описывающий ход решения проблемы. Порождается действием Клиента (письмом, звонком, …).
• Агент(Agent) — менеджер, который участвует в решении проблемы. Агентов может быть несколько, они могут делиться по уровню ответственности, направлению решаемых задач и т. д.
• Владелец(Owner) заявки — агент, который взялся решать данную проблему.
• Ответственный (Responsible) за тикет — агент, который решает данную проблему. Разница с владельцем в том, что владелец может делегировать решение другому агенту (сделать его текущим ответственным), но в целом именно владелец отвечает за заявку.
• Агенты могут оставлять Заметки(Note) к заявке.

Технически с заявкой также связаны понятия:

• Очередь (Queue)— в которой лежит заявка.
• Очередь может быть внутри другой очереди (т.е. быть её подочередью), права никак не зависят.
• Группа (Group) — определяет права на очередь.

Рассматривается версия OTRS 4, официальную документацию можно посмотреть здесь

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

• оповещения о новых заявках поступают только заинтересованным именно в этих заявках
• изначально (можно поменять) оповещения о своих действиях не приходят (что исключает возможность перепутать с другими оповещениями)
• многие действия по заявке могут быть совмещены, например:
• можно оставить внутренний комментарий и закрыть
• или ответить и закрыть/изменить статус
• можно при смене очереди сразу сменить и владельца

Почему нельзя обойтись просто почтой

Почта — это отличный инструмент, более того, OTRS использует почту как механизм общения между Заявителем и Агентом. Чтобы организовать совместную работу через почту существует два способа:

• все письма на адрес support@ приходят всем агентам, которые ответственны за входящую почту, но этот случай мы далее рассматривать не будем, т.к. имеются следующие недостатки:
• ответы агента видит только агент
• непонятно, кто на какие письма должен отвечать (как поделить письма: по алфавиту (и должен ли агент обрабатывать заявку и от Андрея Яшина и Яшина Андрея?)
• агенты вынуждены читать письма (заголовки писем), которые к ним не имеют отношения.
• либо все агенты имеют доступ к одному ящику через IMAP-протокол:
• прочитанное письмо отличается от непрочитанного (т.е. можно делить так: берем непрочитанное и обрабатываем)
• проблема: как отличить нами прочитанное от другим человеком прочитанное?
• А если письмо открыли, но прочитать не успели? Вспомнит ли агент про него?
• ответы на письма лежат в одном месте (теоретически к переписке можно подключить другого агента)

Ниже мы рассмотрим разные примеры, чтобы ответить на вопрос, чем OTRS лучше, чем просто почта, а пока можно отметить следующие особенности:

• Заявка не может быть удалена (в то время как письмо удалить легко и менеджер искренне будет доказывать, что письма не было вообще).
• при этом запись/удаление должны работать, т.к. у письма есть статус прочитано/не прочитано, а, скажем, для Maildir-хранения это — перекладывание из директории new в директорию cur
• Вся переписка в Заявке хранится в одном месте
• письма почтовые клиенты тоже научились группировать/показывать списком (письмо-ответ-ответ на ответ-...)
• но делают они это по теме письма, поэтому в группу может попасть и просто похожее письмо.
• Всегда видно, на какие заявки дан ответ, а на какие — нет. Письмо можно пометить, как прочитанное, но найти все письма, на которые не был дан ответ — задача не тривиальная.
• тем более, что на ответное письмо вида "да, теперь всё хорошо" отвечать и не требуется.

Аналогия

Рассмотрим пример:

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

Базовые операции

Подробно рассмотрены в «Простые операции в OTRS»

В частности, о том:

• как настраивать внешний вид системы
• что/как можно сделать с заявкой

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

Действующие лица для примеров

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

Администратор:

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

Агенты:

• агент-секретарь:
• может понять, в какой отдел должна адресоваться заявка и даже запрашивать недостающие данные при наличии инструкции
• агент-стажер:
• тот, кто еще только учится по данному направлению. Возможно он сильный специалист в другой области.
• агент-спец (специальный), для которого общение напрямую с клиентом нежелательно, т.е. это, например, из-за того, что он:
• агент-консультант: специалист в узкой области;
• агент-авторизатор: разрешает или нет определенные действия другому агенту;
• агент-мизантроп/агент-грубиян: может быть хорошим техническим специалистом, но с людьми лучше ему не общаться;
• агент-молчун: слабое владение языком клиента (возможно и родным для агента);
• агент-наблюдатель: ему требуется доступ на уровне агента, но не желательно, чтобы он мог влиять на систему

Клиенты:

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

Дополнительно:

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

Сценарии

Универсальный сценарий

Письмо от клиента-чаво

Это простой сценарий, т.к. оператору ничего придумывать не нужно:

• Поскольку вопрос стандартный, то на него уже есть стандартный ответ.
• Если таких заявок может быть несколько/много, то администратору стоит завести шаблон ответа для часто задаваемых вопросов
• о создании шаблона можно посмотреть в «Технические подробности OTRS»

Об использовании шаблона при ответе см. «Ответ на сообщение в заявке OTRS»

Согласование/консультация

Это как раз тот случай, когда требуется помощь агента-спеца.

Примеры:

• не хватает знаний (по какой-нибудь узкой теме, т.е. требуется помощь агента-консультанта)
• не хватает прав (требуется помощь агента-авторизатора)
• и т.д.

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

• текущий исполнитель каким-нибудь образом передает заявку нужному агенту:
• меняя ответственного
• перенося в очередь согласования, что лучше предыдущего случая, если согласующих может быть несколько.
• согласовывающий агент после этого может:
• написать внутреннюю заметку (если информация не предназначена непосредственно для заявителя)
• вступить в переписку с заявителем (если это требуется/разрешено)
• как завершающее действие — вернуть предыдущему агенту (или передать заявку дальше по аналогичной схеме)

Консультация с внешним специалистом

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

• текущий агент пересылает информацию по заявке внешнему специалисту (см. «Работа по заявке с email OTRS»)
• агент должен сам контролировать процесс решения задачи внешним специалистом (т.е. убедиться, что письмо дошло и т.д.)
• внешний специалист отвечает на письмо, ответ автоматически попадает в заявку.
• агент принимает решение о дальнейшей обработке заявки.

Обработка "плохих" заявок

Не все сообщения/заявки, которые попадут в систему, являются хорошими. Могут быть:

• заявки рекламного содержания (спам)
• заявки оскорбительного содержания
• и т.д.

Возникают вопросы:

• как уменьшить/предотвратить (это уже вопрос к администратору OTRS и почтовой системы, поэтому на этот вопрос мы здесь отвечать не будем)
• что делать с уже созданными заявками (будем считать, что у нас их несколько, хотя алгоритм подходит и для работы с одной заявкой)

Итак, у нас есть несколько плохих заявок:

• Агент каким-то способом получает список заявок, в котором есть эти "плохие заявки" (см. «Массовая обработка заявок OTRS»)
• с помощью массовой обработки заявок говорит системе, что они будут:
• закрыты неуспешно;
• перемещены в мусорную (Спам) очередь;

Хотя после этого он станем владельцем заявок (т.к. владельцем заявки автоматически становится тот, кто её стал обрабатывать), но они ему (и другим агентам) не будут мешать, т.к.:

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