AI-аналіз втрачених угод: як знайти реальні причини відмов
Ми розробляємо AI-систему, яка аналізує програшні угоди та виявляє приховані патерни причин відмов. Більшість CRM зберігають причини втрат у полі "lost_reason" з варіантами "клієнт обрав іншого" або "ціна висока". Без структурованого аналізу ці дані марні. Наша система автоматично збирає, збагачує та кластеризує причини втрат, витягуючи з транскрипцій розмов, email-листування та post-mortem менеджерів приховані патерни. На виході — actionable інсайти: які конкуренти та на яких сегментах перемагають нас, які етапи воронки найвразливіші, які заперечення не відпрацьовані. Система працює в реальному часі та інтегрується з будь-якою CRM через REST API. Досвід нашої команди — 10+ років у ML та NLP, понад 20 впроваджених рішень. Готові оцінити ваш проект — пишіть.
Як AI-система виявляє реальні причини відмов?
Стандартний lost reason у CRM — "клієнт обрав іншого" — не дає розуміння. Ми застосовуємо LLM-enrichment: модель (GPT-4o або Llama 3) аналізує всі доступні джерела — транскрипції дзвінків, email, нотатки менеджера — та генерує деталізовану причину. Наприклад, замість "ціна" отримуємо "конкурент запропонував інтеграцію з SAP, якої у нас немає, при порівнянній ціні".
Для кластеризації причин використовуємо sentence embeddings (модель intfloat/multilingual-e5-small) та алгоритм K-Means. На виході — топ-5–10 реальних причин втрат з динамікою по тижнях та сегментах. AI-система аналізує 1000 угод у 20 разів швидше, ніж команда аналітиків вручну — порівняйте: 40–60 годин ручної праці проти 2–3 годин автоматичної обробки.
Які проблеми вирішує Lost Deal Analysis?
- Проблема 1: Неповнота даних. Менеджери вводять причину формально. Система автоматично збагачує, використовуючи LLM.
- Проблема 2: Розрізненість. Причини губляться в різних системах. Модель консолідує з CRM, телефонії та пошти.
- Проблема 3: Відсутність порівняльного аналізу. Система показує, кому та на яких сегментах програємо, та виявляє ключові переваги конкурентів.
Як ми будуємо систему для SaaS-платформи?
Розглянемо кейс SaaS-платформи з 5000+ угод на місяць. Команда фіксувала причини в Salesforce, але 70% — "other" або пусто. Ми розгорнули pipeline:
- Data Ingestion: ETL-процеси (Airflow) забирають дані з CRM, API телефонії та поштового сервера. Транскрипції обробляються через Whisper.
- Enrichment: Пайплайн з Hugging Face Transformers (sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2) генерує ембеддінги для кожного кейса. LLM (Llama 3 70B через vLLM) формує human-readable опис причини.
- Clustering: Щотижневий batch-запуск K-Means (k=15) на ембеддінгах. Результат — кластери з мітками, автоматично згенерованими LLM.
- Reporting: Дашборд у Metabase з фільтрами по сегменту, періоду, конкуренту. Щотижневі email-звіти з top-причинами та рекомендаціями.
Результат: після впровадження за два місяці кількість угод, закритих з аналізом причин, зросла з 20% до 95%, а рекомендації скоротили втрати на 12% на цільовому сегменті.
Процес роботи
| Етап | Тривалість | Результат |
|---|---|---|
| Аналітика | 1–2 тижні | Аудит джерел, вибір LLM/embedding моделі, проектування схеми даних |
| Проектування | 1–2 тижні | Архітектура pipeline, інтеграція з CRM, прототип enrichment |
| Реалізація | 2–4 тижні | Розробка ETL, fine-tuning (якщо потрібно), дашборди |
| Тестування | 1 тиждень | A/B-тест на одному сегменті, звірка з ручним аналізом |
| Деплой | 1 тиждень | Розгортання в production, навчання команди |
Строки: від 4 до 8 тижнів залежно від складності інтеграції та доступності даних.
Що ви отримуєте
- Pipeline обробки даних: ETL-скрипти, інтеграція з CRM, дашборди.
- Документація: опис архітектури, інструкція з експлуатації.
- Навчання: 2–3 сесії для команди (менеджери, аналітики, DevOps).
- Підтримка: 1 місяць інцидентної підтримки після деплою, далі по SLA.
- Вихідний код: всі компоненти передаються в репозиторій замовника.
Порівняння ручного та AI-аналізу
| Параметр | Ручний аналіз | AI-аналіз |
|---|---|---|
| Час на аналіз 1000 угод | 40–60 годин | 2–3 години (автоматично) |
| Повнота даних | 20–30% | 90–95% |
| Частота оновлення звітів | Щомісяця | Щодня (реальний час) |
| Виявлення прихованих патернів | Суб'єктивно | Об'єктивна кластеризація |
Типові помилки при впровадженні
- Ігнорування якості транскрипцій. Якщо розшифровка дзвінків дає багато помилок (WER > 20%), LLM-enrichment страждатиме. Рекомендуємо перед стартом оцінити WER та при необхідності донавчити модель розпізнавання.
- Занадто багато кластерів. k > 30 робить інтерпретацію марною. Оптимально 10–15.
- Відсутність feedback loop. Без зворотного зв'язку від менеджерів кластери старіють. Рекомендуємо раз на місяць проводити рев'ю та коригувати мітки.
Наш досвід показує: компанії, що впровадили систему, в середньому скорочують втрати на 8-15% за квартал (Customer attrition). Замовте пілотний проект на одному сегменті — ми покажемо результат за 2 тижні.
Ми гарантуємо якість на кожному етапі: всі моделі проходять валідацію на тестовому наборі, а підсумковий pipeline документується та передається замовнику. Досвід нашої команди — 10+ років у ML та продакшні, понад 20 впроваджених рішень для аналізу продажів.
Готові обговорити ваш проект? Зв'яжіться з нами — ми безкоштовно оцінимо поточні дані та можливості інтеграції. Отримайте консультацію по вашому кейсу вже сьогодні.