Что раздражает клиентов в автоматизации — и как этого избежать

11 мин чтения

Почему автоматизация раздражает даже тех, кто её заказывал?

Коротко: потому что клиент оценивает не технологию, а собственный опыт — и если на его пути появилось препятствие вместо ответа, он запоминает препятствие, а не удобство.
Есть неудобная закономерность: компании ставят автоматизацию, чтобы клиенту стало проще, а клиент уходит раздражённым. Причём раздражение почти никогда не связано с тем, «умный» бот или нет. Оно связано с тем, что человек не смог получить то, за чем пришёл.
Мы много писали о том, что автоматизация даёт бизнесу. Эта статья — взгляд с другой стороны: пять конкретных вещей, которые бесят людей в ботах и автоответах, и что с каждой делать. Сразу предупредим: часть проблем технологией не решается вообще, и об этом мы скажем прямо, а не спрячем в конце.
И еще одно, чтобы не создавать ложных ожиданий. По сводке MIT (проект NANDA, август 2025 года) около 95 % пилотных проектов генеративного ИИ не дают измеримого эффекта на финансовый результат — разбор Fortune, 18.08.2025; первоисточник читался через разбор, поэтому приводим как ориентир. Причина в большинстве случаев одна и та же: инструмент поставили, а опыт клиента не проверяли.

Раздражение 1. Невозможно дозвониться до человека

Коротко: это самое сильное раздражение из пяти, и оно возникает не от бота, а от того, что выхода к человеку нет — или он спрятан так, что его не находят.
Человек может простить бота, который чего-то не знает. Он не прощает ситуацию, когда ему некуда деться.
Как это выглядит на практике. Клиент пишет в чат, получает ответы-заглушки, просит позвать человека — и чат предлагает «сформулировать вопрос иначе». На сайте нет телефона, только форма. В форме поле «телефон» обязательно, а поле «что случилось» — нет. Единственный живой контакт — почта, на которую отвечают через день.
Что делать:
  • оставить видимый путь к человеку — кнопка «позвать оператора» в чате, телефон на видном месте, а не в подвале;
  • сделать кнопку работающей — если оператор недоступен, честно писать «сейчас не на линии, ответим в течение часа» и выполнять это;
  • не требовать контакт до ответа. Требование оставить телефон до того, как клиент получил хоть какую-то пользу, читается как «сначала заплати вниманием»;
  • дать альтернативный канал — если человек хочет написать в мессенджер, а не в чат, у него должна быть эта возможность.
Про то, почему скорость первого ответа вообще важна и как её измерить у себя, мы писали в статье про первую минуту.
Важная оговорка: это не проблема ИИ. Это проблема дизайна процесса. ИИ может сделать выход к человеку более заметным, но если оператора нет или он не отвечает — никакая технология этого не исправит.

Раздражение 2. Бот делает вид, что понял

Коротко: хуже всего не «я не знаю», а уверенный ответ не на тот вопрос — потому что клиент тратит время, пока не поймёт, что его не поняли.
Есть три уровня поведения, и они очень различаются по последствиям.
Первый: бот честно говорит, что не понял, и просит уточнить. Это нормально. Раздражает меньше всего, потому что клиент понимает, что происходит.
Второй: бот задаёт уточняющий вопрос по делу. Это хорошо. Так и должно быть.
Третий: бот отвечает уверенно, но не на тот вопрос. Вот это и есть источник раздражения. Человек спросил про совместимость, а ему рассказали про гарантию. Он перечитывает свой вопрос, решает, что плохо сформулировал, переформулирует — и получает ещё одну уверенную невпопад реплику.
Что делать:
  • разрешить боту не знать. Поведение «я не нашёл ответа, передаю человеку» должно быть штатным, а не аварийным;
  • настроить стоп-темы. Если вопрос про цену, сроки или техническую совместимость требует данных, которых нет, консультант должен передавать, а не догадываться;
  • проверять не «работает ли», а «правильно ли уходит к человеку». При тестировании до запуска это самый важный критерий, и о нём часто забывают;
  • читать диалоги. Уверенная невпопад реплика находится в логах за две минуты, но только если логи кто-то читает.
