Сповіщення про готовність замовлення: налаштування в 1С-Бітрікс

Клієнт оформлює самовивіз, чекає товар, але повідомлення не приходить — він або приходить раніше часу, або забуває про замовлення. У результаті зняття резерву, повернення та втрата лояльності. Ми усуваємо цю проблему: інформування «Ваше замовлення готове до видачі» надсилається миттєво, як тільки співробітник складу змінює статус. Наші інженери з 10+ років досвіду роботи з Бітрікс гарантують надійне рішення під ключ.

Відправлення сповіщення критичне, тому що покупець орієнтується на строк зберігання. Якщо не сповістити вчасно — замовлення не заберуть. Якщо сповістити раніше — клієнт прийде, а товару ще немає. Правильне налаштування виключає обидва сценарії. За даними нашої практики, своєчасне повідомлення збільшує відсоток викупу замовлень самовивозу на 15–20%, а повернення знижуються до 30%. Економія від впровадження становить до 30% від вартості повернень — при середньому чеку 3000 грн це близько 900 грн з кожного повернення.

Чому важливо налаштувати сповіщення правильно?

Неправильне налаштування веде до збоїв: сповіщення приходить із затримкою, не доходить до клієнта або містить невірну адресу складу. У результаті — невдоволення та повернення. Правильна конфігурація гарантує:

• миттєву відправку після зміни статусу;
• роботу обраного каналу (SMS, Telegram, email) без збоїв;
• актуальні дані про точку самовивозу та строк зберігання.

Ми використовуємо спеціальні статуси та події, описані в документації Бітрікс, для миттєвої реакції. статуси замовлень

Які канали сповіщень ефективніші?

Telegram-сповіщення доставляються в 2–3 рази швидше за SMS, але вимагають підписки клієнта. SMS універсальний і надійніший, але повільніший за Telegram. Email — найдешевший канал, але найповільніший. Комбінування каналів підвищує ймовірність доставки до 99.9%.

Як сповіщення впливає на конверсію?

Своєчасне інформування збільшує відсоток викупу замовлень самовивозу на 15–20%. Клієнт отримує чіткий сигнал: «Ваше замовлення чекає». Якщо затримка — ймовірність невикупу зростає в 2 рази. Наші клієнти відзначають зниження повернень до 30% після налаштування системи. Окупність рішення — 2–3 місяці. Орієнтовна вартість робіт — від 4000 до 8000 грн залежно від складності.

Типові статуси замовлень і тригер повідомлення

Спеціальний статус RC — точка входу для сповіщення. Без нього механізм не працює.

У Бітрікс немає вбудованого статусу «Готовий до видачі». Створюємо кастомний:

Магазин → Налаштування → Статуси замовлень → Додати:

• Символьний код: RC (Ready for Collect)
• Назва: «Готовий до видачі»
• Колір: зелений

Після створення статусу — обробник на його зміну:

\Bitrix\Main\EventManager::getInstance()->addEventHandler(
    'sale',
    'OnSaleOrderStatusChange',
    function (\Bitrix\Main\Event $event) {
        $order    = $event->getParameter('ENTITY');
        $newStatus = $order->getField('STATUS_ID');

        if ($newStatus !== 'RC') {
            return; // Нас цікавить тільки статус "Готовий до видачі"
        }

        // Отримуємо точку самовивозу з властивості замовлення
        $pickupStoreProp = $order->getPropertyCollection()
            ->getItemByOrderPropertyCode('PICKUP_STORE_ID');
        $storeId = $pickupStoreProp ? $pickupStoreProp->getValue() : null;

        $storeInfo = null;
        if ($storeId) {
            $storeInfo = \Bitrix\Catalog\StoreTable::getById($storeId)->fetch();
        }

        // Формуємо та надсилаємо сповіщення
        \Local\Notifications\ReadyForPickupNotifier::notify($order, $storeInfo);
    }
);

Клас сповіщення про готовність

// /local/lib/Notifications/ReadyForPickupNotifier.php
namespace Local\Notifications;

use Bitrix\Sale\Order;

