Документ взят из кэша поисковой машины. Адрес оригинального документа : http://wiki.cmc.msu.ru/Main/StartOTRS?rev=9
Дата изменения: Unknown
Дата индексирования: Sun Apr 10 04:14:37 2016
Кодировка: koi8-r
(r9) StartOTRS < Main < Foswiki
You are here: Foswiki>Main Web>LikeTechnology>StartOTRS (revision 9)EditAttach

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

На этой странице:

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

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

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

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

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

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

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

Подробно рассмотрены на странице, посвященной базовым операциям в OTRS

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

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

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

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

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

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

Сценарии

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

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

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

Об использовании шаблона при ответе

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

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

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

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

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

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

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

Итак, у нас есть несколько плохих заявок:
  • Агент каким-то способом получает список заявок, в котором есть эти "плохие заявки" (например — в списке дайджеста)
  • с помощью массовой обработки заявок говорит системе, что они будут:
    • закрыты неуспешно;
    • перемещены в мусорную (Junk) очередь;
Хотя после этого он станем владельцем заявок (т.к. владельцем заявки автоматически становится тот, кто её стал обрабатывать), но они ему (и другим агентам) не будут мешать, т.к.:
  • они все закрыты
  • при поиске всегда можно указать, чтобы поиск не затрагивал очередь Junk
Edit | Attach | Print version | History: r12 | r10 < r9 < r8 < r7 | Backlinks | View wiki text | Edit WikiText | More topic actions...
Topic revision: r9 - 14 Jan 2014, RomanKondakov
 
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback