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

Каталог, цены, заявки и путь клиента к заказу

1. Назначение

Сервис строится как единый AI layer между пользователем и тремя системами Newton.by:

  • каталогом товаров в Bitrix / Percona MySQL;
  • ценовым слоем QuadCRM API;
  • back office в МойСклад JSON API.

Он не заменяет эти системы и не пытается стать новой ERP или CRM. Задачи слоя:

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

2. Бизнес-задача

Первичный бизнес-результат здесь не автоматизация заявки сама по себе, а рост продаж за счет более сильной консультации. Клиент получает понятную информацию по ассортименту, может сравнить варианты, увереннее выбрать товар и перейти к заказу именно в Newton.by.

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

Текущая ситуация выглядит так:

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

Сервис закрывает этот разрыв единым слоем оркестрации.

3. Клиентский путь

Клиентская логика состоит из четырех этапов:

  1. Пользователь пишет в диалоговом окне на сайте, мессенджер или соцсеть.
  2. Сервис определяет intent, подбирает релевантные товары и помогает сравнить альтернативы.
  3. После определения товара сервис получает актуальную цену из QuadCRM.
  4. Если пользователь готов перейти к покупке или другому действию, сервис создает заказную заявку в МойСклад или делает handoff.

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

4. Карта взаимодействий

flowchart LR
    U[Покупатель] --> W[Сайт, мессенджеры, соцсети]
    W --> G[Channel Gateway]
    G --> A[Agent Service]
    A --> O[Оркестратор агента]
    O --> LLM[LLM / reasoning layer]
    O --> R[Product Retrieval]
    O --> P[Price Adapter]
    O --> B[Back Office Adapter]
    O --> H[Operator Handoff]
    O --> LOG[Логи и аналитика]

    subgraph Catalog["Каталог"]
        M[(Percona MySQL / Bitrix)]
        ETL[Sync / Embedding Pipeline]
        V[(Vector Index)]
        META[(Metadata Index)]
        M --> ETL --> V
        ETL --> META
    end

    subgraph Pricing["Цены"]
        QAPI[QuadCRM API]
        PG[(QuadCRM PostgreSQL)]
        QAPI --- PG
    end

    subgraph Backoffice["Заявки"]
        MSAPI[МойСклад JSON API]
        MS[(МойСклад cloud)]
        MSAPI --> MS
    end

    R --> V
    R --> META
    P --> QAPI
    B --> MSAPI

    style Catalog fill:#f7faf4,stroke:#58af23,stroke-width:1.5px,color:#2d3130
    style Pricing fill:#fbf4fb,stroke:#7e1c7e,stroke-width:1.5px,color:#2d3130
    style Backoffice fill:#f8f8f8,stroke:#94979a,stroke-width:1.5px,color:#2d3130
Рисунок 1: Единый AI-слой поверх каталога, цен и заявок

Логика взаимодействия по системам жестко разделена:

  • Bitrix / Percona MySQL отвечает только за каталог;
  • Qdrant отвечает за семантический поиск по каталогу;
  • QuadCRM API отвечает за цену, акции и связанные ценовые данные;
  • МойСклад JSON API отвечает за заявки и операторские действия;
  • внутреннее состояние сервиса живет отдельно и не подменяет основные системы компании.

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

5. Основные сценарии

5.1 Консультация и подбор

sequenceDiagram
    participant User as Клиент
    participant Channel as Сайт / мессенджер / соцсеть
    participant Agent as AI-агент
    participant Retrieval as Product Retrieval
    participant Vector as Vector Index
    participant Meta as Metadata Index
    participant Price as Price Adapter
    participant QuadAPI as QuadCRM API
    participant QuadDB as QuadCRM PostgreSQL

    User->>Channel: Хочу тихую стиральную машину до 1800 BYN
    Channel->>Agent: Сообщение пользователя
    Agent->>Retrieval: semantic_search(запрос, фильтры)
    Retrieval->>Vector: поиск похожих товаров
    Retrieval->>Meta: получить карточки и атрибуты
    Vector-->>Retrieval: список product_id
    Meta-->>Retrieval: описания, характеристики, ссылки
    Retrieval-->>Agent: shortlist товаров
    Agent->>Price: get_price(product_ids)
    Price->>QuadAPI: запрос актуальных цен
    QuadAPI->>QuadDB: чтение цен / акций / остатков
    QuadDB-->>QuadAPI: актуальные данные
    QuadAPI-->>Price: цены / акции / статус
    Price-->>Agent: актуальные цены
    Agent-->>Channel: рекомендации + сравнение + цена
