Как клиенты относятся к ИИ-ботам и что делает общение удобным
Чтобы оценить общение клиента с ИИ-ботом, проверяйте, решена ли его задача и легко ли перейти к человеку, когда бот не справился. Важно также честно представить помощника: кто отвечает, что он умеет, чего не умеет и как связаться с сотрудником. Есть данные о том, что раскрытие природы бота снижало продажи, но они получены в очень конкретных условиях и не дают оснований скрывать использование ИИ. Кроме того, с 2 августа 2026 года в ЕС действуют требования прозрачности AI Act для систем, взаимодействующих с людьми.
После статьи вы сможете составить честное приветствие бота, определить правила передачи разговора сотруднику и выбрать метрики, которые покажут раздражение клиентов без догадок.
Что на самом деле раздражает клиента
Когда клиент пишет «дайте мне живого человека», проверьте, не столкнулся ли он с одной из следующих ситуаций.
Бот не понимает запрос. Клиент формулирует вопрос своими словами, а бот отвечает на другое или предлагает неподходящее меню. После двух-трёх таких ответов терпение заканчивается.
Приходится повторять. Клиент уже назвал номер заказа и описал проблему, но после передачи оператору его просят сделать то же самое. Повтор воспринимается как признак того, что компания не ценит его время.
Бот не может решить задачу, но не признаёт этого. Ответ звучит вежливо и уверенно, но ничего не меняется: возврат не оформлен, статус не выяснен, а разговор формально «закрыт».
Нет пути к человеку. Кнопки «связаться с оператором» нет, она спрятана или бот несколько раз пытается «помочь самостоятельно», прежде чем разрешить передачу.
Эти проблемы могут быть связаны со слабым сценарием, отсутствием доступа к нужным данным и плохо продуманной передачей. Практический вывод: прежде чем обсуждать, как «представить» бота, проверьте, действительно ли он помогает в тех сценариях, для которых его запустили.
Что изучали исследователи — и где пределы выводов
В одном полевом эксперименте более 6 200 клиентов финансовой компании случайным образом получали структурированный исходящий звонок по продаже от бота или человека. Когда бот не сообщал о своей природе до разговора, его результат продаж был примерно на уровне опытных сотрудников и примерно вчетверо выше, чем у неопытных. Предварительное сообщение о том, что звонит бот, сопровождалось снижением доли покупок более чем на 79,7%. Эффект был меньше при более позднем раскрытии и среди клиентов с предыдущим опытом общения с ИИ. Клиенты, знавшие, что говорят с ботом, говорили короче и оценивали его как менее компетентного и эмпатичного.
Почему этот результат нельзя переносить на современную поддержку:
- это исходящие звонки с целью продажи, а не входящие обращения клиента, который сам ищет помощи;
- это структурированный голосовой сценарий продаж, а не решение проблемы с заказом;
- данные собраны до массового распространения генеративных моделей, и отношение людей к собеседникам с ИИ могло с тех пор измениться — это отдельный вопрос, для ответа на который нужны новые данные;
- метрикой была покупка, а не решение задачи или удовлетворённость.
И главное: исследование описывает реакцию людей, а не разрешает вводить их в заблуждение. Стратегия «раскрыть позже», основанная на этом эксперименте, несовместима с требованиями там, где применяется статья 50 AI Act: по ней информация должна предоставляться не позднее первого взаимодействия.
Что именно требует статья 50. Поставщики ИИ-систем, предназначенных для прямого взаимодействия с людьми, должны проектировать их так, чтобы люди понимали, что общаются с ИИ, если это не очевидно для информированного, внимательного и разумного человека. Обязанности прозрачности применяются с 2 августа 2026 года. Распространяется ли AI Act на ваш бизнес, кто в вашей цепочке является поставщиком системы и в какой форме нужно раскрытие — вопросы для юридической проверки. Но даже там, где закон прямо не требует раскрытия, сокрытие ИИ создаёт риск потери доверия, когда клиент это обнаружит.
Как представить помощника: роль, границы, возможность связаться с человеком
Хорошее представление бота отвечает на три вопроса клиента ещё до того, как он их задаст: «с кем я говорю», «с чем мне здесь помогут» и «что делать, если не помогут».
Учебный пример: приветствие и два пути разговора
Текст и сценарий ниже — редакционный образец, а не готовая юридическая формулировка и не описание реального проекта.
Приветствие:
> «Я ИИ-помощник сервиса. Помогу найти информацию о вашем заказе, доставке и возврате. Если для решения вопроса понадобится сотрудник, я передам ему разговор вместе со всем, что вы уже рассказали».
Путь 1: простой вопрос о статусе заказа. Клиент пишет: «Где мой заказ 4512?» Бот проверяет, что клиент авторизован и заказ принадлежит ему, считывает статус из учётной системы и отвечает: «Вчера заказ передали службе доставки, ожидаемая дата — четверг. Отправить номер для отслеживания?» Разговор заканчивается, когда клиент получил ответ, а не когда бот решил, что «всё понятно».
Путь 2: спор о возврате. Клиент пишет: «Мне отказали в возврате, но товар приехал повреждённым». Бот не спорит и не обещает решение, на которое у него нет полномочий. Он уточняет несколько фактов — номер заказа, что именно повреждено, есть ли фото — и объясняет: «Решение по возврату принимает сотрудник. Я передам ему наш разговор, номер заказа и фото, повторять ничего не придётся». Оператор получает карточку с уже собранными данными и продолжает с того места, где остановился бот.
В этом примере бот не притворяется человеком, честно обозначает пределы своих полномочий и делает передачу полезной, а не формальной.
Чего не стоит писать в приветствии
Некоторые формулировки кажутся дружелюбными, но создают ложные ожидания, которые затем приводят к раздражению:
- «Помогу с любым вопросом». Бот, который не умеет оформлять возврат, после такого обещания разочаровывает сильнее, чем бот, сразу обозначивший свои границы.
- «Сейчас соединю с менеджером», если операторов в это время нет. Лучше честно сказать: «Сотрудники работают с 9:00 до 18:00. Я сохраню ваш вопрос, и вам ответят в рабочее время».
- «Я всё понимаю» и другие заявления об эмоциях и понимании, которые клиент может воспринять как имитацию человека.
- Длинный список возможностей. Достаточно трёх-четырёх самых частых задач; остальное бот может предложить, когда поймёт запрос.
Отдельный вопрос — имя. У бота может быть имя, если оно не создаёт впечатления, что это сотрудник. «Помощник Алиса» с пояснением «я ИИ-помощник» — приемлемо. Имя и аватар реального человека без пояснений — нет.
Как сохранить контроль у клиента
Клиенту комфортно, когда он понимает, что происходит, и может это изменить. Для ИИ-бота это означает несколько конкретных механизмов.
Уточнять, а не угадывать. Если запрос неоднозначный, бот переспрашивает: «Вы имеете в виду возврат денег или замену товара?» — вместо того чтобы выбирать наугад.
Подтверждение перед действием. Прежде чем отменить заказ, изменить адрес или оформить заявку, бот показывает, что именно сделает, и просит подтвердить.
Исправление данных. Если бот неправильно понял номер, дату или сумму, клиент может исправить это одним сообщением, и дальше будет использоваться исправленное значение.
Понятная эскалация. Связь с человеком доступна в любой момент и не требует «пройти» несколько шагов с ботом. Клиент знает, что произойдёт дальше: чат с оператором сейчас, ответ в рабочее время или обратный звонок. Если операторы недоступны, бот говорит об этом прямо, а не изображает ожидание.
Честность при неуверенности. Если у бота нет данных, он говорит «я не нашёл эту информацию», а не выдаёт правдоподобно звучащий ответ.
Как измерить опыт без догадок
Распространённая ловушка — считать клиента довольным, если он не попросил человека и не пожаловался. Некоторые платформы поддержки считают разговор решённым не только тогда, когда клиент это подтвердил, но и если он не запросил оператора и не ответил отрицательно в течение короткого времени. Например, одна платформа поддержки автоматически помечает разговор как «предположительно решённый» через три минуты, если клиент не попросил человека и не отреагировал негативно. Это полезно для учёта нагрузки, но не заменяет измерение удовлетворённости: клиент мог просто уйти.
Стоит отслеживать вместе несколько метрик:
| Метрика | Что показывает | На что обратить внимание |
|---|---|---|
| Подтверждённое решение | Клиент сам ответил, что вопрос решён | Отдельно от предполагаемого решения |
| Повторное обращение по той же теме | Бот формально «закрыл» разговор, но проблема осталась | Заранее задайте окно подсчёта, например 72 часа или 7 дней |
| Запрос оператора | Где бот не справился или клиент ему не доверяет | Анализируйте, на каком шаге разговора появляется запрос |
| Отказ продолжать разговор | Клиент ушёл без ответа | Сравнивайте с теми же сценариями до запуска бота |
| Ожидание оператора после передачи | Помогает ли передача на деле | Долгое ожидание после бота раздражает сильнее, чем без него |
| Оценка после решения | Субъективное впечатление | Спрашивайте после выполнения задачи, а не после первого ответа бота |
| Жалобы | Самые серьёзные сбои | Разбирайте вручную, а не только подсчитывайте |
Сравнивайте сопоставимые сценарии: статус заказа с ботом и без него, а не «бота» в целом с «операторами» в целом. Операторы часто получают более сложные обращения, поэтому прямое сравнение их оценок с оценками бота некорректно.
Как улучшать сценарий
Улучшение ИИ-бота — это работа с конкретными проблемами в конкретных разговорах, а не общее «настроить тон».
Порядок работы:
- Соберите проблемные разговоры. Те, что закончились запросом оператора, отказом, повторным обращением или жалобой. Регулярно анализируйте их выборку из разных сценариев.
- Определите тип проблемы. Бот не понял запрос; у него не было нужных данных; он ответил неверно; у него не было полномочий, но он не передал разговор; при передаче оператор не получил контекст.
- Измените что-то одно. Добавьте источник данных, измените правило эскалации или перепишите ответ для определённого типа запросов — и зафиксируйте, что именно и когда изменили.
- Проверьте эффект в том же сценарии. Сравните метрики до и после для того же типа обращений и за сопоставимый период. Если объём мал, собирайте данные дольше, чем хочется, чтобы не принять случайное колебание за улучшение.
- Проверьте, не ухудшилось ли что-то ещё. Новое правило эскалации может сократить число жалоб, но увеличить нагрузку на операторов. Это тоже нужно отслеживать.
Учебная иллюстрация одного цикла (ситуация вымышлена): при разборе выяснилось, что клиенты часто просят оператора после вопроса «когда вернут деньги». Причина — у бота нет доступа к статусу возврата, и он отвечает общей фразой о сроках. Команда подключает к боту статус возврата из учётной системы и меняет только этот ответ. Через несколько недель для этого типа обращений сравнивают долю запросов оператора, повторных обращений и подтверждённых решений с тем же периодом до изменения. Если запросов оператора стало меньше, а жалоб больше, изменение пересматривают, а не считают успехом по одному показателю.
Что сделать в своём процессе
- Перепишите приветствие бота, чтобы оно называло его роль, границы возможностей и способ связаться с человеком.
- Сделайте передачу оператору доступной в любой момент и объясните клиенту, что будет дальше.
- Передавайте собранный контекст вместе с разговором, чтобы клиенту не приходилось повторять историю.
- Разделите подтверждённое и предполагаемое решение в отчётах и добавьте повторные обращения и запросы оператора.
- Каждую неделю разбирайте выборку проблемных разговоров и классифицируйте причины.
- Меняйте по одному элементу и проверяйте эффект на тех же сценариях.
- Попросите юриста оценить, применяется ли к вам статья 50 AI Act или другие требования раскрытия и в какой форме.
Частые вопросы
Рекомендуем сообщать об этом с первого сообщения: понятная роль бота снижает недопонимание и помогает сохранить доверие. Является ли это юридической обязанностью именно вашей компании и в какой форме, зависит от применимого права: в ЕС статья 50 AI Act требует информировать людей о взаимодействии с ИИ, если это не очевидно, а требования прозрачности применяются с 2 августа 2026 года. Применимость к вашей ситуации проверьте с юристом.
Можно, если имя не создаёт ложного впечатления, что клиент общается с сотрудником. Рядом с именем должно быть понятно, что это ИИ-помощник. Для удобства важнее не имя, а ясная роль, границы возможностей и доступная передача оператору.
Используйте поведенческие и прямые сигналы: отказы от разговора, повторные обращения по той же теме, запросы оператора, жалобы, оценки после решения задачи и долю подтверждённых решений. Сравнивайте сопоставимые сценарии до и после изменений. Отсутствие жалобы не означает удовлетворённость. Если вы планируете ИИ-помощника для клиентов или хотите понять, почему действующий бот раздражает людей, команда BotLabs может разобрать с вами один сценарий: какие обращения поступают, что бот вправе делать сам, когда и с какими данными он передаёт разговор сотруднику. На короткой консультации определим, с какого сценария начать и что измерять, чтобы видеть реальный опыт клиентов.
Консультация по передаче от бота к человеку
За 15 минут со специалистом BotLabs по внедрению ИИ обсудим один тип обращений: где бот перестаёт помогать, как клиент вызывает оператора и что происходит дальше. Определим первое правило передачи и показатель, по которому проверить изменение.
Запрос клиента
Передача человеку
15 минут со специалистом: выберем правило передачи человеку и показатель для проверки одного типа обращений.


