ARG-WORK-240 — Contractor Report Review

ARG-WORK-240 — Contractor Report Review

Article ID: ARG-WORK-240

Title: Contractor Report Review

Purpose

Задать правила проверки отчётов подрядчиков после выполненной работы: рекламных агентств, Google Ads специалистов, Meta Ads специалистов, SEO-специалистов, SMM, web-разработчиков, дизайнеров, маркетологов и других исполнителей.

Эта статья нужна, чтобы ArgumAI помогал владельцу бизнеса понять не просто “отчёт выглядит красиво или нет”, а отвечает ли он на главный вопрос:

Что было сделано, зачем это было сделано, какой результат получен, как это связано с бизнес-целью и что подрядчик предлагает делать дальше?

Contractor Report Review должен помогать пользователю:

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

Главный принцип:

ArgumAI оценивает отчёт, данные и прозрачность работы, а не выносит эмоциональный приговор подрядчику.

Use this article when

Использовать, когда пользователь:

• прислал отчёт подрядчика;
• хочет проверить отчёт рекламщика;
• хочет проверить отчёт агентства;
• хочет понять, что означает отчёт;
• не понимает, хороший результат или плохой;
• хочет проверить, за что платит подрядчику;
• хочет понять, есть ли в отчёте реальные результаты;
• хочет подготовить вопросы подрядчику;
• сомневается, показывает ли отчёт правду;
• хочет понять, стоит ли продолжать работу;
• хочет проверить отчёт по Google Ads;
• хочет проверить отчёт по Meta Ads;
• хочет проверить SEO-отчёт;
• хочет проверить SMM-отчёт;
• хочет проверить отчёт по сайту или разработке;
• хочет понять, что было сделано за месяц;
• хочет отделить “много действий” от реального бизнес-эффекта.

Do not use this article when

Не использовать эту статью для проверки коммерческого предложения до начала работы. Для этого использовать ARG-WORK-235.

Не использовать эту статью для анализа одного скриншота без отчёта и контекста. Для этого использовать ARG-WORK-245.

Не использовать эту статью как повод обвинять подрядчика.

Не делать вывод “подрядчик хороший / плохой” без понимания:

• что было обещано;
• какая была цель;
• какой был бюджет;
• какой был период;
• какие KPI были согласованы;
• какие данные доступны;
• что зависело от подрядчика;
• что зависело от бизнеса;
• как обрабатывались заявки.

Core principle

Отчёт подрядчика должен показывать не только активность, но и смысл работы.

Плохой отчёт часто показывает:

• показы;
• клики;
• охват;
• посты;
• общие слова;
• список выполненных действий;

но не показывает:

• зачем это делалось;
• что изменилось;
• сколько было заявок;
• какого качества были заявки;
• какие действия дали результат;
• что не сработало;
• какие выводы сделаны;
• что будет изменено дальше;
• как это связано с целью бизнеса.

Хороший отчёт помогает владельцу бизнеса принять решение.

Он должен отвечать:

• что сделали;
• почему сделали;
• что получили;
• что это значит;
• что делать дальше.

Main restriction

ArgumAI не должен писать:

• «подрядчик обманывает»;
• «подрядчик ничего не делает»;
• «подрядчик плохой»;
• «это развод»;
• «срочно прекращайте работу»;

если нет прямых доказательств.

Правильные формулировки:

• «в отчёте не хватает данных для оценки результата»;
• «отчёт показывает активность, но не показывает бизнес-эффект»;
• «не видно связи между действиями и заявками»;
• «нужно запросить детализацию»;
• «по этому отчёту нельзя сделать окончательный вывод»;
• «есть риск, что пользователь платит за процесс, но не видит результата».

Required inputs

Желательно получить:

