Персональные цены для дилеров в B2B-портале: как настроить гибкое ценообразование

Как усложняются условия при росте дилерской сети:

Уровень условий	Как задаётся в учётной системе	Как отражается в портале
Сегмент дилера	Вид цены или ценовая группа: например, базовый опт, расширенный опт, эксклюзивный партнёр	Дилер видит только свою цену в каталоге и корзине, без возможности заглянуть в прайс другого сегмента
Договорные и объёмные условия	Соглашение с клиентом: скидки, пороги по объёму, фиксированные цены на отдельные позиции	Итоговая стоимость корзины пересчитывается автоматически и совпадает с будущим счётом
Нестандартные скидки и исключения	Процесс согласования с контролем минимальной маржи и ответственным руководителем	Запрос на спецусловия уходит на согласование прямо из кабинета, а решение возвращается дилеру и менеджеру

Четыре измерения, из которых складывается цена для дилера

Сегмент партнёра

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

Договорные условия

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

Объёмные пороги

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

Регион и канал

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

Почему Excel и личные договорённости перестают работать

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

Принцип единого источника цены

Устойчивая архитектура строится на простом правиле: условия задаются один раз в учётной системе, а портал только их отображает. В связке 1С и сайта для этого используются штатные объекты: виды цен, ценовые группы, соглашения с клиентами и правила скидок. Портал при этом получает не готовые таблицы цен, а ссылку на соглашение конкретной организации и рассчитывает стоимость по тем же правилам, по которым её посчитает 1С при формировании счёта. Привязка дилера к контрагенту, о которой шла речь в разборе архитектуры запуска портала за 21 день, здесь становится фундаментом: именно по ней портал понимает, чьи условия применять. Если портал создаётся или перестраивается под такую модель, это задача уровня разработки B2B-платформы, а не настройки типового интернет-магазина.

Два подхода к передаче цен

Выгрузка готовых цен для каждого дилера

Самая очевидная схема: учётная система рассчитывает цены для каждой организации и передаёт их на сайт таблицей. Для небольшой сети она работает, но масштабируется плохо: сто дилеров и пять тысяч позиций дают полмиллиона ценовых записей, которые нужно обновлять при каждом изменении закупки или условий. Обмен растягивается на часы, а между выгрузками дилер видит устаревшую цену. Подробнее о типовой архитектуре обмена и её ограничениях говорится в разборе B2B-магазина на 1С-Битрикс.

Передача правил и расчёт на лету

Более устойчивая схема строится иначе: в портал передаются не результаты, а правила. Это виды цен, привязка организации к соглашению, пороги скидок и исключения по позициям. Цена конкретного дилера рассчитывается в момент обращения к каталогу или корзине. Объём обмена сокращается на порядки, а любое изменение условий в 1С становится видно на портале после следующего обмена правилами, без пересчёта полумиллиона записей.

Финальная цена: когда портал должен спросить 1С

Для витрины каталога допустима расчётная цена на стороне портала, но на последнем шаге, при оформлении заказа, разумно сверять итог с учётной системой. Именно в этой точке расходятся ожидания: дилер видит в корзине одну сумму, а счёт приходит с другой, потому что в 1С сработало правило, которое портал не учёл. Запрос финального расчёта при оформлении закрывает этот разрыв, а лёгкий расчёт на витрине сохраняет скорость каталога. Если в портале заложен пересчёт по объёмным порогам, корзина должна обновлять цену при каждом изменении количества, иначе дилер не увидит, что добавление пары коробок переводит всю позицию в следующий ценовой уровень.

Кеширование: типичная ловушка персональных цен

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

Коммерческие предложения и спецусловия

Для заказов с нетиповыми условиями, например крупной партии со скидкой за объём, стандартной корзины мало. Здесь работает тот же подход, что и в сложных продажах с расчётом предложения под клиента: логика калькуляции и генерация документа автоматизируются, а условия берутся из утверждённых правил. Как это реализуется на практике, показано в разборе автоматизации сложных B2B-продаж через CPQ. Условия дилера при этом должны быть видны и менеджеру: карточка организации в CRM-системе хранит соглашение и историю уступок, чтобы менеджер и дилер говорили об одних и тех же цифрах. В личном кабинете те же условия отображаются партнёру, как это устроено в личном кабинете дилера.

Скидка как управляемое решение, а не уступка

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

Согласование спецусловий как бизнес-процесс

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

Защита от ценовых войн внутри сети

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

Где хранить логику скидок: роль учётной системы

Чем сложнее правила, тем важнее, в какой системе они заданы. Для оптовой торговли с множеством видов цен, соглашений и скидок критично, чтобы конфигурация 1С поддерживала нужную модель из коробки, а не требовала кастомной разработки на каждый новый тип условий. Выбор между типовыми конфигурациями и его влияние на оптовые процессы разбирался в материале про 1С:УТ и комплексную конфигурацию для оптовой торговли. Для ценообразования вывод практический: если сложная ценовая логика уже реализована в учётной системе штатно, портал её наследует, а если нет, стоимость портала растёт за счёт доработок на стороне 1С.

Стоимость внедрения против стоимости потерь

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

Как оценить эффект до масштабирования

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

Три практических результата гибкого ценообразования

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

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

Частые вопросы о персональных ценах в B2B-портале (FAQ)

Q: Где правильно хранить персональные цены и скидки дилеров: в портале или в 1С?
A: В учётной системе. Виды цен, соглашения с клиентами и правила скидок задаются один раз в 1С, а портал получает правила и рассчитывает цену конкретной организации. Такой подход исключает дублирование таблиц и расхождения между ценой в корзине и в итоговом счёте.

Q: Как не допустить, чтобы один дилер увидел цены другого?
A: Нужны два уровня защиты: авторизация с привязкой пользователя к организации и изоляция кеша. Блоки с ценой выносятся в динамические области, а ключ кеширования включает идентификатор соглашения, поэтому цена одного дилера не попадает в выдачу другому.

Q: Как контролировать маржу, если менеджеры вправе согласовывать скидки?
A: Скидки проходят через формализованное правило: минимальная маржа по позиции, предельный процент для сегмента, срок действия и ответственный руководитель. Типовые запросы с достаточной маржой согласуются автоматически, нетиповые эскалируются руководителю с готовым расчётом.

Q: Когда цена на портале должна пересчитываться в 1С, а когда достаточно расчёта на стороне сайта?
A: Для витрины каталога допустим быстрый расчёт на стороне портала по переданным правилам. На последнем шаге, при оформлении заказа, итог стоит сверять с учётной системой, чтобы сумма в корзине совпадала с будущим счётом даже при срабатывании сложных правил.