Трекер эскалаций

Что это за сервис

Внутренний инструмент для старших специалистов и руководителей поддержки, который ведёт обращения, переданные на второй уровень, в разработку или руководству. Он отвечает на три вопроса: кто сейчас отвечает за проблему, сколько осталось до срока и что уже сделано.

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

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

Что он делает

Собирает эскалации в одну очередь. Эскалации из разных каналов и help desk получают единую модель серьёзности и статуса.
Закрепляет ответственного. Владелец назначается при первой передаче и остаётся им до решения; сменить его можно только явным действием руководителя.
Подключает разработку, не снимая ответственности. Инженер добавляется как второй участник, а отвечает перед клиентом по-прежнему поддержка.
Предупреждает до нарушения срока. Сроки ответа и решения зависят от серьёзности; при расходе заданной доли времени эскалация поднимается наверх с отметкой.
Ведёт хронологию. Каждая передача, смена статуса и заметка попадают в ленту, по которой пересменка и разбор после решения проходят без реконструкции.

Нюансы и особенности

Серьёзность нужно определить заранее. Критерии уровней с примерами согласуют до запуска, иначе всё становится «срочным». Ручные повышения журналируют и разбирают.
Передача без заметки запрещена. Эскалация не меняет владельца, пока не записано, что уже проверено и чего ждут от следующего участника. Это главный способ остановить перекидывание проблемы.
Сроки хранят в записи. Срок ответа и решения вычисляют при создании эскалации по её уровню и хранят в записи. Изменение уровня пересчитывает срок и попадает в журнал, чтобы задним числом ничего не «исправлялось».
Порог предупреждения — настройка. Отметка при 80 % израсходованного времени — пример; долю и получателей уведомлений задают в конфиге.
Несколько help desk в одной очереди. Эскалации приходят через API, вебхуки или из реплики базы. Каждая запись хранит источник и внешний id, чтобы статус можно было отправить обратно. Если эскалации редкие и help desk умеет назначать и отслеживать их сам, отдельный трекер не окупится.
Контекст клиента рядом. Тариф и состояние клиента показывают в очереди: старший видит риск оттока до ответа. Расчёт состояния живёт в дашборде состояния клиентов.
Роли ограничивают на сервере. Агент видит свои эскалации, старший — свою группу, руководитель — всё, включая выгрузку. Инженер видит только те, куда его добавили.

Как сгенерировать через ИИ-агентов

Промпты рассчитаны на AI-агента (Claude Code, Cursor и аналоги) в Laravel-проекте с установленным Filament 4.x. Отправляйте их по одному и проверяйте результат каждого шага.

1. Данные

Создай модели и миграции для трекера эскалаций: Escalation (источник, внешний
id обращения, клиент, уровень серьёзности, статус, ответственный от поддержки,
участник от разработки, срок ответа, срок решения), SeverityLevel (код,
критерии с примерами, окно ответа и решения в часах), EscalationEvent
(эскалация, тип события, автор, заметка, время). Добавь фабрики с демо-данными.

2. Карточка эскалации и хронология

Сгенерируй Filament-ресурс для Escalation. В карточке покажи клиента, уровень,
оба срока с оставшимся временем, ответственного и участника от разработки,
а ниже — ленту событий через relation manager. Сроки вычисляй при создании
по SeverityLevel и сохраняй в записи.

3. Очередь и передача

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

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

4. Интеграции и предупреждения

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

5. Роли и отчёты

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