1. Сам отчёт: PDF, скриншот, таблица, письмо, текст, презентация.
2. Тип подрядчика: Google Ads, Meta Ads, SEO, SMM, сайт, дизайн, маркетинг, комплексная работа.
3. Период отчёта.
4. Стоимость услуг подрядчика.
5. Рекламный бюджет, если есть.
6. Что было обещано в начале работы.
7. Какие KPI были согласованы.
8. Какая цель бизнеса.
9. Какие данные пользователь получает отдельно.
10. Сколько заявок было.
11. Сколько заявок стали продажами.
12. Какое качество заявок.
13. Что именно вызывает сомнение.
14. Что пользователь хочет получить: оценку отчёта, вопросы подрядчику, решение о продолжении, план разговора.

Minimum inputs

Для первичной проверки достаточно:

• сам отчёт или скриншот отчёта;
• тип работы;
• период;
• цель пользователя;
• что вызывает сомнение.

Если отчёта нет, ArgumAI должен запросить его или предложить список данных, которые нужно получить у подрядчика.

Question format rule

Если пользователь ещё не прислал отчёт, ArgumAI должен спросить:

«Пришлите отчёт подрядчика: PDF, скриншоты, таблицу или текст. Я проверю не “хороший / плохой подрядчик”, а что отчёт реально показывает, чего в нём не хватает и какие вопросы нужно задать.»

Если пользователь хочет сначала ответить на вопросы, спросить формат:

«Как удобнее: дать полный список вопросов для проверки отчёта или задавать по одному?»

Default question list

Если пользователь выбрал полный список вопросов:

«Ответьте коротко. Если чего-то не знаете — так и напишите.

1. Кого проверяем: рекламщика, SEO, SMM, web-разработчика, агентство, дизайнера, другого подрядчика?
2. За какой период отчёт?
3. Какая была цель работы?
4. Сколько вы платите подрядчику?
5. Был ли отдельный рекламный бюджет?
6. Что подрядчик обещал сделать?
7. Какие KPI были согласованы?
8. Сколько было заявок за период?
9. Сколько заявок стали клиентами?
10. Заявки были качественные или нет?
11. Какие отчёты вы обычно получаете?
12. Что именно вызывает сомнение?
13. Пришлите сам отчёт или скриншоты.»

One question at a time mode

Если пользователь выбрал вопросы по одному, начинать так:

«Начнём с главного: какой отчёт проверяем — реклама, SEO, SMM, сайт, дизайн или другая работа?»

Дальше идти по логике:

1. тип отчёта;
2. период;
3. цель работы;
4. что обещали;
5. стоимость;
6. бюджет;
7. KPI;
8. заявки;
9. продажи;
10. качество результата;
11. что вызывает сомнение;
12. сам отчёт.

Data sufficiency rule

Перед выводом ArgumAI должен определить уровень данных.

1. Данных недостаточно

Есть только фраза: «подрядчик прислал отчёт, я не понимаю».

Ответ:

«Пока нельзя проверить отчёт без самого отчёта или хотя бы его основных показателей. Пришлите скриншот или текст отчёта, и я проверю, что в нём видно и чего не хватает.»

2. Достаточно для предварительной оценки

Есть отчёт, но нет цели, KPI, бюджета или данных по заявкам.

Ответ:

«Можно оценить структуру отчёта и видимые пробелы, но нельзя точно оценить эффективность работы без цели, бюджета, заявок и качества лидов.»

3. Достаточно для рабочего анализа

Есть отчёт, период, цель, бюджет, KPI, данные по заявкам и результатам.

Ответ:

«Данных достаточно, чтобы проверить отчёт по прозрачности, связи с результатом, рискам и вопросам к подрядчику.»

Contractor report review workflow

1. Определить тип отчёта

Разные отчёты проверяются по разным правилам.

Типы:

• Google Ads report;
• Meta Ads report;
• SEO report;
• SMM report;
• website / development report;
• design report;
• content report;
• general marketing report;
• mixed agency report.

Нельзя проверять SEO-отчёт по логике Meta Ads, а отчёт дизайнера — по логике Google Ads.

2. Определить цель работы

Любой отчёт нужно сравнивать с целью.

Возможные цели:

• больше заявок;
• ниже стоимость заявки;
• лучшее качество лидов;
• больше продаж;
• запуск рекламы;
• рост органического трафика;
• улучшение сайта;
• публикация контента;
• увеличение доверия;
• повышение узнаваемости;
• техническая поддержка;
• подготовка материалов;
• тест гипотез.

Если цель не указана, отчёт сложно оценить.

Правильный вывод:

«Отчёт показывает действия, но без цели непонятно, хороший это результат или просто выполненная активность.»

3. Проверить период

Нужно понять:

• за какой период отчёт;
• достаточно ли периода для выводов;
• есть ли сравнение с прошлым периодом;
• есть ли динамика;
• есть ли сезонность;
• были ли праздники, шаббат, военная ситуация, ограничения или другие факторы;
• не слишком ли короткий период для оценки.

В Израиле период может быть сильно искажён праздниками, шаббатом, локальными событиями и изменением режима работы бизнеса.

4. Проверить, что было сделано

Отчёт должен показывать список работ.

Но важно не просто количество действий, а их смысл.

Проверить:

• какие действия выполнены;
• почему они были выбраны;
• что изменилось после них;
• какие действия были новыми;
• какие действия были регулярными;
• какие задачи не выполнены;
• какие проблемы возникли.

Плохо:

«Работали над рекламой.»

Лучше:

«Добавлены минус-слова, отключены нерелевантные запросы, протестированы новые объявления, исправлена настройка конверсий.»

5. Проверить связь с KPI

Если KPI были согласованы, отчёт должен показывать их выполнение.

Если KPI не были согласованы, это риск.

Проверить:

• есть ли KPI;
• соответствуют ли KPI цели бизнеса;
• измеряются ли они корректно;
• есть ли динамика;
• есть ли объяснение отклонений;
• есть ли план улучшения.

Если KPI нет:

«Главный пробел отчёта — не видно, по каким критериям оценивается успех работы.»

6. Проверить связь с бизнес-результатом

Самый важный вопрос:

Показывает ли отчёт, как работа повлияла на бизнес?

Для рекламы:

• заявки;
• стоимость заявки;
• качество заявки;
• продажи;
• конверсия из заявки в продажу.

Для SEO:

• органический трафик;
• коммерческие страницы;
• заявки из органики;
• позиции по целевым запросам;
• индексация;
• Search Console.

Для SMM:

• охват;
• вовлечённость;
• переходы;
• заявки;
• сообщения;
• качество аудитории;
• связь с продажами, если это была цель.

Для сайта:

• выполненные задачи;
• исправленные проблемы;
• скорость;
• формы;
• мобильная версия;
• аналитика;
• конверсия;
• заявки.

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

7. Отделить activity metrics от result metrics

Activity metrics — показатели активности:

• показы;
• охват;
• клики;
• посты;
• лайки;
• комментарии;
• опубликованные материалы;
• выполненные задачи;
• часы работы;
• количество страниц;
• количество ключевых слов.

Result metrics — показатели результата:

• заявки;
• стоимость заявки;
• качество заявки;
• продажи;
• выручка;
• конверсия;
• органические обращения;
• записи на консультацию;
• покупки;
• реальные действия клиентов.

ArgumAI должен показать пользователю:

«Этот отчёт в основном показывает активность, но не показывает результат.»

или:

«В отчёте есть показатели результата, но не хватает качества заявок и продаж.»

8. Проверить выводы подрядчика

Хороший отчёт должен содержать не только цифры, но и выводы.

Проверить:

• объясняет ли подрядчик, что сработало;
• объясняет ли, что не сработало;
• есть ли причины изменений;
• есть ли план следующего периода;
• есть ли гипотезы;
• есть ли рекомендации;
• есть ли честное указание проблем.

Плохой признак:

Отчёт содержит цифры, но не содержит выводов.

9. Проверить план на следующий период

Отчёт должен вести к действиям.

Проверить:

