ИИ-агент для малого бизнеса: практический план первого запуска

Начинать стоит не с выбора платформы, а с одного процесса, где ошибка агента дешева, а объём рутины измерим. Ниже — порядок действий: аудит задач, расчёт экономики, подготовка данных, пилот на 4–6 недель и критерии, когда проект пора останавливать.

Сергей Езепенко · 09.11.2026 · время чтения 16 мин

Какие задачи малого бизнеса агент закрывает уже сейчас

Практика показывает: агент окупается не на «стратегических» задачах, а на рутине, которая съедает время одного-двух сотрудников. Ниже пять сценариев, которые малый бизнес запускает без собственной команды разработки — на готовых платформах или с подрядчиком за 2–6 недель.

Первая линия поддержки. Типовые вопросы по заказам и доставке — «где мой заказ», «можно ли поменять адрес», «почему не пришло уведомление» — составляют, по разным оценкам, 60–75% обращений в поддержку интернет-магазина или сервиса. Агент подключается к CRM или учётной системе, находит заказ по номеру или телефону, сверяет статус и отвечает. Если данных нет или ситуация нетиповая (возврат, претензия, спор по оплате), он передаёт диалог оператору и прикладывает выжимку: номер заказа, что уже проверено, что сказал клиент. Оператор не тратит первые пять минут на выяснение контекста.

Обработка входящих заявок. Письма и формы приходят в свободной форме: «нужен расчёт на 200 штук до конца месяца, самовывоз». Агент извлекает из текста поля — позицию, количество, срок, способ доставки, контакт — и заносит в CRM или таблицу. Там, где раньше менеджер вручную перебивал данные из почты, появляется структурированная запись. Ошибки случаются, поэтому первый месяц стоит проверять выборку: агент уверенно размечает 80–90% заявок, остальные помечает как «требует проверки».

Внутренний помощник по базе знаний. Регламенты, инструкции, условия работы с поставщиками, шаблоны документов — всё это лежит в папках и находится медленно. Агент с доступом к базе отвечает сотруднику со ссылкой на источник. Для малого бизнеса это заметно снижает время адаптации нового сотрудника: вместо «спроси у Марины» — конкретный пункт регламента.

Сортировка и черновики ответов в почте и мессенджерах. Агент раскладывает входящие по темам (заказ, счёт, жалоба, партнёрство), готовит черновик ответа по шаблону и оставляет его на согласование. Сотрудник правит и отправляет. Экономия — не в полной замене человека, а в том, что на письмо уходит две минуты вместо десяти.

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

Пример из практики: небольшая оптовая компания (11 сотрудников) поставила агента на разбор почты и подготовку черновиков. Через месяц доля писем, уходящих без правки, составила около 40%, а среднее время ответа клиенту сократилось с 4 часов до 40 минут. Полной автоматизации не было — и не планировалось.

Чем агент отличается от чат-бота и от автоматизации

Три инструмента часто смешивают, хотя решают разные задачи и по-разному стоят в поддержке. Разница проявляется на первом же нестандартном запросе.

Чат-бот идёт по сценарию. У него есть дерево веток: кнопка «статус заказа» → ввод номера → ответ. Если клиент напишет «вчера оплатил, но письмо не пришло, посмотрите по почте», бот не поймёт: ветки под такой запрос нет. Сценарий можно расширять, но каждая новая ветка — это работа и риск, что реальный поток обращений пойдёт мимо. Бот предсказуем и дёшев, пока разговор укладывается в заготовленную логику.

Агент выбирает действие сам. Ему задают цель и набор инструментов, а последовательность шагов он определяет по ситуации. Вместо ветки «ввод номера заказа» он решает: найти клиента по email, затем по имени, затем проверить историю писем. Если один путь не сработал — пробует другой. Подробнее о том, как устроен такой цикл, — в материале что такое AI-агент и как он работает.

Агент вызывает инструменты. Это ключевое отличие. Он не просто отвечает текстом, а обращается к CRM, API, базе знаний, почте, календарю: создаёт сделку, ставит задачу, отправляет письмо, обновляет статус. Чат-бот обычно отвечает, автоматизация — выполняет заранее заданную последовательность, а агент комбинирует и то и другое под конкретный запрос.

Классическая автоматизация детерминирована. Сценарий «пришло письмо с темой X → создать сделку → назначить менеджера» работает одинаково всегда и почти не даёт сбоев. Его проще отладить, дешевле поддерживать, и результат воспроизводим. Если входные данные однородны — формы, фиксированные темы писем, выгрузки из систем — автоматизация выигрывает у агента по стоимости владения.

