Ошибка первая: ждать от бота ответа на любой вопрос
Типичный путь выглядит так. Компания ставит на сайт или в Telegram бота с меню: график работы, адрес, прайс, форма заявки. Первое время это разгружает менеджеров на типовых вопросах. Потом клиенты начинают спрашивать про свой заказ, про дату отгрузки, про счёт, выставленный на прошлой неделе. Бот отвечает заготовкой или предлагает позвонить, и клиент уходит недовольным. Ошибка в ожидании: простой сценарный бот без подключений знает только то, что в него заранее вписали.
Если большая часть обращений в чат начинается со слов про конкретную сделку или документ, это сигнал пересмотреть подход. Задача уже не в том, чтобы выбрать кнопку из меню, а в том, чтобы найти данные и подготовить ответ.
Ошибка вторая: оставить бота без доступа к рабочим системам
Бот, не подключённый к 1С, CRM и почте, не знает ни остатков, ни статуса оплаты, ни истории переписки. Любой вопрос по существу он передаёт человеку, а менеджер заново выясняет у клиента то, что уже записано в системе. Перед сменой подхода полезно проверить, где у вас лежат ответы на частые вопросы:
- остатки и сроки поставки лежат в учётной системе, например в 1С
- история договорённостей с клиентом хранится в CRM или в почте
- условия договора и приложения находятся в папках с документами
- договорённости по звонкам записаны в заметках менеджеров
- график отгрузок ведёт логист в отдельной таблице
Чем больше таких источников, тем острее нужен помощник, который умеет к ним обращаться. Агент работает внутри подключённых систем и видит ровно то, что ему разрешили.
Ошибка третья: разрешить действия наружу без проверки
Противоположная крайность — дать боту или агенту право самому отправлять письма, подтверждать скидки и менять договоры. Один неудачный ответ клиенту может стоить сделки. Разумное правило такое: простые действия вроде поиска данных, подготовки сводки или черновика агент выполняет сам, а всё, что уходит за пределы компании или затрагивает деньги и документы, проходит через подтверждение сотрудника.
Ошибка четвёртая: оценивать работу по числу закрытых диалогов
Бот, который быстро закрывает диалог, выглядит успешным, пока не посмотришь, что стало с клиентом дальше. Закрытый чат не означает решённый вопрос. Полезнее смотреть, сколько обращений дошло до менеджера с уже собранным контекстом, сколько повторных вопросов пришло по той же теме и как долго клиент ждал содержательного ответа. Для этого не нужна сложная аналитика: достаточно раз в неделю просматривать выборку диалогов вместе с руководителем отдела.
Чем простой бот и агент отличаются на одном и том же обращении
Возьмём вопрос клиента: когда придёт мой заказ и можно ли поменять адрес доставки. Вот как с ним справляются два подхода.
| Критерий | Простой бот без подключений | ИИ-агент |
|---|---|---|
| Источник ответа | Заранее написанные реплики | Данные из подключённых систем и документов |
| Нестандартный вопрос | Предлагает связаться с менеджером | Ищет информацию и готовит черновик ответа |
| Действия наружу | Отправляет заготовку | Готовит письмо или сообщение и ждёт подтверждения |
| Настройка | Правка веток сценария | Роль, правила и доступы описываются обычными словами |
| Когда подходит | Вопросы однотипны и редко меняются | Ответ зависит от сделки, документа или клиента |
Что остаётся за человеком и с чего начать переход
Менеджер не исчезает из процесса: он принимает решения, договаривается о скидке, звонит в сложных случаях. Платформа Coagent ставится на сервер компании, агент есть у каждого сотрудника и работает с почтой, 1С через стандартный интерфейс OData, Битрикс24 или amoCRM. Он подсказывает, собирает сводку по клиенту и готовит черновик, а отправляет письмо человек. Подключение к системам настраивается вместе с клиентом.
Для первого шага не нужно менять всё сразу. Выберите один поток обращений, например вопросы о статусе заказа, и посмотрите, сколько времени менеджеры тратят на поиск данных. Если много, бота стоит дополнить агентом именно на этом участке.
Опишите один поток обращений, который отнимает больше всего времени, и обсудите его разбор.