Как Qlean отказался от найма под сезон и автоматизировал поддержку с помощью ИИ-агентов

Опытом делится Лев Оганезов, product manager в Qlean.

Всем привет! Меня зовут Лев, я product manager, и моя специализация — автоматизация бизнес-процессов. Сегодня я хочу поделиться кейсом о том, как нам удалось перестроить поддержку в Qlean, автоматизировать значительную долю чатов и уйти от постоянного наращивания костов на ФОТ.

Qlean — это сервис бытовых услуг по модели «Uber для клининга». Пользователи заказывают через нас уборку квартир (от поддерживающей до послеремонтной) и вызывают химчистку на дом. В среднем мы обрабатываем около 60 000 обращений в месяц.

В какой-то момент бизнес начал быстро расти. Разумеется, пропорционально росла и нагрузка на поддержку. У нас ярко выражена сезонность: в пиковые периоды приходилось экстренно наращивать команду, а в низкий сезон — ломать голову, как перераспределить ресурсы. Цель стояла амбициозная — автоматизировать омниканальную систему клиентских обращений до 90%, не раздувая штат. Решение напрашивалось само собой — внедрение AI.

Шаг 1. Аналитика: а надо ли оно нам?

Перед тем как бросаться внедрять нейросети, нужно было оцифровать базу:

• Сколько обращений в месяц мы получаем?
• С чем реально пишут юзеры?
• Сможем ли мы это автоматизировать?
• Не дешевле ли просто нанять еще людей?

Посчитать общее количество тикетов в хелпдеске было легко. А вот понять суть запросов — сложнее. CRM дает лишь примерную картину, так как человеческий фактор никто не отменял. Нам нужна была конкретика. Мы написали скрипты, с помощью которых удалось выгрузить все диалоги за месяц и скормили их AI для категоризации.

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

Self-service — даем пользователю инструменты решить вопрос самому. Прямые ответы бота — для типовых запросов. Сценарии через API — для сложных действий.

Стало понятно: мы смело можем целиться в автоматизацию минимум 40% запросов.

Шаг 2. Экономика и инструменты: выбираем модель и платформу

Когда мы поняли, с какими запросами приходят пользователи, встал главный вопрос: а будет ли экономика ИИ вообще биться с нашими реалиями? Или все-таки дешевле по старинке нанять еще людей?

Цена за токены напрямую зависит от модели, поэтому сначала нужно было определиться с «движком». Мы сделали ставку на Grok 3 mini. Чуть позже расскажем почему.

Чтобы не действовать вслепую, мы собрали подробную матрицу оценки (своего рода калькулятор юнит-экономики бота). Логика была следующей:

1. Мы взяли все наши выделенные категории обращений.
2. Прикинули среднее количество сообщений (а значит, и токенов) на решение вопроса в каждой категории.
3. Рассчитали стоимость закрытия одного тикета силами ИИ (в рублях за токены).
4. Сравнили это со стоимостью закрытия тикета живым специалистом.

Мы просчитали несколько сценариев и везде цифры показали, что даже с учетом затрат на токены для LLM, дельта в стоимости поддержки выходит существенно в нашу пользу. Внедрять ИИ было выгодно.

Сначала мы думали пилить всё in-house. Но быстро отказались от этой затеи: проект рисковал превратиться в «фестиваль костылей», сожрал бы массу IT-ресурсов, да еще и добавил бы головной боли с шифрованием и ФЗ-152. Около двух месяцев мы проводили интервью с вендорами и в итоге остановились на платформе Wikibot. Наш выбор пал на них по нескольким причинам:

• Удобный личный кабинет, в котором комфортно работать.
• Гибкость настроек, позволяющая выстраивать нужную нам логику.
• Понятная аналитика и прозрачное ценообразование.
• Суперкрутая и амбициозная команда. Видно, что ребята горят своим продуктом и постоянно его улучшают.

Шаг 3. Выбор LLM: почему мы сделали ставку на Grok 3 mini?

Многие могут спросить, прочитав про выбор модели: почему Grok 3 mini, а не более современные и расхайпленные флагманы?

Да, модель уже немного «старенькая», но для наших задач она подошла идеально:

1. Экономика: Она дешевая, что критично при наших объемах в десятки тысяч диалогов.
2. Function Calling: Она невероятно круто и стабильно работает с функциями и API.
3. Управляемость: Модель легко поддается обучению. Если подойти к промптингу с умом, можно добиться выдающихся результатов.

