В поддержку Mindbox ежегодно поступает более 50 000 обращений. Чтобы справляться с таким потоком, требуется 16 специалистов поддержки. Они разбирают документацию, находят ответы и помогают клиентам.
Чтобы отвечать быстрее и упростить работу поддержки, мы решили ее автоматизировать. Всего за три месяца нам удалось выстроить рабочий алгоритм, собрать базу знаний из десятков тысяч материалов и запустить MVP.
Теперь бот закрывает 15–20% запросов и отвечает за 25 секунд. Нагрузка на команду поддержки снизилась, а удовлетворенность клиентов (CSAT) AI-помощником поддержки составила около 90%. В этой статье — кейс, как нам удалось сделать такого бота своими силами.
Дисклеймер: в этой статье мы описываем разработку первой версии бота. Это наша проба пера: мы впервые работали с AI и где-то сделали слишком просто. Сейчас мы дорабатываем бота, он уже стал умнее. О том, что мы дорабатывали, расскажем в следующих материалах. Например, расскажем, как оптимизировали подготовку материалов базы знаний, чтобы не тратить на нее кучу человекочасов и денег, а также как сделали всю систему более гибкой и адаптивной.
Про автора и Mindbox
Меня зовут Тимофей Столяров. Я работаю AI-продакт-менеджером в Mindbox и отвечаю за то, чтобы рутинные и сложные процессы в компании можно было делегировать нейросетям. Бот поддержки оказался моим первым успешным проектом, с которого я начал развиваться как продакт-менеджер.
Основной продукт Mindbox — это облачная CDP-платформа автоматизации маркетинга. С ее помощью маркетологи отправляют email- и SMS-рассылки, управляют программами лояльности, запускают попапы и квизы на сайтах.
Почему решили автоматизировать техподдержку
Во время работы с Mindbox у маркетологов и разработчиков возникают вопросы. Например, как настроить обмен данными с сайтом или как добавить виджет товарных рекомендаций на сайт через Javascript SDK. Ответы на эти вопросы часто есть в публичном доступе. Но для удобства клиентов у нас работает поддержка.
Обращения, которые приходят в поддержку, часто повторяются — разные клиенты задают одни и те же вопросы, но могут использовать свои формулировки. Например, один напишет: «не получается загрузить фид», другой — «почему товары не обновляются?», третий — «пустые карточки после импорта». Формально — ни одного совпадения по словам, а по факту — все жалуются на один и тот же баг.
Чтобы не писать новый ответ на каждое обращение, специалисты создают статьи и загружают их в справку Mindbox — внешнюю базу данных для клиентов. Вот основные хранилища:
справка Mindbox — внутренний архив ответов на прошлые обращения;
help.mindbox.ru — база с инструкциями для маркетологов, которые работают с продуктом через административный доступ;
developers.mindbox.ru — технические инструкции по интеграции и настройке API, обычно нужны разработчикам;
Mindbox Журнал — корпоративный блог платформы, где публикуются кейсы клиентов и учебные материалы для маркетологов.
Если объединить все данные с помощью ИТ-архитектуры, можно научить нейросеть находить нужную информацию и передавать клиентам в чате поддержки. Это позволит ускорить обработку запросов и разгрузить сотрудников. С этой идеи началась разработка автоматического оператора.

Как устроен бот поддержки
Цель AI-бота в том, чтобы снизить нагрузку на команду поддержки и ускорить ответы, сохранив их качество. Достичь ее можно с помощью LLM, которая могла бы искать материалы в базе Mindbox и генерировать ответы на запросы.
Существуют разные подходы к генерации, я выбрал Retrieval-Augmented Generation (RAG). Это подход, при котором языковые AI-модели ищут информацию в базе знаний, а затем формируют на ее основе связный текст и передают его пользователю через цепочку ассистентов.
RAG позволяет приблизить точность ответов к 100% за счет того, что нейросеть ориентируется по базам данных, а не придумывает ответ сама. Построить стабильный продукт только на основе LMM-модели почти невозможно. Модель будет придумывать несуществующие данные и выдавать их за правду.

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