class ReadyForPickupNotifier
{
    public static function notify(Order $order, ?array $storeInfo): void
    {
        $userId = $order->getUserId();
        $user   = \Bitrix\Main\UserTable::getById($userId)->fetch();

        $storeName    = $storeInfo['TITLE'] ?? 'магазині';
        $storeAddress = $storeInfo['ADDRESS'] ?? '';
        $orderId      = $order->getId();

        // Час зберігання — з налаштувань (за замовчуванням 5 днів)
        $holdDays = (int)\Bitrix\Main\Config\Option::get(
            'local.pickup', 'hold_days', 5
        );
        $holdUntil = date('d.m.Y', strtotime("+{$holdDays} days"));

        $message = "Замовлення #{$orderId} готове до видачі в {$storeName}.\n";
        if ($storeAddress) {
            $message .= "Адреса: {$storeAddress}\n";
        }
        $message .= "Строк зберігання: до {$holdUntil}.";

        // Telegram
        if (!empty($user['UF_TELEGRAM_CHAT_ID'])) {
            \Local\Telegram\BotService::sendMessage(
                $user['UF_TELEGRAM_CHAT_ID'],
                $message
            );
        }

        // SMS через сервіс
        $phone = $order->getPropertyCollection()
            ->getPhone()
            ?->getValue();
        if ($phone) {
            \Local\Sms\SmsService::send($phone, $message);
        }

        // Email — стандартний механізм Бітрікс
        // Створюємо подію для шаблону листа
        \CEvent::Send('ORDER_READY_FOR_PICKUP', SITE_ID, [
            'ORDER_ID'      => $orderId,
            'STORE_NAME'    => $storeName,
            'STORE_ADDRESS' => $storeAddress,
            'HOLD_UNTIL'    => $holdUntil,
            'USER_EMAIL'    => $user['EMAIL'],
            'USER_NAME'     => $user['NAME'],
        ]);
    }
}

Налаштування email-шаблону

Шаблон email-сповіщення створюється в Налаштування → Поштові події → Шаблони → Додати з типом події ORDER_READY_FOR_PICKUP. У шаблоні використовуйте змінні #ORDER_ID#, #STORE_NAME#, #STORE_ADDRESS#, #HOLD_UNTIL#. Зразковий текст листа:

Здравствуйте, #USER_NAME#!
Ваше замовлення #ORDER_ID# готове до видачі в #STORE_NAME#.
Адреса: #STORE_ADDRESS#
Строк зберігання: до #HOLD_UNTIL#.
З повагою, інтернет-магазин.

Обробка збоїв доставки

Якщо сповіщення не дійшло, ми перевіряємо логи відправлення та статус каналу. Типові причини збою — невірний номер телефону, відключений Telegram-бот або неактивний email. Налаштовуємо повторну відправку через альтернативний канал: наприклад, якщо SMS не пішла, надсилаємо email. Це підвищує надійність системи до 99%. Додаткову інформацію по REST API Бітрікс24 можна використовувати для інтеграції.

Автоматичний перехід при надходженні товару

Якщо товару не було в момент покупки, замовлення має автоматично перейти в статус «Готовий до видачі» при надходженні на склад:

\Bitrix\Main\EventManager::getInstance()->addEventHandler(
    'catalog',
    'OnProductUpdate',
    function (\Bitrix\Main\Event $event) {
        $productId = $event->getParameter('ID');
        $fields    = $event->getParameter('FIELDS');

        if (!isset($fields['QUANTITY']) || $fields['QUANTITY'] <= 0) {
            return;
        }

        // Шукаємо очікуючі замовлення на цей товар із самовивозом
        $waitingOrders = \Local\Orders\PickupOrderFinder::getWaiting($productId);
        foreach ($waitingOrders as $waitingOrderId) {
            $order = \Bitrix\Sale\Order::load($waitingOrderId);
            if ($order && $order->getField('STATUS_ID') === 'N') {
                $order->setField('STATUS_ID', 'RC');
                $order->save();
            }
        }
    }
);

Що входить в роботу

• Створення спеціального статусу «Готовий до видачі» з обробником
• Налаштування мультиканальних сповіщень (SMS, Telegram, email)
• Інтеграція з точками самовивозу (підстановка адреси та назви)
• Моніторинг доставки та автоматичний повтор при збої
• Документація з налаштування та навчання менеджерів (2 години)
• Гарантія 3 місяці на всі доробки
• Доступ до вихідного коду та права адміністратора

Процес роботи

1. Аналітика — вивчаємо поточні статуси та логіку самовивозу.
2. Проектування — створюємо схему переходів і каналів сповіщень.
3. Реалізація — пишемо код спеціального статусу, обробника та сервісів.
4. Тестування — перевіряємо всі можливі сценарії: зміна статусу, відсутність товару, збій SMS-шлюзу.
5. Деплой — викладаємо на бойовий сервер, налаштовуємо моніторинг.
6. Навчання — показуємо менеджерам, як керувати статусами.

