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

Иллюстрация: индивидуальные прайсы относятся к конкретным покупателям.

Оглавление

• Сначала определите, кому принадлежит цена
• Источник цены должен быть известен
• Приоритеты правил: не всегда нужно брать минимум
• Цена относится к конкретной единице и варианту
• Срок действия и версия прайса
• Переключение организации — это пересчёт, а не смена подписи
• Что сообщать при изменении цены в корзине
• Ручная цена менеджера не должна терять основание
• Как разбирать расхождение без переписки на полдня
• Учебная проверка на трёх организациях
• Внедряйте по группам условий, а не по всем клиентам сразу

Сначала определите, кому принадлежит цена

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

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

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

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

Источник цены должен быть известен

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

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

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

Если источник недоступен, заранее выберите поведение. Можно показать последнее значение с допустимыми ограничениями, перевести заказ в запрос уточнения или временно запретить подтверждение цены. Решение зависит от риска и процесса. Но подстановка розничного прайса под подписью «ваша цена» без объяснения почти гарантирует недоразумение.

Приоритеты правил: не всегда нужно брать минимум

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

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

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

Смена организации меняет контекст цены и доступных условий.

Цена относится к конкретной единице и варианту

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

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

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

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

Срок действия и версия прайса

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

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

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

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

Переключение организации — это пересчёт, а не смена подписи

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

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

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

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

Что сообщать при изменении цены в корзине

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

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

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

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

Перед заказом цену сверяют с актуальными основаниями расчёта.

Ручная цена менеджера не должна терять основание

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

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

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

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

Как разбирать расхождение без переписки на полдня

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

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

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

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

Учебная проверка на трёх организациях

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

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

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

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

Внедряйте по группам условий, а не по всем клиентам сразу

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

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

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

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