У автоматизации есть соблазнительный короткий путь: найти новую CRM, сервис, бота или AI-платформу и решить, что проблема теперь техническая. Мы сами несколько раз попадали в похожую ловушку, только на уровне разработки Agent Core. Хотелось построить универсальный механизм исполнения, а в какой-то момент механизма стало так много, что его обслуживание превратилось в отдельную работу.
Полезный вывод оказался не техническим: автоматизация начинается не с выбора программы. Она начинается с точного повторяемого маршрута, который можно наблюдать, измерить и упростить.
Сначала надо найти повторяемую операцию
Фраза «хотим автоматизировать продажи» слишком широкая. Что именно повторяется? Менеджер вручную переносит лид из формы в CRM? Проверяет оплату и меняет статус заказа? Копирует остатки между кабинетами? Собирает отчёт из нескольких систем?
Когда маршрут описан до конкретных шагов, становится видно, где ошибка процесса, а где действительно не хватает инструмента. Иногда новая CRM не нужна — достаточно соединить существующие системы. Иногда наоборот: текущая система не умеет нужное действие и интеграция только законсервирует ограничение.
Новая система не исправляет плохую логику
Если в процессе непонятно, кто отвечает за следующий шаг, автоматизация может лишь быстрее передавать неопределённость. Если данные вводятся в разных форматах, интеграция начнёт быстрее распространять грязные данные. Если никто не знает, какой статус считается правильным, AI тоже не должен угадывать политику компании.
Мы увидели аналогичную проблему в своей инфраструктуре. Отдельный Runner для задач работал и давал дисциплину, но вокруг него накопилась сложная state machine: очереди, blocked/failed состояния, восстановление, дополнительный контроль. Когда появился более прямой безопасный путь, лишний слой мы удалили. Автоматизация оказалась полезной до тех пор, пока стоимость её координации не стала выше пользы.
Хороший первый шаг — маленький, но законченный
Я бы выбирал один маршрут, у которого понятны вход и выход. Например: новая заявка с сайта должна появиться в CRM с источником и ответственным. Или оплаченный заказ должен изменить статус и передать событие на склад. Один такой путь можно измерить до и после.
После этого уже выбираются средства: API, webhook, интеграционная платформа, скрипт или AI. Инструмент следует за процессом, а не наоборот.
Именно поэтому диагностика перед автоматизацией — не лишняя консультация. Это способ не потратить бюджет на ускорение неправильного процесса.
Процесс стоит описать до того, как искать подрядчика или сервис
Для первого разбора достаточно простой схемы: что запускает процесс, какие данные приходят на вход, кто принимает решение, что должно измениться на выходе и что происходит при исключении. Уже на этом уровне обычно обнаруживаются места, которые невозможно автоматизировать без управленческого решения. Например, два сотрудника по-разному понимают один статус или один и тот же заказ вручную заводится в нескольких системах с разными обязательными полями.
Если такую неоднозначность спрятать под интеграцией, она не исчезает. Просто спор или ошибка происходят быстрее и становятся менее заметными. Поэтому до кода полезно договориться о правилах: какой источник считается главным, кто владеет следующим шагом, какие состояния допустимы и когда процесс считается завершённым.
После этого видно, где нужен скрипт, а где AI
Большая часть бизнес-автоматизации по-прежнему прекрасно решается обычными правилами. Пришла новая заявка — создать лид. Получена оплата — передать событие дальше. Изменился остаток — синхронизировать значение. Чем однозначнее вход и ожидаемый выход, тем меньше причин добавлять модель.
AI нужен там, где появляется язык и контекст: разобрать письмо, классифицировать нестандартный запрос, сопоставить несколько описаний, подготовить ответ, найти отклонение в разрозненных данных. Даже в таком процессе жёсткие правила лучше оставить вокруг модели: что она может читать, какие варианты результата допустимы и какое действие требует подтверждения.
Автоматизация без наблюдаемости создаёт новый вид ручной работы
Есть ещё один слой, который легко недооценить. Интеграция должна не только работать в нормальном сценарии, но и понятно ломаться. Если внешний сервис недоступен, куда попадёт задача? Увидит ли кто-то ошибку? Можно ли безопасно повторить операцию? Не создаст ли повтор дубль заказа или сообщения?
Если ответов нет, команда получает новый ручной процесс — поиск пропавших событий внутри автоматизации. Поэтому журнал, понятные статусы и возможность восстановить цепочку важны не меньше самого соединения систем. Хорошая автоматизация уменьшает неопределённость, а не прячет её глубже.
Первый проект должен доказывать принцип целиком
Я бы не начинал с десятков сценариев одновременно. Лучше выбрать один поток, который действительно повторяется и имеет понятный результат. Провести его от входного события до подтверждённого выхода, учесть ошибку внешней системы и только после этого копировать подход на соседние процессы.
Так появляется реальная оценка сложности. Иногда выясняется, что основная работа была не в интеграции, а в нормализации данных. Иногда достаточно небольшого webhook и нескольких правил. Иногда действительно нужен отдельный сервис или AI-слой. Но это решение принимается после диагностики, а не потому, что выбранный продукт умеет много функций.
В результате программа становится последним, а не первым пунктом выбора. Сначала бизнес определяет маршрут и критерий готовности. Затем выбирается самый простой инструмент, который этот маршрут надёжно закрывает.
Хороший процесс имеет владельца и понятный выход
Автоматизация часто ломается на границе подразделений. Система успешно передала данные, но следующий сотрудник не считает это своей задачей. Или технически создан новый статус, а никто не договорился, что он означает. Поэтому в описании маршрута нужен не только набор шагов, но и владелец результата.
Для каждой автоматизированной цепочки я бы фиксировал, кто замечает исключение, кто имеет право повторить действие и кто принимает решение, если данные расходятся. Это не бюрократия. Без такого владельца любой сбой возвращает процесс в общий чат, где команда вручную выясняет, «кто должен посмотреть».
Экономика автоматизации тоже начинается с конкретного маршрута
Когда процесс очерчен, можно считать не абстрактную «эффективность цифровизации», а понятные затраты: сколько ручных переходов есть сейчас, где возникает задержка, какой объём исключений останется после автоматизации и сколько будет стоить поддержка интеграции. Иногда автоматизировать редкую операцию дороже, чем оставить её человеку. Иногда короткая задержка в массовом процессе создаёт намного большую стоимость.
Такой расчёт защищает от двух крайностей: автоматизировать всё подряд или, наоборот, годами терпеть повторяемую ручную работу. Решение появляется из фактической частоты, риска ошибки и цены сопровождения.
Если у вас несколько систем и много ручных переходов, полезно сначала выбрать один маршрут и разобрать его целиком. Мы можем помочь с такой диагностикой и последовательностью внедрения: обсудить задачу