Почему AI-автоматизация ломается на плохих данных

Коротко

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

Если в CRM дубли, в таблицах разные названия товаров, в Telegram теряются договорённости, а менеджеры по-разному заполняют поля, AI не “починит процесс”. Он просто быстрее разнесёт ошибки по системе.

Перед внедрением нужно не “идеально вылизать базу”, а сделать минимум:

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

Как плохие данные ломают AI-автоматизацию

Представим обычную ситуацию в малом бизнесе.

Заявки приходят с сайта, из Telegram, WhatsApp, Авито, личных сообщений и рекомендаций. Часть попадает в CRM, часть остаётся у менеджера в чате, часть лежит в таблице “на всякий случай”. Один и тот же клиент может быть записан как “Иван”, “Иван Петров”, “Петров И.” и “Иван WB”.

Пока всё делает человек, проблема неприятная, но привычная. Менеджер помнит контекст, спрашивает коллегу, ищет по переписке, иногда ошибается, но вытягивает процесс руками.

Когда подключают AI-агента, начинается другое.

Агент видит четыре разных клиента. У одного нет телефона. У второго нет истории общения. У третьего стоит статус “новый”, хотя он уже оплатил. У четвёртого в комментарии написано “не звонить”, но это поле не попало в сценарий.

В итоге автоматизация делает формально правильные действия по неправильным данным:

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

Это не “AI ошибся”. Это система дала ему плохую картину мира.

Типовые проблемы данных в CRM, продажах и поддержке

Плохие данные редко выглядят как одна большая авария. Обычно это набор мелочей, к которым все привыкли.

Дубли клиентов и сделок

Дубли — самый частый источник ошибок.

Клиент оставил заявку на сайте, потом написал в Telegram, потом позвонил с другого номера. Если система не умеет связывать эти касания, AI видит три независимых обращения.

Для продаж это означает двойные сообщения и путаницу в воронке. Для поддержки — повторные вопросы. Для отчётов — завышенное количество лидов и неправильную конверсию.

Перед автоматизацией важно проверить хотя бы основные ключи объединения: телефон, email, Telegram username, ID клиента, номер заказа, ИНН для B2B.

Свободный текст вместо нормальных статусов

Статус сделки должен быть машинно понятным.

Плохо:

• “думает”;
• “вроде готов”;
• “позвонить потом”;
• “ждём”;
• “не сейчас”.

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

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

Разные названия одного и того же объекта

В e-commerce и маркетплейсах это встречается постоянно.

В таблице товар называется “Костюм женский беж”. В WB — другой артикул. В Ozon — третий offer_id. В рекламном отчёте — SKU. В CRM — “костюм бежевый новый”. В голове менеджера — “тот самый костюм из весенней партии”.

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

Для селлера WB/Ozon это особенно критично: ошибка в карточке, цене или рекламной кампании может стоить денег уже сегодня.

История общения живёт в мессенджерах, а решение — в CRM

Частая картина: CRM показывает “сделка в работе”, но главный контекст лежит в Telegram.

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

Автоматизация не обязана переносить в CRM каждую реплику. Но ключевые события должны фиксироваться: договорённость, запрет на контакт, следующий шаг, дата, ответственный, сумма, статус.

Иначе AI будет работать с витриной, а не с реальным процессом.

Нет владельца данных

Если никто не отвечает за качество CRM, качество быстро падает.

Менеджерам важно закрывать сделки, поддержке — отвечать быстрее, руководителю — видеть отчёт. Но если нет правила “как заполняем поля” и человека, который следит за этим правилом, база превращается в склад компромиссов.

AI в такой системе становится ещё одним пользователем, который зависит от дисциплины остальных.

Почему нельзя просто “дать AI доступ ко всему”

Есть соблазн: подключить AI к CRM, Telegram, таблицам, маркетплейсам, почте и сказать: “разберись сам”.

В демо это может выглядеть впечатляюще. В production — опасно.

AI-агенту нужны не только доступы, но и границы:

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

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

Хорошая автоматизация не убирает человека из процесса. Она убирает рутину и оставляет человеку контрольные точки.

