Продажи через чат-бота

Если в группе есть товары и хотя бы один из них видим боту, бот автоматически получает commerce-tools — никакой настройки на стороне бота не требуется. Тот же бот при наличии услуг получает booking-tools, оба набора работают вместе.

LLM-tools

search_products

Поиск по каталогу с фильтрами.

search_products({
  query?: string,
  categorySlug?: string,
  tags?: string[],         // AND-match
  priceMin?: number,       // ₽
  priceMax?: number,       // ₽
  inStock?: boolean,
  sortBy?: 'relevance' | 'price_asc' | 'price_desc' | 'newest',
  limit?: number           // default 20, max 50
})

Поиск идёт по pg_trgm (тот же индекс, что в UI). Видны только товары, доступные этому конкретному боту в его группе (product_agent_visibility).

В ответе бот получает:

• Оптовые тиры цен (priceTiers) — бот понимает, что минимальный заказ 5 шт или что от 20 шт дешевле.
• Ограничения количества (minQuantity, maxQuantity, quantityStep).
• Метку ПО ЗАЯВКЕ для inquiry-товаров — бот знает, что оплату выставлять не нужно.

create_order

Создание заказа прямо из чата.

create_order({
  items: [{ productId: string, variantId?: string, quantity: number }],
  customerEmail?: string,
  customerPhone?: string,
  customerName?: string,
  notes?: string
})

Если в истории сессии уже есть email клиента, бот берёт его из истории — не обязательно спрашивать заново. Оплата создаётся автоматически. Заказ привязывается к группе, боту, сессии и лиду CRM (если есть).

Сервер при создании применяет оптовые тиры и скидки от суммы — клиентским данным не доверяет.

get_order

Самообслуживание «где мой заказ»:

get_order()  // без параметров

Возвращает заказы, оформленные в этой же переписке (по sessionId): статус, позиции, сумма, ссылка на оплату для pending_payment. Чужие заказы недоступны — без поиска по email. Тумблер orderLookupEnabled, по умолчанию включён.

Режим продавца

Тумблер salesPushEnabled (вкладка «Продажи» в настройках бота). По умолчанию включён.

Включён: бот проактивно ведёт клиента к покупке — отрабатывает возражения, предлагает конкретный следующий шаг, один чёткий CTA. Без выдуманных скидок и «осталось 2 штуки» — только реальные данные из каталога.

Выключен: бот работает в справочном режиме — отвечает на вопросы, не дожимает к заказу. Подходит для поддержки или информационных ботов.

Маркеры в ответах

Бот вставляет маркеры в текст ответа — сервер парсит их и заменяет на UI-компоненты:

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

Товары «по заявке» в чате

Если salesMode='inquiry', бот ведёт другой флоу — не создаёт заказ и не выставляет ссылку на оплату:

1. Бот сообщает клиенту цену с учётом выбранного количества и оптовых тиров.
2. Собирает контакты (имя, телефон или email, пожелания).
3. Информирует, что менеджер свяжется для уточнения деталей.
4. На стороне сервера лид с полным снапшотом (товар, количество, сумма) попадает в CRM.

Попытка создать заказ через create_order для inquiry-товара вернёт ошибку inquiry_only — бот получает человекочитаемое пояснение.

Защита от вранья (phantom-claim guard)

LLM иногда «убеждена», что вызвала инструмент, хотя на деле нет. Например, написала «Готово, оплачивайте!», но create_order не вызывала. Это вранье клиенту.

Framix решает в два шага:

1. Phantom-claim guard. Если в ответе есть фраза вида «заказ оформлен / готов к оплате», а в сессии не было успешного create_order или маркера [[pay:...]] — сервер подменяет ответ на стандартный текст-извинение.
2. Auto-recover. Если бот поставил [[pay:<orderId>]], но забыл вызвать create_order — сервер пытается восстановить вызов сам (распарсить намерение из истории + дёрнуть create_order с нужными параметрами). Если получилось — клиент не замечает.

Где в кабинете настраивается

/agents/[id] → блок «Продажи»:

• Какой merchant_account обслуживает оплаты в чате этого бота.
• Тумблер «Режим продавца» (salesPushEnabled).
• Тумблер «Показывать мои заказы» (orderLookupEnabled).
• Дополнительные подсказки в системный промпт.

Видимость товаров управляется через product_agent_visibility в карточке товара.

Как это выглядит в чате

Клиент: есть лёгкие куртки на весну до 8 тыс?

Бот: Нашёл три варианта в вашем бюджете: [[products:p1,p2,p3]]

(UI рисует карусель из 3 карточек)

Клиент: второй, размер M

Бот: Хорошо, оформляю. На какой email прислать подтверждение?

Клиент: kolya@example.com

Бот: Заказ оформлен на 5 990 ₽. Оплатите по кнопке ниже: [[pay:ord_abc123]]

Под сообщением — кнопка « Оплатить». Клиент жмёт, открывается embedded-чекаут YooKassa прямо в чат-виджете или в /checkout/[token].

После оплаты — webhook, заказ → paid, бот в той же сессии отправляет благодарность и [[my-orders]].

В Telegram/VK

• Карусель [[products:...]] → нумерованная inline-клавиатура (Telegram не умеет горизонтальный скролл).
• Кнопка [[pay:...]] → обычная ссылка (embedded в Telegram невозможно).
• Маркер [[my-orders]] → ссылка на /my с одноразовым кодом.

Биллинг

Расход токенов любого LLM-вызова (включая вызовы commerce-tools) → ai_token_usage → списывается с баланса owner'а, как обычные диалоги. Процент за сами заказы платформа не берёт (см. Касса и платежи).

Связанные разделы

• Создание бота
• Товары и каталог
• Мерчанты и платежи
• Чекаут
• Единый клиент группы