Провальный проект автоматизации редко выглядит как катастрофа. Чаще это тихая история: бот запустили, им пользуются двое из десяти, менеджеры вернулись к Excel, собственник не поднимает тему, потому что неприятно признавать потраченные деньги. Через год кто-то предлагает «попробовать ИИ», и команда встречает идею с усталым скепсисом. Так автоматизация съедает не только бюджет, но и доверие, а второе восстановить дороже.
За несколько лет работы с малым и средним бизнесом мы в AiKrok видели одни и те же причины неудач, причём они почти не зависят от отрасли и инструментов. Ниже — семь ошибок, каждая с признаками, по которым её можно распознать заранее, и способом избежать.
Ошибка 1. Автоматизировать процесс, которого нет
Самая частая. Руководитель говорит: «Хотим автоматизировать обработку заявок». Начинаем разбирать — и выясняется, что заявки обрабатывают трое менеджеров, каждый по-своему: один звонит сразу, другой пишет в WhatsApp на следующий день, третий сначала проверяет клиента по базе. Никто не знает, какой вариант правильный. Автоматизировать здесь нечего: бот зафиксирует один из трёх вариантов, и двое менеджеров сочтут его неправильным.
Признак: на вопрос «что происходит с заявкой после того, как она пришла?» разные сотрудники отвечают по-разному.
Что делать: сначала описать процесс на одной странице — шаги, ответственные, исключения. Иногда на этом этапе выясняется, что половину шагов можно просто убрать, и автоматизация уже не нужна. Как провести такой разбор за день, описано в статье об аудите процессов.
Ошибка 2. Начать с самого большого и сложного
«Давайте сразу сделаем систему, которая ведёт клиента от первого касания до повторной покупки, с ИИ, CRM и аналитикой». Такой проект длится месяцы, за которые бизнес меняется, требования плывут, а результата всё нет. К моменту запуска часть сценариев уже устарела, а команда разочарована ожиданием.
Признак: у проекта нет ответа на вопрос «что заработает через две недели».
Что делать: разбить на этапы, каждый из которых даёт самостоятельную пользу и может быть запущен отдельно. Первый этап — самый болезненный и самый понятный кусок. Остальное — после того, как первый проработал месяц и показал цифры. Что именно стоит класть в первую версию, мы разбирали в статье об MVP за две недели.
Ошибка 3. Решать за команду, не спрашивая команду
Автоматизацию заказывает собственник, пользуются ею сотрудники. Если менеджеров не спросили, что мешает им в работе, система почти наверняка добавит им действий, а не уберёт: ещё одно окно, ещё одно поле, ещё одна кнопка «подтвердить». Люди голосуют ногами — ведут параллельные таблицы, забывают ставить статусы, и данные в системе перестают отражать реальность.
Признак: через месяц после запуска в системе меньше записей, чем сделок в реальности.
Что делать: до разработки провести два-три часа с теми, кто будет пользоваться. Выяснить, что они делают руками по десять раз в день, и начать с этого. Первый эффект должен быть виден сотруднику, а не только руководителю: меньше звонков диспетчеру, не нужно переписывать заявку из чата в таблицу. Тогда дисциплина поддерживается сама.
Ошибка 4. Ждать от ИИ того, что должен делать обычный код
Мода на языковые модели приводит к попыткам отдать им всё: посчитать стоимость доставки, определить срок по договору, выбрать тариф. Модель делает это уверенно и иногда неправильно. Потом выясняется, что агент назвал клиенту цену, которой нет в прайсе, или пообещал срок, который компания не может выполнить.
Признак: в описании решения модель «сама считает», «сама определяет», «сама решает» в тех местах, где есть чёткие правила.
Что делать: разделить роли. Модель понимает текст, извлекает данные, формулирует ответ. Расчёты, проверки, правила — обычный код или таблица. Если правило можно записать как «если А, то Б», оно не должно быть в модели. Это снимает основную часть рисков, о которых идёт речь в статье о галлюцинациях ИИ, и попутно удешевляет решение.
Ошибка 5. Не определить, как измерять результат
«Стало лучше» — не результат. Если до запуска не зафиксировано, что именно должно измениться и на сколько, то через три месяца невозможно понять, работает ли автоматизация. Собственник опирается на ощущения, команда — на свои, и разговор о продолжении превращается в спор мнений.
Признак: на вопрос «как поймём, что получилось?» ответ начинается со слов «ну, будет видно».
Что делать: до старта зафиксировать два-три числа: время ответа на заявку, доля неявок, часы на подготовку отчёта. Измерить их «до». Поставить цель с оговоркой на диапазон. После запуска смотреть на те же числа раз в неделю. Это дисциплинирует и подрядчика, и заказчика.
Ошибка 6. Запустить и забыть
Автоматизация — не ремонт, который сделали и живут. Меняются цены, появляются новые услуги, клиенты начинают задавать вопросы, которых не было, мессенджер обновляет API. Если никто не отвечает за систему после запуска, она деградирует: бот отвечает устаревшими данными, интеграция падает после обновления, и первым это замечает клиент.
Признак: после приёмки проекта нет человека, который хотя бы раз в неделю смотрит логи и диалоги.
Что делать: назначить владельца внутри компании — не разработчика, а человека из бизнеса, который знает процесс. Договориться с подрядчиком о поддержке: что входит, за какое время реагируют. Заложить в бюджет не только разработку, но и сопровождение, ориентировочно десятую-пятую часть стоимости разработки в год, в зависимости от сложности. Структура таких затрат разобрана в статье о стоимости AI-агента.
Ошибка 7. Выбирать инструмент до того, как понята задача
«Нам нужен Bitrix24», «хотим бота на n8n», «сделайте в Make, у нас уже есть подписка». Инструмент выбирается по знакомству, рекламе или совету знакомого, а потом задача подгоняется под него. В результате простая вещь делается сложно, а сложная — не делается вовсе, потому что инструмент этого не умеет.
Признак: в первой встрече с подрядчиком обсуждаются платформы, а не процессы.
Что делать: сначала задача, объёмы, интеграции, требования к данным. Потом инструмент под них. Хороший подрядчик спросит, сколько у вас заявок в день и где хранятся клиенты, прежде чем назовёт платформу. Если он начинает с названия продукта, который продаёт, это повод насторожиться.
Что объединяет все семь
Ни одна из этих ошибок не техническая. Технологии в 2026 году надёжны: модели понимают текст, интеграции работают, платформы автоматизации зрелые. Проекты проваливаются на стыке с людьми и процессами: непонятная задача, завышенные ожидания, отсутствие владельца и измерений.
Хорошая новость в том, что все семь ошибок предотвращаются до начала разработки, на этапе разговора. Если перед стартом у вас есть описание процесса на страницу, понятно, что заработает через две недели, команда участвовала в обсуждении, зафиксированы цифры «до» и назначен владелец — проект с высокой вероятностью принесёт результат. Если хотя бы трёх пунктов нет, лучше потратить ещё неделю на подготовку, чем месяцы на переделку.
С чего начать
Пройдитесь по списку из семи пунктов применительно к процессу, который собираетесь автоматизировать, и честно отметьте, где есть пробелы. Обычно их два-три, и закрыть их можно за несколько дней внутренней работы, без подрядчика. После этого разговор с разработчиком будет короче, а оценка — точнее. Если нужен взгляд со стороны, можно начать с бесплатной консультации: мы задаём именно эти вопросы на первой встрече.