Допродажи: уместное дополнение к заказу и правила отказа

Допродажа уместна, когда основной товар уже выбран, дополнение отвечает понятной потребности, а каталог подтверждает совместимость, цену и наличие. Один отказ должен остановить предложение. Если хотя бы одного обязательного подтверждения нет, система ничего не предлагает и не просит ИИ угадать недостающие сведения.

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

Чем допродажа отличается от подбора основного товара

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

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

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

Польза cross-sell возникает не из самого факта дополнительной продажи. Аксессуар должен закрывать потребность, связанную с покупкой: подключить оборудование, обеспечить нужный способ установки или защитить его при перевозке. Фраза «к этому часто берут» не объясняет пользу и не подтверждает совместимость.

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

Какие данные ограничивают предложение

Для каждой связи между товарами нужны не только названия. Минимальная запись содержит:

Microsoft описывает для Dynamics 365 Sales связи related products четырёх типов: accessory, cross-sell, substitute и up-sell. В стандартных приложениях Sales Hub и Sales Professional связь также может быть однонаправленной или двунаправленной. Это официальный пример устройства каталога одной платформы, а не единый стандарт для всех CRM.

Само наличие связи related product не доказывает техническую совместимость конкретных позиций. Её нужно хранить или получать из утверждённого источника данных. Возможность функции в конкретной конфигурации Dynamics 365 также зависит от приложения, лицензии, роли, настроек и прав; статья не подтверждает её доступность в системе читателя.

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

Как задать правила уместной допродажи

Для одного конкретного процесса можно установить такую последовательность:

1. Основной товар уже выбран и сохранён в заказе.
2. Правило находит связанные позиции и проверяет совместимость.
3. Процесс получает актуальные цену и наличие.
4. Правила исключают запрещённые категории и ситуации со стоп-сигналами.
5. Покупателю показывают не более одного допустимого дополнения.
6. После согласия позицию добавляют явно; после отказа заказ оставляют без изменений.

Ограничение «не более одного дополнения» относится к этому учебному процессу. Это не универсальная норма и не обещание определённой конверсии. Для другого магазина лимит определяют по ассортименту, каналу общения и реакции покупателей, а затем фиксируют в требованиях.

Стоп-сигналы должны прерывать сценарий до генерации текста:

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

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

Что поручить ИИ, а что оставить правилам

ИИ можно поручить сформулировать короткое объяснение пользы среди позиций, которые уже прошли проверку. Например, модель превращает структурированные данные «совместимо с E-18; назначение — подключение внешнего блока; цена — 3 500 ₽» в понятную реплику. Она не должна сама объявлять товары совместимыми или восстанавливать неизвестную цену по похожим позициям.

Детерминированные правила и источники данных отвечают за:

• точное совпадение идентификаторов и вариантов товара;
• подтверждённую совместимость;
• актуальные цену и остаток;
• ограничения по категории и условиям применения;
• лимит предложений;
• остановку после отказа.

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

Из сценария следует заранее исключить медицинские товары и любые другие категории, где компания не разрешила автоматическую рекомендацию. Перечень определяет владелец процесса вместе с ответственным специалистом. Языковая модель не должна самостоятельно ослаблять эти ограничения даже при настойчивой просьбе покупателя.

Учебная проверка дополнений к заказу

Ниже — синтетический пример для обсуждения правил. Это не клиентский кейс Switch On AI, не результат живого теста и не выгрузка из реальной CRM.

Исходный заказ: оборудование E-18, 1 штука по цене 12 000 ₽. Исходная сумма: 1 × 12 000 = 12 000 ₽.

Формула отбора для примера:

допустимо = совместимость ∧ остаток > 0 ∧ известна актуальная цена ∧ нет стоп-сигнала

Всем условиям соответствует только B-18. A-12 исключается из-за несовместимости, хотя он есть на складе. C-18 исключается из-за нулевого остатка, хотя совместимость указана. Покупателю нельзя показывать эти две позиции как запасные варианты.

Если покупатель согласится на B-18, расчёт будет таким: 12 000 + 1 × 3 500 = 15 500 ₽. Разница с исходным заказом — 15 500 − 12 000 = 3 500 ₽, или 3 500 / 12 000 × 100% = 29,17%. Это арифметика синтетического примера, а не ожидаемый эффект внедрения.

Диалог с отказом:

Менеджер: К оборудованию E-18 подходит принадлежность B-18. Она нужна для подключения внешнего блока. Цена — 3 500 ₽. Добавить её в заказ или оставить только оборудование?

Покупатель: Нет, оставьте только оборудование.

Менеджер: Хорошо, сохраняю исходный заказ без изменений: E-18, 1 штука, 12 000 ₽.

После отказа менеджер не предлагает A-12 или C-18 и не повторяет вопрос о B-18. Итоговый заказ остаётся прежним: E-18, 1 штука, 12 000 ₽.

Как подготовить менеджеров и предложения услуг

Менеджеру нужна не заученная техника давления, а короткая конструкция: потребность → польза → цена → возможность отказаться. Формулировку меняют под канал, но не скрывают условия.

Офлайн-продажа: «Для перевозки выбранного оборудования подходит этот совместимый кейс. Он стоит 2 000 ₽. Добавить его или оставить только оборудование?» Использовать такую реплику можно лишь при подтверждённом наличии кейса.

Онлайн-заказ: «К выбранной модели подходит кабель для подключения внешнего блока — 1 200 ₽. Добавить в корзину? Если он не нужен, заказ останется без изменений».

B2B-услуга: «Для согласованной услуги может понадобиться отдельная настройка обмена данными. Она нужна, если результат требуется передавать в вашу систему. Стоимость укажем после проверки API и объёма работ; можно оставить исходный состав услуги без этой настройки».

Последняя формулировка не превращает неизвестную цену в обещание. Для B2B сначала проверяют потребность и технические условия, затем отдельно согласуют изменение состава работ.

При разборе учебных диалогов менеджер должен уметь:

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

Корпоративное обучение не входит в описываемую услугу Switch On AI. Команда заказчика сама утверждает правила общения и отвечает за подготовку сотрудников. Автоматизированный помощник должен следовать этим правилам, а не незаметно заменять их собственной тактикой продаж.

Как оценить пилот и подготовить внедрение

Средний чек сам по себе не показывает качество допродажи. Он может вырасти одновременно с возвратами или жалобами. Для пилота сравнивают периоды с одинаковыми каналами, категориями товаров, правилами показа и способом учёта. Если условия различаются, вывод нужно разделить по группам или не делать.

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

Пример расчёта на синтетических данных: допустимое предложение показали 80 раз, приняли 16 раз — 16 / 80 × 100% = 20%. Из 16 проданных дополнений вернули 2 — 2 / 16 × 100% = 12,5%. Жалоба поступила по одному из 80 показов — 1 / 80 × 100% = 1,25%. Эти числа не являются результатами Switch On AI или отраслевыми ориентирами; они лишь показывают разные знаменатели.

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

Switch On AI разрабатывает ИИ-помощников, ботов и интеграции для продаж после проверки данных, API, прав и ограничений конкретных систем. ИИ-помощник может объяснять разрешённое дополнение; чат-бот — вести такой диалог в согласованном канале; обычная интеграция — передавать проверенные поля между системами без генерации реплик. Подходящий вариант зависит от операции.

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

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