Рабочий подход: сначала данные, потом AI

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

Например:

• обработка входящих заявок;
• первичная квалификация лидов;
• ответы на типовые вопросы поддержки;
• ежедневный отчёт по продажам;
• мониторинг остатков WB/Ozon;
• разбор отзывов и вопросов покупателей;
• сводка по сделкам без движения;
• напоминания менеджерам по CRM.

Дальше процесс нужно разложить на простую схему.

1. Где начинается процесс

Нужно понять, откуда приходит событие.

Для заявки это может быть форма сайта, Telegram-бот, сообщение менеджеру, звонок, email. Для маркетплейса — новый заказ, отзыв, изменение остатков, рекламный расход. Для поддержки — вопрос клиента, тикет, комментарий в чате.

Если входов несколько, важно решить: все ли они попадают в один контур или часть пока остаётся за пределами автоматизации.

2. Какие данные обязательны

Для каждого процесса есть минимальный набор полей.

Для лида:

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

Для заказа:

• номер заказа;
• клиент;
• товары;
• сумма;
• статус оплаты;
• статус доставки;
• проблемные отметки.

Для товара WB/Ozon:

• внутренний артикул;
• SKU/nmID/offer_id;
• остаток;
• цена;
• себестоимость, если считаем маржу;
• статус карточки;
• рекламные кампании, если анализируем продвижение.

Если обязательных данных нет, агент должен не угадывать, а возвращать задачу человеку: “не хватает телефона”, “нет связки SKU”, “нет себестоимости для расчёта маржи”.

3. Где источник правды

Самый важный вопрос: если данные отличаются, чему верим?

Например, статус сделки в CRM говорит “новый”, а в Telegram менеджер написал “оплатил”. Таблица показывает остаток 12, кабинет маркетплейса — 3. В отчёте рекламных расходов одна сумма, в финансовом отчёте другая.

Без правила приоритета автоматизация будет спорить сама с собой.

Источник правды не всегда один на всю компанию. Для контактов это может быть CRM. Для остатков — кабинет WB/Ozon. Для финансов — бухгалтерская система. Для задач — таск-трекер. Главное, чтобы правило было явным.

4. Какие действия AI может выполнять сам

Не все действия одинаково рискованные.

Низкий риск:

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

Средний риск:

• поставить задачу менеджеру;
• изменить статус сделки;
• отправить типовое сообщение;
• обновить тег клиента;
• создать черновик документа.

Высокий риск:

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

Для среднего и высокого риска нужен human-in-the-loop: подтверждение человеком, лимиты, журнал действий и возможность отката.

5. Как фиксируются ошибки

Ошибки будут. Вопрос не в том, как сделать систему “безошибочной”, а в том, увидите ли вы проблему быстро.

Минимум для нормальной эксплуатации:

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

Если агент предложил не тот ответ, вы должны понять почему: не было данных, был неправильный статус, промпт не учёл правило, модель неверно классифицировала обращение или интеграция передала неполный объект.

Без логов автоматизация превращается в магию. А магию невозможно обслуживать.

Пример: AI-агент для заявок из Telegram и CRM

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

Хотят внедрить AI-агента, который будет:

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

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

Рабочая подготовка выглядит так:

1. Определяем единый идентификатор клиента: телефон, email или Telegram ID.
2. Настраиваем правило: если клиент уже есть, не создавать новый контакт, а обновлять существующий.
3. Ограничиваем статусы сделки до понятного списка.
4. Создаём обязательные поля: источник, интерес, следующий шаг, ответственный.
5. Разделяем типы заявок: консультация, поддержка, партнёрство, маркетплейс, другое.
6. Для неуверенной классификации ставим статус “нужна проверка”, а не отправляем в случайную воронку.
7. Включаем лог: что агент прочитал, что решил, что создал или предложил.

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

Пример: WB/Ozon и отчёт, которому нельзя верить

У селлера есть таблица себестоимости, кабинет WB, кабинет Ozon и рекламные отчёты. Хочется AI-агента, который каждый день показывает:

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

Главная проблема — связки.

