Проблема и что мы сделали
В интернет-магазине каталог, поиск и поддержка часто существуют отдельно: товары правят в учёте, на сайте — другой язык характеристик, в чате оператор не уверен в остатке.
Мы разработали единый AI-контур, синхронизированный с 1С и «МойСклад». Система генерирует и обновляет карточки товаров, приводит характеристики к единому формату, даёт семантический поиск по каталогу и помогает покупателю подобрать товар. Ассистент видит актуальные цены и остатки, консультирует клиента и передаёт заказ в CRM.
Три задачи, которые нельзя решать порознь
Магазин живёт на связке витрины и учёта. Номенклатура и остатки — в 1С и «МойСклад». На сайте нужны понятные карточки и поиск, который находит не только по точному названию. В поддержке покупатель спрашивает «что подойдёт» и «есть ли в наличии» — и ждёт ответ без сюрпризов на кассе.
Пока эти куски разведены, появляется классический разрыв. В учёте товар есть, на карточке характеристики кривые. Поиск не понимает запрос своими словами. Ассистент или оператор отвечает устаревшей ценой. Заказ из переписки потом вручную догоняют в CRM.
Нужен был один контур: каталог, поиск и поддержка на общих данных из 1С и «МойСклад» — а не отдельный чат-бот «поверх» сайта.
Слой 1. Каталог, который сам держит форму
Синхронизация с 1С и «МойСклад». Контур завязан на учётные системы: оттуда берутся номенклатура, цены, остатки и изменения. Каталог на витрине не живёт своей параллельной жизнью — он следует за учётом.
Генерация и обновление карточек товаров. ИИ создаёт и актуализирует карточки: описания и структура данных не зависят от того, успел ли контент-менеджер «дописать вручную» после каждой поставки. Когда в учёте появляется или меняется позиция, карточный слой может догнать изменение в том же контуре.
Единый формат характеристик. Разные поставки и разные привычки заведения номенклатуры дают зоопарк свойств. Система приводит характеристики к единому формату — чтобы фильтры, сравнение и поиск опирались на одинаковые поля, а не на «где-то цвет, где-то расцветка, где-то пусто».
Без этого слоя умный поиск и ассистент быстро начинают галлюцинировать ассортимент: красиво отвечают про товар, которого в таком виде на витрине нет.
Слой 2. Семантический поиск по каталогу
Покупатель редко ищет так, как заведена номенклатура в 1С. Он пишет задачу, признак, «как у того, что смотрел», бытовой язык.
Мы реализовали семантический поиск по каталогу: система понимает смысл запроса и ищет по содержанию карточек и характеристикам, а не только по точному совпадению названия. Поиск сидит на том же каталоге, который синхронизирован с учётом и приведён к единому формату свойств — иначе «умный» поиск тащит мусор из кривых карточек.
Слой 3. Ассистент, который продаёт из живых данных
Подбор товара. Ассистент помогает покупателю выбрать: уточняет задачу, опирается на каталог и выдаёт релевантные позиции, а не общий текст «посмотрите раздел».
Актуальные цены и остатки. В диалоге ассистент видит данные из контура, связанного с 1С и «МойСклад». Консультация не расходится с витриной и складом: клиенту не обещают то, чего нет, и не называют вчерашнюю цену.
Передача заказа в CRM. Когда покупатель готов, заказ уходит в CRM из того же сценария поддержки. Не «напишите менеджеру на почту» и не ручной перенос переписки в сделку — диалог заканчивается объектом в CRM.
Так поддержка перестаёт быть оторванным чатом и становится третьим лицом того же контура, что каталог и поиск.
Как это выглядит для покупателя
Человек приходит с запросом своими словами. Семантический поиск или ассистент находит позиции из актуального каталога. В карточке — нормализованные характеристики. В ответе ассистента — живые цена и остаток. Решение купить не обрывается: заказ оказывается в CRM, а не только в истории чата.
Снаружи это «удобный магазин». Внутри — одна синхронизация с учётом и три слоя логики на одних данных.
Где держим границы
Каталог без дисциплины характеристик превращает семантический поиск в лотерею. Поэтому нормализация свойств — не косметика, а условие для поиска и подбора.
Ассистент не должен «договаривать» наличие. Цены и остатки берутся из контура 1С / «МойСклад»; если данных нет или позиция не в продаже — это должно быть видно в ответе, а не маскироваться уверенным текстом.
Заказ в CRM — финал консультации, а не отдельный ритуал. Иначе снова появляется разрыв: поговорили в одном месте, продажу завели в другом и потеряли контекст.
| Было | Стало |
| Каталог, поиск и поддержка жили отдельно | Единый AI-контур на общих данных |
| Карточки и характеристики отставали от учёта | Генерация/обновление карточек и единый формат свойств из контура 1С и «МойСклад» |
| Поиск требовал «правильного» названия | Семантический поиск по каталогу |
| В чате цена и остаток могли врать | Ассистент видит актуальные цены и остатки |
| Заказ из диалога догоняли руками | Заказ передаётся в CRM |
Что вышло в результате
Интернет-магазин получил единый AI-контур, в котором связаны каталог, умный поиск и поддержка. Система синхронизирована с 1С и «МойСклад»: обновляет карточки, нормализует характеристики, ищет по смыслу, помогает подобрать товар по живым цене и остатку и передаёт заказ в CRM.
Покупателю не нужно переводить свой язык на язык номенклатуры и перепроверять ответ поддержки по витрине. Команде магазина не нужно склеивать три инструмента вручную — правда об ассортименте и продаже собирается в одном контуре.