Правила дешевле модели до тех пор, пока процесс помещается в 10–15 ветвлений, а девять обращений из десяти приходят в ожидаемой форме. В этих границах правило стоит ноль за обращение, отвечает одинаково каждый раз и проверяется чтением: открыл условие — увидел, что будет. Как только доля обращений вне шаблона переваливает за десятую часть, а ветвлений становится несколько десятков, соотношение переворачивается — и дальше вопрос только в том, окупается ли разница.
Спор «нейросеть или обычная автоматизация» обычно ведётся идеологически, хотя решается арифметикой. У правил нулевая стоимость обращения и стопроцентная воспроизводимость, но они не переносят грязный вход. У модели есть гибкость на грязном входе, но она стоит денег за каждое обращение, требует контура контроля и отвечает не всегда одинаково.
Ниже — как посчитать оба параметра за час, сравнение обеих схем на одинаковых вводных в 3 000 обращений в месяц, четыре типа входа, на которых правила ломаются всегда, честная скрытая стоимость правил и решающее дерево на одну страницу. Цены — по состоянию на сентябрь 2026 года.
Два числа, по которым принимается решение
Не нужно ни исследования, ни аудита. Нужны два числа, и оба считаются по выгрузке из вашей же системы за один рабочий день.
Точка, где дальнейшие действия зависят от условия: тип клиента, сумма, регион, статус оплаты, наличие товара. Каждое ветвление удваивает количество путей, которые надо описать и потом поддерживать. Считать надо не «сколько шагов в процессе», а сколько раз внутри него приходится смотреть на данные и выбирать дорогу.
- 1Выгрузите 100 последних обращений или заявок подряд, без отбора. Именно подряд: выборка «типичных» примеров, которую соберёт руководитель отдела, всегда чище реальности.
- 2Разметьте их на три кучи: полностью в шаблоне (данные там, где ожидались, формулировка понятная), в шаблоне с оговоркой (не хватает одного поля, есть опечатка) и вне шаблона. Доля первой кучи — ваш процент типовых обращений.
- 3Нарисуйте на листе путь обработки одной заявки и отметьте каждую точку, где сотрудник смотрит на данные и выбирает, что делать дальше. Количество таких точек — число ветвлений. Больше двух часов эта работа не занимает.
Дальше читается по таблице ниже. До 10–15 ветвлений и при 90 % типовых обращений берутся правила. Выше 30 ветвлений или ниже 70 % типовых — модель. Между этими границами лежит зона, в которой обычно выигрывает гибридная схема: правила на массовом потоке, модель на остатке.
Двухосевое поле. Горизонтальная ось — «число ветвлений процесса» с делениями 5, 10, 15, 30, 50. Вертикальная — «доля обращений в шаблоне» с делениями 50, 70, 90, 100 %. Поле разделено на три области: левая верхняя (до 15 ветвлений, выше 90 %) закрашена и подписана «правила: 0 ₽ за обращение»; правая нижняя (выше 30 ветвлений или ниже 70 %) подписана «модель: 0,4–1,2 ₽ за обращение»; диагональная полоса между ними подписана «гибрид: правила на массовом потоке, модель на остатке». На поле отмечены две точки модельных расчётов из статьи: «сценарий А: 60 % типовых» и «сценарий Б: 90 % типовых», обе при 3 000 обращений в месяц. Чертёжный стиль, подписи по-русски.
Сравнение на одинаковых вводных: 3 000 обращений в месяц
Вводные для обеих схем одни и те же: 3 000 обращений в месяц, ручной разбор одного — 5 минут, ставка сотрудника со всеми налогами и накладными — 600 ₽/час. Полный ручной разбор стоит 3 000 × 5 = 15 000 минут, то есть 250 часов и 150 000 ₽ в месяц. Это верхняя планка, от которой считается экономия в обоих вариантах.
| Параметр | Автоматизация по правилам | ИИ-агент на модели |
|---|---|---|
| Разработка | 120 000–180 000 ₽ | 250 000–500 000 ₽ |
| Срок запуска | 3–4 недели | 6–10 недель |
| Стоимость одного обращения | 0 ₽ | 0,4–1,2 ₽ (токены российских моделей) |
| Эксплуатация в месяц | 8 000 ₽ поддержки | 18 000 ₽ контура контроля плюс токены |
| Изменение регламента | 1–3 часа, пока правил меньше 20 | 20 минут: правка базы знаний |
| Закрыто без человека при 60 % типовых | 55 % | 78 % |
| Воспроизводимость ответа | Полная: одинаковый вход — одинаковый выход | Неполная: формулировка может отличаться |
| Как проверяется | Чтением условий | Прогоном на 200–300 прошлых случаях |
Свойство схемы отвечать одинаково на одинаковый вход — сегодня, завтра и через полгода. У правил она полная и проверяется чтением условия. У модели неполная: формулировка и иногда трактовка меняются от запуска к запуску. Для владельца это не философия, а деньги: там, где ответ становится обязательством — цена, скидка, срок, — воспроизводимость важнее гибкости, и модель в таком месте либо не ставится, либо работает через подтверждение человеком.
Теперь то же самое в деньгах. Сценарий А — процесс, где в шаблон попадает 60 % обращений: правила закрывают 55 %, модель — 78 %. Обратите внимание на разрыв в первой цифре: правила закрывают меньше, чем доля типовых обращений, потому что часть «типовых» приходит с опечаткой, лишним пробелом в артикуле или нестандартной формулировкой и в условие не попадает. Модель, наоборот, забирает часть нетиповых — те, где ответ всё-таки есть в базе знаний, просто вопрос задан не так, как ожидалось.
Арифметику стоит проверить: 3 000 × 45 % = 1 350 обращений остаётся людям при правилах, 1 350 × 5 = 6 750 минут, это 112,5 часа по 600 ₽. У модели остаётся 22 % — 660 обращений, 3 300 минут, 55 часов. Токены: 3 000 × 0,8 ₽ = 2 400 ₽. Доплата 350 000 − 150 000 = 200 000 ₽ делится на 22 100 ₽ разницы и даёт девять месяцев.
А теперь сценарий Б — тот же поток, но процесс приведён в порядок и в шаблон попадает 90 % обращений. Правила закрывают 82 %, модель — 88 %. У правил остаётся 540 обращений (45 часов, 27 000 ₽), чистая экономия 115 000 ₽ в месяц. У модели остаётся 360 обращений (30 часов, 18 000 ₽), чистая экономия 111 600 ₽. Правила выигрывают прямо по деньгам — при втрое меньшем вложении и вдвое меньшем сроке запуска.
Между сценариями А и Б изменилось одно число — доля типовых обращений, — и решение перевернулось. Поэтому вопрос «у нас 3 000 обращений, нам нужен ИИ?» бессмысленный: 3 000 одинаковых заявок закрываются правилами почти целиком, а 300 разнородных не закрываются ими совсем.
Стандартная таблица в презентации выглядит так: «сейчас 150 000 ₽ в месяц на людей — с агентом 33 000 ₽». Формально верно, но сравнение подменено: правильная база сравнения не ручная работа, а те же деньги при схеме на правилах, которая стоит втрое дешевле в разработке. Просите добавить в таблицу третью колонку. Если подрядчик отвечает, что правила «уже не актуальны», это ответ про его специализацию, а не про вашу экономику.
Где правила ломаются всегда
Есть четыре типа входа, на которых количество условий не помогает: сколько правил ни напиши, останется хвост, который в них не попадает. Общий признак один — вход не нормализован.
Данные, которые приходят полями и в предсказуемом виде: тип обращения выбран из списка, номер заказа лежит в отдельном поле, сумма — числом, город — из справочника. С таким входом работает обычное условие, и обращение обходится в ноль рублей. Ненормализованный вход — это одно текстовое поле, письмо, документ произвольной формы или запись разговора: правила там угадывают, модель разбирает. Нормализовать вход формой на сайте иногда дешевле, чем покупать модель, — это стоит проверить до сметы.
- Свободный текст клиента. «Здравствуйте, я вчера заказывала две штуки, одну хочу поменять на другой цвет, а вторую вернуть» — одно сообщение, два разных процесса, ни одного поля. Правило может искать ключевые слова, но «поменять» и «вернуть» в одном предложении оно уже не разведёт.
- Опечатки, сокращения и ошибки в данных. Артикул с лишним пробелом, город «СПБ», «спб» и «Санкт-Питербург», номер заказа из другой системы. Каждый вариант — отдельное условие, а список вариантов не заканчивается никогда.
- Документы разных форм. Счета и накладные от двадцати поставщиков, где одно и то же поле лежит в разных местах листа. Шаблонное распознавание требует настройки на каждую форму — подробности в разборе реальной точности распознавания.
- Речь с шумом. Звонок из цеха или из машины, перебивания, фоновая музыка. Пороговое правило по ключевой фразе здесь не срабатывает — что действительно работает, разбирали в материале о точности распознавания русской речи.
Проверить это на своём процессе можно тем же способом, что и долю типовых: в размеченной сотне обращений посмотреть, сколько из них пришло одним текстовым полем, документом или записью разговора. Если таких больше трети, спор окончен независимо от количества ветвлений: правила будут закрывать половину потока, а вторая половина всё равно пойдёт людям. Правильный вопрос в этом случае не «правила или модель», а «модель на входе и правила дальше» — об этом раздел про связку ниже.
Сравнение в две колонки по четырём строкам входа: «свободный текст клиента», «опечатки и сокращения», «документы разных форм», «речь с шумом». Левая колонка «правило»: для каждой строки короткий результат — «ищет ключевые слова, не разводит два намерения в одном сообщении», «нужен отдельный вариант на каждое написание», «настройка на каждую форму листа», «пороговая фраза не срабатывает». Правая колонка «модель»: «разбирает намерения», «приводит написание к одному виду», «находит поле по смыслу», «работает с расшифровкой». Снизу общая подпись: «общий признак — вход не нормализован». Чертёжный стиль, подписи по-русски.
Скрытая стоимость правил: когда дерево перестают понимать
У правил есть расход, которого нет в смете. Дерево условий растёт: каждая новая ситуация добавляет ветку, каждое исключение — ещё одну. Пока правил пятнадцать, изменение регламента занимает 1–3 часа: открыли, поправили, проверили. При ста двадцати правилах то же изменение занимает два дня и совещание — не потому, что работа сложнее, а потому что никто не может сказать, что сломается.
Момент, когда это произошло, обычно пропускают. Признаки видны раньше, чем последствия.
- Правки в сценарий вносит один человек, и в его отпуск изменения откладываются.
- Появились правила с именами вроде «временное исключение для крупных клиентов, не удалять».
- После каждой правки что-то ломается в другом месте, и это считается нормой.
- Никто не может ответить, что произойдёт при конкретном сочетании условий, — проверяют опытом на живом потоке.
- Есть ветки, про которые известно, что они не работают, но их не трогают из осторожности.
В деньгах это выглядит так. Строка «8 000 ₽ поддержки» в расчёте выше относится к свежему набору из полутора десятков правил. Через два года эксплуатации в том же процессе обычно живёт 80–120 условий, время на одно изменение вырастает с часа до дня, и та же строка становится 25 000–35 000 ₽ в месяц — при том же потоке и без единой новой функции. Это и есть настоящая цена схемы на правилах: не разработка, а стоимость изменения регламента через два года.
Два и больше признака — процесс уже стоит дороже, чем показывает смета поддержки. Что с этим делать по шагам и как за два часа собрать карту сценариев, разобрано в материале о том, когда сценарии становятся клубком. Важно, что переход на модель этот клубок не распутывает: он переносит его в базу знаний, где она так же зарастает противоречивыми документами. Сначала карта и чистка, потом смена схемы.
RPA и правила рядом с моделью, а не против неё
Самая частая ошибка выбора — считать это соревнованием. На практике зрелое решение состоит из трёх слоёв, и каждый делает то, что дешевле делает именно он: модель разбирает смысл, правила принимают решение, роботы и интеграции выполняют действия в системах.
- 1Модель — на входе
Разбирает свободный текст, письмо, документ или расшифровку звонка и приводит их к структуре: тип обращения, номер заказа, сумма, срок. Дальше по конвейеру идёт уже нормализованный вход, а не человеческая формулировка.
- 2Правила — в решении
Что делать с распознанным обращением, решает обычное условие: сумма до 5 000 ₽ и клиент в белом списке — оформляем сразу, иначе на подтверждение. Здесь важна воспроизводимость, а не гибкость, поэтому модель в этом слое не нужна.
- 3Интеграции и RPA — в действии
Если у системы есть API, действие выполняется через него — это всегда предпочтительнее. Если API нет или он закрыт, повторяемые действия в интерфейсе закрывает российский стек RPA: PIX RPA, Sherpa RPA, ROBIN, Primo RPA. Что выбрать в конкретном случае, разбирали в материале «RPA или интеграция по API».
Ключевое в этой схеме — что решение остаётся у правил. Соблазн отдать модели и разбор, и решение выглядит логично («она же всё равно читает обращение»), но именно в слое решения нужна воспроизводимость: скидка, срок и сумма обязаны считаться одинаково каждый раз и проверяться чтением условия. Модель на входе ошибётся в распознавании поля и это будет видно; модель в решении ошибётся в трактовке правила, и это увидят только на сверке.
Слой правил в такой связке чаще всего собирается на низкокодовой платформе с российской пропиской — Albato, ApiX-Drive или n8n на своём сервере. Где проходит граница между низким кодом и обычной разработкой, разбирали отдельно; там же про то, почему для сложной логики платформа перестаёт быть дешёвой.
Карта из трёх горизонтальных слоёв со стрелками сверху вниз. Верхний слой «вход»: узлы «письмо», «сообщение клиента», «документ поставщика», «расшифровка звонка». Средний верхний слой «модель: разбор смысла» с подписью на стрелке «тип обращения, номер заказа, сумма, срок» и пометкой «0,4–1,2 ₽ за обращение». Ниже слой «правила: решение» с примером условия «сумма до 5 000 ₽ и клиент в белом списке — сразу, иначе на подтверждение» и пометкой «0 ₽ за обращение». Нижний слой «действие»: два узла — «интеграция по API» (подписан «предпочтительно») и «RPA в интерфейсе» с подписью «PIX RPA, Sherpa RPA, ROBIN, Primo RPA». Стрелки к системам: CRM, 1С, почта. Чертёжный стиль, подписи по-русски.
Решающее дерево на одну страницу
Всё, что разобрано выше, сворачивается в пять вопросов подряд. Отвечать на них надо по порядку и на своих числах — доле типовых из размеченной сотни обращений и количеству ветвлений с листа. Первый отрицательный ответ и есть решение: дальше по дереву идти не нужно, потому что следующие вопросы уже не изменят исход.
- 1Можно ли убрать сами обращения? Половина вопросов «где мой заказ» снимается статусом в письме и кнопкой в личном кабинете. Если да — ни правила, ни модель не нужны, это самый дешёвый исход.
- 2Приходит ли вход в нормализованном виде — полями, а не свободным текстом и не документом произвольной формы? Если нет, модель нужна как минимум на входе, независимо от остального.
- 3Меньше ли ветвлений, чем 10–15, и больше ли 90 % обращений в шаблоне? Если да — берём правила: 120 000–180 000 ₽, три-четыре недели, ноль за обращение.
- 4Окупается ли доплата за модель? Считается как в сценарии А: разница в чистой экономии делится на разницу во вложениях. Девять месяцев — приемлемо, восемнадцать — нет.
- 5Есть ли кому смотреть выборку каждый месяц? Если нет ответственного с часами в календаре, модель ставить рано: без контура контроля она деградирует незаметно. Правила в этом смысле терпеливее.
Вертикальное дерево решений из пяти ромбов-вопросов сверху вниз: «можно убрать сами обращения?», «вход приходит полями?», «ветвлений меньше 15 и типовых больше 90 %?», «доплата за модель окупается быстрее 9 месяцев?», «есть ответственный за выборку?». От каждого ромба вправо отходит ветка «нет» или «да» с прямоугольным исходом: «кнопка и самообслуживание — 0 ₽ за обращение», «модель на входе, правила дальше», «правила: 120 000–180 000 ₽, 3–4 недели», «остаёмся на правилах», «сначала назначить ответственного». Нижний исход дерева — «заказной агент: 250 000–500 000 ₽, 6–10 недель». Чертёжный стиль, подписи по-русски.
Когда не нужно ни то ни другое
Оба варианта — расход. Есть ситуации, где правильный ответ не «правила» и не «модель», а «ничего из этого», и признать это дешевле, чем выбрать между двумя лишними тратами.
- Причина обращений устранима. Если 40 % вопросов — «где мой заказ», их снимает не автоматизация ответов, а ссылка на статус в письме о доставке. Автоматизировать ответ на вопрос, которого не должно быть, — самый дорогой способ решить проблему.
- Поток меньше 300 обращений в месяц. Весь ручной разбор — это 25 часов и 15 000 ₽, а поддержка правил стоит 8 000 ₽ в месяц ещё до разговора о модели. Разработка в 150 000 ₽ будет возвращаться больше двух лет.
- Процесс переписывают каждую неделю. Пока регламент не устоялся, правила придётся переделывать на каждой итерации, а модель нечем проверять: истории решений не накапливается. Сначала стабилизация, потом автоматизация — этот же вывод в материале о том, как выбрать первый процесс.
- Решение по каждому случаю принимает человек и записать эти правила невозможно. Тогда нет ни источника для правил, ни разметки для модели, и первым шагом идёт не проект, а описание того, как вообще принимается решение.
И последнее. Порядок, в котором стоит идти, обратный привычному: сначала убрать причину обращений, потом закрыть массовый поток правилами, а модель ставить на остаток, где вход грязный, а ветвлений много. При таком порядке модель обходится дешевле, чем если начать с неё: ей достаётся меньший объём и более понятная задача, а вы платите за токены и контроль только там, где без них действительно нельзя.
Модель покупают не за ум, а за грязный вход. Там, где вход чистый, дешевле обычное условие.