Типові помилки при налаштуванні

• Забувають створити подію для email-шаблону — листи не йдуть.
• Не вказують ID складу у властивості замовлення — сповіщення без адреси.
• Не враховують кешування — сповіщення приходить із затримкою.
• Не перевіряють права доступу до REST API (для Telegram) — канал не працює.

Наші інженери з 10+ років досвіду виключають ці помилки на етапі тестування.

Строки та гарантія

Спеціальний статус, обробник, мультиканальне сповіщення — від 4 до 8 годин. Автоматичний перехід при надходженні товару — ще 4–6 годин. На всі роботи надається гарантія 3 місяці. Зв'яжіться з нами, щоб обговорити деталі вашого проекту. Замовте налаштування — отримайте готове рішення під ключ.

Як налаштування кошика 1С-Бітрікс вирішує проблему втрати конверсії

Ми займаємося налаштуванням кошика та оформлення замовлення на 1С-Бітрікс з 2013 року. За цей час зіткнулися з типовою проблемою: штатний sale.order.ajax втрачає на кожному кроці 10–15% покупців. Три кроки — і третина тих, хто вже додав товар, іде. Не тому що передумали — інтерфейс спотикається.

sale.order.ajax видає 500-ку, якщо не налаштований хоча б один обробник доставки. Зависає на 15 секунд при розрахунку НПП — запит синхронний, без таймауту. Потребує ІПН у фізичної особи, бо властивість не розділена за типом платника. Кожен такий кейс — прямі втрати, які система не компенсує.

Наш досвід (понад 10 років, 300+ проєктів, сертифіковані спеціалісти) показує: переробка чекауту з одним фокусом — конверсія — окупається за 1–2 місяці. Мінімум кроків, максимум зручності, надійна робота зв'язок із платежами та доставкою.

Чому однокроковий чекаут збільшує конверсію?

Всі поля на одній сторінці. Логічне групування, жодних зайвих переходів:

• Контактні дані — ім'я, телефон, email. Три поля. Не п'ять, не десять, не «вкажіть дату народження для програми лояльності».
• Доставка — вибрав місто → побачив способи з цінами та термінами. AJAX-розрахунок через API НПП, Boxberry, Укрпошти. Запити паралельні, таймаут 3 секунди — якщо один API завис, інші покажуться.
• Оплата — способи фільтруються за вибраною доставкою. Післяплата при самовивозі? Не показуємо.
• Промокод — поле видно, перевірка миттєва, знижка відображається в підсумку одразу.
• Підсумок — динамічний перерахунок за будь-якої зміни. Змінив кількість → сума → вартість доставки → підсумок. Без перезавантаження.

Під капотом:

• Повний AJAX — жодного перезавантаження. Компонент працює через Bitrix\Sale\Order::create() та REST, не через стандартний sale.order.ajax.
• Валідація в реальному часі: не «заповніть поле правильно», а «номер телефону: +38 (__) --». Маска inputmask + серверна перевірка.
• Збереження даних при випадковому відході — sessionStorage зберігає введене, при поверненні все на місці.
• Автозаповнення адреси через DaData: почав вводити вулицю → повна адреса з індексом, FIAS-кодом та координатами. Менше помилок з боку кур'єрської.
• Підтримка властивостей замовлення за типом платника — фізична особа бачить одні поля, юридична — інші. Перемикач у формі.

Однокрокова форма дає приріст конверсії в середньому на 15–20% порівняно з багатокроковою (згідно з даними Statista, частка відмов на другому кроці сягає 40%). Джерело: Statista, дослідження чекауту в e-commerce.

Як відновити покинуті кошики?

Збереження. Авторизовані — кошик у b_sale_basket, доступний з будь-якого пристрою. Гості — cookie з TTL 30 днів. FUSER_ID прив'язаний до cookie, кошик не пропаде через годину. Синхронізація: додав з телефону, оформив з ноутбука — кошик єдиний.

Повернення. Email-серія: 3 листи. Через 1 годину — нагадування. Через 24 години — «ваш товар закінчується». Через 72 години — персональний промокод на 5–10%. Реалізація через sale.basketcomponent + CEvent::Send() з відкладеною відправкою через агенти. Push-повідомлення через браузер — Notification API, підписка через сервіс-воркер. Ретаргетинг — дані про кошик йдуть у Google Ads через eCommerce-події.

