Налаштування SMS-повідомлень про покинутий кошик 1С-Бітрікс

Багато інтернет-магазинів на 1С-Бітрікс втрачають до 70% покинутих кошиків після email-розсилок. SMS-канал дає 95% відкриваності, але тільки при грамотному налаштуванні — інакше гроші на шлюз витрачаються даремно. Нещодавно до нас звернувся клієнт з каталогом електроніки на 50 000 товарів: після email повертали лише 5% кошиків, а після підключення SMS з тригодинним інтервалом — 18%. Довелося точно розраховувати бюджет, оскільки кожне повідомлення коштувало 3-5 грн. Ми налаштовували такі сценарії для десятків проектів і знаємо, як уникнути типових помилок: від дублювання повідомлень до блокування номера через перевищення лімітів.

SMS виправдані для кошиків із середнім чеком від 3000 грн. та товарів імпульсного попиту (електроніка, одяг). Email не доходить до клієнта — спам-фільтри, неактивні скриньки. SMS бачать всі, але ціна за повідомлення змушує рахувати кожен сценарій.

Чому SMS ефективніші за email для повернення кошиків?

Email-листи часто потрапляють у спам. SMS бачать майже одразу, але це дорогий канал. Тому ми застосовуємо SMS тільки коли користувач не відкрив email за 3-4 години — точний інтервал налаштовується під каталог. Згідно з ФЗ-38 «Про рекламу», для SMS-маркетингу потрібна попередня згода, що ми обов'язково реалізуємо.

Які технічні складнощі ховаються за SMS-розсилкою?

Головна проблема — точне отримання номера телефону. Якщо в профілі користувача немає UF_PHONE, доводиться парсити останнє замовлення, а це сповільнює агент. Друга складність — нормалізація номера: різні маски вводу (сім-495-123-45-67) перетворюємо в єдиний формат 74951234567. Третя — дотримання лімітів провайдера: не більше 100 повідомлень на хвилину на акаунт, інакше блокування.

Отримання телефону користувача

Телефон може зберігатися в полях користувача (b_user_field) або у властивостях замовлення. Наш стандартний підхід — перевіряти спочатку UF_PHONE, потім останнє замовлення:

function getUserPhone(int $userId): string
{
    $user = \Bitrix\Main\UserTable::getById($userId)->fetch();
    if (!empty($user['UF_PHONE'])) return $user['UF_PHONE'];

    $order = \Bitrix\Sale\Order::getList([
        'filter' => ['USER_ID' => $userId],
        'order'  => ['DATE_INSERT' => 'DESC'],
        'limit'  => 1,
        'select' => ['ID'],
    ])->fetch();

    if (!$order) return '';
    $orderObj = \Bitrix\Sale\Order::load($order['ID']);
    foreach ($orderObj->getPropertyCollection() as $prop) {
        if ($prop->getField('CODE') === 'PHONE') {
            return (string)$prop->getValue();
        }
    }

    return '';
}

Підключення SMS-шлюзу через API

Бітрікс має вбудований модуль main.smsmanager, але він не гнучкий для покинутих кошиків. Ми використовуємо прямий API провайдера — SMS.ru як приклад:

class SmsRuClient
{
    private string $apiId;

    public function __construct(string $apiId)
    {
        $this->apiId = $apiId;
    }

    public function send(string $phone, string $message, string $from = 'SHOP'): bool
    {
        $phone = preg_replace('/[^0-9]/', '', $phone);
        if (strlen($phone) === 10) $phone = '7' . $phone;

        $ch = curl_init('https://sms.ru/sms/send');
        curl_setopt_array($ch, [
            CURLOPT_POST => true,
            CURLOPT_POSTFIELDS => http_build_query([
                'api_id' => $this->apiId,
                'to'     => $phone,
                'msg'    => $message,
                'from'   => $from,
                'json'   => 1,
            ]),
            CURLOPT_RETURNTRANSFER => true,
            CURLOPT_TIMEOUT => 10,
        ]);

        $response = json_decode(curl_exec($ch), true);
        curl_close($ch);

        return isset($response['status']) && $response['status'] === 'OK';
    }
}

