Сотни SKU, ответ 24/7: AI-продавец на Авито и в Telegram для производителя промышленного холода

У производителя сотни SKU: характеристики, совместимость, прайсы, монтаж и сопутствующие услуги. Первый контакт почти всегда случается на Авито, а содержательный разговор продолжается в Telegram.

Что мешало продажам:

- инженеры-продавцы тратили 5-15 минут на подбор модели по каждому типовому запросу;

- после перехода с Авито в Telegram клиент заново объяснял задачу;

- обращения вечером и в выходные лежали без ответа до утра, лид остывал;

- follow-up через 3, 7 и 14 дней после КП зависел от памяти менеджера;

- знания о линейке были в головах сотрудников и уходили вместе с ними.

Главное ограничение: ассистент не имеет права «придумать» характеристику, цену или срок. Такой ответ либо привязан к документу, либо вопрос уходит человеку.

1. Приём сообщений без потерь и дублей. Авито и Telegram присылают события через webhooks и ждут быстрого ответа, иначе повторяют доставку. Эндпоинт на FastAPI проверяет подпись, сохраняет сырое событие в PostgreSQL и сразу отвечает 200 OK, а обработка идёт воркером из очереди в Redis. Уникальный ключ (channel, event_id) гарантирует, что повторная доставка не даст второго ответа клиенту. Сообщения одного диалога обрабатываются строго по очереди под блокировкой, короткие реплики подряд склеиваются в один ход (ожидание 20 секунд). Разные диалоги идут параллельно, медленный ответ модели одному клиенту не тормозит остальных.

2. Общая память Авито и Telegram. Агент на Авито быстро отвечает и берёт телефон, после этого диалог переходит в Telegram. Профили склеиваются только по подтверждённому контакту: ошибочная склейка хуже двух отдельных профилей. В памяти хранятся последние сообщения, сжатое резюме диалога и структурированные факты (оборудование, объём, бюджет, срок, этап воронки). Telegram-агент не задаёт вопросов, на которые клиент уже ответил на Авито.

3. База знаний по каталогу. Таблицы характеристик и прайсы режутся построчно: одна строка - одна позиция, заголовки столбцов повторяются в каждом фрагменте, чтобы число не отрывалось от параметра. Описания и условия поставки режутся по разделам. У каждого фрагмента есть SKU, категория, тип документа (характеристики, прайс, инструкция, условия), версия и дата. Векторы лежат в PostgreSQL (pgvector): для каталога такого объёма отдельная векторная БД не нужна, а фильтры и поиск выполняются одним запросом.

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

5. Синхронизация с Google Drive каждые 15 минут. Планировщик забирает изменения по курсору, сравнивает хеш содержимого и переиндексирует изменившийся документ в одной транзакции: в индексе не бывает половины старой и половины новой версии. Удалённые файлы удаляются из индекса, снятая позиция не продаётся. Если документ не распарсился, остаётся прежняя версия и приходит алерт. Поменяли прайс - через четверть часа ассистент отвечает по новому.

6. Роутер и сценарий продаж. Первым шагом быстрая модель определяет намерение: подбор, характеристика, цена и наличие, срок, возражение, КП, просьба позвать менеджера. «Спасибо, подумаю» не запускает поиск по каталогу, «позовите менеджера» сразу передаёт диалог человеку. Дальше работает сценарий с явными состояниями: первичный контакт, выяснение потребности, подбор, возражения, квалифицирован, передача менеджеру, дожим, закрыт. Модель предлагает переход, код проверяет его по таблице допустимых. Дожим идёт только с 10 до 18 по Москве.

7. Проверка ответа и защита. Модель возвращает JSON по строгой схеме: ответ клиенту, новые поля квалификации, id использованных источников, следующий шаг, нужна ли передача человеку. Если в ответе есть цена или число, а источников нет, ответ блокируется. Сообщения клиента идут в модель как данные, а не как инструкции; скидки, нестандартные сроки и КП модель выполнить не может, только передать менеджеру. Менеджер забирает диалог командой /connect и возвращает командой /disconnect, параллельных ответов клиенту не бывает.

8. Оценка качества и мониторинг. Набор реальных диалогов с разметкой (правильный фрагмент каталога, ожидаемое действие) прогоняется перед каждым изменением промпта, модели или нарезки. Считаем точность роутера, полноту поиска, долю ответов без источника, правильность передачи менеджеру. В Grafana: латентность по этапам, доля передач человеку, ошибки интеграций, отставание синхронизации, стоимость вызовов модели на диалог.

• Обращения обрабатываются 24/7, включая ночь и выходные.

• Два канала, одна память: клиент не повторяет задачу при переходе с Авито в Telegram.

• База по сотням моделей обновляется из Google Drive каждые 15 минут, без разработчика.

• Подбор модели по запросу: мгновенно вместо 5-15 минут менеджера.

• Менеджер получает квалифицированный лид с собранными требованиями и сделку в нужной стадии CRM.

• Дожим через 3, 7 и 14 дней идёт по расписанию, а не по памяти менеджера.

Частые вопросы

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

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

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