Аналог товара в ответе ИИ: что нужно проверить перед заменой

Клиент просит снятую с производства модель, а ИИ находит похожий артикул и предлагает замену. Совпадение названия и мощности не доказывает взаимозаменяемость, и монтаж может остановиться на другом размере.

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

Рассмотрим условный эпизод. клиент просит «ту же самую» модель насоса, но её сняли с производства. ИИ-продавец находит артикул с похожим названием, видит совпадение по мощности и предлагает замену. Клиент соглашается, потому что цена ниже. Через неделю выясняется, что присоединительный размер у замены другой, и монтаж останавливается на объекте. Формально никто не соврал: похожее название действительно похоже.

Механизм этой ошибки не в том, что ИИ плохо ищет. Он в том, что «аналог» — это не свойство товара, а вывод о взаимозаменяемости в конкретном применении. Совпадение по одному параметру не даёт права объявить замену. Нужен согласованный порядок: какие параметры критичны, кто подтверждает совпадение, что видит клиент и где сотрудник останавливает автоматический ответ, пока техническая проверка не закрыта.

Похожее название и взаимозаменяемость — разные утверждения

Каталог хранит атрибуты артикула: мощность, размер, материал, комплектацию. Это описание товара, а не доказательство, что он подойдёт вместо исходного. Взаимозаменяемость появляется только тогда, когда кто-то сопоставил требования конкретного применения с параметрами замены и зафиксировал результат. Каталог сам такого вывода не содержит.

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

Microsoft описывает устройство каталога товаров и связей между позициями в документации по настройке каталога. Оттуда полезно взять саму идею структурированных атрибутов и связей, но не вывод о том, что связанные позиции автоматически равнозначны. Связь в каталоге — это заявленное отношение, которое ещё нужно проверить под задачу клиента.

На странице ИИ-команды «Везория» можно посмотреть опубликованные возможности продукта и формат обсуждения задачи «проверить замену по матрице параметров». Наличие конкретных связей с каталогом, документами производителя и согласованиями выясняют до запуска: описанное здесь — требования к процессу, а не автоматически доступные функции.

Матрица критичных параметров решает, что вообще сравнивать

Без заранее согласованного перечня параметров сравнение превращается в разговор о том, что удобно сравнить. Продавец смотрит на цену, инженер — на присоединительный размер, клиент — на срок поставки. Каждый прав по-своему, и именно поэтому нужен общий список, утверждённый до первого запроса на замену.

Матрица — это не таблица «лучше/хуже». Это перечень вопросов, на которые нужен ответ до предложения замены. Параметр, которого нет в матрице, не становится неважным: он просто не проверен, и это тоже фиксируется.

Рабочий объект проверки замены

Свободная заметка «аналог подходит» не годится: через месяц никто не вспомнит, на каком основании сделан вывод. Нужен отдельный объект или строго определённый набор полей, связанный с исходной позицией и кандидатом.

Ключевое поле здесь — статус. Пока он не «подтверждена», ИИ-продавец не формулирует замену как готовое предложение. Он может сообщить, что подбор идёт, и передать задачу специалисту. Это не бюрократия, а способ не превратить догадку в обещание.

Сцена, где совпало всё, кроме размера

Условный пример. Клиент просит насос с присоединением определённого диаметра для замены вышедшего из строя. ИИ-продавец находит кандидата: мощность совпадает, напор близкий, цена привлекательная. В карточке кандидата присоединительный размер не заполнен — поле пустое, а не отличается. Пустое поле легко прочитать как «не важно» или «наверное, такое же».

Если процесс разрешает предлагать замену при незаполненном критичном параметре, клиент получит уверенное сообщение о совместимости. Если процесс требует заполнения всех критичных полей до статуса «подтверждена», кандидат уходит на проверку. Разница между этими двумя настройками — не косметическая: она определяет, остановится ли ошибка до монтажа или после.

Сцена, где клиент согласился на цену, но не на режим

Другой условный случай. Кандидат дешевле, клиент говорит «берите, разница в цене устраивает». Продавец воспринимает это как согласие на замену целиком. Но клиент согласился на цену, а не подтвердил, что новый режим работы подходит для его задачи. Согласие на коммерческое условие не заменяет техническое согласование.

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

Где ИИ-продавец останавливается и передаёт задачу

голосовой агент в проектных требованиях описан как ИИ-продавец в звонках по согласованному сценарию: он фиксирует интерес и передаёт задачу менеджеру. В контексте замены это означает, что разговор может выявить потребность в аналоге и собрать исходные данные, но вывод о взаимозаменяемости делает не он.

Граница проходит по типу утверждения. «Есть кандидат с такими параметрами» — факт из источника. «Этот кандидат вам подойдёт» — вывод, требующий проверки. Первое ИИ может сообщить, второе — только после закрытого статуса. Если сценарий не различает эти два типа фраз, замена будет предлагаться раньше, чем кто-либо её проверил.

Как выглядит интерфейс проверки для сотрудника

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

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

