Дашборд із AI: 6 метрик, які щотижня дивиться засновник SMB

Коли засновниця 70-людної SaaS-компанії попросила минулого кварталу "проаудитити її дашборди", вона відкрила Looker з 41 чартом на трьох вкладках. На льоту не змогла назвати три числа, що зрушили за минулий тиждень. Це не проблема дашборду. Це проблема мислення.

Чому SMB-дашборди роздуваються?

Бо нові чарти дешеві, а видалення — політика. Хтось у команді зробив кожен із них з причини. Видалити — наче відкинути цю причину. Тому вони накопичуються.

Визначення: Bloat дашборду — поступове накопичення графіків, кожен з яких мав сенс окремо, але разом не дають жодного рішення.

Рішення — не "зробити кращий дашборд". Рішення — спершу визначити щотижневе питання засновника, а потім лишити лише ті чарти, що на нього відповідають. AI добре допомагає з другим. З першим — не допомагає взагалі.

Скільки метрик потрібно на рівні засновника?

Шість. Не п'ять, не десять. Шість поміщаються на один екран, у 15-хвилинний огляд, і змушують реально пріоритезувати. П'ять спокушають пропустити операційне здоров'я; десять — повертають у режим сканування.

Шість розбиваються на три пари:

• Дві бізнес-результатні метрики — виручка, retention, gross margin. Пара "чи мав цей тиждень значення".
• Дві pipeline-leading метрики — кваліфіковані ліди, активація, time-to-value. Пара "що йде далі".
• Дві метрики операційного здоров'я — runway, ризик відтоку, capacity команди. Пара "що може зламатися".

Як стадія змінює відповідь?

Найбільша помилка — засновник тягне PMF-стадійний дашборд у growth. PMF-метрики — про те, чи продукт любить вузька група; growth — про те, чи компаундиться двигун; scale — про те, чи виживає система.

PMF (до ~$1M ARR, до 30 людей)

• Тижневі активні юзери / клієнти
• Activation rate (перша значуща дія)
• Якісний NPS або "would-be-disappointed" частка
• Cash runway у місяцях
• Концентрація топ-1 клієнта
• Time-to-first-value (signup → перший job done)

Growth (~$1-10M ARR, 30-150 людей)

• Net revenue retention
• New MRR за джерелом (pipeline → win rate)
• Тренд gross margin
• Довжина sales cycle
• CAC payback у місяцях
• Engineering throughput vs roadmap commit

Scale (~$10M+ ARR, 150-500 людей)

• Rule-of-40 (growth % + margin %)
• Розрив logo retention vs net dollar retention
• Pipeline coverage наступного кварталу
• Hiring plan vs actual (lead time)
• Free-cash-flow conversion
• Incident / SLA breach rate

Визначення: Stage-aware метрика — число, що стає діагностичним на одній стадії і шумом на іншій (NPS на PMF — сигнал; той самий NPS на scale — vanity без сегментації).

Де AI реально допомагає?

У трьох конкретних місцях, і "вибрати, що міряти" — не серед них.

1. Переклад намір → запит. "Покажи weekly active customers за signup-cohort, останні 12 тижнів" — засновник не повинен писати SQL. AI пише чорновий запит, ви ревʼюїте JOIN-логіку, шипите.
2. Чесна назва чарту. AI добре пропонує питання, на яке чарт відповідає — і змушує ясність. Якщо чарт не описується питанням — він не повинен жити.
3. Ловить момент "це виглядає дивно". Згодувати LLM останні 12 точок із запитом "помітне щось?" виловлює inflection, який око пропускає у понеділковому скані.

Шаблон промпту для генерації запиту

Допоможи нетехнічному засновнику зібрати запит метрики.

Бізнес-контекст: [напр. "B2B SaaS, ~$3M ARR, ~50 людей"]
Data warehouse: [напр. "BigQuery", "Postgres", "Snowflake"]
Таблиці: [список з 1-рядковим описом]

Метрика: [назва + бізнес-визначення в одне речення]
Розріз: [часовий grain + сегменти, напр. "тижнево, за signup-cohort"]
Рішення, що тригериться цією метрикою: [1 речення — що зміниться, якщо вона зрушить]

Будь ласка:
1. Запропонуй SQL (або BI calc) з явно винесеними припущеннями.
2. Назви 2 найімовірніші місця, де запит помиляється (timezone, dedupe, тощо).
3. Запропонуй єдину назву чарту, яка формулює питання, на яке він відповідає.

Рядок "рішення, що тригериться" — той, що засновники пропускають найчастіше. Без нього AI зробить технічно правильний запит для метрики, на яку ніхто не діятиме.

