Как подготовить ИИ-ассистента к работе с заявками

В форму на сайте сервисной компании приходит сообщение: «Нужен выезд завтра, адрес пришлю в WhatsApp, бюджет до 15 тысяч». ИИ-ассистент должен определить услугу, срочность, канал связи и создать задачу менеджеру. Если он перепутает сумму, потеряет срок или отправит в CRM выдуманный адрес, клиент будет ждать ответа, а отдел продаж начнёт исправлять последствия автоматизации.

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

Сначала определить результат для каждой заявки

ИИ помогает, когда его зона ответственности сформулирована конкретно. Формулировка «разбирай обращения клиентов» оставляет слишком много свободы. Гораздо полезнее задать понятный результат: заполнить карточку лида, выделить тип услуги, определить срочность, подготовить черновик ответа или назначить задачу менеджеру.

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

услуга: только варианты из каталога компании;
город или район: берётся из сообщения клиента, при отсутствии остаётся пустым;
бюджет: число в рублях или статус «не указан»;
срочность: сегодня, в течение недели, планово;
канал для ответа: телефон, Telegram, WhatsApp, email;
следующий шаг: звонок, сообщение, расчёт или уточняющий вопрос.

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

Разделить форму данных и бизнес-правила

Ассистент может вернуть аккуратный JSON, однако это ещё не доказывает корректность данных. Поле budget может содержать 500000 вместо 50000, а выбранная услуга — отсутствовать в вашем прайс-листе. Внешне ответ выглядит исправным, но он создаёт ошибку в воронке.

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

Представим клинику, которая принимает заявки на консультацию. Ассистент может извлечь имя, желаемого врача, дату и способ связи. Перед записью система должна проверить расписание врача, длительность приёма и филиал. При сомнении она ставит пометку «нужно уточнение», а не создаёт запись с вымышленным временем.

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

Заранее описать ситуацию «данных нет»

В реальных обращениях клиент часто пишет коротко: «Сколько стоит?», «Нужно срочно», «Перезвоните». Он может прислать голосовое сообщение, скриншот или фразу без названия услуги. Для ассистента это обычный рабочий случай, который нужно спроектировать заранее.

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

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

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

Ограничить действия, которые ассистент делает сам

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

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

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

Тестировать на настоящих примерах до запуска

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

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

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

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

Закрепить версию и следить за изменениями

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

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

Начать с одного сценария и расширять постепенно

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

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