5 ошибок в ТЗ на автопостинг, если менеджеры не заполняют CRM

5 ошибок в ТЗ на автопостинг, если менеджеры не заполняют CRM

«Посты выходят, обращения приходят, а я не вижу воронку продаж». Если вам знакома эта ситуация, в техническом задании на автопостинг нужно описать не только расписание публикаций, но и путь обращения до CRM. Иначе вы автоматизируете выпуск контента, а потери заявок останутся прежними. 📌

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

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

Сразу разделим данные: показатели в расчётных примерах — условные числа для объяснения методики, а не результаты клиентов. Реальные технические требования и исследовательские выводы обозначены отдельно.

1. Как решить проблему «менеджеры теряют заявки», если в ТЗ указаны только публикации?

Добавьте в ТЗ маршрут обращения: от конкретного поста до карточки CRM и ответственного сотрудника. Задание «публиковать контент по расписанию» заканчивается на выходе поста — оно не обеспечивает регистрацию заявок.

Типичная формулировка: «Настроить автопостинг в Telegram и ВК, подключить сайт, поставить публикации в очередь». Исполнитель может выполнить всё перечисленное. Но если посетитель отправил форму, а карточка не создалась, формально претензия окажется за пределами задания.

Это первая ошибка: результат описан как действие системы, а не как проверяемый бизнес-процесс.

Что именно добавить в техническое задание?

Для каждого способа обращения укажите источник, точку приёма, способ передачи в CRM и владельца ошибки. Один универсальный пункт «интегрировать с CRM» оставляет слишком много неопределённости.

Для связки «пост → сайт → форма → CRM» зафиксируйте:

• Источник: площадка, аккаунт, рубрика, идентификатор публикации.
• Разметка: правила заполнения `utm_source`, `utm_medium`, `utm_campaign`, при необходимости — `utm_content`.
• Точка обращения: форма на посадочной странице, заказ, заявка на консультацию.
• Передача данных: какие поля и идентификаторы получает CRM.
• Назначение: кто становится ответственным, что происходит вне рабочего времени.
• Контроль: где фиксируется неуспешная передача и кто получает уведомление.

Отдельно опишите обращения в личные сообщения, комментарии и по телефону. UTM-метка не переносит переписку в CRM и не определяет источник телефонного звонка без дополнительного механизма учёта.

Готовый пункт для ТЗ:

> Для каждой тестовой заявки из формы сохранить контакт, время обращения, адрес страницы и доступные UTM-метки. Создать либо обновить запись CRM по согласованному правилу поиска дублей. При ошибке передачи записать событие в журнал и уведомить ответственного. Способ обработки личных сообщений согласовать отдельно.

Если вы планируете заказать автопостинг контента в соцсети, сразу разделите два объёма работ: публикацию и передачу обращений. У них могут быть разные исполнители и разные критерии приёмки.

Как посчитать, сколько обращений теряется между формой и CRM?

Сравнивайте уникальные валидные обращения на входе с записями, которые удалось найти в CRM. Количество публикаций и просмотров для этой проверки не подходит.

Коэффициент регистрации обращений:

Kрег = обращения, зарегистрированные в CRM / валидные обращения на входе × 100%.

Расчётный пример:

• Форма зарегистрировала 40 уникальных валидных обращений.
• В CRM найдены 34 соответствующие записи.
• Коэффициент регистрации: 34 / 40 × 100% = 85%.
• Разрыв регистрации: 15%, или 6 обращений.

Это ещё не доказательство, что все шесть обращений потеряны окончательно. Часть может находиться в очереди, попасть в другую сущность CRM или ожидать обработки. Но это уже проверяемый список расхождений, а не впечатление «менеджеры что-то упускают».

Знаменатель должен быть очищен от тестов, спама и повторов по заранее согласованным правилам. Иначе коэффициент будет показывать особенности подсчёта, а не качество процесса.

2. Как решить проблему «менеджеры не заполняют CRM», не добавляя им ручную работу?

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

Вторая ошибка в ТЗ — написать: «Менеджер указывает источник, ссылку на пост, кампанию и статус». Источник и ссылка уже известны системе. Переписывать их вручную — лишняя операция и дополнительное место для ошибки.

Разделите поля по способу заполнения.

Автоматически, если данные доступны в конкретном канале:

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

После контакта с клиентом:

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

