Чому мінімальна сума замовлення ламає оформлення в B2B
Правило мінімальної суми замовлення в 1С-Битрикс часто ставлять «на всякий випадок» — щоб відсікти роздрібні замовлення на одну позицію.
В оптовому сценарії воно ламає логіку: поріг кошика рахується за ціною каталогу, а договірна ціна підставляється пізніше, вже в момент оформлення B2B-замовлення.
Клієнт із узгодженими цінами отримує відмову на суму, якої в його договорі немає. Правило блокує саме тих, хто вже пройшов погодження і прийшов за повторною закупівлею, — тобто найдешевших в обслуговуванні покупців.
Другий збій — правило взагалі не спрацьовує. Обмеження перевіряється на кроці кошика, але в компанії є й інші точки входу: швидке замовлення за артикулом, повтор із історії замовлень, обмін з 1С.
Замовлення створюється в кількох місцях, а перевірка живе в одному компоненті, і частина маршрутів іде повз неї.
Третій — обхід правила. Клієнт прибирає приховані поля форми або надсилає прямий запит до обробника оформлення, і замовлення нижче порогу проходить.
Контроль лише на боці браузера знімається однією дією; контроль на сервері без прив'язки до типу клієнта б'є по договірних покупцях.
Ціна помилки — покинуті кошики, які у звітах виглядають як «клієнт передумав». Менеджер телефонує, з'ясовує, що замовлення не пройшло через поріг, і оформлює вручну — час іде на те, що мало працювати саме. Нижче розбираємо, як закрити це серверною логікою та типами клієнтів.
Що дає керований поріг відвантаження: 4 вимірювані ефекти
Поріг відвантаження в 1С-Битрикс — не «відсічка» в кошику, а правило, яке спрацьовує на боці сервера до створення замовлення. Поріг задається окремо для кожної групи покупців: оптовик із договором і роздрібний клієнт отримують різні умови, а не одну загальну суму.
Частка дрібних замовлень падає
Рахуємо базу: скільки замовлень нижче порогу, яку частку вони займають, скільки в них рядків. Після ввімкнення правила частка дрібних замовлень скорочується в рази — частина покупців добирає кошик до потрібної суми. Видно у звітах окремо по кожній групі.
Час обробки скорочується
Дрібне замовлення коштує тих самих дій: комплектація, документи, доставка. Коли їх менше, менеджер зайнятий великими відвантаженнями, і час від оплати до передачі в доставку падає. Різницю з базою до впровадження видно за один-два місяці.
Ручні погодження переходять у правило
Раніше менеджер пропускав «своїх» клієнтів нижче порогу по дзвінку або в листуванні. Тепер виняток — дозвіл для групи покупців або особистий поріг, а не усна домовленість. Звернень «чи можна менше» стає менше: клієнт бачить умову та залишок до порогу прямо в кошику.
Спірні замовлення не губляться
Якщо суми не вистачає, клієнт отримує зрозуміле повідомлення із залишком, а не мовчазну відмову на оформленні. Кількість покинутих кошиків і звернень до підтримки знижується, а менеджер бачить, хто вперся в поріг, і вирішує питання точково.
Способи контролю мінімального замовлення: кошик, оформлення, профіль
Поріг мінімальної суми замовлення можна перевіряти в чотирьох точках, і вони не замінюють, а доповнюють одна одну: кошик інформує, оформлення замовлення зупиняє, профіль компанії задає правила для конкретного клієнта, а серверна перевірка закриває обхід контролів на боці браузера.
Якщо залишити лише підказку в кошику, поріг обходиться прямим запитом — тому серверний контроль вважаємо обов'язковим, а інші рівні налаштовуємо як інтерфейсні.
| Де контролюємо | Коли підходить | Обмеження |
|---|---|---|
| Кошик | раннє попередження оптовика, повзунок доставки | лише інформування, значення змінюється в браузері |
| Оформлення замовлення | жорсткий стоп перед створенням замовлення | не розрізняє типи платників і договорів |
| Профіль компанії | різні пороги для груп клієнтів і договорів | потребує прив'язки користувача до компанії та ролі |
| Серверна перевірка | обов'язковий контур для всіх сценаріїв | потрібні зрозумілі тексти помилок і повторна валідація |
Як рівні поєднуються
Пороги тримаємо в одному місці — у налаштуваннях групи клієнтів або типу договору, які підтягуємо з облікової системи. Тоді кошик, оформлення та профіль читають одне правило й не розходяться: клієнт бачить ту саму суму, яку перевіряє сервер.
Винятки для раніше узгоджених умов задаємо не правкою шаблону, а окремою групою з нульовим порогом — правило залишається прозорим і переноситься між середовищами без ручних правок.
Етапи впровадження: аудит кошика, схема правил, перевірка
Правила щодо мінімальної суми замовлення живуть не в одному місці: частина логіки — у шаблоні кошика, частина — в обробниках оформлення 1С-Битрикс, частина — в обміні з обліковою системою.
Завдання — звести їх в один відтворюваний набір, який переживає оновлення платформи й залишається зрозумілим менеджерам без програміста. Робота йде шістьма етапами, від аудиту до передачі налаштувань.
- Аудит кошика та сценаріїв замовлення. Дивимося, на якому кроці рахується сума — до знижок чи після, чи входить доставка, як поводяться різні типи платників і групи покупців.
- Схема правил. Фіксуємо матрицю: пороги за групами, окремі умови для юросіб і опту, винятки для самовивозу, поведінку при частковому відвантаженні. Погоджуємо до коду — правки на цьому кроці найдешевші.
- Реалізація перевірки. Правило працює в двох місцях: підказка в кошику пояснює, скільки не вистачає до порогу, а серверна перевірка не дає оформити замовлення в обхід інтерфейсу.
- Тестовий контур. Розгортаємо копію каталогу й налаштувань — логіку перевіряємо на реальних даних, не зачіпаючи робочий сайт.
- Перевірка сценаріїв. Гість і авторизований покупець, різні групи, оформлення з особистого кабінету, обмін з обліковою системою, мобільна версія — проганяємо граничні випадки й фіксуємо результат.
- Передача замовнику. Віддаємо схему правил, інструкцію для менеджерів і список місць, де поріг змінюється без участі розробника.
Що залишається в проєкті: налаштування, ролі, регламенти
Після впровадження в проєкті залишається не набір розрізнених галочок, а підтримуваний контур: карта налаштувань, схема успадкування умов, права доступу та регламенти.
За ним наступний поріг або нова група покупців додається однією правкою, без перезбирання логіки оформлення замовлення.
- Карта налаштувань — де саме задано поріг: рівень сайту, групи покупців, регіону, типу ціни; яке правило перекриває інші при перетині умов.
- Схема успадкування умов — що спрацює для оптовика з філією та чому поріг групи не збігається з базовим.
- Права доступу — хто змінює суму, хто погоджує, кому залишено лише перегляд; правку порогу винесено в окреме право з підтвердженням другим співробітником.
- Інструкція для покупців — формулювання в кошику, листі та особистому кабінеті: чому замовлення не оформлюється і як добрати суму.
- Регламент змін — коли поріг правиться (акція, сезон, новий договір), хто погоджує і як відкочується попередня версія.
- Журнал змін — автор, час і попереднє значення щодо кожної правки, щоб розібрати спірне замовлення за фактом.
- Пам'ятка менеджеру — як пояснити покупцю відмову в оформленні та в якому випадку сума знімається вручну.
- Результат впровадження — приймання контрольними замовленнями: нижче порогу, рівно на порозі та вище, окремо для кожної групи покупців.
Кейс: як оптовий постачальник перебудував правила кошика
В оптового постачальника кошик на 1С-Битрикс був єдиним для всіх: і роздрібний покупець, і дилер оформлювали замовлення за одними й тими самими правилами.
У результаті 38% замовлень надходили на одну-дві позиції — їх усе одно збирали вручну, і менеджери витрачали основний час на дозбирання та дзвінки з уточненнями.
Ми розвели покупців за сегментами — роздріб, дилер, великий опт — і прив'язали до кожної групи свої правила кошика: мінімальна кількість позицій, поріг за обсягом партії, окремі умови самовивозу.
Поріг не блокує покупця мовчки: кошик показує, скільки не вистачає до умови, і пропонує добрати із супутніх груп.
Що змінили
Нижче порогу в роздрібі залишилася тільки швидка купівля однієї позиції — її винесли в окремий сценарій із самовивозом, і такі замовлення перестали потрапляти в чергу ручної обробки.
Дилерський сегмент отримав поріг за кількістю позицій, великий опт — за обсягом партії, щоб замовлення відразу йшло у відвантаження, а не в дозбирання.
Метрики до та після
- частка замовлень нижче порогу: 38% → 11%
- середній час обробки замовлення: 24 хвилини → 8 хвилин
- частка замовлень, оформлених без участі менеджера: 52% → 88%
- скасування через неузгоджені умови: 15% → 4%
- середня кількість позицій у замовленні: +2,3
Правила живуть у налаштуваннях груп користувачів, тому новий сегмент додається без переписування логіки кошика.
Чим правило кошика відрізняється від обмеження в особистому кабінеті?
У 1С-Битрикс це два різних рівні перевірки, і один одного вони не підмінюють. Правило кошика спрацьовує при перерахунку кошика: змінюється склад або сума — умова переперевіряється, і в разі недотримання оформлення блокується.
Обмеження в кабінеті перевіряє дані покупця — тип платника, профіль, групу — до того, як він почне збирати замовлення.
Різниця механізмів — у точці відмови. Кошик не дає завершити оформлення, поки сума нижче порогу, і покупець бачить це прямо в кошику. Обмеження в кабінеті звужує доступ раніше: частина цін, способів оплати або сам розділ оформлення для профілю просто не з'являються.
| Критерій | Правило кошика | Обмеження в кабінеті |
|---|---|---|
| Коли спрацьовує | при перерахунку кошика | при визначенні профілю |
| На що спирається | склад і сума замовлення | дані платника та групи |
| Що бачить покупець | блокування оформлення | урізаний набір цін і оплат |
| Успадкування умов | від прив'язки до сайту та групи | від типу платника |
| Поріг | загальний для всіх | залежить від сегмента |
Успадкування умов влаштовано по-різному: правило кошика бере умови від об'єкта прив'язки — сайт, група користувачів, профіль, — а обмеження в кабінеті зав'язане на тип платника. За кількох сегментів поріг тримають у кабінеті, а кошик використовують як фінальну перевірку.
Вибір механізму диктує завдання: жорсткий мінімум на все замовлення — правило кошика, різні умови для дилерів і роздробу — обмеження в кабінеті.
Технічні питання: обмін, кеш, промо та винятки
Поріг мінімальної суми бере участь у розрахунку кошика, тому зачіпає три вузли, які найчастіше ламаються при наївній реалізації: кеш, правила знижок і обмін з обліковою системою. Розбираємо кожен.
Блок кошика та ознака «поріг не досягнуто» залежать від вмісту кошика й профілю покупця — ці дані виводимо з-під загального кешу. Каталог залишається статичним і віддається швидко, а підсумок збирається окремо при кожній зміні.
Поріг перераховується відразу після додавання позиції, і чистити кеш усього каталогу після правки налаштувань не доводиться.
Порядок застосування знижок фіксуємо до перевірки порогу: спочатку відпрацьовують правила акцій і персональні знижки, потім поріг перевіряється за підсумковою сумою.
Інакше клієнт із накопичувальною знижкою бачить одну цифру в кошику й іншу на кроці оформлення — найчастіше джерело звернень до підтримки.
В облікову систему замовлення йде вже з розрахованою ознакою проходження порогу, а назад повертаються статуси замовлень: оплачено, зібрано, відвантажено. Винятки задаємо правилами — категорії, що не беруть участі в підрахунку, самовивіз, окремі групи оптових покупців. Правила живуть у налаштуваннях, а не в коді, тому новий сценарій додається без доопрацювання.
Поріг не повинен діяти для оптових клієнтів — як це влаштовано?
Поріг перевіряється в прив'язці до групи покупця: для однієї групи правило ввімкнено, для іншої вимкнено або замінено своїм значенням. Перемикання групи відразу змінює поведінку кошика, окрема копія сайту не потрібна.
Після зміни порогу кеш скидати вручну?
Ні. Налаштування порогу входять у ключ кешування блоку кошика, тому при збереженні нових значень старі варіанти перестають віддаватися покупцям. Сторінки каталогу при цьому не інвалідуються — їхній кеш залишається валідним.
Обговоримо вашу схему оформлення та повернемося з планом
Щоб план робіт був точним, а не загальним, нам потрібен контекст вашої схеми замовлення: за якими ознаками ви ділите клієнтів (група покупця, договір, тип ціни, регіон), на якому кроці спрацьовує перевірка мінімальної суми — у кошику, при оформленні чи перед оплатою, і що робити із замовленнями, оформленими до зміни.
Від вас достатньо тестового стенда, списку груп покупців і правил розрахунку суми — зі знижками, доставкою та позиціями під замовлення. Якщо стенда немає, погодимо роботи на копії, щоб правки не зачепили робочий сайт.
Далі ми повертаємося з оцінкою та планом, де кожен пункт — конкретна зміна, а не «доопрацювати кошик».
Що увійде в план:
- логіка перевірки: де рахується сума, які групи покупців під неї потрапляють, які позиції не враховуються;
- зміни в оформленні замовлення: текст повідомлення, блокування кнопки, підказка про суму, якої не вистачає;
- налаштування для менеджерів: як обійти обмеження для окремого клієнта без правки коду;
- обмін з 1С: які правила приїжджають з облікової системи та як діяти при розбіжності;
- сценарії перевірки: гість, оптовий клієнт, клієнт із відстрочкою, замовлення на граничній сумі;
- передача проєкту: доступи, схема налаштувань, інструкція для менеджерів і розробників;
- підтримка після впровадження: термін супроводу та порядок правок, якщо правила зміняться.
Опишіть завдання — повернемося з оцінкою та планом.
