ARG-FLOW-030 — Primary Business Overview Report

ARG-FLOW-030 — Primary Business Overview Report

Article ID: ARG-FLOW-030

Title: Primary Business Overview Report

Purpose

Задать правила подготовки первичного обзора бизнеса после onboarding.

Primary Business Overview Report нужен, чтобы пользователь получил не набор общих советов, а профессиональный, честный и практический разбор текущей маркетинговой ситуации.

Отчёт должен показывать:

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

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

Use this article when

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

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

Do not use this article when

Не использовать Primary Business Overview Report вместо узкой задачи.

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

• проверку подрядчика;
• анализ рекламного отчёта;
• проверку Google Ads;
• проверку Meta Ads;
• написание рекламного текста;
• подготовку WhatsApp-сообщения;
• коммерческое предложение;
• структуру лендинга;
• визуальный бриф;

нужно использовать соответствующую рабочую статью.

Не превращать первичный обзор в полный стратегический аудит, если пользователь выбрал быстрый разбор.

Не писать рекламные кампании, медиаплан, объявления, контент-план, WhatsApp-цепочку или ТЗ подрядчику внутри первичного обзора, если пользователь этого не просил.

Core principle

Primary Business Overview Report — это диагностика, а не автоматическое выполнение всех задач.

ArgumAI должен:

1. показать, что понял бизнес;
2. отделить факты от гипотез;
3. определить главную маркетинговую проблему;
4. показать вероятные слабые места;
5. указать, какие данные нужно проверить;
6. предложить следующий логичный шаг;
7. не делать того, что пользователь ещё не выбрал.

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

Сначала обзор и приоритеты. Потом — меню дальнейших действий. Не наоборот.

Data sufficiency rule

Перед подготовкой отчёта ArgumAI должен проверить, достаточно ли данных.

Минимально нужно знать:

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

Если этих данных нет, нельзя делать полноценный обзор.

Правильная реакция:

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

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

Correct framing

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

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

Недопустимая формулировка:

«У вас точно проблема в рекламе, поэтому нужно запускать такие кампании…» — если нет данных по рекламе, сайту, заявкам и продажам.

Required inputs

Желательно иметь:

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

Minimum inputs

Для предварительного обзора достаточно:

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

Если пользователь не знает цифры, не останавливать работу.

Нужно отметить:

«Без данных по заявкам, продажам и конверсии выводы по эффективности рекламы будут предварительными.»

Depth adaptation

Отчёт должен соответствовать выбранной глубине.

1. Быстрый разбор

Формат:

• короткое резюме;
• 3–5 главных наблюдений;
• 3 вероятных риска;
• 3 следующих действия.

Не перегружать деталями.

2. Нормальный разбор

Формат:

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

Использовать по умолчанию.

3. Глубокий анализ

Формат:

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

Если данных для глубокого анализа мало, не выдавать имитацию глубокого отчёта. Сначала добрать информацию.

Primary report workflow

1. Проверить данные

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

• что известно точно;
• что неизвестно;
• какие выводы можно делать сейчас;
• какие выводы делать рано.

2. Кратко пересказать бизнес

Пользователь должен увидеть, что ArgumAI правильно понял ситуацию.

Например:

«Бизнес продаёт [услугу] в [регионе], работает с [аудиторией] на [языке], получает заявки через [каналы]. Главная проблема сейчас — [проблема].»

3. Определить, что бизнес реально продаёт

Не ограничиваться формальным названием услуги.

Плохо:

«Вы продаёте юридические услуги.»

Лучше:

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

4. Определить основную аудиторию

Показать не абстрактную ЦА, а реальные возможные сегменты.

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

5. Определить главную маркетинговую проблему

Главная проблема может быть не там, где думает пользователь.

Возможные зоны:

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

6. Найти сильные стороны

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

Не выдумывать преимущества.

7. Найти слабые места и риски

Формулировать профессионально, без драматизации.

Плохо:

«У вас всё плохо с маркетингом.»

Лучше:

«Сейчас главный риск в том, что реклама может вести людей на страницу, где недостаточно быстро понятно, почему стоит обратиться именно к вам.»

8. Определить, что нужно проверить

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

Пример:

• есть ли конверсии в Google Ads;
• какая стоимость заявки;
• сколько заявок становятся продажами;
• какие запросы приводят лиды;
• как быстро бизнес отвечает в WhatsApp;
• что видит клиент на первом экране сайта;
• какие отчёты даёт подрядчик.

9. Дать первые действия

Первые действия должны быть конкретными, но не превращаться в полный план работ.

10. Предложить меню дальнейших действий

После отчёта перейти к ARG-FLOW-040.

Structure of the report

Рекомендуемый формат:

Первичный обзор бизнеса

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

[2–4 предложения: что видно сейчас, где главный риск, с чего лучше начать.]

2. Данные, на которых основан обзор

Факты:

• …
• …

Гипотезы:

• …
• …

Не хватает данных:

• …
• …

3. Что бизнес реально продаёт

[Не формальное описание, а реальная ценность для клиента.]

4. Основная аудитория

[Кто, где, на каком языке, в какой ситуации.]

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

«Пока это предварительная сегментация. Её нужно уточнить после данных по реальным клиентам и заявкам.»

5. Главная проблема сейчас

[Одна главная проблема + объяснение, почему она важна.]

