Как мы поставили ИИ-агента принимать заявки в техподдержку — и не потеряли контроль

Полтора года назад у нас в «АйТи-Фреш» на телефоне диспетчера в среднем скапливалось по 40 заявок в день от полусотни клиентов. Кто-то звонит, потому что 1С не открывается. Кто-то — потому что принтер не печатает. А кто-то в панике, потому что «всё пропало», хотя на деле просто отвалился RDP. Сегодня первую заявку почти всегда принимает не человек, а ИИ-агент — и я как директор наконец сплю спокойно, потому что вижу каждое его решение.

Почему первая линия — это узкое горлышко, а не просто вежливый голос

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

У одного нашего клиента — небольшая юрфирма на 18 рабочих мест — раньше было так: заявка «не работает 1С» могла означать что угодно, от «забыл пароль» до «упал SQL Server». Диспетчер не программист, он не обязан с ходу отличить обрыв связи с КриптоПро от банальной блокировки лицензии. В итоге на разбор уходило время, которое клиент фактически оплачивает простоем, а не звонком.

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

Что реально делает ИИ-агент на первой линии

Агент у нас принимает заявки из трёх каналов: почта, Telegram-бот и веб-форма на сайте клиента. Внутри — языковая модель с доступом к базе знаний по инфраструктуре каждого клиента: какая у него 1С, какой сервер, кто за что отвечает. Заявка прилетает — агент её читает, классифицирует по типу (1С, сеть, оборудование, доступы, бухгалтерский вопрос) и, если нужно, задаёт уточняющий вопрос.

Простой пример. Пишет бухгалтер: «не могу отправить отчёт». Агент не бросается сразу заводить тикет «сломался интернет». Он спрашивает: какая ошибка на экране, работает ли КриптоПро, пробовали ли перезайти. Три вопроса — и уже понятно, истёк сертификат ЭЦП или реально легла связь с оператором. Дальше заявка улетает точному специалисту с готовым описанием проблемы, а не с фразой «всё сломалось, шеф в бешенстве».

Важная деталь — агент не изобретает категории на лету. Мы дали ему жёсткий справочник: пятнадцать типов заявок, приоритеты, SLA по каждому клиенту отдельно. Для медклиники, например, всё, что касается МИС, — красный приоритет, реакция 15 минут. Для торговой точки сбой кассы в рабочие часы — тоже красный, а в нерабочие — уже жёлтый.

История с ночным падением обмена — как это выглядит вживую

Расскажу случай. Клиент — оптовая база стройматериалов, склад работает с пяти утра. В 4:47 кладовщик пытается отгрузить товар, а 1С выдаёт ошибку обмена с сервером лицензирования. Раньше это означало звонок дежурному инженеру, который спросонья пытается понять, что вообще происходит, по трём строчкам в WhatsApp.

Сейчас кладовщик пишет в Telegram-бота. Агент за 20 секунд уточняет код ошибки, смотрит в базу знаний — у этого клиента сервер 1С стоит на Windows Server 2019, лицензии через HASP-ключ, а накануне вечером было плановое обновление Windows с перезагрузкой. Вывод: сервис лицензирования не поднялся после ребута. Сам агент на боевой сервер не лезет — таких прав у него нет и не будет. Но он сразу создаёт тикет с высшим приоритетом, прикладывает диагностику и будит дежурного инженера звонком через Telegram-алерт, а не письмом, которое человек прочитает через час.

Инженер просыпается и видит готовую картину — не «что-то сломалось», а «служба лицензирования 1С не стартовала после перезагрузки сервера, нужен ручной рестарт». Заходит по RDP, перезапускает, три минуты — и склад работает. Без агента это заняло бы час толковых расспросов спросонья.

Как не потерять контроль над первой линией

Тут я всегда останавливаю коллег, которые хотят «дать агенту побольше прав, чтобы сам всё чинил». Нет. Мы сознательно ограничили ИИ-агента ролью диспетчера, а не исполнителя. Он не заходит на серверы клиентов, не перезапускает службы, не меняет права доступа. Его задача — принять, классифицировать, задать вопросы, создать тикет и, если нужно, эскалировать человеку. Точка.

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

