Как мы построили AI-систему продаж для автопроката YETI в Дубае

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

Пока менеджер занят или спит, клиент продолжает искать. Чаще всего бронь получает прокат, который ответил первым.

Для YETI мы построили не просто чат-бота, а специализированную AI-систему продаж. Она принимает обращения из WhatsApp, понимает запрос клиента, ведёт его по процессу бронирования, получает актуальные данные об автомобилях, проверяет документы и формирует готовую сделку в Kommo CRM.

WhatsApp в этой системе — только интерфейс общения с клиентом. Основная работа происходит внутри серверной архитектуры, которая управляет AI-агентами, данными, очередями сообщений и состоянием каждой сделки.

Проект в цифрах

Внутри решения:

• 3 специализированных AI-агента;
• 12 этапов бронирования;
• WhatsApp Business как основной канал;
• Kommo CRM как рабочая система менеджеров;
• отдельная база автомобилей и тарифов;
• автоматическое заполнение карточки сделки;
• распознавание документов с помощью компьютерного зрения;
• поддержка русского и английского языков;
• хранение контекста переписки;
• очереди входящих сообщений;
• защита от параллельной обработки одной сделки;
• защита от повторной отправки ответов;
• собственное серверное приложение.

Первая рабочая версия была собрана на n8n. После проверки логики на реальных диалогах систему полностью перенесли в отдельное приложение на Node.js.

Почему обычного чат-бота было недостаточно

Со стороны процесс аренды автомобиля может выглядеть просто:

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

Менеджеру необходимо узнать:

• город аренды;
• дату начала;
• продолжительность аренды;
• предпочтительный класс автомобиля;
• подходящую модель;
• тип страховки;
• условия депозита;
• дополнительные услуги;
• способ получения автомобиля;
• контактные данные;
• наличие необходимых документов.

Клиент при этом редко присылает всю информацию одним сообщением. Обычно переписка выглядит так:

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

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

1. понимает, что уже сообщил клиент;
2. определяет текущий этап бронирования;
3. запрашивает только недостающие данные;
4. получает актуальную информацию из базы;
5. записывает результат в CRM;
6. передаёт диалог менеджеру в правильный момент.

Как работает система

Общая схема выглядит так:

Дополнительно к этому процессу подключён отдельный AI-агент, который анализирует фотографии документов.

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

После этого несколько коротких сообщений могут быть объединены в один запрос. Например:

Система передаёт AI не четыре независимых события, а одну собранную мысль:

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

• запросить город;
• уточнить дату;
• сохранить срок аренды;
• получить автомобили из базы;
• показать варианты;
• запросить документ;
• заполнить поле в Kommo;
• передать диалог менеджеру.

После этого отдельный AI-презентер формулирует ответ клиенту.

Почему внутри работают три AI-агента

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

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

Поэтому мы разделили систему на три узких роли.

1. AI-администратор

Это управляющий агент системы. Он не общается с клиентом напрямую. Его задача — принять решение о следующем действии.

Администратор получает:

• новое сообщение;
• историю переписки;
• данные карточки Kommo;
• текущий этап бронирования;
• уже заполненные параметры;
• доступные системные действия.

После анализа он возвращает структурированное решение:

• какое поле нужно сохранить;
• какой этап установлен сейчас;
• достаточно ли данных для поиска автомобиля;
• нужно ли обратиться к базе;
• нужно ли проверить документ;
• какой вопрос требуется задать;
• пора ли передавать сделку менеджеру.

Администратор не имеет права придумывать цены, модели или условия. Коммерческие данные он получает только из базы.

2. AI-презентер

Это единственный агент, который пишет клиенту. Он получает готовое решение администратора и превращает его в короткое естественное сообщение на языке клиента.

Например, администратор определил:

Презентер формулирует:

Главное ограничение презентера — один вопрос в одном сообщении. Он не отправляет клиенту анкету из восьми пунктов и не перегружает диалог. Процесс выглядит как нормальная переписка с менеджером.

3. AI-агент проверки документов

Этот агент подключается, когда клиент присылает фотографию документа. Он анализирует изображение и определяет:

• является ли файл документом;
• какой тип документа изображён;
• читается ли фотография;
• не обрезаны ли важные области;
• можно ли продолжить оформление.

Система принимает паспорт, Emirates ID или водительские права. Для продолжения достаточно одного подходящего документа.

При этом AI не принимает юридическое решение о допуске клиента к аренде. Он только отсеивает очевидно неподходящие изображения и просит прислать новую фотографию, если документ невозможно прочитать. Окончательное решение остаётся за сотрудником проката.

12 этапов бронирования

Диалог построен вокруг формального состояния сделки. Система всегда знает, на каком этапе находится клиент и какие данные уже получены. Процесс состоит из 12 этапов:

1. Определение города, даты начала и срока аренды.
2. Выбор класса автомобиля.
3. Поиск доступных автомобилей.
4. Выбор конкретной модели.
5. Выбор страховки.
6. Выбор условий депозита.
7. Выбор дополнительных услуг.
8. Доставка или самовывоз.
9. Подтверждение итоговых условий.
10. Получение и проверка документов.
11. Подтверждение контактных данных.
12. Передача сделки менеджеру и отключение AI.

Этапы не означают, что бот механически задаёт 12 вопросов подряд. Клиент может сразу написать:

Система извлечёт из сообщения город, класс, дату и срок аренды. Эти данные будут сохранены, а повторно спрашивать их AI не станет.

Жёсткие условия перехода между этапами

Некоторые этапы нельзя пропустить. Например, система не должна показывать автомобили, пока не знает:

• город;
• дату начала;
• срок аренды;
• класс автомобиля.

Без этих параметров невозможно корректно проверить наличие и определить цену. Поэтому перед обращением к базе система проверяет обязательные поля. Если одного из них нет, AI продолжает сбор данных.

Такой механизм не позволяет модели «помочь клиенту» выдуманным ответом. AI не решает, какие автомобили существуют. Он решает, какие данные нужно запросить, а список машин получает из отдельного источника истины.

Откуда AI получает автомобили и цены

Информация об автопарке хранится отдельно от языковой модели. В базе находятся:

• модели автомобилей;
• классы;
• города;
• тарифы;
• ограничения;
• доступные варианты;
• дополнительные условия.

Когда обязательные параметры собраны, AI-администратор вызывает серверную функцию поиска. Функция возвращает только автомобили, соответствующие запросу клиента. После этого презентер формирует понятное предложение.

Как данные попадают в Kommo

Kommo используется не только как место хранения переписки. По мере разговора система обновляет карточку сделки:

• город;
• дата начала аренды;
• продолжительность;
• выбранный класс;
• выбранный автомобиль;
• страховка;
• депозит;
• дополнительные услуги;
• вариант получения машины;
• статус документов;
• язык клиента;
• текущий этап бронирования.

Когда AI передаёт сделку менеджеру, сотруднику не нужно перечитывать весь чат и вручную переносить данные. Он получает структурированную карточку с уже собранными параметрами. Переписка при этом остаётся в Kommo, поэтому менеджер может проверить контекст и продолжить разговор с того же места.

Инженерная проблема, которую не видно клиенту

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

Клиент пишет несколько сообщений подряд

Человек может отправить четыре сообщения за пять секунд. Если запускать AI на каждое из них, система сформирует несколько параллельных ответов.

Поэтому мы добавили окно агрегации. После входящего сообщения система делает короткую паузу. Если за это время приходят новые сообщения, они объединяются и обрабатываются вместе.

Одну сделку нельзя обрабатывать параллельно

Пока система формирует ответ, клиент может прислать ещё одно сообщение. Без блокировки два процесса одновременно прочитают одно состояние сделки и начнут его изменять. В результате могут появиться:

• два ответа;
• повторно созданные действия;
• конфликтующие значения полей;
• неверный этап бронирования.

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

WhatsApp и CRM должны оставаться синхронизированными

Сообщение проходит через несколько систем: WhatsApp, канал связи, Kommo, серверное приложение, AI-модель и базу данных. Любое событие может быть доставлено повторно или с задержкой. Поэтому система хранит идентификаторы обработанных событий и перед отправкой проверяет, не был ли такой ответ уже сформирован.

Состояние нельзя хранить только в истории чата

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

• текущий этап;
• собранные параметры;
• выбранный автомобиль;
• ранее показанные варианты;
• язык клиента;
• состояние передачи менеджеру;
• результат проверки документа.

AI получает эту структуру вместе с историей, но не восстанавливает весь процесс с нуля при каждом сообщении.

Первая версия: быстрый запуск на n8n

Первую версию системы мы собрали на n8n. Для прототипирования это было правильным решением. n8n позволил быстро подключить Kommo, принимать сообщения, обращаться к AI, тестировать промпты, работать с базой автомобилей, проверять документы и запускать первые реальные диалоги.

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

Сложность изменений

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

Очереди и блокировки

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

Отладка

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

Поддержка

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

n8n выполнил свою задачу: позволил быстро проверить продуктовую гипотезу. Но производственная система переросла формат прототипа.

Миграция на собственное приложение

После проверки бизнес-логики мы перенесли систему в отдельное серверное приложение на Node.js. Поведение для клиента осталось прежним:

• тот же WhatsApp;
• тот же стиль общения;
• те же этапы;
• те же автомобили;
• та же передача менеджеру.

Изменилась внутренняя архитектура. Логика была разделена на независимые модули:

• приём событий;
• агрегация сообщений;
• очередь обработки;
• блокировка сделок;
• хранение состояния;
• AI-администратор;
• AI-презентер;
• проверка документов;
• интеграция с Kommo;
• работа с базой автомобилей;
• отправка сообщений;
• журналирование ошибок.

После миграции каждую часть можно изменять и тестировать отдельно.

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

