Дашборд для отдела продаж на Vue: какие метрики выводить

Дашборд для отдела продаж на Vue я обычно начинаю не с вёрстки графиков, а с разговора с РОПом: какие цифры он реально смотрит каждое утро и какие решения на их основе принимает. Если пропустить этот шаг, получится красивая панель с двадцатью виджетами, из которых используют два. За последние пару лет я собрал несколько таких дашбордов для интернет-магазинов на WooCommerce и для B2B-компаний с CRM на Bitrix24 и amoCRM, и ниже - рабочий список метрик и подход к архитектуре, который я использую сейчас.

Зачем отделу продаж дашборд на Vue, а не готовая BI-система

Google Data Studio, Power BI и встроенная аналитика CRM закрывают базовые отчёты, но упираются в три вещи: скорость обновления данных, кастомную логику расчёта метрик и интеграцию нескольких источников в одном экране. Когда нужно свести в одну таблицу заявки из Tilda-формы, оплаты через эквайринг T‑Bank, статусы доставки СДЭК и переписку из Telegram-бота на aiogram - готовая BI-система превращается в набор костылей и коннекторов, за каждый из которых ещё и платишь отдельно.

Vue в этой задаче даёт то, чего нет в конструкторах: реактивность из коробки для живых цифр, компонентный подход для повторяющихся виджетов (карточка менеджера, воронка, график по дням) и полный контроль над тем, как считается каждая метрика. На практике дашборд на Vue 3 с Pinia для стейта и Chart.js или ECharts для графиков собирается быстрее, чем кажется, если заранее понятна структура данных.

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

Какие метрики выводить на дашборд отдела продаж

Я делю метрики на три блока и стараюсь не смешивать их на одном экране - у РОПа, менеджера и собственника разные горизонты внимания.

Метрики воронки и конверсии

Базовый набор, без которого дашборд бесполезен:

• количество лидов за период с разбивкой по источнику (сайт, реклама, входящие звонки, Telegram-бот);
• конверсия из лида в квалифицированный контакт;
• конверсия из квалифицированного контакта в сделку;
• конверсия из сделки в оплату;
• средний цикл сделки в днях - считаю от создания карточки до перевода в статус «оплачено»;
• количество сделок, зависших на одном этапе дольше среднего срока - это сигнал для РОПа, а не для собственника.

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

const conversionRate = computed(() => {
  if (!leads.value.length) return 0
  const won = deals.value.filter(d => d.status === 'won').length
  return ((won / leads.value.length) * 100).toFixed(1)
})

Метрики по менеджерам

Этот блок - самый чувствительный политически, поэтому доступ к нему обычно ограничиваю ролью РОПа и выше. Вывожу:

• количество обработанных лидов на менеджера за день/неделю;
• среднее время первого ответа на заявку - для B2C-магазинов критично, у меня в одном проекте сокращение этого показателя с 40 до 12 минут подняло конверсию в оплату на 6 процентных пунктов за квартал;
• выручка на менеджера и средний чек;
• процент просроченных задач в CRM (задачи, которые должны были быть выполнены, но статус не менялся).

Финансовые показатели

Здесь уже интересно собственнику и финансовому директору:

• выручка по дням/неделям с сравнением к прошлому периоду;
• средний чек и его динамика;
• ROI по каналам привлечения - если есть данные по расходам на рекламу, свожу их с выручкой из CRM;
• процент возвратов и отмен заказов (для e‑commerce с доставкой через СДЭК это отдельная больная метрика - часть отмен происходит уже после отправки).

Важный момент по хранению: если дашборд агрегирует контакты и переписку клиентов, держите базу и бэкенд на серверах в РФ - это требование 152-ФЗ по локализации персональных данных, и зарубежные таблицы вроде Google Sheets или Airtable для хранения телефонов и почты клиентов не подходят, даже если удобны для черновой аналитики.

Откуда брать данные: CRM, эквайринг, СДЭК, мессенджеры

Самая долгая часть проекта - не вёрстка графиков, а стыковка источников. На практике набор такой:

• CRM - amoCRM и Bitrix24 отдают данные по REST API с вебхуками на изменение статуса сделки, это основной источник для воронки;
• Эквайринг - если магазин на WooCommerce с оплатой через T‑Bank, я забираю статусы платежей через вебхуки эквайринга, а не жду синхронизации заказа в CRM, потому что она может опаздывать на 10-15 минут;
• Доставка - API СДЭК даёт статусы «передан курьеру», «в пути», «вручен», «возврат» - это база для метрики возвратов;
• Мессенджеры - если лиды приходят через Telegram-бота на aiogram, время первого ответа беру прямо из логов бота, а не из CRM, куда переписка попадает с задержкой.

