Проактивні AI-повідомлення: запобігаємо зверненням у підтримку

Клієнт чекає замовлення, але доставка затримується. Замість того щоб телефонувати в підтримку, він отримує SMS з новим ETA і посиланням на трекер. Це і є проактивне AI-повідомлення — система сама знаходить проблему і вирішує її до того, як клієнт помітить. Ми впроваджуємо такі рішення, і тікети в контакт-центр падають на 20–35%.

Автоматична детекція та генерація повідомлень

Система аналізує тисячі подій у реальному часі: статуси замовлень, логістичні дані, підписки, поведінкові патерни. Щойно детектор знаходить аномалію — затримку, ризик відмови платежу, наближення ліміту, — Large language model (наприклад, Claude 3.5 Sonnet) генерує персоналізоване повідомлення та надсилає його через відповідний канал: SMS, push, email або месенджер. Усе відбувається за секунди, без участі людини. Результат: клієнт отримує рішення, а підтримка — менше дзвінків.

Чому проактивні повідомлення вигідніші за реактивну підтримку?

Порівняємо прямі витрати на контакт-центр і на систему повідомлень. Типовий дзвінок у контакт-центр обходиться компанії у $2–4ів, а одне повідомлення — у $1–1і. При вартості дзвінка у 100–300 разів вищій за повідомлення достатньо запобігти менш ніж 1% звернень, щоб система окупилася. На практиці вона відсікає 20–35% тікетів.

Які канали повідомлень ефективніші?

Вибір каналу впливає на швидкість реакції та вартість. Ось порівняння основних варіантів:

Для критичних подій (затримка доставки, збій сервісу) ми використовуємо SMS+push, для менш термінових — email.

Основні тригери системи

Система покриває п'ять основних сценаріїв, на які припадає 80% звернень у підтримку:

• Затримки доставки: детекція замовлень, де estimated_delivery перевищено більш ніж на день. Клієнт отримує повідомлення з новим ETA і, якщо потрібно, пропозицію компенсації.
• Ризик відмови платежу: за 30 днів до закінчення терміну картки — email з проханням оновити дані. Це запобігає 15–20% відмов підписок.
• Наближення ліміту підписки: коли usage сягає 80%, клієнту пропонують розширити план. Upsell без участі підтримки.
• Повідомлення про збої: якщо сервіс у регіоні клієнта тимчасово недоступний, повідомлення приходить до того, як користувач спробує зайти та створить тікет.
• Аномальна активність: вхід з нового пристрою або місцезнаходження — автоматичне повідомлення з підтвердженням.

Архітектура системи: як це працює під капотом

Основні компоненти: детектор подій на Python, LLM для генерації тексту (Claude 3.5 Sonnet), модуль пріоритизації на Pandas. Детектор аналізує логістичні дані, підписки та поведінкові патерни. Нижче — ключові класи (повна реалізація в репозиторії).

