• /
  • /

AI без хайпа и бюджета: как ВкусВилл превращает звонки в продуктовые инсайты

Во ВкусВилле решили по-новому посмотреть на B2B-клиентов: не как на строчки в CRM, а как на живых людей с реальными задачами и сомнениями. Вместо длинных UX-исследований запустили собственный MVP на базе транскрибированных звонков: без команды дата-сайентистов, без внешнего API и без затрат. Просто руководитель продуктовой команды Денис Лялин за пару вечеров написал скрипт и начал вытаскивать контекст из звонков, формировать гипотезы, помогать продажам и строить путь к персонализации.

Краткое содержание:
Когда вы впервые задумались о внедрении ИИ?

Изначально история с ИИ была вообще не про продажи. Это была продуктовая задача. У нас ведь есть своя специфика: ЛПР, который принимает решение, будет ли компания пользоваться нашим сервисом, и конечный пользователь — это разные люди. И говорить с ними нужно о разном.


С ЛПР ты разговариваешь про верхнеуровневые вещи: ценности, заботу о сотрудниках, корпоративную культуру, здоровое питание. А вот у конечного пользователя миллион вопросов по функционалу: что-то не нравится, что-то мешает, что-то нужно доработать. И каждый раз встаёт вопрос: что делать в первую очередь?


И здесь важно не просто угадать, а действовать объективно. Но объективность сложно обеспечить, особенно когда у тебя относительно немного клиентов, скажем, 2–3 тысячи ИНН. Опросы не дают нужной выборки, на интервью не всегда найдёшь участников, да и времени уходит масса. А мы хотели понять, чем реально недовольны пользователи. Не гипотетически, а прямо сейчас.

Как вы начали использовать ИИ? С чего начался первый эксперимент?
Мы решили: а что если просто достанем все звонки, которые приходили на горячую линию, и посмотрим, о чём нас спрашивают? Это оказалось и объективнее, и, что немаловажно, в сотни раз быстрее.

Я сам за два вечера написал скрипты на Python. То есть буквально два вечера — и у нас уже есть срез по самым частым вопросам. А если делать нормальное исследование «вручную» — это месяц. Подключается продакт, UX-исследователь, кто-то пишет опросы, кто-то их рассылает, потом начинается: «Ой, мы не готовы отвечать», «Извините, нам некогда». Или зовём людей на интервью — и хорошо, если согласятся человек десять.

Скрипты реально сэкономили массу времени. Мы просто вытащили текст из звонков, сложили в массив и начали анализировать. И в этот момент пришло озарение: из этого массива можно собирать не просто список проблем, а полноценный портрет клиента. Увидеть, кто чем недоволен, какие паттерны повторяются, что важно людям на самом деле.

Потому что можно сколько угодно смотреть на дашборд: выручка растёт, метрики хорошие, лояльность на высоте. А потом оказывается, что на горячей линии регулярно жалуются на документооборот. Говорят, например: «Неудобно работать с накладными, не разобрались, что с ними делать, нет возможности подписывать ежедневно». И ты понимаешь: тот рост, который видишь в цифрах, на самом деле очень хрупкий.

Стоит прийти шустрому конкуренту, задать нужные вопросы, попасть в те боли, которые давно копятся — и всё. Люди сейчас умеют быстро находить нужного ЛПР и делать персонализированное предложение. И если ты вовремя не отреагировал и пропустил сигналы клиента, тебя просто подвинут.
Получается, до внедрения ИИ с обращениями работали вручную. Как это было устроено?
Всё и сейчас так: на горячую линию приходят обращения, и каждое фиксируется — кто обратился, в чём суть, какое решение было предложено. Это делает оператор вручную. Никакой магии.

То есть мы точно не ведём речь о том, чтобы полностью отказаться от операторов. Мы просто нащупали момент, где можно попробовать автоматизировать, что-то вынести в другую плоскость. Но это точно не про замену человека.

