Техподдержка тонет не в сложных заявках, а в повторах. Одна и та же проблема приходит десятками: у соседа не работает, у меня не работает, на этаже ни у кого не работает. Каждый пишет отдельно, каждое обращение становится отдельной задачей. Инженер открывает пятую копию и понимает, что чинить надо один раз, а разбирать - пять. Бот техподдержки, который мы собрали для крупной инженерной компании, снимает именно этот слой: проверяет похожие открытые задачи, прежде чем завести новую, сам ловит массовые сбои и связывается с мониторингом, чтобы предупредить людей раньше, чем они успели написать.
Проверка на дубль до новой задачи
Когда сотрудник просит бота завести заявку, бот не создаёт её сразу. Сначала он проверяет, нет ли уже похожей открытой задачи. Сравнивает не по точному совпадению текста - люди пишут одну и ту же беду разными словами. Бот сверяет и название, и содержание через ИИ-анализ смысла, поэтому понимает, что "не грузится почта" и "почтовый клиент завис на запуске" - про одно.
Если похожая открытая задача есть, бот показывает её вместо того, чтобы завести копию. Сотрудник видит, что обращение уже в работе, и не создаёт шестую версию той же проблемы. Инженер разбирает одну задачу вместо очереди дублей по ней.
Инциденты: когда проблема массовая
Массовый сбой - отдельная история. Это волна обращений по одной причине, а не два-три повтора. Бот работает с инцидентами двумя путями: вручную и сам.
Объявление от администратора
Когда о сбое уже известно, администратор публикует объявление об инциденте. С этого момента любому, кто пишет боту по той же теме, бот сразу отвечает: проблема массовая и в работе, новую заявку заводить не нужно. Человек получает честный ответ за секунды и не встаёт в очередь впустую.
Автообнаружение волны
Бот считает похожие обращения. Если за сутки их приходит больше заданного порога, он сам заводит инцидент и предупреждает менеджеров. Дальше на все обращения по этой теме бот отвечает как по известному сбою: не плодит задачи, показывает, что проблему уже видят и чинят. Порог настраиваем: где-то тревожный сигнал - пять похожих обращений, где-то - двадцать.
Связка с мониторингом: ответ раньше вопроса
Самый быстрый ответ - тот, что готов до обращения. Бот связан с системами мониторинга (Zabbix и подобные). Когда мониторинг фиксирует падение сервиса, бот получает сигнал и сам сообщает: проблема известна, решается. Сотрудник открывает чат с жалобой, а там уже ответ - чинят. Заявку заводить не нужно, инцидент уже идёт.
Такая связка разворачивает логику техподдержки. Раньше сбой сначала бил по людям, люди писали, из обращений складывалась картина. Теперь картина складывается от инфраструктуры к людям: сервис упал - бот предупредил - очередь одинаковых заявок не собралась.
Пример: сотня обращений вместо сотни задач
Вот показательный случай. Цифры тут про порядок величины, без точного замера. Упал общий сервис, которым пользуется вся компания. За час к боту написали порядка сотни сотрудников с одной и той же бедой. Без сборки это была бы сотня отдельных задач в очереди, сотня открытий, сотня разборов - и инженеры весь час занимались бы сортировкой копий, а не починкой.
Бот свёл волну в один инцидент. Каждому написавшему он сразу ответил, что проблема массовая и её чинят, - человек получил ответ вместо молчания. Инженеры видели одну задачу с реальной причиной вместо сотни копий. Один сбой - один инцидент - один разбор.
Почему это снимает нагрузку, а не добавляет её
До бота обращения в этой компании шли почтой, звонками и устно, около 10% терялось по дороге. Первый ответ мог ждать до 10 часов - инженер занят основной работой и до заявки доходил не сразу. Дубли и массовые сбои в такой схеме множат хаос: одну проблему разбирают несколько человек параллельно, а часть жалоб вообще выпадает.
Проверка на дубль и автоматические инциденты убирают эту работу до того, как она возникла. Инженер не тратит время на сортировку копий, сотрудник не ждёт в очереди по уже известному сбою, картина по массовым проблемам собирается сама. Из тысяч обращений в месяц 40% закрываются ответом из базы знаний без заявки - но это уже другой слой бота, а антидубли работают ровно на том, чтобы оставшиеся заявки не размножались.
Если ваша техподдержка разбирает одну проблему по десять раз и узнаёт о массовом сбое от сотого написавшего, этот слой автоматизации стоит посчитать на ваших данных.
