Описание проекта
Тикеты должны создаваться из двух каналов. Первый — электронная почта: входящее письмо на адрес поддержки должно автоматически разбираться в новый тикет с сохранением отправителя, темы, текста и вложений, а ответы должны подшиваться к тому же тикету, а не порождать дубли. Второй — веб-портал, где сотрудник входит под своей учётной записью, заполняет короткую форму, выбирает категорию и видит движение своей заявки. К каждому тикету привязываются приоритет и таймер SLA, чтобы упавший сервер расчёта зарплаты обрабатывался иначе, чем просьба заменить мышку. При риске срыва срока система должна подсвечивать тикет и при необходимости эскалировать его. Агенты работают из очередей: тикеты назначаются вручную или маршрутизируются правилами по категории, и агент всегда должен видеть свою нагрузку. Нужны понятные статусы (новый, в работе, ожидает заявителя, решён, закрыт) с полной историей того, кто и когда что менял, а также раздел отчётности с объёмом обращений, средним временем решения и соблюдением SLA, чтобы руководство видело эффективность команды.
Чтобы не было недопонимания по объёму: это внутренний инструмент тикетинга и управления IT-услугами, а не виджет живого чата для сайта. Нам не нужен всплывающий чат-пузырь или переписка с посетителями; фокус — жизненный цикл тикета, очереди, SLA и отчётность для внутренних сотрудников.
— Создание тикетов из входящей почты (с тредами и вложениями) и через форму веб-портала
— Приоритеты и настраиваемые таймеры SLA с подсветкой риска и эскалацией
— Правила назначения и маршрутизации, очереди агентов, личные представления нагрузки
— Статусы с полной историей аудита каждого изменения
— Панель отчётности: объём тикетов, среднее время решения, соблюдение SLA
— Ролевой доступ для заявителей, агентов и администраторов