Я категорически против идеи полностью убрать живое общение. Меня самого раздражают боты: когда звонишь в компанию, а там непроходимый бот, и он не понимает, что ты хочешь поговорить с человеком. В скрипте не предусмотрено: «Позови мне человека». Ты хоть что говори — не пробиться. Меня это бесит, как и многих, я уверен. Поэтому я за то, чтобы живые люди продолжали принимать звонки.

Но вот для анализа обращений пригодится автоматизация. Особенно в продуктовой истории: можно быстро увидеть паттерны, собрать статистику, принять решение, куда развивать функционал.

В продажах это тоже может сработать, но чуть сложнее. Там свои нюансы.
Что вы узнали из первых данных по звонкам?
Если кратко, то мы собрали транскрибации, сняли верхний срез и разметили обращения: какие темы звучат чаще, какие реже. Получилось выделить «горячие», «тёплые» и «холодные» проблемы. Это помогло понять, за что браться в первую очередь и где самое узкое место.

Вообще, вся эта история сильно отрезвляет, потому что со временем взгляд замыливается, и тебе кажется, что ты и так всё про свой продукт знаешь. Мы порой существуем в определённом вакууме: что-то сами считаем важным, обсуждаем в команде, решаем, что надо делать, — а на горячей линии в это время говорят совсем о другом.

Проблема ещё и в том, что человек не может держать в голове такое количество информации, а AI — может. Он помогает собрать и удержать общий контекст.

Но главное — не в технических предпосылках. Мы, как и многие, пришли к простой, но важной мысли: B2B-клиент — это не просто строчка в CRM, не просто сделка. Клиент в B2B — это условный Анатолий, который ненавидит накладные, или Игорь, которому важно, насколько быстро мы отвечаем на вопросы. Это не какие-то абстрактные сущности, а живые люди со своими сомнениями, болями и задачами.

И звонки — это один из немногих источников, где можно этот человеческий контекст достать, понять, что именно беспокоит людей, и уже потом «поженить» это с метриками и увидеть, что реально влияет на восприятие продукта.
Как вам удалось встроить обработанные данные с горячей линии в продукт и продажи?
Важно отметить, что мы пока не пришли к какому-то финальному виду процесса. Нельзя сказать, что всё, мы всё проверили, теперь делаем вот так и никак иначе. Мы ещё в процессе. Потому что хочется получать больше контекста, чтобы реальнее оценивать проблему.

Вот пример: в первой итерации анализа мы увидели огромное количество упоминаний электронного документооборота. Мы подумали: «Ужас, всех раздражает наш ЭДО! Наверное, интеграция работает плохо, или мы что-то не так отправляем». А потом, когда начали докапываться до контекста, оказалось, что проблемы как таковой нет. Просто люди спрашивают: «Мы сменили оператора ЭДО, подскажите, как вас теперь найти в Диадоке?» То есть это не претензия, а обычный рабочий вопрос.

Вот такие моменты хочется различать. И здесь всё упирается в промт: как задать правильный запрос, чтобы модель вытащила именно то, что нужно.

Мы пока только настраиваем процесс так, чтобы это всё можно было оперативно встроить в продуктовую разработку. Чтобы ребята из команды могли пользоваться AI-анализом как постоянным источником данных. Но даже сейчас мы уже забрали с горячей линии самые острые темы и начали с ними работать.

Например, у нас была история с ассортиментом. Пользователям что-то нравилось, а потом этот товар не приехал, или в дарксторах его пока нет. Такие ситуации знакомы всем ритейлерам. Но мы-то внутри знаем, что можем предложить аналог. Или знаем, где это можно найти, даже если пока не завели нужную позицию. Мы можем помочь — просто надо знать, кому и что предложить. И вот на этом этапе подключаем продажи. Мы передаём конкретные сигналы: вот у этих клиентов были запросы, а вот что мы можем им предложить. Составили матрицу, сделали на данных релевантные подборки — и ребята из отдела продаж уже звонят, пишут, рассказывают клиенту: «Смотрите, у нас есть решение».

По сути, продуктовая команда помогла собрать оффер, а дальше уже включился отдел продаж и помог клиентам закрыть потребность.
Кто в команде отвечал за запуск ИИ? Или ты один справился?
Да, один, никого больше не подключал. Объясню почему.

