Прогноз churn без data team: 4-крокова модель для SMB

Коли Head of CS у 90-людному SaaS сказала мені, що їй потрібна "ML-модель для прогнозу churn", я спитав, що вона робитиме зі скором у понеділок зранку. Вона замислилась. Саме ця пауза — причина, чому більшість SMB-проєктів з прогнозу churn вмирають: їх будують до того, як хтось визначив понеділкову дію.

Чому SMB-моделі churn не доходять до прод?

Бо їх скоупують як data-science проєкт, а не як CS-операцію. Команда ганяється за логістичною регресією на 18 місяцях когортних даних, наймає контрактора, через 14 тижнів понеділкового workflow все ще нема. А тим часом два акаунти тихо пішли.

Definition: Сигнал churn — вимірювана зміна поведінки акаунта, що статистично корелює з відмовою впродовж 30-90 днів.

Чесна версія: Head of CS, який знає книгу акаунтів, ментально ранжує ризикові за 20 хвилин. Робота моделі — не замінити це судження, а гарантувати, що жоден акаунт не пропаде, коли команда виросте більше, ніж одна людина може утримати в голові.

Як виглядає 4-крокова модель?

Чотири кроки, щотижня, без ML-інфраструктури. Кожен крок — конкретний deliverable, що CS-лід веде в таблиці плюс LLM.

Крок 1 — 9 поведінкових сигналів

Не 50. Дев'ять. Сигнали діляться на три групи: usage drift, relationship drift, support drift.

Usage drift (3 сигнали):

• Логіни на активне місце впали на 30%+ vs 4-тижневе середнє
• Використання core-функції впало на 40%+ для workflow, який ви продали
• Зупинилось додавання нових юзерів (нема нових місць 60 днів, коли раніше було щомісячно)

Relationship drift (3 сигнали):

• Champion пішов із компанії (зміна ролі, LinkedIn-сигнал, або out-of-office, що стає постійним)
• Exec sponsor перестав ходити на QBR або останні 2 зустрічі переносив
• Renewal owner з боку клієнта змінився і не вийшов на зв'язок

Support drift (3 сигнали):

• Тикетів на 50%+ більше і сентимент став негативним
• Повторні тикети з тієї ж root-cause (3+ за 30 днів)
• Останній NPS або open-text містив порівняння з конкурентом

Ці 9 покривають ~80% B2B SMB-churn-кейсів, які я бачу. Більше не треба, поки ви не пропрацювали ці 6 місяців.

Крок 2 — Скор кожного акаунта щотижня

Плоско-зважений скор: одна колонка на сигнал, 1 якщо є, 0 якщо нема. Сума з 9. Tier:

• 0-2: green (звичайний моніторинг)
• 3-5: yellow (проактивний outreach цього тижня)
• 6-9: red (ескалація до exec, save play)

Definition: Save play — визначена послідовність дій, яку CS-команда запускає по red-акаунтах: discovery-call, активація exec sponsor, переписування success plan, документована точка рішення на день 30.

Не зважуйте сигнали по-різному, поки нема даних. Рівне зважування б'є фальшиву точність перші 3-6 місяців. Після 25-50 churn-подій — подивіться, які сигнали спрацьовували перед втратою, і переоцініть ваги.

Крок 3 — AI пише account-level summary

Це крок, який реально змінює навантаження. По кожному yellow/red акаунту LLM читає:

• Останні 30 днів usage-телеметрії (CSV-експорт)
• Останні 90 днів support-тикетів (тема + перше повідомлення)
• Останні 4 тижні нотаток зустрічей (якщо CS-команда їх веде)
• NPS open-text за останній квартал

І видає 6-рядковий narrative: що дрифтить, хто залучений, ймовірна root cause, одне запитання для наступного outreach. З цим narrative CSM іде на save-call.

Крок 4 — Понеділковий 30-хвилинний огляд

Head of CS плюс 1-2 senior CSM витрачають 30 хвилин понеділка на red і high-yellow акаунти. Кожен отримує власника, призначення save-play, дату check-in. Список іде назад у таблицю з минулотижневими діями done/not-done.

Це і є цикл. У неділю ввечері AI генерує narratives, у понеділок зранку люди вирішують. Побудова — не більше 4 годин; тижнева вартість — 90-120 хвилин CS-часу плюс LLM-кошти (зазвичай <€50/міс для SMB-книги).

Шаблон щотижневого трекінгу

Один рядок на акаунт у yellow/red. Нова вкладка на тиждень.

Тиждень: [ДАТА]
Акаунт: [НАЗВА]
ARR: [N]
Дата renewal: [ДАТА]

