Небольшой магазин без отдела продаж: владелец сам отвечал на вопросы о составе, стойкости и наличии. Вечерние и ночные сообщения — а их было больше половины — обрабатывались только на следующий день.
Кейсы описывают реальные разработанные решения. Названия компаний, диалоги и данные в примерах — демонстрационные: они показывают логику работы системы, но не раскрывают клиентов. Все показатели — расчётные модели с указанными допущениями, а не подтверждённая отчётность.
Исходная ситуация
Магазин продаёт наборы нишевой парфюмерии из разных стран. Ассортимент небольшой, но требующий объяснений: клиенту важно понять разницу между семействами ароматов, стойкость, для какого сезона и повода подходит набор, есть ли позиция в наличии. Продажи шли через сайт и Telegram, отвечал сам владелец — в свободное от остальных дел время.
Мне не нужен бот, который отвечает «спасибо за обращение». Нужен продавец: чтобы он реально помог человеку выбрать, говорил нормальным языком и не выдумывал, чего у меня нет. И чтобы ночью тоже работал — половина заказов приходит после полуночи.
Анализ
Разбор начинается не с технологий, а с того, где процесс теряет время, деньги или клиентов.
Цель
Получить помощника, который ведёт живой диалог о выборе аромата, отвечает строго по документам магазина, фиксирует каждое обращение и доводит заинтересованного человека до оформленной заявки — независимо от времени суток.
Рамки проекта
Эти ограничения определили архитектуру сильнее, чем выбор конкретных сервисов.
Решение
Агент уточняет повод, предпочтения по семейству аромата и бюджет, а затем предлагает конкретные наборы с объяснением, почему они подходят.
Ассортимент, описания и правила магазина ведутся в Google Docs — владелец правит документ, и агент сразу отвечает по актуальной версии.
Перед ответом система ищет клиента в Airtable. Если человек уже писал, разговор продолжается с учётом прошлых предпочтений.
Каждое обращение попадает в таблицу Airtable: контакт, тема, что интересовало, статус. Отдельная CRM для такого объёма не нужна.
Когда клиент определился, агент фиксирует заявку с составом набора и контактом — владельцу остаётся согласовать оплату и доставку.
История переписки хранится в PostgreSQL, поэтому агент не переспрашивает то, что клиент уже сказал десять сообщений назад.
Пользовательский сценарий
Вопрос о подборе, наличии или условиях доставки приходит в Telegram — в том числе ночью, когда владелец не на связи.
Не более одного-двух вопросов за сообщение: для кого подарок, что ближе по характеру аромата, какой бюджет — без превращения диалога в анкету.
Варианты, цены и наличие берутся из базы знаний, а не из общих представлений модели об ассортименте.
Стойкость, состав, наличие более доступных вариантов — ответ снова опирается на документ, а не на догадку.
Когда решение принято, агент запрашивает контакт и оформляет заявку с составом заказа.
Тема и итог обращения попадают в Airtable; способы оплаты и доставку владелец согласовывает сам.
Пошаговая логика
Шаги, помеченные как действие человека, автоматизации не подлежат сознательно.
Telegram-бот принимает входящее и определяет тип: текст, голос или неподдерживаемый формат.
Команда /start отрабатывает отдельной веткой: клиент получает короткое приветствие и понимает, чем помощник может быть полезен.
Голосовое скачивается и расшифровывается, после чего объединяется с текстовым потоком в единый запрос.
Агент проверяет карточку в Airtable: новый это человек или уже писал раньше.
Вопросы об ассортименте, наличии, доставке и возврате обрабатываются через документ магазина. Ответ строится только по найденному.
Агент уточняет повод, предпочтения и бюджет, а затем предлагает конкретные позиции с объяснением выбора.
Тема разговора и итог записываются в таблицу: видно, о чём спрашивают чаще всего.
Новый клиент заводится, существующий обновляется. Дубли исключены проверкой перед записью.
При готовности клиента формируется заявка с составом заказа и контактом.
Оплата, доставка и любые нестандартные договорённости остаются за человеком.
Архитектура
# правило, которое закрывает главный риск такого бота
Ты отвечаешь только по документам магазина.
Перед ответом о наличии, составе, стойкости, цене,
доставке или возврате — обратись к базе знаний.
Запрещено:
— брать факты из общих знаний модели;
— считать историю диалога источником фактов о товаре;
— придумывать позиции, объёмы, скидки и сроки.
Если подтверждения нет:
«Такой позиции сейчас нет. Могу показать
близкие варианты или уточнить у владельца.»Не абстракция
Точная визуализация по фактически экспортированному файлу n8n: настоящие имена узлов, связи и расположение — не иллюстрация, а слепок рабочей системы.
Технологии
Все компоненты — управляемые сервисы и открытые API. Решение разворачивается на инфраструктуре заказчика, ключи доступа остаются у него, а любую часть можно заменить без переписывания всей системы.
Границы автоматизации
Осознанно оставленные ручные шаги — не недоработка, а часть проекта. Они защищают репутацию бизнеса.
Надёжность
Автоматизация ломается на исключениях, поэтому они продуманы до запуска, а не после первой жалобы.
| Ситуация | Как обрабатывается |
|---|---|
| <b>Позиции нет в базе знаний</b> | Агент прямо сообщает об этом и предлагает близкие варианты из наличия вместо выдуманного ответа. |
| <b>Голосовое не распознано</b> | Клиент получает просьбу продублировать текстом, обращение остаётся в работе. |
| <b>Прислан файл или стикер</b> | Отдельная ветка с понятным сообщением о поддерживаемых форматах. |
| <b>Клиент уже есть в Airtable</b> | Обновляется существующая карточка, дубль не создаётся. |
| <b>Вопрос вне компетенции агента</b> | Обращение помечается как требующее владельца и попадает в таблицу с соответствующим статусом. |
Безопасность
Реализация
Какие вопросы задают чаще всего, что нужно знать для подбора, где заканчивается зона ответственности бота.
Приведение описаний, правил доставки и возврата к формату, пригодному для точного поиска.
Самая долгая часть: агент должен звучать как человек, а не как справочник. Проверка на контрольных диалогах.
Структура таблиц, поиск клиента, защита от дублей, фиксация обращений и заявок.
Работа на реальных обращениях, правка формулировок, разбор случаев, где агент ушёл в сторону.
Полный цикл — 2–3 недели при своевременных ответах со стороны заказчика и готовых материалах. Этапы идут частично параллельно.
Эффект
Ниже — модельные диапазоны, полученные из описанных допущений. Это не отчётность заказчика: реальные значения зависят от потока обращений, качества исходных данных и дисциплины команды.
Развитие
Система собрана модульно, поэтому каждый пункт добавляется без переработки существующей логики.
Разберу процесс и честно скажу, что здесь стоит автоматизировать, а что лучше оставить человеку. Разбор задачи — бесплатный и ни к чему не обязывает.