Согласование изменения предложения

Когда проверка закрыта, изменение позиции в предложении должно проходить через согласование, а не появляться в документе само. Microsoft описывает состояния коммерческих предложений и работу с ними в материале о создании и редактировании предложений. Идея состояний полезна: предложение с заменой — это не тот же документ, что исходное, и переход между ними фиксируется.

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

Согласование как отдельный шаг, а не подпись ради галочки

Запрос на согласование полезен, когда у него есть предмет: что меняется, почему, на каком основании. Microsoft описывает механику принятия и отклонения запросов в документации по согласованиям. Механика даёт статус и историю, но не решает, кто вправе подтверждать техническую совместимость.

Поэтому в проектных требованиях согласование привязывают к группе параметров. Сотрудник, подтверждающий присоединительные размеры, и сотрудник, подтверждающий коммерческие условия, могут быть разными людьми. Один запрос «согласуйте всё» размывает ответственность: непонятно, кто именно проверил критичный параметр.

Трудные исключения: когда матрица не даёт ответа

Не всякий случай закрывается матрицей. Бывает, что параметр критичен, но данных о кандидате нет ни у производителя, ни в каталоге. Тогда честный статус — «требует уточнения», а не «подтверждена по умолчанию». Уточнение может идти к поставщику или к клиенту, но оно должно быть названо, а не спрятано за обтекаемой формулировкой.

Отдельное исключение — совместимость с уже установленным оборудованием на объекте. Матрица описывает товар, но не описывает объект. Здесь нужен ответ клиента или выезд специалиста, и до этого ответа замена остаётся кандидатом. Если процесс этого не различает, он будет уверенно предлагать замену, которая не стыкуется с тем, что уже стоит.

Что проверять в самом процессе, а не в товаре

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

Эти сценарии — не гарантия безошибочности, а способ увидеть, где процесс пропускает догадку вперёд проверки. Их стоит повторять при изменении каталога или сценария разговора.

Практикум: разбор одного запроса на замену

Возьмём условный запрос. Клиент просит фильтр определённого типоразмера, которого нет в наличии. ИИ-продавец находит кандидата с похожим назначением. Дальше — по шагам, которые можно провести вручную, без внедрения.

Сначала выписываем критичные параметры из матрицы для этого типа товара. Затем по каждому параметру открываем источник и ставим один из статусов: совпадает, отличается, нет данных. Параметр «нет данных» не превращаем в «совпадает». После этого смотрим, остались ли отличия, которые клиент должен принять, и формулируем сообщение, где названо именно то, на что он соглашается.

Затем проверяем, кто вправе закрыть проверку по каждому параметру, и меняем статус только этим сотрудником. Если хотя бы один критичный параметр остался без данных, замена не становится предложением. Такой разбор занимает время, но показывает, где именно процесс держится, а где пропускает.

Везория и ИИ-команда: где проходит граница полномочий

Везория в проектных требованиях описана как ИИ-команда для задач бизнеса со знаниями и настроенными инструментами. В контексте замены это означает, что команда может работать с матрицей параметров и источниками, но решение о взаимозаменяемости остаётся за уполномоченным сотрудником. Инструменты дают доступ к данным, а не право объявлять совпадение.

Что остаётся клиенту, а что компании

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

Поэтому в сообщении клиенту полезно разделять: что подтверждено, что отличается и что требует его решения. Такая формулировка не украшает текст, а делает согласие осмысленным. Если клиент видит только итоговую цену, он соглашается на цену, а не на замену.

Один шаг проверки перед запуском

Прежде чем разрешать ИИ-продавцу предлагать аналоги, стоит взять один реальный тип товара и вручную прогнать по нему матрицу критичных параметров на двух-трёх кандидатах. Это покажет, какие поля пустые, где источник не даёт ответа и кто в компании вправе закрыть проверку. Результат такого разбора — не отчёт, а рабочий список параметров и полномочий, на котором дальше строится согласованный процесс замены.

Заполненный протокол сравнения двух условных изделий

Предположим, покупатель назвал исходное изделие, а в каталоге найден кандидат на замену. Для безопасного коммерческого обсуждения недостаточно одной колонки «аналог». Запишите назначение, критичные параметры исходного варианта, источник каждого значения, сведения кандидата и открытые расхождения. Если параметр не найден, пустое место должно остаться вопросом специалисту, а не превратиться в совпадение.

Проверьте протокол на двух людях: продавец должен объяснить покупателю открытый вопрос, специалист — понять, какие исходные сведения ему передали. Если каждый вынужден заново начинать подбор, агент пока подготовил название кандидата, а не полезное сравнение. Итогом может быть и обоснованный отказ от замены. Такая остановка сохраняет смысл продажи лучше, чем уверенная рекомендация без подтверждённой применимости.

Соседний вопрос разобран отдельно: Комплект товаров в разговоре с ИИ: совместимость важнее списка. Здесь основной предмет — сравнение исходного и заменяющего артикула по критичным параметрам и согласованию; не комплект разных компонентов.