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

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

Чому 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.