Каждый поступающий запрос получает свой вектор, по которому инструменты векторного поиска находят материалы, близкие по смыслу, и формируют на их основе ответ.
Если искать информацию по всем материалам, которые у нас есть, точность и скорость будут низкими. Поэтому я разделил данные по тематическим кластерам. Например, в кластер «Маркетинг» ушли кейсы Mindbox, статьи по продажам, продвижению, стратегиям. В «Инструкции» — гайды по настройке приветствия, сценариев, персонализации. В «Разработку» — интеграции с сервисами, Javascript SDK. Если вопрос технический, бот придает больший вес инструкциям и мануалам, если маркетинговый — кейсам и гайдам.
Так ассистент быстрее находит нужную информацию. Он не перебирает все 50 000 документов, а сначала смотрит на категорию вопроса, кодирует его в числа и дальше сравнивает с вариантами из нужного кластера.

Как работает бот поддержки и почему у него несколько ассистентов
Подготовку ответа можно разделить на 5 шагов:
Уточняем запрос.
Определяем категорию вопроса.
Ищем нужный материал.
Проверяем релевантность материала.
Генерируем ответ.
Каждую из этих задач выполняет отдельный ассистент. Они последовательно обрабатывают вопрос: уточняют, ищут информацию, отвечают. Это нужно, чтобы избежать ошибок, сохранить скорость и качество ответов. Если все делает один ассистент, результаты получаются неточные, так как у него хранится очень много инструкций.
Итак, разберем каждый шаг в отдельности.
Шаг 1: уточняем запрос. Иногда первое сообщение боту — неполное или двусмысленное. Чтобы прояснить его, первый ассистент задает уточняющие вопросы. Например, если клиент напишет «рассылка имени», то бот задаст уточняющий вопрос: «Вы имеете в виду, как вставить имя в рассылку или что-то другое?»
Шаг 2: определяем категорию вопроса. После того как вопрос уточнен, второй ассистент определяет его категорию: «сегментация», «интеграции», «маркетинг» или одна из еще 20 категорий. И формулирует поисковый запрос, по которому стоит искать материалы. Например, «параметры подстановки имени в рассылки», «как вставить имя клиента в рассылку», «подстановка стандартных имен в коммуникации». Это происходит под капотом и не видно клиенту.
Шаг 3: ищем информацию. Следующий ассистент ищет в базе знаний материалы по этим поисковым запросам и фильтрует их по категории. Например, если вопрос не технический, то поиск идет среди статей help и текстов с экспертизой вопросов-ответов, а статьи с developers про интеграцию будут намеренно пропущены, потому что не отвечают запросу. Поиск материалов происходит через векторные значения (это не AI, просто набор цифр, который оцифровывает смысл вопроса. В базе находятся «похожие» цифры — об этом писали выше).

Шаг 4: проверяем релевантность материала. Каждый найденный материал дополнительно проверяется: отвечает ли он на вопрос пользователя. Это уже делает AI. Он отсеивает все лишнее и оставляет только те документы, которые реально помогут пользователю. Для этого в базовом промпте ассистента прописан фильтр-вопрос: «Эта статья поможет ответить на вопрос?» Если ответ отрицательный, материал исключается. Если положительный, остается в выборке.
Шаг 5: передаем информацию пользователю. На этом шаге задачу подхватывает один из нескольких ассистентов: тот, который лучше всего отвечает на данную категорию вопросов. Например, для ответов на вопросы про мобильные пуши подключается ассистент с инструкциями про мобильные пуши — он будет лучше давать инструкции, приводить примеры кода для приложения, так как такие вопросы часто могут задавать разработчики. А у других ассистентов инструкции могут быть на понятном маркетологу языке.
Ассистент получает инструкции с прошлых шагов, а также вопрос клиента и на их основе формулирует ответ.