Подробный разбор причин, по которым бот не находит ответ, — в отдельной статье. Там же про то, что часть случаев не лечится настройкой: если ответа в материалах нет, его нет.

Раздражение 3. Бот повторяет один и тот же вопрос

Коротко: это ломает ощущение разговора — человек уже сказал, а его не услышали; повтор вопроса читается как «тебя не слушают».
Ситуация знакомая: клиент написал «нужна доставка в Казань, 3 коробки». Бот спрашивает город. Клиент отвечает: Казань. Бот спрашивает, сколько коробок. Клиент отвечает. Бот спрашивает город доставки.
Причина почти всегда одна: консультант не удерживает то, что уже прозвучало в диалоге. Каждый вопрос обрабатывается как отдельный, а не как часть разговора.
Что делать:
  • проверять сценарии на повторные вопросы — это делается на тестовом прогоне, и такие места видны сразу;
  • не собирать анкету с нуля, если информация уже есть: город, объём и срок обычно звучат в первом же сообщении;
  • не спрашивать то, что можно понять из контекста — например, не уточнять «вы юридическое лицо?», если клиент уже написал про оплату по счёту;
  • короткая память лучше длинной. Консультанту не нужно помнить диалог месячной давности, ему нужно не терять услышанное в пределах текущего разговора.

Раздражение 4. Контекст теряется при переводе на оператора

Коротко: человек повторно рассказывает то, что уже рассказал, — и это самое обидное, потому что автоматизация была нужна как раз для того, чтобы этого не происходило.
Посмотрите, как это обычно устроено. Клиент двадцать минут объяснял боту задачу, уточнял параметры, отвечал на вопросы. Потом бот передаёт диалог менеджеру. Менеджер пишет: «Здравствуйте! Чем могу помочь?»
Всё, что было сказано, осталось в чате, но не дошло до человека — или дошло в виде строчки «клиент, телефон, тема: консультация».
Что делать:
  • передавать историю диалога, а не только контакт. Менеджер должен видеть, что спрашивали, что ответили, что уточнили;
  • передавать незакрытое. Главное в передаче — не «что клиент хотел», а «что осталось нерешённым к этому моменту»;
  • не начинать с «чем могу помочь», если из истории ясно, зачем пришёл человек;
  • проверять передачу руками. Возьмите пять реальных передач и посмотрите, что видит менеджер. Если он не может продолжить разговор с середины — передача не работает.

Раздражение 5. «Уточню и вернусь» — и не возвращается

Коротко: обещание вернуться, которое не выполняется, хуже прямого «я не знаю» — оно превращает мелкий пробел в обман.
Это самый недооценённый пункт, потому что он не выглядит катастрофой. Подумаешь, не перезвонили.
Но с точки зрения клиента происходит вот что: он получил обещание, поверил ему и перестал искать альтернативу. А потом выяснил, что ждал зря. Такой опыт запоминается крепче, чем молчание.
Что делать:
  • не обещать того, что не обеспечено процессом. «Уточню и вернусь» допустимо только там, где есть задача в CRM, ответственный и срок;
  • считать такие обещания отдельно. Не «передано менеджеру», а «обещано вернуться» — и проверять, сколько из них закрыто;
  • ставить срок в самом обещании. «Уточню у технолога, вернусь до 18:00» — это обещание, которое можно проверить. «В ближайшее время» — нельзя;
  • если вернуться не получилось — написать об этом. Сообщение «к сожалению, не успеваем, ответим завтра до обеда» переносится гораздо легче, чем тишина.

Что общего у всех пяти и что не решается технологией

