Как автоматизировать обработку входящих лидов и почты с помощью ИИ

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

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

Один понятный процесс

Автоматизация лидов часто начинается с желания «чтобы ИИ сам все обрабатывал». На практике надежнее начать с одного конкретного процесса и описать его по шагам.

Базовый процесс для этой статьи:

1. Входящее письмо поступает на общий адрес отдела продаж или через форму на сайте.
2. Извлечение данных: из письма получаем компанию, потребность, контакт и желаемые сроки.
3. Проверка и поиск: есть ли уже такой контакт или компания в CRM.
4. Маршрутизация: кто из менеджеров отвечает за этот лид.
5. Запись в CRM: создание или обновление лида с полями и ссылкой на исходное письмо.
6. Задача менеджеру: напоминание связаться с клиентом и нужный контекст.
7. Ответ клиенту: если он предусмотрен, то как отдельный этап с черновиком и согласованием.

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

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

Что извлекает модель

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

• Компания: название, если оно указано. Сайт или почтовый домен — вспомогательный сигнал.
• Контакт: имя, должность, телефон, электронная почта.
• Потребность: краткое описание того, чего хочет человек.
• Масштаб: количество филиалов, пользователей, объем — если он указан.
• Сроки: желаемое время начала или разговора.
• Упомянутые системы: действующая CRM, учетная система, каналы.

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

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

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

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

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

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

• Ответственный менеджер. Назначается по правилам: регион, направление, текущий владелец компании в CRM, очередность. Модель может помочь определить направление потребности, но назначение выполняет правило.
• Допустимые статусы. Новый лид получает только начальный статус процесса. Модель не переводит его в «квалифицированный» или «сделка» на основании тона письма.
• Существующий контакт. Дубликат по почте, телефону или домену ищет код в CRM. Если контакт найден, лид связывается с ним, а не создается заново.
• Права доступа. Интеграция работает от сервисной учетной записи с минимальными правами: создавать лиды и задачи, но не удалять записи, не менять сделки и не отправлять счета.
• Спам и нерелевантные письма. Модель может классифицировать письмо как нерелевантное, но действие с ним (архив или отдельная очередь) задается правилом, а сомнительные случаи направляются на ручную проверку.

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

Повторы и ошибки

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

Повторное получение одного и того же письма. Почта, вебхук или платформа автоматизации могут доставить одно событие дважды. Триггеры опроса Zapier исключают повторно полученные записи по уникальному первичному ключу (по умолчанию id); это защищает только триггер от повторной обработки той же записи, а не последующую запись в CRM. Если сценарий запустили вручную повторно или событие пришло другим путем, защита нужна и на уровне записи в CRM.

Что для этого требуется:

• Стабильный идентификатор события: например, идентификатор почтового сообщения (message_id) или ID заявки из формы.
• Ключ операции: «идентификатор события + тип действия». Перед созданием лида проверяется, была ли операция с таким ключом уже выполнена.
• Журнал обработки: повторное событие обновляет запись в журнале («получено повторно»), а не создает второго лида.

Тайм-аут CRM. Запрос на создание лида не получил ответа. Это не означает, что лид не создан: CRM могла сохранить его, а ответ потерялся. Перед повтором нужно проверить, существует ли запись, по ключу операции или внешнему идентификатору.

Частично выполненный сценарий. Лид создан, а задача менеджеру — нет, потому что следующий модуль завершился с ошибкой. В Make есть обработчики ошибок и сохранение незавершенных запусков, которые позволяют продолжить сценарий с места сбоя. Но откат изменений поддерживают только модули с транзакциями; обычные вызовы API, например создание лида по HTTP, автоматически не откатываются. Поэтому сценарий нужно проектировать так, чтобы продолжение после сбоя не повторяло уже выполненные шаги.

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

Контроль внешних сообщений

Внутренние действия (карточку лида, задачу менеджеру) можно исправить, если что-то пошло не так. Письмо клиенту исправить нельзя: оно уже отправлено.

Поэтому внешнюю коммуникацию делят на отдельные этапы:

1. Черновик. Модель готовит ответ на основе извлеченных данных и утвержденных шаблонов.
2. Согласование. Менеджер проверяет и при необходимости редактирует текст. Для каждого типа письма определено, кто его согласует.
3. Отправка. Отдельное действие с отдельным правом, которое фиксируется в CRM.

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

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

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

Приемка и измерение

До запуска и после него процесс оценивают на конкретных примерах и по метрикам.

Ниже — учебный пример. Письмо выдумано для объяснения.

Входящее письмо: «Нужен бот для трех филиалов, CRM уже есть, обсудим на следующей неделе».

Учебная карточка обработки

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

• Пересланная цепочка. Коллега переслал письмо клиента со своим комментарием. Контактом должен быть клиент, а не коллега; комментарий не должен попасть в описание потребности.
• Два запроса в одном письме. Клиент спрашивает о боте и отдельно об интеграции с учетной системой. Правило процесса определяет, будет ли это один лид с двумя потребностями или два лида.
• Ответ на старое письмо. Клиент ответил на рассылку полугодовой давности. Лид должен связаться с существующим контактом и историей, а не создаваться с нуля.
• Письмо без контактных данных в тексте. Телефона нет, указана только почта отправителя. Поле телефона остается пустым, его нельзя придумывать по подписи другого человека.
• Нерелевантное письмо. Предложение поставщика или спам. Оно не становится лидом, но попадает в отдельную очередь, чтобы ошибочную классификацию можно было заметить.

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

Метрики, которые стоит отслеживать после запуска:

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

Вывод

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

Что можно сделать в своем процессе:

1. Выберите один узкий процесс и опишите шаги от письма до задачи менеджеру.
2. Составьте перечень извлекаемых полей с правилом «неизвестное остается пустым» и фрагментами-доказательствами для ключевых полей.
3. Задайте правила назначения ответственного, статусов, поиска дубликатов и прав интеграции.
4. Добавьте ключ операции на основе идентификатора события и проверку существующей записи после каждого тайм-аута.
5. Разделите внешние письма на черновик, согласование и отправку; перед отправкой проверяйте, не было ли письмо уже отправлено.
6. Соберите примеры для приемки, включая повтор события и недоступность CRM, и начните отслеживать долю корректных карточек, время до назначения, потерянные обращения и ручные исправления.

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

Часто задаваемые вопросы