Если в таблице себестоимости нет точного соответствия с SKU/Ozon offer_id/WB nmID, агент не сможет корректно посчитать прибыльность. Он может взять похожее название и ошибиться. Например, смешать разные размеры, цвета или комплекты.

Поэтому перед автоматизацией нужен “словарь товаров”: внутренний артикул, идентификаторы маркетплейсов, название, категория, себестоимость, упаковка, особенности. Это скучная работа, но без неё AI-отчёт будет красивым и бесполезным.

Хороший агент в такой ситуации должен не просто “выдать аналитику”, а подсветить качество данных:

• у 18 товаров нет себестоимости;
• у 7 товаров не найден offer_id;
• у 4 карточек разные названия в таблице и Ozon;
• по 3 позициям невозможно посчитать маржу;
• рекламные расходы есть, а связки с товаром нет.

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

ROI: где экономия времени на самом деле

Экономия от AI-автоматизации появляется не в момент, когда “бот начал отвечать”. Она появляется, когда процесс перестаёт требовать ручного поиска, сверки и переписывания данных.

Например, менеджер каждый день тратит 40 минут на проверку сделок без движения: открывает CRM, смотрит статусы, читает комментарии, вспоминает переписку. AI-агент может за 2–3 минуты собрать список сделок, где нет следующего шага, и предложить действие.

Но это работает только если:

• сделки реально ведутся в CRM;
• статусы не заполняются произвольно;
• дата следующего шага есть в понятном поле;
• Telegram-договорённости хотя бы кратко фиксируются;
• агенту разрешено читать нужные объекты.

Если этих условий нет, экономия растворяется: менеджер всё равно проверяет вручную, потому что не доверяет отчёту.

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

Мини-чек-лист качества данных перед AI-внедрением

Перед запуском AI-агента проверьте не “готов ли бизнес к искусственному интеллекту”, а более приземлённые вещи.

Контур процесса

• Понятно, где начинается процесс.
• Понятно, где он заканчивается.
• Есть список систем, через которые проходит объект: CRM, Telegram, таблица, маркетплейс, почта, API.
• Есть ответственный за процесс.

Объекты и поля

• Определены ключевые объекты: клиент, сделка, заказ, товар, обращение, задача.
• У каждого объекта есть уникальный идентификатор или правило склейки.
• Обязательные поля известны и реально заполняются.
• Нет критичных полей, которые живут только “в голове менеджера”.

Статусы

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

Дубли и связки

• Есть правило поиска дублей.
• Понятно, как объединять контакты.
• Для товаров связаны внутренние артикулы и идентификаторы площадок.
• Для заказов и обращений есть связь с клиентом.

Права и контроль

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

Если по половине пунктов ответ “не знаем”, внедрять AI во весь процесс рано. Но можно начать с безопасного режима: агент только анализирует данные и показывает проблемы.

Как внедрять без большого рефакторинга

Не обязательно останавливать бизнес и месяц “чистить CRM”.

Практичный путь — запускать автоматизацию слоями.

Шаг 1. Диагностика данных

Сначала агент или скрипт ничего не меняет. Он только читает данные и показывает:

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

Это безопасный старт. Команда видит реальное состояние процесса без споров на уровне ощущений.

Шаг 2. Черновики и рекомендации

Дальше AI готовит предложения, но не выполняет действия сам.

Например:

• “объединить эти два контакта”;
• “поставить сделке статус ждём оплату”;
• “ответить клиенту таким текстом”;
• “передать обращение в поддержку”;
• “проверить товар, потому что реклама есть, а заказов нет”.

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

Шаг 3. Автоматизация низкорисковых действий

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

• ставить задачи;
• присваивать теги;
• создавать черновики;
• отправлять внутренние уведомления;
• обновлять технические поля;
• формировать ежедневные отчёты.

Это уже экономит время, но не создаёт большого риска для клиентов и денег.

Шаг 4. Действия с подтверждением

Для более чувствительных сценариев оставляем подтверждение.

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

Так AI становится операционным помощником, а не неконтролируемым администратором.

Что делать, если данные уже плохие

