статья · 24.10.2026
Автоматизация начинает приносить пользу не тогда, когда выбрана технология, а когда выбран процесс. Ниже — пять признаков готовности и способ посчитать выгоду до первой строки кода.
Первый порыв — выписать все рутинные операции и отдать список подрядчику. Через месяц выясняется: половина процессов живёт в головах, вторая половина меняется каждый квартал, а измерить результат нечем.
Дело не в технологии. Автоматизация усиливает то, что уже есть: если правила размыты, бот уверенно воспроизведёт беспорядок, только быстрее. Если данных нет, системе не из чего собрать ответ.
Порядок обратный: один узкий участок с понятными границами, описание, автоматизация, следующий участок. У проекта «автоматизируем всё» нет критерия готовности — его нельзя закрыть, принять и посчитать. Один процесс с измеримым результатом закрыть можно, и это видят обе стороны.
Есть и человеческая часть. Если сотрудники читают автоматизацию как замену, они сопротивляются тихо: не заполняют поля, обходят систему, отвечают клиентам в личных мессенджерах. Об этом говорят до старта, а не после.
Готовность видна без аудита. Пять вопросов, на которые отвечает тот, кто делает работу руками.
Совпало три-четыре пункта — процесс стоит разбирать дальше. Совпало один-два — сначала описать правила и собрать примеры, автоматизация подождёт.
Считать принято сложно: TCO, сценарии, модели. На первом разговоре хватает листа бумаги.
Часы × стоимость часа × частота. Пример, не прайс: шестьдесят заявок в неделю по двенадцать минут — двенадцать часов. При условной стоимости часа восемьсот рублей это около девяти с половиной тысяч в неделю и порядка сорока тысяч в месяц. Дальше сравниваем с ценой внедрения: разработка, интеграции, поддержка, время сотрудников на приёмку.
Вторая поправка — реальная экономия. Время не исчезает целиком: остаётся проверка, разбор ошибок, обновление базы знаний. На первом этапе честно закладывать половину высвобожденных часов, а не все сто процентов.
Третья — неденежные эффекты. Ответ ночью, отсутствие забытых заявок, одинаковые ответы у всех операторов. Это настоящая польза, но подменять ею расчёт нельзя: если в часах процесс не окупается, стоит спросить, зачем он нужен.
И последнее — срок окупаемости. Если он уходит за горизонт года, дело обычно не в цене разработки, а в выбранном процессе: он либо слишком редкий, либо слишком сложный для первого шага.
Есть три участка, где математика сходится чаще всего. Не потому, что они модные, а потому что в них совпадают все пять признаков.
Разбор заявок. Приём из формы, почты или мессенджера, классификация по теме, передача нужному человеку, ответ на стандартные вопросы. Работа повторяется каждый день, правила известны, цена ошибки низкая — заявку всегда можно перекинуть вручную.
Ответы по базе знаний. Условия, сроки, инструкции, статусы. Здесь важна деталь: автоматизируется не «поддержка», а конкретный набор тем. Как это выглядит на практике — в материале про автоматизацию поддержки.
Отчёты. Сбор данных из нескольких систем в один файл или дашборд по одному шаблону раз в неделю. Человек тратит на это часы, машина — минуты, а ошибки в ручной сборке встречаются регулярно. Обычно это часть интеграций между системами.
Общее у всех трёх: частые однотипные операции, понятный результат и дешёвая ошибка. Поэтому они окупаются быстрее, чем «цифровой сотрудник», который должен уметь всё.
Список того, что автоматизировать не стоит, короче, но важнее списка возможностей.
Что делать вместо: упростить процесс. Убрать лишнее согласование, объединить две формы в одну, договориться об одном шаблоне ответа. Половина «автоматизации» на проверку оказывается уборкой, и это самый дешёвый способ разгрузить людей.
Пилот — не демонстрация, а проверка на реальной работе. У него есть критерий успеха, зафиксированный до старта, и он измеряется теми же цифрами, что и текущий процесс.
На выходе — работающий контур на реальных данных, список типовых ошибок, цифры до и после и понятная цена следующего этапа. Если вместо этого показывают слайды и обещают, что «всё заработает», это не пилот.
Хороший признак — когда подрядчик сам предлагает остановиться на одном участке, хотя вы готовы платить за три. Значит, он считает риск, а не бюджет.
Эти вопросы отделяют инженера от продавца презентаций. Задавать их лучше до подписания, а не на приёмке.
Ответы должны быть конкретными. «Всё сделаем, всё работает» — не ответ. Если подрядчик не может назвать ни одного процесса, который автоматизировать не стоит, он либо не разбирался в задаче, либо продаёт что-то другое.
И последнее: попросите показать похожий контур в работе, а не скриншоты. Посмотреть, как устроена работа с процессами и куда движется проект, полезнее любого описания. Если хотите обсудить свой случай — напишите, разберём, с чего начать.
С одного. Выберите участок, где совпадают объём, повторяемость и дешёвая ошибка, — чаще всего это приём и разбор заявок. Не начинайте с самого болезненного процесса: там больше всего исключений и меньше всего шансов на быстрый результат. Первый контур должен закрыться за две-три недели, иначе энтузиазм кончится раньше, чем появится эффект.
Нет. Часть задач закрывается обычной интеграцией, формой или правилами в CRM, и это дешевле. ИИ нужен там, где на входе свободный текст: письма, сообщения, документы без жёсткого шаблона. Если задачу можно описать условием «если — то», языковая модель только добавит неопределённости.
Сначала его надо описать. Возьмите двадцать-тридцать реальных случаев и выпишите, что вы делаете в каждом. Если на половине примеров ответ «зависит», процесс ещё не готов: сначала договоритесь о правилах, потом отдавайте в разработку. Иначе автоматизируете не процесс, а чьё-то настроение.
Пилот на одном участке — около двух недель, включая работу в режиме проверки человеком. Дальше срок зависит от числа систем, которые нужно связать, и от качества данных. Точный срок до просмотра реальных обращений не назовёт ни один честный подрядчик.
Опишите процесс в двух предложениях — вернусь со схемой решения и оценкой сроков.