Tool tip (AIAdvisoryBoard.me): Дисципліна шести метрик тримається лише якщо щотижневий огляд показує рядок Plan → Fact → Gap для кожної — що було обіцяно, що сталося, що означає розрив. Наша операційна система щоденного менеджменту автоматизує саме цей вид по компанії, тож огляд починається з gap, а не з чарту. 7-денна діагностика показує, які з ваших чартів виживають у новій системі, а які тихо помирають. Дивіться на https://aiadvisoryboard.me/?lang=en.

Manager scan (2-хвилинний digest)

• Шість метрик на одному екрані — решта в окремому ops-вʼю
• Кожна метрика з Plan (обіцяне) і Fact (що сталося)
• Gap-рядок словами, не числами — "промахнули активацію на 14 бо onboarding-email зламався у вівторок"
• Стадія підписана у заголовку — щоб команда знала, чому саме ці шість
• Owner на метрику — інженери не володіють виручкою, sales не володіє latency
• Поріг на метрику — число, що тригерить розмову, не просто колір
• Sparkline за 12 тижнів — щоб напрямок переважив однотчковий шум
• Token / volume / "active user" чарти свідомо виключені з засновницького вʼю
• Раз на квартал — ревʼю, чи ці шість усе ще правильні для цієї стадії
• Один copy/paste шаблон на метрику, щоб новий аналітик відбудував дашборд за день

Micro-case (що змінюється за 7-14 днів)

У сервісної компанії на 90 людей був дашборд з 32 чартів, який CEO зізналася що відкриває "раз на тиждень, потім закриває". Замінили на шість метрик growth-стадії: NRR, qualified pipeline за джерелом, тренд gross margin, довжина sales cycle, CAC payback, engineering throughput vs commit. Перший огляд зайняв 22 хвилини й виявив дві проблеми, яких ніхто не називав — sales cycle подовжився на 11 днів проти попереднього кварталу, інженери недовозили проти commit чотири спринти поспіль. Жодного в 32-чартній версії не було видно, бо обидва жили line-items усередині більших графіків. До третього тижня CEO вела огляд сама і ставила гостріші питання кожному функціональному лідеру. Старий дашборд не видалили — понизили до "deep dive" посилання, яке ніхто не клікав.

Note on this case: Цей приклад ілюстративний — на основі типових патернів, які ми бачимо у компаніях 30-500 людей, не конкретний клієнт. Конкретні числа — округлені діапазони, не гарантії.

Tool tip (AIAdvisoryBoard.me): Більшість дашбордів засновників повертаються до bloat, бо немає автоматизованого Plan → Fact → Gap циклу, який щопонеділка штовхає шість метрик назад засновнику. Наша система тягне Plan із тижневих комітів, Fact з операційних систем і пише Gap-наратив звичайною мовою — щоб дашборд не залежав від того, чи засновник памʼятає відкрити його. Стартуйте 7-денну діагностику на https://aiadvisoryboard.me/?lang=en.

FAQ

Чи може AI вибрати шість метрик за мене? Ні — і будь-який інструмент, що це обіцяє, продає шаблон, не систему. Вибір метрик вимагає знання вашої стадії, вашого бутилкового горла і стратегічної ставки. AI допомагає після цього рішення, не до.

Як щодо leading vs lagging? Pipeline-leading пара покриває leading. Бізнес-результатна пара — переважно lagging, і це навмисно. Потрібні обидва: leading для дії, lagging для accountability.

Як часто шість мають мінятися? Раз на квартал — здоровий ритм. Рідше — пропускаєте перехід стадій; частіше — губите порівнянність. Призначте квартальний "metric audit" як підготовку до борди.

CFO хоче 30 метрик. Що робити? CFO потрібно 30 — для closing'у, аудиту і моделювання. Засновнику — шість. Це різні роботи. Шість — щотижневий огляд засновника; 30 живе у фінансовому back-office, не у понеділку CEO.

Шість інші для B2C SMB? Структура пар тримається, назви міняються. B2C свопить "qualified pipeline" на "weekly active buyers" і "sales cycle" на "repeat purchase interval". Та сама дисципліна, інший словник.

Висновок

Засновницький дашборд — не data-продукт. Це decision-артефакт. Шість метрик, один екран, одне тижневе питання — решта це прокрастинація, замаскована під ретельність.

Виберіть стадію, на якій ви насправді. Виберіть шість. Дайте AI зібрати запити. Видаліть усе інше із засновницького вʼю.

Якщо хочете систему, яка щодня показує Plan → Fact → Gap по всій компанії — подивіться, як працює 7-денна діагностика на https://aiadvisoryboard.me/?lang=en.