Сигнали (1/0):
- Логіни -30%+: [ ]
- Core-функція -40%+: [ ]
- Зупинились нові місця: [ ]
- Champion пішов: [ ]
- Exec sponsor disengaged: [ ]
- Renewal owner змінився: [ ]
- Тикетів +50% з негативом: [ ]
- Повторні тикети (3+ за 30д): [ ]
- Згадка конкурента: [ ]
Скор: [N]/9   Tier: [G/Y/R]

AI summary (6 рядків):
- Drift: [ТЕКСТ]
- Люди: [ТЕКСТ]
- Ймовірна причина: [ТЕКСТ]
- Відкрите питання: [ТЕКСТ]
- Попередні save plays: [ТЕКСТ]
- Ризик ARR при втраті: [N]

Власник: [ІМ'Я]
Save play: [КЛЮЧ_ШАБЛОНУ]
Наступний check-in: [ДАТА]
Дія цього тижня: [ТЕКСТ]

Шаблон навмисне нудний. Нудне виживає.

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

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

• Plan: кожен акаунт має визначений renewal-шлях (дата, ARR, success criteria) — Fact: 14 з 47 не мають документованих success criteria — Gap: ці 14 летять наосліп незалежно від скору
• Plan: ризикові акаунти отримують save play за 5 робочих днів — Fact: 3 з минулих red-ів чекали 11+ днів — Gap: понеділковий огляд є, але follow-through нема
• Plan: champion-loss тригерить outreach за тиждень — Fact: 2 champions пішли в березні, outreach не було 6 тижнів — Gap: LinkedIn change-of-job alerts не підключені
• Plan: двічі-перенесений QBR тригерить exec sponsor — Fact: патерн є, дії нема — Gap: ніхто не власник "двічі-перенесено"
• Plan: AI narrative готовий до понеділкового огляду — Fact: 11 з 13 тижнів вчасно — Gap: незначний
• Plan: ваги сигналів переглядаються після кожного churn — Fact: 4 churn-и квартал, post-mortem у 3 з них нема — Gap: цикл не замикається

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

140-людний B2B SaaS запустив саме цю 4-крокову модель після втрати двох six-figure акаунтів за квартал — обидва "без попереджень" за словами CSM-ів. Тиждень 1: таблиця, сигнали, baseline. Тиждень 2: AI narratives запущені, перший понеділковий огляд — і одразу 4 акаунти, про які CS-команда активно не хвилювалась, включно з одним, де champion пішов 3 тижні тому і ніхто не помітив. До тижня 6: red-tier з 9 → 4, два save закриті (один з expansion, бо discovery-call виявив іншу больову точку), і Head of CS отримала назад приблизно півдня на тиждень, який раніше йшов на ручний скан книги. Вартість: ~€40/міс на LLM. Без data team.

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 CS-команд виявляють, що їх телеметрія, CRM і support живуть у різних системах без нічного join. Шар Plan → Fact → Gap у нашій daily-management OS бере join на себе: нічний pull із джерел, скоринг проти Plan, готово до 7:00 понеділка з ранжованим списком. 7-денна діагностика показує, чи поточні дані витримають 9-сигнальну модель, чи треба спочатку один cleanup. Старт: https://aiadvisoryboard.me/?lang=en.

FAQ

А якщо в нас узагалі нема usage-телеметрії? Стартуй з relationship + support drift (6 з 9 сигналів). Це все одно ловить більшість B2B SMB-churn — relationship-сигнали сильніші, ніж очікують. Telemetry додавайте на наступному релізі; не чекайте її, щоб стартувати модель.

Чи не пропустить рівне зважування важливих сигналів? Перший квартал — ні. Рівне зважування б'є overfit на малих даних. Після 25+ churn-подій — подивіться, які сигнали спрацьовували за 60 днів до втрати, і переоцініть. До цього вагування — декорація.

Чи має AI також писати outreach email? Іноді корисно, але більший важіль — account narrative; email уже легкий, коли знаєш історію. Спершу правильний narrative; email — один промпт далі.

Чим це відрізняється від customer health score? Health score — це одне число; ця модель — структурований workflow. Health-скори часто рахують і ігнорують. 4-кроковий цикл змушує понеділкове рішення — це єдине, що зупиняє тихий churn.

А експансія — це той самий скор? Ні, тримайте окремо. Змішування ризику і expansion дає скор, що нічого не значить ні в один бік. Запускайте паралельну expansion-модель на тій же каденції; 30-хвилинний понеділок покриває обидві.

Висновок

4-крокова модель з 9 сигналами і AI narrative б'є 14-тижневий ML-білд для будь-якого SMB, що ще не має CS-команди більше 10 людей. Сенс не в складності — а в тому, що жоден акаунт не пропадає, кожен red має власника, і цикл замикається щотижня.

Виберіть 9 сигналів. Побудуйте таблицю цього тижня. Запустіть перший понеділковий огляд наступного.

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