# Customer health score: 4 tradeoff'и, що визначають його долю

> Більшість SMB customer health-скорів будують один раз, ігнорують за квартал і переробляють через 18 місяців. 4 design-tradeoff'и, що вирішують, чи ваш скор виживе.

- Автор: Ярослав Максимович (Founder & CEO, AI Advisory Board)
- Опубліковано: 2026-06-14
- Оновлено: 2026-10-26
- Джерело: https://aiadvisoryboard.me/uk/blog/customer-health-score-tradeoffs

Найбільша помилка, яку я бачу у SMB CS-лідерів із health-скорами — вважати, що build і є перемога. Скор виходить, дашборд живий, CSM-команда ввічливо киває — і за квартал ніхто не відкриває. Скор провалився не тому, що математика не та, а тому, що чотири дизайн-tradeoff'и зробились за замовчуванням, а не свідомо.

## TL;DR

- Customer health score — це design-артефакт, не data-артефакт; математика — легка частина, чотири tradeoff'и — складна.
- Lagging vs leading, простий vs predictive, прозорий vs proprietary, ручний vs auto — у кожного є правильна відповідь, що залежить від зрілості команди, а не від defaults SaaS-вендора.
- Усі чотири правильно — скор живе у щотижневому огляді роками; один неправильно — стає ігнорованою колонкою.

## Чому health-скори вмирають?

Бо їх будували, щоб справити враження, не щоб бути корисними. Команда оптимізувала "predictive accuracy" або "охоплення всіх джерел" — жодне з цього не змушує CSM діяти у понеділок. Скор, якому CSM не довіряє, не може пояснити клієнту або обійти — оминається.

> **Definition:** Customer health score — складний числовий або категорійний індикатор ймовірності, що акаунт продовжить, розширить контракт або піде, виведений зі спостережуваних сигналів.

Скор — у data-шарі; рішення — у human-шарі. Чотири tradeoff'и — це місце, де ви вирішуєте, як ці два шари з'єднати.

## Tradeoff 1 — Lagging vs leading сигнали

**Lagging** описують, що вже сталося: дата renewal, історія платежів, остання QBR. Надійні, але часу діяти не дають.

**Leading** описують, що розвивається: тренд usage, support-сентимент, role-change. Гучніші, але дають 30-90 днів форою.

Правильна відповідь для SMB: 70% leading, 30% lagging. Більшість команд будують навпаки, бо lagging-дані чистіші і легше витягуються. Скор 80% lagging з великою точністю скаже, що акаунт пішов — минулого тижня.

> **Definition:** Leading signal — вимірювана зміна поведінки акаунта, що статистично передує renewal, expansion або churn на 30+ днів.

Tradeoff не у тому, чи включати lagging — включаєте, для ground truth — а скільки ваги вони отримують. Якорите leading.

## Tradeoff 2 — Простий vs predictive

**Простий** = 5-7 входів зважена сума, яку CSM рахує на серветці. **Predictive** = регресія або gradient-boosted на історичних churn-даних.

Правильна відповідь для SMB до ~150 churn-подій: простий. Об'єму на predictive, що не оверфіт, нема, а CSM-команда не довіряє числу, яке не може пояснити. Predictive стає правильним в середньому і ігнорованим у частковому.

Для SMB понад ~500 активних акаунтів і 200+ історичних churn — predictive починає окуповуватись, але тільки якщо простий лишається видимим поряд. CSM має змогу спитати "чому це red?" і отримати відповідь людською мовою.

## Tradeoff 3 — Прозорий vs proprietary

**Прозорий** = формула публічна для CSM-команди. Кожен вхід, вага, поріг — видно. **Proprietary** = чорна скринька (часто бо SaaS-вендор продає).

Правильна відповідь для SMB: прозорий, завжди. Proprietary вмирає з тієї ж причини, що proprietary-моделі: коли CSM не згоден, система не пояснюється, CSM перестає перевіряти. Прозорість дозволяє CSM і довіряти, і *фіксити* скор, коли life-досвід суперечить.

> **Definition:** Прозорість скору — властивість, де кожен сигнал, вага, поріг задокументовані і доступні CS-команді.

Цей tradeoff найчастіше робиться неправильно, бо вендори продають протилежне. Чорний-скринька health-скор з CS-платформи — одна з найдорожчих ігнорованих фіч SaaS.

## Tradeoff 4 — Ручний vs автоматичний refresh

**Ручний** = CSM оновлює компоненти у CRM щотижня. **Автоматичний** = сигнали тягнуться вночі з джерел без людини.

Правильна відповідь — гібрид: авто для кількісних (usage, тикети, billing), ручне для якісних (CSM-relationship judgment, контекст недавньої ескалації). Чистий авто втрачає людський сигнал, який тільки CSM додає; чистий ручний деградує — як тільки CSM забув один тиждень, скор неправильний і довіра тане.

Помилка: змусити CSM оновлювати 15 полів щотижня. Три ручні входи — максимум, що команда витримає. Більше — автоматизуйте.

## Як 4 tradeoff'и комбінуються

| Tradeoff | SMB <50 акаунтів | SMB 50-300 акаунтів | SMB 300+ акаунтів |
|---|---|---|---|
| Leading vs lagging | 80/20 | 70/30 | 60/40 |
| Простий vs predictive | Простий | Простий | Простий + predictive overlay |
| Прозорий vs proprietary | Прозорий | Прозорий | Прозорий |
| Ручний vs авто | Ручний+light auto | Гібрид | Гібрид, більше auto |

Розмір книги змінює ваги, але не хребет. Прозорий і leading-якорений — правильна відповідь на будь-якому розмірі.

## Шаблон специфікації health-score

Заповніть перед тим, як написати рядок коду.