Агент нужен там, где входные данные неоднородны. Свободный текст, вложения, разные форматы от поставщиков, диалог с клиентом, который каждый раз строится по-новому. Там, где правило «если A, то B» не покрывает половину случаев, агент справляется лучше — но и стоит дороже: запросы к модели, тестирование, наблюдение за качеством.

Любой агент требует ограничений. Без них он превращается в источник проблем. Минимальный набор:

1. Лимиты — сколько действий и запросов к модели агент может сделать за диалог или за сутки, чтобы счёт не вырос в разы из-за зацикливания.
2. Права — доступ только к тем системам и полям, которые нужны для задачи; отправка писем и изменение заказов — либо после подтверждения, либо в ограниченном объёме.
3. Логи — каждое действие с входными данными и результатом, чтобы разобрать инцидент и понять, почему агент ответил именно так.

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

Как выбрать первый процесс: матрица приоритетов

Первый процесс выбирают не по тому, что интересно автоматизировать, а по тому, что даёт предсказуемый результат при минимальном риске. Практичная рамка — четыре оценки по каждому кандидату: объём, цена ошибки, качество данных, юридическая и финансовая безопасность. Процесс, который проходит по всем четырём, идёт в пилот; остальные откладываются, даже если кажутся перспективными.

Объём. Считайте не «сколько это занимает времени», а сколько операций в неделю или месяц проходит через процесс. Обращения в поддержку, заявки с сайта, счета на оплату, заявки на возврат, запросы на подбор товара, входящие письма на общий ящик. Если процесс даёт меньше 100 операций в месяц, экономия от автоматизации будет меньше стоимости поддержки агента — такой процесс не окупится, даже если сделать его идеально. Порог в 100 операций в месяц — нижняя граница; комфортно начинать с 300–500.

Цена ошибки. Для каждой операции оцените, что происходит при сбое. Три сценария: агент ошибся, но клиент поправил и всё обошлось; агент ошибся, и это стоит денег (возврат, компенсация, повторная доставка); агент ошибся, и это стоит клиента или репутации. Первый сценарий допустим на пилоте, второй — только с ручной проверкой на выходе, третий — не для первого запуска. Считайте не «в среднем», а по худшему реалистичному случаю: если ошибка в 1% случаев приводит к возврату на 5 000 рублей, при 500 операциях в месяц это 25 000 рублей риска — эту сумму нужно заложить в расчёт окупаемости.

Данные в машиночитаемом виде. Агент работает с текстом и структурированными данными. Если знания о процессе живут в голове менеджера, в переписке в мессенджере или в сканах договоров без распознавания, сначала придётся собрать базу: регламент, прайс, частые вопросы и ответы, таблицу статусов заказа. Это отдельный этап на 2–4 недели, и его нужно ставить в план до разработки, а не после. Хороший признак — процесс уже частично описан: есть CRM с полями, шаблоны писем, инструкция для стажёра.

Юридические и финансовые риски. Исключайте из первого пилота всё, что связано с платежами, налоговой отчётностью, кадровыми решениями, персональными данными в чувствительных категориях и договорами с юридическими последствиями. Агент может готовить черновик, но решение и подпись остаются за человеком. Это не навсегда — это правило первого запуска, когда вы ещё не знаете, как система ведёт себя на ваших данных.

Простой способ свести оценки — таблица на 5–7 процессов, где по каждому столбцу ставится балл от 1 до 3, а строки сортируются по сумме. Процесс с максимальным баллом и объёмом от 100 операций в месяц идёт в пилот. Пример: у интернет-магазина на 400 заказов в неделю главные кандидаты — ответы на вопросы «где мой заказ» (высокий объём, низкая цена ошибки, данные в CRM есть) и оформление возвратов (объём ниже, цена ошибки в деньгах). Первым запускают статусы заказов, возвраты — вторым, с обязательной проверкой оператором. Подробнее о том, как устроен агент и какие роли он закрывает, — в материале что такое AI-агент и как он работает.

Экономика проекта: что считать до старта

Пилот ИИ-агента почти всегда окупается, если считать правильно, и почти никогда — если считать «на глаз». До старта нужны четыре цифры: стоимость рутины, расходы на модель, стоимость разработки и поддержки, срок возврата. Считать лучше в одном файле, чтобы через месяц можно было сравнить план с фактом.

