Push-сповіщення про замовлення в Telegram для 1С-Бітрікс

Автоматизація push-сповіщень про замовлення через Telegram у 1С-Бітрікс

При зміні статусу замовлення в 1С-Бітрікс стандартні email-сповіщення губляться в спамі — відкриваність рідко перевищує 20%. Telegram доставляє повідомлення миттєво з читаністю 90%. Впровадження Telegram-бота скорочує кількість звернень у підтримку на 30–40% і суттєво знижує витрати на SMS-розсилки — це підтверджує дослідження RetailCRM. Додатково знижуються операційні витрати: перехід на push-сповіщення скорочує ручні відповіді операторів на 50%, що економить значні кошти при середньому потоці замовлень. Ми оцінюємо ваш проект за один день — зв'яжіться з нами, щоб обговорити деталі.

Telegram в 4 рази швидше за email по доставці та в 2 рази дешевший за SMS. У 9 з 10 випадків користувачі читають push-сповіщення Telegram у перші хвилини. Це знижує навантаження на підтримку та пришвидшує інформування клієнтів. Для інтернет-магазинів на 1С-Бітрікс інтеграція виконується через обробник події OnSaleOrderStatusChange і не потребує заміни існуючої системи сповіщень.

Проблеми, які вирішує Telegram-бот

• Email у спамі: до 30% листів не доходять до клієнта. Telegram гарантує доставку 99% повідомлень.
• Затримки сповіщень: листи можуть іти до 5 хвилин. Telegram — 1–2 секунди.
• Низька читаність: 80% email залишаються непрочитаними. Telegram-повідомлення відкривають у перші хвилини.
• Ручна підтримка: оператори витрачають час на відповіді про статуси. Бот бере цю роботу на себе.

Чому Telegram-сповіщення ефективніші за email?

Порівняння за ключовими метриками:

Як працює інтеграція з Бітрікс?

При зміні статусу замовлення Бітрікс генерує подію OnSaleOrderStatusChange. Стандартний механізм сповіщень (/bitrix/admin/posting_list.php) відправляє email. Telegram підключається як додатковий канал через обробник події. Детальніше про події — в офіційній документації Бітрікс.

Які статуси замовлення підтримуються?

Як створити обробник зміни статусу замовлення

Створення Telegram-бота для сповіщень

Бот для сповіщень про замовлення — не діалоговий, а push-only: він тільки відправляє, не приймає команди. Створюється через @BotFather:

/newbot
Название: Уведомления MyShop
Username: myshop_orders_bot

Отримуємо токен виду 1234567890:AAHb-xxxxxx. Токен зберігається в налаштуваннях модуля або в /bitrix/.settings.php, не в коді шаблону.

Користувач повинен почати діалог з ботом (/start), щоб бот отримав його chat_id. Для цього в особистому кабінеті додається кнопка «Підключити Telegram-сповіщення», яка відкриває посилання https://t.me/myshop_orders_bot?start=uid_12345.

Збереження chat_id користувача

// Webhook бота принимает /start с параметром
$update = json_decode(file_get_contents('php://input'), true);
$text = $update['message']['text'] ?? '';
$chatId = $update['message']['chat']['id'];

if (preg_match('/^\/start uid_(\d+)$/', $text, $matches)) {
    $userId = (int)$matches[1];

    // Сохраняем chat_id в пользовательское поле UF_TELEGRAM_CHAT_ID
    \Bitrix\Main\UserTable::update($userId, [
        'UF_TELEGRAM_CHAT_ID' => $chatId,
    ]);

    // Подтверждение пользователю
    TelegramApi::sendMessage($chatId, 'Telegram-уведомления о заказах подключены.');
}

Обробник зміни статусу замовлення