Во-первых, это просто чистое любопытство. Не сказать, что я себе какие-то баллы этим зарабатывал. Просто интересно было поковыряться, что-то почитать, попробовать. Мне такое в кайф.

А во-вторых — и это, наверное, главное — я не мог объяснить аналитикам, чего именно хочу в итоге, потому что сам не до конца понимал, что там увижу. Было ощущение, что в звонках точно есть какие-то паттерны, какие-то проблемы, но как это привести к какому-то виду, не знал. И понял: если сейчас это отдать аналитикам, всё растянется — будут задачи в трекере, обсуждения, распределение ролей. Притянем пару сильных ребят, они погрузятся, но на всё это уйдёт куча времени.

При этом было ощущение, что можно попробовать быстро, «на коленке». Пара промптов, небольшая модель, пусть даже для локальной транскрибации — и всё, можно будет что-то посмотреть. Я так и сделал. За пару вечеров всё запустилось, и, надо сказать, полетело неплохо.
Если другие компании захотят сделать похожее решение в формате MVP, что для этого нужно?
На этапе MVP точно не нужен квалифицированный дата-сайентист. Хватит и базовых технических навыков, чтобы хотя бы пощупать, понять, можно ли из этой истории что-то выжать. Желательно понимать хотя бы на базовом уровне, как работают библиотеки, как с ними обращаться, или знать Python, если кому-то он ближе.

Лучше всего, на мой взгляд, начать с Google Colab — это простейшее решение, где не нужно ставить никаких зависимостей, ничего устанавливать. Просто заходишь и сразу начинаешь работать.

Ещё один момент: я для себя понял, что на старте имеет смысл обратиться к той модели, которая хорошо пишет код. Я пробовал разные, и мне больше всего зашли Gemini от Google и Claude. Они хорошо справлялись с задачами и, главное, не теряли контекст, — это важно.

А дальше, когда у тебя уже что-то получилось, ты начинаешь задавать себе больше вопросов, видишь потенциал, понимаешь, в какую сторону копать. И вот тут можно начинать разворачивать эту историю, подключать других людей, если нужно. Но на старте всё вполне по силам даже неспециалисту.

Я даже могу поделиться фрагментами кода, показать, как это выглядит. Здесь нет какой-то большой тайны.
Фрагмент кода (кликабельно)
Роль: Ты — Principal Software Engineer, и тебе поручено спроектировать и реализовать с нуля data-пайплайн для анализа аудиозаписей. Ты обладаешь глубокими знаниями в области data-инжиниринга, асинхронного программирования и лучших практик безопасности. Твоя задача — создать систему, которая будет не только функциональной, но и производительной, надежной и готовой к масштабированию.

Проект: "Анализ Звонков"

Высокоуровневая цель: Разработать автоматизированный Python-пайплайн, который принимает на вход Excel-файл со ссылками на аудиозаписи звонков, обрабатывает их и возвращает тот же файл, обогащенный результатами транскрибации и анализа с помощью большой языковой модели (LLM).

Функциональные требования (Шаги пайплайна):

Входные данные: Пайплайн должен принимать путь к Excel-файлу. В файле есть как минимум колонка с URL-адресами аудиофайлов и колонки с персональными данными клиентов (PII), например, 'Название контакта', 'ИНН'.

Обработка аудио:

Для каждой строки в файле скачать аудиофайл по URL.

Транскрибировать скачанный аудиофайл с помощью openai-whisper.

Сохранить полученный текст в новую колонку Transcription_Text.

Очистка текста: Перед анализом текст транскрипции должен проходить базовую очистку: приведение к нижнему регистру, удаление спецсимволов и лишних пробелов.

Анализ текста с помощью YandexGPT:

Используя API YandexGPT, для каждой транскрипции определить:

Настроение клиента (например, 'Позитивное', 'Нейтральное', 'Негативное').

Ключевые "боли" клиента (проблемы, возражения).

Основные темы разговора (например, 'Оплата', 'Доставка', 'Техподдержка').