Коротко: общее у них одно — клиент не получил того, за чем пришёл; и три из пяти случаев лечатся не моделью, а процессом и людьми.
Разложим честно.
Решается настройкой: «делает вид, что понял» (границы и стоп-темы), «повторяет вопрос» (память в рамках диалога), «теряется контекст» (передача истории).
Решается процессом, а не технологией: «невозможно дозвониться до человека» — это вопрос наличия оператора и регламента, а не бота; «не возвращается» — это вопрос дисциплины и учёта обещаний.
Не решается вообще, если нет ответа. Если в компании нет письменного ответа на вопрос, никакая автоматизация его не создаст — она только быстрее покажет, что ответа нет. Это неприятный, но полезный вывод: часть работы с клиентским опытом — это работа с собственной документацией.
Здесь стоит вспомнить про ожидание, что инструмент сам всё поправит. Японское исследование Persol Research Institute (2026, национальная выборка) — FNN, 03.02.2026 — показало: генеративный ИИ ускоряет отдельные задачи в среднем на 16,7 %, но рабочее время реально сократилось лишь примерно у 25,4 % пользователей, а 61,2 % высвобожденного времени вернулось в работу, и в основном в текущую рутину. То есть просто «поставить и не трогать» не работает ни для бизнеса, ни для клиента: освободившееся время надо направить на то, что действительно улучшает опыт.

Как проверить свою автоматизацию глазами клиента

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

FAQ

«Нам говорят, что клиенты не любят ботов. Это правда?»
Клиенты не любят не ботов, а тупики. Тот же человек спокойно примет автоматический ответ, если он по делу и если рядом есть кнопка «позвать человека». Раздражение вызывает не факт автоматизации, а невозможность получить ответ.
«Стоит ли вообще предупреждать, что отвечает бот?»
По нашему опыту — да, если разговор может повлиять на решение по цене или срокам. Но это второстепенно: клиента раздражает не отсутствие предупреждения, а ответ не по существу. Честное «я бот, вот что я знаю, вот как позвать человека» работает лучше, чем маскировка под оператора.
«У нас маленькая компания, оператора нет круглосуточно. Что делать?»
Честно об этом сказать. «Сейчас не рабочее время, ответим завтра с 9:00, вот форма» — нормальный ответ, который не раздражает. Раздражает другое: когда создаётся впечатление, что человек сейчас на связи, а его нет.
«Как понять, что наш бот раздражает людей?»
По трём признакам: люди пишут «позовите человека» в первых двух сообщениях; в диалогах повторяются одни и те же уточнения; после передачи оператору клиент заново объясняет задачу. Все три видны в логах без всякой аналитики.
«Может ли помочь более умная модель?»
Частично. Она лучше понимает формулировки и реже «делает вид, что понял». Но путь к человеку, дисциплина обещаний и наличие письменных ответов от модели не зависят — это ваши процессы.
«С чего начать, если сейчас всё плохо?»
С одного: сделайте так, чтобы до человека можно было добраться за один шаг, и убедитесь, что этот шаг работает в нерабочее время. Это самое дешёвое улучшение с самым заметным эффектом.
Что вы можете сделать прямо сейчас: пройти пять сценариев собственного сайта с телефона в субботу вечером и записать, где вам захотелось закрыть страницу. Этот список честнее любой аналитики. А если решите, что нужен инструмент, — состав и цены на странице тарифов.
Получить демо на своём сайте — пришлём ссылку на консультанта, обученного по материалам вашего сайта. Задайте ему свои самые неудобные вопросы и посмотрите, где он отвечает по делу, а где передаёт разговор человеку.
Павел Гмир, основатель LeanAgent. Пишу о том, как компании теряют заявки на скорости ответа и что из этого реально исправить. Обсудить можно в TenChat или в Telegram.
Павел Гмир, основатель LeanAgent
Пятнадцать лет в производстве и операционном управлении, в том числе в японской компании. Пишу о том, как бизнес теряет заявки на скорости ответа и что из этого реально исправить.