Третье — жёсткая граница эскалации. Если агент не уверен в классификации больше чем на 70 процентов (да, у нас это буквально настроенный порог), заявка автоматически уходит человеку-диспетчеру с пометкой «требует уточнения», а не гадает наугад. Лучше пусть переспросит лишний раз, чем молча отправит критичный инцидент не туда.

Подводные камни, на которые мы наступили

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

Второй момент — сопротивление со стороны самих клиентов. Одна из бухгалтеров прямо написала: «не хочу разговаривать с роботом, дайте живого человека». Мы не стали спорить. Просто в боте есть кнопка «позвать оператора» на любом шаге — агент сразу передаёт диалог человеку, без квестов и лишних вопросов. Из полусотни клиентов этой кнопкой реально пользуются человек пять, но им важно знать, что она есть.

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

Сколько это стоит и когда окупается

Экономика простая, хоть и не все любят такие разговоры. Токены языковой модели на обработку одной заявки обходятся в копейки — рублей 3-5 в пересчёте, даже с учётом уточняющих вопросов. Сложнее и дороже была разработка — база знаний по инфраструктуре каждого клиента, интеграция с нашей CRM и Telegram, тестовый период. На круг ушло около 380 тысяч рублей и три месяца работы одного разработчика.

Окупилось за пять месяцев. Раньше было полтора диспетчера на полсотни клиентов, сейчас справляется один — и то не на полную загрузку, с запасом на рост базы. Плюс среднее время до передачи заявки нужному специалисту упало с 22 минут до 3. Для клиента с почасовой оплатой простоя это ощутимые деньги — и аргумент лучше любой рекламы.

Отдельно скажу: экономия не в увольнении диспетчера. Мы никого не сократили — просто перестали набирать второго диспетчера при росте клиентской базы, а высвободившееся время человека ушло на более сложные разговоры, где действительно нужен живой человек с эмпатией и опытом.

Как внедрить у себя, если у вас своя ИТ-служба или контора поменьше

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

Второй шаг — выбрать один канал приёма заявок, не пытаться охватить сразу всё. Мы начинали только с Telegram-бота, почту и веб-форму подключили через полгода. Третий — обязательно тестовый период в режиме тени, о котором я говорил выше. Без него вы рискуете либо совсем не доверять агенту, либо довериться слишком рано.

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

Частые вопросы

Не начнёт ли агент сам что-то чинить на боевых серверах без ведома инженера?
Нет, у нас это исключено архитектурно. Агент физически не имеет доступа к серверам, службам и учётным записям клиентов — только к базе знаний и системе тикетов. Его максимум — создать заявку и уведомить нужного специалиста. Любое действие руками выполняет только живой инженер.

Что будет, если агент ошибётся с классификацией заявки?
Такое случается, особенно первое время. Мы держим порог уверенности: если агент не уверен в решении, заявка автоматически уходит человеку на ручную классификацию. Плюс раз в неделю мы разбираем спорные случаи и дообучаем базу знаний, так что ошибки одного типа не повторяются.

Заменяет ли такой агент живого диспетчера полностью?
У нас нет — и я бы не советовал к этому стремиться. Агент отлично справляется с рутинной классификацией и первичным сбором информации, но сложные эмоциональные разговоры, нестандартные случаи и финальное решение по эскалации всё равно на человеке. Это инструмент, который освобождает время диспетчера, а не заменяет его.

Сколько времени и денег нужно на внедрение такой системы в компании на 20-30 рабочих мест?
По нашему опыту и опыту клиентов, которым мы это настраивали, реалистичный срок — полтора-два месяца, включая тестовый период в режиме тени. Бюджет для компании такого размера обычно укладывается в 150-250 тысяч рублей, если не создавать всё с нуля, а адаптировать готовую архитектуру под конкретные типы заявок.