Стоимость рутины. Возьмите роль, которая больше всего занята повторяемыми операциями, и посчитайте полную стоимость часа: оклад с налогами и взносами, делённый на фактические рабочие часы. Для менеджера с зарплатой 60 000 рублей на руки это порядка 700–900 рублей в час с учётом взносов. Дальше — доля повторяемых операций в его дне. Если менеджер тратит 40% времени на однотипные ответы, при 160 рабочих часах это 64 часа в месяц, то есть 45–58 тыс. рублей. Это верхняя граница экономии: агент редко забирает все 100% рутины, реалистично — 60–80%, остальное уходит на проверку и исключения.

Расходы на токены. Стоимость запроса зависит от длины контекста и числа шагов. Короткий ответ по шаблону — это тысячи токенов, обработка письма с историей переписки и поиском по базе знаний — десятки тысяч. При 500 обращениях в месяц и средней цене запроса 1–3 рубля выходит 500–1 500 рублей на модель; если агент делает 3–4 шага на обращение, умножьте на это число. Стоимость токенов падает, но не планируйте на это бюджет: считайте по текущим тарифам с запасом 30–50% на рост объёма.

Разработка и поддержка. Пилот под один процесс с интеграцией в CRM или почту — от 150 до 600 тыс. рублей в зависимости от сложности интеграций и объёма базы знаний. Верхняя граница — когда нужны нестандартные коннекторы, разграничение доступа и логирование для аудита. Поддержка после запуска: правки промптов, обновление базы знаний, разбор ошибок — в среднем 10–20% от стоимости разработки в месяц, то есть 15–120 тыс. рублей. Закладывайте это в расчёт сразу: пилот без поддержки деградирует за 2–3 месяца, потому что меняются продукты, цены и типовые вопросы.

Подписки и инфраструктура. Доступ к LLM, хостинг, векторная база, мониторинг — порядка 5–30 тыс. рублей в месяц для малого бизнеса. Нижняя граница — облачная модель по API и минимальная инфраструктура, верхняя — собственные сервисы, шифрование и резервные каналы.

Срок окупаемости. Считайте по сэкономленным часам, а не по ожидаемому росту выручки. Формула: (разработка + поддержка за 6 месяцев + инфраструктура за 6 месяцев) / месячная экономия на часах. Если пилот стоит 300 тыс., поддержка 30 тыс. в месяц, инфраструктура 10 тыс., а экономия — 50 тыс. рублей в месяц, окупаемость около 8–9 месяцев. Если больше 12 — либо процесс выбран слишком мелкий, либо экономия посчитана оптимистично. Пример: сервисный центр на 800 обращений в месяц заменил агента на статусах заявок, экономия 55 тыс. рублей в месяц при затратах на пилот 280 тыс. — выход на окупаемость за 6 месяцев с учётом поддержки. О том, как менялись подходы и расценки за последний год, — в статье AI-агенты для малого бизнеса: что изменилось в 2026 году.

Данные и доступы: что подготовить до разработки

Первый проект с ИИ-агентом чаще спотыкается не на модели, а на данных. До того как разработчик откроет редактор, у бизнеса должна быть папка с материалами, по которым агент будет учиться и проверяться. Без этого сроки растягиваются: сначала две недели уходят на «а пришлите примеры переписки», потом ещё неделя — на уточнение, что считается правильным ответом.

Начните с выгрузки реальных обращений. Нужно 200–500 диалогов за последние 3–6 месяцев — из почты, мессенджеров, CRM, формы на сайте. Не причёсывайте их: пусть будут и грубые клиенты, и опечатки, и обращения не по теме. По этой выборке считают, какую долю запросов агент закроет сам, а где понадобится передача человеку. Если взять 20 «красивых» примеров, метрики будут завышены, а на проде агент столкнётся с тем, чего не видел.

Дальше — справочники. Агенту нужны структурированные ответы на типовые вопросы: номенклатура товаров или услуг с ценами, тарифы и условия, статусы заказов и заявок, правила возврата и гарантии, график работы и зоны доставки. Формат — таблица или выгрузка из учётной системы, но с однозначными формулировками. Если в прайсе написано «от 5 000», а менеджер в переписке называет 7 200, агент будет путаться. Справочники стоит один раз вычитать и назначить ответственного, который обновляет их при изменениях.