Рисунок 2: Консультация: от запроса пользователя до shortlist и цены

Логика консультации:

  1. Пользователь формулирует потребность.
  2. agent-service принимает сообщение через Channel Gateway и передает его в Orchestrator.
  3. Orchestrator запускает retrieval по каталогу.
  4. Retrieval ищет товары в Qdrant и добирает metadata по карточкам.
  5. При необходимости агент задает уточняющие вопросы.
  6. После определения товара сервис обращается к QuadCRM API.
  7. Пользователь получает ответ, опирающийся на данные каталога, с товаром, сравнением вариантов, аргументацией и актуальной ценой.

5.2 Заявка или handoff

sequenceDiagram
    participant User as Клиент
    participant Agent as AI-агент
    participant BO as Back Office Adapter
    participant MSAPI as МойСклад JSON API
    participant MS as МойСклад cloud
    participant Op as Оператор

    User->>Agent: Хочу оформить заказ / возврат / консультацию
    Agent->>Agent: собирает контакты и согласие
    Agent->>Agent: формирует summary диалога
    Agent->>BO: create_case(type, user, product, summary)
    BO->>MSAPI: создать заявку
    MSAPI->>MS: создать сущность
    MS-->>MSAPI: entity_id / status
    MSAPI-->>BO: case_id / status
    BO-->>Agent: номер заявки
    Agent-->>User: подтверждение и следующий шаг
    MS-->>Op: задача для сотрудника
Рисунок 3: Переход от консультации к заявке или handoff

Транзакционная часть запускается только после подтверждения пользователя:

  1. Агент собирает обязательные поля.
  2. Формирует краткое резюме диалога.
  3. Создает заявку через МойСклад JSON API.
  4. Возвращает пользователю подтверждение и номер заявки.
  5. При низкой уверенности или явном запросе на человека запускается handoff.

6. Принципы работы сервиса

Ключевые правила:

  1. Основная задача консультации помочь клиенту выбрать, заказать и купить подходящий товар в Newton.by.
  2. Цена не придумывается и не становится долгоживущей истиной внутри сервиса.
  3. Заявка не создается без явного согласия пользователя.
  4. Персональные данные собираются только в минимально нужном объеме.
  5. При низкой уверенности запускается handoff, а не неподтвержденный ответ.
  6. Каталог, цены и заявки остаются в системах-источниках.

Практическая модель поведения:

  • при широком запросе сервис предлагает shortlist и уточнения;
  • при ценовом запросе сначала определяется товар, потом вызывается QuadCRM API;
  • при заказе или возврате сначала собираются обязательные поля, потом идет запись в МойСклад;
  • при неопределенности или недоступности внешних систем сервис эскалирует сценарий, а не симулирует успешное действие.

7. Порядок внедрения

flowchart LR
    A[Этап 0.<br/>Discovery и доступы] --> B[Этап 1.<br/>Каталог и векторный поиск]
    B --> C[Этап 2.<br/>Интеграция цен через QuadCRM]
    C --> D[Этап 3.<br/>Заявки в МойСклад]
    D --> E[Этап 4.<br/>Пилот на живом трафике]
    E --> F[Этап 5.<br/>Оптимизация и масштабирование]
Рисунок 4: Последовательность запуска проекта

Этапы запуска:

  1. Discovery: доступы, методы API, ID mapping, обязательные поля.
  2. Catalog MVP: extraction, embeddings, retrieval, консультация по каталогу.
  3. Pricing: подключение QuadCRM API.
  4. Requests: запись заявок в МойСклад.
  5. Pilot: живой ограниченный трафик, наблюдаемость, корректировки.
  6. Optimization: расширение каналов, tuning, масштабирование.

8. Итоговая модель

Сервис является не просто чат-интерфейсом, а рабочей сервисной прослойкой между клиентом и инфраструктурой Newton.by:

  • рост продаж за счет более сильной консультации, сравнения, осознанного выбора и перехода к заказу;
  • один вход для клиента;
  • один слой оркестрации для диалога;
  • собственный слой поиска поверх каталога;
  • актуальная цена из QuadCRM;
  • заявка и handoff через МойСклад;
  • прозрачный audit trail и контролируемый rollout.

9. Что смотреть дальше

Детали реализации вынесены в отдельные материалы: