Дашборды в 2026: собираем тот, которым будут пользоваться

Типовая ситуация – дашборд сделали, показали команде, все сказали, что это полезно и будут пользоваться. Через месяц оказывается, что заходов в отчет почти нет, а ваши коллеги по-прежнему просят выгрузки.

Обычно это списывают на то, что дашборд был сделан плохо (не те данные или визуализации). Но чаще дело оказывается в другом: дашборд просто не собран под работу, которую человек делает регулярно. Он собран под тему.

Например, «нужен дашборд по поддержке» – это тема.

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

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

В этой статье разбираем, как за 5 шагов собрать диагностический дашборд под задачу на примере удовлетворённости клиентов поддержкой.

Шаг 1. Выбрать задачу

Задача – это работа, которую пользователь делает регулярно и будет делать дальше, есть у него дашборд или нет. У неё 3 признака.

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

Как найти задачу

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

Что стоит спросить:

В какой момент вы про это вспоминаете? Здесь ищем триггер. Ответ будет вроде «на понедельничном созвоне», «когда руководитель спрашивает» или «когда приходят жалобы». Это и есть момент, ради которого дашборд открывают.
Что вы в этот момент хотите понять? Здесь появляется первая формулировка задачи. Пока в общих словах, но уже не просто «поддержка», а «нормально ли мы отрабатываем» или «почему клиенты недовольны».
Что делаете дальше, чтобы разобраться? Это реальная последовательность действий: куда человек идёт, что открывает, что с чем сравнивает. Тот самый маршрут, который дашборд должен повторить.
А в чём обычно оказывается дело? Самый полезный вопрос: в ответ человек перечислит привычные подозрения вроде «обычно это возвраты» или «чаще всего кто-то из новеньких». Это его рабочие гипотезы, из них дальше вырастают метрики и разрезы. Записывайте дословно, пригодится на шагах 3 и 5.
Чем всё обычно заканчивается? Это проверка на решение. Если в ответ звучит «ну, посмотрели и дальше работаем», то задачи нет, а есть привычка смотреть.

Знаете, как человек решает задачу сейчас, – считайте, что полдела сделано. Этот маршрут и переносим в дашборд: не изобретаем новый путь, а делаем существующий быстрее.

Одна задача = один дашборд

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

Поддержка

Исследовать удовлетворённость клиентов службой поддержки
Оценить, справляется ли команда с потоком обращений
Оценить, насколько эффективно работает бот в поддержке

Продажи

Выяснить, из-за чего упала выручка в этом месяце
Найти товары, из-за которых снижается маржа
Локализовать место, где мы теряем клиентов в воронке

Задачи разные, значит, и дашборды под них будут разными. А дашборд, который пытается закрыть все 3 задачи сразу, не закроет ни одной.

Дальше мы будем собирать дашборд под одну из этих задач. Возьмем эту – исследовать удовлетворённость клиентов службой поддержки.

Шаг 2. Выбрать ключевую метрику

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

Задача → Ключевая метрика

Исследовать удовлетворённость клиентов службой поддержки (наш выбор) → Индекс удовлетворенности клиентов (CSAT) (открыть на карте метрик)
Оценить, справляется ли команда с потоком обращений → Среднее время ожидания (открыть на карте метрик)
Оценить, насколько эффективно работает бот в поддержке → % авто-решенных обращений (открыть на карте метрик)

Кандидатов на роль ключевой метрики обычно несколько, и тут легко ошибиться.

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

Лучше подойдёт «Среднее время ожидания» – по ней видно, стали клиенты ждать дольше или нет.

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

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

Смотрим на примере

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

Шаг 3. Собрать поддерживающие метрики

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

Начинайте с гипотез пользователя из первого шага: что он назвал сам, то в дашборде быть обязано. Иначе он ему не поверит и пойдёт за выгрузкой.

Дальше открывайте карту метрик и проверяйте, не пропустили ли вы что-то влияющее. Смотрите на те метрики, что стоят в 1–3 шагах от ключевой. Дальше связь идёт через столько промежуточных звеньев, что по движению метрики уже не понять, при чём тут ключевая.

Оставшихся кандидатов разбираем по 3-м группам.

