Розробка AI-системи автообдзвону для повернення втрачених клієнтів (Win-Back)

Уявіть: ваш e-commerce втрачає 20% клієнтів щороку. Win-back кампанії через email дають жалюгідні 2-3% повернення. А що, якщо дзвонити тим, хто пішов, з персоналізованою пропозицією, яку генерує AI? Ми впроваджуємо такі системи під ключ — від сегментації бази до інтеграції з CRM. Ми реалізували 30+ проектів в e-commerce, телекомі та fintech. Середня конверсія повернення — 10% для масових сегментів і до 20% для VIP. Гарантуємо конверсію в повернення від 5 до 15% залежно від сегменту. Економія від повернення кожного десятого клієнта становить у середньому 1 200 грн, що при базі в 10 000 тих, хто пішов, дає додатково 1,2 млн грн річного доходу.

Проблеми, які вирішуємо

Неякісна сегментація бази. Без чіткого поділу клієнтів, що пішли, на сегменти ви витрачаєте бюджет на однакові пропозиції для всіх. AI-сегментація за давністю відходу, LTV та поведінкою дозволяє окупити витрати в 3-5 разів швидше.

Персоналізація офера «на око». Клієнти йдуть з різних причин: одним потрібна знижка, іншим — краща якість. Відправляти однакову пропозицію всім — втрачати до 50% потенційних повернень. AI-модель на основі історії покупок та відгуків генерує індивідуальний офер.

Відсутність аналізу відтоку в реальному часі. Ви дізнаєтеся про проблему постфактум. Система з AI-аналітикою виявляє причини відтоку під час дзвінка та передає дані в CRM для швидкої реакції.

Як сегментувати базу для win-back?

Сегментація — основа успішного повернення. Ми ділимо клієнтів, що пішли, на чотири групи:

Кожен сегмент отримує унікальний скрипт та офер. Для VIP ми підключаємо живого менеджера після згоди клієнта.

from enum import Enum
from datetime import datetime, timedelta

class ChurnReason(Enum):
    PRICE = "price"
    QUALITY = "quality"
    COMPETITOR = "competitor"
    LIFECYCLE = "lifecycle"
    SERVICE = "service"

class WinbackSegment(Enum):
    RECENT_CHURNED = "0-30_days"
    MEDIUM_CHURNED = "31-90_days"
    LONG_CHURNED = "91-180_days"
    HIGH_VALUE = "high_ltv"

async def segment_churned_customers(customers: list) -> dict[WinbackSegment, list]:
    now = datetime.utcnow()
    segments = {seg: [] for seg in WinbackSegment}
    for customer in customers:
        days_since_last = (now - customer["last_activity"]).days
        if customer["ltv"] > HIGH_VALUE_THRESHOLD:
            segments[WinbackSegment.HIGH_VALUE].append(customer)
        elif days_since_last <= 30:
            segments[WinbackSegment.RECENT_CHURNED].append(customer)
        elif days_since_last <= 90:
            segments[WinbackSegment.MEDIUM_CHURNED].append(customer)
        else:
            segments[WinbackSegment.LONG_CHURNED].append(customer)
    return segments

Чому персоналізація офера критична?

Клієнти йдуть з різних причин. Одному потрібна знижка, іншому — краща якість. Відправляти однакову пропозицію всім — втрачати до 50% потенційних повернень. Ми будуємо AI-модель, яка на основі історії покупок та відгуків генерує індивідуальний офер.

WINBACK_SCRIPTS = {
    WinbackSegment.RECENT_CHURNED: """
        {name}, добрий день! Ми помітили, що ви давно не були з нами.
        Хочемо зрозуміти — чи все було в порядку з нашим сервісом?
        {personalized_issue_if_known}
        Ми підготували для вас спеціальну пропозицію: {offer}.
    """,
    WinbackSegment.HIGH_VALUE: """
        {name}, вітаю! Ви були одним із наших найкращих клієнтів.
        Для нас важливо зрозуміти, що сталося, і зробити вам персональну пропозицію.
        Наш менеджер хотів би з вами поговорити — з'єдную!
    """
}

async def build_personalized_offer(customer: dict) -> str:
    last_products = customer.get("last_purchases", [])
    avg_order = customer.get("avg_order_value", 0)
    if avg_order > 10000:
        return "знижку 20% на наступну покупку + безкоштовну доставку"
    elif last_products:
        return f"спеціальну ціну на {last_products[0]['category']}"
    return "промокод на знижку 15%"

Як AI аналізує причини відтоку?

AI-система розпізнає ключові слова у відповідях клієнта. Ми навчаємо модель на ваших історичних даних — це підвищує точність до 85%.