Здесь проходит граница ответственности. Сервис автопостинга контента не должен автоматически объявлять обращение квалифицированным, если для этого нужен разговор с человеком.

Почему обязательное поле ещё не означает качественные данные?

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

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

Для ТЗ полезнее такая логика:

• На создании обращения — минимальный набор технических данных.
• На переходе к следующей стадии — только необходимые для неё сведения.
• При закрытии — результат и содержательная причина.
• Для активной сделки — ответственное лицо и следующее действие.

Коэффициент полноты данных:

Kполн = корректно заполненные обязательные поля / проверенные обязательные поля × 100%.

Команда Молвун приводит цифры: условный пример: проверили 20 карточек, в каждой — 5 обязательных полей. Всего 100 проверок. Корректными оказались 78 значений: полнота составила 78%.

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

Плюсы минимального набора полей:

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

Ограничение: сокращение формы не заменяет регламент продаж. Если руководитель не использует данные CRM на рабочих встречах, сотрудники не видят практического смысла в их заполнении.

Зачем CRM, если обращения уже записывают в Excel?

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

Сравнение по задаче:

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

Если бизнес вырос, появился новый РОП или крупный клиент выпал из внимания, полезно проверять не «есть ли CRM», а можно ли по любой активной сделке увидеть владельца, договорённость и следующий шаг.

3. Почему автопостинг публикует не по расписанию, хотя исполнитель пишет «всё отправлено»?

Потому что отправка запроса, принятие задания площадкой и фактический выход публикации — разные события. Третья ошибка в ТЗ — считать успешный ответ интеграции доказательством опубликованного поста.

По стандарту IETF RFC 9110, опубликованному в 2022 году, HTTP-ответ 202 Accepted означает, что запрос принят к обработке, но обработка ещё не завершена. Это технический факт, а не статистика надёжности сервисов.

Ответ 200 OK также нужно трактовать в контексте конкретного метода API. Успешное чтение статуса задания не обязательно означает успешную публикацию.

Попросите исполнителя разделить состояния:

• Запланировано — контент находится в очереди.
• Отправлено — запрос ушёл на площадку.
• Принято — площадка приняла задание.
• Опубликовано — получено предусмотренное API подтверждение, по возможности — ссылка или идентификатор поста.
• Ошибка — зафиксированы причина и дальнейшее действие.

Критерий приёмки должен опираться на подтверждение публикации, доступное для конкретной площадки. Если API не позволяет проверить часть параметров, это ограничение следует указать заранее.

Что проверить в расписании и повторных попытках?

Проверьте часовой пояс, правила задержек, срок действия доступа и защиту от повторной публикации. Пункт «повторить при ошибке» без условий способен создать дубли.

В ТЗ нужны ответы:

1. Где хранится часовой пояс и как он отображается пользователю?
2. Что происходит, если публикация не вышла в назначенное время?
3. При каких ошибках разрешён повтор?
4. Как определяется, что предыдущая попытка всё-таки завершилась?
5. После какого события требуется ручное вмешательство?
6. Кто получает уведомление об истёкшем доступе?

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

Молвун фиксирует: для приёмочного теста можно согласовать, например, допуск задержки 5 минут. Это не отраслевой норматив и не универсальная возможность сервиса: значение выбирают под задачу и ограничения площадки.

Коэффициент публикации в согласованный срок:

Kсрок = публикации в пределах допуска / запланированные публикации × 100%.

Расчётный пример:

• В тесте запланированы 20 публикаций.
• 18 вышли в пределах согласованного допуска.
• 1 вышла позже.
• 1 не опубликована.
• Kсрок = 90%, доля фактически опубликованных постов — 95%.

Два показателя отвечают на разные вопросы. Первый — о соблюдении расписания, второй — о факте выхода.

Если вы хотите купить услугу автопостинга в Telegram и Instagram, не переносите условия одной площадки на другую. Поддерживаемые типы аккаунтов, форматы и способы публикации нужно проверять по актуальной документации каждого канала.

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

4. Как не принять рост публикаций за рост продаж или упоминаний в AI?

Разведите показатели выпуска контента, регистрации обращений, продаж и присутствия бренда в AI-ответах. Четвёртая ошибка — объединить их в обещание «автопостинг увеличит продажи и видимость», не указав способ проверки.

Публикация — управляемое действие. Продажа зависит также от предложения, спроса, работы менеджера, наличия товара и других факторов. Упоминание в AI-ответе зависит не только от частоты размещения материалов.

