Как составить матрицу эскалации с помощью ИИ: соберите уже утверждённые правила поддержки, попросите модель разложить их по строкам «условие — роль — канал — срок — резерв» и потребуйте основание для каждой ячейки. Модель заполняет маршрут передачи обращения, отмечает незакрытые поля и готовит вопросы владельцу процесса. Ниже — порядок действий, учебная таблица и копируемый промпт.
Назначение документа и его границы
Матрица эскалации описывает, как обращение движется между людьми, когда первый исполнитель не справляется сам. В документации Atlassian по политикам эскалации сказано, что политика определяет, кого уведомляют при срабатывании алерта, кому передают инцидент, если первый ответственный недоступен или не может его решить, и как происходят эти передачи — обычно с поправкой на серьёзность, длительность и охват. Там же отмечено, что политика эскалации служит парой к расписанию дежурств: расписание говорит, кто доступен, а политика — как инцидент перемещается между ними.
Границы документа задайте до генерации. Матрица фиксирует маршрут передачи: условие срабатывания, роль получателя, канал, срок и резервный ответственный. Она опирается на уже принятые правила поддержки. Она не устанавливает SLA за владельца процесса и не решает за него, какой срок считать нормальным. В документации PagerDuty по политикам эскалации описано, что политика представляет собой упорядоченный набор правил, которые также называют уровнями: когда инцидент срабатывает, система идёт по этим правилам, пока кто-нибудь не подтвердит получение.
Практический вывод для границ: вы переносите существующие договорённости в структурированный вид и оставляете пустыми те поля, по которым договорённости ещё нет. Модель помогает разложить правила и заметить пропуски. Решение о сроках и о том, кто именно отвечает, остаётся за владельцем процесса.
Ещё одна граница — различие между подтверждением получения и решением проблемы. В документации PagerDuty по инцидентам указано, что подтверждение говорит системе, что ответственный работает над инцидентом, останавливает эскалацию и приостанавливает дальнейшие уведомления, при этом подтверждение не закрывает инцидент: инцидент закрывается при его разрешении; разрешение всех связанных алертов также разрешает инцидент. Это различие стоит закрепить в матрице отдельной колонкой или отдельным правилом, иначе резервный ответственный будет получать уведомления там, где работа уже идёт.
Явные правила и роли
Соберите правила в одном месте до обращения к модели. Возьмите инструкции поддержки, регламенты дежурств и переписку, где зафиксированы договорённости. Выпишите каждое правило отдельной строкой в форме «если — то». Пример такой выписки: общие вопросы обрабатывает оператор с 09:00 до 18:00; если вход не работает после проверки инструкции, оператор сразу создаёт задачу техспециалисту; если техспециалист не подтвердил получение в течение тридцати рабочих минут, оператор обращается к дежурному; запрос отмены платежа оператор передаёт руководителю поддержки и обещаний возврата не даёт.
Роли выпишите отдельным списком с указанием зоны ответственности. Оператор принимает обращения и выполняет первичную проверку. Техспециалист разбирает технические сбои. Дежурный подключается, когда основной исполнитель не подтвердил получение. Руководитель поддержки получает запрос отмены платежа. Его полномочия на финансовое решение в учебном входе не заданы; это отдельный вопрос владельцу процесса. Для каждой роли отметьте, какие действия она совершает и какие решения принимает.
В документации Atlassian по политикам эскалации названы три типа эскалации: иерархическая — по старшинству, функциональная — по экспертизе, автоматическая — по правилу, когда алерт не подтверждён вовремя. Этот набор удобно использовать как проверочный список: пройдитесь по своим правилам и отметьте, какой тип эскалации описывает каждое. Там же отмечено, что ответ на вопрос «кого уведомлять» может зависеть от уровня серьёзности и длительности инцидента, поэтому одинаковый маршрут для всех обращений подходит не всегда.
Отдельно выпишите то, чего в правилах нет. Работа вне указанного времени, канал передачи для части ролей, срок реакции руководителя поддержки — эти поля останутся открытыми, и их нужно вынести в вопросы владельцу. Модель на этом шаге полезна тем, что находит пропуски: вы даёте ей список правил и список ролей, а она показывает, какие комбинации не описаны.
Учебная таблица с основаниями
Попросите модель собрать таблицу, где у каждой ячейки есть основание. Основание — это ссылка на конкретное правило из вашей выписки. Ячейка без основания остаётся пустой или помечается как открытый вопрос. Ниже учебный пример такой таблицы. Все его правила вымышлены для разбора; применять их как регламент реальной команды можно только после согласования.
| Код | Условие | Роль | Канал | Срок | Резерв | Основание |
|---|---|---|---|---|---|---|
| E1 | Общий вопрос | Оператор | Канал неизвестен, уточнить у владельца | Срок реакции неизвестен; оператор работает в указанные часы | Резерв неизвестен | Правило о работе оператора с 09:00 до 18:00 |
| E2 | Вход не работает после проверки инструкции | Техспециалист | Создание задачи; система не названа | Сразу; резерв через тридцать рабочих минут без подтверждения | Дежурный | Правило о задаче техспециалисту и правиле тридцати минут |
| E3 | Запрос отмены платежа | Руководитель поддержки | Канал неизвестен, уточнить у владельца | Срок неизвестен | Резерв неизвестен | Правило о передаче запроса руководителю |
Разберите таблицу по столбцам. Столбец «условие» отвечает на вопрос, при каком событии начинается передача. Столбец «роль» называет получателя. Столбец «канал» фиксирует способ передачи: задача в трекере, сообщение в чате, звонок. Столбец «срок» задаёт, через какое время срабатывает резерв. Столбец «резерв» называет, кто подключается, если основной получатель не подтвердил получение. Столбец «основание» связывает ячейку с правилом.
В документации PagerDuty по политикам эскалации описан порядок работы: система немедленно уведомляет цель на первом правиле, задержки перед первым уведомлением нет; если до истечения таймаута никто не предпринял действие — не подтвердил, не решил, не переназначил, — инцидент переходит к следующему правилу. Этот порядок полезен как образец логики, которую вы описываете словами в столбцах «срок» и «резерв». Конкретные таймеры из чужого продукта переносить в свою ручную команду не нужно: сроки вы назначаете из своих договорённостей.
Проверьте таблицу на полноту. Для каждой строки должно быть ясно, что происходит при отсутствии реакции. Если резерв не назван, строка не закрыта. Если канал не определён, передача может не состояться. Открытые ячейки вынесите в отдельный список вопросов владельцу процесса.
Копируемый промпт для сборки матрицы
Промпт ниже переносит правила в таблицу и требует основание для каждой ячейки. Скопируйте его целиком и подставьте свои правила, роли и список открытых вопросов.
Ты помогаешь составить матрицу эскалации поддержки.
Входные данные.
Правила поддержки:
[вставьте свои правила в форме «если — то», по одному на строку]
Роли и зоны ответственности:
[вставьте список ролей с описанием действий и решений]
Известные ограничения:
[вставьте то, что уже зафиксировано: часы работы, порядок передачи, запреты]
Задача.
1. Перенеси правила в таблицу со столбцами: код, условие, роль, канал, срок, резерв, основание.
2. В столбце «основание» укажи, из какого правила взята ячейка. Если основания нет, оставь ячейку пустой и добавь строку в список открытых вопросов.
3. Различай подтверждение получения и решение проблемы. Подтверждение останавливает резервное уведомление и не закрывает обращение.
4. Различай рабочие и календарные минуты. Если в правилах сказано «рабочие», не заменяй их календарными.
5. Не выдумывай режим работы вне указанных часов. Не назначай сроки и не принимай решения о платежах за владельца процесса.
6. В конце дай список вопросов владельцу: по каждому открытому полю — что именно нужно уточнить.
Формат ответа: таблица, затем список открытых вопросов, затем короткое перечисление правил, которые остались неоднозначными.
Что менять под себя: в блоке входных данных подставьте свои правила, роли и ограничения. Если у вас несколько типов обращений, добавьте их в правила отдельными строками. Если по какому-то вопросу решение уже принято, впишите его в ограничения, чтобы модель не предлагала варианты.
Вариации той же задачи. Первая: попросите модель проверить готовую матрицу на пропуски и назвать строки без резерва. Вторая: попросите переписать матрицу в виде инструкции для нового сотрудника, по шагам. Третья: попросите собрать отдельную таблицу для обращений вне рабочих часов, оставив сроки пустыми до решения владельца. Четвёртая: попросите сформулировать, какие метрики понадобятся, чтобы понять, работает ли маршрут. Пятая: попросите найти в правилах места, где подтверждение получения можно спутать с решением проблемы.
Проверка отрицательного сценария
Возьмите учебный сценарий и прогоните его по таблице. Во вторник в 10:00 вход не заработал после проверки инструкции. По строке E2 оператор сразу создаёт задачу техспециалисту. Резервное уведомление дежурному срабатывает в 10:30, если подтверждения не было. Если техспециалист подтвердил получение в 10:10, условие для резервного уведомления уже не выполнено. При этом задача может оставаться нерешённой: подтверждение говорит о том, что работа идёт, и не говорит о том, что проблема закрыта.
Второй сценарий проверяет границу документа. В 21:00 режим работы неизвестен. Дневное правило не даёт основания придумать ночной срок, поэтому строка для этого случая остаётся открытой, а вопрос уходит владельцу. Модель, которой не задали это ограничение, склонна подставить правдоподобный срок. Поэтому в промпте есть отдельный пункт про режим вне указанных часов.
Третий сценарий проверяет решения, которые модель принимать не должна. Запрос отмены платежа оператор передаёт руководителю поддержки и обещаний возврата не даёт. Если модель предлагает написать клиенту срок возврата, это выход за границы: решение о платежах остаётся за владельцем процесса.
В документации PagerDuty по инцидентам отмечено, что подтверждённый инцидент, который снова срабатывает, возобновляет следование политике эскалации. Это поведение описывает PagerDuty. Для ручной матрицы отдельно согласуйте с владельцем, когда повторное открытие запускает маршрут заново. В документации PagerDuty по политикам эскалации также указано, что инциденты не эскалируются, если их подтвердили или решили до истечения таймаута. Оба правила полезны как проверочные вопросы к вашей таблице: что происходит при возврате обращения и что происходит при подтверждении до срока.
Открытые поля и вопросы владельцу
Открытые поля — это нормальное состояние первой версии матрицы. Их не нужно закрывать догадками. Соберите их в список и передайте владельцу процесса. Для каждого поля сформулируйте вопрос так, чтобы на него можно было ответить одним решением.
Типовые открытые поля. Канал передачи для роли, если в правилах он не назван. Срок реакции для роли, если правило задаёт только момент создания задачи. Резервный ответственный для строк, где основной получатель может не ответить. Режим работы вне указанных часов. Порядок действий при возврате обращения после подтверждения.
В документации Atlassian по метрикам инцидентов отмечено, что метрики вроде MTTR, MTBF и MTTF дают отправную точку для разговора о том, как инциденты решаются и почему они эскалируются или деэскалируются. Там же сказано, что MTTR может означать четыре разных измерения — repair, recovery, respond, resolve, — и команде стоит договориться, какое именно она отслеживает. Для матрицы это означает, что в вопросах владельцу полезно уточнить, что именно вы будете измерять: время до подтверждения получения, время до решения или время до передачи следующей роли.
В документации Freshdesk по управлению эскалациями описан порядок уровней: если клиент не получил ответ после первой эскалации, обращение можно передать более компетентному сотруднику или руководителю через определённый период, а третья ступень настраивается, если обращение всё ещё не решено. Там же указано, что вся матрица эскалации должна быть чётко определена, и на каждом шаге право собственности на проблему закрепляется за конкретным человеком. Этот принцип переносится в столбец «роль»: у каждой строки должен быть один ответственный.
Материал Freshworks об эскалации тикетов связывает устройство матрицы с размером организации и типом запроса и описывает вариант с уровнями вплоть до четырёх в зависимости от приоритета. Число уровней своей матрицы определите по согласованным маршрутам и ролям. Строка таблицы и уровень эскалации — разные вещи: несколько условий могут вести к одному уровню.
Согласование с владельцем
Согласование закрывает работу над матрицей. Подготовьте к встрече три вещи: таблицу с основаниями, список открытых полей и перечень решений, которые вы не принимали. Владелец процесса подтверждает сроки, каналы и резервных ответственных, а также отвечает на вопросы из списка.
Порядок согласования. Сначала пройдитесь по строкам с заполненными ячейками и подтвердите, что основания верны. Затем разберите открытые поля по одному. После этого проверьте, что у каждой роли есть понятная зона ответственности и что резервный ответственный знает о своей роли. В конце зафиксируйте версию документа и дату, с которой она действует.
В документации Freshdesk по управлению эскалациями отмечено, что разбор причин каждой эскалации помогает принять меры, чтобы она не повторилась: например, если оператор не успел ответить из-за перегрузки, вопрос решается распределением нагрузки. Там же описан случай, когда оператор зависел от другой команды и не получил от неё ответа вовремя: тогда ответственность за информирование клиента переходит к этой команде. Оба примера полезно держать в голове при согласовании: матрица описывает маршрут, а причины сбоев разбираются отдельно.
После согласования матрица становится рабочим документом. Её стоит пересматривать, когда меняются правила поддержки, состав ролей или режим работы. Модель удобно использовать повторно: вы даёте ей обновлённые правила и просите показать, какие строки изменились и какие основания устарели.
Частые вопросы
Что такое матрица эскалации простыми словами?
Это таблица, которая описывает маршрут обращения: при каком условии оно передаётся, кому, по какому каналу, через какой срок подключается резерв. В документации Atlassian по политикам эскалации такой маршрут назван документированным путём с тремя типами эскалации: по старшинству, по экспертизе и по правилу. Матрица опирается на уже принятые правила поддержки и не устанавливает сроки за владельца процесса.
Можно ли поручить составление матрицы нейросети?
Да, если вы даёте модели готовые правила и роли. Модель раскладывает их по строкам, находит пропуски и готовит вопросы владельцу. Решения о сроках, каналах и платежах остаются за человеком. Промпт из этой статьи требует основание для каждой ячейки, поэтому вы видите, откуда взято каждое значение.
Чем подтверждение получения отличается от решения проблемы?
Подтверждение говорит, что ответственный взял обращение в работу, и приостанавливает эскалацию и уведомления. В документации PagerDuty по инцидентам закрытие связано с разрешением инцидента; если разрешены все связанные алерты, инцидент также разрешается. При истечении acknowledgement timeout подтверждённый нерешённый инцидент может снова перейти в triggered и продолжить эскалацию. Для ручной матрицы правила подтверждения и возобновления маршрута согласуют отдельно.
Сколько уровней эскалации заводить?
Ориентируйтесь на свои правила и на роли, которые действительно могут подключиться. Материал Freshworks об эскалации тикетов описывает вариант с уровнями вплоть до четырёх в зависимости от приоритета. Это пример из конкретного материала; число уровней своей матрицы согласуйте с владельцем процесса. Объединять условия можно, если при этом сохраняются разные маршруты и ответственные.
Что делать с полями, по которым нет решения?
Оставьте их пустыми и вынесите в список вопросов владельцу процесса. Модель не должна подставлять правдоподобные сроки или каналы. В учебном примере канал для строк E1 и E3 помечен как неизвестный, а срок и резерв для E3 — как неустановленные. Владелец закрывает эти поля своим решением, после чего матрица становится рабочей.