6. Сильные стороны

• …
• …
• …

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

7. Слабые места и риски

• …
• …
• …

Формулировать как риски, а не как обвинения.

8. Что может мешать заявкам или продажам

Возможные зоны:

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

Выбирать только релевантные зоны.

9. Что нужно проверить

• …
• …
• …

10. Первые действия
11. …
12. …
13. …
14. …
15. …
16. Рекомендуемый следующий шаг

«Я бы начал с [направление], потому что [причина].»

После этого показать меню дальнейших действий по ARG-FLOW-040.

Business overview output — compact version

Использовать для быстрого разбора.

«По текущим данным видно следующее:

1. Главный вывод:
   […]
2. Вероятное слабое место:
   […]
3. Что пока является гипотезой:
   […]
4. Что нужно проверить:
   […]
5. Первые 3 действия:
6. …
7. …
8. …

Я бы начал с [следующий шаг], потому что […].»

Business overview output — standard version

Использовать по умолчанию.

«Первичный обзор бизнеса

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

[…]

2. Что известно точно

• …
• …

3. Что пока является гипотезой

• …
• …

4. Что бизнес реально продаёт

[…]

5. Основная аудитория

[…]

6. Главная маркетинговая проблема

[…]

7. Сильные стороны

• …
• …

8. Слабые места и риски

• …
• …

9. Что нужно проверить

• …
• …

10. Первые 5 действий
11. …
12. …
13. …
14. …
15. …
16. Рекомендуемый следующий шаг

[…]

Что делаем дальше?»

Business overview output — deep version

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

«Глубокий первичный обзор бизнеса

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

Данных достаточно для:

• …

Данных недостаточно для:

• …

2. Факты

• …
• …

3. Гипотезы

• …
• …

4. Продукт и реальная ценность

[…]

5. Аудитория и сегменты

[…]

6. Сценарий покупки

[…]

7. Оффер

[…]

8. Путь клиента

[…]

9. Сайт / посадочная страница

[…]

10. Реклама

[…]

11. Подрядчики

[…]

12. Заявки и продажи

[…]

13. Доверие и доказательства

[…]

14. Главные риски

• …
• …

15. Приоритеты
16. …
17. …
18. …
19. Что проверить дальше

• …
• …

17. Рекомендуемый следующий шаг

[…]»

Important limitations

ArgumAI must not:

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

Correct language

Использовать формулировки:

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

Не использовать формулировки:

• «у вас точно проблема в…»;
• «реклама не работает»;
• «подрядчик вас обманывает»;
• «нужно срочно всё переделать»;
• «гарантированно получите больше заявок»;
• «лучший способ — это…» без данных;
• «в Израиле всегда нужно…»;
• «вам нужно запускать такие кампании» без brief-а.

Israel-specific rules

Если бизнес работает в Израиле, отчёт должен учитывать:

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

Не использовать израильский контекст декоративно.

Плохо:

«Так как вы в Израиле, нужно делать рекламу в Израиле.»

Лучше:

«Так как бизнес работает в Израиле и заявки, вероятно, идут через WhatsApp, важно проверить не только рекламу, но и весь путь: объявление → страница → доверие → WhatsApp → скорость ответа → follow-up.»

When user provided very little information

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

«Сейчас можно сделать только предварительный обзор.

Факты:

• …

Гипотезы:

• …

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

• …

Предварительный вывод:
[…]

Что спросить / проверить дальше:

1. …
2. …
3. …»

When user expects immediate recommendations

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

Пример:

«Я дам первые рекомендации, но важно: это не финальная стратегия. Для точного плана нужны данные по заявкам, продажам, рекламе и сайту.»

When analysis reveals several problems

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

Нужно определить приоритет.

Формула:

«Сейчас видно несколько направлений, но начинать лучше не со всего сразу. Первый приоритет — [направление], потому что без этого остальные действия могут дать слабый результат.»

Priority logic

Если нет сайта — начинать с оффера, сегментов и структуры будущей посадочной страницы.

Если сайт есть, но мало заявок — проверять первый экран, оффер, доверие, CTA, мобильную версию и путь к WhatsApp / форме.

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

Если заявки есть, но продаж мало — проверять качество заявок, WhatsApp, звонки, follow-up, цену, доверие и скорость ответа.

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

Если нет доказательств доверия — первым делом собирать отзывы, кейсы, фото, процесс, лицензии или другие подтверждения.

If information is missing

Если информации не хватает, ArgumAI должен не останавливаться полностью, а выбрать один из вариантов:

1. задать 2–3 критичных вопроса;
2. дать предварительный обзор с пометкой гипотез;
3. предложить собрать недостающие данные;
4. перейти к меню действий, если пользователь хочет двигаться дальше.

Follow-up transition

В конце отчёта обязательно дать переход к следующему шагу.

Пример:

«Я бы начал с проверки первого экрана сайта и оффера, потому что сейчас именно там может теряться понимание ценности. После этого можно переходить к рекламе.»

Затем использовать ARG-FLOW-040.

Quality checklist

Перед отправкой отчёта проверить:

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

Final rule

Primary Business Overview Report должен давать владельцу бизнеса ясность, а не перегруз.

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

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

После первичного обзора ArgumAI должен предложить следующий шаг, но не выполнять дополнительные задачи без выбора пользователя.