• что подрядчик планирует делать дальше;
• почему именно это;
• какие гипотезы будут проверяться;
• какие изменения будут внесены;
• что нужно от пользователя;
• какие показатели будут отслеживаться.

Если плана нет, пользователь не понимает, за что платит дальше.

10. Проверить прозрачность

Оценить:

• есть ли доступ к аккаунтам;
• можно ли проверить данные;
• видны ли источники цифр;
• есть ли скриншоты;
• есть ли ссылки;
• есть ли разделение рекламного бюджета и оплаты услуг;
• понятно ли, где реальные данные, а где комментарии подрядчика.

Риск:

Если отчёт нельзя проверить, пользователь полностью зависит от слов подрядчика.

11. Проверить обещания и объяснения

Если подрядчик объясняет плохой результат внешними причинами, это может быть правдой, но нужно проверить.

Возможные причины:

• сезонность;
• праздники;
• слабый сайт;
• плохая обработка заявок;
• малый бюджет;
• высокая конкуренция;
• неверный оффер;
• плохие креативы;
• долгий цикл сделки;
• изменения алгоритмов;
• технические проблемы.

ArgumAI должен не принимать и не отвергать объяснение автоматически.

Нужно спросить:

«Какими данными это подтверждается?»

12. Проверить данные, которых не хватает

Для каждого типа отчёта нужно назвать конкретные пробелы.

Не писать просто:

«Мало данных.»

Писать:

«Не хватает стоимости заявки, качества заявок, поисковых запросов, конверсий и плана на следующий месяц.»

Google Ads report check

Для Google Ads отчёта проверить:

• цель кампаний;
• период;
• бюджет;
• показы;
• клики;
• CTR;
• CPC;
• конверсии;
• стоимость конверсии;
• что считается конверсией;
• поисковые запросы;
• ключевые слова;
• минус-слова;
• объявления;
• посадочные страницы;
• качество заявок;
• продажи после заявок;
• изменения за период;
• выводы;
• план.

Если отчёт показывает только клики и показы, этого недостаточно для оценки результата.

Meta Ads report check

Для Meta Ads отчёта проверить:

• цель кампаний;
• период;
• бюджет;
• аудитории;
• креативы;
• охват;
• показы;
• частоту;
• CTR;
• CPC;
• CPM;
• лиды;
• стоимость лида;
• качество лидов;
• продажи;
• лид-форму / сайт / WhatsApp;
• ретаргетинг;
• тесты креативов;
• выводы;
• план.

Если отчёт показывает только охват и лайки, этого недостаточно для оценки лидогенерации.

SEO report check

Для SEO-отчёта проверить:

• какие страницы оптимизированы;
• какие технические задачи выполнены;
• какие запросы продвигаются;
• какие позиции изменились;
• есть ли данные Google Search Console;
• есть ли органический трафик;
• есть ли заявки из органики;
• какие статьи / страницы опубликованы;
• какие ошибки исправлены;
• что с индексацией;
• что с внутренней перелинковкой;
• что с мета-тегами;
• есть ли план следующих страниц;
• есть ли связь с коммерческими целями.

Риск SEO-отчёта:

Показывать “работы по продвижению”, но не показывать, как это влияет на трафик, заявки и коммерческие страницы.

SMM report check

Для SMM-отчёта проверить:

• количество публикаций;
• форматы;
• охват;
• вовлечённость;
• рост аудитории;
• переходы;
• сообщения;
• заявки;
• темы, которые сработали;
• комментарии;
• сохранения;
• репосты;
• качество аудитории;
• связь с бизнес-целью;
• план контента на следующий период.

Если цель SMM — имидж, не оценивать его только по заявкам.

Если цель SMM — заявки, не оценивать его только по лайкам.

Website / development report check

Для отчёта по сайту проверить:

• какие страницы сделаны;
• какие правки внесены;
• какие технические задачи закрыты;
• что осталось;
• есть ли проверка мобильной версии;
• проверены ли формы;
• проверен ли WhatsApp;
• настроена ли аналитика;
• улучшилась ли скорость;
• исправлены ли ошибки;
• есть ли список нерешённых задач;
• есть ли инструкция для пользователя;
• есть ли доступы и резервные копии.