При этом мы не ограничиваем себя. Если в сценарии возникает потребность обработать медиафайл (фото или видео от клиента), мы не заставляем Grok ломать об это зубы. Система просто точечно подключает на этот конкретный шаг более современную «тяжелую» мультимодальную модель, а затем возвращает управление обратно. Это позволяет держать идеальный баланс между стоимостью и качеством.

Шаг 4. Пилот на Химчистке и столкновение с реальностью

Пилот решили запускать на химчистке — это более понятный и управляемый продукт. Мы настроили аналитику и запустили первую версию.

Первая архитектура была до боли простой: один гигантский промпт на 10 000+ токенов, в который мы попытались впихнуть вообще всё. И, как это часто бывает, технические проблемы выявились уже после реального внедрения.

Монолитный подход с треском провалился:

• Инструкции внутри промпта начали конфликтовать друг с другом.
• Агент периодически терял контекст диалога.
• Вносить даже мелкие правки стало страшно — одно изменение ломало логику в другом месте.

При этом бот всё равно умудрялся закрывать около 20% из 10 000 обращений в месяц! Но мы понимали, что так далеко не уедем.

Шаг 5. Смена архитектуры: Router-Executor

Мы полностью пересобрали логику. Вместо одного «всезнающего» бота внедрили гибридную архитектуру:

1. Диспетчер (Router): Мы вычистили из него все тексты ответов. Теперь он работает исключительно как маршрутизатор — определяет интент и кидает диалог в нужный поток.
2. Direct Answer: Обрабатывает фаст-фуд запросы (простые «привет/спасибо/до свидания»).
3. Article-Executor: Вытаскивает и отдает ответы строго по статьям из базы знаний.
4. Specialized Agent: Вызывает нужного «субагента» для сложных API-сценариев (например, оформление заказа).

Для чистоты работы агентов приходилось учитывать массу нюансов. Например, мы жестко прописали инструкции, чтобы бот игнорировал определенные параметры статуса заказа, если клиент в процессе диалога резко менял тему.

Шаг 6. Контроль качества и дообучение: как мы понимаем, где бот не справляется

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

Для этого мы реализовали в хелпдеске логику автоматического тегирования. В момент закрытия тикета или его передачи на живого специалиста, система (агент) автоматически проставляет в карточке заявки следующие поля:

1. Тип обращения: с каким именно интентом пришел юзер (те самые наши категории).
2. Причина перевода: если бот не справился и позвал человека, он обязан «объяснить» почему. Например: превышен лимит сообщений, для решения нужен сложный сценарий, или он просто не нашел ответ в базе знаний.
3. Саммари диалога: краткий пересказ того, что хотел клиент и что сделал бот до момента перевода.
4. Бот поплыл: специалист может самостоятельно заполнить поле и тем самым подсветить, где бот плохо себя проявил. Что нам это дало? Мы получили возможность регулярно выгружать список заявок и видеть кристально чистую картину. Мы четко понимаем, кто и с чем пишет, в каких категориях бот отрабатывает блестяще, а где откровенно плавает. Если мы видим, что категория «Виды обработки (химчистка / Аквачистка)» стабильно уходит на оператора с причиной «не знает ответ» — мы просто идем и дополняем статью в базе знаний для Article-Executor'а.

Дополнительно мы настроили подсчет количества сообщений в диалогах (от клиента, бота и оператора). Эта метрика оказалась критически важной: она помогает нам вычислить, какой лимит сообщений нужно выставлять для каждой конкретной категории.

Что получилось в цифрах

После обкатки гибридной архитектуры на химчистке мы раскатали решение на более крупный продукт — клининг и сейчас занимаемся этой историей.

Текущие показатели:

• Химчистка: бот закрывает 68% запросов (при объеме 10 000 обращений/мес). CSAT держится на отличной отметке 4.0.
• Клининг: бот закрывает 31% запросов (при объеме 50 000 обращений/мес). CSAT вырос с 3.1 до 4.2.
• Скорость: Среднее время ответа сократилось до 34 секунд.

Самое главное — мы сняли зависимость от сезонных пиков. Вместо бесконечного найма мы выстроили управляемую систему, а живых операторов перевели на решение действительно сложных, нестандартных клиентских кейсов.

Что дальше?

Мы продолжаем масштабировать логику. Ближайший план:

• Довести долю закрытия до 90%.
• Дообучить бота работе с полноценными API-действиям.
• Переехать на более стабильную омниканальную платформу.
• Развивать исходящие коммуникации в связке с AI и глубокий self-service.

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