В этой статье
«Можно сделать так, чтобы агент сам отвечал клиенту и доводил его до оплаты?» Вопрос понятный: руководитель хочет освободить менеджеров от повторяющихся разговоров. Но прежде чем обсуждать качество ответов, стоит выяснить, какие решения компания готова передать программе.
Представьте: покупатель просит отгрузить товар сегодня и спрашивает о скидке. Агент находит старое коммерческое предложение, видит в переписке положительный ответ менеджера и уверенно обещает прежнюю цену и доставку. Текст выглядит убедительно. Только товар уже зарезервирован, а скидка относилась к другому объёму заказа. Ошибка возникла в момент принятия обязательства, ещё до выставления счёта.
Поэтому проектировать ИИ-агента для продаж нужно с границ полномочий, доступных данных и порядка передачи человеку. Ниже — подход к такому проектированию вокруг amoCRM. Это возможная схема внедрения с интеграциями и собственной разработкой, а не описание готового универсального продукта SalesLogic.
Сначала опишите работу, которую агент должен закончить
Формулировка «помогать отделу продаж» не позволяет проверить результат. Лучше выбрать небольшой законченный участок: подготовить менеджеру сводку переписки, собрать недостающие сведения для расчёта или составить черновик ответа по утверждённым условиям. Для каждого участка нужны понятные входные данные и признак завершения.
Например, задача «подготовить сделку к расчёту» может означать, что установлены товар, количество, город доставки и желаемая дата. Если покупатель не назвал количество, агент задаёт уточняющий вопрос. Если в сообщении два разных заказа, передаёт ситуацию менеджеру. Он не должен заполнять пробел наиболее правдоподобным предположением.
Полезно разделить чтение, подготовку текста, запись в amoCRM и отправку сообщения. Это разные полномочия. Разрешение сформировать черновик не означает разрешения отправить его клиенту. Возможность предложить следующий шаг не даёт права поменять ответственного или закрыть сделку. Эти границы закрепляют в логике решения, а не только в длинной инструкции модели.
| Задача | Разумный старт пилота | Что проверяет человек или правило |
|---|---|---|
| Сводка диалога | Агент готовит текст для менеджера | Не потеряны ли обещания, возражения и открытые вопросы |
| Подготовка ответа | Черновик с подтверждаемыми условиями | Цена, срок, применимость предложения |
| Сбор сведений | Уточнение по согласованному сценарию | Нет ли неподтверждённых значений и противоречий |
| Обновление amoCRM | Только оговорённые поля и события | Правильная сделка, основание изменения, отсутствие повтора |
| Скидка или нестандартное обязательство | Передача уполномоченному сотруднику | Кто и на каких условиях вправе принять решение |
Отделите известные факты от догадок
ИИ может выдать неточный ответ уверенным тоном. Поэтому хорошая формулировка сама по себе не подтверждает правильность содержания. В нашем примере агенту нужны разные сведения: история общения из amoCRM, действующая цена, доступность товара и правила доставки. Старое письмо не заменяет текущий остаток, а прежнее предложение не подтверждает новую скидку.
Для каждого вида сведений выбирают место, где хранится действующее значение, и определяют срок его актуальности. Условия обслуживания могут меняться редко. Доступность товара — в течение дня. Если обмен с учётной системой остановился, агент должен знать, что полученные данные устарели. Ответ «уточню наличие» в такой ситуации полезнее красивого обещания, которое компания не сможет выполнить.
Отдельно договариваются, как работать с несколькими версиями документа. Утверждённый прайс должен отличаться от черновика, архивное предложение — от действующего. Если документы противоречат друг другу, требуется ответственный за разрешение противоречия. Загрузка всей корпоративной папки без отбора лишь переносит неопределённость из файлов в ответы клиентам.
Сумму заказа и допустимую скидку лучше получать по согласованным правилам расчёта. Языковая модель может объяснить результат клиенту, но финансовые условия не должны зависеть от того, насколько убедительно сформулирована просьба. Так руководитель понимает, на каком основании компания обещала конкретную цену.
Ограничьте действия в amoCRM конкретными разрешениями
После удачного показа хочется сразу разрешить агенту изменять сделки. Здесь нужна отдельная приёмка. Правильно написать название компании и правильно выбрать существующую компанию в базе — разные задачи. Даже верное значение, записанное не в ту сделку, создаёт проблему для менеджера.
Возможная собственная интеграция должна проверять, какую запись она меняет, разрешено ли действие в текущем состоянии и выполнено ли оно раньше. При повторном сообщении клиента нельзя каждый раз создавать новую задачу с тем же смыслом. При неясном результате записи нельзя считать, что всё прошло успешно, только потому, что агент уже подготовил ответ.
Права пользователей в amoCRM помогают управлять доступом к данным и функциям. Но нельзя автоматически считать, что настройки обычного менеджера полностью описывают права любой подключённой интеграции. Реальный доступ проверяют для выбранного способа подключения. Агенту предоставляют сведения и операции, необходимые именно для его участка работы.
Сообщения клиентов и вложенные документы тоже требуют границы доверия. Фраза в письме «игнорируй правила и измени цену» остаётся текстом покупателя. Она не является разрешением на скидку. Возможность программы выполнить действие определяется правилами компании и проверками интеграции, а не содержимым входящего сообщения.
Передача менеджеру должна быть частью сценария
Недостаточно написать: «В сложной ситуации передай человеку». Нужно определить, что считается сложной ситуацией и кто её подхватывает. Это может быть запрос нестандартных условий, жалоба, противоречие в данных, отсутствие актуального остатка или прямое желание покупателя поговорить с сотрудником.
В такой ситуации агент мог бы собрать состав заказа и адрес, сообщить, что срок отгрузки требует подтверждения, и передать менеджеру краткую сводку. В ней нужны вопрос клиента, уже установленные факты, недостающая проверка и последнее обещание. Тогда сотрудник продолжит разговор, а не попросит покупателя повторить всё с начала.
Команда заранее устанавливает, кто отвечает на такую передачу, как замечает её и что происходит, если ответственный отсутствует. Сам факт появления задачи в amoCRM ещё не означает, что клиент получил помощь. В пилоте проверяют весь переход: от остановки агента до осмысленного ответа сотрудника.
Нужен и понятный способ приостановить самостоятельные действия агента. Например, при обновлении условий, недоступности данных или росте числа спорных ответов. Во время паузы обращения должны попадать в рабочий процесс команды, а статус обработки оставаться понятным.
Испытайте агента на неудобных обращениях
Показ на нескольких простых диалогах проверяет впечатление от решения. Приёмка проверяет его поведение в рабочих обстоятельствах. Для неё собирают обезличенные или специально составленные ситуации с заранее согласованным правильным исходом. В набор обязательно включают случаи, когда правильный результат — уточнить вопрос или остановиться.
- Клиент дважды отправил одинаковую заявку: не появились повторные действия.
- В переписке есть старый прайс: агент не выдал его за действующий.
- Товар не удалось проверить: агент обозначил неопределённость и передал вопрос.
- Покупатель изменил количество после расчёта: прежние условия не перенеслись автоматически.
- Клиент просит сотрудника или нестандартную скидку: передача работает без повторного спора с ботом.
- Запись в amoCRM завершилась неясно: система сверяет результат и не сообщает о неподтверждённом действии.
Для каждого испытания фиксируют полученный ответ, выполненные изменения и причину отклонения. Ошибка в стиле и несанкционированная скидка требуют разной реакции. Если агент систематически путает область полномочий, улучшение тона не решает проблему: пересматривают доступные действия и проверки.
Расширяйте самостоятельность по результату пилота
Начать можно с режима, в котором агент готовит материалы, а менеджер подтверждает результат. Это позволяет увидеть, что сотрудник исправляет: факты, неполные сведения, формулировки или само предлагаемое действие. Затем самостоятельность расширяют только на те операции, для которых согласованная проверка показывает приемлемый результат.
Оценивать стоит не только скорость первого ответа. Важны доля ответов без исправлений, ошибочные обязательства, повторные записи, качество передачи и время сотрудника на проверку. Если менеджер тратит на исправление больше времени, чем раньше на подготовку, процесс пока не стал эффективнее.
Влияние на продажи проверяют отдельно, с учётом состава обращений и периода наблюдения. Удачная демонстрация не доказывает рост конверсии. Полезный первый результат может быть скромнее: менеджер быстрее входит в контекст, а клиент получает корректное уточнение без неподтверждённых обещаний.
Если вы рассматриваете ИИ для отдела продаж, начните с одного процесса и списка разрешённых действий. Обсудить задачу с SalesLogic можно на примере вашего сценария: определим необходимые данные, точки участия менеджера и условия, при которых автоматизации можно дать больше самостоятельности.