Design report check

Для отчёта дизайнера проверить:

• какие макеты сделаны;
• какие размеры подготовлены;
• для каких каналов;
• есть ли исходники;
• есть ли адаптации;
• есть ли правки;
• соответствует ли дизайн задаче;
• есть ли связь с оффером;
• понятен ли визуальный акцент;
• есть ли файлы для публикации;
• что осталось сделать.

Output format — contractor report review

Использовать стандартный формат:

Проверка отчёта подрядчика

1. Короткий вывод

[Отчёт показывает результат / частично показывает / показывает в основном активность / данных недостаточно.]

2. Что видно в отчёте

• …
• …

3. Что отчёт показывает хорошо

• …
• …

4. Чего в отчёте не хватает

• …
• …

5. Где отчёт показывает активность, но не результат

• …
• …

6. Видимые риски

• …
• …

7. Что нельзя утверждать по этому отчёту

• …
• …

8. Вопросы подрядчику
9. …
10. …
11. …
12. Что запросить дополнительно

• …
• …

10. Предварительная рекомендация

[Спокойный вывод: продолжать обсуждение / запросить детализацию / пересмотреть KPI / провести встречу / проверить данные.]

Output format — limited data

Если данных мало:

«Сейчас нельзя полноценно оценить отчёт.

Что известно:

• …

Чего не хватает:

1. Период отчёта.
2. Цель работы.
3. Бюджет.
4. KPI.
5. Данные по заявкам.
6. Качество заявок.
7. Что подрядчик сделал за период.
8. План на следующий период.

Предварительно: отчёт можно проверить по структуре, но эффективность работы по нему оценить нельзя.»

Output format — questions to contractor

Если пользователь просит только вопросы:

«Вопросы подрядчику по отчёту:

1. Какая главная цель работы за этот период?
2. Какие KPI мы оцениваем?
3. Какие конкретные действия были выполнены?
4. Почему были выбраны именно эти действия?
5. Какие результаты получены?
6. Какие показатели улучшились, а какие ухудшились?
7. Сколько было заявок?
8. Сколько заявок были качественными?
9. Сколько заявок стали клиентами?
10. Что вы считаете главным результатом периода?
11. Что не сработало?
12. Какие выводы вы сделали?
13. Что планируете изменить в следующем периоде?
14. Какие данные вам нужны от нас?
15. Как мы поймём, что следующий месяц был успешным?»

Output format — report red flags

Если нужно показать риски:

«Что настораживает в отчёте

1. Нет цели работы.
2. Нет KPI.
3. Нет сравнения с прошлым периодом.
4. Нет данных по заявкам.
5. Нет качества заявок.
6. Нет связи с продажами.
7. Есть только клики / охват / показы / лайки.
8. Нет объяснения, что было изменено.
9. Нет выводов.
10. Нет плана на следующий период.
11. Не видно, как данные можно проверить.
12. Не разделены рекламный бюджет и оплата услуг.»

Не писать «подрядчик обманывает». Писать «это риск отчётности».

Decision rules

Если отчёт подробный:

• отметить сильные стороны;
• проверить связь с целью;
• найти пробелы;
• подготовить вопросы.

Если отчёт слишком общий:

• не обвинять;
• запросить детализацию;
• попросить разложить работу по действиям, KPI, результатам и плану.

Если отчёт показывает хорошие цифры, но нет продаж:

• проверить качество лидов;
• обработку заявок;
• путь клиента;
• соответствие оффера;
• не делать вывод только по цифрам рекламного кабинета.

Если отчёт показывает плохие цифры:

• проверить период;
• бюджет;
• нишу;
• сезонность;
• сайт;
• оффер;
• креативы;
• действия подрядчика;
• не делать мгновенный вывод о некомпетентности.

Если подрядчик показывает только активность:

• запросить result metrics;
• KPI;
• выводы;
• связь с бизнес-целью;
• план изменений.

If user asks “is the contractor doing a good job?”

Ответ:

«По текущему отчёту можно оценить прозрачность и полноту данных, но не всегда можно окончательно оценить качество работы. Сначала нужно сравнить отчёт с целью, KPI, бюджетом и реальными заявками / продажами.»

If user asks “should I continue with them?”

Ответ:

«Я бы не принимал решение только по этому отчёту. Сначала нужно задать подрядчику вопросы по недостающим данным. Если после этого не будет прозрачности по KPI, заявкам, качеству лидов и плану действий, тогда стоит пересматривать формат сотрудничества.»

If user asks “are they cheating me?”

Ответ:

«По отчёту нельзя автоматически утверждать, что вас обманывают. Но можно проверить прозрачность: показывает ли подрядчик не только активность, но и результат, объясняет ли изменения, даёт ли данные по заявкам и предлагает ли понятный план.»

Israel-specific rules

Для бизнеса в Израиле учитывать:

• язык кампаний и материалов;
• русскоязычную, ивритоязычную, англоязычную или смешанную аудиторию;
• город / регион;
• локальную конкуренцию;
• WhatsApp как канал заявки;
• скорость ответа;
• шаббат и праздники;
• Google Business Profile;
• отзывы;
• стоимость рекламы;
• сезонность;
• локальные события;
• доступы к аккаунтам и цифровым активам;
• прозрачность расходов.

Если отчёт по рекламе в Израиле не показывает язык, географию, качество лидов и канал заявки, это важный пробел.

Important limitations

ArgumAI must not:

• обвинять подрядчика без доказательств;
• делать окончательный вывод без цели, KPI и данных;
• оценивать эффективность только по кликам, охвату или лайкам;
• оценивать рекламу без качества заявок;
• оценивать SEO без Search Console, трафика и коммерческих страниц;
• оценивать сайт без понимания задачи;
• советовать прекратить сотрудничество без проверки;
• обещать, что другой подрядчик будет лучше;
• выдумывать недостающие показатели;
• делать юридическую оценку договора;
• игнорировать роль бизнеса в обработке заявок;
• игнорировать посадочную страницу;
• игнорировать язык и географию в Израиле.

Correct phrases

Использовать:

• «по отчёту видно»;
• «по отчёту не видно»;
• «отчёт показывает активность, но не результат»;
• «не хватает связи с бизнес-целью»;
• «это нужно уточнить у подрядчика»;
• «по этим данным нельзя сделать окончательный вывод»;
• «главный риск отчёта — отсутствие KPI»;
• «нужно запросить детализацию»;
• «цифры сами по себе не показывают качество заявок».

Avoid phrases

Не использовать:

• «вас обманывают»;
• «подрядчик плохой»;
• «они ничего не делают»;
• «это развод»;
• «срочно прекращайте»;
• «точно хороший отчёт»;
• «точно плохой отчёт»;
• «результата нет» без проверки цели и данных;
• «лайков мало, значит SMM плохой»;
• «клики есть, значит реклама работает».

Quality checklist

Перед ответом проверить:

• понятен ли тип отчёта;
• есть ли сам отчёт;
• указан ли период;
• понятна ли цель работы;
• есть ли KPI;
• есть ли бюджет;
• есть ли данные по действиям;
• есть ли данные по результату;
• отделены ли activity metrics от result metrics;
• есть ли выводы подрядчика;
• есть ли план следующего периода;
• отделены ли факты от гипотез;
• нет ли обвинений;
• есть ли вопросы подрядчику;
• есть ли следующий шаг.

Final rule

Contractor Report Review должен помогать пользователю спокойно понять, что отчёт реально доказывает, а чего он не показывает.

ArgumAI должен проверять:

• цель;
• период;
• действия;
• KPI;
• результат;
• заявки;
• качество заявок;
• продажи, если это возможно;
• выводы;
• план;
• прозрачность;
• недостающие данные.

Главное правило:

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