Доступы делят по принципу минимальной необходимости. Агент читает каталог и базу знаний, создаёт заявки в CRM, но не должен видеть зарплаты, договоры с поставщиками, чужие клиентские базы. Технически это отдельная учётная запись с ограниченными правами и API-ключом, а не логин руководителя. Если агент работает с оплатой или персональными данными, доступ к платёжным данным лучше не давать вовсе — только ссылку на платёжную страницу.

Журнал действий заводят сразу, а не «потом прикрутим». В нём фиксируют: время запроса, текст обращения, какой инструмент вызвал агент, что вернула система, итоговый ответ, был ли перевод на оператора. Хранение входных запросов нужно и для разбора ошибок, и для подтверждения качества. Срок хранения определите заранее — например, 90 дней для рабочих логов и до года для обезличенной статистики.

Персональные данные требуют отдельного внимания. По 152-ФЗ обращения клиентов с именем, телефоном, адресом — это персональные данные, и их обработка должна быть описана в политике, а согласие — получено там, где оно нужно. Если модель работает через зарубежный API, проверьте, не уходит ли туда лишнее: часто достаточно маскировать телефон и почту перед отправкой в модель. Юрист и ответственный за ИБ должны посмотреть схему потоков данных до запуска, а не после первой жалобы.

Небольшой пример: у сервисного бизнеса агент отвечал на вопросы о сроках ремонта. В справочник залили прайс, но забыли таблицу статусов заявок — агент уверенно говорил «ваш заказ готов», хотя это было не так. После добавления статусов и правила «если статус не найден — переводить на менеджера» доля ошибок упала с 18% до 4% на той же выборке.

Выбор технологии: облако, API или готовая платформа

Способ сборки агента определяет не только бюджет, но и то, насколько легко будет что-то поменять через полгода. Есть три практических варианта, и выбор между ними — это выбор между скоростью запуска и степенью контроля.

Готовые платформы — конструкторы чат-ботов и агентов с шаблонами под поддержку, продажи, запись на услуги. Плюс: запуск за дни, не нужен разработчик в штате, интеграции с популярными CRM и мессенджерами уже есть. Минус: логика ограничена сценариями платформы. Если понадобится нестандартная проверка заказа или расчёт стоимости по сложной формуле, придётся либо подстраиваться, либо уходить. Ещё один риск — тарификация по диалогам: при росте обращений счёт растёт непропорционально.

API моделей даёт полный контроль. Вы сами описываете системный промпт, набор инструментов, правила передачи оператору, храните логи у себя. Это подходит, когда процессы специфичны: например, агент должен сверять заявку с остатками на складе и считать доставку по тарифной сетке. Цена контроля — нужен разработчик или подрядчик на поддержке. Не разовая сборка, а сопровождение: обновления моделей, правки промптов, разбор инцидентов. По опыту небольших проектов это от 10 до 30 часов в месяц после запуска.

Локальные модели разворачивают на своём сервере, когда требования к данным жёсткие: медицинские сведения, работа с документами ограниченного доступа, запрет на передачу информации во внешние сервисы. Такое решение дороже в запуске — нужна инфраструктура, специалист по ML, регулярные обновления. Для малого бизнеса это оправдано редко, чаще хватает облачного API с маскированием чувствительных полей.

Для первого проекта достаточно одной модели и двух-трёх инструментов. Инструмент — это функция, которую агент может вызвать: найти заказ по номеру, проверить наличие товара, создать заявку. Не пытайтесь сразу подключить всё: каждая интеграция — это отдельная точка отказа и отдельный сценарий для тестирования. Начните с базы знаний и одного действия, например создания заявки, и посмотрите, как агент справляется на реальном потоке.

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

Практическое правило выбора: если задача укладывается в шаблон платформы и бюджет ограничен — берите платформу; если процесс уникален и есть кому поддерживать код — API; если данные нельзя выпускать за периметр — локальная модель. Решение фиксируйте в коротком документе: что выбрали, почему, какие ограничения приняли. Через полгода это сэкономит спор «а почему мы так сделали».

Пилот за 4–6 недель: этапы и метрики

Пилот нужен не для того, чтобы убедиться, что технология работает. Она работает. Пилот нужен, чтобы понять, окупается ли она на вашем процессе, с вашими клиентами и вашими сотрудниками. Поэтому горизонт в 4–6 недель — это не срок внедрения, а срок проверки гипотезы. Если за это время не удалось получить измеримый результат, дальше вкладываться рано.

