Услуги на базе ИИ-агентов, которые агентство продаст в 2026
Шесть автоматизаций на ИИ-агентах, которые я использую в двух реальных бизнесах, переупакованные в продаваемые пункты услуг для агентства: составление промо-постов к событиям и в соцсетях, классификация комментариев и входящих сообщений, еженедельная операционная сводка, черновики рассылки и надёжное подтверждение бронирований. Для каждого пункта указано, кому он подходит, примерный уровень сложности сборки и чего не стоит обещать. Механика ценообразования, скоупинг и продуктизация разобраны в других статьях — здесь именно меню, написанное так, чтобы агентство могло превратить его в страницу услуг на этой же неделе.
Каждую среду. 28 400+ читателей. Никакой воды.
✓ Проверьте почту — нажмите ссылку подтверждения, чтобы завершить подписку.
✓ Вы подписаны!
✓ Вы уже в списке.
[Взгляд оператора] Я запускаю 30+ ИИ-агентов в продакшене между Pickleland (крытым комплексом для пиклбола на девять кортов в Пфлагервилле, Техас) и моим консалтинговым брендом. После каждого выступления агентства задают мне один и тот же вопрос — не «как работают агенты», а «что мне реально поставить в меню услуг». Вот это меню: шесть пунктов, взятых прямо из автоматизаций, которые я сам эксплуатирую, каждый сформулирован так, как вы бы сформулировали его в предложении клиенту: что это, кому подходит, какой уровень сборки и чего не стоит обещать.
Это не статья про то, как автоматизировать свой бизнес — её я уже написал здесь. Это и не статья про механику ценообразования — это структура «фиксированная плата за сборку плюс ретейнер» из сколько брать с клиентов. Это уровень над обоими: реальные названия услуг, очерченные достаточно узко, чтобы потенциальный клиент мог сказать «да» одной из них без того, чтобы вы сначала объясняли, что такое ИИ-агент.
Оглавление
Открыть Оглавление
- Почему «услуги ИИ-агентов» как категория не продаются
- Меню услуг
- Сборка меню в пакеты, а не хаос по отдельным позициям
- Стек за всеми шестью
- Часто задаваемые вопросы
- Сколько из этого агентству стоит предлагать при запуске?
- Нужен ли для этого разработчик в штате?
- Какую самую большую ошибку допускают агентства при продаже этого меню?
- Должен ли у каждого из них быть этап проверки человеком?
- Как понять, что потенциальный клиент действительно готов купить один из этих пунктов?
Почему «услуги ИИ-агентов» как категория не продаются
«Мы строим ИИ-агентов» — это не услуга. Это заявление о возможностях, а заявления о возможностях никто не покупает — покупают что-то с названием и определённым результатом. Сравните «мы строим ИИ-агентов для локального бизнеса» с «мы автоматически составляем ваши промо-посты к событиям и каждое воскресенье кладём их в очередь на утверждение». Второе владелец бизнеса способен представить работающим в собственном аккаунте уже к пятнице.
Решение — та же дисциплина, что я описываю в как упаковать экспертизу в продуктизированную услугу: фиксированный объём, название, которое клиент использовал бы в разговоре, и чёткая граница вокруг того, что входит. Всё ниже написано по этому стандарту. Если нужен формат документа, чтобы превратить любой из этих пунктов в подписанный объём работ перед тем как назвать цену, — это как написать документ об объёме работ для ИИ-агента.
Меню услуг
Шесть автоматизаций, каждую из которых я сначала эксплуатирую сам, прежде чем вообще продавать этот паттерн.
1. Составление промо к событиям и в соцсетях
Что это: агент по расписанию, который с фиксированной периодичностью проверяет предстоящие события или предложения клиента — мой запускается каждое воскресенье на предстоящую неделю — и составляет промо-посты, подходящие площадке или бренду, в очередь на утверждение. Ничего не публикуется без того, чтобы человек нажал «одобрить».
Кому подходит: любому клиенту с повторяющимся календарём того, что нужно продвигать, — события, занятия, еженедельные акции, дни открытых дверей. Спортзалы, площадки, рестораны, локальный сервисный бизнес. Не подходит клиенту с нерегулярным, разовым календарём запусков — там нет повторяющегося ритма, к которому агент мог бы привязаться.
Уровень сборки: агент с одним потоком — один триггер (часы), один источник данных (календарь или система бронирования клиента), один результат (черновики в очереди). Это нижняя граница уровня с одним потоком в моей схеме ценообразования.
Чего не стоит обещать: не продавайте «ведение соцсетей». Вы продаёте генерацию черновиков, а не стратегию, не работу с сообществом, не рекламный бюджет. Пропишите это прямо в документе об объёме работ, потому что формулировка «соцсети» сама приглашает к расползанию объёма в момент, когда клиент захочет, чтобы вы ещё и отвечали на комментарии — а это отдельный пункт, см. ниже.
2. Классификация комментариев и входящих сообщений с черновиками ответов
Что это: агент, запускаемый по вебхуку при поступлении нового комментария или входящего сообщения; он классифицирует намерение (вопрос, жалоба, комплимент, спам — либо вопрос, жалоба, бронирование, другое, в зависимости от канала) и составляет ответ для всего, что выше порога уверенности. Комплименты логируются, спам подавляется, всё остальное попадает в очередь на проверку человеком.
Кому подходит: любому клиенту с достаточным объёмом входящих сообщений, чтобы человек занимался ручной сортировкой, — страница в Facebook с активными комментариями, общий почтовый ящик, форма обратной связи, где раньше кто-то читал каждое сообщение с нуля. Не подходит для аккаунтов с действительно низким объёмом — накладные расходы на очередь проверки не окупаются при меньше чем горстке сообщений в неделю.
Уровень сборки: многошаговый агент, если охватывает больше одного канала (например, комментарии Facebook и почту) или требует второго прохода классификации; один поток, если это один канал с одним действием на выходе. Оценивайте уровень по числу каналов, а не по объёму сообщений — объём меняет стоимость эксплуатации, а не стоимость сборки.
Чего не стоит обещать: это не заменяет человека, который реально общается с клиентами. Агент снимает лёгкие 80% — вопросы в духе FAQ и очевидный спам, — чтобы тот, кто проверяет очередь, тратил время на сообщения, требующие суждения, а не на остальные. Скажите это прямо в питче. Клиент, который решил, что покупает замену службы поддержки, разочаруется уже ко второму месяцу.
3. Еженедельная операционная сводка
Что это: агент по расписанию, который забирает горстку операционных показателей — бронирования, процент отмен, загрузку, какая бы ни была ключевая метрика клиента — и любые отмеченные аномалии, затем оформляет сводку из пяти пунктов, доставляемую туда, где владелец её реально читает (Notion, почта, Slack), каждое утро понедельника.
Кому подходит: любому владельцу-оператору, который сейчас получает эту картину, логинясь в два-три дашборда и считая всё сам, — или не получает вовсе, потому что ни у кого нет времени её собрать. Это сильная первая продажа для клиента, скептически настроенного к ИИ-агентам в целом: низкий риск, ничто не действует от его имени, и ценность видна уже на первой неделе.
Уровень сборки: один поток при условии, что источники данных — это системы, из которых агент может читать напрямую (API платформы бронирования, выгрузка из таблицы, аккаунт аналитики). Добавьте уровень, если данные клиента живут где-то без чистого доступа на чтение и агенту нужен кастомный скрапинг или ручная обработка выгрузок.
Чего не стоит обещать: сводка сообщает, а не решает. Не давайте клиенту читать «обнаружение аномалий» как «агент скажет мне, почему упала выручка». Он отмечает, что число вышло за пределы нормального диапазона. Почему — по-прежнему работа владельца, просто с информацией из сводки, которая довела его до этого быстрее.
4. Черновики рассылки
Что это: агент, который составляет регулярную рассылку клиента прямо как черновик в его почтовой платформе, опираясь на любой исходный материал, который клиент предоставит (недавние посты, предстоящие события, постоянно ведущийся документ с заметками), готовый к редактированию человеком и отправке.
Кому подходит: любому клиенту, уже взявшему на себя обязательство регулярно отправлять рассылку, но делающему это нестабильно, потому что проблема чистого листа съедает время. Не подходит клиенту, который ещё не решил, зачем ему рассылка вообще, — составление черновика ускоряет существующую привычку, а не создаёт редакторское суждение с нуля.
Уровень сборки: один поток, низкая сложность — при условии, что агент пишет прямо в нативный статус черновика платформы (большинство современных сервисов рассылок это позволяют), а не требует ручной передачи копированием-вставкой. Если приходится взаимодействовать с сервисом без пригодного API, это дополнительная интеграционная работа, поднимающая уровень.
Чего не стоит обещать: это составляет черновик; человек по-прежнему редактирует и отправляет каждый раз сам. Не позиционируйте это как «мы будем вести вашу рассылку за вас» — это подразумевает контроль над решениями по стратегии и периодичности, которые агент не принимает. Позиционируйте как «рассылка выходит по расписанию, потому что написание первого черновика перестаёт быть узким местом».
5. Надёжность подтверждения брони и последующих напоминаний
Что это: агент, который гарантирует, что каждая бронь получит подтверждение и, где уместно, напоминание по расписанию. Человек, вручную рассылающий подтверждения, достаточно быстр в обычный день; ценность здесь в том, что у агента не бывает плохих дней и он никогда не забывает подтверждение.
Кому подходит: любому клиенту, чей процесс бронирования или приёма сейчас зависит от того, вспомнит ли кто-то отправить подтверждение вручную. Сервисный бизнес, бизнес по записи, любой случай, где пропущенное подтверждение означает неявку или потерянного клиента, решившего, что бронь не прошла.
Уровень сборки: многошаговый — триггер (новая бронь), чтение (данные клиента и брони), запись (подтверждение и/или запланированное напоминание) и обычно уведомление персоналу. Это уверенно попадает в многошаговый уровень с интеграциями, потому что затрагивает живую систему бронирования или CRM, а не просто составляет текст на проверку.
Чего не стоит обещать: не продавайте это на экономии времени — ручная отправка подтверждающего письма занимает тридцать секунд, так что расчёт окупаемости на одном времени слаб. Продавайте на сценарии сбоя, который агент устраняет: человек в плохой день забывает подтверждение, и клиент уходит. У агента не бывает плохих дней. Это и есть настоящий аргумент продажи, и он честный, потому что это тот же аргумент страховой ценности, которым я оправдываю сборку этого паттерна для собственного бизнеса.
Сборка меню в пакеты, а не хаос по отдельным позициям
Шесть пунктов — это меню, а не шесть отдельных разговоров о продаже. Я бы сгруппировал их в два-три пакета, а не питчил каждый по отдельности:
- Стартовый пакет: выберите самую проблемную задачу, которую клиент уже делает плохо или не делает вовсе — обычно это еженедельная сводка или составление промо, потому что оба низкорисковые и ценность видна быстро.
- Пакет роста: добавьте агента классификации и ответов, как только стартовый пакет заработал доверие. Здесь клиент начинает чувствовать накопительный эффект, потому что привычка к очереди на проверку из первого пакета переносится.
- Пакет надёжности: агент подтверждения брони, продаваемый отдельно, как только у клиента есть настоящая система бронирования или приёма, которую стоит защищать, — часто это самая ценная и наименее эффектная продажа, и она заходит лучше после того, как клиент уже видел, как агент надёжно работает на чём-то менее рискованном.
Назначайте цену на каждый пакет так, как я описываю в сколько брать с клиентов за сборку ИИ-агентов: фиксированная плата за сборку по пакету плюс ретейнер на обслуживание, а не почасовая оценка. И прежде чем строить что-либо для клиента, проведите ту же четырёхчастную проверку окупаемости — ручные затраты, стоимость сборки, стоимость эксплуатации, налог на обслуживание, — которой я пользуюсь, чтобы решить, строить ли это для себя, изложенную в схеме ROI. Если пункт этого меню не проходит разумный срок окупаемости для конкретного клиента, не продавайте его этому клиенту — продайте тот, который проходит.
Стек за всеми шестью
Все шесть работают на одном и том же лёгком стеке, который я использую в собственных бизнесах: Claude как модельный слой, Cloudflare Workers для триггеров по расписанию и вебхуков, и Airtable как основа очередей на проверку и состояния задач, в которую даже не-разработчики реально могут заглянуть. Ничего из этого не требует корпоративного софта или большой команды для доставки — отчасти поэтому экономика работает для агентства, продающего малому и среднему бизнесу, а не корпоративным клиентам.
Часто задаваемые вопросы
Сколько из этого агентству стоит предлагать при запуске?
Два-три, не все шесть. Выберите те, что подходят уже имеющимся клиентам — если ваш портфель в основном состоит из локального сервисного бизнеса с активными профилями в соцсетях, начните с составления промо и классификации комментариев. Добавить остальное после хорошей поставки первых двух проще, чем запустить все шесть и не доставить нормально ни одну.
Нужен ли для этого разработчик в штате?
Уровень с одним потоком (составление промо, еженедельная сводка, черновики рассылки) может собрать человек, свободно чувствующий себя со скриптами и документацией API, а не старший инженер. Многошаговый уровень (классификация по нескольким каналам, подтверждения брони) выигрывает от настоящего опыта разработки — прежде всего потому, что надёжность в продакшене для системы, затрагивающей живую систему бронирования, важнее, чем для того, что просто составляет текст на проверку.
Какую самую большую ошибку допускают агентства при продаже этого меню?
Продают возможность вместо результата — «услуги ИИ-агентов» вместо «ваши промо к событиям составлены и ждут вашего одобрения каждое воскресное утро». Второе — услуга, которую клиент способен себе представить. Первое — встреча по продажам.
Должен ли у каждого из них быть этап проверки человеком?
У первых четырёх — да, все они выдают черновики, которые должен одобрить человек. Агент подтверждения брони — исключение, потому что подтверждения низкорисковые и достаточно чувствительны ко времени, чтобы очередь на проверку свела на нет саму суть. Это разделение — какие результаты требуют проверки, а какие нет — стоит прописать явно в каждом документе об объёме работ, подробнее об этом в как написать документ об объёме работ для ИИ-агента.
Как понять, что потенциальный клиент действительно готов купить один из этих пунктов?
Он уже выполняет базовую задачу вручную и может конкретно описать её вам — что её запускает, сколько примерно времени занимает, как выглядит хороший результат. Потенциальный клиент, который не может описать свой текущий процесс, ещё не готов к агенту — он готов к разговору о том, чтобы сначала определить процесс, а это отдельный, меньший проект.
Каждую среду. 28 400+ читателей. Никакой воды.
✓ Проверьте почту — нажмите ссылку подтверждения, чтобы завершить подписку.
✓ Вы подписаны!
✓ Вы уже в списке.
Похожие статьи
ИИ-агенты для SaaS: что автоматизировать первым
Фреймворк уровней и ROI для решений об ИИ-агентах, применённый к SaaS-процессам, которые действительно стоит автоматизировать в первую очередь.
AI AgentsАгенты Claude против Zapier: что и когда использую я
Zapier переносит данные между приложениями по правилу. Агент Claude принимает решения по неструктурированным данным. Вот как я выбираю между ними.
AI AgentsКак написать документ об объёме ИИ-агента
Документ об объёме превращает расплывчатый запрос на ИИ-агента в фиксированную смету: что в нём нужно, шаблон и промпт для черновика.
Получайте ИИ-руководство на почту
Каждую среду. 28 400+ читателей. Никакой воды.
Проверьте почту.
Мы отправили письмо для подтверждения — нажмите на ссылку, чтобы завершить подписку. Проверьте папку «Спам», если не видите его в течение минуты.
Вы подписаны.
Добро пожаловать — следующий выпуск скоро придёт на вашу почту.
Вы уже в списке — ждите выпуск каждую среду.