Индивидуальные цены для клиентов: правила B2B-магазина

Как устроить индивидуальные цены для B2B-клиентов: организация, прайс-лист, приоритет правил, актуальность корзины, обмен с 1С и проверка доступа.

Автор: Александр Поркулевич, CEO и основатель, 404gen.

Какая задача стоит за индивидуальными ценами

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

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

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

Цена принадлежит контексту организации

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

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

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

Выберите объект предложения

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

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

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

Индивидуальные цены для клиентов требуют приоритета правил

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

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

Отделите прайс от скидки и промокода

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

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

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

Период действия должен быть определён точно

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

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

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

Корзина хранит намерение, а не вечную гарантию цены

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

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

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

Назначьте владельца коммерческих данных

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

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

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

Кэш должен учитывать покупателя и редакцию

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

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

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

Закрытые условия проверяются на сервере

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

Разграничение по строкам базы может стать одним из слоёв защиты, но не заменяет проектирование приложения. В документации PostgreSQL описаны политики row-level security и особенности их применения. Конкретная архитектура должна учитывать соединения, служебные роли и обходные пути. Нельзя объявить задачу решённой по одному наличию механизма в базе, не проверив фактические запросы всех каналов.

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

Объясняйте расхождение без ручной переписки по кругу

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

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

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

Приёмка по матрице условий

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

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

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

Что подготовить для оценки

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

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

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

Частые вопросы

Можно ли просто назначить каждому клиенту процент скидки?

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

Когда нужно пересчитывать сохранённую корзину?

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

Можно ли показывать розничную цену при ошибке обмена?

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

Нужна ли отдельная разработка поверх готового магазина?

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

Источники и пример интерфейса

Пример платформенной модели клиентских каталогов — документация Shopify о B2B-каталогах и ценах. Один из механизмов разграничения данных — политики row-level security PostgreSQL. Ни один из этих инструментов не задаёт автоматически правила конкретной компании: источники, приоритеты и проверку согласуют отдельно.

Для подготовки прайса полезна статья об импорте Excel и проверке строк, а для соседних скидочных правил — материал о промокодах. В концепте «Сметка» показаны организация, основание цены и проверка редакции расчёта на вымышленных данных.

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