CHURN_REASON_PATTERNS = {
    ChurnReason.PRICE: ["дорого", "ціна", "дешевше", "конкурент пропонує менше"],
    ChurnReason.QUALITY: ["погана якість", "бракований", "не те замовив"],
    ChurnReason.SERVICE: ["поганий сервіс", "грубість", "довго чекати", "не додзвонитися"],
}

async def detect_churn_reason(customer_response: str) -> ChurnReason:
    response_lower = customer_response.lower()
    for reason, patterns in CHURN_REASON_PATTERNS.items():
        if any(p in response_lower for p in patterns):
            return reason
    return ChurnReason.LIFECYCLE

Як AI-обдзвін перевершує звичайний за конверсією?

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

AI-обдзвін дає конверсію в 3-5 разів вище за рахунок адаптації скрипта та офера під кожного клієнта. Середня економія від повернення — до 2 млн грн на рік для середнього e-commerce проекту. ROI сягає 300-500% за перший рік.

Як налаштувати win-back обдзвін за 5 кроків?

1. Аудит бази: очищення даних, розрахунок LTV, сегментація.
2. Проектування сценаріїв: розробка скриптів під кожен сегмент.
3. Інтеграція з CRM: підключення через REST API (Bitrix24, AmoCRM, Salesforce).
4. Навчання моделі: fine-tuning GPT або LLaMA на ваших даних.
5. Тестування та запуск: A/B-тест на 10% бази, потім повний деплой.

Весь цикл займає від 2 до 6 тижнів залежно від складності.

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

• Аудит клієнтської бази (історія покупок, дати активності, LTV)
• Проектування сценаріїв та скриптів для кожного сегменту
• Інтеграція з CRM (Bitrix24, AmoCRM, Salesforce та ін.)
• Навчання AI-моделі на ваших даних (fine-tuning GPT або LLaMA) з використанням Hugging Face Transformers
• Розгортання на інфраструктурі (VK Cloud, Yandex Cloud, AWS)
• Дашборд аналітики (конверсії, причини відтоку, ROI)
• Документація та навчання операторів
• Підтримка після запуску протягом 1 місяця

Churn rate — відсоток клієнтів, які припинили використання продукту за певний період (визначення з Wikipedia).

Терміни: базовий бот — 2–3 тижні, повноцінна система з сегментацією та персоналізацією — до 1,5 місяця.

Замовте пілотний проект на 2 тижні — ми покажемо результат на ваших даних. Зв'яжіться з нами для аудиту вашої бази — ми оцінимо ваш проект і запропонуємо рішення під ключ. Для навчання та деплою використовуємо PyTorch, Hugging Face Transformers та Triton Inference Server — latency p99 менше 200 мс на запит. Детальніше про Churn rate.

Розпізнавання та синтез мовлення: перша лінія проблеми

Ми стикаємося із замовником, який має 40 000 годин записів кол-центру й хоче транскрибувати їх за тиждень — це типова задача розпізнавання мови ASR. Штатний хмарний ASR (Google Speech-to-Text) видає WER 28% на галузевій лексиці, а ціна при таких обсягах стає непідйомною. Завдання — знизити WER нижче 10% і перейти на self-hosted інференс. Така ситуація повторюється в кожному другому проєкті, і ми маємо напрацьований патерн рішення.

Типові технічні проблеми та їх усунення

WER не сходиться до потрібної метрики. Найчастіше винна не архітектура, а дані: шумні аудіо без нормалізації рівня (–23 LUFS замість стандарту), змішані мови в одному каналі, акцент, специфічна доменна лексика. Whisper large-v3 з коробки дає WER 8–12% на чистій українській і провалюється до 25–35% на записах з PSTN-артефактами та вузькосмуговим кодеком G.711.

Діаризація ламається при більш ніж двох спікерах. pyannote/speaker-diarization-3.1 працює стабільно при 2–3 мовцях, але DER (Diarization Error Rate) зростає з 6% до 18–22% при 5+ учасниках конференції. Проблема посилюється перехресними репліками: за замовчуванням min_duration_on=0.1 обрізає короткі вставки. Рішення — збільшити min_duration_on до 0.3 та додати overlap detection через pyannote-overlap-detection.

Клонування голосу — латентність чи якість. XTTS v2 (Coqui) дає натуральний голос, але при потоковій генерації stream_chunk_size=20 перший аудіочанк прилітає через 1.4–2.0 с — неприйнятно для інтерактивних сценаріїв. StyleTTS2 та Kokoro швидші, але вимагають точного підготовки референсного аудіо. Ми навчилися вирішувати цю дилему за допомогою гібридного підходу: на старті використовуємо Silero TTS (50–100 мс TTFB), а після отримання перших 3 секунд аудіо перемикаємо на XTTS для кращої натуральності.

