Почему 80% AI-проектов в бизнесе проваливаются

Привет, герой бизнеса!

AI-чатботы стали стандартом для бизнеса: их внедряют банки, e-commerce, SaaS и госструктуры. Но парадокс в том, что большинство из них не улучшает клиентский опыт, а ухудшает его.

По разным оценкам, до 60–80% внедрений чат-ботов не достигают заявленных целей или закрываются в течение первых месяцев после запуска. При этом проблема не в самой технологии, а в том, где и как её применяют.

По данным fortune.com

Почему чат-боты в поддержке часто не решают задачу

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

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

В такой конфигурации бот не может работать как помощник в принятии решений. У него нет доступа к полному контексту запроса:

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

В результате он вынужден опираться только на заранее прописанные сценарии ответов. Диалог часто зацикливается: система формально отвечает на запрос, но не продвигает пользователя к решению.

Почему AI-чат превращается в дорогой FAQ

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

Это логично с точки зрения скорости внедрения, но критично с точки зрения результата.

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

В результате база знаний AI оказывается смещённой: она отражает не пользовательские запросы, а корпоративный язык.

Где возникает разрыв

Пользователь приходит в систему с ситуацией, его запрос почти всегда связан с контекстом:

1. конкретный заказ и его статус,
2. ограничения или исключения в продукте,
3. нестандартная комбинация условий,
4. ошибка или непонимание процесса.

Но в большинстве случаев AI-чат не имеет доступа к этому контексту. Он работает с заранее подготовленными текстами, которые описывают продукт в общем виде, поэтому система отвечает не на ситуацию, а на формулировку запроса.

Если AI обучается на FAQ, он наследует эту же логику:

1. искать похожий вопрос,
2. подставлять ближайший готовый ответ,
3. игнорировать недостающий контекст.

AI не спасает плохой сайт и плохую архитектуру продукта

В основе любого AI-решения всегда лежат четыре слоя: структура сайта, качество данных, логика продукта и доступность информации. Если хотя бы один из них не выстроен, AI-чат начинает работать, как интерфейс поверх разрозненных фрагментов системы.

Например:

1. когда структура сайта не отражает сценарии пользователей, а собрана вокруг маркетинговых блоков, AI не понимает, как связаны сущности продукта;
2. когда данные не унифицированы (CRM, заказы, поддержка, платежи живут отдельно), у системы нет единого источника правды;
3. когда логика продукта описана, как набор страниц «что мы хотим рассказать», AI не может восстановить последовательность действий пользователя;
4. если информация не доступна в машинно-используемом виде (нет API, нет структурированных данных), чат вынужден работать только с текстами.

AI формирует ответ на основе вероятностного совпадения текста, поэтому он может выглядеть уверенно даже тогда, когда данных недостаточно.

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

AI работает иначе: он отвечает мгновенно и одинаково для всех. С точки зрения архитектуры это массовая генерация ответов на основе ограниченного контекста. Поэтому любая неточность в данных или логике не корректируется, а тиражируется.

Технически это связано с тем, что модель строит ответ на основе входного запроса и доступного ей контекста (например, базы знаний). Если контекст неполный или противоречивый, модель не может это определить, она просто выбирает наиболее вероятный ответ из доступных фрагментов информации.

Что проверить перед внедрением AI в клиентский сервис

1. Есть ли на сайте актуальная и структурированная информация?

Если информация о доставке, оплате, тарифах или услугах разбросана по разным страницам, противорева или устарела, то AI начнёт воспроизводить эти же ошибки.

2. Есть ли единый источник данных?

Чат не должен угадывать статус заказа или клиента. Если CRM, сайт, личный кабинет не связаны между собой, AI не сможет давать точные ответы.

3. Есть ли на сайте логика пользовательских сценариев?

AI работает лучше всего там, где информация организована вокруг действий пользователя, а не вокруг внутренних разделов компании.

4. Не используется ли AI как компенсация плохого UX?

AI помогает ускорять взаимодействие, но не заменяет понятную структуру сайта, навигацию и доступность информации. Если без чат-бота пользователь теряется, проблема находится глубже, чем отсутствие AI.

5. Есть ли ограничения для AI?

В зонах с высокой ценой ошибки (финансы, медицина, юридические и конфликтные вопросы и пр.) должны быть сценарии передачи запроса в поддержку.

6. Кто отвечает за актуальность данных после запуска?

Частое упущение: бот внедрили, но базу знаний больше никто не обновляет. Через несколько месяцев AI начинает уверенно ссылаться на устаревшую информацию.

7. Есть ли вообще понятная бизнес-задача?

«Нам нужен AI-чат» — не задача.

Задача — это:

1. сократить нагрузку на поддержку,
2. ускорить ответы,
3. уменьшить количество типовых обращений,
4. повысить конверсию,
5. улучшить onboarding (помощь пользователю в начале работы).

Вместо заключения

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

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

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

➡️ Запись на Стратегическое интервью здесь.

Успехов в делах!

Роман Федосов, основатель и генеральный директор веб-интегратора «Компот»