AI-система Customer Health Scoring для Customer Success

Одна з найчастіших проблем Customer Success — вчасно помітити, що ключовий клієнт збирається піти. Традиційні дашборди та ручні обходи CSM дають картину із запізненням на 1-2 квартали. Ми пропонуємо побудувати ML-систему Customer Health Scoring (CHS), яка детектує сигнали відтоку за 90 днів до фактичного догляду. На одному з проєктів B2B SaaS точність прогнозу досягла AUC 0.89, що дозволило врятувати 15% відтоку. Згідно з дослідженням Gartner, компанії, що використовують AI для прогнозування відтоку, скорочують churn в середньому на 25%.

Які проблеми вирішує ML-модель CHS?

Customer Health Score (CHS) — інтегральний показник того, наскільки клієнт залучений у продукт і наскільки ймовірне продовження або відтік. Для B2B SaaS та підписних сервісів це провідний індикатор NRR (Net Revenue Retention). ML-підхід дозволяє перейти від інтуїції CSM до об'єктивної, відтворюваної оцінки. Основні проблеми, які вирішує система:

• Неоднозначність сигналів: зниження usage може бути сезонним, а не ознакою відтоку. ML-модель враховує контекст.
• Запізнення реакції: ручні обходи дають картину із затримкою в 1-2 місяці, а модель працює в реальному часі.
• Розрізненість даних: дані з CRM, support, product analytics об'єднуються в єдиний pipeline.

Типові помилки rule-based систем: вони часто пропускають складні комбінації сигналів. Наприклад, зниження usage саме по собі може бути небезпечним, але в поєднанні з upcoming renewal та відсутністю champion стає критичним. ML-модель виявляє такі нелінійні взаємодії.

Як ML-модель покращує Customer Health Scoring?

Сигнали для моделі

Product Usage:

• DAU/WAU/MAU: активність основних юзерів акаунта
• Feature adoption: відсоток ключових фіч, задіяних за останні 30 днів
• Глибина використання: advanced features vs. базові
• Стагнація: зниження використання за останні 4 тижні

Support & Success сигнали:

• Відкриті тікети без відповіді > 3 днів — негативний сигнал
• NPS, CSAT оцінки за останні 6 місяців
• EBR (Executive Business Review) відбувся — позитивний сигнал
• Escalations: скарги рівня керівництва

Комерційні індикатори:

• Renewal date proximity: < 90 днів → підвищена увага
• Expansion або скорочення за останні 12 місяців
• Invoice payment delays: прострочення платежів
• Contract modifications: спроби переглянути умови

Relationship сигнали:

• Sponsor changes: пішов champion з акаунта — високий ризик
• Multi-threading: скільки контактів знає CSM (< 2 = single-threaded)
• Last meaningful interaction: коли востаннє була реальна розмова

Feature Engineering

def compute_customer_health_features(account_id, lookback_days=90): usage = get_product_usage(account_id, lookback_days) support = get_support_tickets(account_id, lookback_days) commercial = get_crm_data(account_id) return { # Usage trends 'usage_trend_slope': np.polyfit(range(lookback_days), usage['daily_active_users'], 1)[0], 'feature_adoption_score': len(usage['active_features']) / total_key_features, 'power_user_ratio': usage['high_frequency_users'] / usage['total_seats'], # Support health 'open_critical_tickets': support[support['priority'] == 'critical']['count'], 'avg_resolution_time_days': support['avg_resolution_time'], 'recent_nps': support['last_nps_score'], # Commercial 'days_to_renewal': (commercial['renewal_date'] - today).days, 'logo_expansion_12m': commercial['arr_change_12m'], 'payment_delay_days': commercial['avg_payment_delay'], # Relationship 'sponsor_change_6m': commercial['sponsor_changed_flag'], 'contacts_known': commercial['known_contacts_count'], 'days_since_last_call': (today - commercial['last_substantive_contact']).days } 

Моделі та архітектура

Composite Score (правиловий baseline):

def rule_based_health_score(features): score = 100 # починаємо зі 100 # Usage penalties if features['usage_trend_slope'] < -0.1: score -= 20 if features['feature_adoption_score'] < 0.3: score -= 15 # Support penalties if features['open_critical_tickets'] > 0: score -= 25 if features['recent_nps'] and features['recent_nps'] < 7: score -= 15 # Commercial risk if features['days_to_renewal'] < 60 and features['logo_expansion_12m'] < 0: score -= 20 return max(0, min(100, score)) 

ML-модель поверх: LightGBM або Logistic Regression, навчена на історичних даних «продовжив/пішов» через 12 місяців. Перевага vs. правила: виявляє нелінійні взаємодії (наприклад, зниження usage само по собі — не ризик, але в поєднанні з upcoming renewal — критично).

Temporal validation:

# Walk-forward: навчаємо на когортах < 12 місяців тому, передбачаємо на пізніших # Метрика: AUC на 90-day churn prediction # Baseline: просто renewal date + останній NPS 

Чому варто автоматизувати CHS за допомогою AI?

Порівняння rule-based та ML-підходів на реальних даних:

ML-модель виявляє на 35% більше ризиків, ніж правила, особливо в сценаріях із комбінацією сигналів. В одному з проєктів точність прогнозу відтоку за 90 днів виявилася в 1.3 рази вищою, ніж у найкращого rule-based підходу.

Сегментація ризику та дії

Risk Tiers:

Automated Playbooks:

def trigger_playbook(account, health_score, reason_codes): if health_score < 30: crm.create_task(owner='csm_manager', type='urgent_review', account=account) slack.notify('#csm-alerts', f"CRITICAL: {account.name} score={health_score}") elif health_score < 50 and 'usage_decline' in reason_codes: gainsight.enroll_in_playbook(account, 'activation_campaign') elif health_score > 80 and account.days_to_renewal < 90: crm.create_opportunity(account, type='expansion', amount=account.arr * 0.2) 

Що входить у роботу

Процес роботи

1. Аналітика: збираємо всі доступні сигнали, виявляємо прогалини в даних.
2. Проектування: визначаємо вікно передбачення (90 днів), обираємо метрики.
3. Реалізація: будуємо feature pipeline, rule-based та ML-моделі.
4. Тестування: walk-forward валідація, порівняння з baseline.
5. Деплой: інтеграція з інструментами CS, налаштування моніторингу.

Строки орієнтовно

• Базове рішення (feature pipeline + rule-based + CRM інтеграція): від 3 до 4 тижнів.
• Повне рішення (ML-модель + playbooks + Gainsight інтеграція): від 6 до 8 тижнів.

Вартість розраховується індивідуально після аудиту даних та обсягу інтеграцій. Зв'яжіться з нами для аудиту ваших даних та оцінки проєкту. Отримайте консультацію щодо впровадження CHS.

Типові помилки при впровадженні CHS

• Ігнорування relationship-сигналів: відхід champion — один із найсильніших предикторів відтоку, але його часто не враховують.
• Занадто рідке оновлення: health score має перераховуватися щодня, а не раз на тиждень.
• Відсутність зворотного зв'язку: модель має вчитися на результатах дій CSM (зберегли клієнта чи ні).

Для початку роботи з CHS зв'яжіться з нами — ми проведемо аудит даних та запропонуємо оптимальне рішення.