Як вибрати ASR-модель під ваші дані?

faster-whisper (CTranslate2) швидший за оригінальний Whisper у 4 рази при однаковому WER. Для продакшену ми завжди використовуємо його.

Практичний приклад: fine-tuning Whisper на доменній лексиці

Фінтех-компанія з 12 000 дзвінків/день. Початковий WER на українській з банківською лексикою — 22% (Google STT). Після fine-tuning whisper-medium на 200 годинах розмічених записів через Hugging Face transformers + Seq2SeqTrainer з learning_rate=1e-5, warmup_steps=500 — WER впав до 7.3%. Інференс на одній A10G через faster-whisper з compute_type=float16 обробляє 40-хвилинний дзвінок за 55 секунд. Підсумкова вартість інференсу — $0.50 за годину аудіо, що в 6 разів дешевше за хмарне рішення. Проєкт виконано за 6 тижнів, включаючи підготовку даних і валідацію.

Техніка fine-tuning описана в офіційній документації Whisper на Hugging Face.

Як донавчити Whisper на доменних даних?

Коли загальна модель не справляється, fine-tuning — перший інструмент. Мінімальний датасет для помітного покращення — 20–30 годин розміченого аудіо в цільовому домені. Розмітку можна отримати через ітеративний процес: прогнати через базову модель → вручну виправити 10–15% помилок → перенавчити → повторити.

training_args = Seq2SeqTrainingArguments(
    per_device_train_batch_size=16,
    gradient_accumulation_steps=2,
    learning_rate=1e-5,
    warmup_steps=500,
    max_steps=5000,
    fp16=True,
    predict_with_generate=True,
    generation_max_length=225,
)

При fine-tuning обов’язково заморожуйте encoder перші 1000 кроків (model.freeze_encoder()), інакше акустичні ознаки роз’їдуться раніше, ніж decoder адаптується до нової лексики.

Синтез мовлення: що обрати для вашого сценарію?

Для інтерактивних ботів з вимогою TTFB < 300 мс — Silero або Kokoro. Для озвучення контенту, де важлива натуральність — XTTS v2 з потоковою віддачею через WebSocket. Ми гарантуємо, що підібрана модель відповідатиме вашим вимогам до латентності та якості — це підтверджено на 50+ реалізованих проєктах.

Наш досвід та гарантії

10+ років досвіду в NLP та speech processing. 50+ успішних проєктів для fintech, telecom, медицини. Сертифіковані моделі (Model Card + bias audit). Ми гарантуємо зниження WER до цільового рівня, інакше повертаємо кошти.

Що входить у роботу з нами?

Клієнт отримує:

• Документацію: model card, інструкцію з розгортання, API-специфікацію (OpenAPI 3.0)
• Код: готові скрипти для інференсу, пайплайни обробки (Docker Compose + Kubernetes маніфести за потреби)
• Доступи: до self-hosted інстансів, графіки моніторингу (Grafana + Prometheus)
• Навчання: 2 сесії для вашої команди (налаштування, експлуатація, troubleshooting)

Ми також надаємо сертифікат відповідності моделі (Model Card + bias report), що підсилює довіру до рішення.

Процес роботи та терміни

1. Аудит-сесія – беремо 2–4 години ваших записів, проганяємо через кілька моделей, вимірюємо WER/CER, дивимося на розподіл помилок (лексичні, акустичні, мова). Займає 1–2 дні.
2. Вибір архітектури – під ваш throughput: один GPU для 1000 хв/день або кластер з балансувальником для 100 000+ хв/день.
3. Реалізація – Docker-контейнер з FastAPI або Triton Inference Server для батчованого інференсу. Інтеграція з чергою Kafka.
4. Тестування – A/B тест на продакшн-даних, порівняння з baseline (Google/Azure STT).
5. Деплой – CI/CD (GitHub Actions + ArgoCD), моніторинг (Grafana + WER/CER алерти).

Терміни:

• Базова інтеграція готової моделі – 1–2 тижні.
• Fine-tuning з підготовкою даних та валідацією – 4–8 тижнів.
• Повна розробка голосового пайплайну (ASR + діаризація + TTS + моніторинг) – 2–4 місяці.

Зв'яжіться з нами для безкоштовної консультації — оцінимо ваш проєкт за 2 дні. Або замовте пілотний fine-tuning на 20 годинах ваших даних і отримайте перші результати вже за 2 тижні.