Полезная структура отчёта:

• Контент: что запланировано, опубликовано и завершилось ошибкой.
• Переходы: какие посещения удалось связать с размеченными ссылками.
• Обращения: сколько валидных контактов зарегистрировано и попало в CRM.
• Продажи: какие сделки завершены и по какой модели им присвоен источник.
• GEO: в каких ответах по согласованным запросам упомянут бренд, какие источники процитированы.

Молвун предоставляет инструменты мониторинга упоминаний бренда в нейросетях, анализа тональности и доли голоса — Share of Voice. Эти данные помогают оценивать AI-видимость, но не подтверждают автоматически, что конкретная сделка возникла благодаря публикации.

Что исследования действительно говорят о GEO-контенте?

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

Команда Молвун приводит цифры: по данным работы «GEO: Generative Engine Optimization», опубликованной на KDD в 2024 году, отдельные методы оптимизации дали увеличение видимости до 40% на исследовательском бенчмарке.

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

Поэтому автопостинг для GEO-контента стоит описывать через управляемые требования:

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

Формулировка «Услуги по автопостингу для роста упоминаний в AI» нуждается в расшифровке: какие материалы выпускают, где размещают, что измеряют и какие результаты не гарантируют.

Как сравнивать долю голоса без статистических ловушек?

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

Например:

• Доля ответов с брендом: число ответов с упоминанием бренда / все проверенные ответы.
• Доля упоминаний бренда: упоминания бренда / упоминания всех отслеживаемых брендов.

Это не взаимозаменяемые показатели.

Команда Молвун приводит цифры: условный расчёт: в 50 проверенных ответах бренд появился 10 раз — доля ответов с упоминанием равна 20%. В следующем сопоставимом измерении — 15 из 50, то есть 30%.

Разница составляет:

• 10 процентных пунктов;
• 50% относительного роста.

Оба расчёта верны, но второй без исходной базы выглядит значительно внушительнее.

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

5. Что включить в ТЗ, если прошлый подрядчик не довёл внедрение?

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

Когда прошлый подрядчик не довёл внедрение, новый исполнитель часто получает неполный набор доступов, неизвестные правила интеграции и код без инструкции. Повторная настройка начинается с выяснения, что вообще было сделано.

Попросите передать:

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

Доступы должны оставаться под контролем компании. Пароли и токены не следует вставлять в общедоступное ТЗ: согласуйте защищённый способ передачи и минимально необходимые права.

Как выглядит проверка до окончательного расчёта?

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

1. Обычная публикация: пост вышел, подтверждение сохранено.
2. Отложенная публикация: время соответствует согласованному часовому поясу.
3. Неподдерживаемый файл: система показывает понятную причину отказа.
4. Недействующий доступ: ответственному приходит уведомление.
5. Сетевой сбой: повтор выполняется по согласованному правилу.
6. Повторная отправка: не создаёт непредусмотренный дубликат.
7. Форма после перехода из поста: обращение регистрируется с доступными метками.
8. Недоступная CRM: обращение не исчезает без следа, фиксируется состояние передачи.
9. Повторное обращение клиента: применяется согласованное правило поиска дублей.
10. Пустое бизнес-поле: проверяется предусмотренная логика перехода между стадиями.

В протоколе фиксируйте ожидаемый результат, фактический результат и подтверждение проверки.

Приёмка 10 из 10 сценариев означает только успешное прохождение этих тестов в данных условиях. Она не является гарантией бесперебойной работы.

Плюсы приёмки по сценариям:

• меньше споров о слове «готово»;
• понятна граница между публикацией, интеграцией и продажами;
• проще передать поддержку другому исполнителю.

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

Как составить план внедрения и рассчитать окупаемость автопостинга?

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

Рабочий план состоит из 5 этапов.

1. Диагностика. Найти точки входа обращений, проверить расхождения с CRM, определить владельцев процесса.
2. Проектирование. Согласовать поля, статусы, правила повторов, уведомления и критерии приёмки.
3. Пилот. Проверить ограниченный набор площадок, форматов и путей обращения.
4. Приёмка. Пройти согласованные сценарии, устранить критические дефекты, обучить пользователей.
5. Расширение. Подключать остальные каналы после подтверждения работоспособности базового процесса.