В итоговой версии используются:

• Node.js — серверная среда;
• Express — приём входящих событий и HTTP-слой;
• Redis — очереди, временное состояние и блокировки;
• PostgreSQL — автомобили, тарифы и постоянные данные;
• Kommo API — сделки, поля, этапы и переписка;
• WhatsApp Business API — канал общения;
• OpenAI GPT — анализ диалога и формирование ответов;
• компьютерное зрение (vision-модель) — анализ изображений документов;
• Docker — развёртывание сервисов;
• Git — контроль версий кода и промптов.

Промпты AI-агентов хранятся отдельно от основной логики приложения и также версионируются. Это позволяет увидеть, какое правило действовало в конкретный момент, сравнить версии и при необходимости откатить изменение.

Как развивался проект

Проект прошёл несколько последовательных стадий.

• Версия 1. Проверка идеи. Базовый AI отвечает на сообщения и собирает часть данных.
• Версия 2. Формальный процесс бронирования. Диалог разделён на этапы. Появляется состояние сделки и обязательные условия перехода.
• Версия 3. Интеграция с реальным автопарком. AI перестаёт предлагать автомобили самостоятельно и получает их из базы.
• Версия 4. Три специализированных агента. Принятие решений, формулировка ответов и анализ документов разделяются.
• Версия 5. Работа с очередями сообщений. Добавляются агрегация реплик, блокировки сделок и защита от дублирования.
• Версия 6. Проверка документов. Система начинает анализировать присланные изображения и запрашивать повторное фото при необходимости.
• Версия 7. Миграция с n8n. После проверки процесса вся производственная логика переносится в собственное приложение.
• Версия 8. Управляемая эксплуатация. Добавляются журналирование, версионирование промптов, контроль ошибок и возможность безопасно изменять отдельные компоненты.

Что пришлось переделывать

Проект не появился сразу в окончательном виде. Некоторые компоненты мы переписывали несколько раз. В частности:

• меняли модель хранения состояния диалога;
• переделывали обработку нескольких сообщений подряд;
• усиливали защиту от параллельных ответов;
• разделяли функции одного AI между несколькими агентами;
• меняли правила перехода между этапами;
• перерабатывали механизм выбора автомобилей;
• переносили логику из n8n в Node.js;
• выносили промпты из процесса в отдельные версионируемые файлы.

Это нормальная часть разработки AI-системы, которая работает не в демонстрации, а с реальными клиентами. Главная сложность здесь не в том, чтобы получить от модели красивый ответ. Главная сложность — сделать поведение системы устойчивым при неполных данных, повторных событиях, нестандартных сообщениях и параллельных диалогах.

Что система не делает

YETI не заменяет весь отдел продаж. Система сознательно не выполняет несколько действий.

• Не принимает окончательное решение по клиенту. AI может проверить тип и качество фотографии документа, но не определяет юридическую допустимость аренды.
• Не принимает оплату и не выдаёт автомобиль. Оплата, договор, окончательное подтверждение и передача машины остаются за сотрудником.
• Не придумывает наличие и цены. Все коммерческие данные поступают из базы.
• Не продолжает разговор после передачи менеджеру. Когда сделка готова, AI переходит в закрытый режим. Дальше общается человек.
• Не пытается самостоятельно разрешить любой спор. Нестандартные ситуации и чувствительные вопросы передаются сотруднику.

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

Что изменилось для бизнеса

После внедрения процесс обработки заявки стал стандартизированным.

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

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

Что нужно для создания подобной системы

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

1. Формализовать бизнес-процесс

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

2. Определить источники истины

AI не должен самостоятельно придумывать цены, наличие, тарифы, скидки, сроки и коммерческие условия. Для каждого типа данных нужен контролируемый источник.

3. Отделить решения от формулировок

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

4. Хранить формальное состояние

Одной истории переписки недостаточно. Этап сделки и собранные параметры должны храниться отдельно.

5. Спроектировать параллельную обработку

До запуска необходимо решить, как объединять короткие сообщения, как блокировать сделку, как обрабатывать повторные события, как предотвращать двойные ответы и как восстанавливать процесс после ошибки.

6. Подключить CRM как часть процесса

AI должен не только отвечать, но и изменять рабочую систему: заполнять поля, менять этапы, сохранять результаты, передавать ответственность и отключаться после передачи человеку.

7. Начать с контролируемого запуска

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

Итог

Для YETI мы построили специализированную AI-систему продаж для автопроката. Она объединяет WhatsApp, Kommo CRM, базу автомобилей, три AI-агента, компьютерное зрение, очереди сообщений и серверную логику.

Клиент видит обычную переписку в WhatsApp. Но за этой перепиской работает система, которая понимает запрос, управляет этапами бронирования, хранит состояние сделки, получает актуальные автомобили, проверяет документы, заполняет CRM, защищается от параллельных и повторных событий и передаёт готовую заявку менеджеру.

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