🛒 Интернет-магазин «Пентод»

Что это. Демо-сайт вымышленного магазина электроники: главная, «Каталог», «Покупателям» и «Где заказ». Планируемый адрес — /ru/shop на витрине примеров.

Что показывает. Переход от «бот пересказывает статью» к «бот отвечает про конкретную сущность из вашей системы». Сценарий делает HTTP-запрос в собственный API магазина и собирает ответ из заказа, а не из статьи базы знаний. Второй механизм этого демо — AI-классификация: обращение размечается по теме до того, как за него возьмётся человек.

Пока не работает

Проект под это демо в Fixorix ещё не заведён, идентификатор виджета пуст — кружка чата на сайте нет, и Telegram-бот к демо не подключён. Ниже описано, что должно быть настроено; см. Что нужно, чтобы демо заработали.

Что настроено в Fixorix

Что	Значение
Каналы	«Виджет» и Telegram
База знаний	13 статей: доставка, оплата, гарантия, возврат, каталог
Сценарий	Ответ по базе знаний плюс блок «HTTP запрос» к API заказов
AI	Классификация обращения по теме
Модуль «Тикеты»	Не используется в этом примере

Блок «HTTP запрос» ходит по адресу вида /api/orders/{id}, где id — номер заказа, который клиент назвал в переписке. Ответ уже готов к показу: он плоский и на русском, статусы приходят готовыми подписями, а не кодами. Неизвестный номер возвращает 404 и found: false, чтобы сценарий ветвился по коду ответа, не разбирая тело.

Что приходит в ответе	Что с этим делает сценарий
Подпись статуса и пояснение, что он означает	Отдаёт клиенту как есть — переписывать статус в сценарии не нужно
Состав заказа, сумма товаров, доставка, итог	Показывает, чтобы клиент опознал свой заказ
Способ доставки, интервал, пункт выдачи, срок хранения	Отвечает на вопрос «когда и куда приедет»
Признак финального статуса	Решает, предлагать ли дальнейшие шаги

У этого API нет авторизации, и это сознательно

Все заказы вымышлены, поэтому эндпоинт открыт. Для настоящего магазина так делать нельзя: в реальном проекте API заказов должен требовать ключ, а сценарий — передавать его заголовком.

Ограничения блока. Ответ — не больше 1 МиБ, не больше 100 HTTP-вызовов на один запуск сценария. Запросы к приватным адресам и служебным хостам блокируются, поэтому API демо должен быть доступен по публичному адресу.

Что попробовать

1. Откройте страницу «Где заказ», введите в поле «Номер заказа» значение 1042 и нажмите «Найти».
2. Не закрывая страницу, спросите в чате: «Где мой заказ 1042?»
3. Сравните: сценарий сходит в тот же API и ответит теми же полями, что показаны на экране, — статус «Передан курьеру» и интервал доставки.

Вопрос в чат	Какой ответ ждать
«Где мой заказ 1042?»	Статус, состав, сумма и интервал доставки — собранные из заказа, а не из статьи
«Заказ 9999, где он?»	Заказа нет: API отвечает 404, сценарий уходит в ветку «не нашли»
«До скольких нужно оформить, чтобы уехало сегодня?»	Ответ по базе знаний: отсечка — до 14:00 по московскому времени
«Сколько заказ лежит в пункте выдачи?»	5 дней — это статья базы знаний, а срок по конкретному заказу приходит из API строкой «Хранится ещё N дней»

Страница «Где заказ» говорит об этом прямо: ответ собирается из заказа, а не из статьи в базе знаний.

📷 Скриншот: страница «Где заказ» с найденным заказом 1042 (будет добавлен).

Берите заказ 1042, а не 1044

Известное расхождение: API и страница по-разному считают просрочку. Заказ 1044 («Ждёт в пункте выдачи», приехал вчера, хранится ещё четыре дня) на странице показан правильно, а API про него отвечает «просрочен на 1 день». Если сценарий процитирует API, бот начнёт противоречить странице — ровно тот провал, ради опровержения которого построен стенд. До показа расхождение нужно починить, а показывать — заказ 1042.

Что есть на сайте

Каталог. Телефоны, ноутбуки и мониторы, звук — с характеристиками, ценой, наличием и сроком гарантии (12, 24 или 36 месяцев). Отдельным блоком — «Как выбрать».

«Покупателям». Доставка с тарифами, бесплатная доставка от 15 000 ₽ и от 20 000 ₽ по разным тарифам, отсечка «до 14:00 по московскому времени», пункты выдачи и хранение 5 дней. Дальше — оплата, гарантия, возврат, блок «Чего мы не делаем» и частые вопросы.

«Где заказ». Восемь демонстрационных номеров — с 1041 по 1048, каждый в своём статусе: «Принят», «Собирается», «Передан курьеру», «Ждёт в пункте выдачи», «Доставлен», «Возврат оформлен», «Отменён».

Как это устроено

Каталог, тарифы доставки и правила возврата лежат в одном объекте данных. Из него рендерится сайт и генерируются 13 статей базы знаний — поэтому условия в чате совпадают со страницей «Покупателям».

А вот заказы в базу знаний намеренно не попадают: они отдаются по HTTP в момент вопроса. Загрузи их в базу знаний — и поиск возвращал бы вчерашний замороженный статус, а клиенту нужен сегодняшний.

Правило простое: правила — в базу знаний, состояния — по HTTP.

Ограничения

• Заказ через чат не оформляется и не отменяется: сценарий только читает состояние заказа.
• Восемь демонстрационных номеров зафиксированы в данных. Любой другой номер вернёт «не нашли» — это не ошибка, а поведение демо.
• API демо открыт без ключа. Повторять эту схему в реальном проекте нельзя.
• Блоки работы с тикетами в сценариях не исполняются, поэтому обращение из чата не превращается в тикет автоматически.
• Пока проект не заведён, чата на сайте нет и вопросы задать негде.

→ Примеры · Блоки сценариев · AI-классификация · Telegram · База знаний