Сколько займёт внедрение? Без обследования назвать достоверный срок нельзя. Подключение готового коннектора и разработка нестандартной интеграции с CRM — разные по объёму работы. В договоре полезнее видеть сроки этапов, зависимости от доступов и порядок приостановки работ, чем одну дату без условий.

Как оценить экономию времени и не принять её за прибыль?

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

Формула:

Экономия времени = число публикаций × сокращение ручного времени на публикацию − дополнительное время контроля.

Условный пример:

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

подрядчик фиксирует: расчёт: 60 × (8 − 3) − 60 = 240 минут, или 4 часа.

Сокращение трудозатрат в этом примере — 50%: было 480 минут, стало 240 минут с учётом контроля. Это арифметика заданного сценария, не рыночная статистика и не обещание сервиса.

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

Что включить в расчёт ROI?

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

ROI = (подтверждённый эффект − все затраты) / все затраты × 100%.

В затраты включают:

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

В эффект — подтверждённую экономию либо дополнительный маржинальный результат по согласованной модели расчёта.

Запрос «Цена на автопостинг контента для GEO» не задаёт сопоставимую услугу. Один исполнитель может считать только размещение, другой — подготовку материалов, третий — ещё и мониторинг AI-упоминаний. Стоимость сравнивают после выравнивания состава работ.

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

Какие кейсы запрашивать у исполнителя?

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

Вопросы исполнителю:

• Какие площадки и форматы подключали?
• Как подтверждали выход публикации?
• Как обращения попадали в CRM?
• Что делали при сбое?
• Какие данные менеджеры заполняли вручную?
• Какие результаты измерили и по какой методике?

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

Вопросы и ответы

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

Хочу купить автопостинг на несколько платформ — что проверить до оплаты?

Проверьте поддержку нужных площадок, типов аккаунтов и форматов, а также условия доступа к ним. Отдельно уточните, входят ли журнал ошибок, подтверждение публикации, уведомления и интеграция с CRM.

Фраза «поддерживается площадка» не означает, что доступны все её форматы. Купить автопостинг на несколько платформ и получить одинаковую функциональность в каждом канале — не одно и то же.

Как настроить автопостинг для бизнеса, если менеджеры не заполняют CRM?

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

Поиск «как настроить автопостинг для бизнеса» часто приводит к инструкциям по подключению аккаунтов. Для контроля продаж этого недостаточно: нужен отдельный сценарий «обращение → запись CRM → ответственный → задача».

Почему автопостинг не публикует контент по расписанию?

Причину нужно искать в журнале конкретной публикации: возможны проблемы доступа, формата, часового пояса, лимитов или обработки запроса. Без журнала отличить сбой площадки от ошибки настройки трудно.

Запросите время постановки в очередь, время отправки, ответ API и итоговое подтверждение. Не соглашайтесь считать статус «отправлено» доказательством выхода поста.

Какие сервисы автопостинга лучше для бизнеса с CRM и несколькими каналами продаж?

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

Поиск «автопостинг в соцсети сервис» стоит дополнить конкретными условиями: нужная CRM, площадки, форматы, требования к уведомлениям и хранению данных. Сравнивать сервисы следует по этим условиям, а не по общему описанию.

Как настроить автопостинг для продвижения бренда, а не только для заполнения ленты?

Свяжите контент-план с вопросами покупателей, проверяемыми фактами о компании и отдельными показателями результата. Публикации, обращения и AI-упоминания измеряйте раздельно.

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

поставщик услуг — это CRM, агентство или платформа автопостинга и GEO-аналитики?

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

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

Сотрудники не будут пользоваться системой — как снизить этот риск?

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

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

Можно заказать автопостинг, а интеграцию с CRM добавить потом?

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

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

---

Вывод: ошибки в ТЗ фрилансеру начинаются там, где «пост опубликован» принимают за «процесс работает». Для управляемого результата нужны маршрут обращения, автоматическая передача доступных данных, контроль сбоев, раздельные метрики и приёмка по сценариям.

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

Если вам нужны автопостинг и контроль присутствия бренда в AI-ответах, изучите [возможности платформы Молвун] в разделах «Продукт» и «Как работает». Затем сопоставьте их со своим ТЗ — без ожидания, что один инструмент заменит CRM и управление продажами.

---

Про данные. Диапазоны в тексте — ориентиры по открытым источникам и отзывам, а не прайс конкретной компании. Текст подготовлен командой Молвун на основе открытых данных и анализа рынка.