ИИ в продажах и CRM: от заявки до следующего действия

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

Сначала опишите результат глазами менеджера

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

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

Маршрут заявки: что происходит по шагам

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

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

3. Подготовить факты и вопросы. В условном примере фактами будут запрос расчёта, два филиала и просьба писать по почте. «Срочная закупка» была бы предположением. Отсутствие спецификации нужно отметить прямо, поскольку без неё сотрудник не подготовит предметный расчёт.

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

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

Какие поля согласовать до подключения CRM

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

Матрица полномочий для первого пилота

Дубли: совпадение контакта ещё не означает одну сделку

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

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

Пропуски и противоречия нужно оставлять видимыми

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

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

Ручное одобрение должно предшествовать действию

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

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

Если вызов API не удался

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

Особенно опасен обрыв ответа после отправки команды: задача могла уже создаться. Перед повтором система проверяет результат и использует защиту от повторного выполнения. Если подтвердить состояние нельзя, она показывает «результат не подтверждён», а не «готово». Если карточка создана, но задача не появилась, нужно восстановить недостающий шаг, а не повторять всю цепочку. Число повторов ограничивают; после исчерпания попыток обращение передают человеку.

Как принять качество, а не красивое резюме

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

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

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

Источники технических требований

В документации amoCRM описана повторная отправка уведомлений при неудачной попытке [1]. Поэтому повторную доставку события нужно учитывать при проектировании. Документация Битрикс24 отдельно указывает право на создание лидов [2]: существование метода API не заменяет разрешения на его использование.

Пауза перед критическим действием для подтверждения человеком описана, например, в документации LangGraph [3]. Это технические основания рекомендаций, не заявление о готовых интеграциях или используемом стеке Silvia.