Неделя 1. Процесс, метрики, выборка. До первой строчки кода или настройки промпта выберите один процесс, а не «всю поддержку». Хороший кандидат: обработка входящих заявок с сайта, ответы на типовые вопросы по наличию и доставке, первичная квалификация лидов, разбор обращений в мессенджере. Плохой кандидат: жалобы, возвраты, всё, где есть конфликт или деньги. Опишите процесс в виде регламента на 1–2 страницы: кто владелец, какие входы, какие выходы, что считается успешным ответом, где точка эскалации на человека. Соберите тестовую выборку обращений — минимум 150–200 реальных диалогов за последние 2–3 месяца, включая неудобные. Одновременно зафиксируйте базовую линию: сколько сейчас стоит обработка одного обращения в часах сотрудника, какая доля уходит на повторные уточнения, сколько в среднем длится ответ.

Недели 2–3. Прототип с ручной проверкой. Соберите работающий прототип на выбранной выборке. На этом этапе агент не общается с клиентами — он готовит черновики ответов, а сотрудник проверяет каждый. Задача — не скорость, а понимание, где агент ошибается и почему. Ведите простой журнал: номер диалога, ответ агента, правка сотрудника, тип ошибки (не понял вопрос, взял не тот источник, придумал факт, не предложил эскалацию). К концу второй недели у вас должно быть 30–50 размеченных ошибок — это и есть материал для доработки базы знаний и инструкций.

Недели 4–5. Теневой режим. Агент работает параллельно с сотрудником на живом потоке, но клиент видит ответ человека. Сравнивайте ответы: совпадают, расходятся по формулировке, расходятся по сути. Здесь вылезают краевые случаи, которых не было в выборке, и становится видно реальную нагрузку на проверяющего.

Метрики. Считайте четыре показателя: точность (доля ответов, принятых без правки по сути), доля эскалаций (сколько обращений агент передал человеку — и сколько передал бы зря), время ответа (от поступления до отправки), стоимость обработки одного обращения с учётом токенов, подписки и часов на проверку. Критерий успеха задайте числом до старта пилота: например, «точность не ниже 85%, доля лишних эскалаций не выше 10%, стоимость обращения ниже текущей на 30%». Если число не задано заранее, после пилота начнётся подгонка результата под желание продолжать.

Типичные ошибки и когда проект стоит остановить

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

Вторая ошибка — отсутствие эскалации. Агент отвечает там, где должен молчать: клиент пишет про брак, угрожает судом, спрашивает про индивидуальные условия — а бот бодро продолжает диалог по скрипту. Это стоит дороже, чем молчащий бот. Задайте явные стоп-темы: претензии, возвраты, юридические вопросы, всё, что связано с деньгами сверх прайса. Правило простое: если агент не уверен, он передаёт диалог человеку и сообщает об этом клиенту без имитации компетентности.

Третья ошибка — экономия на тестах. 50 диалогов показывают, что агент работает на среднем случае, и ничего не говорят о краевых. На 50 обращениях вы не увидите опечаток, голосовых, смеси двух вопросов в одном сообщении, сарказма, клиента, который пишет в три часа ночи. Для приёмки нужно 150–200 диалогов, из них минимум треть — проблемные.

Пример из практики: компания запустила агента на приём заявок с сайта, тестировала на 40 «чистых» обращениях, получила точность 92% и вывела в прод. На живом потоке выяснилось, что около 15% заявок содержат вложения — сканы и фото, — а агент их не читает и отвечает по тексту письма, теряя суть. Две недели ушло на то, чтобы это заметить, потому что метрику по вложениям никто не заложил.

Когда проект стоит остановить:

1. Точность ниже 80% после двух циклов доработок. Если после правки базы знаний и инструкций агент всё ещё ошибается в каждом пятом ответе, вы не экономите время сотрудника, а добавляете ему проверку. Доработки на этом уровне обычно упираются не в модель, а в качество исходных данных — и это уже другой проект.
2. Экономия часов не покрывает поддержку. Считайте полную стоимость: подписка, токены, часы на проверку ответов, часы на обновление базы знаний, время владельца процесса. Если суммарно выходит больше, чем сотрудник тратил раньше, — останавливайте. Агент имеет смысл, когда снимает нагрузку, а не перекладывает её в другое место.

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

Автор: Сергей Езепенко, основатель «Системы Поток». Работаю с клиентами с 2018 года, 20 запущенных проектов: стройка, медицина, юруслуги, недвижимость, онлайн-школы.