Автоматизация бизнеса с помощью ИИ — какие задачи можно передать нейросетям.

Human-in-the-loop

Контроль человеком не означает провал автоматизации. Часто это оптимальная конструкция.

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

Процесс не стал полностью автономным, но трудозатраты сократились в разы, а риск остался управляемым.

Удобно вводить уровни допуска. Низкий риск - система действует сама. Средний - действует при выполнении дополнительных условий. Высокий - только готовит предложение и ждет подтверждения.

Логи и наблюдаемость

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

Без логов ошибки превращаются в мистику. С логами они становятся инженерной задачей.

Журналирование важно не только для отладки. Оно позволяет замечать дрейф качества. Например, после изменения формы заявки количество сообщений, которые модель классифицирует как «другое», выросло с пяти до двадцати процентов. Это сигнал, что нужно обновить инструкции или контекст.

Обработка исключений

Хороший сценарий проектируют не только для нормального пути. Нужно заранее решить, что делать, если отсутствуют данные, внешний сервис не отвечает, модель вернула некорректный формат, уверенность низкая или запрос попал в запрещенную категорию.

Самое безопасное исключение - передать задачу человеку с понятным описанием причины. Автоматизация не обязана быть героической. Иногда лучший шаг системы - честно сказать: «Мне не хватает данных, требуется проверка».

Версии и изменение правил

Бизнес меняется. Появляются новые продукты, тарифы, сотрудники, юридические требования, правила коммуникации. Поэтому инструкции для ИИ и автоматизации должны иметь владельца и версию.

Не стоит хранить критичные правила только внутри длинного промпта, который никто не документирует. Лучше вынести справочную информацию в отдельные источники, а в инструкции оставить роль, цель, границы и порядок действий.

Тогда обновление цены не требует переписывать весь сценарий, а изменение политики возврата можно внести в одну базу знаний.

Инструкция для модели как техническое задание

Хороший промпт в автоматизации похож не на магическую формулу, а на короткое техническое задание. В нем есть роль, цель, входные данные, правила, формат результата и поведение при нехватке информации.

Например: «Определи тему обращения из списка из восьми категорий. Используй только текст клиента и историю последних трех сообщений. Если ни одна категория не подходит уверенно, верни other. Не придумывай номер заказа. Выход - JSON с полями category, urgency, order_id, reason».

Такую инструкцию можно тестировать. А просьбу «проанализируй обращение максимально качественно» тестировать почти невозможно.

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

Набор тестовых кейсов

До запуска соберите набор примеров, которые отражают реальную работу. Не только простые случаи, но и пограничные.

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

Для каждого примера заранее укажите ожидаемый результат. Затем прогоняйте набор после каждого значимого изменения инструкции или модели.

Это превращает настройку из субъективного «кажется, стало лучше» в повторяемую проверку.

Идемпотентность и защита от дублей

Технический термин «идемпотентность» означает простую вещь: повторный запуск не должен случайно создавать второй платеж, вторую задачу или второй email.

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

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

Стоимость и задержка как часть архитектуры

Не все AI-шаги одинаково дорогие и быстрые. Для простой классификации часто достаточно менее ресурсоемкой модели, а сложный анализ можно выполнять только для небольшой доли случаев.

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

Так же стоит избегать передачи огромного контекста «на всякий случай». Чем точнее вы выбираете нужные данные, тем стабильнее система.

Глава 4. Продажи: от входящего лида до следующего действия

Где в продажах больше всего рутины

Отдел продаж кажется областью, которую трудно автоматизировать, потому что в центре находится разговор между людьми. Но большая часть времени менеджера проходит не в разговоре. Он читает заявки, ищет данные, переносит информацию в CRM, готовится к звонкам, пишет однотипные сообщения, фиксирует договоренности и вспоминает, кому нужно сделать повторное касание.

Именно вокруг самой коммуникации обычно и находится основной резерв автоматизации. Цель не в том, чтобы убрать менеджера из сделки, а в том, чтобы освободить его от действий, которые не требуют человеческого контакта.

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

Квалификация входящих лидов

Простой сценарий может выглядеть так. В компанию приходит заявка из формы, мессенджера или почты. Автоматизация собирает имя, источник и текст. Затем ИИ определяет потребность, примерный тип клиента, срочность, наличие ключевых критериев и то, какой информации не хватает.

После этого CRM получает не пустую карточку с одним телефоном, а короткое резюме: чего хочет человек, какой продукт ему может подойти, что нужно уточнить первым вопросом.

Важно не превращать AI-оценку в абсолютную истину. Если компания использует скоринг, модель должна быть лишь одним из сигналов. Надежнее, когда итоговый приоритет складывается из объективных данных и AI-классификации.

Например, бюджет, регион и размер компании можно проверить точными правилами. Намерение и контекст запроса - поручить модели. Такой гибрид дает более стабильный результат.

ИИ снимает рутину до и после разговора с клиентом.

Подготовка менеджера к контакту

Перед звонком сотрудник часто тратит несколько минут, чтобы открыть CRM, посмотреть предыдущие сообщения, сайт компании, заметки коллег и историю покупок. Этот этап легко превратить в автоматический бриф.

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

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

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

Расшифровка звонков и фиксация договоренностей

После разговора начинается одна из самых нелюбимых частей работы: заполнение CRM. Если разговор записывается законно и с соблюдением необходимых требований, его можно расшифровать, а затем извлечь структурированные данные.

ИИ может выделить проблему клиента, договоренности, сроки, возражения, участников, следующий шаг и вопросы, на которые нужно ответить. Затем система подставляет эти данные в черновики полей CRM.