Где работает бот и как с ним взаимодействует команда
Технически бот работает на выделенном сервере.
На сервере лежат базы знаний: статьи, справка, архив обращений и обучающие материалы. Когда команда поддержки обновляет или добавляет новые тексты, они просто загружаются в нужную папку на сервере. После этого бот автоматически получает к ним доступ и может использовать в своих ответах.
Таким образом, сервер служит хранилищем данных и рабочей средой для AI-ассистента, а команда контент-редакторов и разработчиков подключается к нему только для обновления информации или доработки алгоритмов.
MVP и первый запуск в продукте
Весь проект начался в 2024 году. Это было полностью моей инициативой, поэтому я же и разрабатывал решение. Мне пришлось разобраться в теме LLM-моделей с нуля и на основе экспериментов сформировать рабочий пайплайн обработки вопросов, затем собрать и протестировать несколько прототипов.
В 2024 году специализированных статей и гайдов о том, как собрать бота поддержки, было немного. Инструкции в сети часто не имели внятной документации. Инструменты вроде n8n (low‑code решения для автоматизации без программирования) были слабо развиты для использования с AI-агентами, либо я о них просто не знал.
Первую версию бота я написал на Python — со своими пайплайнами, логикой и логами. Через три месяца появилась первая рабочая версия, мы протестировали ее и запустили MVP на части клиентских проектов.
После запуска мы начали наблюдать, как клиенты взаимодействуют с ботом и как сотрудники поддержки подключаются к диалогам после него. Наша цель была — проверить технологию и убедиться, что бот действительно помогает пользователям и не создает дополнительных сложностей.
Пилот длился несколько месяцев, и после бот заработал на всех активных проектах. За это время мы улучшили качество ответов, добавили новые материалы в базу и сделали еще проще переключение на оператора: если клиенту нужен живой специалист, его легко можно пригласить в чат.
Параллельно работу ассистента оценивали специалисты поддержки. Они анализировали диалоги клиентов, выделяли слабые места в ответах. Если находили неточности, корректировали материалы в базе, на которой обучался AI. Сейчас удовлетворенность клиентов новым продуктом (CSAT) составляет около 90%.
Результаты и планы развития
После запуска бота мы получили три основных эффекта:
15–20% клиентских обращений теперь закрываются автоматически — без участия человека. Это снизило нагрузку на команду и сократило время ожидания ответа: медианное время — 25 секунд.
Бот работает круглосуточно. Даже если вопрос поступает ночью, клиент получает базовые подсказки и может продолжить работу, не дожидаясь начала рабочего дня.
Бот берет на себя простые, повторяющиеся запросы, освобождая время специалистов для сложных и нестандартных ситуаций.
При этом структура работы поддержки не изменилась: команды продолжают работать с теми же процессами. Просто теперь при планировании найма мы учитываем, что часть задач решается автоматически, и можем гибко распределять ресурсы без расширения штата.
Сейчас бот не имеет доступа к данным конкретных проектов — это осознанное решение. Но мы уже готовим инфраструктуру, чтобы он мог безопасно работать с частью клиентских данных, например подсказывать фильтры, зная, какие уникальные поля есть в проекте.
Также сейчас у бота нет собственной системы навигации — интерфейса, где можно было бы визуально искать информацию или отслеживать, какие категории уже охвачены. В будущих итерациях мы планируем добавить интерфейсную часть: панель, где можно будет визуально управлять структурой знаний, редактировать связи между материалами и контролировать, какие документы участвуют в обучении. Это станет следующим шагом развития системы и сделает работу с базой данных прозрачнее и удобнее. Следите за новостями, будем делиться прогрессом.
Часть из этих планов мы уже реализовываем. Как все прошло и какие результаты получили, расскажем в следующих статьях.