В 2ГИС команда AI-сервисов занимается автоматизацией внутренних процессов — от контроля качества в отделе продаж до классификации обращений в поддержке и модерации контента. Команда сэкономила тысячи человеко-часов с помощью AI, но к этому результату пришли не сразу — сначала столкнулись с тем, что сотрудники не были готовы использовать AI-инструменты.

В отделе продаж 2ГИС есть контроль качества — сотрудники прослушивают звонки менеджеров и проверяют, насколько они следуют скрипту. По итогам дают обратную связь: например, если сотрудник не представился или не отработал возражения.

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

Из десятков потенциальных пользователей инструмент стали применять только трое руководителей. Почему? У этого оказалось три причины:

Следующий кейс показал, что автоматизация не равняется оптимизации — даже если все хотят автоматизировать и подразумевают под этим экономию ресурсов.

В 2ГИС есть служба поддержки бронирования отелей, где операторы помогают клиентам. Команда решила автоматически классифицировать входящие тикеты по тематикам, чтобы выявлять категории и отслеживать время обработки.

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

• Актуализация заселения
• Пересмотр дат
• Корректировка дат
• Изменение времени
• Перенос дат

У сотрудников саппорта не было устоявшихся правил разметки, все работали и классифицировали так, как им было комфортно. Модель воспроизвела эти различия в масштабе без учета особенностей.

Из двух кейсов команда извлекла выводы, которые определили дальнейшую работу.

Усилия на внедрение = усилиям на разработку. Когда оцениваешь задачу, считаешь: написать код — X часов, на тесты уйдет N часов. Оказывается, это только половина пути. Чтобы сервис работал и экономил человеко-часы, нужно потратить еще столько же времени. Об этом надо думать заранее.

Если процесс неструктурирован сам по себе, автоматизация масштабирует проблемы, а не решает их. Сначала надо разобраться, как процесс устроен и есть ли смысл его ускорять.

После первых неудач у технических команд часто возникает соблазн взять самую последнюю модель — и точно получится. По опыту 2ГИС, это ловушка: человеческий фактор и риски не менее важны, чем мощь модели. В прототипе все понятно, но для реального внедрения самая сильная модель не сильно поможет.

Команда выработала четыре принципа снижения рисков.

В 2ГИС модераторы читают отзывы к заведениям на карте и проверяют их на токсичность. Запускать AI сразу на большую аудиторию было рискованно, а просить модераторов давать обратную связь помимо основной работы — нереалистично.

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

Когда команда автоматизирует процессы, об этом узнают другие подразделения и начинают приносить свои заявки. У внутренних заказчиков при этом есть ожидания, которые надо корректировать сразу.

Отдельная проблема в конфликте метрик. Заказчики хотят улучшить все сразу, но на практике метрики тянут в разные стороны:

• Экономия времени vs качество. Автоматизация ускоряет обработку, но если ради скорости упрощается логика — качество ответов падает.
• Скорость vs удовлетворенность. Быстрый шаблонный ответ бота закрывает тикет, но клиент чувствует, что его не услышали — CSAT снижается.
• Конверсия vs стоимость. Более умная модель повышает конверсию, но и стоит дороже — юнит-экономика может не сойтись.

Поэтому надо сразу определять с заказчиком, что в приоритете: время, конверсия, удовлетворенность, стоимость? Оптимизировать все одновременно не получится.

На старте трудно понять, какого качества удастся добиться — 90% или 70%. Чем больше экспериментов и быстрее цикл, тем выше вероятность прийти к рабочему результату. Если итерации занимают месяцы — проблема может стать неактуальной раньше, чем вы ее решите.

Четыре фактора, которые влияют на скорость цикла.

Из опыта нескольких проектов команда сформировала чек-лист для каждого нового AI-проекта.

Опыт 2ГИС показывает, что главная сложность AI-проектов — не в технической части. Написать код, обучить модель, собрать pipeline — это примерно половина пути. Вторая половина — сделать так, чтобы решением реально пользовались: встроить в существующий процесс, заслужить доверие пользователей, выбрать правильную метрику и не пытаться автоматизировать хаос. Демо не приносят бизнес-эффекта — внедрения приносят.