Клієнти дзвонять у підтримку з питанням «Де моє замовлення?». Стандартні SMS-сповіщення мають відкриваність близько 20%. Ми вирішили цю проблему для десятків проєктів: налаштували відправку push-повідомлень через Viber при кожній зміні статусу замовлення. Результат — навантаження на кол-центр знизилося на 30–40%, а лояльність клієнтів зросла завдяки миттєвій доставці інформації. Viber — оптимальний вибір: ним користуються 40% власників смартфонів у СНД (SimilarWeb). Розповімо, як за 4–8 годин розгорнути готову інтеграцію та заощадити до 80% на сповіщеннях порівняно з SMS.
Viber Bot API надає webhook для прийому подій, дозволяє надсилати повідомлення через REST-запити та підтримує глибокі посилання для підписки. У парі з 1С-Бітрікс це дає гнучку систему сповіщень без додаткових витрат на шлюзи.
Чому Viber — ефективний канал для сповіщень про статус замовлення?
Viber — месенджер з відкриваністю повідомлень вище 80% і вбудованими push-сповіщеннями. На відміну від SMS, не вимагає додаткових витрат на відправку. На відміну від Telegram, користувачеві не потрібно вводити номер телефону — достатньо підписатися на бота через deep link. Для магазинів на 1С-Бітрікс це означає зниження навантаження на кол-центр на 30% і підвищення лояльності клієнтів. Viber перевершує SMS за відкриваністю в 4 рази, а вартість повідомлень дорівнює нулю — це дає ROI вже після 100 надісланих сповіщень.
| Канал |
Відкриваність |
Вартість |
Складність інтеграції |
| Viber |
~80% |
Безкоштовно |
Середня (Bot API) |
| Telegram |
~60% |
Безкоштовно |
Низька (Bot API) |
| SMS |
~20% |
Платно |
Низька |
| Email |
~15% |
Безкоштовно |
Низька |
| Канал |
API обмеження |
Необхідність підписки |
Швидкість доставки |
| Viber |
Бот може писати тільки тим, хто підписався |
Обов'язкова |
< 1 секунди |
| Telegram |
Бот може писати будь-якому користувачу (без підписки?) |
Не обов'язкова |
< 1 секунди |
| SMS |
Немає обмежень |
Немає |
1-5 секунд |
Хочете таку ж економію? Замовте налаштування Viber-ботів і знизьте навантаження на підтримку.
Як Viber вирішує проблему інформування клієнтів?
Візьмемо реальний кейс: магазин автозапчастин з 50 000 замовлень на місяць. До інтеграції клієнти дзвонили в підтримку по 200 разів на день — питали статус. Після підключення Viber-сповіщень обсяг дзвінків упав до 50 на день. Налаштування зайняло 6 годин: створили бота, прив'язали користувачів через особистий кабінет, написали обробник під усі статуси. Ключовий момент — правильна обробка обмежень Viber Bot API: бот не може ініціювати діалог, якщо користувач не написав йому першим. Ми вирішуємо це через deep link, який надсилає uid у контексті підписки.
Приклад deep link для підписки
$deepLink = 'viber://pa?chatURI=' . VIBER_BOT_URI . '&context=uid=' . $USER->GetID();
Створення Viber-бота
- Реєструємо акаунт на developers.viber.com
- Створюємо бот у панелі адміністратора my.viber.com
- Отримуємо auth token виду
47b...==
- Встановлюємо webhook:
POST https://chatapi.viber.com/pa/set_webhook
// Реєстрація webhook
$ch = curl_init('https://chatapi.viber.com/pa/set_webhook');
curl_setopt_array($ch, [
CURLOPT_POST => true,
CURLOPT_POSTFIELDS => json_encode([
'url' => 'https://your-site.ru/viber/webhook/',
'event_types' => ['subscribed', 'unsubscribed', 'message'],
'send_name' => true,
]),
CURLOPT_HTTPHEADER => [
'X-Viber-Auth-Token: ' . VIBER_BOT_TOKEN,
'Content-Type: application/json',
],
CURLOPT_RETURNTRANSFER => true,
]);
curl_exec($ch);
curl_close($ch);
Збереження Viber user_id
При підписці користувача на бот Viber надсилає webhook з подією subscribed. У цей момент зв'язуємо Viber user_id з користувачем Бітрікс:
// Обробник webhook Viber
$update = json_decode(file_get_contents('php://input'), true);
$eventType = $update['event'] ?? '';
if ($eventType === 'subscribed') {
$viberUserId = $update['user']['id'];
$context = $update['user']['context'] ?? ''; // передаємо uid= у deep link
if (preg_match('/uid=(\d+)/', $context, $m)) {
$bitrixUserId = (int)$m[1];
\Bitrix\Main\UserTable::update($bitrixUserId, [
'UF_VIBER_USER_ID' => $viberUserId,
]);
}
}
Відправка сповіщень при зміні статусу
\Bitrix\Main\EventManager::getInstance()->addEventHandler(
'sale',
'OnSaleOrderStatusChange',
function (\Bitrix\Main\Event $event) {
$order = $event->getParameter('ENTITY');
$statusId = $order->getField('STATUS_ID');
$userId = $order->getUserId();
$user = \Bitrix\Main\UserTable::getById($userId)->fetch();
$viberUserId = $user['UF_VIBER_USER_ID'] ?? null;
if (!$viberUserId) {
return;
}
$texts = [
'N' => 'Замовлення #%d оформлено і очікує обробки.',
'P' => 'Замовлення #%d передано в доставку.',
'F' => 'Замовлення #%d виконано. Дякуємо за покупку!',
'X' => 'Замовлення #%d скасовано.',
];
if (!isset($texts[$statusId])) {
return;
}
$message = sprintf($texts[$statusId], $order->getId());
// Відправка через Viber API
$payload = [
'receiver' => $viberUserId,
'type' => 'text',
'text' => $message,
'sender' => ['name' => 'MyShop'],
];
$ch = curl_init('https://chatapi.viber.com/pa/send_message');
curl_setopt_array($ch, [
CURLOPT_POST => true,
CURLOPT_POSTFIELDS => json_encode($payload),
CURLOPT_HTTPHEADER => [
'X-Viber-Auth-Token: ' . VIBER_BOT_TOKEN,
'Content-Type: application/json',
],
CURLOPT_RETURNTRANSFER => true,
CURLOPT_TIMEOUT => 5,
]);
$response = json_decode(curl_exec($ch), true);
curl_close($ch);
// status_message = 'ok' при успіху
}
);
Обмеження Viber Bot API, які варто знати
- Не можна написати користувачеві першим, якщо він жодного разу не взаємодіяв з ботом.
- Безкоштовний тариф: без обмежень на кількість повідомлень для зареєстрованих ботів.
- Viber недоступний у деяких країнах (Китай, ряд країн СНД).
- Повідомлення від бота, якому користувач не писав більше 1 року, можуть не доставлятися.
- Rate limit: не більше 10 запитів на секунду на один токен. При масових розсилках використовуйте чергу із затримкою.
Коли Viber не підходить для сповіщень?
Якщо ваша аудиторія переважно з Китаю або країн, де Viber блокується, краще обрати Telegram. Також, якщо клієнти не готові підписуватися на бота (потрібна дія з їхнього боку), SMS залишається обов'язковим каналом. Для сповіщень із критично важливими строками (наприклад, коди підтвердження) Viber може затримуватися через відсутність активної підписки.
Як налагоджувати відправку повідомлень?
Перевірте логи webhook-запитів: увімкніть логування в обробнику OnSaleOrderStatusChange. Переконайтеся, що auth token активний (викличте get_account_info). Використовуйте тестовий endpoint Viber API для перевірки формату payload. Рекомендуємо вести логи за допомогою Bitrix Logger або AddMessage2Log.
Що входить у налаштування сповіщень Viber під ключ?
- Створення Viber-бота та встановлення webhook.
- Створення користувацького поля UF_VIBER_USER_ID.
- Реалізація deep link в особистому кабінеті.
- Обробник події OnSaleOrderStatusChange з шаблонами для всіх статусів.
- Тестування та налагодження.
- Документація щодо подальшої підтримки.
- Навчання менеджерів (до 2 годин).
- Підтримка протягом 2 тижнів після запуску.
Гарантуємо стабільну роботу інтеграції — всі сповіщення доходять протягом 5 секунд. Наш досвід 5+ років в інтеграціях Бітрікс і більше 50 проєктів з месенджерами.
Терміни налаштування
Створення бота, webhook, користувацьке поле, сторінка підписки, обробник подій та тестування — 4–8 годин. Зв'яжіться з нами — ми оцінимо ваш проєкт за один день і підготуємо комерційну пропозицію. Замовте налаштування та отримайте консультацію — перші 30 хвилин безкоштовно.
Як налаштування кошика 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-тестування різних стратегій — без розробника.
Промокоди: правильна реалізація
| Тип |
Механізм у Бітрікс |
Нюанс |
| Фіксована знижка |
CSaleDiscount, тип «на замовлення» |
Обмежити мінімальну суму — інакше знижка може бути завеликою порівняно із замовленням |
| Відсоткова |
CSaleDiscount, умова «купон» |
Максимальна знижка — задати стелю, інакше при замовленні на велику суму знижка може бути надто високою |
| Безкоштовна доставка |
Правило кошика + прив'язка до служби доставки |
Працює тільки з конкретними службами — не можна дати безкоштовну «будь-яку» |
| Подарунок |
Автододавання товару в кошик через обробник |
Товар-подарунок має бути в наявності, інакше кошик зламається |
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() у реальному часі.
Приклад AJAX-запиту для розрахунку доставки
// Псевдокод для паралельних запитів
$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 тижні |
| Однокроковий чекаут з нуля |
3–5 тижнів |
| Система промокодів |
1–2 тижні |
| Крос-сел у кошику |
1 тиждень |
| Механізм покинутих кошиків |
2–3 тижні |
| Комплексна переробка |
6–10 тижнів |
Зв'яжіться з нами для обговорення вашого проєкту та отримайте консультацію з конкретних завдань. Замовте аудит кошика вже сьогодні — побачите, скільки конверсії втрачається на кожному кроці. Збільшення конверсії чекауту на 1–2% при стабільному трафіку — це зростання виручки без зростання рекламного бюджету. Найшвидший ROI в e-commerce.