Действие — рычаги, то, на что можно повлиять напрямую.

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

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

Результат — объём потока, сколько всего стоит за ключевой метрикой.

Это количество обращений для оценки поддержки, количество заказов для среднего чека, количество сессий для конверсии. Такая метрика тоже нужна всегда: падение оценки с 4,8 до 4,2 — это провал на 1000 отзывов и флуктуация на 10.

Диагностика — метрики, на которые нельзя повлиять напрямую, но которые показывают здоровье процесса.

Часто такая метрика работает зонтиком над группой рычагов: «Соблюдение SLA» само по себе не управляемо, зато сразу говорит, держим ли мы норматив вообще. Поэтому и правило про 1–3 шага для них мягче, ведь они описывают процесс более масштабно, а не просто отдельное звено.

Метрик на дашборде стремитесь держать до 10, потому что больше десятка чисел человек одновременно в голове не держит. Если набор упорно не влезает, то, скорее всего, дашборд пытается закрыть несколько задач вместо одной. Но правило не жёсткое: одиннадцать-двенадцать метрик, если каждая работает, лучше, чем выброшенная метрика-рычаг.

Смотрим на примере

Получилось 9 метрик:

Действие — время первого ответа, время до решения, время обработки обращения, доля решённых обращений, % авто-решённых обращений, оценка процесса возврата.

Результат — количество обращений.

Диагностика — обращений на агента, соблюдение SLA. В дашборде они стоят плашками под ключевой метрикой, каждая с текущим значением и изменением.

Шаг 4. Добавить метрики-противовесы

В идеале, работа с дашбордом заканчивается тем, что человек предпринимает какое-то действие (берётся за рычаг). И почти каждый рычаг можно выкрутить так, что нужная метрика вырастет, а другая ухудшится.

Противовесы — это метрики, по которым видно цену действия. Работают они в паре с метриками действия (рычаги):

Влияем на Что может ухудшиться «Доля обращений без оператора»: дорабатываем бота, чтобы разгрузить людей «Доля переоткрытых обращений»: бот закрыл диалог, а клиент вернулся с тем же вопросом «Норматив ответа (SLA)»: сокращаем, чтобы клиенты ждали меньше «Индекс удовлетворённости команды»: норматив держат за счёт сотрудников, и они выгорают

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

Смотрим на примере

Противовесов два.

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

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

Шаг 5. Определить разрезы

Метрики отвечают на вопрос «за счёт чего», а разрезы – на вопрос «где именно». Ответ, ради которого собирался дашборд, выглядит как пара: проблемная метрика × проблемный разрез.

Кандидатов ищите в двух местах:

В ответах пользователя. Какие гипотезы он проверяет обычно, из раза в раз («чаще всего дело в возвратах», «сначала смотрю по каналам»), и как режет данные в выгрузках.
В карточках метрик. У каждой метрики есть список разрезов, в которых её имеет смысл смотреть. У нас такой список будет собран в Атласе.

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

Что показывать в самих разрезах

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

Ключевую метрику показываем в разрезах всегда.
Поддерживающую пользователь выбирает переключателем, причём одну на все разрезы сразу, чтобы срезы оставались сравнимыми между собой.
Объём потока тоже держим на виду всегда.

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

Почему нужна фильтрация

Собранный так дашборд пользователь проходит одним из двух маршрутов.

Прямой. Ключевая метрика просела → среди поддерживающих видно проблемную → смотрим её по разрезам → находим, где именно.

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

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

Смотрим на примере

Разрезов 4, и каждый применим ко всем метрикам набора:

Тип обращения. Вопрос про доставку и вопрос про возврат обрабатываются по-разному, и ломается обычно что-то одно.

Канал. Чат, почта и телефон живут по своим правилам: в чате ждут ответа минуту, а в почте сутки.

Специалист. Показывает, проблема общая или у конкретных людей.

Участие специалиста. Обращение закрыл бот или подключался человек. Здесь видно, справляется автоматизация или только откладывает вопрос.

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

Финал

Дашборд не заменяет мышление, а упрощает его. Человек всё так же проверяет свои гипотезы, но при этом не собирает данные руками и не ждёт выгрузку два дня.

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

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

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