Як налаштувати агент відправки SMS?

Покрокове налаштування:

1. Створити таблицю abandoned_cart з полями USER_ID, FUSER_ID, STATUS, EMAIL_SENT_AT, SMS_SENT_AT.
2. Написати агент, який вибирає записи зі статусом email_sent, у яких минуло 3 години.
3. В агенті перевіряти згоду UF_SMS_CONSENT та наявність актуального телефону.
4. Відправляти SMS через SmsRuClient, оновлювати статус.
5. Зареєструвати агент з періодичністю 10 хвилин.

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

При замовленні налаштування SMS-повідомлень про покинуті кошики ви отримуєте:

• Аудит поточного збору телефонів та згод на розсилку.
• Інтеграцію обраного SMS-шлюзу (SMS.ru, SMSC.ru, МТС Комунікатор) з тестовим запуском.
• Створення агента відправки із захистом від дублювання та обробкою лімітів.
• Налаштування поля UF_SMS_CONSENT та форми згоди в особистому кабінеті.
• Документацію з підтримки та моніторингу.
• Навчання адміністраторів.

Як часто відправляти SMS?

SMS відправляємо тільки один раз, через 3 години після email, якщо лист не відкрито. Агент обробляє не більше 20 кошиків за раз, щоб не перевантажити шлюз:

function sendAbandonedCartSms(): string
{
    $smsClient = new SmsRuClient(getenv('SMSRU_API_ID'));

    $candidates = AbandonedCartTable::getList([
        'filter' => [
            'STATUS'         => 'email_sent',
            '<EMAIL_SENT_AT' => new \Bitrix\Main\Type\DateTime('-3 hours'),
            '=SMS_SENT_AT'   => false,
        ],
        'limit' => 20,
    ])->fetchAll();

    foreach ($candidates as $row) {
        $user = \Bitrix\Main\UserTable::getById($row['USER_ID'])->fetch();
        if (empty($user['UF_SMS_CONSENT'])) continue;

        $phone = getUserPhone($row['USER_ID']);
        if (!$phone) continue;

        if (hasRecentOrder($row['USER_ID'])) {
            AbandonedCartTable::update($row['ID'], ['STATUS' => 'recovered']);
            continue;
        }

        $basket  = \Bitrix\Sale\Basket::loadItemsForFUser($row['FUSER_ID'], SITE_ID);
        if ($basket->isEmpty()) continue;

        $smsText = buildCartSmsText($user['NAME'], $basket->getPrice(), '/basket/');
        $sent    = $smsClient->send($phone, $smsText);

        AbandonedCartTable::update($row['ID'], [
            'STATUS'      => $sent ? 'sms_sent' : 'sms_failed',
            'SMS_SENT_AT' => $sent ? new \Bitrix\Main\Type\DateTime() : null,
        ]);
    }

    return __FUNCTION__ . '();';
}

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

• Відправка без перевірки згоди — порушення ФЗ-38, блокування провайдером.
• Дублювання повідомлень — агент без прапорця відправки. Використовуйте статуси email_sent, sms_sent.
• Невірна нормалізація номера: +7 (495) 123-45-67 -> 74951234567. Помилка в коді призведе до пустої відправки.
• Занадто часті відправки — шлюз може заблокувати акаунт. Обмежте агент лімітом 20 кошиків за раз.

Як керувати згодою на SMS-маркетинг?

Поле UF_SMS_CONSENT повинно встановлюватися при реєстрації або в особистому кабінеті — явним чекбоксом «Хочу отримувати SMS з персональними пропозиціями». Без явної згоди відправка SMS порушує ФЗ-38. Ми гарантуємо дотримання законодавства при налаштуванні.

Рішення підходить як для 1С-Бітрікс, так і для Бітрікс24. Наша команда має багаторічний досвід роботи з Бітрікс та сертифікацію «1С-Бітрікс: Розробник». Ми реалізували понад 50 проектів з налаштуванням оповіщень. Отримайте консультацію по вашому проекту — напишіть нам. Замовте налаштування SMS-повідомлень і поверніть до 20% покинутих кошиків.

Як налаштування кошика 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.