Использование OTRS
На этой странице:
Введение или что это такое
- OTRS — это система обработки инцидентов/заявок от участников/пользователей/заявителей, т.е. от людей с ролью:
- Клиент(Customer) — человек, у которого Проблема (иначе зачем ему писать письмо, звонить, …).
- Проблема — что-то, что хочет Клиент (зарегистрироваться, чтобы мы что-то сделали, чтобы мы чего-то не делали — не важно).
- Заявка(Ticket) — трек, описывающий ход решения проблемы. Порождается действием Клиента (письмом, звонком, …).
- Агент(Agent) — менеджер, который участвует в решении проблемы. Агентов может быть несколько, они могут делиться по уровню ответственности, направлению решаемых задач и т. д.
- Владелец(Owner) заявки — агент, который взялся решать данную проблему.
- Ответственный (Responsible) за тикет — агент, который решает данную проблему. Разница с владельцем в том, что владелец может делегировать решение другому агенту (сделать его текущим ответственным), но в целом именно владелец отвечает за заявку.
- Агенты могут оставлять Заметки(Note) к заявке.
Почему нельзя обойтись просто почтой
Почта — это отличный инструмент, более того, OTRS использует почту как механизм общения между Заявителем и Агентом. Чтобы организовать совместную работу через почту существует два способа:- все письма на адрес support@ приходят всем агентам, которые ответственны за входящую почту, но этот случай мы далее рассматривать не будем, т.к. имеются следующие недостатки:
- ответы агента видит только агент
- непонятно, кто на какие письма должен отвечать (как поделить письма: по алфавиту (и должен ли агент обрабатывать заявку и от Андрея Яшина и Яшина Андрея?)
- агенты вынуждены читать письма (заголовки писем), которые к ним не имеют отношения.
- либо все агенты имеют доступ к одному ящику через IMAP-протокол:
- прочитанное письмо отличается от непрочитанного (т.е. можно делить так: берем непрочитанное и обрабатываем)
- ответы на письма лежат в одном месте (теоретически к переписке можно подключить другого агента)
- Заявка не может быть удалена (в то время как письмо удалить легко и менеджер искренне будет доказывать, что письма не было вообще).
- при этом запись/удаление должны работать, т.к. у письма есть статус прочитано/не прочитано, а, скажем, для Maildir-хранения это — перекладывание из директории new в директорию cur
- Вся переписка в Заявке хранится в одном месте (письма почтовые клиенты тоже научились группировать/показывать списком (письмо-ответ-ответ на ответ-...), но делают они это по теме письма, поэтому в группу может попасть и просто похожее письмо)
- Всегда видно, на какие заявки дан ответ, а на какие — нет. Письмо можно пометить, как прочитанное, но найти все письма, на которые не был дан ответ — задача не тривиальная.
Базовые операции
Подробно рассмотрены на странице, посвященной базовым операциям в OTRS В частности, о том:- как настраивать внешний вид системы
- что/как можно сделать с заявкой
Действующие лица для примеров
Чтобы было понятнее, рассмотрим какие разные типажи/роли у нас могут работать с системой. В одном человеке может сочетаться несколько типажей, в зависимости от ситуации может быть один или другой.
Администратор:- человек, который может вносить изменения в систему. Сразу можно сказать, что он должен иметь права на запись в группе admins
- агент-секретарь:
- может понять, в какой отдел должна адресоваться заявка и даже запрашивать недостающие данные при наличии инструкции
- агент-стажер:
- тот, кто еще только учится по данному направлению. Возможно он сильный специалист в другой области.
- агент-спец (специальный), для которого общение напрямую с клиентом нежелательно, т.е. это, например, из-за того, что он:
- агент-мизантроп/агент-грубиян: может быть хорошим техническим специалистом, но с людьми лучше ему не общаться
- агент-молчун: слабое владение языком клиента (возможно и родным для агента),
- агент-консультант: специалист в узкой области,
- агент-авторизатор: разрешает или нет определенные действия другому агенту.
- агент-наблюдатель: ему требуется доступ на уровне агента, но не желательно, чтобы он мог влиять на систему.
- клиент-чаво: способен задать вопрос, на который уже вывешен ответ
- клиент-взрыв: быстро обижающийся клиент (понятие относительное, т.к. при столкновении с грубияном в эту категорию можно занести почти всех)
Сценарии
Универсальный сценарий
Письмо от клиента-чаво
Это простой сценарий, т.к. оператору ничего придумывать не нужно:- Поскольку вопрос стандартный, то на него уже есть стандартный ответ.
- Если таких заявок может быть несколько/много, то администратору стоит завести шаблон ответа для часто задаваемых вопросов
- о создании шаблона можно посмотреть в технических подробностях об OTRS
Согласование/консультация
Это как раз тот случай, когда требуется помощь агента-спеца.
Примеры:- не хватает знаний (по какой-нибудь узкой теме, т.е. требуется помощь агента-консультанта)
- не хватает прав (требуется помощь агента-авторизатора)
- и т.д.
- текущий исполнитель каким-нибудь образом передает заявку нужному агенту:
- меняя ответственного Подробнее о смене ответственного
- перенося в очередь согласования, что лучше предыдущего случая, если согласующих может быть несколько. Подробнее о перемещении в другую очередь
- или другим способом (как вариант, пишет через систему письмо специалисту, которого нет в системе, подробнее о написании писем на сторонний адрес, в этом случае агент должен сам контролировать процесс решения задачи специалистом)
- согласовывающий агент после этого может:
- написать внутреннюю заметку (если информация не предназначена непосредственно для заявителя)
- вступить в переписку с заявителем (если это требуется/разрешено)
- как завершающее действие — вернуть предыдущему агенту (или передать заявку дальше по аналогичной схеме)
Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding Foswiki? Send feedback