Для связки источников без написания отдельного бэкенда под каждый вебхук я часто использую n8n - он берёт на себя приём вебхуков, трансформацию данных и запись в промежуточную базу, откуда Vue-дашборд уже читает готовые агрегаты через свой API. Для типовых интеграций (CRM + эквайринг + СДЭК) у меня есть готовые скрипты и коннекторы под такие связки, которые ускоряют старт проекта на пару недель по сравнению с разработкой с нуля.

Архитектура дашборда: что выбрать для визуализации

Стек, который я использую чаще всего: Vue 3 + Composition API, Pinia для стейта, Vite для сборки. Для графиков выбор зависит от сложности:

Для 90% дашбордов отдела продаж хватает ECharts - она закрывает и воронку, и тепловые карты активности менеджеров, и обычные графики выручки без танцев с бубном.

Бэкенд под агрегацию данных обычно поднимаю на Node.js с периодическим опросом CRM-API и приёмом вебхуков от эквайринга и СДЭК, данные складываю в PostgreSQL. Дашборд не ходит напрямую в CRM при каждой загрузке страницы - это убивает скорость и упирается в лимиты API у amoCRM и Bitrix24.

Кейс: дашборд для отдела продаж интернет-магазина на WooCommerce

Показательный проект - магазин на WooCommerce с оплатой через T‑Bank и доставкой через СДЭК, отдел продаж из 4 менеджеров, лиды приходили с сайта и из Telegram-бота. Задача: РОП тратил по 40 минут утром на сборку отчёта из трёх систем вручную.

Что сделал:

• настроил приём вебхуков от WooCommerce и T‑Bank через n8n, данные лились в PostgreSQL;
• подключил СДЭК API для статусов доставки и возвратов;
• собрал дашборд на Vue 3 с тремя экранами: воронка и конверсия, метрики по менеджерам, финансовая сводка;
• добавил алерты в тот же Telegram-бот - если заявка висит без ответа больше 20 минут, бот пингует РОПа.

Результат через два месяца: время сборки утреннего отчёта ушло до нуля - все смотрят один экран, среднее время первого ответа сократилось почти втрое, а РОП впервые увидел, что треть отмен заказов происходит уже после передачи в СДЭК - это была отдельная зона роста, о которой раньше просто не было данных.

Сроки и стоимость разработки

Дашборд/BI-панель на Vue.js у меня стоит от 90 000 ₽ - в эту сумму входит фронтенд с графиками, авторизация по ролям и подключение одного источника данных (например, CRM). Дальше цена растёт от количества интеграций и сложности агрегации:

• подключение эквайринга или СДЭК как дополнительного источника - обычно оформляю как комплексную интеграцию, от 40 000 ₽ за каждый источник, в зависимости от того, есть ли готовое API или нужен парсинг личного кабинета;
• автоматизация сбора данных через n8n вместо самописного бэкенда - от 25 000 ₽;
• Telegram-бот с алертами по метрикам - от 30 000 ₽ отдельным модулем;
• техподдержка дашборда после запуска (мониторинг вебхуков, актуализация под изменения в API CRM) - от 15 000 ₽/мес.

На рынке цены на похожие дашборды у студий и фрилансеров варьируются в среднем от 150 000 до 400 000 ₽ за проект с несколькими интеграциями - разброс большой из-за того, что часть исполнителей закладывает готовые BI-конструкторы поверх которых накручивают лицензии. Сроки по опыту: минимальный дашборд с одним источником данных - 2-3 недели, с полноценной агрегацией из CRM, эквайринга и доставки - 5-7 недель.

Частые вопросы

Можно ли обойтись без бэкенда и тянуть данные из CRM напрямую в браузер?

Технически да, но на практике это упирается в лимиты API CRM-систем и скорость загрузки - при 5-10 виджетах на экране прямые запросы из браузера начинают тормозить и периодически ловить rate-limit. Промежуточный бэкенд с агрегацией и кэшированием снимает эту проблему и заодно скрывает API-ключи от фронтенда.

Сколько источников данных реально нужно на старте?

Я рекомендую начинать с одного-двух - CRM и эквайринга, этого достаточно для базовой воронки и финансовых метрик. СДЭК, мессенджеры и рекламные кабинеты подключаю вторым этапом, когда понятно, что первая версия дашборда реально используется командой.

Как часто должны обновляться данные на дашборде?

Для большинства метрик воронки и выручки хватает обновления раз в 5-15 минут через вебхуки или опрос API - это не режим реального времени, но для управленческих решений его и не нужно. Реальное время имеет смысл только для алертов по просроченным заявкам.

Стоит ли брать готовую BI-систему вместо разработки дашборда на Vue?

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