Как подготовить задание на дашборд: гайд для маркетолога и разработчика

Марина С.

3 мин.

23

Дата публикации: 29.07.2026

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

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

1. Цель дашборда и итоговый результат

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

• Какую конкретную задачу решает дашборд: контроль продаж, загрузку производства, эффективность отдела, движение заявок?
• Что сейчас неудобно или недоступно, из-за чего вообще возникла идея сделать отчёт?
• Как выглядит итоговый результат — что именно человек видит, открыв дашборд утром?

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

2. Пользователи и роли доступа

Дашборд для руководителя и дашборд для менеджера — разные интерфейсы, даже если данные берутся из одной системы.

• Кто будет смотреть отчёт: руководитель, РОП, менеджер, снабженец, юрист?
• Нужна ли персонализация — например, чтобы менеджер видел только свои сделки, а руководитель отдела видел всю команду?
• Какие данные должны быть закрыты для одних ролей и открыты для других?

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

3. Метрики и KPI: что считать и как

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

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

4. Источники данных

Дашборд редко строится на одной сущности CRM, и это важно выяснить заранее, а не по ходу разработки.

• Из каких сущностей брать данные: лиды, сделки, контакты, компании?
• Используются ли смарт-процессы — часто нестандартная отчётность (сервис, HR, снабжение) строится именно на них, а не на стандартных сделках.
• Нужна ли интеграция с внешними системами: 1С (остатки, оплаты), рекламные кабинеты, Google-таблицы, Excel?
• Есть ли пользовательские поля, без которых аналитика будет неполной? Стандартных полей CRM почти всегда не хватает для содержательной сегментации.

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

5. Инструменты и технологии

• Подойдёт ли встроенный BI-конструктор Битрикс24, или задача сложнее и нужен внешний BI-инструмент?
• Требуется ли BI-коннектор для выгрузки данных во внешние системы, например Power BI или Looker Studio?
• Есть ли ограничения по бюджету или лицензиям, которые сужают выбор инструмента?

6. Визуализация и периодичность обновления

Проектирование интерфейса отчёта — тоже часть задания, а не дизайнерская деталь.

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

Чек-лист для технического задания

Короткий список вопросов, которые стоит закрыть до старта разработки — маркетолог или заказчик может пройтись по нему сам, а разработчик использовать как основу ТЗ:

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

Типичная ошибка при постановке задачи

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

Итог

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