«Заказ принят» — а заказа нет: как проверить ИИ‑менеджера до запуска

Представьте: в 22:30 клиент пишет в цветочный магазин: «Нужен букет к девяти утра. Доставите?» ИИ‑менеджер тут же отвечает: «Да, заказ принят. Курьер привезет букет к девяти».

Утром выясняется, что заказа нет. Флористы ничего не собрали, курьер никуда не едет, а клиент уверен, что магазин его подвел. Для него отвечал не «какой‑то бот», а сама компания.

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

В обычной кассе сотрудник не говорит «Оплата прошла», пока терминал не покажет успешную операцию. На экране появилось подтверждение — значит, деньги получены. Такой же принцип нужен ИИ‑менеджеру.

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

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

История с цветочным магазином — собирательный пример. Все реплики и детали вымышлены, реальные переписки клиентов мы не используем.

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

Что именно считать подтверждением

Цифровым чеком может быть номер заказа, статус записи или отметка в таблице. Малому бизнесу не обязательно покупать для этого новую программу.

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

Почему бот может уверенно сказать то, чего не сделал

Чтобы проверить наличие, бот должен обратиться к учету товаров. Чтобы записать клиента — к календарю. Чтобы передать заявку — к CRM, то есть к программе, где компания ведет клиентов и обращения.

Если эта связка не настроена или программа не ответила, ИИ все равно способен написать правдоподобную фразу. Поэтому проверять нужно не красоту ответа, а то, что произошло после него.

ИИ действительно может помогать сотрудникам. В исследовании, опубликованном в The Quarterly Journal of Economics, доступ к ИИ‑помощнику повысил число успешно решенных обращений в час в среднем на 15%. Авторы изучили работу 5 172 сотрудников поддержки и более трех миллионов чатов.

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

Семь проверок ИИ‑менеджера за полчаса

Проводите их на тестовых данных. Не отключайте рабочую CRM и не создавайте ложные заказы от имени настоящих клиентов.

1. Спросите о том, чего нет в базе. Напишите: «Будут ли завтра белые пионы в магазине на Ленина?» — если точных остатков на завтра в системе нет.

Хороший результат: бот говорит, что не может подтвердить наличие, и предлагает уточнить его у сотрудника.

Тревожный сигнал: бот уверенно обещает пионы или придумывает срок поставки.

2. Поменяйте важную деталь по ходу разговора. Сначала спросите о товаре в Казани, а затем уточните: «Я ошибся, мне нужен магазин в Самаре. Там тоже есть?»

Хороший результат: бот заново проверяет Самару и отвечает по новому магазину.

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

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

3. Попросите оформить заказ без обязательных данных. Напишите: «Передайте заявку, телефон дам потом».

Хороший результат: бот сначала просит данные, без которых сотрудник не сможет продолжить работу.

Тревожный сигнал: он пишет «заявка передана», хотя связаться с клиентом невозможно.

4. Отправьте одну просьбу дважды. Повторите сообщение и номер телефона. Иногда клиент нажимает кнопку два раза, а иногда программа сама повторяет отправку после задержки.

Хороший результат: в CRM остается одна заявка. Существующая карточка обновляется или повтор помечается как повтор.

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

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

5. Проверьте, что будет при ошибке. Попросите разработчика или подрядчика показать сбой в тестовой версии: например, временно сделать так, чтобы CRM не приняла заявку.

Хороший результат: бот не пишет «готово». Он честно сообщает, что передача пока не подтверждена. Сотрудник получает уведомление и видит данные, которые нужно обработать вручную.

Тревожный сигнал: клиент видит «заявка передана», а в CRM пусто. Или бот обещает «сейчас подключу сотрудника», но сотрудник не получает ни задачи, ни уведомления.

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

6. Подключите к чату сотрудника. Попросите человека, затем продолжите тестовый разговор от имени менеджера.

Хороший результат: бот перестает задавать вопросы и отменяет запланированные напоминания. В разговоре остается один ответственный.

Тревожный сигнал: менеджер уже общается с клиентом, а бот снова просит телефон или пишет: «Ваш вопрос еще актуален?»

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

7. Найдите подтверждение каждого слова «готово». После теста откройте CRM, календарь или таблицу. Возьмите все фразы бота: «передал», «записал», «заказ оформлен», «оплата прошла».

Хороший результат: для каждой фразы можно показать запись, ее номер, время и итог.

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

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

Что сохранить в цифровом чеке

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

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

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

Что попросить показать подрядчика

Перед запуском попросите команду показать не презентацию, а два живых примера на тестовых данных: успешную заявку и ошибку.

Проверьте вместе:

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

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

Как начать без долгого проекта

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

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

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

В глобальном опросе McKinsey 21% участников из компаний, использующих генеративный ИИ, сообщили, что серьезно перестроили хотя бы один рабочий процесс. Именно перестройка процессов сильнее других изученных признаков была связана с влиянием ИИ на прибыль.

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

Чек‑лист для владельца бизнеса

Перед запуском проверьте:

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

Надежный ИИ‑менеджер различает три состояния: «я понял», «я проверяю» и «готово».

Сказать «готово» он может только тогда, когда у бизнеса есть подтверждение. Именно это мы называем цифровым чеком.