Портрет клиента (краткое саммари на 3-4 предложения, описывающее цель и манеру общения клиента).

Результаты каждого анализа сохранить в отдельные новые колонки.

Обеспечение безопасности:

Во время всего процесса обработки персональные данные клиентов (PII) в DataFrame должны быть зашифрованы.

Перед сохранением итогового файла PII-данные должны быть расшифрованы обратно в читаемый вид.

Выходные данные: Пайплайн должен сохранить итоговый DataFrame в новый Excel-файл, содержащий все исходные колонки, а также новые колонки с транскрипцией и результатами анализа.

Нефункциональные требования (Критерии качества):

Архитектура и Дизайн:

Спроектируй решение как единый, целостный модуль, предпочтительно в виде класса (например, CallAnalysisPipeline), который инкапсулирует всю логику.

Минимизируй операции чтения/записи на диск. Все промежуточные трансформации должны происходить в памяти с pandas.DataFrame.

Производительность:

Запросы к API YandexGPT являются наиболее вероятным узким местом. Ты обязан реализовать эту часть с использованием асинхронного подхода (asyncio, aiohttp) для обеспечения высокого параллелизма запросов (concurrent requests).

Надежность и Отказоустойчивость:

Пайплайн должен быть перезапускаемым (resumable). Если процесс прервется, при следующем запуске он должен автоматически определять уже обработанные строки и продолжать с места остановки. Реализуй механизм чекпоинтов (сохранение промежуточного результата каждые N строк).

Система должна быть устойчива к сбоям. Ошибка при обработке одной строки (например, неверный URL или сбой API) не должна останавливать весь пайплайн. Такие ошибки должны корректно логироваться.

Все сетевые операции (скачивание, API-запросы) должны иметь механизм повторных попыток с экспоненциальной задержкой.

Безопасность:

Для шифрования персональных данных используй криптографически стойкий симметричный алгоритм, предназначенный для долговременного хранения, например, AES в режиме GCM. Категорически запрещается использовать алгоритмы, токены которых имеют короткое время жизни по умолчанию (например, cryptography.fernet).

Конфигурируемость и Поддерживаемость:

Вынеси все настраиваемые параметры (пути к файлам, ключи API, параметры моделей, названия колонок) в единый конфигурационный объект (например, dataclass).

Реализуй исчерпывающее логирование с указанием этапов работы, времени выполнения ключевых операций и возникающих ошибок. Используй декоратор для логирования времени выполнения функций.

Формат вывода:

Один Python-скрипт, содержащий полную реализацию пайплайна.

Команда pip install ... для установки всех необходимых зависимостей.

Четкие комментарии в коде, объясняющие важные архитектурные решения.

Опционально: Включи функцию для оценки качества транскрипции по метрике WER.
А сейчас звонки транскрибируются автоматически? Или всё ещё вручную?
Сейчас автоматическая система не работает. Мы очень бережно относимся к персональным данным, особенно на этапе MVP. Чтобы ничего не выносить наружу, мы стараемся держать всё внутри контура. А чтобы сразу реализовать полноценную автоматическую интеграцию — через API, забирать звонки напрямую из телефонии, что-то копировать, размечать — нужны были ресурсы, которых не было. Тем более что для нас это вообще была неизведанная тропа, мы шли на ощупь.

Поэтому мы сделали просто: вручную сформировали список звонков. Сделали буквально Excel-таблицу со ссылками на записи, размеченную: кто звонил, какая тема, какое направление. Храним данные у себя, ничего наружу не уходит. Потом берём этот массив и прогоняем его через инструмент. Всё максимально локально.

Это решение «на коленке», но оно работает. Сформировать такую выборку — дело нескольких минут, получаса. Иногда нам помогают ребята из CRM: мы собираем когорту интересных нам обращений и начинаем смотреть, что в ней происходит.
Почему не стали использовать встроенные инструменты IP-телефонии?
У нас действительно IP-телефония, и я знаю, конечно, что у провайдеров вроде Mango или UIS уже встроены функции транскрибации, тегирования, меток по словам. Можно зайти в личный кабинет, поставить, например, фильтр на слово «неудобно» или «брак» — и получить список звонков, где оно прозвучало.