import pandas as pd import numpy as np from anthropic import Anthropic import json class ProactiveNotificationEngine: """Детекція подій, які потребують проактивного повідомлення""" NOTIFICATION_TRIGGERS = { 'delivery_delay': { 'threshold': 'expected_delivery exceeded by 1 day', 'channel': 'sms+push', 'priority': 'high' }, 'payment_failure_risk': { 'threshold': 'card expires within 30 days', 'channel': 'email', 'priority': 'medium' }, 'service_disruption': { 'threshold': 'user in affected region', 'channel': 'push+sms', 'priority': 'critical' }, 'subscription_limit_approaching': { 'threshold': 'usage > 80% of plan limit', 'channel': 'in_app+email', 'priority': 'medium' }, 'anomalous_account_activity': { 'threshold': 'login from new location', 'channel': 'email+sms', 'priority': 'high' } } def detect_delivery_issues(self, orders: pd.DataFrame, logistics_data: pd.DataFrame) -> pd.DataFrame: """Детекція замовлень з ризиком затримки""" merged = orders.merge(logistics_data, on='tracking_id', how='left') today = pd.Timestamp.now() merged['days_delayed'] = ( merged['estimated_delivery_updated'] - merged['expected_delivery'] ).dt.days at_risk = merged[ (merged['days_delayed'] > 0) & (~merged['delivered']) & (~merged['notification_sent']) ].copy() at_risk['urgency'] = pd.cut( at_risk['days_delayed'], bins=[-np.inf, 1, 3, np.inf], labels=['minor', 'moderate', 'significant'] ) return at_risk def detect_usage_limit_alerts(self, subscriptions: pd.DataFrame) -> pd.DataFrame: """Клієнти, що наближаються до лімітів підписки""" subscriptions = subscriptions.copy() subscriptions['usage_pct'] = subscriptions['current_usage'] / subscriptions['plan_limit'] return subscriptions[ (subscriptions['usage_pct'] > 0.80) & (subscriptions['usage_pct'] < 1.0) & (~subscriptions['upsell_shown']) ].sort_values('usage_pct', ascending=False) def generate_notification(self, trigger_type: str, customer: dict, event_data: dict) -> dict: """Персоналізований текст повідомлення""" llm = Anthropic() trigger_config = self.NOTIFICATION_TRIGGERS.get(trigger_type, {}) response = llm.messages.create( model="claude-3-5-sonnet-20241022", max_tokens=150, messages=[{ "role": "user", "content": f"""Write a proactive customer notification in Russian. Trigger: {trigger_type} Customer: {customer.get('first_name', 'Клієнт')} Event details: {json.dumps(event_data, ensure_ascii=False)[:200]} Write: 1. Short subject/title (push notification style, max 50 chars) 2. Body (2-3 sentences: what happened, what we're doing, what customer should do if anything) Be empathetic and solution-focused. No corporate speak. Return JSON: {{"title": "...", "body": "..."}}""" }] ) try: content = json.loads(response.content[0].text) except Exception: content = {'title': 'Важлива інформація про ваше замовлення', 'body': ''} return { 'customer_id': customer.get('id'), 'channel': trigger_config.get('channel', 'email'), 'priority': trigger_config.get('priority', 'normal'), 'title': content.get('title'), 'body': content.get('body'), 'trigger_type': trigger_type } def prioritize_notifications(self, pending_notifications: pd.DataFrame) -> pd.DataFrame: """Пріоритизація з урахуванням втоми від повідомлень""" priority_order = {'critical': 0, 'high': 1, 'medium': 2, 'low': 3} pending_notifications['priority_num'] = pending_notifications['priority'].map(priority_order) sorted_notifs = pending_notifications.sort_values( ['customer_id', 'priority_num'] ) result = sorted_notifs.groupby('customer_id').head(2) return result 

Як ми впроваджуємо систему: процес роботи

1. Аналіз даних: досліджуємо історію звернень і логів, виявляємо основні тригери незадоволення.
2. Проектування тригерів: визначаємо 5–10 типів подій, які мають викликати повідомлення.
3. Інтеграція з API: підключаємося до CRM, OMS, логістичної платформи.
4. Реалізація детекторів: пишемо код для виявлення подій у реальному часі.
5. Налаштування LLM: калібруємо промпти для генерації людяного та емпатичного тексту.
6. A/B-тестування: запускаємо пілот на 10% аудиторії, порівнюємо метрики (NPS, тікети, повідомлення).
7. Деплой та моніторинг: розгортаємо на Kubernetes (Triton Inference Server) з дашбордом у Grafana.

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

• Вихідний код детекторів та інтеграцій (ваш форк репозиторію).
• Документація з архітектури та API.
• Налаштовані шаблони повідомлень для 5+ сценаріїв.
• Інструкція з експлуатації та додавання нових тригерів.
• Підтримка на етапі пілоту (2 тижні після деплою).
• Навчання команди (2–4 години воркшопу).

Строки та як почати

Пілот з одним тригером і 1000 клієнтів — від 14 днів. Повноцінне впровадження з 10 тригерами та масштабуванням — 1–2 місяці. Вартість розраховується індивідуально під ваш обсяг даних і кількість сценаріїв. Зв'яжіться з нами — оцінимо проєкт за один робочий день і запропонуємо план впровадження. Наш досвід у AI-комунікаціях — 5+ років, ми реалізували понад 50 проєктів у рітейлі, фінтеху та телекомі. Гарантуємо зниження звернень у підтримку мінімум на 15% після першого етапу. Отримайте консультацію — дізнайтеся, як проактивні повідомлення вплинуть на ваші метрики.

Дослідження Gartner показує, що компанії, які використовують проактивні повідомлення, знижують кількість звернень у підтримку на 20–35%.