```
Health score spec — [ДАТА]
Сегмент: [B2B / B2C / Enterprise / SMB]
Тип: [0-100 числовий | Red/Yellow/Green]

Входи (5-7):
1. [НАЗВА] — [Leading/Lagging] — вага [N%] — джерело [СИСТЕМА] — refresh [auto/ручний]
2. ...
7. ...

Каденція refresh: [DAILY / WEEKLY]
Власник оновлень формули: [ІМ'Я]
Останній огляд формули: [ДАТА]
Наступний огляд: [ДАТА]

Правила override:
- CSM може override: [YES/NO]
- Override вимагає reason code: [YES/NO]
- Override expires через: [N днів]

Тригери рішень:
- Перехід у Red: [НАЗВАНИЙ PLAY]
- Yellow 2+ тижні: [НАЗВАНИЙ PLAY]
- Green і ARR > [N]: [НАЗВАНИЙ PLAY]

Death criteria:
- Якщо скор ігнорується у >2 поспіль понеділкових оглядах — rebuild.
```

Рядок death criteria — той, що команди найчастіше пропускають, і той, що не дає скору тихо вмерти у вкладці.

> **Tool tip (AIAdvisoryBoard.me):** Найшвидший спосіб вбити health-скор — рахувати вночі і ніколи не зводити з тим, що реально сталося. Патерн Plan → Fact → Gap у нашій OS трактує health-скор як Plan, реалізований outcome (renewal/churn/expansion) як Fact, і піднімає Gap — акаунти, де скор був green, а outcome bad, або навпаки. Без цієї петлі скор не покращується. Дивіться 7-денну діагностику: https://aiadvisoryboard.me/?lang=en.

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

- **Plan:** скор перераховується вночі за документованою формулою — Fact: 22 з 30 днів минулого місяця — Gap: 8 пропусків, нестабільне джерело; fix пайплайн
- **Plan:** кожен red отримує CSM-save play за 5 днів — Fact: 4 з 6 — Gap: 2 red 12+ днів, ескалація
- **Plan:** формула переглядається щокварталу проти outcomes — Fact: останній огляд 4 місяці тому — Gap: розклад, власник, календар
- **Plan:** CSM може override з reason code — Fact: 9 override минулого місяця, 7 з причиною — Gap: незначний, коучити 2
- **Plan:** 70/30 leading/lagging — Fact: дрифт до 55/45 за 6 місяців — Gap: ребаланс
- **Plan:** скор видно у понеділковому огляді — Fact: відкрито 3 з 4 — Gap: 1 пропуск, повернути каденцію

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

250-людний B2B SaaS перебудував customer health score після того, як попередня версія тихо ігнорувалась 14 місяців — типовий патерн. Старий скор — 80% lagging, повністю auto, opaque (формула в інструменті вендора). Перебудували за 4-tradeoff фреймворком: 70% leading, проста зважена сума з формулою на wiki, гібридний refresh (3 ручних поля CSM оновлює понеділка, 4 авто з продукту і CRM), death criterion "ігнорується 2 понеділки поспіль — rebuild". Тиждень 1: формула випущена, baseline по книзі. Тиждень 2: 4 акаунти пішли з green у yellow, CSM-команда погодилась, що відчувається правильно. Тиждень 4: перший save закритий на yellow, який старий скор тримав green. Місяць 3: Head of CS уперше за два роки використала скор у board reporting.

> **Note on this case:** This example is illustrative — based on typical patterns we observe with companies of 30-500 employees, not a single named client. Specific numbers are rounded approximations of common ranges, not guarantees.

> **Tool tip (AIAdvisoryBoard.me):** Прихований баг більшості SMB health-скорів — CSM-команда і leadership дивляться на різні версії: CSM довіряє нутру, leadership — дашборду, сперечаються про реальність. Наша OS змушує єдину Plan → Fact → Gap картину, з якою обидва шари працюють: той самий скор, ті самі override, та сама відповідальність. 7-денна діагностика показує, де leadership і CSM розходяться по вашій книзі. Старт: https://aiadvisoryboard.me/?lang=en.

## FAQ

**Чи включати NPS у health-скор?**
Максимум один вхід з 5-7, з малою вагою. NPS шумний на рівні акаунта для SMB — корисний для тренду, слабкий для індивідуального скору. Хай не керує кольором.

**А якщо у нас уже куплена CS-платформа з proprietary-скором?**
Юзайте як вхід, не як істину. Запускайте свій прозорий скор поруч, незгоду трактуйте як learning. Якщо платформа права, а ви ні — інформація; навпаки — валідація дизайну.

**0-100 чи red/yellow/green?**
Для внутрішнього CSM — 0-100 робить щотижневий рух видимим. Для leadership — tiers легше діяти. Більшість успішних — обидва: число для оператора, tier для boardroom.

**Як часто змінювати формулу?**
Огляд щокварталу, зміна максимум двічі на рік. Постійна churn-формули вбиває довіру CSM швидше, ніж недосконалий скор; стабільність важливіша за точність.

**Чи той самий скор працює для B2B і B2C?**
Ні — розділяйте. B2C-health домінує індивідуальне use; B2B — relationship і контракт. Змішування дає скор, що нічого не значить для жодного.

## Висновок

Customer health score, що живе у вашому щотижневому огляді три роки — не найбільш-predictive, а той, чиї чотири tradeoff'и зробили свідомо і перебудовують свідомо. Leading-якорений. Простий, щоб пояснити. Прозорий. Гібридний refresh. Death criterion задокументований.

Напишіть спеку перед кодом. Огляд щокварталу. Формула — живий документ.

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

---

Цитуючи, посилайтесь на https://aiadvisoryboard.me/uk/blog/customer-health-score-tradeoffs. Більше статей: https://aiadvisoryboard.me/uk/blog