Аналітика відмов. На якому кроці йдуть? Якщо на виборі доставки — ціна шокує. Якщо на оплаті — карта відхиляється, 3D-Secure не проходить. Помилки платіжної системи ловимо через колбеки LiqPay/CloudPayments і пишемо в лог — бачимо конкретний відсоток відмов за кожною причиною. Гарантуємо повернення 15–20% користувачів, які оформили кошик і покинули сайт.

Гостьове замовлення: убити обов'язкову реєстрацію

«Хочу купити USB-кабель, а мене просять придумати пароль із 8 символів з великою літерою та спецсимволом». Обов'язкова реєстрація вбиває 25–30% конверсії на дрібних замовленнях.

• Покупка без акаунта — оформлюємо через CSaleUser::GetAnonymousUserID() або створюємо користувача автоматично з випадковим паролем.
• Після оформлення — лист з даними для входу. Хоче — активує акаунт, не хоче — і так отримає замовлення.
• Повторний візит — визначаємо за email або телефоном, прив'язуємо до існуючого акаунта.
• Авторизація прямо в чекауті: SMS-код замість пароля — через Bitrix\Main\Authentication\ShortCode або інтеграцію з SMS-гейтом.

Крос-сел: допродажі, які не дратують

У кошику

Рекомендації на основі реальних даних із b_sale_basket — «з цим товаром купували» на базі асоціативних правил, а не рандому. Прив'язка через властивість інфоблоку PROPERTY_ACCESSORIES. Оптова мотивація: «Візьміть 3 — заощадьте 15%» — реалізується через правила кошика в b_sale_discount. Поріг безкоштовної доставки: «Додайте на певну суму — доставка безкоштовно». Простий віджет, але збільшує середній чек на 10–20%.

Управління через адмінку

Менеджер прив'язує рекомендовані товари вручну або вмикає автоматичні алгоритми. Правила відображення: категорія, діапазон цін, наявність. A/B-тестування різних стратегій — без розробника.

Промокоди: правильна реалізація

UX промокоду:

• Поле видно, але не кричить — не відволікає тих, у кого коду немає.
• Миттєва перевірка: «Промокод закінчився» / «Мінімальна сума не досягнута» — а не «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 — адреса, ПІБ, ІПН. Підказки під час введення, валідація ФІАС.
• Google Maps — вибір пунктів видачі на карті, геолокація для визначення міста.
• НПП, Boxberry, Укрпошта — API-розрахунок вартості та термінів у реальному часі.
• LiqPay, CloudPayments, ПриватБанк — прийом платежів, рекурентні списання, холдування.
• CRM — замовлення автоматично йде в Бітрікс24, створюється угода з прив'язкою до контакту.
• Склад — перевірка залишків через CCatalogStoreProduct::GetList() у реальному часі.

// Псевдокод для паралельних запитів
$promises = [];
foreach ($tariffs as $tariff) {
    $promises[] = async(function() use ($tariff, $basket) {
        return $tariff->calculate($basket);
    });
}
$results = awaitAll($promises, 3000);

Що входить у роботу

• Аналіз поточного чекауту та виявлення вузьких місць (аудит конверсії, логів, помилок).
• Проєктування UX: прототипування однокрокової форми, узгодження із замовником.
• Розробка компонента чекауту на основі Bitrix\Sale\Order + REST, з заміною sale.order.ajax.
• Інтеграція з платіжними (LiqPay, CloudPayments, ПриватБанк) та логістичними API (НПП, Boxberry, Укрпошта).
• Налаштування промокодів, крос-селу, покинутих кошиків.
• Тестування на реальних сценаріях: десктоп, мобільні, планшети.
• Передача документації (опис API, інструкції для менеджерів, доступи).
• Навчання співробітників роботі з новим кошиком.
• Пост-релізна підтримка — 2 тижні моніторингу та правок.

Строки

Зв'яжіться з нами для обговорення вашого проєкту та отримайте консультацію з конкретних завдань. Замовте аудит кошика вже сьогодні — побачите, скільки конверсії втрачається на кожному кроці. Збільшення конверсії чекауту на 1–2% при стабільному трафіку — це зростання виручки без зростання рекламного бюджету. Найшвидший ROI в e-commerce.