Но мы в эту сторону даже не пошли. Всё, что у нас получилось, — это результат чистого энтузиазма. Нам просто хотелось попробовать, насколько по-своему можно покрутить промпты, достать что-то особенное, поискать закономерности.

Я уверен, что у ребят из телефонии есть похожие решения, но мы выбрали свой путь. Когда ты не до конца знаешь, чего именно хочешь, но у тебя есть скиллы и возможность поэкспериментировать бесплатно, ты, скорее всего, попробуешь сам. А не пойдёшь сразу писать запросы: «А давайте вот это сделаем, а можно вот это?» Всё-таки у провайдеров телефонии каждая доработка под конкретного клиента — это всегда время, деньги и отсутствие гибкости. Нам же было важно почувствовать свободу, полёт фантазии, поиграть с промптами. Но, думаю, те ИИ-инструменты, что есть у ребят из телефонии, — тоже мощная штука.
Какие планы по развитию ИИ-подхода — будете масштабировать?
Первое и самое простое — научить команду использовать этот источник данных. Мы сейчас поняли, как лучше записывать промпт, чтобы доставать нужный контекст, и хотим показать продуктовым командам, как это можно применять.

Если у кого-то, условно, возникает вопрос: «Что делать в первую очередь — работать над конверсией или копать в другую сторону?», можно не бежать сразу к исследователям. У них ведь и так огромный бэклог задач и постоянный поиск респондентов. Мы можем сами быстро достать нужный контекст с помощью ИИ-инструментов. Это не замена классическому исследованию, но хороший способ быстро проверить гипотезу, не оступиться и принять объективное решение.

Следующий шаг — масштабировать обработку. Перейти на более серьёзные модели транскрибации, где меньше ошибок и выше качество данных, потому что сейчас всё работает в условиях ограниченных ресурсов. Условно: нет нужных графических процессоров, чтобы обрабатывать всё молниеносно. Но если подставить более мощную модель, получится более качественный контекст и точнее выводы.
Как ещё можно использовать данные из звонков? Что хочется сделать в перспективе?
Есть как минимум два направления. Первое — это быстро помочь продажам: посмотреть, какие вопросы менеджеры задают и какие не задают, хотя могли бы, исходя из контекста разговора. Это уже большое поле для развития.

А второе — более масштабное. Мы ведь сегментируем клиентов по жизненному циклу: от новичка до стабильно активного или того, кто уходит в отток. И можно взять контекст звонков и посмотреть, что говорили клиенты перед оттоком или, наоборот, что говорят те, кто удерживаются на стабильном уровне.

На основе этого мы сможем собрать живой портрет клиента — то, что он действительно говорит, а не то, что просто отражено в цифрах. И тогда можно будет делать настоящую персонализацию. Не просто «скидка 5% для всех», а, например: «Вот у этого клиента был запрос на капусту, которой сейчас нет». Такому человеку бессмысленно делать общую рассылку — это не создаст лояльности. А вот персонализированный оффер, когда ты реально услышал клиента, работает.

Идея в том, чтобы перед звонком менеджер получал подсказку: «Компания такая-то. За все время взаимодействия поднимались такие-то темы. Возможно, стоит обсудить вот это, вот это и вот это». Это очень круто усиливает доверие и лояльность со стороны клиента.

Но при этом важно, чтобы команда правильно воспринимала процессы. Здесь история не про контроль и проверку, а про дополнительный полезный инструмент. ИИ не заменит человека, не сделает за него звонок, но он точно поможет. Например, когда менеджер готовится к встрече и не знает, с чего начать, вот тогда такой инструмент действительно может быть полезен.

И никаких чудес тут нет. Два промпта не превращаются сразу в Клондайк инсайтов, так это не работает. Всё по чуть-чуть, итеративно и аккуратно.
Автор: Денис Лялин
Руководитель отдела клиентского пути Вкусвилл Бизнес
Куратор: Андрей Шапран
Редактор: Эля Кузнецова
Над статьёй работали

Рекомендуемые статьи