← усі кейси
Інтернет-магазин E-commerce / FoodTech · червень 2026 р.

AI-асистент допродажів у CRM: менеджеру лишається прочитати готову репліку

На кожне нове замовлення сервіс сам підбирає 2 товари для крос-селу і пише готовий скрипт, який менеджер просто зачитує клієнту по телефону. Латентність ~5 секунд, усе на локальній LLM.

  • На кожне замовлення - 2 релевантні товари + готовий скрипт прямо в картці CRM
  • Латентність ~5 секунд від створення замовлення до готового скрипта
  • LLM обирає лише з топ-10 кандидатів - жодних вигаданих SKU чи цін
  • Усе на локальній LLM: дані не йдуть у хмару, собівартість запиту = електрика
KeyCRMn8nFastAPIPostgreSQLQwen 27B / OllamaDocker

Інтегрована автоматизація для інтернет-магазину середнього розміру. Під час обробки кожного нового замовлення система сама підбирає два товари для крос-селу і формує готовий розмовний скрипт, який менеджер просто зачитує клієнту. Сервіс уже працює в бойовому режимі.

~5 с
від замовлення до готового скрипта
2
товари крос-селу на кожне замовлення
0
розумової роботи менеджера

Бізнес-проблема

Три причини, чому допродаж «не злітає» сам собою

😴 Менеджери лінуються

  • Допродаж - це згадати асортимент, придумати зв'язку, сформулювати й запропонувати. Більшість не роблять цього взагалі

📈 Трафік дорожчає

  • Реклама росте на 15-30% щороку. Без зростання чека й LTV економіка розвалюється

🎯 Низька маржа ніш

  • Здорове харчування, нутрицевтика: кожні +50 грн до чека - різниця між прибутком і збитком

Висновок простий: треба зробити так, щоб менеджеру було легше зробити допродаж, ніж не зробити. Не «подумай, що ще запропонувати», а одразу «прочитай ось цей абзац клієнту».

Рішення

Серверний AI-сервіс на кожне нове замовлення читає кошик, підбирає 2 релевантні товари і генерує готову репліку українською просто в картку замовлення. Менеджер дзвонить клієнту з підтвердженням (рутинна операція) і в кінці зачитує скрипт. Розумова робота нульова, опір нульовий.

Потік: від замовлення до скрипта в картці
Замовлення на сайті CRM (KeyCRM) webhook «новий ордер» n8n
FastAPI-сервіс підбір ~10 кандидатів Локальна LLM: 2 товари + скрипт поле «Що допродати?» в картці

Загальна латентність - 4-5 секунд. Для CRM, де картку відкривають за хвилини-години, це непомітно.

Логіка підбору: LLM не вигадує, а обирає з перевіреного

Ключовий принцип: спершу детермінований алгоритм звужує весь каталог до топ-10 кандидатів, і лише потім LLM обирає 2 з 10 та пише скрипти. Модель ніколи не вигадує SKU «з голови».

Скоринг кандидатів - сума з чотирьох джерел
Найвища вагаЕкспертна матриця крос-сел пар - складена керівником товарного напряму вручну (60-70 локомотивів)
ВисокаCo-purchase з історії - які товари статистично часто йдуть разом в одному кошику (підвищений lift)
СередняКомплементарні категорії - те, що зазвичай супроводжує вже наявне в кошику
ДинамічнаСезонність: velocity за 14 днів × календарний буст (пряники в грудні, паска навесні)

На цей пул накладаються жорсткі фільтри, щоб рекомендація завжди була доречною:

  • товар у наявності й не куплений цим клієнтом за останні 60 днів;
  • сума двох рекомендацій - не більше 40% від чека (щоб не лякати цінником);
  • дієтичні теги клієнта: веганам - не тваринне, діабетикам - фініки/мед замість цукру, безглютеновим - не пшеничне борошно;
  • дві рекомендації - обов’язково з різних категорій (щоб не вийшло «кокосове молоко» + «кокосові вершки»).

Головна знахідка пілоту: pitch - це скрипт, а не інструкція

Чому друга версія дала стрибок адопції

❌ v1 · інструкція менеджеру

  • «Запропонуй клієнту X, оскільки він узяв Y»
  • Менеджер усе одно мусить перекласти це в живу розмову - робота не зникає

✅ v2 · пряма репліка клієнту

  • «До вашого псиліуму ідеально пасує мигдальне борошно - без нього кето-випічка не вийде. Раджу взяти разом, всього 159 грн.»
  • Менеджер просто читає. Не думає, не формулює.

Технологічний стек

Усе на одному сервері з GPU, без хмарних LLM
CRMKeyCRM - нативні webhook'и на події, REST API на читання/запис, кастомні поля картки
Оркестраторn8n (self-hosted) - приймає webhook і передає orderId далі, без логіки
СервісFastAPI (Python) - API-клієнти, підбір кандидатів, спілкування з LLM, логування
БазаPostgreSQL - каталог, історія, експертна матриця, co-purchase пари, лог рекомендацій
LLMЛокальна Qwen 27B через Ollama на власному GPU - низька латентність, нульова вартість запиту
ДеплойDocker Compose - кожен компонент окремим контейнером

Жодних хмарних LLM (ChatGPT/Claude API): персональні дані клієнтів не залишають інфраструктуру, собівартість запиту = вартість електрики, немає лімітів сторонніх API.

Roadmap: контур якості й самонавчання

Уся розмова відбувається по телефону, отже доступна для аналізу. Поточна автоматизація - фундамент, далі будуємо цикл, що сам себе вдосконалює.

Дорожня карта
Фундамент ✓Підбір + готовий скрипт у картці CRM - у бойовому режимі
Етап 1Транскрипція дзвінків: IP-телефонія (Ringostat) → Whisper
Етап 2Семантичний аналіз: чи менеджер запропонував допродаж і чи клієнт погодився
Етап 3Цикл зворотного зв'язку: погодився → +вага парі, відмовився → штраф; перерахунок щомісяця
Етап 4Контроль менеджерів: немає спроби допродажу в транскрипті → точковий сигнал керівнику
Етап 5Якісна метрика: менеджер тисне 👍/😐/👎 у картці після розмови
Як система самонавчається (Етап 3)
Дзвінок клієнт погодився + вага парі товарів
Дзвінок клієнт відмовився − вага парі щомісячний перерахунок без втручання

Підсумок

Ми не вигадуємо нову бізнес-модель - ми знімаємо тертя з добре відомого процесу. Замість «менеджер мусить пам’ятати асортимент і вміти продавати» → «менеджер відкриває картку і читає готовий текст». Решта - інженерна задача: webhook, API, БД, LLM, коректний промпт. Усе на одному сервері з GPU, без хмарних API.

Кейс відкритий до тиражування на будь-який інтернет-магазин із CRM, що підтримує webhook’и та кастомні поля картки замовлення.

Потрібне схоже рішення?

Опишіть задачу - підберу архітектуру під ваш бюджет і дані.