Кошик та оформлення замовлення на 1С-Бітрікс
Чому sale.order.ajax — головний ворог конверсії
Штатний sale.order.ajax — компонент, який Бітрікс пропонує для оформлення замовлення. Багатокроковий: доставка → оплата → підтвердження. На кожному переході втрачається 10-15% користувачів. Три кроки — і третина покупців, які вже поклали товар у кошик, пішли. Не тому що передумали — тому що інтерфейс спіткнувся.
А ще sale.order.ajax видає 500-ку, якщо не налаштований хоча б один обробник доставки. Або зависає на 15 секунд при розрахунку СДЕК, бо запит до API синхронний і без таймауту. Або вимагає ІПН у фізичної особи, бо властивість замовлення не розділена за типом платника. Кожен такий випадок — прямі втрати.
Ми переробляємо чекаут з одним фокусом — конверсія. Мінімум кроків, максимум зручності, надійна робота зв'язок з платежами та доставкою.
Однокроковий чекаут: все на одному екрані
Усі поля на одній сторінці. Логічне групування, жодних зайвих переходів.
- Контактні дані — ім'я, телефон, email. Три поля. Не п'ять, не десять, не «вкажіть дату народження для програми лояльності»
- Доставка — обрав місто → побачив способи з цінами та термінами. AJAX-розрахунок через API СДЕК, Boxberry, Укрпошти. Запити паралельні з таймаутом 3 секунди — якщо один API завис, решта відобразяться
- Оплата — способи фільтруються за обраною доставкою. Накладений платіж при самовивозі? Не показуємо
- Промокод — поле видно, перевірка миттєва, знижка відображається в підсумку одразу
- Разом — динамічний перерахунок при будь-якій зміні. Змінив кількість → сума → вартість доставки → разом. Без перезавантаження сторінки
Під капотом
- Повний AJAX — жодного перезавантаження. Компонент працює через
Bitrix\Sale\Order::create()та REST, а не через стандартнийsale.order.ajax - Валідація в реальному часі: не «заповніть поле правильно», а «номер телефону: +380 (__) --». Маска
inputmask+ серверна перевірка - Збереження даних при випадковому переході —
sessionStorageзберігає введене, при поверненні все на місці - Автозаповнення адреси через DaData: почав вводити вулицю → повна адреса з індексом, FIAS-кодом та координатами. Менше помилок з боку кур'єрської служби
- Підтримка властивостей замовлення за типом платника — фізична особа бачить одні поля, юридична — інші. Перемикач у формі
Гостьове замовлення: прибрати обов'язкову реєстрацію
«Хочу купити USB-кабель за 300 гривень, а мене просять придумати пароль із 8 символів з великою літерою та спецсимволом». Обов'язкова реєстрація вбиває 25-30% конверсії на дрібних замовленнях.
- Покупка без облікового запису — оформлюємо через
CSaleUser::GetAnonymousUserID()або створюємо користувача автоматично з випадковим паролем - Після оформлення — лист із даними для входу. Хоче — активує обліковий запис, не хоче — і так отримає замовлення
- Повторний візит — визначаємо за email або телефоном, прив'язуємо до наявного облікового запису
- Авторизація прямо в чекауті: SMS-код замість пароля — через
Bitrix\Main\Authentication\ShortCodeабо інтеграцію з SMS-шлюзом
Крос-сел: допродажі, які не дратують
У кошику
Рекомендації на основі реальних даних із b_sale_basket — «з цим товаром купували» на базі асоціативних правил, а не випадкових товарів.
- Аксесуари: до телефону — чохол і захисне скло. Прив'язка через властивість інфоблоку
PROPERTY_ACCESSORIES - Оптова мотивація: «Візьміть 3 — заощадите 15%». Реалізується через правила кошика в
b_sale_discount - Поріг безкоштовної доставки: «Додайте на 500 грн — доставка безкоштовно». Простий віджет, але збільшує середній чек на 10-20%
Керування через адмінку
Менеджер прив'язує рекомендовані товари вручну або вмикає автоматичні алгоритми. Правила відображення: категорія, діапазон цін, наявність. A/B-тестування різних стратегій — без розробника.
Покинуті кошики: повертаємо 15-20% тих, хто пішов
Збереження
- Авторизовані — кошик у
b_sale_basket, доступний з будь-якого пристрою - Гості — cookie з TTL 30 днів.
FUSER_IDприв'язаний до cookie, кошик не зникне через годину - Синхронізація: додав з телефону, оформив з ноутбука — кошик єдиний
Повернення
- Email-серія: 3 листи. Через 1 годину — нагадування. Через 24 години — «ваш товар закінчується». Через 72 години — персональний промокод на 5-10%. Через
sale.basketcomponent+CEvent::Send()з відкладеним надсиланням через агенти - Push-сповіщення через браузер —
Notification API, підписка через сервіс-воркер - Ретаргетинг — дані про кошик відправляються в рекламні мережі через eCommerce-події
Аналітика відмов
На якому кроці йдуть? Якщо на виборі доставки — ціна доставки шокує. Якщо на оплаті — картку відхилено, 3D-Secure не проходить. Помилки платіжної системи ловимо через колбеки ЮKassa/CloudPayments і пишемо в лог — бачимо конкретний відсоток відмов за кожною причиною.
Промокоди: правильна реалізація
| Тип | Механізм у Бітрікс | Нюанс |
|---|---|---|
| Фіксована знижка | CSaleDiscount, тип «на замовлення» |
Не забути обмежити мінімальну суму — інакше знижка 500₴ при замовленні на 300₴ |
| Відсоткова | CSaleDiscount, умова «купон» |
Максимальна знижка — задати стелю, інакше при замовленні на 500К знижка 50% = 250К |
| Безкоштовна доставка | Правило кошика + прив'язка до служби доставки | Працює лише з конкретними службами — не можна дати безкоштовну «будь-яку» |
| Подарунок | Автододавання товару в кошик через обробник | Товар-подарунок має бути в наявності, інакше кошик зламається |
UX промокоду:
- Поле видно, але не кричить — не відволікає тих, у кого коду немає
- Миттєва перевірка: «Промокод закінчився» / «Мінімальна сума 3000₴» — а не «Error 422»
- Знижка видна в підсумковому розрахунку окремим рядком
- Можна прибрати промокод і застосувати інший
UX-оптимізація: дрібниці, які вирішують
Десктоп:
- Прогрес-бар — користувач бачить, де він
- Розумні значення за замовчуванням — найпопулярніший спосіб доставки вже обрано (визначаємо за статистикою
b_sale_order) - Мінімум обов'язкових полів — лише те, без чого не можна відправити замовлення. По батькові? Необов'язково. Коментар? Необов'язково
- Перерахунок без лоадерів на 5 секунд — debounce 300ms на AJAX-запитах
Мобільні:
- Великі кнопки — палець не промахується.
min-height: 48pxза настановами Google - Правильні типи клавіатури:
type="tel"для телефону,inputmode="numeric"для кількості - Кнопка «Оформити» зафіксована внизу —
position: sticky - Розгортувані секції — екранний простір на 375px цінний
Обробка помилок:
- «Перевірте номер картки» замість «Payment processing error»
- Автопрокрутка до першої помилки —
scrollIntoView({ behavior: 'smooth' }) - «Товар закінчився» — обробляємо в чекауті без втрати заповнених даних. Пропонуємо аналог або прибираємо з кошика з перерахунком
Інтеграції
- DaData — адреса, ПІБ, ІПН. Підказки під час введення, валідація ФІАС
- Карти — вибір ПВЗ на карті, геолокація для визначення міста
- СДЕК, Boxberry, Укрпошта — API-розрахунок вартості та термінів у реальному часі
- ЮKassa, CloudPayments, LiqPay — прийом платежів, рекурентні списання, холдування
- CRM — замовлення автоматично потрапляє в Бітрікс24, створюється угода з прив'язкою до контакту
-
Склад — перевірка залишків через
CCatalogStoreProduct::GetList()у реальному часі
Терміни
| Завдання | Термін |
|---|---|
| Оптимізація поточного чекауту | 1-2 тижні |
| Однокроковий чекаут з нуля | 3-5 тижнів |
| Система промокодів | 1-2 тижні |
| Крос-сел у кошику | 1 тиждень |
| Механізм покинутих кошиків | 2-3 тижні |
| Комплексна переробка | 6-10 тижнів |
Збільшення конверсії чекауту на 1-2% при стабільному трафіку — це зростання виручки без зростання рекламного бюджету. Найшвидший ROI в e-commerce.







