Автоматизация отчётности агентства: делаем SEO-эксперта проактивным

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

Реактивный vs проактивный

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

Устройство действия по расписанию

Настройка нового действия — это одни и те же несколько полей вне зависимости от задачи: название, тип триггера, что сделать с результатом, cron-расписание, сам текст задания, куда доставить и от чьего имени выполнять. Вот так настроен реальный еженедельный отчёт — и он берёт данные сразу из двух источников, а не из одного (идентификаторы клиента ниже — заглушки, подставьте настоящие домен, ID счётчика и chat id):

Основную работу делает промпт. Обратите внимание — он не заканчивается фразой «сформируй PDF и отправь в Telegram»: это уже задано полем «Что сделать» выше, повторять это в промпте — просто шум:

Задача: Провести еженедельный сводный мониторинг эффективности сайта в
поиске и трафика.
База знаний: example-client — возьми из неё формат отчёта и стиль
комментариев клиента.
Инструменты: Используй get_gsc_data для сайта: domain:example-client.com
и get_yandex_metrika_data для счётчика ID: 12345678
Параметры сбора: Период — последние 7 дней. Из GSC — разрезы (dimensions):
['query', 'page']. Из Метрики — метрики: визиты, отказы, глубина
просмотра; группировка — по источникам трафика.
Требования: Сравни оба источника с предыдущей неделей. Составь
расхождения по источникам — сопоставь органический трафик из GSC с
данными по источникам из Метрики и укажи, где цифры расходятся. Выдели
три запроса с наибольшим падением позиций и источники с ростом отказов
больше чем на 10 процентных пунктов.

Почему один сводный отчёт эффективнее двух отдельных

Очевидная альтернатива — два действия по расписанию, одно для GSC, одно для Метрики, каждое со своим отчётом. Это работает, но строго хуже: в каждом запуске у агента в контексте только один датасет, поэтому сверить один источник с другим он не может, а клиенту приходится сводить два PDF вручную. Дайте одному запуску оба инструмента — и оба набора данных окажутся в одном контексте: требование «составь расхождения по источникам» из промпта выше работает именно потому, что агент видит цифры GSC и Метрики одновременно, пока пишет отчёт. Меньше действий по расписанию для поддержки — приятный побочный эффект; настоящая причина — в том, что для самого сравнения нужны оба датасета в одном месте.

Почему в промпте нужно называть инструмент и ID ресурса явно

От чьего имени выполняется задача и почему это важно

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

Частые ошибки при настройке отчётов по расписанию

• Не указан идентификатор ресурса. «Наш сайт» — не идентификатор: у GSC это домен или URL-префикс, у Метрики — ID счётчика. Указывайте настоящий.
• Расписание не совпадает с готовностью данных. Отчёт утром в воскресенье «за последние 7 дней» требует, чтобы расписание и окно данных реально совпадали — проверьте, какая задержка отчётности у источника на самом деле.
• Не протестировали вручную заранее. Прогоните точный текст промпта как разовую задачу, прежде чем доверять его cron-расписанию, — плохой промпт на повторе просто ошибается регулярно вместо одного раза.
• Один промпт на всех клиентов. Общий шаблон с подставленной спецификой клиента лучше, чем один расплывчатый промпт «на всех сразу».
• База знаний не названа в задаче по расписанию. Агент не выберет её сам — без явного указания формат отчёта уплывёт от того, к которому привык клиент. Назовите её в задаче, как в промпте выше.

База знаний и скилы — это разные вещи

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

Скилы — это функциональность тарифа «Агентство» в Оракуле, поверх инструментов и базы знаний, которые есть у каждой роли. Конкретный пример из смежной дисциплины: скил conversion copywriter на mcpmarket.com добавляет структурированную технику убеждения — она нужна ровно в тот момент, когда отчёт перестаёт быть выгрузкой данных и должен продать следующий объём работ.

Максим Сафьянов

Я делаю Оракул: оркестратор ИИ-агентов для digital- и SEO-агентств, который разворачивается на вашем сервере — безлимит ролей, исходный код передаётся при внедрении.