Первое — не стыдиться. У большинства компаний данные неидеальны. Особенно если бизнес рос быстро, процессы собирались на ходу, а инструменты подключались по мере боли.

Второе — не пытаться “почистить всё”. Это почти всегда заканчивается усталостью и незавершённым проектом.

Лучше выбрать один процесс с понятной бизнес-ценностью.

Например: “заявки не теряются и по каждой есть следующий шаг”. Для этого не нужно исправлять всю CRM за три года. Нужно настроить текущий поток заявок, обязательные поля, статусы и напоминания.

Или: “каждый день видно, какие товары WB/Ozon требуют внимания”. Для этого не нужно сразу строить идеальное хранилище данных. Достаточно связать ключевые SKU, остатки, продажи и рекламные расходы по приоритетным товарам.

AI-автоматизация хорошо работает как прожектор. Она быстро показывает, где процесс не описан, где нет владельца, где данные расходятся. Это неприятно, но полезно: становится понятно, что чинить первым.

Когда AI лучше не подключать

Есть ситуации, где сначала нужен не AI, а базовая операционная дисциплина.

Например:

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

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

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

Как понять, что процесс готов к AI

Процесс готов не тогда, когда “все данные идеальные”. Идеальных данных почти не бывает.

Хороший признак — вы можете ответить на пять вопросов:

1. Что является входом процесса?
2. Где лежит главный объект: клиент, сделка, заказ, товар или обращение?
3. Какие поля обязательны для решения?
4. Какие действия AI может делать сам, а какие только предлагать?
5. Где посмотреть лог, если что-то пошло не так?

Если ответы есть, можно запускать пилот.

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

FAQ

Нужно ли полностью чистить CRM перед AI-автоматизацией?

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

AI может сам найти и удалить дубли?

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

Что важнее: промпт или качество данных?

Для production-автоматизации качество данных важнее. Хороший промпт не спасёт, если агент не видит актуальный статус, получает неполные поля или работает с дублями. Промпт задаёт поведение, но данные задают реальность, в которой агент принимает решение.

Можно ли начать с Telegram, если CRM в плохом состоянии?

Можно, но лучше не делать Telegram единственным источником правды. Безопасный вариант — AI собирает заявки из Telegram, структурирует их и создаёт или обновляет записи в CRM. Так мессенджер остаётся удобным входом, а процесс постепенно переезжает в управляемый контур.

Какие данные критичны для AI-агента в продажах?

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

Что нельзя отдавать AI без подтверждения?

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

Как быстро понять, где у нас проблемы с данными?

Запустите короткий аудит одного процесса. Например, выгрузите сделки за 30 дней и проверьте дубли, пустые поля, странные статусы, сделки без следующего шага и расхождения с перепиской. Для маркетплейсов проверьте связку внутренних артикулов с WB/Ozon, наличие себестоимости и корректность остатков.

Вывод

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

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

Если хочешь понять, что автоматизировать у себя и где сначала нужно навести порядок в данных — напиши Дмитрию в Telegram @dmkosik или опиши процесс для диагностики Paramiko. Можно начать с одного участка: заявки, CRM, поддержка, WB/Ozon, отчёты или Telegram-бот.

QA-чеклист

• [x] Есть служебный SEO-блок: slug, meta title, description, запросы, internal links, schema notes.
• [x] H1 соответствует теме и поисковому интенту.
• [x] После вступления есть блок “Коротко”.
• [x] Логика статьи идёт по цепочке: problem → workflow → ROI/time saved → risks → implementation.
• [x] Есть примеры из CRM, Telegram, продаж, поддержки, WB/Ozon.
• [x] Нет обещаний, что AI заменит людей.
• [x] Объяснены human-in-the-loop, логи, права доступа и подтверждение рискованных действий.
• [x] Есть практические чек-листы, которые можно применить до внедрения.
• [x] Есть FAQ на 7 вопросов.
• [x] CTA мягкий: Telegram @dmkosik / диагностика Paramiko.
• [x] Текст без канцелярита, хайпа и пустых списков.
• [x] Статья подходит для evergreen SEO/LLM-блога Paramiko.ru.