// /local/php_interface/init.php
\Bitrix\Main\EventManager::getInstance()->addEventHandler(
    'sale',
    'OnSaleOrderStatusChange',
    function (\Bitrix\Main\Event $event) {
        $order = $event->getParameter('ENTITY');
        $statusId = $order->getField('STATUS_ID');
        $userId = $order->getUserId();

        // Читаем chat_id пользователя
        $user = \Bitrix\Main\UserTable::getById($userId)->fetch();
        $chatId = $user['UF_TELEGRAM_CHAT_ID'] ?? null;

        if (!$chatId) {
            return; // Пользователь не подключил Telegram
        }

        // Формируем текст по статусу
        $messages = [
            'N' => 'Заказ #%d принят и ожидает обработки.',
            'P' => 'Заказ #%d передан в доставку.',
            'F' => 'Заказ #%d выполнен. Спасибо за покупку!',
            'X' => 'Заказ #%d отменён.',
        ];

        $template = $messages[$statusId] ?? null;
        if (!$template) {
            return;
        }

        $text = sprintf($template, $order->getId());
        $text .= "\n\nПодробнее: " . SITE_SERVER_NAME . '/personal/orders/' . $order->getId() . '/';

        // Отправляем через Telegram Bot API
        TelegramBotService::send($chatId, $text);
    }
);

Клас відправки в Telegram Bot API

class TelegramBotService
{
    private static string $token = '1234567890:AAHb-xxxxxx';

    public static function send(string $chatId, string $text, array $options = []): bool
    {
        $params = array_merge([
            'chat_id'    => $chatId,
            'text'       => $text,
            'parse_mode' => 'HTML',
        ], $options);

        $ch = curl_init('https://api.telegram.org/bot' . self::$token . '/sendMessage');
        curl_setopt_array($ch, [
            CURLOPT_POST           => true,
            CURLOPT_POSTFIELDS     => json_encode($params),
            CURLOPT_HTTPHEADER     => ['Content-Type: application/json'],
            CURLOPT_RETURNTRANSFER => true,
            CURLOPT_TIMEOUT        => 5,
        ]);
        $response = curl_exec($ch);
        curl_close($ch);

        return json_decode($response, true)['ok'] ?? false;
    }
}

Токен зберігається не в коді, а в конфігу:

// /bitrix/.settings.php
'custom' => [
    'value' => [
        'telegram_bot_token' => '1234567890:AAHb-xxxxxx',
    ],
],

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

• Створення та налаштування Telegram-бота через @BotFather
• Розробка сторінки підключення в особистому кабінеті покупця
• Реалізація обробника подій на OnSaleOrderStatusChange
• Збереження chat_id у користувацьке поле UF_TELEGRAM_CHAT_ID
• Тестування всіх статусів замовлення (N, P, F, X та нестандартних)
• Документація з експлуатації та подальшої підтримки
• Навчання адміністратора роботі з ботом

Строки налаштування

Створення бота, користувацьке поле, сторінка підключення, обробник подій — 6–10 годин. У складних випадках (багато статусів, нестандартна логіка) строк збільшується до 2–3 днів. Ми гарантуємо стабільну роботу сповіщень після налаштування. Наша команда має сертифікацію 1С-Бітрікс та більш ніж 10 років досвіду розробки на цій платформі. За час роботи ми реалізували 50+ проектів з інтеграцією Telegram-сповіщень. Отримайте консультацію з налаштування Telegram-бота для вашого магазину.

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

1. Зберігання токена у файлі шаблону — токен повинен бути в /bitrix/.settings.php або в налаштуваннях модуля.
2. Відсутність перевірки існування chat_id — якщо користувач не підключив бота, код повинен коректно завершуватись без помилок.
3. Не всі статуси замовлення оброблені — для кожного статусу потрібно передбачити шаблон повідомлення, інакше сповіщення не відправиться.
4. Ігнорування сповіщень про скасування замовлення — цей статус часто пропускають, але клієнт повинен знати про скасування.

Як діагностувати проблеми з доставкою?

Якщо сповіщення не приходять, перевірте, чи почав користувач діалог з ботом (команда /start). Переконайтеся, що токен активний та chat_id збережено в UF_TELEGRAM_CHAT_ID. Перегляньте лог обробника — можливо, блокування через ліміти Telegram на кількість повідомлень (30 msg/sec). У складних випадках підключіть покрокове логування.

Замовте налаштування Telegram-бота — отримайте консультацію та оцінку проекту за один день без передоплати. Ми інтегруємо бота з вашою CRM та 1С, забезпечивши стабільні сповіщення на всіх етапах замовлення.

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